Martin S. Weber a écrit :


> Basically the same as with the intel controller and as described elsewhere numerously.
> STALL, blah, repeat & cycle, with a lot of ehci_intrlist_timeout in between.

I have the same thing with what I think being a Texas controler:

ehci0 at pci2 dev 14 function 2: vendor 0x1033 product 0x00e0 (rev. 0x02)
vendor 0x1033 product 0x00e0 -> patching BAR
ehci0: interrupting at irq 10
ehci0: BIOS has given up ownership
ehci0: EHCI version 0.95
ehci0: companion controllers, 3 ports each: ohci0 ohci1
usb2 at ehci0: USB revision 2.0

The "patching BAR" is a personal hack that shifts the device from a 
shadow address space.

But, more puzzling, I came across that since yesturday:

[...]
wd0 at atabus0 drive 0: <HTS726060M9AT00>
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 57231 MB, 116280 cyl, 16 head, 63 sec, 512 bytes/sect x 117210240 
sectors
wd0: 32-bit data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
wd0(piixide0:0:0): using PIO mode 4, Ultra-DMA mode 5 (Ultra/100) (using 
DMA)
atapibus0 at atabus1: 2 targets
piixide0:1:0: lost interrupt
         type: ata tc_bcount: 512 tc_skip: 0
cd0 at atapibus0 drive 0: <SD-R2102, 52BF811837, 1A16> cdrom removable
piixide0:1:0: lost interrupt
         type: ata tc_bcount: 512 tc_skip: 0
piixide0:1:0: lost interrupt
         type: ata tc_bcount: 512 tc_skip: 0

That never occured before. Could it be related, or are these two well 
separate problems?

Thanks
Vincent