* System freeze when accessing st.ko and /dev/st0
@ 2004-02-06 19:42 Phil Carinhas
2004-02-06 20:09 ` Brian King
0 siblings, 1 reply; 5+ messages in thread
From: Phil Carinhas @ 2004-02-06 19:42 UTC (permalink / raw)
To: linux-scsi
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 |
`--------------------------------------------------------'
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: System freeze when accessing st.ko and /dev/st0
2004-02-06 19:42 System freeze when accessing st.ko and /dev/st0 Phil Carinhas
@ 2004-02-06 20:09 ` Brian King
2004-02-06 20:29 ` Mike Anderson
0 siblings, 1 reply; 5+ messages in thread
From: Brian King @ 2004-02-06 20:09 UTC (permalink / raw)
To: pac; +Cc: linux-scsi
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
Phil Carinhas wrote:
> 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 |
> `--------------------------------------------------------'
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Brian King
eServer Storage I/O
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: System freeze when accessing st.ko and /dev/st0
2004-02-06 20:09 ` Brian King
@ 2004-02-06 20:29 ` Mike Anderson
2004-02-06 20:47 ` Brian King
0 siblings, 1 reply; 5+ messages in thread
From: Mike Anderson @ 2004-02-06 20:29 UTC (permalink / raw)
To: Brian King; +Cc: pac, linux-scsi
Brian King [brking@us.ibm.com] 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
andmike@us.ibm.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: System freeze when accessing st.ko and /dev/st0
2004-02-06 20:29 ` Mike Anderson
@ 2004-02-06 20:47 ` Brian King
2004-02-06 20:54 ` Brian King
0 siblings, 1 reply; 5+ messages in thread
From: Brian King @ 2004-02-06 20:47 UTC (permalink / raw)
To: Mike Anderson; +Cc: pac, linux-scsi, James Bottomley, Kai.Makisara, dgilbert
[-- Attachment #1: Type: text/plain, Size: 755 bytes --]
Mike Anderson wrote:
> Brian King [brking@us.ibm.com] 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?
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
--
Brian King
eServer Storage I/O
IBM Linux Technology Center
[-- Attachment #2: patch-2.6.2-sg_st-cdev_unmap --]
[-- Type: text/plain, Size: 1024 bytes --]
diff -Naur linux-2.6.2/drivers/scsi/sg.c linux-2.6.2-cdev_unmap/drivers/scsi/sg.c
--- linux-2.6.2/drivers/scsi/sg.c Fri Feb 6 14:12:22 2004
+++ linux-2.6.2-cdev_unmap/drivers/scsi/sg.c Fri Feb 6 14:12:35 2004
@@ -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);
diff -Naur linux-2.6.2/drivers/scsi/st.c linux-2.6.2-cdev_unmap/drivers/scsi/st.c
--- linux-2.6.2/drivers/scsi/st.c Fri Jan 9 00:59:45 2004
+++ linux-2.6.2-cdev_unmap/drivers/scsi/st.c Fri Feb 6 14:18:57 2004
@@ -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;
}
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: System freeze when accessing st.ko and /dev/st0
2004-02-06 20:47 ` Brian King
@ 2004-02-06 20:54 ` Brian King
0 siblings, 0 replies; 5+ messages in thread
From: Brian King @ 2004-02-06 20:54 UTC (permalink / raw)
To: Brian King
Cc: Mike Anderson, pac, linux-scsi, James Bottomley, Kai.Makisara,
dgilbert
Brian King wrote:
> Mike Anderson wrote:
>
>> Brian King [brking@us.ibm.com] 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?
Sorry. I just realized this was already reported and fixed. Just hasn't made
it into the mainline...
--
Brian King
eServer Storage I/O
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-02-06 20:54 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-02-06 19:42 System freeze when accessing st.ko and /dev/st0 Phil Carinhas
2004-02-06 20:09 ` Brian King
2004-02-06 20:29 ` Mike Anderson
2004-02-06 20:47 ` Brian King
2004-02-06 20:54 ` Brian King
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox