Bug 130076 - Panic when connecting USB camera
Summary: Panic when connecting USB camera
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-usb (Nobody)
Depends on:
Reported: 2008-12-31 12:00 UTC by Mike Clarke
Modified: 2018-01-03 05:16 UTC (History)
1 user (show)

See Also:

crashdump (2.21 KB, text/plain)
2008-12-31 12:00 UTC, Mike Clarke
no flags Details
dmesg.boot (39.53 KB, text/plain)
2008-12-31 12:00 UTC, Mike Clarke
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Clarke 2008-12-31 12:00:05 UTC
Connecting one of my USB cameras (Olympus C-2040Z) consistently
causes an instant panic. Other devices (e.g. Nikon Coolpix 3100,
Logitech USB mouse, Kingston memory stick, Canon printer) never
cause any problems.

The panic occurs immediately the camera is connected and before any
information about the device could be displayed on the console

I regularly use the Olympus camera with 6.4-RELEASE on the same
hardware with no problems but cannot use it with 7.1.

Another PC running version 7 and with a different chipset shows
the same problem and panics if I connect this camera.

Fix: none0@pci0:0:0:0: class=0x050000 card=0x0d04105b chip=0x02f010de rev=0xa2 hdr=0x00
none1@pci0:0:0:1: class=0x050000 card=0x0d04105b chip=0x02fa10de rev=0xa2 hdr=0x00
none2@pci0:0:0:2: class=0x050000 card=0x0d04105b chip=0x02fe10de rev=0xa2 hdr=0x00
none3@pci0:0:0:3: class=0x050000 card=0x0d04105b chip=0x02f810de rev=0xa2 hdr=0x00
none4@pci0:0:0:4: class=0x050000 card=0x0d04105b chip=0x02f910de rev=0xa2 hdr=0x00
none5@pci0:0:0:5: class=0x050000 card=0x0d04105b chip=0x02ff10de rev=0xa2 hdr=0x00
none6@pci0:0:0:6: class=0x050000 card=0x0d04105b chip=0x027f10de rev=0xa2 hdr=0x00
none7@pci0:0:0:7: class=0x050000 card=0x0d04105b chip=0x027e10de rev=0xa2 hdr=0x00
pcib1@pci0:0:2:0: class=0x060400 card=0x000010de chip=0x02fc10de rev=0xa1 hdr=0x01
pcib2@pci0:0:3:0: class=0x060400 card=0x000010de chip=0x02fd10de rev=0xa1 hdr=0x01
pcib3@pci0:0:4:0: class=0x060400 card=0x000010de chip=0x02fb10de rev=0xa1 hdr=0x01
vgapci0@pci0:0:5:0:  class=0x030000 card=0x0d04105b chip=0x024010de rev=0xa2 hdr=0x00
none8@pci0:0:9:0: class=0x050000 card=0x0d04105b chip=0x027010de rev=0xa2 hdr=0x00
isab0@pci0:0:10:0:   class=0x060100 card=0x0d04105b chip=0x026010de rev=0xa2 hdr=0x00
none9@pci0:0:10:1:   class=0x0c0500 card=0x0d04105b chip=0x026410de rev=0xa2 hdr=0x00
none10@pci0:0:10:2:  class=0x050000 card=0x0d04105b chip=0x027210de rev=0xa2 hdr=0x00
ohci0@pci0:0:11:0:   class=0x0c0310 card=0x0d04105b chip=0x026d10de rev=0xa2 hdr=0x00
ehci0@pci0:0:11:1:   class=0x0c0320 card=0x0d04105b chip=0x026e10de rev=0xa2 hdr=0x00
atapci0@pci0:0:13:0: class=0x01018a card=0x0d04105b chip=0x026510de rev=0xa1 hdr=0x00
atapci1@pci0:0:14:0: class=0x010185 card=0x0d04105b chip=0x026610de rev=0xa1 hdr=0x00
atapci2@pci0:0:15:0: class=0x010185 card=0x0d04105b chip=0x026710de rev=0xa1 hdr=0x00
pcib4@pci0:0:16:0:   class=0x060401 card=0x00000000 chip=0x026f10de rev=0xa2 hdr=0x01
none11@pci0:0:16:2:  class=0x040100 card=0x0d04105b chip=0x026b10de rev=0xa2 hdr=0x00
nfe0@pci0:0:20:0: class=0x068000 card=0x0d04105b chip=0x026910de rev=0xa1 hdr=0x00
hostb0@pci0:0:24:0:  class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00
hostb1@pci0:0:24:1:  class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00
hostb2@pci0:0:24:2:  class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00
hostb3@pci0:0:24:3:  class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00
ahc0@pci0:4:7:0:  class=0x010000 card=0x78509004 chip=0x50789004 rev=0x03 hdr=0x00
--- pciconf ends here ---
How-To-Repeat: Although I can consistently repeat the problem by just plugging in
the camera I appreciate this will be dificult to diagnose without
having the same or similar model camera. Please let me know if there
are any further diagnostics I can run to provide more information,
I would be happy to apply any suggested experimental patches if this
would help
Comment 1 Volker Werth freebsd_committer 2008-12-31 12:33:31 UTC
State Changed
From-To: open->feedback

the backtrace is of no use as the fault occurs in a loaded module. 
Please use asf(8) output to load the modules into kgdb and send us  
a more useful backtrace. Thank you very much for your effort!
Comment 2 Volker Werth freebsd_committer 2008-12-31 16:12:45 UTC
Responsible Changed
From-To: freebsd-usb->vwe

I'm wondering if you can put the core dump somewhere for downloading?
Comment 3 mike 2009-01-05 12:49:06 UTC
I tried using asf but, apart from a few lines confirming that the symbol 
tables had been loaded for acpi.ko and linux.ko, there was no 
difference. The backtrace was just the same as before.

I've got hardly any experience of using kgdb and this is the first time 
I've needed to submit a PR so it might be that I've done something 
stupid in the process so here's an outline of the steps I took.

kldstat confirmed that the only modules loaded are kernel, acpi.ko and 

I ran ...

asf -N /boot/kernel/kernel -M /var/crash/vmcore.0 -s /boot/kernel

... which produced the following in /root/.asf:

add-symbol-file /boot/kernel/acpi.ko.symbols 0xc0db4350 -s .data 
0xc0df5000 -s .bss 0xc0df73a0
add-symbol-file /boot/kernel/linux.ko.symbols 0xc55a9080 -s .data 
0xc55bf080 -s .bss 0xc55c16e0

Then I ran ...

kgdb /boot/kernel/kernel /var/crash/vmcore.2

... with the following commands:

source /root/.asf

Since then I've disabled linux and acpi to eliminate them from adding 
any confusion to the problem and I still get the panics.

I can upload a copy of the latest core dump to my webspace. It's rather 
big to upload in the daytime so I'll schedule it for tonight. I'll 
email you with the URL when it's ready. Do you need any other files to 
go with the dump?

Mike Clarke
Comment 4 Mike Clarke 2009-02-06 12:02:13 UTC
Just wondering if you managed to access the core dump? I emailed the url 
direct to vwe a while ago but I don't remember seeing any accesses in 
the server logs.

Mike Clarke
Comment 5 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:29 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped