Re: USB Ohci Suspend/Resume

On Saturday 05 April 2003 12:38 pm, Anish Mistry wrote:
> Hi,
> 	I've been working on some usb suspend/resume code for my laptop since the 
USB 
> ports stop working after a resume.  After a lot of trial and error I finally 
> got it to "work" sorta.  Behavior with my code:
> 1) If I remove any type of device, suspend the laptop and then resume any 
usb 
> device that I plug in will start working correctly, etc.
> attach -> detach -> suspend -> resume -> attach  (OK)
> 2) When I leave a device plugged in and remove it while it is suspended, 
then 
> resume it, the laptop will resume properly, but when I plug the device back 
> it will show a detaching message then panic.
> attach -> suspend -> detach -> resume -> attach  (Panic)
> 3) If I leave the device plugged in then suspend and resume with the device 
> plugged in it will panic.
> attach -> suspend -> resume -> (Panic)
> 4) If I suspend the laptop, plug in the device, and then resume, then it's 
ok.
> suspend -> attach -> resume -> (Ok)
> 
> Now for the weird part, at least for me.   Panics for numbers (2) and (3) 
only 
> happen with certain classes of devices (ums,ukbd), but with devices like 
> (uhid,umass,uscanner,ugen) there was no panic and the devices reattached 
just 
> fine.  These were the only type of devices that I was able to test, so the 
> lists probably includes other device types.
> 
> If anyone has any suggestions it would be appreciated.  This is my first 
> attempt at any kernel code.
> 
> Attached is my dmesg, and usb code patch. 
> 
> Thanks,
> 
> This is where it panics:
> ohci_device_intr_close
> 
> This GDB was configured as "i386-undermydesk-freebsd"...
> panic: page fault
> panic messages:
> ---
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x10
> fault code              = supervisor write, page not present
> instruction pointer     = 0x8:0xc266605f
> stack pointer           = 0x10:0xcd357be4
> frame pointer           = 0x10:0xcd357c00
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 337 (usb0)
> trap number             = 12
> panic: page fault
> 
> syncing disks, buffers remaining... 1414 1414 1413 1413 1413 1413 1413 1413 
> 1413                        1413 1413 1413 1413 1413 1413 
> wakeup from sleeping state (slept 00:00:09)
> ata0: resetting devices ..
> done
> ata1: resetting devices ..
> done
> 1413 1413 1413 1413 1413 1413 1413 
> giving up on 1326 buffers
> Uptime: 1m39s
> Dumping 239 MB
> ata0: resetting devices ..
> done
>  16 32 48 64 80 96 112 128 144 160 176 192 208 224
> ---
> Reading symbols from 
> /usr/obj/usr/src/sys/LITTLEGUY/modules/usr/src/sys/modules/                       
> acpi/acpi.ko.debug...done.
> pi/acpi.ko.debug
> Reading symbols from 
> /usr/obj/usr/src/sys/LITTLEGUY/modules/usr/src/sys/modules/                       
> usb/usb.ko.debug...done.
> Loaded symbols for 
> /usr/obj/usr/src/sys/LITTLEGUY/modules/usr/src/sys/modules/us                       
> b/usb.ko.debug
> Reading symbols from 
> /usr/obj/usr/src/sys/LITTLEGUY/modules/usr/src/sys/modules/                       
> linux/linux.ko.debug...done.
> Loaded symbols for 
> /usr/obj/usr/src/sys/LITTLEGUY/modules/usr/src/sys/modules/li                       
> nux/linux.ko.debug
> Reading symbols from 
> /usr/obj/usr/src/sys/LITTLEGUY/modules/usr/src/sys/modules/                       
> ums/ums.ko.debug...done.
> Loaded symbols for 
> /usr/obj/usr/src/sys/LITTLEGUY/modules/usr/src/sys/modules/um                       
> s/ums.ko.debug
> #0  doadump () at /usr/src/sys/kern/kern_shutdown.c:239
> 239             dumping++;
> (kgdb) bt
> #0  doadump () at /usr/src/sys/kern/kern_shutdown.c:239
> #1  0xc01e5a98 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:371
> #2  0xc01e5d43 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
> #3  0xc02fa7e2 in trap_fatal (frame=0xcd357ba4, eva=0)
>     at /usr/src/sys/i386/i386/trap.c:843
> #4  0xc02fa4c2 in trap_pfault (frame=0xcd357ba4, usermode=0, eva=16)
>     at /usr/src/sys/i386/i386/trap.c:757
> #5  0xc02fa03d in trap (frame=
>       {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 4, tf_esi = -1033428992, 
> tf_                       ebp = -852132864, tf_isp = -852132912, tf_ebx = 
> -1033431168, tf_edx = 0, tf_ecx                        = -1033444956, tf_eax 
> = -1033429216, tf_trapno = 12, tf_err = 2, tf_eip = -10334                       
> 78049, tf_cs = 8, tf_eflags = 66118, tf_esp = -1033351552, tf_ss = 
> -852132872})
>     at /usr/src/sys/i386/i386/trap.c:444
> #6  0xc02eaa08 in calltrap () at {standard input}:96
> #7  0xc265c148 in usbd_close_pipe (pipe=0xc2671780)
>     at /usr/src/sys/dev/usb/usbdi.c:272
> #8  0xc26b3c4d in ums_disable (priv=0xc2671780)
>     at /usr/src/sys/dev/usb/ums.c:582
> #9  0xc26b36d2 in ums_detach (self=0x0) at /usr/src/sys/dev/usb/ums.c:371
> #10 0xc01f9d57 in device_detach (dev=0xc2672000) at device_if.h:48
> #11 0xc01f90ef in device_delete_child (dev=0x0, child=0xc28390a0)
>     at /usr/src/sys/kern/subr_bus.c:976
> #12 0xc265be93 in usb_disconnect_port (up=0x4, parent=0x0)
> ---Type <return> to continue, or q <return> to quit--- 
>     at /usr/src/sys/dev/usb/usb_subr.c:1364
> #13 0xc265919e in uhub_explore (dev=0xc262e100)
>     at /usr/src/sys/dev/usb/uhub.c:428
> #14 0xc2659f65 in usb_discover (v=0xc242c1a0) at 
> /usr/src/sys/dev/usb/usb.c:702
> #15 0xc2659958 in usb_event_thread (arg=0xc242c1a0)
>     at /usr/src/sys/dev/usb/usb.c:399
> #16 0xc01d3912 in fork_exit (callout=0xc26598f0 <usb_event_thread>, arg=0x0, 
>     frame=0x0) at /usr/src/sys/kern/kern_fork.c:791
> (kgdb) 
> 
> 
> -- 
> Anish Mistry
> 

I've worked a bit more at this, but the only thing I can seem to do to fix 
this for the ums and ukbd is to comment out the usbd_close_pipe() call.  Then 
device then seems to work perfectly with no panics or other visible side 
effects, but this just doesn't seem like a correct procedure.  If any USB 
people have any suggestions it would be appreciated.

Thanks,

-- 
Anish Mistry