port. Something
> in 4.4, most probably 4fd41a8552af ("SCSI: Fix NULL pointer
> dereference in runtime PM") is also needed.
Although that commit isn't in 4.3.x yet, it should be added soon.
Maybe in the next release.
Alan Stern
f ("SCSI: Fix NULL pointer
dereference in runtime PM"), which was added to the mainline kernel
between 4.3 and 4.4. I don't know what the commit ID would be for a
.stable kernel.
Alan Stern
at the problem must be.
It's too bad nobody was able to capture a log where the error
occurred in sr_runtime_suspend, though -- all the logs in the bug
report show sd_runtime_resume.
> Alan, thank you a lot for being so responsive and helpful!
You're welcome.
Alan Stern
drive
and test a patched kernel. There are no
problems on my computer, so it will have to be one or more of you guys.
Alan Stern
Compare with the
Subject: line in this email thread.
> I will try to do a photo next time, too.
If I send you a patch, can you build and test it?
Alan Stern
eference
in sd_resume(), though. If you revert them, does the problem go away?
Also, can you add some debugging statements to sd_resume() so we can
see where the NULL pointer comes from?
Alan Stern
more, and using Linux
> 3.19 the drive is detected and the system boots.
>
> Does anything stand out what changed in this area between Linux 3.19 and
> 4.1?
I believe the problem shown in that photo was fixed by commit
49718f0fb8c9 ("SCSI: Fix NULL pointer dereference in runtime P
On Sat, 31 Oct 2015, Alan Stern wrote:
> I believe the problem shown in that photo was fixed by commit
> 49718f0fb8c9 ("SCSI: Fix NULL pointer dereference in runtime PM"),
> which was merged in 4.2 and has been back-ported to various stable
> releases.
On second thought
Sending to author of the offending commit and maintainer of the
xhci-hcd driver.
Alan Stern
On Sat, 9 May 2015, Ralf Jung wrote:
> Hi,
>
> > The USB-3 driver is made up of these files: drivers/usb/host/xhci*
>
> I did a bisect on these files only, and
ch folder I should restrict the bisect
> to - otherwise, this would take way too long.
The USB-3 driver is made up of these files: drivers/usb/host/xhci*
Alan Stern
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
is strongly
suggests that the bug doesn't lie in the controller itself but in the
firmware (BIOS or ACPI).
Alan Stern
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Wed, 19 Dec 2012, Octavio Alvarez wrote:
> On Wed, 19 Dec 2012 08:57:00 -0800, Alan Stern
> wrote:
>
> > You, the stupid end-user, would not see this message at all under
> > normal circumstances. It uses the ohci_dbg macro and therefore will
> > not appear
On Wed, 19 Dec 2012, Octavio Alvarez wrote:
> On Wed, 19 Dec 2012 07:29:23 -0800, Alan Stern
> wrote:
> >> + ohci_dbg(ohci, "marked as bad wakeup.\n");
> >
> > I'd prefer the message to be something more like "enabled nVidia/SiS
> >
m, not an error in the UHCI controller hardware.
Alan Stern
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
x/usb/hcd.h2012-12-19 10:48:43.305822774 +0800
> @@ -138,6 +138,7 @@
> resource_size_t rsrc_start; /* memory/io resource
> start */
> resource_size_t rsrc_len; /* memory/io resource
> length */
> unsignedpo
rn 0;
> > +}
>
> I would informing the user via dmesg output about the applied quirk
> and a point him to relevant documentation. Something like this:
>
> "Detected OHCI controller ID :, which requires no-wakeup quirk.
> See Documentation/quirks/ohci-no-wakeup.txt"
Incidentally, this patch should be written differently. Instead of a
quirks routine, there should simply be a bad_wakeup bitflag added to
the usb_hcd structure. The flag should be set in ohci-pci.c by
matching against nVidia's PCI vendor ID.
Alan Stern
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
newer chipset revisions / generations ?
Has anybody ever seen a report of an nVidia OHCI controller that does
_not_ have this bug?
Alan Stern
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
me bug on another M2N board
> with MCP55 a while ago).
It would be great if we could get in touch with an engineer at ASUS or
nVidia who knows the cause of this problem and how to work around it.
Tianyu, do you think this would be possible?
Alan Stern
--
To UNSUBSCRIBE, email to debi
e devices are probably
working correctly.
Do you have one of these machines to test?
Alan Stern
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ies for malfunctioning USB devices.
I don't know about malfunctioning host controllers, though. Maybe.
> Or you
> have some new debug measures, they are welcome. If something I said is
> wrong, please
> help me correct it. Thanks.
We really need to know which compo
ther one connected.
>
> Having said that, I have also seen the system suspend, but I don't
> quite trust these tests. I think I may have failed to make sure
> the settings were appropriate for the test (wrong kernel or wakeup
> disabled).
Did anything ever happen with this?
Ala
On Thu, 4 Oct 2012, Sébastien Dinot wrote:
> Alan Stern a écrit :
> > The log file shows lots and lots of low-level communication errors.
> > They could be caused by bad cabling or by bad USB hardware in your
> > computer. It's unlikely that they were caused by the mous
On Thu, 4 Oct 2012, Sébastien Dinot wrote:
> Hi,
>
> Alan Stern a écrit :
> > Please build a kernel with CONFIG_USB_DEBUG enabled.
>
> Done (3.6.0+ kernel)
>
> > When a hang occurs, get a list of hang tasks (Alt-SysRq-w probably
> > won't work, but &qu
but
"echo w >/proc/sysrq-trigger" from a network login should). Then send
the dmesg output
Alan Stern
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Mon, 9 Jul 2012, Octavio Alvarez wrote:
> On Sun, 08 Jul 2012 17:28:25 -0700, Alan Stern
> wrote:
>
> >> >> Removing my pen drive cleared CCS on [6].
> >> >
> >> > Okay, that explains that. More or less. Is this an old USB-1.1 pen
> >
On Sun, 8 Jul 2012, Octavio Alvarez wrote:
> >> On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern
> >>
> >> wrote:
> >>
> >> >> roothub.portstatus [4] 0x0303 LSDA PPS PES CCS
> >> >> roothub.portstatus [5] 0x0303
On Sat, 7 Jul 2012, Octavio Alvarez wrote:
> On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern
> wrote:
>
> >> roothub.portstatus [4] 0x0303 LSDA PPS PES CCS
> >> roothub.portstatus [5] 0x0303 LSDA PPS PES CCS
> >> roothub.portstatus [6] 0x0101 P
er, 0b.0.
> I also bisected the "3.2 doesn't sleep due to ohci" problem and found this:
>
> commit a6eeeb9f45b5a417f574f3bc799b7122270bf59b
> Author: Alan Stern
> Date: Mon Sep 26 11:23:38 2011 -0400
>
> USB: Update USB default wakeup settings
Yes
On Mon, 25 Jun 2012, Octavio Alvarez wrote:
> On Mon, 25 Jun 2012 07:33:11 -0700, Alan Stern
> wrote:
>
> > What happens if Octavio disables wakeup for that controller before
> > suspending?
> >
> > echo disabled >/sys/bus/pci/devices/:00:0b.0/powe
Latency: 0 (750ns min, 250ns max)
> Interrupt: pin A routed to IRQ 23
> Region 0: Memory at d5006000 (32-bit, non-prefetchable) [size=4K]
> Capabilities:
> Kernel driver in use: ohci_hcd
>
> The Nvidia implementation of OHCI is unusual in some ways and
atches of source code.
>
> However, I will be pleased, if I can help with testing. If there is a kernel-
> package available, I will be pleased, to install it and send the results.
Can you ask somebody more familiar with Debian to build a patched
kernel for you?
Alan Stern
--
To UNS
-2.6.32-5-amd64-31 (and
> > higher!)
> > and it appeared only on 64-bit-systems.
> [...]
>
> The only change to ohci-hcd between these versions was:
>
> commit 5f528de0ef9b3e092e276d95930830b847b33dc4
> Author: Alan Stern
> Date: Fri S
ked-by: Alan Stern
CC: Matthew Dharm
CC: sta...@kernel.org
---
This would be better if the bcdDevice range was more specific. But we
can take it as it is.
drivers/usb/storage/unusual_devs.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/s
On Fri, 20 Nov 2009, Vitaly Kuznetsov wrote:
> Alan Stern writes:
>
> >> So, the minimum is US_FL_MAX_SECTORS_64 | US_FL_BULK_IGNORE_TAG
> >
> > I would still like to see a usbmon trace showing what happens with
> > US_FL_BULK_IGNORE_TAG and _without_ US_F
On Fri, 20 Nov 2009, Vitaly Kuznetsov wrote:
> Alan Stern writes:
>
> >> > +/* Reported by Vitaly Kuznetsov */
> >> > +UNUSUAL_DEV( 0x04e8, 0x5122, 0x, 0x,
> >> > + "Samsung",
> >> > + &
"Samsung",
> > + "YP-CP3",
> > + US_SC_DEVICE, US_PR_DEVICE, NULL,
> > + US_FL_MAX_SECTORS_64 | US_FL_FIX_INQUIRY |
> > US_FL_FIX_CAPACITY | US_FL_BULK_IGNORE_TAG),
This is highly questionable. How can you be
s usb
> internals, so they can expose an interface libusb can use
> to come up with good error reporting.
Shouldn't you be writing to the authors of libusb instead? The
interface between libusb and the kernel is adequate; you're asking
about changes to the interface between libu
er the device is able to drive the USB data lines or it
isn't. If it can then it should function normally. If it can't, the
kernel will realize it was disconnected.
Alan Stern
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
1in-intr
> Dec 21 14:41:28 wmiwilli kernel: usb 2-1: unregistering interface 2-1:1.0
> Dec 21 14:41:28 wmiwilli kernel: usb 2-1:1.0: hotplug
> Dec 21 14:41:28 wmiwilli kernel: usb 2-1: unregistering device
> Dec 21 14:41:28 wmiwilli kernel: usb 2-1: hotplug
> Dec 21 14:41:28
ection, or it
could be the mouse sending a bad signal, or it could be some sort of
outside electromagnetic interference.
By the way, it looks like you don't need the entire patch. Just the parts
the remove the lines saying
case -EILSEQ:
should be enough to help.
Alan Ster
er saw that messages. Or do you mean, it is bug that these messages
> weren't reported when CONFIG_USB_DEBUG is on?
I meant that there should have been something in the log even without the
patch. Not the same as what you get with the patch, but something.
Alan Stern
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
le, because it is now four months old.
This _should_ have shown up in the dmesg log if you had CONFIG_USB_DEBUG
turned on. Make sure you have it on when running more tests.
Alan Stern
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
-2:1.0: hotplug
> usbhid 2-2:1.0: usb_probe_interface
> usbhid 2-2:1.0: usb_probe_interface - got id
> input: USB HID v1.10 Mouse [Logitech USB Mouse] on usb-:00:1d.1-2
> hub 2-0:1.0: state 5 ports 2 chg 0000 evt 0004
That's all normal.
> Is there some usb sniffer for linux
other. (Note that both mice are wheel mice, and share the same design,
> doesn't make sense to me that one is named ".. Mouse" and one ".. Wheel
> Mouse")
To get more information, turn on USB verbose debugging (CONFIG_USB_DEBUG)
in the kernel configuration a
44 matches
Mail list logo
