linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH 2.4] blacklist a device in usb-storage
       [not found] <mailman.1092508141.32379.linux-kernel2news@redhat.com>
@ 2004-08-16  6:52 ` Pete Zaitcev
  2004-08-16  7:48   ` O.Sezer
  0 siblings, 1 reply; 8+ messages in thread
From: Pete Zaitcev @ 2004-08-16  6:52 UTC (permalink / raw)
  To: O.Sezer, linux-kernel, zaitcev, marcelo.tosatti

On Sat, 14 Aug 2004 21:22:20 +0300
"O.Sezer" <sezeroz@ttnet.net.tr> 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

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: [PATCH 2.4] blacklist a device in usb-storage
  2004-08-16  6:52 ` [PATCH 2.4] blacklist a device in usb-storage Pete Zaitcev
@ 2004-08-16  7:48   ` O.Sezer
  2004-08-16 15:07     ` Pete Zaitcev
  0 siblings, 1 reply; 8+ messages in thread
From: O.Sezer @ 2004-08-16  7:48 UTC (permalink / raw)
  To: Pete Zaitcev; +Cc: linux-kernel, marcelo.tosatti

Pete Zaitcev wrote:
> On Sat, 14 Aug 2004 21:22:20 +0300
> "O.Sezer" <sezeroz@ttnet.net.tr> 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

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

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: [PATCH 2.4] blacklist a device in usb-storage
  2004-08-16  7:48   ` O.Sezer
@ 2004-08-16 15:07     ` Pete Zaitcev
  2004-08-16 15:54       ` O.Sezer
  2004-08-16 16:12       ` O.Sezer
  0 siblings, 2 replies; 8+ messages in thread
From: Pete Zaitcev @ 2004-08-16 15:07 UTC (permalink / raw)
  To: O.Sezer; +Cc: linux-kernel, marcelo.tosatti, zaitcev

On Mon, 16 Aug 2004 10:48:12 +0300
"O.Sezer" <sezeroz@ttnet.net.tr> wrote:

> > 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"?

> 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

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: [PATCH 2.4] blacklist a device in usb-storage
  2004-08-16 15:07     ` Pete Zaitcev
@ 2004-08-16 15:54       ` O.Sezer
  2004-08-16 22:32         ` Pete Zaitcev
  2004-08-16 16:12       ` O.Sezer
  1 sibling, 1 reply; 8+ messages in thread
From: O.Sezer @ 2004-08-16 15:54 UTC (permalink / raw)
  To: Pete Zaitcev; +Cc: linux-kernel, marcelo.tosatti

Pete Zaitcev wrote:
[...]
>>>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"?
> 
> 
>>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.

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

> 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


 >>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!

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: [PATCH 2.4] blacklist a device in usb-storage
  2004-08-16 15:07     ` Pete Zaitcev
  2004-08-16 15:54       ` O.Sezer
@ 2004-08-16 16:12       ` O.Sezer
  1 sibling, 0 replies; 8+ messages in thread
From: O.Sezer @ 2004-08-16 16:12 UTC (permalink / raw)
  To: Pete Zaitcev; +Cc: linux-kernel, marcelo.tosatti

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

Pete Zaitcev wrote:
[...]
>>>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"?
> 
> 
>>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.

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

> 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


>>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!



^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: [PATCH 2.4] blacklist a device in usb-storage
  2004-08-16 15:54       ` O.Sezer
@ 2004-08-16 22:32         ` Pete Zaitcev
  2004-08-17 11:12           ` O.Sezer
  0 siblings, 1 reply; 8+ messages in thread
From: Pete Zaitcev @ 2004-08-16 22:32 UTC (permalink / raw)
  To: O.Sezer; +Cc: linux-kernel, marcelo.tosatti

On Mon, 16 Aug 2004 18:54:25 +0300
"O.Sezer" <sezeroz@ttnet.net.tr> wrote:

> EIP: 0010: [<e0d24da0>]  Not tainted

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

>  >>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>

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

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: [PATCH 2.4] blacklist a device in usb-storage
  2004-08-16 22:32         ` Pete Zaitcev
