Date: Thu, 26 Feb 2004 14:15:35 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Mike Tancsa <mike@sentex.net> Cc: stable@freebsd.org Subject: Re: Testers needed: Joe's MFC of USB code Message-ID: <Pine.BSF.4.21.0402261412110.6679-100000@InterJet.elischer.org> In-Reply-To: <6.0.3.0.0.20040226142202.104acb10@209.112.4.2>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 26 Feb 2004, Mike Tancsa wrote: > > OK, I have applied it to one of my older AMD boxes. > > ohci0: <SiS 5571 USB controller> mem 0xcfffc000-0xcfffcfff irq 5 at device > 1.2 on pci0 > usb0: OHCI version 1.0, legacy support > usb0: <SiS 5571 USB controller> on ohci0 > usb0: USB revision 1.0 > uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 3 ports with 3 removable, self powered > uhid0: APC Back-UPS ES 725 FW:802.n2.D USB FW:n2, rev 1.10/1.06, addr 2, > iclass 3/0 > ohci1: <SiS 5571 USB controller> mem 0xcfffd000-0xcfffdfff irq 5 at device > 1.3 on pci0 > usb1: OHCI version 1.0, legacy support > usb1: <SiS 5571 USB controller> on ohci1 > usb1: USB revision 1.0 > uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub1: 3 ports with 3 removable, self powered > > ohci0@pci0:1:2: class=0x0c0310 card=0x70011039 chip=0x70011039 rev=0x07 > hdr=0x00 > vendor = 'Silicon Integrated Systems (SiS)' > device = 'SiS5597/8 Universal Serial Bus Controller' > class = serial bus > subclass = USB > ohci1@pci0:1:3: class=0x0c0310 card=0x70001039 chip=0x70011039 rev=0x07 > hdr=0x00 > vendor = 'Silicon Integrated Systems (SiS)' > device = 'SiS5597/8 Universal Serial Bus Controller' > class = serial bus > subclass = USB > > > It seems to work as it did before. However, as my colleague found , it > still panic's when you detach the ucom device. So, this bug is already present in RELENG_4 and has survived the MFC.. Have you tried the same thing on 5.x? Can you get a traceback? (either a serial console or a coredump) Does it work well with devices plugged into the ohci ports when powered up? Earlier versions of the the patch had troubles with that but it seems to have been solved. (at least for me). > > ---Mike > > At 01:26 PM 26/02/2004, Julian Elischer wrote: > > > >On Fri, 27 Feb 2004, Eugene Grosbein wrote: > >[...] > > > 'Failed to set value of option mode: Device busy'. > > > 6. Choose 'File/Exit' menu in this xscanimage window. > > > > > > Several seconds later system will lock up. There is nothing to be done > > > if you are in X, only power down/up cycle will help. > > > > > > > > > Sympthoms of lockup: system does not respond to pings, consoles do not > > switch. > > > Ctril-Alt-ESC will work for a few moments after lockup > > > but if you wait a little, it won't work and lockup will become 'total'. > > > > > > Versions: sane-backends-1.0.13_2, sane-frontends-1.0.11_1, gimp-1.2.3_2,1 > > > > > > Now what do we have with a patch proposed? Well, instead of lockup > > > we obtain good old kernel panic (the patch is really usefull). > > > And crashdump, of course. The panic is 100% repeatable. Here comes gdb > > > backtrace (kernel compiled with INVARIANTS and debug info): > > > > >thankyou! > > > >this is exactly the kind of thing we are looking for.. > > > >I have a scanner here.. I'll try duplicate it.. > >looks like it is caused by closing the file descriptor while the device > >is "busy" in some way.. > > > >Julian > > > > > >_______________________________________________ > >freebsd-stable@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0402261412110.6679-100000>