Skip to contentSkip to conversation

blacklist a device in usb-storage

PATCH Pete Zaitcev 3 participants 7 messages Aug 16, 2004 – Aug 17, 2004 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Pete Zaitcev

author
#1 lore raw
Quoted 8 lines · On Sat, 14 Aug 2004 21:22:20 +0300 "O.Sezer" <[email protected]> wrote:

The disk in question is VID/PID=0b86:5110 32mb JMTek/eXputer disk.
http://www.qbik.ch/usb/devices/showdev.php?id=1092 says it can never be supported through usb-storage because it claims to be usb storage compliant but is not.
[...]
If there's any other way of preventing usb-storage to take- over this disk, then tell me and despise my ignorance, Otherwise, Marcelo please apply ;)

I do not understand what the objective might be. Just do not use that thing with Linux kernel 2.4. Why do you wish "to revent usb-storage from taking over this disk"?

-- Pete

#2 lore raw
Quoted 14 lines · Pete Zaitcev
Quoted 8 lines · On Sat, 14 Aug 2004 21:22:20 +0300 "O.Sezer" <[email protected]> wrote:

The disk in question is VID/PID=0b86:5110 32mb JMTek/eXputer disk.
http://www.qbik.ch/usb/devices/showdev.php?id=1092 says it can never be supported through usb-storage because it claims to be usb storage compliant but is not.
[...]
If there's any other way of preventing usb-storage to take- over this disk, then tell me and despise my ignorance, Otherwise, Marcelo please apply ;)

Quoted 5 lines

I do not understand what the objective might be. Just do not use that thing with Linux kernel 2.4. Why do you wish "to revent usb-storage from taking over this disk"?

-- Pete

