Bug#801925: NULL pointer dereference: IP: [] sr_runtime_suspend+0xc/0x20 [sr_mod]
On Tue, 23 Feb 2016, Alexandre Rossi wrote:
> Okay now I've tried with 4.4. The oops does not occur. So this is
> fixed for me in 4.4.
>
> If there is interest in backporting to 4.3, 13b438914341 ("SCSI: fix
> crashes in sd and sr runtime PM") is not enough to backport. 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
Bug#801925: NULL pointer dereference: IP: [] sr_runtime_suspend+0xc/0x20 [sr_mod]
On Tue, 9 Feb 2016, Alexandre Rossi wrote:
> Hi,
>
> netconsole does not seem to work so early in the boot process this time.
>
> > As this is Linux 4.3 and not 4.4, I guess this is a different problem
> > though. Alexandre, where you able to capture the stack trace? I’d submit
> > a new bug report with this.
>
> Here is a photo. Please ping me if you need to test some debugging patches.
It looks like the problem occurs in blk_post_runtime_resume(). Since
there have been recent changes to this routine, it's hard to tell
whether you're using the most up-to-date code.
In particular, the first few lines of blk_post_runtime_resume() in
block/blk-core.c should look like this:
void blk_post_runtime_resume(struct request_queue *q, int err)
{
if (!q->dev)
return;
The test was introduced by commit 4fd41a8552af ("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
Bug#801925: NULL pointer dereference: IP: [] sr_runtime_suspend+0xc/0x20 [sr_mod]
On Tue, 19 Jan 2016, Paul Menzel wrote:
> Could you please attach the debugging patch. Hopefully Alexandre, Erich,
> or I will have some spare time to build an image from it.
Actually, this patch is an attempt at a fix. After looking more
carefully at your log pictures, I realized what 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
drivers/scsi/sd.c |7 +--
drivers/scsi/sr.c |4
2 files changed, 9 insertions(+), 2 deletions(-)
Index: usb-4.4/drivers/scsi/sd.c
===
--- usb-4.4.orig/drivers/scsi/sd.c
+++ usb-4.4/drivers/scsi/sd.c
@@ -3275,8 +3275,8 @@ static int sd_suspend_common(struct devi
struct scsi_disk *sdkp = dev_get_drvdata(dev);
int ret = 0;
- if (!sdkp)
- return 0; /* this can happen */
+ if (!sdkp) /* E.g.: runtime suspend following sd_remove() */
+ return 0;
if (sdkp->WCE && sdkp->media_present) {
sd_printk(KERN_NOTICE, sdkp, "Synchronizing SCSI cache\n");
@@ -3315,6 +3315,9 @@ static int sd_resume(struct device *dev)
{
struct scsi_disk *sdkp = dev_get_drvdata(dev);
+ if (!sdkp) /* E.g.: runtime resume at the start of sd_probe() */
+ return 0;
+
if (!sdkp->device->manage_start_stop)
return 0;
Index: usb-4.4/drivers/scsi/sr.c
===
--- usb-4.4.orig/drivers/scsi/sr.c
+++ usb-4.4/drivers/scsi/sr.c
@@ -144,6 +144,9 @@ static int sr_runtime_suspend(struct dev
{
struct scsi_cd *cd = dev_get_drvdata(dev);
+ if (!cd)/* E.g.: runtime suspend following sr_remove() */
+ return 0;
+
if (cd->media_present)
return -EBUSY;
else
@@ -985,6 +988,7 @@ static int sr_remove(struct device *dev)
scsi_autopm_get_device(cd->device);
del_gendisk(cd->disk);
+ dev_set_drvdata(dev, NULL);
mutex_lock(&sr_ref_mutex);
kref_put(&cd->kref, sr_kref_release);
Bug#801925: NULL pointer dereference: IP: [] sr_runtime_suspend+0xc/0x20 [sr_mod]
On Tue, 19 Jan 2016, Erich Schubert wrote: > Hi, > Attached are photos of the Kernel null pointer BUG that I'm observing. > > These shots are with 4.4.0-rc8. > As you can see, I have a similar trace to Paul, but the error occurs > one stack frame earlier? Yours is only slighly similar to Paul's. He got an error in sr_runtime_suspend, but your error occurs in sd_resume -- a completely different function in a different source file. > Maybe Alex issue is the same bug, but triggered slightly different or > just the kernel compiled differently. > __rpm_callback, scsi_autopm_put_device, __pm_runtime_resume, sd_probe > is present in all of these traces. > > Sorry, I do not have a lot of time right now to help testing or debugging. I can't tell what's going wrong without some real debugging. This means somebody has to build 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
Bug#801925: NULL pointer dereference: IP: [] sr_runtime_suspend+0xc/0x20 [sr_mod]
On Sun, 10 Jan 2016, Erich Schubert wrote: > Hi all, > 4.4-rc8 does not fix the problem for me. > Anything beyond 4.1.0 remains unable to boot this computer. > > Unfortunately, because the error occurs during early early SCSI > initialization, I do not have easy access to the log - no disk, no > network. > It happens during SATA initialization: "scsi_runtime_resume". You didn't include any debugging information. However... > So my back trace looks different than Alex in > https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=42;filename=scsi-null-pointer-dereference.log;bug=801925;att=1 > but like the one Paul is seeing: > https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;filename=20151020_006.jpg;bug=801925;att=3 The information in that bug report says that the failure happens in sr_runtime_resume, not in scsi_runtime_resume. 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
Bug#801925: NULL pointer dereference: IP: [] sr_runtime_suspend+0xc/0x20 [sr_mod]
On Sat, 9 Jan 2016, Paul Menzel wrote: > Version: 4.4~rc8-1~exp1 > > Dear Alan, > > > Thank you for your help! > > There were some follow-ups to the bug report [1], but I think you and I > were not in CC. I wasn't. > > http://marc.info/?l=linux-scsi&m=144185206825609&w=2 > > http://marc.info/?l=linux-scsi&m=144185208525611&w=2 > I can only say, that I am still unable to boot my system with Linux > 4.4-rc8 [2]. Are these patches included there? They are. I don't see how they could cause a NULL pointer dereference 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
Bug#801925: NULL pointer dereference: IP: [] sr_runtime_suspend+0xc/0x20 [sr_mod]
On Sat, 31 Oct 2015, Paul Menzel wrote:
> > Well, that didn't help much. Paul hit another oops, this time in
> > sd_mod but again apparently related to runtime PM. My patch only
> > touched sr_mod.
> >
> > This time he sent photos of the complete oops; see
> > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801925;filename=20151020_005.jpg;att=4;msg=15>
> > and
> > <https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=20151020_006.jpg;bug=801925;att=3;msg=15>
>
> after backing up my data, I tested a little bit 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 PM"),
which was merged in 4.2 and has been back-ported to various stable
releases.
Alan Stern
Bug#801925: NULL pointer dereference: IP: [] sr_runtime_suspend+0xc/0x20 [sr_mod]
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, it seems more likely that this issue probably was
_caused_ by that commit. The fix can be found in these two emails:
http://marc.info/?l=linux-scsi&m=144185206825609&w=2
http://marc.info/?l=linux-scsi&m=144185208525611&w=2
which have not been merged yet as far as I know even though they were
submitted back in September.
Alan Stern
Bug#782442: USB3 external HDD not recognized [regression]
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 here's the result: > > > d6236f6d1d885aa19d1cd7317346fe795227a3cc is the first bad commit > > commit d6236f6d1d885aa19d1cd7317346fe795227a3cc > > Author: Wang, Yu > > Date: Tue Jun 24 17:14:44 2014 +0300 > > > > xhci: Fix runtime suspended xhci from blocking system suspend. > > I confirmed that reverting this commit on top of v3.16 indeed fixes the > issue. > > (Just to remind you, the context is the following bug report: > <https://bugzilla.kernel.org/show_bug.cgi?id=96531>). > > Kind regards, > Ralf > I just tested the v4.1-rc2 kernel to confirm that the issue is still > present. Reverting above commit again fixed the issue. > > Please let me know if there is any other information you need from me. > > Kind regards, > Ralf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#782442: USB3 external HDD not recognized [regression]
On Wed, 15 Apr 2015, Ralf Jung wrote: > Hi all, > > One of my external hard disks does not work anymore with current > kernels, when I plug it into my USB3 port. ... > I can do a git bisect when I am back from travel (in ~1 week), but I > would appreciate some guess of which 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
Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Wed, 19 Dec 2012, [ISO-8859-1] Frank Sch�fer wrote: > I can confirm that MCP55 has this bug and it should be safe to add > MCP65-78S, too, because MCP79 still has the bug. By the way, you mentioned that runtime suspend seemed to work okay, right? It might be worthwhile testing this again, just to be certain. In particular, I'd like to see what "lspci -vv" shows for the controller while it is runtime suspended with a device attached. As far as the OHCI hardware is concerned, there shouldn't be any difference between runtime suspend and system suspend. This 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
Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
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 unless your kernel is built with CONFIG_USB_DEBUG enabled. > > Shouldn't it be exposed to dmesg? None of the other quirk messages are. On the other hand, they don't affect the behavior as much as this quirk does. Still, if we do produce a message about it, I don't feel it is necessary to try and explain the whole situation. Something as simple as "Buggy wakeup support, disabling" should be enough for an end-user who wants to know why typing on the USB keyboard doesn't wake up a suspended system. Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
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 > > wakeup quirk". > > To me, the stupid end-user, both messages are useless. I don't know 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 unless your kernel is built with CONFIG_USB_DEBUG enabled. > that that means or implies. I would go with: > "Disabled OHCI wakeup (USB) due to faulty controller (no-wakeup.txt)" > > and have a file named no-wakeup.txt under Documentation with this: > > " > Users have reported OHCI misbehavior consisting on false wakeups right > after suspend to RAM on some OHCI controllers, particularly from nVIDIA > and SiS. For those controllers, wakeups has been disabled. > > The system will not be able to wake up the system from suspend > to RAM from an OHCI (USB) device. > > To see the list of affected controllers do: > > grep -B 3 ohci_quirk_bad_wakeup linux-pm/drivers/usb/host/ohci-pci.c > > Bug is tracked at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677472 > " It wouldn't hurt to include a URL for the bug report in a comment. Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Wed, 19 Dec 2012, lantianyu wrote: > Oh. I forget to mention the issue also takes place on the uhci. > https://bugzilla.kernel.org/show_bug.cgi?id=42721 > So we also should make such a patch for uhci. That bug report shows clearly that it is a software problem or a device problem, 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
Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Wed, 19 Dec 2012, Lan Tianyu wrote:
> Hi Alan:
>
> How about this patch?
>
> Index: linux-pm/drivers/usb/host/ohci-pci.c
> ===
> --- linux-pm.orig/drivers/usb/host/ohci-pci.c 2012-11-01
> 18:21:33.604460469 +0800
> +++ linux-pm/drivers/usb/host/ohci-pci.c2012-12-19
> 14:39:07.081601806 +0800
> @@ -188,6 +188,15 @@
> pci_write_config_word(pdev, 0x50, misc | 0x0300);
> }
>
> +static int ohci_quirk_bad_wakeup(struct usb_hcd *hcd)
> +{
> + struct ohci_hcd *ohci = hcd_to_ohci (hcd);
> +
> + ohci_dbg(ohci, "marked as bad wakeup.\n");
I'd prefer the message to be something more like "enabled nVidia/SiS
wakeup quirk".
> + hcd->bad_wakeup = true;
> + return 0;
> +}
> +
> /* List of quirks for OHCI */
> static const struct pci_device_id ohci_pci_quirks[] = {
> {
> @@ -238,6 +247,31 @@
> PCI_DEVICE(PCI_VENDOR_ID_ATI, 0x4399),
> .driver_data = (unsigned long)ohci_quirk_amd700,
> },
> + {
> + /* MCP51 OHCI */
> + PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x026d),
> + .driver_data = (unsigned long)ohci_quirk_bad_wakeup,
> + },
> + {
> + /* MCP61 OHCI */
> + PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x03f1),
> + .driver_data = (unsigned long)ohci_quirk_bad_wakeup,
> + },
> + {
> + /* MCP79 OHCI */
> + PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x0aa5),
> + .driver_data = (unsigned long)ohci_quirk_bad_wakeup,
> + },
> + {
> + /* MCP79 OHCI */
> + PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x0aa7),
> + .driver_data = (unsigned long)ohci_quirk_bad_wakeup,
> + },
Since we don't know of any nVidia controllers that function correctly,
you might as well match any product ID.
> + {
> + /* SiS OHCI */
> + PCI_DEVICE(PCI_VENDOR_ID_SI, 7001),
> + .driver_data = (unsigned long)ohci_quirk_bad_wakeup,
> + },
>
> /* FIXME for some of the early AMD 760 southbridges, OHCI
> * won't work at all. blacklist them.
> Index: linux-pm/include/linux/usb/hcd.h
> ===
> --- linux-pm.orig/include/linux/usb/hcd.h 2012-11-01
> 18:21:34.732460451 +0800
> +++ linux-pm/include/linux/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 */
> unsignedpower_budget; /* in mA, 0 = no limit */
> + boolbad_wakeup;
This should be a bitflag (i.e., bad_wakeup:1) and it should come
immediately after has_tt:1.
Alan Stern
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Mon, 17 Dec 2012, Octavio Alvarez wrote:
> On Thu, 13 Dec 2012 00:45:05 -0800, Lan Tianyu
> wrote:
>
> > diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> > index f034716..9335f1b 100644
> > --- a/drivers/usb/core/hcd.c
> > +++ b/drivers/usb/core/hcd.c
> > @@ -2509,7 +2509,8 @@ int usb_add_hcd(struct usb_hcd *hcd,
> > * they only forward requests from the root hub. Therefore
> > * controllers should always be enabled for remote wakeup.
> > */
> > - device_wakeup_enable(hcd->self.controller);
> > + if (!usb_hcd_wakeup_quirks(hcd->self.controller))
> > + device_wakeup_enable(hcd->self.controller);
> > return retval;
> >
> > error_create_attr_group:
> > diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
> > index fdefd9c..ba847d3 100644
> > --- a/drivers/usb/core/quirks.c
> > +++ b/drivers/usb/core/quirks.c
> > @@ -12,6 +12,7 @@
> > */
> >
> > #include
> > +#include
> > #include
> > #include "usb.h"
> >
> > @@ -226,3 +227,33 @@ void usb_detect_interface_quirks(struct usb_device
> > *udev)
> > quirks);
> > udev->quirks |= quirks;
> > }
> > +
> > +struct pci_hcd {
> > + u32 vendor;
> > + u32 device;
> > +};
> > +
> > +static struct pci_hcd hcd_wakeup_qrk[] = {
> > + {PCI_VENDOR_ID_NVIDIA, 0x026d}, /* MCP51 OHCI */
> > + {PCI_VENDOR_ID_NVIDIA, 0x0aa5}, /* MCP79 OHCI */
> > + {PCI_VENDOR_ID_NVIDIA, 0x0aa7}, /* MCP79 OHCI */
> > + { }
> > +};
> > +
> > +int usb_hcd_wakeup_quirks(struct device *dev)
> > +{
> > + struct pci_dev *pdev;
> > + int i;
> > +
> > + if (dev->bus != (struct bus_type *)&pci_bus_type)
> > + return 0;
> > +
> > + pdev = to_pci_dev(dev);
> > + for (i = 0; hcd_wakeup_qrk[i].vendor || hcd_wakeup_qrk[i].device; i++)
> > + if ((hcd_wakeup_qrk[i].vendor == pdev->vendor) &&
> > + (hcd_wakeup_qrk[i].device == pdev->device)) {
> > + return 1;
> > + }
> > +
> > + return 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
Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Thu, 13 Dec 2012, Frank Schäfer wrote: > I have the MCP61 (rev. A2) with id 10de:03f1. > > Further NVIDIA OHCI HCD IDs can be found at > http://openbenchmarking.org/linux/PCI/0c03. > But I'm not sure that we should blacklist them all. Maybe this bug has > been fixed in 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
Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Thu, 13 Dec 2012, Frank Schäfer wrote: > > I write a quirk patch. Can you test? > > Yes, that makes it work ! > > > I just find one MCP51 and two MCP79 OHCI id. Can you provide more buggy > > hcd id via "lspci -nnvvv"? > > Thanks. > > I have the MCP61 (rev. A2) with id 10de:03f1. > > Further NVIDIA OHCI HCD IDs can be found at > http://openbenchmarking.org/linux/PCI/0c03. > But I'm not sure that we should blacklist them all. Maybe this bug has > been fixed in newer chipset revisions / generations ? > Where did you get the ID for the MCP79 from ? Is it confirmed that this > device still suffers from the same bug ? > > I also wonder if this could be an BIOS / ACPI issue. > So far, all boards I've seen were form ASUSTeK (Octavio: A8N-VM, me: > M2N-VM DH, and I remember having seen the same 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 debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Wed, 12 Dec 2012, Lan Tianyu wrote: > Hi Alan: > About your question of "Does the device send a remote wakeup request > even when it is disabled for remote wakeup?", I am not very clear. > Default, device remote wakeup is disabled and if we disable device's > remote wakeup via sysfs, the device's remote wakeup feature will not be > set during being suspended. So normally, it should not send out remote > wakeup signal but if it still sent out, this means it's a buggy device, > right? Right. > Moreover, this test is hard to do during s3 since system suspend, we > can't see any log. So this should be done in the runtime. I think it's > easy to do this test on mouse or keyboard device. Yes, that should work. But Frank says that the same mouse and keyboard do not cause other machines to wake up, so the 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
Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Tue, 11 Dec 2012, Lan Tianyu wrote: > Hi Alan&Greg: > Since 3.1, Alan enabled usb device wakeup default, there are > a lot of problem that immediately resume when enter into s2ram/s2disk. > I have traced some these bugs. Most of these bugs are related usb1.1 > device which attached to OHCI/UHCI. If disable the hc wakeup or no device > attached, it will work again. Not all usb1.1 devices will cause this issue. What if the device is disabled for wakeup? That's the right solution if the device is buggy. > From enabe/disable hc wakeup side, I check what is done in the ACPI. > When system is entering into s3/s4, ACPI will check all the device which has > wakeup resource(there is a gpe interrupt for these devices). If their > wakeup was > enabled, ACPI will enable their gpe interrupt . If there was a signal of gpe > during s3, the system would be resumed. That's the right thing to do. > Normally, usb hc will have gpe to wakeup system. This issue caused by > hc with some usb1.1 devices triggering wakeup signal just after > entering into s3/s4. Does the HC turn on the GPE even when the device does not send a remote wakeup request? Does the device send a remote wakeup request even when it is disabled for remote wakeup? > System resumes immediately. Since the signal is triggered after system > entering > into s3/s4, it's hard to debug what hc does during this procedure(This > comes from > my analyse, I have no such machine to debug). > So can we add a blacklist which contains devices causing such > issue and disable > these devices' remote wakeup when system suspend to avoid such > problems? Well, we can create blacklist entries 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 component is bad: the host controller or the device. Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Mon, 9 Jul 2012, Octavio Alvarez wrote: > > What happens if you unplug only the keyboard, or only the mouse? > > The only thing I can confirm for now is that with both disconnected > the system consistently suspends and that I have seen the system NOT > suspend with either 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? Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689368: Mouse and keyboard freeze on Ivy Bridge platform
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 mouse or > > keyboard, because the log shows errors for both of them starting at > > exactly the same times. > > In my humble opinion, this issue is not caused by a bad USB hardware > because I am encountering it with two different motherboards (MSI > Z77A-G43 and ASUS P8Z77-V LX), both with an uptodate BIOS. Maybe they have something in common. I don't know. All I can do is explain to you what your kernel log indicates -- and it strongly indicates a hardware error. Didn't you notice all those "detected XactErr" lines in the log? There were more than 7 of them! > May be it is caused by a bad cabling but my mouse and my keyboard worked > fine with my previous PC. They are connected to USB2 ports in both > cases. But to clear up this point, I will try new mouse and keyboard. > > A last question: if it is a cable failure, why does it disappear > temporarily when I unload then reload the module? I do not have deep > experience and knowledge of hardware, may be there is a rational > explanation to it. That's a good point, and a cable failure indeed seems less likely than some of the other possibilities (such as a failure of the internal "rate-matching" hub). One possible explanation is that an occasional noisy signal (caused by a slightly faulty cable) triggers a bug in the internal hub, and that bug causes all communication to fail until the hub is reset when you reload the module. > > You could try getting a USB-2 hub and attaching your mouse and > > keyboard through the hub. That might help ... or it might not. > > Sorry, I do not understand the aim of this operation. Could you explain > me it? In addition to what Sarah said, it's possible that your problem is related to the fact that the keyboard and mouse operate at low speed. If you connected them through a hub then that hub would communicate with the internal hub at high speed, not low speed. Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689368: Mouse and keyboard freeze on Ivy Bridge platform
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 "echo w >/proc/sysrq-trigger" from a network login > > should). Then send the dmesg output > > The mouse and the keyboard froze four times tonight in half an hour : > > - at 20:42:05 > - at 20:53:44 > - at 20:58:21 > - at 21:15:19 > > But the SysRq command (executed through a remote SSH connection) > displayed nothing. :( No tasks were hung. That's okay. > In attachment, you will find the kern.log file. 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 mouse or keyboard, because the log shows errors for both of them starting at exactly the same times. You could try getting a USB-2 hub and attaching your mouse and keyboard through the hub. That might help ... or it might not. Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689368: Mouse and keyboard freeze on Ivy Bridge platform
On Wed, 3 Oct 2012 sebastien.di...@free.fr wrote: > Hi, > > I am encountering random keyboard and mouse freezes which can only be > resolved by a hard reset (by pushing the power switch of the computer > case). > The mouse and keyboard are both USB devices and it seems that the bug > is coming from the echci-hcd module: > Can I run additional tests or give you additional informations to > help you resolve this painful bug? Please build a kernel with CONFIG_USB_DEBUG enabled. When a hang occurs, get a list of hang tasks (Alt-SysRq-w probably won't work, 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
Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
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 > >> > drive? If it is USB-2.0 then I would expect it to connect to the EHCI > >> > controller, not the OHCI controller. > >> > >> I don't know... Is there a way to know that? The device is a > >> > >> Bus 001 Device 011: ID 0781:5406 SanDisk Corp. Cruzer Micro U3 > > > > That doesn't mean much by itself. But the lsusb output you included > > confirms that the pen drive was running at high speed -- which means > > that it should never have been connected to the OHCI controller at all. > > Another mystery. It appears that your computer's USB hardware is kind > > of funky. > > Alan, take a look at this: > > Bus# 2 > `-Dev# 1 Vendor 0x1d6b Product 0x0001 Linux Foundation 1.1 root hub >|-Dev# 18 Vendor 0x046d Product 0xc05a Logitech, Inc. Optical Mouse M90 >`-Dev# 19 Vendor 0x046d Product 0xc31d Logitech, Inc. > Bus# 1 > `-Dev# 1 Vendor 0x1d6b Product 0x0002 Linux Foundation 2.0 root hub >`-Dev# 18 Vendor 0x0781 Product 0x5406 SanDisk Corp. Cruzer Micro U3 > > For some reason, my USB drive is now on EHCI! As it should be. Was there ever a time when it was definitely using the OHCI controller? (The CCS status you got before wasn't definite enough to count -- it showed a connected status but not an enabled status.) That should never happen, except when ehci-hcd is unloaded. > > What happens if you unplug only the keyboard, or only the mouse? > > The only thing I can confirm for now is that with both disconnected > the system consistently suspends and that I have seen the system NOT > suspend with either 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). Well, we can assume that the suspend doesn't work when either device is plugged in. Which suggests another test. Try unloading ehci-hcd, and plug in the pen drive. At that point it should use the OHCI controller. Then if you unplug the keyboard and mouse, what happens when you suspend? My guess is that it will resume immediately. Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
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 LSDA PPS PES CCS > >> >> roothub.portstatus [6] 0x0101 PPS CCS > >> > > >> > That's normal, except for the status of port 6 (which actually is port > >> > 7, since we normally count ports starting from 1). The port shows > >> > Current Connect Status, so something is connected to it -- but what? > >> > >> It looks like it was my pendrive. Disconnecting the mouse and keyboard > >> cleared CCS on [4] and [5] (not necesariliy in that order). > >> > >> Removing my pen drive cleared CCS on [6]. > > > > Okay, that explains that. More or less. Is this an old USB-1.1 pen > > drive? If it is USB-2.0 then I would expect it to connect to the EHCI > > controller, not the OHCI controller. > > I don't know... Is there a way to know that? The device is a > > Bus 001 Device 011: ID 0781:5406 SanDisk Corp. Cruzer Micro U3 That doesn't mean much by itself. But the lsusb output you included confirms that the pen drive was running at high speed -- which means that it should never have been connected to the OHCI controller at all. Another mystery. It appears that your computer's USB hardware is kind of funky. > Does it make sense to think that some ports are OHCI and some are > EHCI, particularly if some of them are on the back and some on the > front? No, not really. All the ports should be connected to both controllers. You can check the dmesg log to make sure that they have the same number of ports. > > The suspending part is normal. The resuming part is not... > > > >> [ 181.394398] usb usb2: usb resume > >> [ 181.394403] ohci_hcd :00:0b.0: wakeup root hub > >> [ 181.394426] usb usb1: usb resume > >> [ 181.394430] ehci_hcd :00:0b.1: resume root hub > >> [ 181.428035] ehci_hcd :00:0b.1: port 6 low speed --> companion > > > > That shouldn't have happened. It's not actually _wrong_, but it > > indicates that the USB controllers did not maintain their states > > properly while the system was suspended. > > Considering that this happens while the system is already resuming, > do you think is in some way related with the bug? Yes, I do. It happened during resume because of something that went wrong during suspend. That same something could easily be responsible for the immediate wakeup. > > Just out of curiosity, what happens if you suspend with the mouse and > > keyboard unplugged, i.e., no USB devices attached at all? (To > > forestall possible questions, you run a little shell script that sleeps > > for 10 seconds, during which you unplug the keyboard and mouse, and > > then initiates a system suspend.) > > I'm using the power button to suspend and resume, so this test is > actually easy. > > It's weird, but without K & M connected, even with the pendrive > connected, the system suspends! (The keyboard leds go off and all, > though) It's normal for the LEDs to turn off -- they use more current than is available when the keyboard is suspended. What happens if you unplug only the keyboard, or only the mouse? Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
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 PPS CCS > > > > That's normal, except for the status of port 6 (which actually is port > > 7, since we normally count ports starting from 1). The port shows > > Current Connect Status, so something is connected to it -- but what? > > It looks like it was my pendrive. Disconnecting the mouse and keyboard > cleared CCS on [4] and [5] (not necesariliy in that order). > > Removing my pen drive cleared CCS on [6]. Okay, that explains that. More or less. Is this an old USB-1.1 pen drive? If it is USB-2.0 then I would expect it to connect to the EHCI controller, not the OHCI controller. > FYI, bisecting and other testing was done pretty much without my > pendrive all the time. Good. The fewer possible sources of confusion, the better. > I just tested suspend, just for the sake of it, and it still > wakes up right after sleep. > > > Can you post a complete dmesg log showing bootup with CONFIG_USB_DEBUG > > enabled? > > Sure. This is it, up to second 178 (last msg is in 81), before pushing the > suspend button. ... Pretty much normal. > This is the continuation of the previous dmesg, starting on second 178, > when I pressed the power button. > > (done without my pen drive) The suspending part is normal. The resuming part is not... > [ 181.394398] usb usb2: usb resume > [ 181.394403] ohci_hcd :00:0b.0: wakeup root hub > [ 181.394426] usb usb1: usb resume > [ 181.394430] ehci_hcd :00:0b.1: resume root hub > [ 181.428035] ehci_hcd :00:0b.1: port 6 low speed --> companion That shouldn't have happened. It's not actually _wrong_, but it indicates that the USB controllers did not maintain their states properly while the system was suspended. > [ 181.472053] hub 2-0:1.0: hub_resume > [ 181.472076] ohci_hcd :00:0b.0: GetStatus roothub.portstatus [4] = > 0x00030301 PESC CSC LSDA PPS CCS > [ 181.472082] hub 2-0:1.0: port 5: status 0301 change 0003 > [ 181.472100] ohci_hcd :00:0b.0: GetStatus roothub.portstatus [5] = > 0x00030301 PESC CSC LSDA PPS CCS These messages are indications of the same problem. > [ 181.472105] hub 2-0:1.0: port 6: status 0301 change 0003 > [ 181.524028] ehci_hcd :00:0b.1: GetStatus port:6 status 003402 0 > ACK POWER OWNER sig=k CSC > [ 181.540030] hub 1-0:1.0: hub_resume > [ 181.540040] ehci_hcd :00:0b.1: GetStatus port:1 status 001020 0 > ACK POWER sig=se0 OCC > [ 181.540051] ehci_hcd :00:0b.1: GetStatus port:2 status 001020 0 > ACK POWER sig=se0 OCC > [ 181.540061] ehci_hcd :00:0b.1: GetStatus port:3 status 001020 0 > ACK POWER sig=se0 OCC > [ 181.540071] ehci_hcd :00:0b.1: GetStatus port:4 status 001020 0 > ACK POWER sig=se0 OCC > [ 181.540086] ehci_hcd :00:0b.1: GetStatus port:7 status 001020 0 > ACK POWER sig=se0 OCC > [ 181.540095] ehci_hcd :00:0b.1: GetStatus port:8 status 001020 0 > ACK POWER sig=se0 OCC These messages are highly suspicious. They indicate a low-level hardware problem in the wiring of the USB controllers or support components. I won't go into further detail. The remaining events all seem to flow from these underlying problems. Just out of curiosity, what happens if you suspend with the mouse and keyboard unplugged, i.e., no USB devices attached at all? (To forestall possible questions, you run a little shell script that sleeps for 10 seconds, during which you unplug the keyboard and mouse, and then initiates a system suspend.) Also, what happens if you unload ehci-hcd before suspending (with the keyboard and mouse plugged in as normal)? Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Sat, 7 Jul 2012, Octavio Alvarez wrote: > > If you build a kernel with CONFIG_USB_DEBUG enabled, what > > shows up in /sys/kernel/debug/usb/ohci/*/registers? > > [Sat Jul 07 12:49:27 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb] > $ grep . ohci/*/registers > bus pci, device :00:0b.0 > OHCI Host Controller > ohci_hcd > OHCI 1.0, NO legacy support registers, rh state running > control 0x68f RWE RWC HCFS=operational IE PLE CBSR=3 > cmdstatus 0x0 SOC=0 > intrstatus 0x0024 FNO SF > intrenable 0x804a MIE RHSC RD WDH > ed_controlhead 2edac040 > hcca frame 0x5fce > fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf > fmremaining 0x80002e53 FRT FR=0x2e53 > periodicstart 0x2a2f > lsthresh 0x0628 > hub poll timer off > roothub.a 01000208 POTPGT=1 NPS NDP=8(8) > roothub.b PPCM= DR= > roothub.status 8000 DRWE > roothub.portstatus [0] 0x0100 PPS > roothub.portstatus [1] 0x0100 PPS > roothub.portstatus [2] 0x0100 PPS > roothub.portstatus [3] 0x0100 PPS > roothub.portstatus [4] 0x0303 LSDA PPS PES CCS > roothub.portstatus [5] 0x0303 LSDA PPS PES CCS > roothub.portstatus [6] 0x0101 PPS CCS > roothub.portstatus [7] 0x0100 PPS That's normal, except for the status of port 6 (which actually is port 7, since we normally count ports starting from 1). The port shows Current Connect Status, so something is connected to it -- but what? Can you post a complete dmesg log showing bootup with CONFIG_USB_DEBUG enabled? > > And what shows up in /sys/kernel/debug/usb/devices? > > [Sat Jul 07 12:49:54 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb] > $ cat devices ... Pretty much normal. > > Also, what does the "lspci -vv" output show for the controller if you > > run it with superuser permissions? > > [Sat Jul 07 12:50:10 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb] > $ sudo lspci -vv -s :00:0b.1 0b.1 is the EHCI controller. We want to see the OHCI controller, 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, that commit enables wakeup for USB host controllers by default. Before that, you had to enable wakeup by hand. The question is: Why does the controller think it needs to wake up the system? Can you also post a dmesg log showing a full suspend/immediate-resume cycle with CONFIG_USB_DEBUG enabled? > > And yet the PC doesn't lock up if you unbind ohci-hcd before > > suspending? > > It suspends but it locks-up while waking up. > > > Maybe you can do a git bisection to find what changed between 3.2 and > > 3.4 to cause this behavior. > > commit 2feec47d4c5f80b05f1650f5a24865718978eea4 > Author: Bob Moore > Date: Tue Feb 14 15:00:53 2012 +0800 > > ACPICA: ACPI 5: Support for new FADT SleepStatus, SleepControl > registers > > Adds sleep and wake support for systems with these registers. > One new file, hwxfsleep.c > > Signed-off-by: Bob Moore > Signed-off-by: Len Brown Yes, okay, that is indeed totally separate. You should bring that issue up with Bob Moore and Len Brown on the linux-acpi mailing list. Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
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/power/wakeup > > On kernel 3.2, it lets suspend work again. It might be worthwhile tracking down the reason for the immediate wakeup. If you build a kernel with CONFIG_USB_DEBUG enabled, what shows up in /sys/kernel/debug/usb/ohci/*/registers? And what shows up in /sys/kernel/debug/usb/devices? Also, what does the "lspci -vv" output show for the controller if you run it with superuser permissions? > For kernel 3.4, I'll break it into two parts: the going asleep and the > wakening back. > > For the going asleep part, it works just like 3.2. It previously went > "almost" asleep, but with "echo disabled > wakeup" it suspends correctly. > > For the wakening back part, with both settings the PC locks up requiring a > mechanical (power supply switch) power cycle to bring the computer back. > Not even the 5-sec power button cycle helps. I guess this is a different > bug, so I'll try to troubleshoot it and open a different one. And yet the PC doesn't lock up if you unbind ohci-hcd before suspending? Maybe you can do a git bisection to find what changed between 3.2 and 3.4 to cause this behavior. Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Sun, 24 Jun 2012, Ben Hutchings wrote: > [The full log for this bug is at http://bugs.debian.org/677472] > > On Thu, 2012-06-14 at 09:28 -0700, Octavio Alvarez wrote: > > Under normal circumstances the system simply does not suspend. It appears > > to go all the way to suspension (screen off, disks off, etc.) but when it > > appears that it is going to go off, something prevents it. System doesn't > > hang, it just fails at the very last moment of suspension. > > > > I tried debugging using pm_test. I set it to "core" but suspend_stats > > doesn't catch anything: > > > > # cat /sys/kernel/debug/suspend_stats > > success: 12 > > fail: 0 > > failed_freeze: 0 > > failed_prepare: 0 > > failed_suspend: 0 > > failed_suspend_noirq: 0 > > failed_resume: 0 > > failed_resume_noirq: 0 > > failures: > >last_failed_dev: > > > >last_failed_errno: 0 > > 0 > >last_failed_step: > > > > Even with pm_test set to "none", suspend_stats increases the "success" > > value. > > This indicates that the system is woken up immediately after it > suspends. From the kernel point of view (but not a practical point of > view!) this is different from failing to suspend. > > > As I said earlier, removing ohci_hcd lets suspend work again. > > So the USB controller (OHCI) has for some reason started waking up the > system. As I suspected, this system has an Nvidia chipset: > > 00:0b.0 USB controller [0c03]: NVIDIA Corporation MCP51 USB Controller > [10de:026d] (rev a2) (prog-if 10 [OHCI]) > Subsystem: ASUSTeK Computer Inc. A8N-VM CSM Mainboard [1043:81bc] > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-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 has > prompted a number of changes to power management. The last one was: > > commit c61875977458637226ab093a35d200f2d5789787 > Author: Alan Stern > Date: Thu Nov 17 16:41:45 2011 -0500 > > OHCI: final fix for NVIDIA problems (I hope) Actually that wasn't exactly a power management change, although it was vaguely related. It really was more concerned with initialization and shutdown. > But it looks like we have to disappoint Alan again. Well, this sounds like a different problem. What happens if Octavio disables wakeup for that controller before suspending? echo disabled >/sys/bus/pci/devices/:00:0b.0/power/wakeup Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#622649: linux-image-2.6.38-2-amd64: unable to enumerate USB device on port 6
On Fri, 15 Apr 2011, Hans-J. Ullrich wrote: > Hi Alan, > > I was happy too early, sorry for that. It seems, the compiled module can not > be loaded somehow. Maybe it is my fault and I made a mistake at editing or > compiling. > > As I told, I am not experienced with patches 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 UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#622649: linux-image-2.6.38-2-amd64: unable to enumerate USB device on port 6
On Fri, 15 Apr 2011, Ben Hutchings wrote:
> On Wed, 2011-04-13 at 18:32 +0200, Hans-J. Ullrich wrote:
> [...]
> > I get massive messages from the kernel "unable to enumerate USB device
> > on port 6" which is making the pc slower and
> > which is filling up my syslog. The problem is caused by the ohci-hcd
> > kernel module. Unloading it, is stopping
> > the messages, but then the mouse will not work (of course).
> >
> > This bug appeared the first time at the change from
> > linux-image-2.6.32-5-amd64-30 --> linux-image-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 Sep 10 16:37:05 2010 -0400
>
> OHCI: work around for nVidia shutdown problem
>
> commit 3df7169e73fc1d71a39cffeacc969f6840cdf52b upstream.
>
> The reporter's system does indeed have an nVidia MCP67 chipset. Full
> details (kernel log, lspci, etc.) are at <http://bugs.debian.org/620848>
> and <http://bugs.debian.org/622649>.
Hans, can you test whether the patch below fixes your problem?
Alan Stern
Index: usb-2.6/drivers/usb/host/ohci-pci.c
===
--- usb-2.6.orig/drivers/usb/host/ohci-pci.c
+++ usb-2.6/drivers/usb/host/ohci-pci.c
@@ -207,10 +207,18 @@ static int ohci_quirk_amd700(struct usb_
*/
static int ohci_quirk_nvidia_shutdown(struct usb_hcd *hcd)
{
+ struct pci_dev *pdev = to_pci_dev(hcd->self.controller);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
- ohci->flags |= OHCI_QUIRK_SHUTDOWN;
- ohci_dbg(ohci, "enabled nVidia shutdown quirk\n");
+ /* Evidently nVidia fixed their later hardware; this is a guess at
+* the changeover point.
+*/
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_USB 0x026d
+
+ if (pdev->device < PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_USB) {
+ ohci->flags |= OHCI_QUIRK_SHUTDOWN;
+ ohci_dbg(ohci, "enabled nVidia shutdown quirk\n");
+ }
return 0;
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555835: {PATCH] usb-storage: unusual_devs entry for the Samsung YP-CP3
From: Vitaly Kuznetsov Add an unusual_devs entry for the Samsung YP-CP3 MP4 player. User was getting the following errors in dmesg: usb 2-6: reset high speed USB device using ehci_hcd and address 2 usb 2-6: reset high speed USB device using ehci_hcd and address 2 usb 2-6: reset high speed USB device using ehci_hcd and address 2 usb 2-6: USB disconnect, address 2 sd 3:0:0:0: [sdb] Assuming drive cache: write through sdb:<2>ldm_validate_partition_table(): Disk read failed. Dev sdb: unable to read RDB block 0 unable to read partition table Signed-off-by: Vitaly Kuznetsov Acked-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/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h index d4f034e..05b0d2c 100644 --- a/drivers/usb/storage/unusual_devs.h +++ b/drivers/usb/storage/unusual_devs.h @@ -481,6 +481,13 @@ UNUSUAL_DEV( 0x04e8, 0x507c, 0x0220, 0x0220, USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_MAX_SECTORS_64), +/* Reported by Vitaly Kuznetsov */ +UNUSUAL_DEV( 0x04e8, 0x5122, 0x, 0x, + "Samsung", + "YP-CP3", + USB_SC_DEVICE, USB_PR_DEVICE, NULL, + US_FL_MAX_SECTORS_64 | US_FL_BULK_IGNORE_TAG), + /* Entry and supporting patch by Theodore Kilgore . * Device uses standards-violating 32-byte Bulk Command Block Wrappers and * reports itself as "Proprietary SCSI Bulk." Cf. device entry 0x084d:0x0011. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555835: [usb-storage] linux-image-2.6.30-2-686: Unusual usb storage Samsung YP-CP3 not working
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_FL_MAX_SECTORS_64. > > > > usbmon attached, dmesg looks like: > > [90833.235667] usb-storage: device found at 10 > [90833.235672] usb-storage: waiting for device to settle before scanning > [90838.232280] usb-storage: device scan complete > [90838.232741] scsi 10:0:0:0: Direct-Access SAMSUNG YP-CP3 > 1.00 PQ: 0 ANSI: 0 > [90838.233107] scsi 10:0:0:1: Direct-Access SAMSUNG microSD Card > 1.00 PQ: 0 ANSI: 0 CCS > [90838.251803] sd 10:0:0:0: [sdb] 7649280 512-byte hardware sectors: (3.91 > GB/3.64 GiB) > [90838.252389] sd 10:0:0:0: [sdb] Write Protect is off > [90838.252394] sd 10:0:0:0: [sdb] Mode Sense: 03 00 00 00 > [90838.252397] sd 10:0:0:0: [sdb] Assuming drive cache: write through > [90838.254505] sd 10:0:0:0: [sdb] Assuming drive cache: write through > [90838.254513] sdb: > [90838.255649] sd 10:0:0:0: [sdb] Attached SCSI removable disk > [90838.256630] sd 10:0:0:1: [sdc] Attached SCSI removable disk > [90838.389146] sd 10:0:0:0: [sdb] Unhandled error code > [90838.389150] sd 10:0:0:0: [sdb] Result: hostbyte=DID_ERROR > driverbyte=DRIVER_OK > [90838.389155] end_request: I/O error, dev sdb, sector 8 > [90838.389159] __ratelimit: 110 callbacks suppressed > [90838.389162] Buffer I/O error on device sdb, logical block 1 > [90838.389168] Buffer I/O error on device sdb, logical block 2 > [90838.389171] Buffer I/O error on device sdb, logical block 3 > [90838.389174] Buffer I/O error on device sdb, logical block 4 > [90838.389177] Buffer I/O error on device sdb, logical block 5 > [90838.389180] Buffer I/O error on device sdb, logical block 6 > [90838.389183] Buffer I/O error on device sdb, logical block 7 > [90838.389186] Buffer I/O error on device sdb, logical block 8 > [90838.389189] Buffer I/O error on device sdb, logical block 9 > [90838.389192] Buffer I/O error on device sdb, logical block 10 > [90838.502971] sd 10:0:0:0: [sdb] Unhandled error code > [90838.502975] sd 10:0:0:0: [sdb] Result: hostbyte=DID_ERROR > driverbyte=DRIVER_OK > [90838.502980] end_request: I/O error, dev sdb, sector 0 > [90838.674599] sd 10:0:0:0: [sdb] Unhandled error code > [90838.674602] sd 10:0:0:0: [sdb] Result: hostbyte=DID_ERROR > driverbyte=DRIVER_OK > [90838.674607] end_request: I/O error, dev sdb, sector 0 > [90840.751890] sd 10:0:0:0: [sdb] Unhandled error code > [90840.751898] sd 10:0:0:0: [sdb] Result: hostbyte=DID_ERROR > driverbyte=DRIVER_OK > [90840.751907] end_request: I/O error, dev sdb, sector 0 Okay, thanks. It looks like the IGNORE_RESIDUE flag might also work. But if MAX_SECTORS_64 is good enough, it's probably a better choice. Have you tested this device with a microSD card inserted? Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555835: [usb-storage] linux-image-2.6.30-2-686: Unusual usb storage Samsung YP-CP3 not working
On Fri, 20 Nov 2009, Vitaly Kuznetsov wrote: > Alan Stern writes: > > >> > +/* Reported by Vitaly Kuznetsov */ > >> > +UNUSUAL_DEV( 0x04e8, 0x5122, 0x, 0x, > >> > + "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 sure all those flags are > > really needed? Have you collected a usbmon trace to find out what's > > actually going wrong? > > > > Alan Stern > > Hello Alan, > > as I answered Matthew Dharm yesterday this was not minimal set needed to > get device working properly. > 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_FL_MAX_SECTORS_64. Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555835: [usb-storage] linux-image-2.6.30-2-686: Unusual usb storage Samsung YP-CP3 not working
On Wed, 18 Nov 2009, Moritz Muehlenhoff wrote: > [CCing upstream for review/merge of the patch proposed by Vitaly.] > > This was reported to Debian as > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555835 > > Vitaly, please add a Signed-off-by: header as described in > Documentation/SubmittingPatches > > Cheers, > Moritz > > I wrote a small patch to fix this problem: > > --- drivers/usb/storage/unusual_devs.h.old 2009-09-26 > > 01:58:45.0 +0400 > > +++ drivers/usb/storage/unusual_devs.h 2009-11-12 02:01:20.0 +0300 > > @@ -495,6 +495,13 @@ > > US_SC_DEVICE, US_PR_DEVICE, NULL, > > US_FL_MAX_SECTORS_64), > > > > +/* Reported by Vitaly Kuznetsov */ > > +UNUSUAL_DEV( 0x04e8, 0x5122, 0x, 0x, > > + "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 sure all those flags are really needed? Have you collected a usbmon trace to find out what's actually going wrong? Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#440763: [linux-usb-devel] lsusb omits some devices and (apparently) cannot be fixed
On Thu, 13 Sep 2007, Karl O. Pinc wrote: > On 09/13/2007 05:17:17 PM, Aurelien Jarno wrote: > > Karl O. Pinc a écrit : > > > > lsusb silently ignores at least some permission errors, resulting in > > > no output for the device to which there are no permissions. > > > > > As already explained, lsusb does not parse /dev, but uses libusb for > > that. If a device is not in the list given by libusb, lsusb has no way > > to guess that a device is missing. > > That's why I'm writing to (I hope) the authors of Linux'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 libusb and lsusb. Alan Stern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
On Thu, 22 Dec 2005, Willi Mann wrote: > >>- Now see what's happening when I unplug the mouse "fast": > >> > >>Dec 21 14:40:44 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq > >>status -84 received > >>Dec 21 14:40:44 wmiwilli last message repeated 2 times > >>... > > > >>- When I unplug it "slowly": > >> > >>Dec 21 14:41:27 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq > >>status -84 received > >>Dec 21 14:41:28 wmiwilli last message repeated 7 times > >>.. > > > I don't see any significant difference. Did I miss something? > > I was just thinking what will happen if someone unplugs the mouse (or > another HID device) not completely. Will that fill up the kernel logs? It shouldn't. Either 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]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
On Wed, 21 Dec 2005, Willi Mann wrote: > > 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. > > confirmed. What's needed to get that into the offical kernel releases? I've tried; it wasn't accepted. The patch below should be more acceptable to the maintainer. Try it instead of the other one; it ought to get rid of all those error messages showing up in the log as well as fixing the mouse problem. That is, it won't prevent the actual errors from occurring at a rate of ~1 per minute -- it will just stop the driver from logging the messages. If it works well, I'll submit it. > - Now see what's happening when I unplug the mouse "fast": > > Dec 21 14:40:44 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq > status -84 received > Dec 21 14:40:44 wmiwilli last message repeated 2 times > Dec 21 14:40:44 wmiwilli kernel: hub 2-0:1.0: state 5 ports 2 chg > evt 0002 > Dec 21 14:40:44 wmiwilli kernel: uhci_hcd :00:1d.1: port 1 portsc > 008a,00 > Dec 21 14:40:44 wmiwilli kernel: hub 2-0:1.0: port 1, status 0100, > change 0003, 12 Mb/s > Dec 21 14:40:44 wmiwilli kernel: usb 2-1: USB disconnect, address 2 > Dec 21 14:40:44 wmiwilli kernel: usb 2-1: usb_disable_device nuking all URBs > Dec 21 14:40:44 wmiwilli kernel: uhci_hcd :00:1d.1: shutdown urb > dd36b740 pipe 40408280 ep1in-intr > Dec 21 14:40:44 wmiwilli kernel: usb 2-1: unregistering interface 2-1:1.0 > Dec 21 14:40:44 wmiwilli kernel: usb 2-1:1.0: hotplug > Dec 21 14:40:44 wmiwilli kernel: usb 2-1: unregistering device > Dec 21 14:40:44 wmiwilli kernel: usb 2-1: hotplug > Dec 21 14:40:44 wmiwilli kernel: hub 2-0:1.0: debounce: port 1: total > 100ms stable 100ms status 0x100 > - When I unplug it "slowly": > > Dec 21 14:41:27 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq > status -84 received > Dec 21 14:41:28 wmiwilli last message repeated 7 times > Dec 21 14:41:28 wmiwilli kernel: hub 2-0:1.0: state 5 ports 2 chg > evt 0002 > Dec 21 14:41:28 wmiwilli kernel: uhci_hcd :00:1d.1: port 1 portsc > 008a,00 > Dec 21 14:41:28 wmiwilli kernel: hub 2-0:1.0: port 1, status 0100, > change 0003, 12 Mb/s > Dec 21 14:41:28 wmiwilli kernel: usb 2-1: USB disconnect, address 4 > Dec 21 14:41:28 wmiwilli kernel: usb 2-1: usb_disable_device nuking all URBs > Dec 21 14:41:28 wmiwilli kernel: uhci_hcd :00:1d.1: shutdown urb > cb373140 pipe 40408480 ep1in-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 wmiwilli kernel: hub 2-0:1.0: debounce: port 1: total > 100ms stable 100ms status 0x100 I don't see any significant difference. Did I miss something? Alan Stern Index: linux-2.6.15-rc6/drivers/usb/input/hid-core.c === --- linux-2.6.15-rc6.orig/drivers/usb/input/hid-core.c +++ linux-2.6.15-rc6/drivers/usb/input/hid-core.c @@ -927,8 +927,8 @@ static void hid_irq_in(struct urb *urb, case -ENOENT: case -EPERM: case -ESHUTDOWN:/* unplug */ - case -EILSEQ: /* unplug timeout on uhci */ return; + case -EILSEQ: /* protocol error or unplug */ case -ETIMEDOUT:/* NAK */ break; default:/* error */ @@ -1101,8 +1101,8 @@ static void hid_irq_out(struct urb *urb, case 0: /* success */ break; case -ESHUTDOWN:/* unplug */ - case -EILSEQ: /* unplug timeout on uhci */ unplug = 1; + case -EPROTO: /* protocol error or unplug */ case -ECONNRESET: /* unlink */ case -ENOENT: break; @@ -1149,8 +1149,9 @@ static void hid_ctrl(struct urb *urb, st hid_input_report(hid->ctrl[hid->ctrltail].report->type, urb, 0, regs); break; case -ESHUTDOWN:/* unplug */ - case -EILSEQ: /* unplug timectrl on uhci */ unplug = 1; + case -EILSEQ: /* protocol error or unplug */ + case -EPROTO: /* protocol error or unplug */ case -ECONNRESET: /* unlink */ case -ENOENT: case -EPIPE:/* report not available */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
On Sat, 17 Dec 2005, Willi Mann wrote: > There seems to be relation between mouse usage and the -84 signal: The > more I use the mouse the less it occurs. That particular error generally means that something is interfering with the USB data transmission. It could be a poor cable connection, 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 Stern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
On Sat, 17 Dec 2005, Willi Mann wrote: > > Yes indeed. This looks very similar to the problem reported in > > > > http://bugzilla.kernel.org/show_bug.cgi?id=4916 > > > > See especially comment #19. > > > > It's possible that the patch adding an HID reset routine (the last > > attachment in the bug report) will work for you. You might have to fiddle > > with it a little, because it is now four months old. > > Yes, it works. No more freezing mouse despite the cold weather outside :-) > > > 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. > > Do you mean, it should have shown up without this patch? Since you told > me to enable CONFIG_USB_DEBUG, I had it always on while testing, but I > never 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]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
On Sat, 17 Dec 2005, Willi Mann wrote: > Ok, here is what I did: > cat 2t > -> minimize the gnome-terminal > -> surfed the web > -> suddenly mouse died > -> Strg + Alt + F1, Alt+ F7 > -> reopened the terminal > -> marked the last > 200 lines > -> pasted in file > -> grepped for the mouse identifier 002:01 > here are the last lines of that output: > ddd8de40 618383777 S Ii:002:01 -115 4 = 00ff > ddd8de40 618431747 C Ii:002:01 0 4 = 00ff > ddd8de40 618431774 S Ii:002:01 -115 4 = 00ff > ddd8de40 723190277 C Ii:002:01 -84 0 > ddd8de40 769897561 S Ii:002:01 -115 4 = 00ff > ddd8de40 769910480 C Ii:002:01 0 4 = 00838200 > ddd8de40 769910495 S Ii:002:01 -115 4 = 00838200 > > Does that somehow help to track it down? The event in µs 723190277 seems > very suspicious to me. Yes indeed. This looks very similar to the problem reported in http://bugzilla.kernel.org/show_bug.cgi?id=4916 See especially comment #19. It's possible that the patch adding an HID reset routine (the last attachment in the bug report) will work for you. You might have to fiddle with it a little, 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]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
On Sun, 4 Dec 2005, Willi Mann wrote: > > > To get more information, turn on USB verbose debugging (CONFIG_USB_DEBUG) > > in the kernel configuration and rebuild the USB drivers. Post the kernel > > or dmesg log showing what happens when the connection is lost. > > I've used the debian source for that. They currently don't patch > anything usb-related. I've set CONFIG_USB_DEBUG=y and changed the > processor family to Pentium M. These are the only differences to the > distributed debian kernels. > > Unfortunatly, when the connection is lost, there is no message in dmesg. > And there's also no message when the connection is reactivated. (By chvt > 1 && sleep 1 && chvt 7) Then the problem must be unrelated to the USB stack. > when I unplug and replug the mouse, the following happens: > > hub 2-0:1.0: state 5 ports 2 chg evt 0004 > uhci_hcd :00:1d.1: port 2 portsc 008a,00 > hub 2-0:1.0: port 2, status 0100, change 0003, 12 Mb/s > usb 2-2: USB disconnect, address 3 > usb 2-2: usb_disable_device nuking all URBs > usb 2-2: unregistering interface 2-2:1.0 > usb 2-2:1.0: hotplug > usb 2-2: unregistering device > usb 2-2: hotplug > hub 2-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100 > hub 4-0:1.0: state 5 ports 6 chg evt 0010 > ehci_hcd :00:1d.7: GetStatus port 4 status 001403 POWER sig=k CSC > CONNECT > hub 4-0:1.0: port 4, status 0501, change 0001, 480 Mb/s > hub 4-0:1.0: debounce: port 4: total 100ms stable 100ms status 0x501 > ehci_hcd :00:1d.7: port 4 low speed --> companion > ehci_hcd :00:1d.7: GetStatus port 4 status 003002 POWER OWNER > sig=se0 CSC > hub 2-0:1.0: state 5 ports 2 chg evt 0004 > uhci_hcd :00:1d.1: port 2 portsc 01a3,00 > hub 2-0:1.0: port 2, status 0301, change 0001, 1.5 Mb/s > hub 2-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x301 > usb 2-2: new low speed USB device using uhci_hcd and address 4 > usb 2-2: skipped 1 descriptor after interface > usb 2-2: default language 0x0409 > usb 2-2: new device strings: Mfr=1, Product=2, SerialNumber=0 > usb 2-2: Product: USB Mouse > usb 2-2: Manufacturer: Logitech > usb 2-2: hotplug > usb 2-2: adding 2-2:1.0 (config #1, interface 0) > usb 2-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 around? Maybe that would shed some > more light on this issue. Yes. Read Documentation/usb/usbmon.txt in the kernel source. Alan Stern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
On Thu, 1 Dec 2005, Willi Mann wrote: > > > I have already reported this bug in the Debian BTS with many details: > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314954 > > > I have now tested with a second logitech mouse attached. > > Bus 004 Device 004: ID 04b4:6560 Cypress Semiconductor Corp. CY7C65640 > USB-2.0 "TetraHub" > Bus 004 Device 001: ID : > Bus 002 Device 006: ID 046a:0004 Cherry GmbH > Bus 002 Device 001: ID : > Bus 001 Device 007: ID 046d:c00e Logitech, Inc. Optical Mouse > Bus 001 Device 006: ID 046d:c00c Logitech, Inc. Optical Wheel Mouse > Bus 001 Device 001: ID : > Bus 003 Device 001: ID : > > It also loses the connection after a random amount of time (or maybe > mouse move distance), but they lose the connection independently of each > 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 and rebuild the USB drivers. Post the kernel or dmesg log showing what happens when the connection is lost. Alan Stern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
