Testers needed: Joe's MFC of USB code

[Julian Elischer]

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 at 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 at 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 at freebsd.org mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> >To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
> 
>