In your message on you write:
> Andrew,
> Could you try the same test with the sg driver found in
> lk 2.4.5-ac9 . If that oopses as well, then it would seem
> that sg_detach() is not being called. [Sg_detach() is the
> callback that the mid level uses to tell the sg driver that
> a device has been detached (removed).]
>
> I tried it on my hardware with the newer sg driver (removing
> a parallel port zip drive that is accessed via the imm driver)
> and the "cat" yielded: "No such device or address" [ENXIO].
> That is what I would expect.
>
> Doug Gilbert
>
I tried the same thing using 2.4.5-ac9. It seems the oops problem has
gone away. Thanks for the fix.
Andrew
>
> Andrew Patterson wrote:
> >
> > I get an oops when I try to open a generic scsi device file that was attach
> ed
> > to a LUN that has been removed. The LUN is on a RAID box which is removed
> > using the RAID software. I then try and update the kernel data structures
> > using:
> >
> > echo "scsi remove-single-device x x x x" >/proc/scsi/scsi
> >
> > When a try an open the generic device file that used to be used to access t
> his
> > LUN, e.g.,:
> >
> > cat /dev/sg2
> >
> > I get segmentation fault and the following oops:
> >
> > ksymoops 2.3.4 on i686 2.4.5-pre1. Options used
> > -V (default)
> > -k /proc/ksyms (default)
> > -l /proc/modules (default)
> > -o /lib/modules/2.4.5-pre1/ (default)
> > -m ./System.map (specified)
> >
> > Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_set
> up)
> > n
> > ot found in System.map. Ignoring ksyms_base entry
> > Jun 5 12:29:30 lvadp kernel: Unable to handle kernel paging request at
> > virtual
> > Jun 5 12:29:30 lvadp kernel: c01f4e95
> > Jun 5 12:29:30 lvadp kernel: *pde = 00000000
> > Jun 5 12:29:30 lvadp kernel: Oops: 0000
> > Jun 5 12:29:30 lvadp kernel: CPU: 0
> > Jun 5 12:29:30 lvadp kernel: EIP: 0010:[<c01f4e95>]
> > Using defaults from ksymoops -t elf32-i386 -a i386
> > Jun 5 12:29:30 lvadp kernel: EFLAGS: 00010282
> > Jun 5 12:29:30 lvadp kernel: eax: 00c0043b ebx: 00000000 ecx: 00001502
> > ed
> > Jun 5 12:29:30 lvadp kernel: esi: 00000002 edi: c224e7e0 ebp: c688a220
> > es
> > Jun 5 12:29:30 lvadp kernel: ds: 0018 es: 0018 ss: 0018
> > Jun 5 12:29:30 lvadp kernel: Process scsitool (pid: 2610, stackpage=c4fe90
> 00)
> > Jun 5 12:29:30 lvadp kernel: Stack: 00000000 00000002 c3df3680 0028b33c
> > 0000000
> > Jun 5 12:29:30 lvadp kernel: eax: 00c0043b ebx: 00000000 ecx: 00001502
> > ed
> > Jun 5 12:29:30 lvadp kernel: esi: 00000002 edi: c224e7e0 ebp: c688a220
> > es
> > Jun 5 12:29:30 lvadp kernel: ds: 0018 es: 0018 ss: 0018
> > Jun 5 12:29:30 lvadp kernel: Process scsitool (pid: 2610, stackpage=c4fe90
> 00)
> > Jun 5 12:29:30 lvadp kernel: Stack: 00000000 00000002 c3df3680 0028b33c
> > 0000000
> > Jun 5 12:29:30 lvadp kernel: c4fe9f2c c3df3680 00000202 c021c06b
> > c224e7e
> > Jun 5 12:29:30 lvadp kernel: c7f7cec0 c3df3680 c7f7cec0 00000002
> > ffffffe
> > Jun 5 12:29:30 lvadp kernel: Call Trace: [<c0135c94>] [<c021c06b>] [<c0135
> bf7>
> > ]
> > [<c012c712>] [<c012b845>] [<c012b77e>] [<c012ba7c>]
> > Jun 5 12:29:30 lvadp kernel: [<c0106b43>]
> > Jun 5 12:29:30 lvadp kernel: Code: f6 40 70 01 0f 84 ab 00 00 00 bb 00 e0
> ff
> > ff
> > c7 44 24 10 00
> >
> > >>EIP; c01f4e95 <scsi_block_when_processing_errors+d/f8> <=====
> > Trace; c0135c94 <cached_lookup+10/54>
> > Trace; c021c06b <sg_open+7b/234>
> > Trace; c0135bf7 <permission+2b/30>
> > Trace; c012c712 <chrdev_open+3e/4c>
> > Trace; c012b845 <dentry_open+bd/154>
> > Trace; c012b77e <filp_open+52/5c>
> > Trace; c012ba7c <sys_open+38/b4>
> > Trace; c0106b43 <system_call+33/38>
> > Code; c01f4e95 <scsi_block_when_processing_errors+d/f8>
> > 00000000 <_EIP>:
> > Trace; c021c06b <sg_open+7b/234>
> > Trace; c0135bf7 <permission+2b/30>
> > Trace; c012c712 <chrdev_open+3e/4c>
> > Trace; c012b845 <dentry_open+bd/154>
> > Trace; c012b77e <filp_open+52/5c>
> > Trace; c012ba7c <sys_open+38/b4>
> > Trace; c0106b43 <system_call+33/38>
> > Code; c01f4e95 <scsi_block_when_processing_errors+d/f8>
> > 00000000 <_EIP>:
> > Code; c01f4e95 <scsi_block_when_processing_errors+d/f8> <=====
> > 0: f6 40 70 01 testb $0x1,0x70(%eax) <=====
> > Code; c01f4e99 <scsi_block_when_processing_errors+11/f8>
> > 4: 0f 84 ab 00 00 00 je b5 <_EIP+0xb5> c01f4f4a
> > <scsi_block_whe
> > n_processing_errors+c2/f8>
> > Code; c01f4e9f <scsi_block_when_processing_errors+17/f8>
> > a: bb 00 e0 ff ff mov $0xffffe000,%ebx
> > Code; c01f4ea4 <scsi_block_when_processing_errors+1c/f8>
> > f: c7 44 24 10 00 00 00 movl $0x0,0x10(%esp,1)
> > Code; c01f4eab <scsi_block_when_processing_errors+23/f8>
> > 16: 00
> >
> > 1 warning issued. Results may not be reliable.
> >
> > I am scanning all sg files to determine what devices are available, so I
> > can't use the old reliable "well just don't do that". Any ideas on how
> > I can determine if a device has been removed without getting this error? I
> s
> > it possible to fix this problem in the sg driver? The sd driver seems to
> > be able to handle this.
> >
> > Andrew
> >
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> -=
> > Andrew Patterson Voice: (970) 898-3261
> > Hewlett-Packard Email: [EMAIL PROTECTED]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
