Bug 102469

Summary: Kernel panic when accessing a Sony CLIE (PEG-S300)
Product: [Retired] Red Hat Linux Beta Reporter: Need Real Name <gboyce>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: beta1CC: riel
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-01-17 17:07:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Need Real Name 2003-08-15 16:54:39 UTC
Description of problem:
While attempting to access my Sony Clie under Severn, X would eventually stop
responding correctly, and the machine would lock up.  After running similiar
steps from the console, I found that the machine was panicing.

Version-Release number of selected component (if applicable):
2.4.21-20.1.2024.2.1.nptl (Atlhon + i686)

How reproducible:
Every time, on two separate machines.

Steps to Reproduce:
1.Load "Visor" kernel module.
2.Press "hotsync" on Clie cradle
3.Around when the Clie stops trying to sync, the machine panics.
    
Actual results:
Kernel panic

Expected results:
Successful sync.

Additional info:
Note that this is my first attempt to access the Clie under linux.  I'm not sure
if this panic is specific to Severn, or if it happens on earlier releases as
well.  I should be able to test that in a few days.

Here is the panic:

Aug 14 23:50:49 necronomicon kernel: usb-uhci.c: interrupt, status 3, frame# 551
Aug 14 23:50:49 necronomicon kernel: usb.c: USB disconnect on device 00:07.2-2
address 2
Aug 14 23:50:49 necronomicon kernel: visor.c: Bytes In = 382  Bytes Out = 362
Aug 14 23:50:49 necronomicon kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00000998
Aug 14 23:50:49 necronomicon kernel:  printing eip:
Aug 14 23:50:49 necronomicon kernel: e4d634da
Aug 14 23:50:49 necronomicon kernel: *pde = 1d23f067
Aug 14 23:50:49 necronomicon kernel: *pte = 00000000
Aug 14 23:50:49 necronomicon kernel: Oops: 0002
Aug 14 23:50:49 necronomicon kernel: visor usbserial radeon agpgart parport_pc
lp parport button autofs tg3 ipt_REJECT iptable_filter ip_tables sg sr_mod
floppy ide-scsi scsi_mod ide-cd cdrom key
Aug 14 23:50:49 necronomicon kernel: CPU:    0
Aug 14 23:50:49 necronomicon kernel: EIP:    0060:[<e4d634da>]    Not tainted
Aug 14 23:50:49 necronomicon kernel: EFLAGS: 00010246
Aug 14 23:50:49 necronomicon kernel:
Aug 14 23:50:49 necronomicon kernel: EIP is at usb_serial_disconnect [usbserial]
0x6a (2.4.21-20.1.2024.2.1.nptl)
Aug 14 23:50:49 necronomicon kernel: eax: 00000000   ebx: ddae6400   ecx:
c178c000   edx: dda5df7c
Aug 14 23:50:49 necronomicon kernel: esi: ddae641c   edi: 00000000   ebp:
ddae6400   esp: c178df18
Aug 14 23:50:49 necronomicon kernel: ds: 0068   es: 0068   ss: 0068
Aug 14 23:50:49 necronomicon kernel: Process khubd (pid: 78, stackpage=c178d000)
Aug 14 23:50:49 necronomicon kernel: Stack: ddae641c 00000000 00000010 e4d65480
e4d65460 00000000 dac29494 e0836274
Aug 14 23:50:49 necronomicon kernel:        dd6ef800 ddae6400 dd6ef804 00000002
00000000 dd6ef800 00000100 0000000a
Aug 14 23:50:49 necronomicon kernel:        dfeade00 00000001 e08390cf dfeadf10
00000002 00000010 dfeade00 e0838b2c
Aug 14 23:50:49 necronomicon kernel: Call Trace:   [<e4d65480>]
usb_serial_driver [usbserial] 0x20 (0xc178df24)
Aug 14 23:50:49 necronomicon kernel: [<e4d65460>] usb_serial_driver [usbserial]
0x0 (0xc178df28)
Aug 14 23:50:49 necronomicon kernel: [<e0836274>] usb_disconnect_R2a7790a1
[usbcore] 0x94 (0xc178df34)
Aug 14 23:50:49 necronomicon kernel: [<e08390cf>] usb_hub_port_connect_change
[usbcore] 0x26f (0xc178df60)
Aug 14 23:50:49 necronomicon kernel: [<e0838b2c>] usb_hub_port_status [usbcore]
0x6c (0xc178df74)
Aug 14 23:50:49 necronomicon kernel: [<e08393b8>] usb_hub_events [usbcore] 0x2d8
(0xc178df94)
Aug 14 23:50:49 necronomicon kernel: [<e0839446>] usb_hub_thread [usbcore] 0x36
(0xc178dfc0)
Aug 14 23:50:49 necronomicon kernel: [<e0839410>] usb_hub_thread [usbcore] 0x0
(0xc178dfc4)
Aug 14 23:50:49 necronomicon kernel: [<e0839410>] usb_hub_thread [usbcore] 0x0
(0xc178dfe0)
Aug 14 23:50:49 necronomicon kernel: [<c010727d>] kernel_thread_helper [kernel]
0x5 (0xc178dff0)
Aug 14 23:50:49 necronomicon kernel:
Aug 14 23:50:49 necronomicon kernel:
Aug 14 23:50:49 necronomicon kernel: Code: c7 80 98 09 00 00 00 00 00 00 8d 4e
58 ff 43 74 0f 8e 74 05

Comment 1 Dave Jones 2003-08-15 17:09:05 UTC
Looks familiar. I found that driver particularly easy to break when I got my
Clie too, and that was with a mainstream kernel.  Chances are this is going to
be fixed upstream before someone at Red Hat digs into it, so you may be better
off trying to work with the upstream maintainer, especially as iirc, we don't
apply any patches to that driver..


Comment 2 Need Real Name 2003-08-16 02:15:23 UTC
I just tested this with Redhat 9 with the 2.4.20-18.9 kernel, and could not
reproduce the panic (although I still don't have gpilot setup properly.

Comment 3 Pete Zaitcev 2004-01-17 17:07:01 UTC
I'm pretty sure my "helper process" fixes that. Closing.