@ 2004-08-17 11:12           ` O.Sezer
  0 siblings, 0 replies; 8+ messages in thread
From: O.Sezer @ 2004-08-17 11:12 UTC (permalink / raw)
  To: Pete Zaitcev; +Cc: linux-kernel, marcelo.tosatti

[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]

Pete Zaitcev wrote:
[...]
>> >>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>
> 
> 
> 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.)

> 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).

 > 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

[-- Attachment #2: panic-2.log --]
[-- Type: text/plain, Size: 1761 bytes --]

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


>>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.

^ permalink raw reply	[flat|nested] 8+ messages in thread
* [PATCH 2.4] blacklist a device in usb-storage
@ 2004-08-14 18:22 O.Sezer
  0 siblings, 0 replies; 8+ messages in thread
From: O.Sezer @ 2004-08-14 18:22 UTC (permalink / raw)
  To: linux-kernel; +Cc: marcelo.tosatti, mdharm-usb

[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]

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.

I accidentally plugged this beast not remembering what a royal PITA
it is; here's the output from dmesg:

USB Mass Storage support registered.
sr0: mmc-3 profile: 0h
sr0: mmc-3 profile: 0h
usb.c: deregistering driver usb-storage
usb.c: USB disconnect on device 00:0e.1-2 address 9
sr0: mmc-3 profile: 0h
sr0: mmc-3 profile: 0h
hub.c: new USB device 00:0e.1-2, assigned address 10
usb.c: USB device 10 (vend/prod 0xb86/0x5110) is not claimed by any 
active driver.
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
scsi1 : SCSI emulation for USB Mass Storage devices
usb.c: USB disconnect on device 00:0e.1-2 address 10
sr0: mmc-3 profile: 0h
sr0: mmc-3 profile: 0h
usb-uhci.c: interrupt, status 3, frame# 999
hub.c: new USB device 00:0e.1-2, assigned address 11
scsi: device set offline - not ready or command retry failed after bus 
reset: host 1 channel 0 id 0 lun 0
WARNING: USB Mass Storage data integrity not assured
USB Mass Storage device found at 10
USB Mass Storage support registered.
scsi2 : SCSI emulation for USB Mass Storage devices
sr0: mmc-3 profile: 0h
sr0: mmc-3 profile: 0h
usb-uhci.c: interrupt, status 3, frame# 1912
usb-uhci.c: interrupt, status 3, frame# 775
usb-uhci.c: interrupt, status 3, frame# 1689
usb-uhci.c: interrupt, status 3, frame# 555
usb-uhci.c: interrupt, status 3, frame# 1470
usb-uhci.c: interrupt, status 3, frame# 335
usb-uhci.c: interrupt, status 3, frame# 1248
usb-uhci.c: interrupt, status 3, frame# 115
usb-uhci.c: interrupt, status 3, frame# 1029
usb-uhci.c: interrupt, status 3, frame# 1941

Unplug the device and try /sbin/rmmod usb-sotrage == panic ;(
So I decided to find a way of blacklisting this disk (and
maybe similar others).  Please review the attached patch.

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 ;)

Ozkan Sezer


[-- Attachment #2: 27_blacklist_usb-storage.diff --]
[-- Type: text/plain, Size: 1840 bytes --]


--- 27/drivers/usb/storage/unusual_devs.h~	2004-08-08 02:26:05.000000000 +0300
+++ 27/drivers/usb/storage/unusual_devs.h	2004-08-14 20:57:36.000000000 +0300
@@ -708,7 +708,14 @@
                 "Optio S/S4",
                 US_SC_DEVICE, US_PR_DEVICE, NULL,
                 US_FL_FIX_INQUIRY ),
-		
+
+/* eXputer  Model: Zippy Drive, lies about being USB mass storage compliant.
+   Ref.: http://www.qbik.ch/usb/devices/showdev.php?id=1092 */
+UNUSUAL_DEV(  0x0b86, 0x5110, 0x0000, 0xffff,
+		"eXputer",
+		"Zippy Drive 5000",
+		0, 0, NULL, US_BLACKLISTED_DEV ),
+
 #ifdef CONFIG_USB_STORAGE_ISD200
 UNUSUAL_DEV(  0x0bf6, 0xa001, 0x0100, 0x0110,
 		"ATI",
--- 27/drivers/usb/storage/usb.h~	2004-08-08 02:26:05.000000000 +0300
+++ 27/drivers/usb/storage/usb.h	2004-08-14 20:58:33.000000000 +0300
@@ -103,6 +103,7 @@
 #define US_FL_SCM_MULT_TARG   0x00000020 /* supports multiple targets */
 #define US_FL_FIX_INQUIRY     0x00000040 /* INQUIRY response needs fixing */
 #define US_FL_FIX_CAPACITY    0x00000080 /* READ_CAPACITY response too big */
+#define US_BLACKLISTED_DEV    0x00000200 /* Device blacklisted */
 
 #define USB_STOR_STRING_LEN 32
 
--- 27/drivers/usb/storage/usb.c~	2004-08-08 02:26:05.000000000 +0300
+++ 27/drivers/usb/storage/usb.c	2004-08-14 20:57:36.000000000 +0300
@@ -595,6 +595,14 @@
 	if (id_index <
 	    sizeof(us_unusual_dev_list) / sizeof(us_unusual_dev_list[0])) {
 		unusual_dev = &us_unusual_dev_list[id_index];
+		/* Is this thing blacklisted? */
+		if (unusual_dev->flags & US_BLACKLISTED_DEV) {
+			warn("Device (vend/prod 0x%x/0x%x) is Blacklisted and not supported by usb-storage.\n",
+				dev->descriptor.idVendor,
+				dev->descriptor.idProduct);
+			return NULL;
+		}
+
 		if (unusual_dev->vendorName)
 			US_DEBUGP("Vendor: %s\n", unusual_dev->vendorName);
 		if (unusual_dev->productName)




^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2004-08-17 11:15 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <mailman.1092508141.32379.linux-kernel2news@redhat.com>
2004-08-16  6:52 ` [PATCH 2.4] blacklist a device in usb-storage Pete Zaitcev
2004-08-16  7:48   ` O.Sezer
2004-08-16 15:07     ` Pete Zaitcev
2004-08-16 15:54       ` O.Sezer
2004-08-16 22:32         ` Pete Zaitcev
2004-08-17 11:12           ` O.Sezer
2004-08-16 16:12       ` O.Sezer
2004-08-14 18:22 O.Sezer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).