System freeze when accessing st.ko and /dev/st0

DISCUSSION Phil Carinhas 3 participants 5 messages Feb 6, 2004

Subsystems (3)

SCSI SCSI SG driver SCSI tape driver

lore

Share & tools

lore

Phil Carinhas

author

2004-02-06 19:42 UTC #0 lore raw

System Freeze

When I tried to access the tape drive via 'tar tvfz /dev/st0' the system froze: Here is the call trace:

-------- CALL TRACE from /var/log/messages

Feb  6 12:25:48 taren kernel: st: Version 20031228, fixed bufsize 32768, s/g segs 256
Feb  6 12:25:48 taren kernel: Attached scsi tape st0 at scsi1, channel 0, id 6, lun 0
Feb  6 12:25:48 taren kernel: st0: try direct i/o: yes, max page reachable by HBA268435455
Feb  6 12:32:22 taren kernel: st: Unloaded.
Feb  6 12:32:46 taren kernel: Badness in kobject_get at lib/kobject.c:431
Feb  6 12:32:46 taren kernel: Call Trace:
Feb  6 12:32:46 taren kernel:  [<c0274e50>] kobject_get+0x50/0x60
Feb  6 12:32:46 taren kernel:  [<c015c0c9>] cdev_get+0x39/0x80
Feb  6 12:32:46 taren kernel:  [<c015bf9f>] exact_lock+0xf/0x20
Feb  6 12:32:46 taren kernel:  [<c029a135>] kobj_lookup+0xf5/0x1a0
Feb  6 12:32:46 taren kernel:  [<c015bf80>] exact_match+0x0/0x10
Feb  6 12:32:46 taren kernel:  [<c015be73>] chrdev_open+0x143/0x1c0
Feb  6 12:32:46 taren kernel:  [<c0151c70>] dentry_open+0x130/0x1e0
Feb  6 12:32:46 taren kernel:  [<c0151b38>] filp_open+0x68/0x70
Feb  6 12:32:46 taren kernel:  [<c0151f8b>] sys_open+0x5b/0x90
Feb  6 12:32:46 taren kernel:  [<c01090af>] syscall_call+0x7/0xb
Feb  6 12:32:46 taren kernel: 
Feb  6 12:32:46 taren kernel:  printing eip:
Feb  6 12:32:46 taren kernel: c015beda
Feb  6 12:32:46 taren kernel: Oops: 0002 [#1]
Feb  6 12:32:46 taren kernel: CPU:    1
Feb  6 12:32:46 taren kernel: EIP:    0060:[<c015beda>]    Not tainted
Feb  6 12:32:46 taren kernel: EFLAGS: 00010246
Feb  6 12:32:46 taren kernel: EIP is at chrdev_open+0x1aa/0x1c0
Feb  6 12:32:46 taren kernel: eax: 00000000   ebx: e7b57120   ecx: e7b5715c   edx: f713bd2c
Feb  6 12:32:46 taren kernel: esi: 00000000   edi: 00000000   ebp: f713bc10   esp: d29bbf20
Feb  6 12:32:46 taren kernel: ds: 007b   es: 007b   ss: 0068
Feb  6 12:32:46 taren kernel: Process mt (pid: 5807, threadinfo=d29ba000 task=d6fb6670)
Feb  6 12:32:46 taren kernel: Stack: f7fe2c00 00900000 d29bbf2c 00000000 dccb73a0f713bc10 ffffffe9 f7fe6760 
Feb  6 12:32:46 taren kernel:        c0151c70 f713bc10 dccb73a0 00000000 bffffdc4ef414000 d29ba000 c0151b38 
Feb  6 12:32:46 taren kernel:        f714eb60 f7fe6760 00000000 d29bbf70 f714eb60f7fe6760 fffffff4 ef414000 
Feb  6 12:32:46 taren kernel: Call Trace:
Feb  6 12:32:46 taren kernel:  [<c0151c70>] dentry_open+0x130/0x1e0
Feb  6 12:32:46 taren kernel:  [<c0151b38>] filp_open+0x68/0x70
Feb  6 12:32:46 taren kernel:  [<c0151f8b>] sys_open+0x5b/0x90
Feb  6 12:32:46 taren kernel:  [<c01090af>] syscall_call+0x7/0xb
Feb  6 12:32:46 taren kernel: 
Feb  6 12:32:46 taren kernel: Code: 89 50 04 89 4a 04 e9 87 fe ff ff 8d 74 26 00 8d bc 27 00 00

Here are system specs:
PIII Copermine dual cpu
Both Megaraid and sym53c compiled monolithic.
st is the only module on the system.

====
cat /proc/scsi/scsi
Attached devices:
Host: scsi1 Channel: 00 Id: 06 Lun: 00
Vendor: HP Model: C1537A Rev: L907
Type: Sequential-Access ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 00 Lun: 00
Vendor: MegaRAID Model: LD0 RAID1 17500R Rev: F
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 01 Lun: 00
Vendor: MegaRAID Model: LD1 RAID1 8677R Rev: F
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi2 Channel: 04 Id: 05 Lun: 00
Vendor: HP Model: SAFTE; U160/M BP Rev: 1020
Type: Processor ANSI SCSI revision: 02
====
cat /proc/scsi/sym53c8xx/*
Chip sym53c896, device id 0xb, revision id 0x6 At PCI address 0000:02:06.0, IRQ 24
Min. period factor 10, Wide SCSI BUS
Max. started commands 510, max. commands per LUN 64 Chip sym53c896, device id 0xb, revision id 0x6 At PCI address 0000:02:06.1, IRQ 25
Min. period factor 10, Wide SCSI BUS
Max. started commands 510, max. commands per LUN 64

========
Question: will compiling st into the kernel monolithically change this result?

If possible, please reply to my email address below. If not, thanks for looking at this.

-Phil Carinhas
--
.--------------------------------------------------------.

 | Dr. Philip A. Carinhas       | pac(at)fortuitous.com   |
 | Fortuitous Technologies Inc. | http://fortuitous.com   |
 | Linux Consulting & Training  | Tel : 1-512-218-9561    |

`--------------------------------------------------------'

Brian King

2004-02-06 20:09 UTC #1 lore raw

I have been debugging this same problem in sg today. It appears as if kobj_unmap is never getting called when a device is deleted. When I added a call to kobj_unmap, the problem went away. I'm currently working on a patch for this.

-Brian

Quoted 89 lines · Phil Carinhas

System Freeze
When I tried to access the tape drive via 'tar tvfz /dev/st0' the system froze: Here is the call trace:
-------- CALL TRACE from /var/log/messages
Feb  6 12:25:48 taren kernel: st: Version 20031228, fixed bufsize 32768, s/g segs 256
Feb  6 12:25:48 taren kernel: Attached scsi tape st0 at scsi1, channel 0, id 6, lun 0
Feb  6 12:25:48 taren kernel: st0: try direct i/o: yes, max page reachable by HBA268435455
Feb  6 12:32:22 taren kernel: st: Unloaded.
Feb  6 12:32:46 taren kernel: Badness in kobject_get at lib/kobject.c:431
Feb  6 12:32:46 taren kernel: Call Trace:
Feb  6 12:32:46 taren kernel:  [<c0274e50>] kobject_get+0x50/0x60
Feb  6 12:32:46 taren kernel:  [<c015c0c9>] cdev_get+0x39/0x80
Feb  6 12:32:46 taren kernel:  [<c015bf9f>] exact_lock+0xf/0x20
Feb  6 12:32:46 taren kernel:  [<c029a135>] kobj_lookup+0xf5/0x1a0
Feb  6 12:32:46 taren kernel:  [<c015bf80>] exact_match+0x0/0x10
Feb  6 12:32:46 taren kernel:  [<c015be73>] chrdev_open+0x143/0x1c0
Feb  6 12:32:46 taren kernel:  [<c0151c70>] dentry_open+0x130/0x1e0
Feb  6 12:32:46 taren kernel:  [<c0151b38>] filp_open+0x68/0x70
Feb  6 12:32:46 taren kernel:  [<c0151f8b>] sys_open+0x5b/0x90
Feb  6 12:32:46 taren kernel:  [<c01090af>] syscall_call+0x7/0xb
Feb  6 12:32:46 taren kernel: Feb  6 12:32:46 taren kernel:  printing eip:
Feb  6 12:32:46 taren kernel: c015beda
Feb  6 12:32:46 taren kernel: Oops: 0002 [#1]
Feb  6 12:32:46 taren kernel: CPU:    1
Feb  6 12:32:46 taren kernel: EIP:    0060:[<c015beda>]    Not tainted
Feb  6 12:32:46 taren kernel: EFLAGS: 00010246
Feb  6 12:32:46 taren kernel: EIP is at chrdev_open+0x1aa/0x1c0
Feb  6 12:32:46 taren kernel: eax: 00000000   ebx: e7b57120   ecx: e7b5715c   edx: f713bd2c
Feb  6 12:32:46 taren kernel: esi: 00000000   edi: 00000000   ebp: f713bc10   esp: d29bbf20
Feb  6 12:32:46 taren kernel: ds: 007b   es: 007b   ss: 0068
Feb  6 12:32:46 taren kernel: Process mt (pid: 5807, threadinfo=d29ba000 task=d6fb6670)
Feb  6 12:32:46 taren kernel: Stack: f7fe2c00 00900000 d29bbf2c 00000000 dccb73a0f713bc10 ffffffe9 f7fe6760 Feb  6 12:32:46 taren kernel:        c0151c70 f713bc10 dccb73a0 00000000 bffffdc4ef414000 d29ba000 c0151b38 Feb  6 12:32:46 taren kernel:        f714eb60 f7fe6760 00000000 d29bbf70 f714eb60f7fe6760 fffffff4 ef414000 Feb  6 12:32:46 taren kernel: Call Trace:
Feb  6 12:32:46 taren kernel:  [<c0151c70>] dentry_open+0x130/0x1e0
Feb  6 12:32:46 taren kernel:  [<c0151b38>] filp_open+0x68/0x70
Feb  6 12:32:46 taren kernel:  [<c0151f8b>] sys_open+0x5b/0x90
Feb  6 12:32:46 taren kernel:  [<c01090af>] syscall_call+0x7/0xb
Feb  6 12:32:46 taren kernel: Feb  6 12:32:46 taren kernel: Code: 89 50 04 89 4a 04 e9 87 fe ff ff 8d 74 26 00 8d bc 27 00 00 
Here are system specs:
PIII Copermine dual cpu
Both Megaraid and sym53c compiled monolithic.
st is the only module on the system.
====
cat /proc/scsi/scsi Attached devices:
Host: scsi1 Channel: 00 Id: 06 Lun: 00
Vendor: HP Model: C1537A Rev: L907
Type: Sequential-Access ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 00 Lun: 00
Vendor: MegaRAID Model: LD0 RAID1 17500R Rev: F
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 01 Lun: 00
Vendor: MegaRAID Model: LD1 RAID1 8677R Rev: F
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi2 Channel: 04 Id: 05 Lun: 00
Vendor: HP Model: SAFTE; U160/M BP Rev: 1020
Type: Processor ANSI SCSI revision: 02
====
cat /proc/scsi/sym53c8xx/*
Chip sym53c896, device id 0xb, revision id 0x6 At PCI address 0000:02:06.0, IRQ 24
Min. period factor 10, Wide SCSI BUS
Max. started commands 510, max. commands per LUN 64 Chip sym53c896, device id 0xb, revision id 0x6 At PCI address 0000:02:06.1, IRQ 25
Min. period factor 10, Wide SCSI BUS
Max. started commands 510, max. commands per LUN 64
========
Question: will compiling st into the kernel monolithically change this result?
If possible, please reply to my email address below. If not, thanks for looking at this.
(quoted diff) +0 -3
-Phil Carinhas
--
 .--------------------------------------------------------.
 | Dr. Philip A. Carinhas       | pac(at)fortuitous.com   |
 | Fortuitous Technologies Inc. | http://fortuitous.com   |
 | Linux Consulting & Training  | Tel : 1-512-218-9561    |
 `--------------------------------------------------------'
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 3 lines

Brian King
eServer Storage I/O
IBM Linux Technology Center

Mike Anderson

2004-02-06 20:23 UTC #2 lore raw

Quoted 6 lines · Brian King [[email protected]] wrote:

I have been debugging this same problem in sg today. It appears as if kobj_unmap is never getting called when a device is deleted. When I added a call to kobj_unmap, the problem went away. I'm currently working on a patch for this.
-Brian

Are you indicating that we need a direct call to kobj_unmap along with the call to cdev_unmap?

-andmike
--
Michael Anderson
[email protected]

Brian King

2004-02-06 20:47 UTC #3 lore raw

Quoted 7 lines · Mike Anderson

Quoted 5 lines · Brian King [[email protected]] wrote:
I have been debugging this same problem in sg today. It appears as if kobj_unmap is never getting called when a device is deleted. When I added a call to kobj_unmap, the problem went away. I'm currently working on a patch for this.

Quoted 5 lines

Quoted 1 line
-Brian
Are you indicating that we need a direct call to kobj_unmap along with the call to cdev_unmap?

No. We just need a call to cdev_unmap, which isn't getting done. The attached patch should fix this for both sg and st. I have tested both and it works for me. Phil, can you please apply and let me know if it fixes your problem? It should apply against 2.6.2.

Thanks

Signature · 3 lines

Brian King
eServer Storage I/O
IBM Linux Technology Center

drivers/scsi/sg.c +1 -0

diff -Naur linux-2.6.2/drivers/scsi/sg.c linux-2.6.2-cdev_unmap/drivers/scsi/sg.c
@@ -1513,6 +1513,7 @@
 	if (sdp) {
 		sysfs_remove_link(&scsidp->sdev_gendev.kobj, "generic");
 		sysfs_remove_link(&sdp->cdev->kobj, "device");
+		cdev_unmap(MKDEV(SCSI_GENERIC_MAJOR, sdp->disk->first_minor), 1);
 		cdev_del(sdp->cdev);
 		sdp->cdev = NULL;
 		devfs_remove("%s/generic", scsidp->devfs_name);

drivers/scsi/st.c +1 -0

diff -Naur linux-2.6.2/drivers/scsi/st.c linux-2.6.2-cdev_unmap/drivers/scsi/st.c
@@ -3964,6 +3964,7 @@
 				for (j=0; j < 2; j++) {
 					sysfs_remove_link(&tpnt->modes[mode].cdevs[j]->kobj,
 							  "device");
+					cdev_unmap(MKDEV(SCSI_TAPE_MAJOR, TAPE_MINOR(i, mode, j)), 1);
 					cdev_del(tpnt->modes[mode].cdevs[j]);
 					tpnt->modes[mode].cdevs[j] = NULL;
 				}

Brian King

2004-02-06 20:54 UTC #4 lore raw

Quoted 9 lines · Brian King

Quoted 7 lines · Mike Anderson
Quoted 5 lines · Brian King [[email protected]] wrote:
I have been debugging this same problem in sg today. It appears as if kobj_unmap is never getting called when a device is deleted. When I added a call to kobj_unmap, the problem went away. I'm currently working on a patch for this.

Quoted 6 lines

Quoted 6 lines
Quoted 1 line
-Brian
Are you indicating that we need a direct call to kobj_unmap along with the call to cdev_unmap?

Sorry. I just realized this was already reported and fixed. Just hasn't made it into the mainline...

Signature · 3 lines

Brian King
eServer Storage I/O
IBM Linux Technology Center