Hi,
My Linux 2.6.14.2-SMP kernel has just exploded on me, after I detached my USB2 DVB USB adapter.
This is on a UP PIII 1GHz Coppermine machine. There was a storm of:
dvb-usb: bulk message failed: -19 (2/0)
messages between the disconnection and the eventual oops. Note also that the DVB device was
attached to a USB2 hub.
Cheers,
Chris
usb 5-5.4: new high speed USB device using ehci_hcd and address 21
dvb-usb: found a 'Hauppauge WinTV-NOVA-T usb2' in cold state, will try to load a firmware
dvb-usb: downloading firmware from file 'dvb-usb-nova-t-usb2-01.fw' to the 'Cypress FX2'
dvb-usb: Hauppauge WinTV-NOVA-T usb2 successfully initialized and connected.
usb 5-5.4: USB disconnect, address 21
dvb-usb: generic DVB-USB module successfully deinitialized and disconnected.
usb 5-5.4: new high speed USB device using ehci_hcd and address 22
dvb-usb: found a 'Hauppauge WinTV-NOVA-T usb2' in warm state.
dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
DVB: registering new adapter (Hauppauge WinTV-NOVA-T usb2).
dvb-usb: MAC address: 00:0d:fe:03:77:33
dib3000: Found a DiBcom 3000P.
DVB: registering frontend 0 (DiBcom 3000P/M-C DVB-T)...
dvb-usb: schedule remote query interval to 100 msecs.
dvb-usb: Hauppauge WinTV-NOVA-T usb2 successfully initialized and connected.
usb 5-5.4: USB disconnect, address 22
dvb-usb: bulk message failed: -19 (2/0)
dvb-usb: bulk message failed: -19 (2/0)
dvb-usb: Hauppauge WinTV-NOVA-T usb2 successfully deinitialized and disconnected.
dvb-usb: bulk message failed: -19 (2/0)
dvb-usb: bulk message failed: -19 (2/0)
dvb-usb: bulk message failed: -19 (2/0)
...
dvb-usb: bulk message failed: -19 (2/0)
dvb-usb: bulk message failed: -19 (2/0)
dvb-usb: bulk message failed: -19 (2/0)
Unable to handle kernel paging request at virtual address bd83b3c4
printing eip:
bd83b3c4
*pde = 00000000
Oops: 0000 [#1]
SMP
Modules linked in: dvb_usb_nova_t_usb2 dvb_usb_dibusb_common dib3000mc dib3000_common dvb_usb
dvb_core firmware_class dvb_pll snd_usb_audio snd_usb_lib snd_seq_oss snd_seq_midi
snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_event snd_seq_midi_emul mga drm ipv6
floppy snd_pcm_oss snd_mixer_oss snd_seq binfmt_misc matroxfb_maven i2c_matroxfb i2c_algo_bit loop
w83781d hwmon_vid i2c_isa eeprom ide_cd cdrom psmouse pcspkr button processor nfs nfsd exportfs
lockd parport_pc parport ehci_hcd eth1394 ohci_hcd ohci1394 ieee1394 8139too mii emu10k1_gp
gameport snd_emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_ac97_bus
snd_page_alloc snd_util_mem snd_hwdep snd soundcore i2c_i801 i2c_core uhci_hcd usbcore i8xx_tco
intel_agp agpgart sunrpc ext3 jbd
CPU: 0
EIP: 0060:[<bd83b3c4>] Not tainted VLI
EFLAGS: 00010206 (2.6.14.2)
EIP is at 0xbd83b3c4
eax: 3d373417 ebx: 3d373417 ecx: d498b0b8 edx: c0354000
esi: 00000200 edi: c1405de0 ebp: bd83b3c4 esp: c0354fb0
ds: 007b es: 007b ss: 0068
Process setiathome_4.02 (pid: 12144, threadinfo=c0354000 task=d67375a0)
Stack: c0124de2 00000002 010b8f60 00000000 c0317cc0 c0354000 c0354fc8 c0354fc8
c034007b 00000001 c0317cc8 c034dee0 00000000 c0120ab0 0000000a d647efb0
00000046 0001a952 bf80d458 c010505f
Call Trace:
[<c0124de2>] run_timer_softirq+0xe2/0x1c0
[<c0120ab0>] __do_softirq+0x80/0x100
[<c010505f>] do_softirq+0x4f/0x60
=======================
[<c01038c4>] apic_timer_interrupt+0x1c/0x24
Code: Bad EIP value.
<0>Kernel panic - not syncing: Fatal exception in interrupt
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
On Mon, Nov 14, 2005 at 09:05:29PM +0000, Chris Rankin wrote:
> Hi,
>
> My Linux 2.6.14.2-SMP kernel has just exploded on me, after I detached
> my USB2 DVB USB adapter. This is on a UP PIII 1GHz Coppermine
> machine. There was a storm of:
>
> dvb-usb: bulk message failed: -19 (2/0)
>
> messages between the disconnection and the eventual oops. Note also
> that the DVB device was attached to a USB2 hub.
Chris,
It seems as though there were messages that were still being sent to and
from your device when you disconnected it. Try to make sure that you
quit all the software that was using the device, and if possible, remove
the kernel module that the device uses before removing the device.
You're right---it probably shouldn't cause an oops, but you should
probably make sure you aren't using it before unplugging it anyways.
-David Brigada
--
David Brigada | [email protected]
--- David Brigada <[email protected]> wrote:
> It seems as though there were messages that were still being sent to and
> from your device when you disconnected it. Try to make sure that you
> quit all the software that was using the device,
I'm fairly certain that I'd shut xine down.
> and if possible, remove
> the kernel module that the device uses before removing the device.
This sounds contrary to the entire concept of hotplugging to me. And I don't think that a typical
desktop user would be happy to be told that s/he needs to become root and unload kernel modules
before s/he can unplug a USB device.
Cheers,
Chris
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Hi,
On Mon, 14 Nov 2005, Chris Rankin wrote:
> This sounds contrary to the entire concept of hotplugging to me. And I don't think that a typical
> desktop user would be happy to be told that s/he needs to become root and unload kernel modules
> before s/he can unplug a USB device.
Unfortunately the dvb-core is currently not able to handle hotplugging
while a dvb application is accessing a dvb-dev-node. This applies
for every dvb-device, not only for dvb-usb devices, but no one ever tried
to unplug a DVB PCI card while using it, yet.
Before unplugging a device, you can check if the module is removable to
make sure that really no application is currently using it. (You will get
"module in use" then).
We already thought about that problem and we think that dvbdev.c is the
correct place to start implementing that, but I don't have enough
knowledge (and time) to do that now, sorry.
regards,
Patrick.
On Tue, Nov 15, 2005 Patrick Boettcher wrote:
> On Mon, 14 Nov 2005, Chris Rankin wrote:
> >This sounds contrary to the entire concept of hotplugging to me. And I
> >don't think that a typical
> >desktop user would be happy to be told that s/he needs to become root and
> >unload kernel modules
> >before s/he can unplug a USB device.
>
> Unfortunately the dvb-core is currently not able to handle hotplugging
> while a dvb application is accessing a dvb-dev-node. This applies
> for every dvb-device, not only for dvb-usb devices, but no one ever tried
> to unplug a DVB PCI card while using it, yet.
>
> Before unplugging a device, you can check if the module is removable to
> make sure that really no application is currently using it. (You will get
> "module in use" then).
>
> We already thought about that problem and we think that dvbdev.c is the
> correct place to start implementing that, but I don't have enough
> knowledge (and time) to do that now, sorry.
I thought someone sent a patch which fixes it for the cinergyT2
recently? Wouldn't the same approach work for dvb-usb?
(But I haven't had a chance to test the cinergyT2 patch yet.)
Johannes
Hi,
On Tue, 15 Nov 2005, Johannes Stezenbach wrote:
>> Unfortunately the dvb-core is currently not able to handle hotplugging
>> while a dvb application is accessing a dvb-dev-node. This applies
>> for every dvb-device, not only for dvb-usb devices, but no one ever tried
>> to unplug a DVB PCI card while using it, yet.
>>
>> Before unplugging a device, you can check if the module is removable to
>> make sure that really no application is currently using it. (You will get
>> "module in use" then).
>>
>> We already thought about that problem and we think that dvbdev.c is the
>> correct place to start implementing that, but I don't have enough
>> knowledge (and time) to do that now, sorry.
>
> I thought someone sent a patch which fixes it for the cinergyT2
> recently? Wouldn't the same approach work for dvb-usb?
> (But I haven't had a chance to test the cinergyT2 patch yet.)
Once Deti Fliegl created that patch I had a look at it to figure out if it
can easily be adapted to dvb-usb. This is was my answer:
http://www.linuxtv.org/pipermail/linux-dvb/2005-October/005333.html
After that mail I had some private mails with Deti, but he is currently
too busy to adapt his mechanism to dvbdev.c and I'm too stupid.
The cinergy-driver handles the frontend in a different way and that's
why it is possible to fix it like Deti does it.
If I could fix it in in dvb-usb, then it would be again only fixed for a
small amount of devices. For DVB-PCMCIA-cards using the default
fe-architecture will also cause Oopses like that, when unplugging while
having the device in use. That's why, IMHO, the dvb-core should be made
hotplug-safe, not a single driver. Even worse: it's not just the
frontend-device-nodes, but also the demux-nodes (and I think the other
onces too).
best regards,
Patrick.
--
Mail: [email protected]
WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/
Patrick Boettcher wrote:
> On Tue, 15 Nov 2005, Johannes Stezenbach wrote:
> > Patrick Boettcher wrote:
> >>Unfortunately the dvb-core is currently not able to handle hotplugging
> >>while a dvb application is accessing a dvb-dev-node. This applies
> >>for every dvb-device, not only for dvb-usb devices, but no one ever tried
> >>to unplug a DVB PCI card while using it, yet.
> >>
> >>Before unplugging a device, you can check if the module is removable to
> >>make sure that really no application is currently using it. (You will get
> >>"module in use" then).
> >>
> >>We already thought about that problem and we think that dvbdev.c is the
> >>correct place to start implementing that, but I don't have enough
> >>knowledge (and time) to do that now, sorry.
> >
> >I thought someone sent a patch which fixes it for the cinergyT2
> >recently? Wouldn't the same approach work for dvb-usb?
> >(But I haven't had a chance to test the cinergyT2 patch yet.)
>
> Once Deti Fliegl created that patch I had a look at it to figure out if it
> can easily be adapted to dvb-usb. This is was my answer:
>
> http://www.linuxtv.org/pipermail/linux-dvb/2005-October/005333.html
>
> After that mail I had some private mails with Deti, but he is currently
> too busy to adapt his mechanism to dvbdev.c and I'm too stupid.
The advantage of keeping development stuff on the lists is that
someone else might actually write a patch to address the issue...
> The cinergy-driver handles the frontend in a different way and that's
> why it is possible to fix it like Deti does it.
>
> If I could fix it in in dvb-usb, then it would be again only fixed for a
> small amount of devices. For DVB-PCMCIA-cards using the default
> fe-architecture will also cause Oopses like that, when unplugging while
> having the device in use. That's why, IMHO, the dvb-core should be made
> hotplug-safe, not a single driver. Even worse: it's not just the
> frontend-device-nodes, but also the demux-nodes (and I think the other
> onces too).
I agree. Could you post a summary of your conversation with Deti to
linux-dvb so someone else could start working on it?
Thanks,
Johannes
On Tue, 15 Nov 2005, Johannes Stezenbach wrote:
>> If I could fix it in in dvb-usb, then it would be again only fixed for a
>> small amount of devices. For DVB-PCMCIA-cards using the default
>> fe-architecture will also cause Oopses like that, when unplugging while
>> having the device in use. That's why, IMHO, the dvb-core should be made
>> hotplug-safe, not a single driver. Even worse: it's not just the
>> frontend-device-nodes, but also the demux-nodes (and I think the other
>> onces too).
>
> I agree. Could you post a summary of your conversation with Deti to
> linux-dvb so someone else could start working on it?
Actually, that was the summary :). He said, it should be more generally
done, I suggested him to look into dvbdev.c, then he said is too busy.
In one email he explained his mechanism to me, but you can understand it
also by looking at his cinergy-patch, I think.
Patrick.