As I said above, I cannot prevent accidentals (VID/PIDs aren't printed on the disk, yo know...) And usb-storage must not deal with disks that it cannot deal with:
1. This particular disk can lead to panics as I said.
2. If someone ever writes a driver specific to this device (I know it's less than highly unlikely), than it would be also useful in that case if the disk isn't tried to be owned by usb-storage. That, I think applies as a general case, too.

Ozkan Sezer

author
#3 lore raw
Quoted 4 lines · On Mon, 16 Aug 2004 10:48:12 +0300 "O.Sezer" <[email protected]> wrote:
Quoted 3 lines

I do not understand what the objective might be. Just do not use that thing with Linux kernel 2.4. Why do you wish "to revent usb-storage from taking over this disk"?

Quoted 8 lines

As I said above, I cannot prevent accidentals (VID/PIDs aren't printed on the disk, yo know...) And usb-storage must not deal with disks that it cannot deal with:
1. This particular disk can lead to panics as I said.
2. If someone ever writes a driver specific to this device (I know it's less than highly unlikely), than it would be also useful in that case if the disk isn't tried to be owned by usb-storage. That, I think applies as a general case, too.

The #2 only makes sense when such driver appears.

As for #1, why don't you post the dmesg from your "panic".

-- Pete

#4 lore raw

Pete Zaitcev wrote:
[...]

Quoted 15 lines
Quoted 5 lines
Quoted 3 lines

I do not understand what the objective might be. Just do not use that thing with Linux kernel 2.4. Why do you wish "to revent usb-storage from taking over this disk"?

Quoted 8 lines

As I said above, I cannot prevent accidentals (VID/PIDs aren't printed on the disk, yo know...) And usb-storage must not deal with disks that it cannot deal with:
1. This particular disk can lead to panics as I said.
2. If someone ever writes a driver specific to this device (I know it's less than highly unlikely), than it would be also useful in that case if the disk isn't tried to be owned by usb-storage. That, I think applies as a general case, too.

Quoted 1 line

The #2 only makes sense when such driver appears.

And its title: "usb-storage must not deal with disks that it cannot deal with" _also_ makes sense imho.

Quoted 1 line

As for #1, why don't you post the dmesg from your "panic".

Here's the panic (hand copied from the screen) + the ksymoops' report:

ksymoops 2.4.9 on i686 2.4.27-acx2. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.27-acx2 (specified)
-m /boot/System.map-2.4.27-acx2 (default)

CPU: 0

EIP: 0010: [<e0d24da0>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: d96df164 ebx: ffffffac ecx: 00000003 edx: ffffffac
esi: 00000000 edi: dd738854 ebp: c032decc esp: c032dea8
ds: 0018 es: 0018 ss: 0018
Process swapper: (pid: 0, stackpage= c032d000)

Stack:  e0a3b9cf  dd738854  dd738854  d96df164
        c1758440  d96df164  c1617ef0  c1617ed4
        dd738854  c032defc  e0a3bde4  c1617ed4
        dd738854  c03849e8  dfeb5d84  c032df08
        e0207ee9  00000000  c1617ef0  00000001
        c1617ed4  c032df2c  e0a3be87  c1617ed4
Call Trace: [<e0a3b9cf>]  [<e0a3bde4>]  [<e0207ee9>]
        [<e0a3be87>]   [<c010a848>]  [<c010aa33>]
        [<e0ae4385>]   [<c0107150>]   [<c0105000>]
        [<c01071f4>]
Code: Bad EIP value
Quoted 6 lines
Quoted 6 lines

EIP; e0d24da0 <[sr_mod]sr_registered+22deec/22e1ac> <=====

eax; d96df164 <_end+19349420/2064e31c>
edi; dd738854 <_end+1d3a2b10/2064e31c>
ebp; c032decc <init_task_union+1ecc/2000>
esp; c032dea8 <init_task_union+1ea8/2000>

Trace; e0a3b9cf <[usb-uhci]process_interrupt+21f/260> Trace; e0a3bde4 <[usb-uhci]process_urb+254/260> Trace; e0207ee9 <_end+1fe721a5/2064e31c> Trace; e0a3be87 <[usb-uhci]uhci_interrupt+97/170> Trace; c010a848 <handle_IRQ_event+48/80> Trace; c010aa33 <do_IRQ+83/f0>
Trace; e0ae4385 <[battery]level_save.1+5ea9/10b84> Trace; c0107150 <default_idle+0/40>
Trace; c0105000 <_stext+0/0>
Trace; c01071f4 <cpu_idle+34/40>

<0>Kernel panic: Aiee, killing interrupt handler!

author
#5 lore raw
Quoted 9 lines · On Mon, 16 Aug 2004 18:54:25 +0300 "O.Sezer" <[email protected]> wrote:

EIP: 0010: [<e0d24da0>] Not tainted

Call Trace: [<e0a3b9cf>]  [<e0a3bde4>]  [<e0207ee9>]
         [<e0a3be87>]   [<c010a848>]  [<c010aa33>]
         [<e0ae4385>]   [<c0107150>]   [<c0105000>]
         [<c01071f4>]
Quoted 1 line
Quoted 1 line

EIP; e0d24da0 <[sr_mod]sr_registered+22deec/22e1ac> <=====

Quoted 8 lines

Trace; e0a3b9cf <[usb-uhci]process_interrupt+21f/260> Trace; e0a3bde4 <[usb-uhci]process_urb+254/260> Trace; e0207ee9 <_end+1fe721a5/2064e31c> Trace; e0a3be87 <[usb-uhci]uhci_interrupt+97/170> Trace; c010a848 <handle_IRQ_event+48/80> Trace; c010aa33 <do_IRQ+83/f0>
Trace; c0107150 <default_idle+0/40>
Trace; c01071f4 <cpu_idle+34/40>

Hmm. This looks fishy, because sr_registered is not a function.

Does the same happen after "echo /bin/true > /proc/sys/kernel/hotplug"? Maybe your hotplug setup yanks a module. I heard some crazy distro did that on unplug.

-- Pete

#6 lore raw

Pete Zaitcev wrote:
[...]

Quoted 13 lines
Quoted 11 lines
Quoted 1 line
Quoted 1 line

EIP; e0d24da0 <[sr_mod]sr_registered+22deec/22e1ac> <=====

Trace; e0a3b9cf <[usb-uhci]process_interrupt+21f/260> Trace; e0a3bde4 <[usb-uhci]process_urb+254/260> Trace; e0207ee9 <_end+1fe721a5/2064e31c> Trace; e0a3be87 <[usb-uhci]uhci_interrupt+97/170> Trace; c010a848 <handle_IRQ_event+48/80> Trace; c010aa33 <do_IRQ+83/f0>
Trace; c0107150 <default_idle+0/40>
Trace; c01071f4 <cpu_idle+34/40>

Quoted 1 line

Hmm. This looks fishy, because sr_registered is not a function.

Yeah it's not reliable :/ How about [snd-seq-midi].data.end (the finding if don't I don't unload any modules. After every module unload the finding changes.)

Quoted 1 line

Does the same happen after "echo /bin/true > /proc/sys/kernel/hotplug"?

Doesn't change anything:
Do the "echo /bin/true > /proc/sys/kernel/hotplug", plug the disk, manually do "/sbin/modprobe usb-storage", watch the same scene about interrupts etc, unplug the disk (this time no hotplug magic is in effect), "/sbin/modprobe -r usb-storage" and panic. I guess the device is never released from the scsi layer??? The attached file has the panic info (unreliable as before; and yes it's nvidia-tainted, but nvidia is irrelevant it happens reliably all the time).

Quoted 2 lines

Maybe your hotplug setup yanks a module. I heard some crazy distro did that on unplug.

This is Redhat-9, using hotplug-2004_04_01-4 from rawhide. I remember the very same failures when I was using Mandrake9.0, so the distro change doesn't seem to make a difference (yet).

I still strongly beleive that we need a blacklisting mechanism for crazy cases like this.

Regards,
Ozkan Sezer

ksymoops 2.4.5 on i686 2.4.27-acx2. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.27-acx2 (specified)
-m /boot/System.map-2.4.27-acx2 (default)

Warning (compare_maps): mismatch on symbol _nv000173rm , nvidia says e0f24100, /lib/modules/2.4.27-acx2/nvidia/nvidia.o says e0f23ee0. Ignoring /lib/modules/2.4.27-acx2/nvidia/nvidia.o entry

CPU: 0

EIP: 0010: [<e0f4ada0>] Tainted: P
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: db949164 ebx: ffffffac ecx: 00000003 edx: ffffffac
esi: 00000000 edi: de6a9c74 ebp: db6fbf18 esp: db6fbef4
ds: 0018 es: 0018 ss: 0018
Process swapper: (pid: 9027, stackpage= db6f6000)

Stack:  e0a3b9cf  de6a9c74  de6a9c74  db949164
        c17593c0  db949164  c1617ef0  c1617ed4
        de6a9c74  db6fbf48  e0a3bde4  c1617ed4
        de6a9c74  0000b708  c12551a0  00000286
        00000000  00000000  c1617ef0  00000001
        c1617ed4  db6fbf78  e0a3be87  c1617ed4
Call Trace: [<e0a3b9cf>]  [<e0a3bde4>]  [<e0a3be87>]
        [<c010a848>]   [<c010aa33>]
Code: Bad EIP value
Quoted 8 lines
Quoted 8 lines

EIP; e0f4ada0 <[nvidia].data.end+3e69/1016129> <=====

eax; db949164 <_end+1b5b3420/2064e31c>
ebx; ffffffac <END_OF_CODE+1e0436ac/????>
edx; ffffffac <END_OF_CODE+1e0436ac/????>
edi; de6a9c74 <_end+1e313f30/2064e31c>
ebp; db6fbf18 <_end+1b3661d4/2064e31c>
esp; db6fbef4 <_end+1b3661b0/2064e31c>

Trace; e0a3b9cf <[usb-uhci]process_interrupt+21f/260> Trace; e0a3bde4 <[usb-uhci]process_urb+254/260> Trace; e0a3be87 <[usb-uhci]uhci_interrupt+97/170> Trace; c010a848 <handle_IRQ_event+48/80> Trace; c010aa33 <do_IRQ+83/f0>

<0>Kernel panic: Aiee, killing interrupt handler!

1 warning issued. Results may not be reliable.

#7 lore raw
In reply to Pete Zaitcev

(please ignore if this is duplicate. isp problems...)

Pete Zaitcev wrote:
[...]

Quoted 15 lines
Quoted 5 lines
Quoted 3 lines

I do not understand what the objective might be. Just do not use that thing with Linux kernel 2.4. Why do you wish "to revent usb-storage from taking over this disk"?

Quoted 8 lines

As I said above, I cannot prevent accidentals (VID/PIDs aren't printed on the disk, yo know...) And usb-storage must not deal with disks that it cannot deal with:
1. This particular disk can lead to panics as I said.
2. If someone ever writes a driver specific to this device (I know it's less than highly unlikely), than it would be also useful in that case if the disk isn't tried to be owned by usb-storage. That, I think applies as a general case, too.

Quoted 1 line

The #2 only makes sense when such driver appears.

And its title: "usb-storage must not deal with disks that it cannot deal with" _also_ makes sense imho.

Quoted 1 line

As for #1, why don't you post the dmesg from your "panic".

Here's the panic (hand copied from the screen) + the ksymoops' report:

ksymoops 2.4.9 on i686 2.4.27-acx2. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.27-acx2 (specified)
-m /boot/System.map-2.4.27-acx2 (default)

CPU: 0

EIP: 0010: [<e0d24da0>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: d96df164 ebx: ffffffac ecx: 00000003 edx: ffffffac
esi: 00000000 edi: dd738854 ebp: c032decc esp: c032dea8
ds: 0018 es: 0018 ss: 0018
Process swapper: (pid: 0, stackpage= c032d000)

Stack:  e0a3b9cf  dd738854  dd738854  d96df164
        c1758440  d96df164  c1617ef0  c1617ed4
        dd738854  c032defc  e0a3bde4  c1617ed4
        dd738854  c03849e8  dfeb5d84  c032df08
        e0207ee9  00000000  c1617ef0  00000001
        c1617ed4  c032df2c  e0a3be87  c1617ed4
Call Trace: [<e0a3b9cf>]  [<e0a3bde4>]  [<e0207ee9>]
        [<e0a3be87>]   [<c010a848>]  [<c010aa33>]
        [<e0ae4385>]   [<c0107150>]   [<c0105000>]
        [<c01071f4>]
Code: Bad EIP value
Quoted 6 lines
Quoted 6 lines

EIP; e0d24da0 <[sr_mod]sr_registered+22deec/22e1ac> <=====

eax; d96df164 <_end+19349420/2064e31c>
edi; dd738854 <_end+1d3a2b10/2064e31c>
ebp; c032decc <init_task_union+1ecc/2000>
esp; c032dea8 <init_task_union+1ea8/2000>

Trace; e0a3b9cf <[usb-uhci]process_interrupt+21f/260> Trace; e0a3bde4 <[usb-uhci]process_urb+254/260> Trace; e0207ee9 <_end+1fe721a5/2064e31c> Trace; e0a3be87 <[usb-uhci]uhci_interrupt+97/170> Trace; c010a848 <handle_IRQ_event+48/80> Trace; c010aa33 <do_IRQ+83/f0>
Trace; e0ae4385 <[battery]level_save.1+5ea9/10b84> Trace; c0107150 <default_idle+0/40>
Trace; c0105000 <_stext+0/0>
Trace; c01071f4 <cpu_idle+34/40>

<0>Kernel panic: Aiee, killing interrupt handler!