[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1041678: marked as done (at24 0-005…: supply vcc not found, using dummy regulator)

Your message dated Tue, 01 Aug 2023 01:09:37 +0200
with message-id <6531216.tM3a2QDmDi@bagend>
and subject line Re: Debian's BTS is not for regular user questions
has caused the Debian Bug report #1041678,
regarding at24 0-005…: supply vcc not found, using dummy regulator
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1041678: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041678
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: linux-image-6.1.0-10-amd64
Version: 6.1.37-1
Severity: wishlist
Control: affects -1 src:linux
In my journal I discovered a bunch of orange warnings of the form “at24 0-005…: supply vcc not found, using dummy regulator”:
Jul 22 00:07:06 AnonymizedMachineName kernel: cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters Jul 22 00:07:06 AnonymizedMachineName kernel: input: PC Speaker as /devices/platform/pcspkr/input/input9 Jul 22 00:07:06 AnonymizedMachineName kernel: usbcore: registered new interface driver cdc_mbim Jul 22 00:07:06 AnonymizedMachineName kernel: at24 0-0050: supply vcc not found, using dummy regulator Jul 22 00:07:06 AnonymizedMachineName kernel: at24 0-0050: 256 byte spd EEPROM, read-only Jul 22 00:07:06 AnonymizedMachineName kernel: at24 0-0051: supply vcc not found, using dummy regulator Jul 22 00:07:06 AnonymizedMachineName kernel: at24 0-0051: 256 byte spd EEPROM, read-only Jul 22 00:07:06 AnonymizedMachineName kernel: at24 0-0052: supply vcc not found, using dummy regulator Jul 22 00:07:06 AnonymizedMachineName kernel: iTCO_vendor_support: vendor-support=0 Jul 22 00:07:06 AnonymizedMachineName kernel: at24 0-0052: 256 byte spd EEPROM, read-only Jul 22 00:07:06 AnonymizedMachineName kernel: at24 0-0053: supply vcc not found, using dummy regulator Jul 22 00:07:06 AnonymizedMachineName kernel: at24 0-0053: 256 byte spd EEPROM, read-only Jul 22 00:07:06 AnonymizedMachineName kernel: mc: Linux media interface: v0.10
First, I asked myself what I am being warned about, and it took me quite some time to find out what “vcc” means. Is actually “Vcc”, the voltage common collector as on http://upload.wikimedia.org/wikipedia/commons/4/4b/Voltage_subscripts.png , meant (where “cc” or “CC” is sometimes typeset as a subscript)? If so, write this way, i.e., “Vcc” (or, as a proper abbreviation, “VCC”). The term “vcc” in small letters means to me, for example, the command-line call of the verifying C compiler; to other folks “vcc” might mean something else. If “vcc” here is NOT the voltage common collector, consider writing the full term instead of the abbreviation. (Similar goes for “spd”: if it's a proper abbreviation and not a typo, consider capitalizing all the letters. Further, even “SPD“ might mean many things, from “Serial Presence Detect” to “Surge Protection Device”, so if the context doesn't make it clear, write the full term instead of the abbreviation.)
Second, are these orange messages real warnings (i.e., they foretell potential havoc) or only informational? In the real case, what could go wrong? In the purely informational case, consider making them normal gray-white messages, so that the user is nor really feeling warned or bothered. 

Gratefully,
AlMa

--- End Message ---
--- Begin Message --- 
On Sat, 15 Jul 2023 03:13:51 +0200 AlMa <AlMa0@ro.ru> wrote:
> In the journal I see two yellow lines (which, probably, constitute 
> warnings) directly following one another:
> … 
> Later in the journal we see a white line
> … 
> 
> As the machine (Dell Mobile Precision M6700) experiences various 
> high-level issues later in the boot process, I'm unsure about the 
> contribution of the two issues in the log.  Which software or hardware 
> problems do these warnings inform us about?  Any fix or remedy?

You filed various bugs talking about yellow and white lines of which you 
suspect that yellow may be a warning (which you should be able to find out by 
yourself if that's the case).

The Debian BTS is not meant to ask questions like "what could this message 
tell us?". Put it in a search engine or use one of the MANY user support 
options for that. Computers/Linux put various debug/informational/warning msgs 
in various logs, which _could_ be helpful in case there's an actual ERROR.

But the only *potential* error I see here is "various high-level issues", 
which is so vague so that's completely useless and inactionable.

So I'm going to close this and similar vague bug reports, which aren't 
actually bug reports, but just questions.
And all those ACPI errors? Contact the machine vendor as they're the only ones 
who could resolve such issue. Linux is only reporting that there are issues.

"If we believe Jean Delvare" ... and Jean Delvare response in that bug report:
"This is not a support forum, sorry. If you need help, use support forums and 
mailing lists." ...

From 'bug' #1041191: "Will the fingerprint sensor not work?"
I _assume_ you have the device/machine, so why don't you try it out?
*IF* it turns out it doesn't work then you first use a search engine to see if 
you can make it work yourself by trying out various hints you'll undoubtedly 
find and if that doesn't make it work, *THEN* you have something to file a bug 
about.

You filed *8* different 'bugs' which (almost?) all are about a Dell Mobile 
Precision M6700 ... and not once did you say what actual problem you 
experienced?!?

If you file a bug, you're (basically) asking (several) people to read about a 
problem you're having and then subsequently (potentially) spend time to fix 
that/those problem(s).
Please be more considerate with other people's time and only file bugs for 
*actual* problems and then provide enough information/context so that they
can actually (potentially) act upon it and help you fix that problem.

I initially intended to respond to some actual problems you (also) reported, 
but I've already spend way too much time on these non-issues, so I'm done.

Attachment: signature.asc
Description: This is a digitally signed message part.


--- End Message ---
Reply to: