Bug#738113: linux-image-3.12-1-amd64: regression in xhci_hcd: USB3 doesn't work anymore
On Tue, Feb 11, 2014 at 06:11:09PM +0100, Andreas Cadhalpun wrote:
Hi,
thanks for looking into the issue.
On 11.02.2014 17:40, Sarah Sharp wrote:
On Sat, Feb 08, 2014 at 03:56:31AM +, Ben Hutchings wrote:
For the benefit of other developers, that change is a revert of commit
459d3c146117 ('usb: xhci: Link TRB must not occur within a USB payload
burst') plus this effective revert of commit fc76051c453b ('USB: XHCI:
mark no_sg_constraint'):
I hope that's unrelated. I was effectively going to do the same thing
upstream (except allow the no_sg_constraint to be set on 0.96 and
earlier hosts).
I don't know what else changed from 3.12.8-1 to 3.12.9-1, but this
was the only point in the changelog mentioning xhci.
Alan and I concluded that the cause of this issue is clearing the
no_sg_constraint flag for 1.0 xHCI hosts. The patches to revert the
commits that caused the issues are on their way to the USB subsystem
maintainer (Greg):
http://marc.info/?l=linux-kernelm=139420433008427w=2
http://marc.info/?l=linux-kernelm=139420429908418w=2
http://marc.info/?l=linux-kernelm=139420432208425w=2
The second commit is needed, since once we allow arbitrarily-aligned
scatter-gather, the ASIX driver will use it, which causes the USB to
ethernet adapter to drop packets occasionally.
So we're basically back where we started before 3.12. Scatter-gather
isn't supported on the ASIX driver, and mass storage scatter-gather
works fine. We'll fix the ethernet driver case in 3.16 once we
implement TD fragments.
Sarah Sharp
What does `sudo lspci` show as the manufacturer of your host controller?
The host controller is:
00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series
Chipset Family USB xHCI [8086:8c31] (rev 05) (prog-if 30 [XHCI])
Subsystem: Lenovo Device [17aa:3978]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 46
Region 0: Memory at b570 (64-bit, non-prefetchable) [size=64K]
Capabilities: access denied
Kernel driver in use: xhci_hcd
More information about my setup (including this) can be found in the
original bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738113
Have you also tried reverting commit
9df89d85b407690afa46ddfbccc80bec6869971d usbcore: set lpm_capable field
for LPM capable root hubs? It enables USB 3.0 Link PM for non-Intel
host controllers, which is not what I intended, and could cause issues
with other host controllers. A patch to revert that was sent to Greg
last week, but it looks like it hasn't gotten into Linus' tree yet.
Not sure if that would help, as I have an Intel host controller.
Best regards,
Andreas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738113: linux-image-3.12-1-amd64: regression in xhci_hcd: USB3 doesn't work anymore
On Sat, Feb 08, 2014 at 03:56:31AM +, Ben Hutchings wrote:
On Fri, 2014-02-07 at 21:06 +0100, Andreas Cadhalpun wrote:
Package: src:linux
Version: 3.12.9-1
Severity: important
X-Debbugs-CC: Ben Hutchings b...@decadent.org.uk
Dear Maintainer,
linux 3.12.9-1 introduced a regression in xhci_hcd: USB3 does not work
any more! (see the Kernel log below)
This worked with 3.12.8-1 and still works with 3.13-1~exp1.
In the changelog from 3.12.9-1 the only related change seems to be:
[ Ben Hutchings ]
* xhci: Revert generalised sg support (Closes: #733826, #736274)
For the benefit of other developers, that change is a revert of commit
459d3c146117 ('usb: xhci: Link TRB must not occur within a USB payload
burst') plus this effective revert of commit fc76051c453b ('USB: XHCI:
mark no_sg_constraint'):
I hope that's unrelated. I was effectively going to do the same thing
upstream (except allow the no_sg_constraint to be set on 0.96 and
earlier hosts).
[ 45.906406] sd 5:0:0:0: [sdb] Attached SCSI removable disk
[ 46.135625] FAT-fs (sdb1): utf8 is not a recommended IO charset for
FAT filesystems, filesystem will be case sensitive!
[ 46.138042] FAT-fs (sdb1): Volume was not properly unmounted. Some
data may be corrupt. Please run fsck.
[ 77.320082] usb 4-1: Disable of device-initiated U1 failed.
[ 82.320078] usb 4-1: Disable of device-initiated U2 failed.
What does `sudo lspci` show as the manufacturer of your host controller?
[ 87.692070] xhci_hcd :00:14.0: Timeout while waiting for address
device command
[ 92.896070] xhci_hcd :00:14.0: Timeout while waiting for address
device command
[ 93.100052] usb 4-1: device not accepting address 2, error -62
[ 93.188178] sd 5:0:0:0: [sdb] Unhandled error code
[ 93.188180] sd 5:0:0:0: [sdb]
[ 93.188182] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[ 93.188183] sd 5:0:0:0: [sdb] CDB:
[ 93.188184] Read(10): 28 00 00 00 20 01 00 00 f0 00
[ 93.188189] end_request: I/O error, dev sdb, sector 8193
[ 93.188195] usb 4-1: USB disconnect, device number 2
[...]
Wish I did know. Other people ran into different (but similarly
serious) failures as a result of the changes in 3.12, and the consensus
has been that it would be best to revert those.
But I've just tried with an xHCI ExpressCard (NEC uPD720200 chip) and
USB3 SS disk enclosure, and I can see *somehwat* similar failures to
yours after running bonnie++ for a few seconds. Haven't used that for a
while, so I can't say whether it worked any better with the last
version.
Have you also tried reverting commit
9df89d85b407690afa46ddfbccc80bec6869971d usbcore: set lpm_capable field
for LPM capable root hubs? It enables USB 3.0 Link PM for non-Intel
host controllers, which is not what I intended, and could cause issues
with other host controllers. A patch to revert that was sent to Greg
last week, but it looks like it hasn't gotten into Linus' tree yet.
Sarah Sharp
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733826: [PATCH] xhci: Set scatter-gather limit to avoid failed block writes.
On Fri, Jan 17, 2014 at 04:18:52PM +0100, Johannes Stezenbach wrote: On Tue, Jan 07, 2014 at 02:40:39AM +, Ben Hutchings wrote: On Tue, 2014-01-07 at 07:01 +0800, jida...@jidanni.org wrote: Don't worry, I'll trust you! Plus I'm 53. I don't think anyone else has reproduced this problem, so you are the person in the best place to check that these changes really fix it. You can test patches against the Debian kernel package by following the instructions here: http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official Sascha Weaver found a way to reproduce the problem and was nice enough to test this patch, and also the one in Debian bug #733907. See: http://marc.info/?l=linux-usbm=138996707603975w=2 Ok, thanks for letting me know, Johannes. The patch is queued for 3.14, and won't land in the stable kernels until after 3.14-rc1 (in a couple weeks). Sarah Sharp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733826: crazy loop xhci_hcd Too many fragments
On Mon, Jan 06, 2014 at 03:52:24PM +, David Laight wrote: From: Alan Stern Subject: Re: Bug#733826: crazy loop xhci_hcd Too many fragments On Mon, 6 Jan 2014, Ben Hutchings wrote: On Sat, 2014-01-04 at 05:44 +0800, jida...@jidanni.org wrote: ... # cat /var/log/syslog Jan 1 06:57:38 jidanni5 ntpd[2822]: Listen normally on 5 lo ::1 UDP 123 Jan 1 06:57:38 jidanni5 ntpd[2822]: Listen normally on 6 eth0 fe80::2289:84ff:fe28:ad9 UDP 123 Jan 1 06:57:38 jidanni5 ntpd[2822]: peers refreshed Jan 1 06:57:38 jidanni5 ntpd[2822]: Listening on routing socket on fd #23 for interface updates Jan 1 07:04:49 jidanni5 kernel: [ 559.624680] xhci_hcd :00:14.0: Too many fragments 79, max 63 Jan 1 07:04:49 jidanni5 kernel: [ 559.624695] xhci_hcd :00:14.0: Too many fragments 79, max 63 Jan 1 07:04:49 jidanni5 kernel: [ 559.624704] xhci_hcd :00:14.0: Too many fragments 79, max 63 10 lines later... oops I mean an actual MILLION lines later Assuming my fix for the repetition is correct, the remaining problem is why usb-storage is generating such large/fragmented urbs. usb-storage doesn't generate large or fragmented anything. It merely passes on the scatter-gather information it gets from the block layer. Although not a real fix to the underlying problem, it seems that the default ring size is far too small. Did you mean ring segment size? Any amount of network traffic also activates the ring expansion code. IIRC each ring entry is 16 bytes, so increasing the ring size to 256 still keeps the rings to a single 4k page. Whether anything regularly exceeds 255 fragments is a another matter. If so, yes, changing the segment size makes sense. TRBS_PER_SEGMENT could be increased to 256. I'm not sure if we should switch to using dma_alloc_coherent instead of a DMA pool. Some systems could be using bigger than 4K pages, so we should probably still stick with DMA pools. Ben, can you change your patch to increase TRBS_PER_SEGMENT to 256? Sarah Sharp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733826: [PATCH] xhci: Set scatter-gather limit to avoid failed block writes.
Dan, can you test this patch, on top of the other patch that Ben sent?
There's directions for building a custom kernel here, if you need it:
http://kernelnewbies.org/KernelBuild
I suggest either getting the Debian kernel source and patching that, or
patching 3.12.6 or later.
Sarah Sharp
8--8
Commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e usb: xhci: Link TRB
must not occur within a USB payload burst attempted to fix an issue
found with USB ethernet adapters, and inadvertently broke USB storage
devices. The patch attempts to ensure that transfers never span a
segment, and rejects transfers that have more than 63 entries (or
possibly less, if some entries cross 64KB boundaries).
usb-storage limits the maximum transfer size to 120K, and we had assumed
the block layer would pass a scatter-gather list of 4K entries,
resulting in no more than 31 sglist entries:
http://marc.info/?l=linux-usbm=138498190419312w=2
That assumption was wrong, since we've seen the driver reject a write
that was 218 sectors long (of probably 512 bytes each):
Jan 1 07:04:49 jidanni5 kernel: [ 559.624704] xhci_hcd :00:14.0: Too many
fragments 79, max 63
...
Jan 1 07:04:58 jidanni5 kernel: [ 568.622583] Write(10): 2a 00 00 06 85 0e 00
00 da 00
Limit the number of scatter-gather entries to half a ring segment. That
should be margin enough in case some entries cross 64KB boundaries.
Increase the number of TRBs per segment from 64 to 256, which should
result in ring segments fitting on a 4K page.
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/host/xhci.c | 4 ++--
drivers/usb/host/xhci.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4265b48856f6..d45a0d584daf 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4713,8 +4713,8 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t
get_quirks)
struct device *dev = hcd-self.controller;
int retval;
- /* Accept arbitrarily long scatter-gather lists */
- hcd-self.sg_tablesize = ~0;
+ /* Limit the block layer scatter-gather lists to half a segment. */
+ hcd-self.sg_tablesize = TRBS_PER_SEGMENT / 2;
/* support to build packet from discontinuous buffers */
hcd-self.no_sg_constraint = 1;
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 03c74b7965f8..c283cf183c48 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1260,7 +1260,7 @@ union xhci_trb {
* since the command ring is 64-byte aligned.
* It must also be greater than 16.
*/
-#define TRBS_PER_SEGMENT 64
+#define TRBS_PER_SEGMENT 256
/* Allow two commands + a link TRB, along with any reserved command TRBs */
#define MAX_RSVD_CMD_TRBS (TRBS_PER_SEGMENT - 3)
#define TRB_SEGMENT_SIZE (TRBS_PER_SEGMENT*16)
--
1.8.3.3
--
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, Oct 04, 2012 at 11:36:06PM +0200, 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. 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. 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? Sometimes USB 2.0 hubs can handle more electrical noise from the host controller, especially if they are externally powered by a wall-wort. So introducing a USB 2.0 hub may fix the transfer errors caused by the host. BTW, do these Ivy Bridge systems have any (blue) USB 3.0 ports? If so, does your mouse and keyboard work under those ports? Sarah Sharp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596528: Debuging large transfer under usb3 device
Thanks Guillaume! No rush, I just wanted to make sure I hadn't dropped the ball on a bug report. Sarah Sharp On Fri, May 25, 2012 at 12:42:31AM +0200, Guillaume Jaouen wrote: Hi, I'm really sorry but I had no time yet for tracking this bug. As requested, I will build the last kernel from source with USB 3 debugging mode. I think I'll be able to post these logs sunday. Best regards, Guillaume Jaouen. Le 23 mai 2012 à 21:00, Sarah Sharp sarah.a.sh...@linux.intel.com a écrit : On Sun, May 20, 2012 at 03:50:29AM -0500, Jonathan Nieder wrote: In February, Sarah Sharp wrote: On Mon, Feb 27, 2012 at 08:18:13PM +0100, guillaume.jao...@free.fr wrote: [...] I can't be sure that your host controller is the thing that's broken unless you rebuild your kernel with CONFIG_USB_DEBUGGING and CONFIG_USB_XHCI_HCD_DEBUGGING turned on, and capture the full dmesg starting just before that transfer error. You'll really want to be running 3.3, since that cleaned up a lot of the xHCI driver debugging, and the log file will be much smaller. Did anything come of these questions? Some instructions for building a custom kernel on Debian are at [3], for what it's worth. I didn't get any additional log files, and I can't track down this issue without them. Sarah Sharp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596528: Debuging large transfer under usb3 device
On Sun, May 20, 2012 at 03:50:29AM -0500, Jonathan Nieder wrote: In February, Sarah Sharp wrote: On Mon, Feb 27, 2012 at 08:18:13PM +0100, guillaume.jao...@free.fr wrote: [...] I can't be sure that your host controller is the thing that's broken unless you rebuild your kernel with CONFIG_USB_DEBUGGING and CONFIG_USB_XHCI_HCD_DEBUGGING turned on, and capture the full dmesg starting just before that transfer error. You'll really want to be running 3.3, since that cleaned up a lot of the xHCI driver debugging, and the log file will be much smaller. Did anything come of these questions? Some instructions for building a custom kernel on Debian are at [3], for what it's worth. I didn't get any additional log files, and I can't track down this issue without them. Sarah Sharp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596528: Debuging large transfer under usb3 device
debian kernel: [57835.243349] end_request: I/O error, dev sdd, sector 3703160488 Feb 27 10:29:45 debian kernel: [57835.243417] scsi 5:0:0:0: [sdd] Unhandled error code Feb 27 10:29:45 debian kernel: [57835.243422] scsi 5:0:0:0: [sdd] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK Feb 27 10:29:45 debian kernel: [57835.243429] scsi 5:0:0:0: [sdd] CDB: Write(10): 2a 00 dc b9 bf 98 00 00 f0 00 Feb 27 10:29:45 debian kernel: [57835.243448] end_request: I/O error, dev sdd, sector 3703160728 I'm guessing a bit, but it looks like a transfer error happened, and then the usb-storage driver tried to reset the device. Then it looks like the host controller just stopped responding to commands (including the Set Address command and Reset Device command). That's what the Timeout...command messages are about. I can't be sure that your host controller is the thing that's broken unless you rebuild your kernel with CONFIG_USB_DEBUGGING and CONFIG_USB_XHCI_HCD_DEBUGGING turned on, and capture the full dmesg starting just before that transfer error. You'll really want to be running 3.3, since that cleaned up a lot of the xHCI driver debugging, and the log file will be much smaller. It's possible, although not likely, that we're over writing the link TRB on the command ring and causing the host controller to step off into lala land and access bad memory. My other theory is that your express card is just broken and can't handle the throughput. Or perhaps it's an early prototype that made it out into the market without having good transfer error support. Sarah Sharp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644174: ACPI I/O resource conflicts with ACPI region SMBI
On Wed, Dec 28, 2011 at 06:11:14PM +0100, Mathieu Malaterre wrote: On Thu, Dec 22, 2011 at 8:52 PM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: On Thu, Dec 22, 2011 at 04:18:56PM +0100, Mathieu Malaterre wrote: On Fri, Dec 16, 2011 at 11:27 AM, Jonathan Nieder jrnie...@gmail.com wrote: System: Dell System Vostro 3750 / Portable Computer Ok. So I am running: 3.2.0-rc4-amd64 from debian experimental. No mouse plugged to USB 2.0/3.0 interface: boot is fine Mouse plugged to USB 2.0 interface: boot is fine Mouse plugged to USB 3.0 interface: boot simply stops Does the boot stop when you have a non-HID USB device plugged into the USB 3.0 port (e.g. hub or flash drive or USB speaker)? It could be an issue with a buggy BIOS trying to use the mouse and keyboard (HID devices) attached to the USB 3.0 host. Perhaps it changes the ACPI tables when it tries to use the USB 3.0 host controller, and accidentally overlaps the regions? But if your keyboard and mouse were under USB 2.0, maybe it will only map in the USB 2.0 host controller. I tried booting kernel 3.0.2 (debian/unstable 3.2.0-rc4-amd64) with a USB key plugged into USB 3.0 and was stuck again. So I can confirm that with a normal USB key (non-HID) plugged in USB 3.0 port, makes the kernel refuse to boot. Please try a USB hub as well. It's possible the BIOS is trying to read from the flash drive (which is what I assume you mean by USB key). As suggested by Jonathan N. [1] here is what I did next: $ cat /etc/modprobe.d/mm-blacklist-xhci.conf blacklist xhci_hcd $ update-initramfs -u -k all $ sudo reboot Were you blacklisting xhci only because of the xhci_hcd :03:00.0: WARN: Stalled endpoint messages? Because those messages are harmless, and don't mean anything is *wrong* with the host controller. I simply blindly follow the suggestion. Yeah, don't try to blacklist xhci-hcd. It's not useful. Even if there's no xHCI driver loaded, it seems that ACPI is noticing the conflict between the PCI registers and another region. So unloading the xHCI driver won't help your system boot. You'd need to get a fix into the ACPI subsystem to work around the conflict. I don't think any xHCI driver modification can help here. Is there a way to check if bug is related to ACPI or rather USB 3.0 ? The log messages seem to indicate that it's either an ACPI or a BIOS issue. I really can't suggest any other tests without some input from the ACPI folks. The best solution I can suggest is not boot with a USB device plugged into your USB 3.0 port. Sarah Sharp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644174: ACPI I/O resource conflicts with ACPI region SMBI
On Thu, Dec 22, 2011 at 04:18:56PM +0100, Mathieu Malaterre wrote: On Fri, Dec 16, 2011 at 11:27 AM, Jonathan Nieder jrnie...@gmail.com wrote: - Please test a v3.2 release candidate from experimental. The only packages from outside squeeze that should be needed for this, aside from the kernel image itself, are linux-base and initramfs-tools. - If it reproduces the problem, please blacklist the xhci_hcd module by writing blacklist xhci_hcd to a file /etc/modprobe.d/mm-blacklist-xhci.conf, run update-initramfs -u -k all and reboot to try again without USB 3.0 support. If we're very lucky, this will work around the problem. In that case, please write a summary of the problem to upstream (linux-...@vger.kernel.org, cc-ing Sarah Sharp sarah.a.sh...@linux.intel.com and either me or this bug log so we can track the resulting discussion). Be sure to include: - steps to reproduce the problem - symptoms, and how they differ from what you expected - ways to avoid triggering the problem (maybe some USB ports trigger it and others don't? etc) - full dmesg output from booting, and a photo of the screen after reproducing the problem (ideally by running modprobe xhci_hcd in the very same run of Linux), as attachments - which kernel versions you've tested, and what happened with each - a link to this bug log for the full story - any other weird symptoms or observations System: Dell System Vostro 3750 / Portable Computer Ok. So I am running: 3.2.0-rc4-amd64 from debian experimental. No mouse plugged to USB 2.0/3.0 interface: boot is fine Mouse plugged to USB 2.0 interface: boot is fine Mouse plugged to USB 3.0 interface: boot simply stops Does the boot stop when you have a non-HID USB device plugged into the USB 3.0 port (e.g. hub or flash drive or USB speaker)? It could be an issue with a buggy BIOS trying to use the mouse and keyboard (HID devices) attached to the USB 3.0 host. Perhaps it changes the ACPI tables when it tries to use the USB 3.0 host controller, and accidentally overlaps the regions? But if your keyboard and mouse were under USB 2.0, maybe it will only map in the USB 2.0 host controller. As suggested by Jonathan N. [1] here is what I did next: $ cat /etc/modprobe.d/mm-blacklist-xhci.conf blacklist xhci_hcd $ update-initramfs -u -k all $ sudo reboot Were you blacklisting xhci only because of the xhci_hcd :03:00.0: WARN: Stalled endpoint messages? Because those messages are harmless, and don't mean anything is *wrong* with the host controller. Even if there's no xHCI driver loaded, it seems that ACPI is noticing the conflict between the PCI registers and another region. So unloading the xHCI driver won't help your system boot. You'd need to get a fix into the ACPI subsystem to work around the conflict. I don't think any xHCI driver modification can help here. 3.2.0-rc4-amd64 refuse to boot as soon as I plug my mouse to USB 3.0 port (screenshot at [2]). USB 2.0 and no mouse still boot fine. I am attaching dmesg from a kernel boot, when mouse is attached to USB 2.0 port (see [3]). I think I'll revert to 2.6.39-bpo.2-amd64 because kernel does not seems to like my video card. When I suspend/resume, screen is displayed on screen Ctrl+Shift+F8, while pointer stays on Ctrl+Shift+F7. I can type fine from Ctrl+Shift+F7, since I can see results on Ctrl+Shift+F8. I'll try to compile the nvidia kernel and see if suspend/resume works. Refs: [1] http://bugs.debian.org/644174 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644174#64 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644174#69 Sarah Sharp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584830: linux-image-2.6.32-5-amd64: USB 3.0 / xhci prevents suspend
On Mon, Jun 07, 2010 at 02:18:26AM +0100, Ben Hutchings wrote: On Mon, 2010-06-07 at 00:33 +0200, Thomas Jollans wrote: Package: linux-2.6 Version: 2.6.32-15 Severity: normal My motherboard includes a USB 3.0 controller, handled by the xhci module. When the xhci module is loaded, the system fails to suspend with the following log messages: [ 458.601622] pm_op(): usb_dev_suspend+0x0/0xa [usbcore] returns -2 [ 458.601624] PM: Device usb2 failed to suspend: error -2 When I unload the xhci module, the system suspends just fine, without this message. Sarah, any idea what's going on here? Debian version 2.6.32-15 is closely based on stable version 2.6.32.14. I didn't see any later changes to xhci that look related to PM. The report is expected behavior, since the xHCI driver doesn't implement PCI and USB bus power management yet. The xHCI power management code is still under development. I'm not sure if this code will be added to 2.6.32 stable, since it will add a lot of code to the driver. The code may need to be backported. Can you add this bug (or a link to the debian bug) to the kernel.org bugzilla? I'm trying to get all my xHCI-related bug reports and feature requests there. Sarah Sharp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509293: libgphoto2-2: udev rules broken - use usb_device rather than usb|usb_device
Package: libgphoto2-2 Version: 2.4.1-3 Severity: important Incorrect udev rules in the latest libgphoto2-2 package are not creating USB device files in the plugdev group. That means I can run gphoto2 as root, but not as a normal user. /etc/udev/rules.d/025_libgphoto2.rules includes this skip rule: SUBSYSTEM!=usb|usb_device, GOTO=libgphoto2_rules_end The pipe is not documented to work in the udev manpage, and I think this is the problem. When I change the line to: SUBSYSTEM!=usb_device, GOTO=libgphoto2_rules_end I can access the camera as a normal user. I have CONFIG_USB_DEVICE_CLASS=y in my kernel config. (I looked because of bug 427963.) I did comment out the /etc/fstab rule to automatically mount usbdevfs because I'm a USB developer and I need to be able to remove the USB core module. gphoto2 info: 0.000222 main(2): ALWAYS INCLUDE THE FOLLOWING LINES WHEN SENDING DEBUG MESSAGES TO THE MAILING LIST: 0.002469 main(2): gphoto2 2.4.0 0.002518 main(2): gphoto2 has been compiled with the following options: 0.002549 main(2): + gcc (C compiler used) 0.002629 main(2): + popt (mandatory, for handling command-line parameters) 0.002659 main(2): + exif (for displaying EXIF information) 0.002688 main(2): + cdk (for accessing configuration options) 0.002716 main(2): + no aa (for displaying live previews) 0.002744 main(2): + jpeg (for displaying live previews in JPEG format) 0.002773 main(2): + readline (for easy navigation in the shell) 0.002813 main(2): libgphoto2 2.4.1 0.002850 main(2): libgphoto2 has been compiled with the following options: 0.002880 main(2): + gcc (C compiler used) 0.002908 main(2): + ltdl (for portable loading of camlibs) 0.002936 main(2): + EXIF (for special handling of EXIF files) 0.002969 main(2): libgphoto2_port 0.8.0 0.003004 main(2): libgphoto2_port has been compiled with the following options: 0.003034 main(2): + gcc (C compiler used) 0.003062 main(2): + ltdl (for portable loading of camlibs) 0.003091 main(2): + USB (libusb, for USB cameras) 0.003118 main(2): + serial (for serial cameras) 0.003146 main(2): + no resmgr (serial port access and locking) 0.003175 main(2): + no baudboy (serial port locking) 0.003203 main(2): + no ttylock (serial port locking) 0.003231 main(2): + no lockdev (serial port locking) 0.003260 main(2): CAMLIBS env var not set, using compile-time default instead 0.003288 main(2): IOLIBS env var not set, using compile-time default instead -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.23-wireless (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libgphoto2-2 depends on: ii adduser 3.100 Add and remove users and groups ii libc6 2.7-4 GNU C Library: Shared libraries ii libexif12 0.6.16-2.1 library to parse EXIF files ii libgphoto2-port0 2.4.1-3gphoto2 digital camera port librar ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libltdl3 1.5.22-4 A system independent dlopen wrappe Versions of packages libgphoto2-2 recommends: ii udev 0.125-7/dev/ and hotplug management daemo -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#501060: evince does not preserve zoom across section changes
Package: evince Version: 2.22.2-2 Severity: important If I change the zoom level, then click on a different section in the index, the zoom changes back to the default level. This means I have to zoom in again every time I change sections. An example PDF that shows this problem can be found at http://www.intel.com/technology/usb/download/ehci-r10.pdf I will also file this bug against the upstream gnome bugzilla. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.23-wireless (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages evince depends on: ii gconf2 2.20.1-2 GNOME configuration database syste ii gnome-icon-theme2.20.0-1 GNOME Desktop icon theme ii libart-2.0-22.3.19-3 Library of functions for 2D graphi ii libatk1.0-0 1.20.0-1 The ATK accessibility toolkit ii libbonobo2-02.20.2-1 Bonobo CORBA interfaces library ii libbonoboui2-0 2.20.0-1 The Bonobo UI library ii libc6 2.7-4GNU C Library: Shared libraries ii libcairo2 1.6.4-6 The Cairo 2D vector graphics libra ii libdbus-1-3 1.1.1-3 simple interprocess messaging syst ii libdbus-glib-1-20.74-1 simple interprocess messaging syst ii libdjvulibre21 3.5.20-8 Runtime support for the DjVu image ii libfontconfig1 2.4.1-2 generic font configuration library ii libfreetype62.3.5-1+b1 FreeType 2 font engine, shared lib ii libgcc1 1:4.2.1-4GCC support library ii libgconf2-4 2.20.1-2 GNOME configuration database syste ii libglade2-0 1:2.6.2-1library to load .glade files at ru ii libglib2.0-02.16.1-2 The GLib library of C routines ii libgnome-keyring0 2.22.3-1 GNOME keyring services library ii libgnome2-0 2.20.1.1-1 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.20.1.1-1 A powerful object-oriented display ii libgnomeui-02.20.1.1-1 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 1:2.20.1-1 GNOME Virtual File System (runtime ii libgtk2.0-0 2.12.1-1 The GTK+ graphical user interface ii libice6 1:1.0.1-2X11 Inter-Client Exchange library ii libjpeg62 6b-14The Independent JPEG Group's JPEG ii libkpathsea42007.dfsg.1-2TeX Live: path search library for ii libnautilus-extension1 2.20.0-3 libraries for nautilus components ii liborbit2 1:2.14.10-0.1libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.20.5-1 Layout and rendering of internatio ii libpixman-1-0 0.10.0-2 pixel-manipulation library for X a ii libpng12-0 1.2.15~beta5-2 PNG library - runtime ii libpoppler-glib30.8.7-1 PDF rendering library (GLib-based ii libpopt01.14-4 lib for parsing cmdline parameters ii libsm6 1:1.0.1-3X11 Session Management library ii libspectre1 0.2.0.ds-1 Library for rendering Postscript d ii libstdc++6 4.2.1-4 The GNU Standard C++ Library v3 ii libtiff43.8.2-10 Tag Image File Format (TIFF) libra ii libx11-62:1.0.3-4X11 client-side library ii libxcb-render-util0 0.2+git36-1 utility libraries for X C Binding ii libxcb-render0 1.1-1.1 X C Binding, render extension ii libxcb1 1.1-1.1 X C Binding ii libxml2 2.6.29.dfsg-1GNOME XML library ii libxrender1 1:0.9.1-3X Rendering Extension client libra ii zlib1g 1:1.2.3.3.dfsg-5 compression library - runtime Versions of packages evince recommends: pn dbus-x11 none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
