Hi
I'm not familiar with the USB code, but I've been hitting a BUG() with my
new OHCI card (sorry, it was cheap :( )
the BUG() is at line 464 in usb-ohci.h, which seems to be a linked-list
traversal failing to find an entry.
the backtrace /does/ seem to be the same every time. I dont have ksymoops
(on ARM I decode oopses with grep and system.map :). This appears not to
work so well for X86, but here goes...
c583708b - n/a
c01098fc - follows handle_IRQ_event
c0109a62 - preceeds request_irq
c0106c10 - default_idle
c0106c10 - default_idle
c0106c33 - follows default_idle
c0106c97 - follows cpu_idle
c0105000 - _stext
c0105027 - follows rest_init
Ian Molton Awoke this dragon, who will now respond:
> Hi
>
> I'm not familiar with the USB code, but I've been hitting a BUG() with my
> new OHCI card (sorry, it was cheap :( )
Oops. sorry, forgot - kernel 2.4.19-pre6 (same problem on
2.4.12-ac_something though)
On Sun, 14 Apr 2002 00:40:22 +0100,
Ian Molton <[email protected]> wrote:
>the backtrace /does/ seem to be the same every time. I dont have ksymoops
>(on ARM I decode oopses with grep and system.map :).
Any particular reason for not using ksymoops? If it does not work on
arm, I can get rid of all the arm code ;).
On Sun, Apr 14, 2002 at 10:11:48AM +1000, Keith Owens wrote:
> Any particular reason for not using ksymoops? If it does not work on
> arm, I can get rid of all the arm code ;).
It does work on ARM. I use it, and we've had a few posts using it.
However, since it took several _months_ for the ksymoops version with
the fixed regexps for ARM to come out, I don't really think you're
justified in the above comments.
However, it's just that most people don't bother to think about reading
any documentation (like REPORTING-BUGS) and think that just posting
random bits is sufficient. It's difficult enough to get these people to
post basic things like kernel versions and so forth.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Sun, 14 Apr 2002 10:26:32 +0100,
Russell King <[email protected]> wrote:
>On Sun, Apr 14, 2002 at 10:11:48AM +1000, Keith Owens wrote:
>> Any particular reason for not using ksymoops? If it does not work on
>> arm, I can get rid of all the arm code ;).
>
>It does work on ARM. I use it, and we've had a few posts using it.
>However, since it took several _months_ for the ksymoops version with
>the fixed regexps for ARM to come out, I don't really think you're
>justified in the above comments.
You missed the smiley.
I must admit that ksymoops tends to be the poor relation, it is my
lowest priority out of ia64, kdb, kbuild, modutils and ksymoops. Now
if I could just get kbuild 2.5 and kdb into the kernel, I would have
more time for the other projects :-)>
On Sun, Apr 14, 2002 at 12:40:22AM +0100, Ian Molton wrote:
> Hi
>
> I'm not familiar with the USB code, but I've been hitting a BUG() with my
> new OHCI card (sorry, it was cheap :( )
>
> the BUG() is at line 464 in usb-ohci.h, which seems to be a linked-list
> traversal failing to find an entry.
So your "Subject:" is wrong? Which driver are you having problems with?
usb-ohci.c or usb-uhci.c?
What platform are you running this on, x86?
What devices do you have plugged in?
What were you doing when the BUG() call happened?
Are there any kernel log entries before the BUG()?
What is your .config?
What is the output of /proc/bus/usb/devices with your USB device plugged
in?
thanks,
greg k-h
Greg KH Awoke this dragon, who will now respond:
> On Sun, Apr 14, 2002 at 12:40:22AM +0100, Ian Molton wrote:
> > Hi
> >
> > I'm not familiar with the USB code, but I've been hitting a BUG() with
> > my new OHCI card (sorry, it was cheap :( )
> >
> > the BUG() is at line 464 in usb-ohci.h, which seems to be a linked-list
> > traversal failing to find an entry.
>
> So your "Subject:" is wrong? Which driver are you having problems with?
> usb-ohci.c or usb-uhci.c?
yes. sh*t. sorry :-/
its usb-ohci.
> What platform are you running this on, x86?
yes
> What devices do you have plugged in?
one alcatel usb speedtouch ADSL modem, using the 'user mode' driver.
> What were you doing when the BUG() call happened?
surfin' the net ;) it appears to occur randomly - its been fine the whole
day today, although less stressed than yesterday.
> Are there any kernel log entries before the BUG()?
nope.
> What is your .config?
I can mail it if necessary.
> What is the output of /proc/bus/usb/devices with your USB device plugged
> in?
bash-2.05$ cat /proc/bus/usb/devices
T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 0.00
S: Product=USB OHCI Root Hub
S: SerialNumber=c583b000
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=ff(vend.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=06b9 ProdID=4061 Rev= 0.00
S: Manufacturer=ALCATEL
S: Product=Speed Touch USB
S: SerialNumber=0090D047C395
C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=usbdevfs
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=50ms
I: If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=00 Prot=00 Driver=usbdevfs
I: If#= 1 Alt= 1 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=usbdevfs
E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=07(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=87(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I: If#= 1 Alt= 2 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=usbdevfs
E: Ad=06(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms
E: Ad=07(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms
E: Ad=87(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I: If#= 1 Alt= 3 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=usbdevfs
E: Ad=06(O) Atr=02(Bulk) MxPS= 16 Ivl=0ms
E: Ad=07(O) Atr=02(Bulk) MxPS= 16 Ivl=0ms
E: Ad=87(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=05(O) Atr=02(Bulk) MxPS= 8 Ivl=0ms
E: Ad=85(I) Atr=02(Bulk) MxPS= 8 Ivl=0ms
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 0.00
S: Product=USB OHCI Root Hub
S: SerialNumber=c5839000
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
On Sun, Apr 14, 2002 at 06:32:47PM +0100, Ian Molton wrote:
>
> > What devices do you have plugged in?
>
> one alcatel usb speedtouch ADSL modem, using the 'user mode' driver.
Ah, please try using the patch below from David Brownell to fix this
problem. I've already applied this to my trees, and will get pushed to
the main kernels soon.
Let me know if this helps or not.
thanks,
greg k-h
--- drivers/usb-dist/devio.c Tue Nov 20 22:39:48 2001
+++ drivers/usb/devio.c Wed Mar 20 08:47:37 2002
@@ -286,7 +286,9 @@
}
/*
- * interface claiming
+ * interface claims are made only at the request of user level code,
+ * which can also release them (explicitly or by closing files).
+ * they're also undone when devices disconnect.
*/
static void *driver_probe(struct usb_device *dev, unsigned int intf,
@@ -299,7 +301,20 @@
{
struct dev_state *ps = (struct dev_state *)context;
+ if (!ps)
+ return;
+
+ /* this waits till synchronous requests complete */
+ down_write (&ps->devsem);
+
+ /* prevent new I/O requests */
+ ps->dev = 0;
ps->ifclaimed = 0;
+
+ /* force async requests to complete */
+ destroy_all_async (ps);
+
+ up_write (&ps->devsem);
}
struct usb_driver usbdevfs_driver = {
Greg KH Awoke this dragon, who will now respond:
> On Sun, Apr 14, 2002 at 06:32:47PM +0100, Ian Molton wrote:
> >
> > > What devices do you have plugged in?
> >
> > one alcatel usb speedtouch ADSL modem, using the 'user mode' driver.
>
> Ah, please try using the patch below from David Brownell to fix this
> problem. I've already applied this to my trees, and will get pushed to
> the main kernels soon.
>
> Let me know if this helps or not.
apparently not. first time it booted, it oopsed (not recorded, sorry).
second time, it hit the BUG() again. same backtrace.
I built USB all as modules, in case thats relevant.
On Sun, Apr 14, 2002 at 07:25:32PM +0100, Ian Molton wrote:
> Greg KH Awoke this dragon, who will now respond:
>
> > On Sun, Apr 14, 2002 at 06:32:47PM +0100, Ian Molton wrote:
> > >
> > > > What devices do you have plugged in?
> > >
> > > one alcatel usb speedtouch ADSL modem, using the 'user mode' driver.
> >
> > Ah, please try using the patch below from David Brownell to fix this
> > problem. I've already applied this to my trees, and will get pushed to
> > the main kernels soon.
> >
> > Let me know if this helps or not.
>
> apparently not. first time it booted, it oopsed (not recorded, sorry).
> second time, it hit the BUG() again. same backtrace.
Is this before you even run the usermode driver?
A real ksymoops output would be appreciated.
thanks,
greg k-h
Greg KH wrote:
> On Sun, Apr 14, 2002 at 06:32:47PM +0100, Ian Molton wrote:
>
>>>What devices do you have plugged in?
>>
>>one alcatel usb speedtouch ADSL modem, using the 'user mode' driver.
>
>
> Ah, please try using the patch below from David Brownell to fix this
> problem. I've already applied this to my trees, and will get pushed to
> the main kernels soon.
The oops doesn't come when the driver is exiting in this case (as the
patch was for), it "occurs randomly". The problem might be with the usb
hardware.
> Ian Molton wrote:
>>>What were you doing when the BUG() call happened?
>>
>> surfin' the net ;) it appears to occur randomly - its been fine the whole
>> day today, although less stressed than yesterday.
What is the motherboard, is it an usb add-on card ?
Pierre
------------------------------------------------
Pierre Rousselet <[email protected]>
------------------------------------------------
Pierre Rousselet Awoke this dragon, who will now respond:
>
> The oops doesn't come when the driver is exiting in this case (as the
> patch was for), it "occurs randomly". The problem might be with the usb
> hardware.
> > Ian Molton wrote:
> >>>What were you doing when the BUG() call happened?
> >>
> >> surfin' the net ;) it appears to occur randomly - its been fine the
> >> whole day today, although less stressed than yesterday.
>
> What is the motherboard, is it an usb add-on card ?
Its a VIA based board, and it /is/ an add-on card. its a 4 port OPTi based
card.
Mobo stuff:
Bus 0, device 0, function 0:
Host bridge: VIA Technologies, Inc. VT82C597 [Apollo VP3] (rev 4).
Master Capable. Latency=16.
Prefetchable 32 bit memory at 0xe0000000 [0xe07fffff].
Bus 0, device 1, function 0:
PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x
AGP] (rev 0). Master Capable. No bursts. Min Gnt=4.
USB controller:
Bus 0, device 10, function 0:
USB Controller: OPTi Inc. 82C861 (rev 32).
IRQ 10.
Master Capable. Latency=16. Max Lat=80.
Non-prefetchable 32 bit memory at 0xe0800000 [0xe0800fff].
Bus 0, device 10, function 1:
USB Controller: OPTi Inc. 82C861 (#2) (rev 32).
IRQ 12.
Master Capable. Latency=16. Max Lat=80.
Non-prefetchable 32 bit memory at 0xe0801000 [0xe0801fff].
Ian Molton wrote:
> Its a VIA based board, and it /is/ an add-on card. its a 4 port OPTi based
> card.
From FAQ on Alcatel site:
Q11: My modem often powers down without any reason and I have to reboot
to connect again.
A11: This is a known problem with motherboards using the VIA chipset.
Always install the latest Via4in1 drivers and USB filter from the Via
website. If you have a Motherboard of the KT7 type, one workaround is to
change the BIOS settings: set the 'enhanced chipset performance' setting
on 'enable'. This should help in most cases. For more information about
the KT7 / VIA chipset issues with USB, you may read the the ViaHardware
FAQ pages or the USBman page.
Pierre
------------------------------------------------
Pierre Rousselet <[email protected]>
------------------------------------------------
Pierre Rousselet Awoke this dragon, who will now respond:
> Ian Molton wrote:
> > Its a VIA based board, and it /is/ an add-on card. its a 4 port OPTi
> > based card.
>
> From FAQ on Alcatel site:
>
> Q11: My modem often powers down without any reason and I have to reboot
> to connect again.
the modem doesnt power down. all I get is an oops.
the machine is a k6-ii and is otherwise reliable (even with 100mbit
ethernet).
I've been poking about and have replaced the BUG() with a printk("about to
die!\n"), and return NULL.
I then hardened dl_reverse_done_list so it wouldnt die on receiving a NULL.
this seems to have improved things a LITTLE. I see a few 'about to die's
whizz by, and it stiffs shortly after.
does that help anyone?