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
Andrew Patterson wrote:
>
> I get an oops when I try to open a generic scsi device file that was attached
> 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 this
> 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_setup)
> 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=c4fe9000)
> 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=c4fe9000)
> 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>] [<c0135bf7>
> ]
> [<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? Is
> 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]
