* 2.5.67: ppa driver & preempt == oops
@ 2003-04-12 15:03 Gert Vervoort
2003-04-12 18:28 ` Robert Love
2003-04-12 21:12 ` Andrew Morton
0 siblings, 2 replies; 29+ messages in thread
From: Gert Vervoort @ 2003-04-12 15:03 UTC (permalink / raw)
To: linux-kernel
ppa: Version 2.07 (for Linux 2.4.x)
ppa: Found device at ID 6, Attempting to use EPP 16 bit
ppa: Communication established with ID 6 using EPP 16 bit
scsi0 : Iomega VPI0 (ppa) interface
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023cf5c>] scsi_probe_lun+0x6c/0x200
[<c023d38b>] scsi_probe_and_add_lun+0x7b/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023cf5c>] scsi_probe_lun+0x6c/0x200
[<c023d38b>] scsi_probe_and_add_lun+0x7b/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023cf5c>] scsi_probe_lun+0x6c/0x200
[<c023d38b>] scsi_probe_and_add_lun+0x7b/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023cf5c>] scsi_probe_lun+0x6c/0x200
[<c023d38b>] scsi_probe_and_add_lun+0x7b/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023cf5c>] scsi_probe_lun+0x6c/0x200
[<c023d38b>] scsi_probe_and_add_lun+0x7b/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023cf5c>] scsi_probe_lun+0x6c/0x200
[<c023d38b>] scsi_probe_and_add_lun+0x7b/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023cf5c>] scsi_probe_lun+0x6c/0x200
[<c023d38b>] scsi_probe_and_add_lun+0x7b/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023d074>] scsi_probe_lun+0x184/0x200
[<c023d38b>] scsi_probe_and_add_lun+0x7b/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
Vendor: IOMEGA Model: ZIP 100 Rev: D.13
Type: Direct-Access ANSI SCSI revision: 02
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023c7ef>] scsi_get_evpd_page+0x7f/0x120
[<c023ce2e>] scsi_load_identifier+0x2e/0xf0
[<c023d248>] scsi_add_lun+0x158/0x220
[<c023d3b9>] scsi_probe_and_add_lun+0xa9/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0128db4>] queue_work+0x84/0xa0
[<c02402f5>] ppa_queuecommand+0x95/0xa0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c023c002>] scsi_request_fn+0x172/0x230
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023cc43>] scsi_get_serialnumber+0x93/0x1b0
[<c023c852>] scsi_get_evpd_page+0xe2/0x120
[<c023ceeb>] scsi_load_identifier+0xeb/0xf0
[<c023d248>] scsi_add_lun+0x158/0x220
[<c023d3b9>] scsi_probe_and_add_lun+0xa9/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023cf5c>] scsi_probe_lun+0x6c/0x200
[<c023d38b>] scsi_probe_and_add_lun+0x7b/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
error in initcall at 0xc0391ad0: returned with preemption imbalance
Attached scsi removable disk sda at scsi0, channel 0, id 6, lun 0
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.5.67: ppa driver & preempt == oops
2003-04-12 15:03 2.5.67: ppa driver & preempt == oops Gert Vervoort
@ 2003-04-12 18:28 ` Robert Love
2003-04-13 10:30 ` Gert Vervoort
2003-04-12 21:12 ` Andrew Morton
1 sibling, 1 reply; 29+ messages in thread
From: Robert Love @ 2003-04-12 18:28 UTC (permalink / raw)
To: Gert Vervoort; +Cc: linux-kernel
On Sat, 2003-04-12 at 11:03, Gert Vervoort wrote:
> ppa: Version 2.07 (for Linux 2.4.x)
> ppa: Found device at ID 6, Attempting to use EPP 16 bit
> ppa: Communication established with ID 6 using EPP 16 bit
I guess you don't see these without kernel preemption?
These are not errors, just warnings. Most likely you only see them when
CONFIG_PREEMPT is enabled, because otherwise the kernel cannot detect
them. But they still happen.
Does anything go wrong? Or just these errors?
It looks like one of the scsi command functions grabs a lock and then
does wait_for_completion. I have not identified what lock, yet. But
its a bug in the SCSI code if so, and unrelated to preemption.
Robert Love
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.5.67: ppa driver & preempt == oops
2003-04-12 15:03 2.5.67: ppa driver & preempt == oops Gert Vervoort
2003-04-12 18:28 ` Robert Love
@ 2003-04-12 21:12 ` Andrew Morton
2003-04-13 11:45 ` Gert Vervoort
1 sibling, 1 reply; 29+ messages in thread
From: Andrew Morton @ 2003-04-12 21:12 UTC (permalink / raw)
To: Gert Vervoort; +Cc: linux-kernel
Gert Vervoort <gert.vervoort@hccnet.nl> wrote:
>
> ppa: Version 2.07 (for Linux 2.4.x)
> ppa: Found device at ID 6, Attempting to use EPP 16 bit
> ppa: Communication established with ID 6 using EPP 16 bit
> scsi0 : Iomega VPI0 (ppa) interface
> bad: scheduling while atomic!
This patch should make the warnings go away.
I've been sitting on it for a while, waiting for someone to tell me if the
ppa driver actually works. Perhaps that person is you?
diff -puN drivers/scsi/ppa.c~ppa-null-pointer-fix drivers/scsi/ppa.c
--- 25/drivers/scsi/ppa.c~ppa-null-pointer-fix 2003-03-23 16:08:37.000000000 -0800
+++ 25-akpm/drivers/scsi/ppa.c 2003-03-23 16:09:14.000000000 -0800
@@ -219,13 +219,15 @@ int ppa_detect(Scsi_Host_Template * host
printk(" supported by the imm (ZIP Plus) driver. If the\n");
printk(" cable is marked with \"AutoDetect\", this is what has\n");
printk(" happened.\n");
- spin_lock_irq(hreg->host_lock);
+ if (hreg) /* This is silly */
+ spin_lock_irq(hreg->host_lock);
return 0;
}
try_again = 1;
goto retry_entry;
} else {
- spin_lock_irq(hreg->host_lock);
+ if (hreg) /* And this should be unnecessary */
+ spin_lock_irq(hreg->host_lock);
return 1; /* return number of hosts detected */
}
}
_
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.5.67: ppa driver & preempt == oops
2003-04-12 18:28 ` Robert Love
@ 2003-04-13 10:30 ` Gert Vervoort
2003-04-13 17:32 ` Robert Love
0 siblings, 1 reply; 29+ messages in thread
From: Gert Vervoort @ 2003-04-13 10:30 UTC (permalink / raw)
To: Robert Love; +Cc: linux-kernel
>
>
>I guess you don't see these without kernel preemption?
>
>
I've not tried that for 2.5.67, but with previous 2.5 versions I had no
problems when I disabled the ppa driver or preemption.
>These are not errors, just warnings. Most likely you only see them when
>CONFIG_PREEMPT is enabled, because otherwise the kernel cannot detect
>them. But they still happen.
>
>Does anything go wrong? Or just these errors?
>
>
With 2.5.67 it is just these messages, the system continues working.
Because of these messages I've not tried if the zip-driver functions
properly.
Gert
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.5.67: ppa driver & preempt == oops
2003-04-12 21:12 ` Andrew Morton
@ 2003-04-13 11:45 ` Gert Vervoort
2003-04-13 20:44 ` Andrew Morton
0 siblings, 1 reply; 29+ messages in thread
From: Gert Vervoort @ 2003-04-13 11:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Andrew Morton wrote:
>This patch should make the warnings go away.
>
>
The warnings are still there:
ppa: Version 2.07 (for Linux 2.4.x)
ppa: Found device at ID 6, Attempting to use EPP 16 bit
ppa: Communication established with ID 6 using EPP 16 bit
scsi0 : Iomega VPI0 (ppa) interface
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023cf5c>] scsi_probe_lun+0x6c/0x200
[<c023d38b>] scsi_probe_and_add_lun+0x7b/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023cf5c>] scsi_probe_lun+0x6c/0x200
[<c023d38b>] scsi_probe_and_add_lun+0x7b/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023cf5c>] scsi_probe_lun+0x6c/0x200
[<c023d38b>] scsi_probe_and_add_lun+0x7b/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023cf5c>] scsi_probe_lun+0x6c/0x200
[<c023d38b>] scsi_probe_and_add_lun+0x7b/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023cf5c>] scsi_probe_lun+0x6c/0x200
[<c023d38b>] scsi_probe_and_add_lun+0x7b/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023cf5c>] scsi_probe_lun+0x6c/0x200
[<c023d38b>] scsi_probe_and_add_lun+0x7b/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023cf5c>] scsi_probe_lun+0x6c/0x200
[<c023d38b>] scsi_probe_and_add_lun+0x7b/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023d074>] scsi_probe_lun+0x184/0x200
[<c023d38b>] scsi_probe_and_add_lun+0x7b/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
Vendor: IOMEGA Model: ZIP 100 Rev: D.13
Type: Direct-Access ANSI SCSI revision: 02
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023c7ef>] scsi_get_evpd_page+0x7f/0x120
[<c023ce2e>] scsi_load_identifier+0x2e/0xf0
[<c023d248>] scsi_add_lun+0x158/0x220
[<c023d3b9>] scsi_probe_and_add_lun+0xa9/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0128db4>] queue_work+0x84/0xa0
[<c0240315>] ppa_queuecommand+0x95/0xa0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c023c002>] scsi_request_fn+0x172/0x230
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023cc43>] scsi_get_serialnumber+0x93/0x1b0
[<c023c852>] scsi_get_evpd_page+0xe2/0x120
[<c023ceeb>] scsi_load_identifier+0xeb/0xf0
[<c023d248>] scsi_add_lun+0x158/0x220
[<c023d3b9>] scsi_probe_and_add_lun+0xa9/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
bad: scheduling while atomic!
Call Trace:
[<c0117064>] schedule+0x3a4/0x3b0
[<c0117349>] wait_for_completion+0x99/0xe0
[<c01170c0>] default_wake_function+0x0/0x20
[<c01170c0>] default_wake_function+0x0/0x20
[<c023b15e>] scsi_wait_req+0x7e/0xb0
[<c023b050>] scsi_wait_done+0x0/0x90
[<c023cf5c>] scsi_probe_lun+0x6c/0x200
[<c023d38b>] scsi_probe_and_add_lun+0x7b/0x130
[<c023d64c>] scsi_scan_target+0x5c/0x100
[<c023d741>] scsi_scan_host+0x51/0x90
[<c023798d>] scsi_add_host+0x4d/0x90
[<c0237dac>] scsi_register_host+0x6c/0xc0
[<c01295df>] init_workqueues+0xf/0x30
[<c01050a3>] init+0x33/0x190
[<c0105070>] init+0x0/0x190
[<c01071dd>] kernel_thread_helper+0x5/0x18
error in initcall at 0xc0391ad0: returned with preemption imbalance
Attached scsi removable disk sda at scsi0, channel 0, id 6, lun 0
>I've been sitting on it for a while, waiting for someone to tell me if the
>ppa driver actually works. Perhaps that person is you?
>
>
>
When trying to mount a zip disk, the mount process gets stuck:
[root@viper root]# mount -t ext2 /dev/sda1 /mnt/zip
SCSI device sda: 196608 512-byte hdwr sectors (101 MB)
sda: Write Protect is off
sda: cache data unavailable
sda: assuming drive cache: write through
SCSI device sda: 196608 512-byte hdwr sectors (101 MB)
sda: Write Protect is off
sda: cache data unavailable
sda: assuming drive cache: write through
At this point the mount process is unkillable.
Also strange is that the messages are printed twice.
Gert
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.5.67: ppa driver & preempt == oops
2003-04-13 10:30 ` Gert Vervoort
@ 2003-04-13 17:32 ` Robert Love
2003-04-13 17:44 ` Gert Vervoort
0 siblings, 1 reply; 29+ messages in thread
From: Robert Love @ 2003-04-13 17:32 UTC (permalink / raw)
To: Gert Vervoort; +Cc: linux-kernel
On Sun, 2003-04-13 at 06:30, Gert Vervoort wrote:
> With 2.5.67 it is just these messages, the system continues working.
> Because of these messages I've not tried if the zip-driver functions
> properly.
The bug has probably been there forever, it is just that only now we can
detect it.
So your zip drive most likely works fine.
Try the patch Andrew posted.
Robert Love
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.5.67: ppa driver & preempt == oops
2003-04-13 17:32 ` Robert Love
@ 2003-04-13 17:44 ` Gert Vervoort
2003-04-15 19:00 ` [PATCH] " Patrick Mansfield
0 siblings, 1 reply; 29+ messages in thread
From: Gert Vervoort @ 2003-04-13 17:44 UTC (permalink / raw)
To: Robert Love; +Cc: linux-kernel
Robert Love wrote:
>So your zip drive most likely works fine.
>
>
>
Doesn't look like it works, the mount process gets stuck:
[root@viper root]# mount -t ext2 /dev/sda1 /mnt/zip
SCSI device sda: 196608 512-byte hdwr sectors (101 MB)
sda: Write Protect is off
sda: cache data unavailable
sda: assuming drive cache: write through
SCSI device sda: 196608 512-byte hdwr sectors (101 MB)
sda: Write Protect is off
sda: cache data unavailable
sda: assuming drive cache: write through
At this point the mount process is unkillable.
Gert
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.5.67: ppa driver & preempt == oops
2003-04-13 11:45 ` Gert Vervoort
@ 2003-04-13 20:44 ` Andrew Morton
0 siblings, 0 replies; 29+ messages in thread
From: Andrew Morton @ 2003-04-13 20:44 UTC (permalink / raw)
To: Gert Vervoort; +Cc: linux-kernel
Gert Vervoort <gert.vervoort@hccnet.nl> wrote:
>
> Andrew Morton wrote:
>
> >This patch should make the warnings go away.
> >
> >
> The warnings are still there:
>
> ppa: Version 2.07 (for Linux 2.4.x)
> ppa: Found device at ID 6, Attempting to use EPP 16 bit
> ppa: Communication established with ID 6 using EPP 16 bit
> scsi0 : Iomega VPI0 (ppa) interface
> bad: scheduling while atomic!
> Call Trace:
> [<c0117064>] schedule+0x3a4/0x3b0
> [<c0117349>] wait_for_completion+0x99/0xe0
OK, that seems to be a different bug. The patch actually fixes
a null pointer deref.
> error in initcall at 0xc0391ad0: returned with preemption imbalance
ick.
> When trying to mount a zip disk, the mount process gets stuck:
>
> [root@viper root]# mount -t ext2 /dev/sda1 /mnt/zip
> SCSI device sda: 196608 512-byte hdwr sectors (101 MB)
> sda: Write Protect is off
> sda: cache data unavailable
> sda: assuming drive cache: write through
> SCSI device sda: 196608 512-byte hdwr sectors (101 MB)
> sda: Write Protect is off
> sda: cache data unavailable
> sda: assuming drive cache: write through
>
> At this point the mount process is unkillable.
> Also strange is that the messages are printed twice.
The number of broken drivers in 2.5 continues to be depressing.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH] Re: 2.5.67: ppa driver & preempt == oops
2003-04-13 17:44 ` Gert Vervoort
@ 2003-04-15 19:00 ` Patrick Mansfield
2003-04-15 20:44 ` Gert Vervoort
2003-04-15 21:37 ` Robert Love
0 siblings, 2 replies; 29+ messages in thread
From: Patrick Mansfield @ 2003-04-15 19:00 UTC (permalink / raw)
To: Gert Vervoort, tconnors; +Cc: Robert Love, linux-kernel
On Sun, Apr 13, 2003 at 07:44:04PM +0200, Gert Vervoort wrote:
Here is a patch against 2.5.67, can you try it out?
I did not compile let alone run with this patch.
We never hold the host_lock while calling the detect function (unlike the
io_request_lock, see the bizzare 2.4 code), so acquiring it inside
ppa_detect is very wrong. I don't know why your scsi scan did not hang.
--- linux-2.5.67/drivers/scsi/ppa.c-orig Mon Apr 7 10:31:47 2003
+++ linux-2.5.67/drivers/scsi/ppa.c Tue Apr 15 11:54:34 2003
@@ -219,15 +219,12 @@
printk(" supported by the imm (ZIP Plus) driver. If the\n");
printk(" cable is marked with \"AutoDetect\", this is what has\n");
printk(" happened.\n");
- spin_lock_irq(hreg->host_lock);
return 0;
}
try_again = 1;
goto retry_entry;
- } else {
- spin_lock_irq(hreg->host_lock);
+ } else
return 1; /* return number of hosts detected */
- }
}
/* This is to give the ppa driver a way to modify the timings (and other
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Re: 2.5.67: ppa driver & preempt == oops
2003-04-15 19:00 ` [PATCH] " Patrick Mansfield
@ 2003-04-15 20:44 ` Gert Vervoort
2003-04-15 21:40 ` Patrick Mansfield
2003-04-15 21:37 ` Robert Love
1 sibling, 1 reply; 29+ messages in thread
From: Gert Vervoort @ 2003-04-15 20:44 UTC (permalink / raw)
To: Patrick Mansfield; +Cc: tconnors, Robert Love, linux-kernel
Patrick Mansfield wrote:
>On Sun, Apr 13, 2003 at 07:44:04PM +0200, Gert Vervoort wrote:
>
>Here is a patch against 2.5.67, can you try it out?
>
>I did not compile let alone run with this patch.
>
>
The patch compiles and the warning messages are gone now.
But, I still can't mount a zip disk.
Kernel messages after mounting a zip disk (mount -t ext2 /dev/sda1
/mnt/zip):
SCSI device sda: 196608 512-byte hdwr sectors (101 MB)
sda: Write Protect is off
sda: Mode Sense: 25 00 00 08
sda: cache data unavailable
sda: assuming drive cache: write through
SCSI device sda: 196608 512-byte hdwr sectors (101 MB)
sda: Write Protect is off
sda: Mode Sense: 25 00 00 08
sda: cache data unavailable
sda: assuming drive cache: write through
sda:
The kernel messages are showing twice, does it try to mount the zip disk
two times?
At this point the mount process is stuck:
[root@viper root]# ps -ax | grep zip
998 tty1 D 0:00 mount -t ext2 /dev/sda1 /mnt/zip
1057 tty2 S 0:00 grep zip
[gert@viper root]$
Gert
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Re: 2.5.67: ppa driver & preempt == oops
2003-04-15 19:00 ` [PATCH] " Patrick Mansfield
2003-04-15 20:44 ` Gert Vervoort
@ 2003-04-15 21:37 ` Robert Love
2003-04-15 21:51 ` Randy.Dunlap
1 sibling, 1 reply; 29+ messages in thread
From: Robert Love @ 2003-04-15 21:37 UTC (permalink / raw)
To: Patrick Mansfield; +Cc: Gert Vervoort, tconnors, linux-kernel
On Tue, 2003-04-15 at 15:00, Patrick Mansfield wrote:
> We never hold the host_lock while calling the detect function (unlike the
> io_request_lock, see the bizzare 2.4 code), so acquiring it inside
> ppa_detect is very wrong. I don't know why your scsi scan did not hang.
I do not have this device so I cannot test it, but your logic seems
correct.
This is a much nicer fix for the preempt-related issues than others
proposed, too.
Anyone out there who _can_ mount the device? Can you test this? It
ought to be merged if it works. We need to get device drivers in 2.5 up
to par..
Robert Love
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Re: 2.5.67: ppa driver & preempt == oops
2003-04-15 20:44 ` Gert Vervoort
@ 2003-04-15 21:40 ` Patrick Mansfield
2003-04-16 17:52 ` Gert Vervoort
2003-04-16 18:03 ` Gert Vervoort
0 siblings, 2 replies; 29+ messages in thread
From: Patrick Mansfield @ 2003-04-15 21:40 UTC (permalink / raw)
To: Gert Vervoort; +Cc: tconnors, Robert Love, linux-kernel, linux-scsi
On Tue, Apr 15, 2003 at 10:44:00PM +0200, Gert Vervoort wrote:
> The patch compiles and the warning messages are gone now.
> But, I still can't mount a zip disk.
>
> Kernel messages after mounting a zip disk (mount -t ext2 /dev/sda1
> /mnt/zip):
>
> SCSI device sda: 196608 512-byte hdwr sectors (101 MB)
> sda: Write Protect is off
> sda: Mode Sense: 25 00 00 08
> sda: cache data unavailable
> sda: assuming drive cache: write through
> SCSI device sda: 196608 512-byte hdwr sectors (101 MB)
> sda: Write Protect is off
> sda: Mode Sense: 25 00 00 08
> sda: cache data unavailable
> sda: assuming drive cache: write through
> sda:
>
> The kernel messages are showing twice, does it try to mount the zip disk
> two times?
It opens sd twice (AFAIK) - I think mount scans the block devices (an open
of sd) and then mounts (internal open). The code path in question is
probably via sd.c functions sd_media_changed and sd_revalidate_disk, and
the block_dev.c check_disk_change. sd_open calls check_disk_change.
This could be the same problem others are seeing with removable media
accessed via USB mass storage.
Can you dd to and from the media OK?
Can you capture output for the mount with scsi logging on?
It may or may not help track down what is happening.
If you haven't done much scsi, some scsi logging info:
Check that your .config has CONFIG_SCSI_LOGGING on.
Then do something like:
sync
sync
echo scsi log all > /proc/scsi/scsi
mount /dev/sdw1 /mnt/sdw1
echo scsi log none > /proc/scsi/scsi
umount /mnt/sdw1
Turn off syslogd if you are logging to a scsi disk (and then you need a
serial line to capture output, and all printk's have to go to the
console), and sync if you are booted off scsi before turning on logging.
In either case, you could get a flood of messages.
-- Patrick Mansfield
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Re: 2.5.67: ppa driver & preempt == oops
2003-04-15 21:37 ` Robert Love
@ 2003-04-15 21:51 ` Randy.Dunlap
2003-04-15 22:07 ` Patrick Mansfield
0 siblings, 1 reply; 29+ messages in thread
From: Randy.Dunlap @ 2003-04-15 21:51 UTC (permalink / raw)
To: Robert Love; +Cc: patmans, gert.vervoort, tconnors, linux-kernel
On 15 Apr 2003 17:37:56 -0400 Robert Love <rml@tech9.net> wrote:
| On Tue, 2003-04-15 at 15:00, Patrick Mansfield wrote:
|
| > We never hold the host_lock while calling the detect function (unlike the
| > io_request_lock, see the bizzare 2.4 code), so acquiring it inside
| > ppa_detect is very wrong. I don't know why your scsi scan did not hang.
|
| I do not have this device so I cannot test it, but your logic seems
| correct.
|
| This is a much nicer fix for the preempt-related issues than others
| proposed, too.
|
| Anyone out there who _can_ mount the device? Can you test this? It
| ought to be merged if it works. We need to get device drivers in 2.5 up
| to par..
I have such a device at home. I can try to test it (if the device
still works). What needs to be tested?
or maybe I can loan it to patmans for 1 day...
--
~Randy
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Re: 2.5.67: ppa driver & preempt == oops
2003-04-15 21:51 ` Randy.Dunlap
@ 2003-04-15 22:07 ` Patrick Mansfield
2003-04-15 22:29 ` Randy.Dunlap
0 siblings, 1 reply; 29+ messages in thread
From: Patrick Mansfield @ 2003-04-15 22:07 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: Robert Love, gert.vervoort, tconnors, linux-kernel
On Tue, Apr 15, 2003 at 02:51:55PM -0700, Randy.Dunlap wrote:
> I have such a device at home. I can try to test it (if the device
> still works). What needs to be tested?
That would be nice.
AFAIK just attach and mount it, and probably dd to/from it, and then post
your fix :)
I think any removable scsi (direct access, not cdrom) media might show a
problem (see recent "USB Mass Storage Device" thread from Jim Beam).
> or maybe I can loan it to patmans for 1 day...
I don't have a machine (that I know will boot current 2.5) with a parallel
port.
I/we should get some removable media attached to one of our scsi systems
we have here (maybe usb storage).
-- Patrick Mansfield
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Re: 2.5.67: ppa driver & preempt == oops
2003-04-15 22:07 ` Patrick Mansfield
@ 2003-04-15 22:29 ` Randy.Dunlap
2003-04-15 22:35 ` Patrick Mansfield
0 siblings, 1 reply; 29+ messages in thread
From: Randy.Dunlap @ 2003-04-15 22:29 UTC (permalink / raw)
To: Patrick Mansfield; +Cc: rml, gert.vervoort, tconnors, linux-kernel
On Tue, 15 Apr 2003 15:07:46 -0700 Patrick Mansfield <patmans@us.ibm.com> wrote:
| On Tue, Apr 15, 2003 at 02:51:55PM -0700, Randy.Dunlap wrote:
|
| > I have such a device at home. I can try to test it (if the device
| > still works). What needs to be tested?
|
| That would be nice.
|
| AFAIK just attach and mount it, and probably dd to/from it, and then post
| your fix :)
So I should test (and fix) 2.5.67-k.o and PREEMPT=y ??
Any other requirements?
| I think any removable scsi (direct access, not cdrom) media might show a
| problem (see recent "USB Mass Storage Device" thread from Jim Beam).
|
| > or maybe I can loan it to patmans for 1 day...
|
| I don't have a machine (that I know will boot current 2.5) with a parallel
| port.
IBM made some like that. :)
Maybe you'll have to walk across the street tomorrow.
| I/we should get some removable media attached to one of our scsi systems
| we have here (maybe usb storage).
Yes, you should. I have Zip SCSI, Zip Plus, Zip USB, USB hard drive,
and USB/IEEE1394 hard drive.
--
~Randy
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Re: 2.5.67: ppa driver & preempt == oops
2003-04-15 22:29 ` Randy.Dunlap
@ 2003-04-15 22:35 ` Patrick Mansfield
0 siblings, 0 replies; 29+ messages in thread
From: Patrick Mansfield @ 2003-04-15 22:35 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: rml, gert.vervoort, tconnors, linux-kernel
On Tue, Apr 15, 2003 at 03:29:32PM -0700, Randy.Dunlap wrote:
> On Tue, 15 Apr 2003 15:07:46 -0700 Patrick Mansfield <patmans@us.ibm.com> wrote:
> So I should test (and fix) 2.5.67-k.o and PREEMPT=y ??
I think it's independent of preempt.
> Maybe you'll have to walk across the street tomorrow.
I can do that :)
-- Patrick Mansfield
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Re: 2.5.67: ppa driver & preempt == oops
2003-04-15 21:40 ` Patrick Mansfield
@ 2003-04-16 17:52 ` Gert Vervoort
2003-04-16 18:05 ` Patrick Mansfield
2003-04-16 18:03 ` Gert Vervoort
1 sibling, 1 reply; 29+ messages in thread
From: Gert Vervoort @ 2003-04-16 17:52 UTC (permalink / raw)
To: Patrick Mansfield; +Cc: tconnors, Robert Love, linux-kernel, linux-scsi
>
>
>
>Can you capture output for the mount with scsi logging on?
>
>It may or may not help track down what is happening.
>
>If you haven't done much scsi, some scsi logging info:
>
>Check that your .config has CONFIG_SCSI_LOGGING on.
>
>Then do something like:
>
>sync
>sync
>echo scsi log all > /proc/scsi/scsi
>mount /dev/sdw1 /mnt/sdw1
>
>
scsi logging level set to 0xffffffff
sd_open: disk=sda
scsi_block_when_processing_errors: rtn: 1
sd_media_changed: disk=sda
scsi_block_when_processing_errors: rtn: 1
scsi_block_when_processing_errors: rtn: 1
Trying ioctl with scsi command 0
Leaving scsi_init_cmd_from_req()
scsi_add_timer: scmd: c7ea4060, time: 10000, (c0239cc0)
scsi_dispatch_cmnd (host = 0, channel = 0, target = 6, command =
c7ea40b1, buffer = 00000000,
bufflen = 0, done = c023bb90)
queuecommand : routine at c02417a0
leaving scsi_dispatch_cmnd()
scsi_delete_timer: scmd: c7ea4060, rtn: 1
Command failed c7ea4060 2 busy=1 failed=0
bh?: old sense key No Sense
Non-extended sense class 0 code 0x0
Waking error handler thread
Error handler scsi_eh_0 waking up
scsi_eh_prt_fail_stats: 0:0:6:0 cmds failed: 1, cancel: 0
Total of 1 commands on 1 devices require eh work
scsi_eh_0: requesting sense for id: 6
scsi_add_timer: scmd: c7ea4060, time: 10000, (c0239f10)
scsi_eh_done scmd: c7ea4060 result: 0
scsi_send_eh_cmnd: scmd: c7ea4060, rtn:2002
scsi_send_eh_cmnd: scsi_eh_completed_normally 2002
sense requested for c7ea4060 result 2
Current bh?: sense key Unit Attention
Additional sense: Not ready to ready change, medium may have changed
scsi_eh_0: flush finish cmd: c7ea4060
Notifying upper driver of completion for device 6 8000002
scsi_restart_operations: waking up host to restart
Error handler scsi_eh_0 sleeping
Ioctl returned 0x8000002
IOCTL Releasing command
sd_init_onedisk: disk=sda
Leaving scsi_init_cmd_from_req()
scsi_add_timer: scmd: c7ea4060, time: 30000, (c0239cc0)
scsi_dispatch_cmnd (host = 0, channel = 0, target = 6, command =
c7ea40b1, buffer = c0fffe00,
bufflen = 0, done = c023bb90)
queuecommand : routine at c02417a0
leaving scsi_dispatch_cmnd()
scsi_delete_timer: scmd: c7ea4060, rtn: 1
Command finished 1 0 0x0
Notifying upper driver of completion for device 6 0
Leaving scsi_init_cmd_from_req()
scsi_add_timer: scmd: c7ea4060, time: 30000, (c0239cc0)
scsi_dispatch_cmnd (host = 0, channel = 0, target = 6, command =
c7ea40b1, buffer = c0fffe00,
bufflen = 8, done = c023bb90)
queuecommand : routine at c02417a0
leaving scsi_dispatch_cmnd()
scsi_delete_timer: scmd: c7ea4060, rtn: 1
Command finished 1 0 0x0
Notifying upper driver of completion for device 6 0
SCSI device sda: 196608 512-byte hdwr sectors (101 MB)
Leaving scsi_init_cmd_from_req()
scsi_add_timer: scmd: c7ea4060, time: 30000, (c0239cc0)
scsi_dispatch_cmnd (host = 0, channel = 0, target = 6, command =
c7ea40b1, buffer = c0fffe00,
bufflen = 4, done = c023bb90)
queuecommand : routine at c02417a0
leaving scsi_dispatch_cmnd()
scsi_delete_timer: scmd: c7ea4060, rtn: 1
Command finished 1 0 0x0
Notifying upper driver of completion for device 6 0
sda: Write Protect is off
sda: Mode Sense: 25 00 00 08
Leaving scsi_init_cmd_from_req()
scsi_add_timer: scmd: c7ea4060, time: 30000, (c0239cc0)
scsi_dispatch_cmnd (host = 0, channel = 0, target = 6, command =
c7ea40b1, buffer = c0fffe00,
bufflen = 4, done = c023bb90)
queuecommand : routine at c02417a0
leaving scsi_dispatch_cmnd()
scsi_delete_timer: scmd: c7ea4060, rtn: 1
Command failed c7ea4060 2 busy=1 failed=0
bh?: old sense key No Sense
Non-extended sense class 0 code 0x0
Waking error handler thread
Error handler scsi_eh_0 waking up
scsi_eh_prt_fail_stats: 0:0:6:0 cmds failed: 1, cancel: 0
Total of 1 commands on 1 devices require eh work
scsi_eh_0: requesting sense for id: 6
scsi_add_timer: scmd: c7ea4060, time: 10000, (c0239f10)
scsi_eh_done scmd: c7ea4060 result: 0
scsi_send_eh_cmnd: scmd: c7ea4060, rtn:2002
scsi_send_eh_cmnd: scsi_eh_completed_normally 2002
sense requested for c7ea4060 result 2
Current bh?: sense key Illegal Request
Additional sense: Invalid field in cdb
scsi_eh_0: flush finish cmd: c7ea4060
Notifying upper driver of completion for device 6 8000002
scsi_restart_operations: waking up host to restart
Error handler scsi_eh_0 sleeping
sda: cache data unavailable
sda: assuming drive cache: write through
scsi_block_when_processing_errors: rtn: 1
Trying ioctl with scsi command 30
Leaving scsi_init_cmd_from_req()
scsi_add_timer: scmd: c7ea4060, time: 10000, (c0239cc0)
scsi_dispatch_cmnd (host = 0, channel = 0, target = 6, command =
c7ea40b1, buffer = 00000000,
bufflen = 0, done = c023bb90)
queuecommand : routine at c02417a0
leaving scsi_dispatch_cmnd()
scsi_delete_timer: scmd: c7ea4060, rtn: 1
Command finished 1 0 0x0
Notifying upper driver of completion for device 6 0
Ioctl returned 0x0
IOCTL Releasing command
sd_init_onedisk: disk=sda
Leaving scsi_init_cmd_from_req()
scsi_add_timer: scmd: c7ea4060, time: 30000, (c0239cc0)
scsi_dispatch_cmnd (host = 0, channel = 0, target = 6, command =
c7ea40b1, buffer = c0fffe00,
bufflen = 0, done = c023bb90)
queuecommand : routine at c02417a0
leaving scsi_dispatch_cmnd()
scsi_delete_timer: scmd: c7ea4060, rtn: 1
Command finished 1 0 0x0
Notifying upper driver of completion for device 6 0
Leaving scsi_init_cmd_from_req()
scsi_add_timer: scmd: c7ea4060, time: 30000, (c0239cc0)
scsi_dispatch_cmnd (host = 0, channel = 0, target = 6, command =
c7ea40b1, buffer = c0fffe00,
bufflen = 8, done = c023bb90)
queuecommand : routine at c02417a0
leaving scsi_dispatch_cmnd()
scsi_delete_timer: scmd: c7ea4060, rtn: 1
Command finished 1 0 0x0
Notifying upper driver of completion for device 6 0
SCSI device sda: 196608 512-byte hdwr sectors (101 MB)
Leaving scsi_init_cmd_from_req()
scsi_add_timer: scmd: c7ea4060, time: 30000, (c0239cc0)
scsi_dispatch_cmnd (host = 0, channel = 0, target = 6, command =
c7ea40b1, buffer = c0fffe00,
bufflen = 4, done = c023bb90)
queuecommand : routine at c02417a0
leaving scsi_dispatch_cmnd()
scsi_delete_timer: scmd: c7ea4060, rtn: 1
Command finished 1 0 0x0
Notifying upper driver of completion for device 6 0
sda: Write Protect is off
sda: Mode Sense: 25 00 00 08
Leaving scsi_init_cmd_from_req()
scsi_add_timer: scmd: c7ea4060, time: 30000, (c0239cc0)
scsi_dispatch_cmnd (host = 0, channel = 0, target = 6, command =
c7ea40b1, buffer = c0fffe00,
bufflen = 4, done = c023bb90)
queuecommand : routine at c02417a0
leaving scsi_dispatch_cmnd()
scsi_delete_timer: scmd: c7ea4060, rtn: 1
Command failed c7ea4060 2 busy=1 failed=0
bh?: old sense key No Sense
Non-extended sense class 0 code 0x0
Waking error handler thread
Error handler scsi_eh_0 waking up
scsi_eh_prt_fail_stats: 0:0:6:0 cmds failed: 1, cancel: 0
Total of 1 commands on 1 devices require eh work
scsi_eh_0: requesting sense for id: 6
scsi_add_timer: scmd: c7ea4060, time: 10000, (c0239f10)
scsi_eh_done scmd: c7ea4060 result: 0
scsi_send_eh_cmnd: scmd: c7ea4060, rtn:2002
scsi_send_eh_cmnd: scsi_eh_completed_normally 2002
sense requested for c7ea4060 result 2
Current bh?: sense key Illegal Request
Additional sense: Invalid field in cdb
scsi_eh_0: flush finish cmd: c7ea4060
Notifying upper driver of completion for device 6 8000002
scsi_restart_operations: waking up host to restart
Leaving scsi_init_cmd_from_req()
scsi_add_timer: scmd: c7ea41a0, time: 10000, (c0239cc0)
scsi_dispatch_cmnd (host = 0, channel = 0, target = 6, command =
c7ea41f1, buffer = 00000000,
bufflen = 0, done = c023b0f0)
queuecommand : routine at c02417a0
leaving scsi_dispatch_cmnd()
Error handler scsi_eh_0 sleeping
sda: cache data unavailable
sda: assuming drive cache: write through
sda:scsi_delete_timer: scmd: c7ea41a0, rtn: 1
Command finished 1 0 0x0
Notifying upper driver of completion for device 6 0
Gert
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Re: 2.5.67: ppa driver & preempt == oops
2003-04-15 21:40 ` Patrick Mansfield
2003-04-16 17:52 ` Gert Vervoort
@ 2003-04-16 18:03 ` Gert Vervoort
1 sibling, 0 replies; 29+ messages in thread
From: Gert Vervoort @ 2003-04-16 18:03 UTC (permalink / raw)
To: Patrick Mansfield; +Cc: tconnors, Robert Love, linux-kernel, linux-scsi
>
>
>
>Can you dd to and from the media OK?
>
>
Same effect as mount, now dd is stuck in the "D" state, dd if=/dev/sda
of=/tmp/kw:
[root@viper root]# ps -ax |grep dd
985 tty1 D 0:00 dd if /dev/sda of /tmp/kw
1041 tty2 S 0:00 grep dd
[root@viper root]#
Gert
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Re: 2.5.67: ppa driver & preempt == oops
2003-04-16 17:52 ` Gert Vervoort
@ 2003-04-16 18:05 ` Patrick Mansfield
2003-04-16 19:45 ` Gert Vervoort
0 siblings, 1 reply; 29+ messages in thread
From: Patrick Mansfield @ 2003-04-16 18:05 UTC (permalink / raw)
To: Gert Vervoort; +Cc: tconnors, Robert Love, linux-kernel, linux-scsi
On Wed, Apr 16, 2003 at 07:52:15PM +0200, Gert Vervoort wrote:
> bh?: old sense key No Sense
> Non-extended sense class 0 code 0x0
> Waking error handler thread
> Error handler scsi_eh_0 waking up
> scsi_eh_prt_fail_stats: 0:0:6:0 cmds failed: 1, cancel: 0
> Total of 1 commands on 1 devices require eh work
> scsi_eh_0: requesting sense for id: 6
> scsi_add_timer: scmd: c7ea4060, time: 10000, (c0239f10)
> scsi_eh_done scmd: c7ea4060 result: 0
> scsi_send_eh_cmnd: scmd: c7ea4060, rtn:2002
> scsi_send_eh_cmnd: scsi_eh_completed_normally 2002
> sense requested for c7ea4060 result 2
> Current bh?: sense key Unit Attention
> Additional sense: Not ready to ready change, medium may have changed
The ppa driver did not do auto-sense, so we run the error handler
to get the sense code.
There was a missing call to scsi_queue_next_request for door locking (the
ioctl in the scsi log output, ALLOW_MEDIUM_REMOVAL value 30, or 0x1e),
Mike A posted this patch to linux-scsi in response to some debugging leg
work of Alan Stern, does this fix your problem?
Not sure if it patches clean against 2.5.67, but it's pretty simple.
DESC
The patch adds a call to scsi_queue_next_request from scsi_release_request. It
also removes a call in scsi_eh_lock_done to scsi_put_command.
scsi_release_request will do a call to scsi_put_command if needed.
EDESC
drivers/scsi/scsi.c | 2 ++
drivers/scsi/scsi_error.c | 4 ----
2 files changed, 2 insertions(+), 4 deletions(-)
diff -puN drivers/scsi/scsi.c~scsi-release-req drivers/scsi/scsi.c
--- sysfs-bleed-2.5/drivers/scsi/scsi.c~scsi-release-req Mon Apr 14 15:34:14 2003
+++ sysfs-bleed-2.5-andmike/drivers/scsi/scsi.c Mon Apr 14 15:34:14 2003
@@ -224,8 +224,10 @@ void scsi_release_request(Scsi_Request *
{
if( req->sr_command != NULL )
{
+ request_queue_t *q = req->sr_device->request_queue;
scsi_put_command(req->sr_command);
req->sr_command = NULL;
+ scsi_queue_next_request(q, NULL);
}
kfree(req);
diff -puN drivers/scsi/scsi_error.c~scsi-release-req drivers/scsi/scsi_error.c
--- sysfs-bleed-2.5/drivers/scsi/scsi_error.c~scsi-release-req Mon Apr 14 15:34:14 2003
+++ sysfs-bleed-2.5-andmike/drivers/scsi/scsi_error.c Mon Apr 14 15:34:14 2003
@@ -1334,10 +1334,6 @@ static void scsi_eh_lock_done(struct scs
{
struct scsi_request *sreq = scmd->sc_request;
- scmd->sc_request = NULL;
- sreq->sr_command = NULL;
-
- scsi_put_command(scmd);
scsi_release_request(sreq);
}
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Re: 2.5.67: ppa driver & preempt == oops
2003-04-16 18:05 ` Patrick Mansfield
@ 2003-04-16 19:45 ` Gert Vervoort
2003-04-16 20:07 ` Mike Anderson
0 siblings, 1 reply; 29+ messages in thread
From: Gert Vervoort @ 2003-04-16 19:45 UTC (permalink / raw)
To: Patrick Mansfield; +Cc: tconnors, Robert Love, linux-kernel, linux-scsi
Patrick Mansfield wrote:
>There was a missing call to scsi_queue_next_request for door locking (the
>ioctl in the scsi log output, ALLOW_MEDIUM_REMOVAL value 30, or 0x1e),
>Mike A posted this patch to linux-scsi in response to some debugging leg
>work of Alan Stern, does this fix your problem?
>
>
>
Yes, this fixes the problem. So far, the zip disk seems to work normal
(mount/umount, eject a disk, reading from disk).
>Not sure if it patches clean against 2.5.67, but it's pretty simple.
>
>
The following workaround is needed to make the patch compile (otherwise
the linker complains about scsi_queue_next_request not being defined):
--- scsi_lib.c.1 2003-04-16 21:23:37.000000000 +0200
+++ scsi_lib.c 2003-04-16 21:23:46.000000000 +0200
@@ -351,7 +351,7 @@
* permutations grows as 2**N, and if too many more special
cases
* get added, we start to get screwed.
*/
-static void scsi_queue_next_request(request_queue_t *q, struct
scsi_cmnd *cmd)
+/*static*/ void scsi_queue_next_request(request_queue_t *q, struct
scsi_cmnd *cmd)
{
struct scsi_device *sdev, *sdev2;
struct Scsi_Host *shost;
Gert
>DESC
>The patch adds a call to scsi_queue_next_request from scsi_release_request. It
>also removes a call in scsi_eh_lock_done to scsi_put_command.
>scsi_release_request will do a call to scsi_put_command if needed.
>EDESC
>
>
> drivers/scsi/scsi.c | 2 ++
> drivers/scsi/scsi_error.c | 4 ----
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
>diff -puN drivers/scsi/scsi.c~scsi-release-req drivers/scsi/scsi.c
>--- sysfs-bleed-2.5/drivers/scsi/scsi.c~scsi-release-req Mon Apr 14 15:34:14 2003
>+++ sysfs-bleed-2.5-andmike/drivers/scsi/scsi.c Mon Apr 14 15:34:14 2003
>@@ -224,8 +224,10 @@ void scsi_release_request(Scsi_Request *
> {
> if( req->sr_command != NULL )
> {
>+ request_queue_t *q = req->sr_device->request_queue;
> scsi_put_command(req->sr_command);
> req->sr_command = NULL;
>+ scsi_queue_next_request(q, NULL);
> }
>
> kfree(req);
>diff -puN drivers/scsi/scsi_error.c~scsi-release-req drivers/scsi/scsi_error.c
>--- sysfs-bleed-2.5/drivers/scsi/scsi_error.c~scsi-release-req Mon Apr 14 15:34:14 2003
>+++ sysfs-bleed-2.5-andmike/drivers/scsi/scsi_error.c Mon Apr 14 15:34:14 2003
>@@ -1334,10 +1334,6 @@ static void scsi_eh_lock_done(struct scs
> {
> struct scsi_request *sreq = scmd->sc_request;
>
>- scmd->sc_request = NULL;
>- sreq->sr_command = NULL;
>-
>- scsi_put_command(scmd);
> scsi_release_request(sreq);
> }
>
>.
>
>
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Re: 2.5.67: ppa driver & preempt == oops
2003-04-16 19:45 ` Gert Vervoort
@ 2003-04-16 20:07 ` Mike Anderson
0 siblings, 0 replies; 29+ messages in thread
From: Mike Anderson @ 2003-04-16 20:07 UTC (permalink / raw)
To: Gert Vervoort
Cc: Patrick Mansfield, tconnors, Robert Love, linux-kernel, linux-scsi
Gert Vervoort [gert.vervoort@hccnet.nl] wrote:
> The following workaround is needed to make the patch compile (otherwise
> the linker complains about scsi_queue_next_request not being defined):
>
> --- scsi_lib.c.1 2003-04-16 21:23:37.000000000 +0200
> +++ scsi_lib.c 2003-04-16 21:23:46.000000000 +0200
> @@ -351,7 +351,7 @@
> * permutations grows as 2**N, and if too many more special
> cases
> * get added, we start to get screwed.
> */
> -static void scsi_queue_next_request(request_queue_t *q, struct
> scsi_cmnd *cmd)
> +/*static*/ void scsi_queue_next_request(request_queue_t *q, struct
> scsi_cmnd *cmd)
> {
> struct scsi_device *sdev, *sdev2;
> struct Scsi_Host *shost;
The static removal is present already in bk current.
-andmike
--
Michael Anderson
andmike@us.ibm.com
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Re: 2.5.67: ppa driver & preempt == oops
[not found] ` <fa.i9on98t.1gg0toj@ifi.uio.no>
@ 2003-04-17 19:37 ` walt
0 siblings, 0 replies; 29+ messages in thread
From: walt @ 2003-04-17 19:37 UTC (permalink / raw)
To: linux-kernel
Patrick Mansfield wrote:
> ...There was a missing call to scsi_queue_next_request for door locking (the
> ioctl in the scsi log output, ALLOW_MEDIUM_REMOVAL value 30, or 0x1e),
> Mike A posted this patch to linux-scsi in response to some debugging leg
> work of Alan Stern, does this fix your problem?
>
> Not sure if it patches clean against 2.5.67, but it's pretty simple.
>
> DESC
> The patch adds a call to scsi_queue_next_request from scsi_release_request. It
> also removes a call in scsi_eh_lock_done to scsi_put_command.
> scsi_release_request will do a call to scsi_put_command if needed.
> EDESC
>
>
> drivers/scsi/scsi.c | 2 ++
> drivers/scsi/scsi_error.c | 4 ----
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff -puN drivers/scsi/scsi.c~scsi-release-req drivers/scsi/scsi.c
> --- sysfs-bleed-2.5/drivers/scsi/scsi.c~scsi-release-req Mon Apr 14 15:34:14 2003
> +++ sysfs-bleed-2.5-andmike/drivers/scsi/scsi.c Mon Apr 14 15:34:14 2003
> @@ -224,8 +224,10 @@ void scsi_release_request(Scsi_Request *
> {
> if( req->sr_command != NULL )
> {
> + request_queue_t *q = req->sr_device->request_queue;
> scsi_put_command(req->sr_command);
> req->sr_command = NULL;
> + scsi_queue_next_request(q, NULL);
> }
>
> kfree(req);
> diff -puN drivers/scsi/scsi_error.c~scsi-release-req drivers/scsi/scsi_error.c
> --- sysfs-bleed-2.5/drivers/scsi/scsi_error.c~scsi-release-req Mon Apr 14 15:34:14 2003
> +++ sysfs-bleed-2.5-andmike/drivers/scsi/scsi_error.c Mon Apr 14 15:34:14 2003
> @@ -1334,10 +1334,6 @@ static void scsi_eh_lock_done(struct scs
> {
> struct scsi_request *sreq = scmd->sc_request;
>
> - scmd->sc_request = NULL;
> - sreq->sr_command = NULL;
> -
> - scsi_put_command(scmd);
> scsi_release_request(sreq);
> }
Yes! I can now eject and re-insert a Zip disk in the drive and re-mount
it as many times as I wish.
I did need to remove the 'static' (as posted by Gert) before I could
compile the kernel, but otherwise it seems perfect.
You guys are great, thanks!
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Re: 2.5.67: ppa driver & preempt == oops
@ 2003-04-16 9:45 Chuck Ebbert
0 siblings, 0 replies; 29+ messages in thread
From: Chuck Ebbert @ 2003-04-16 9:45 UTC (permalink / raw)
To: Patrick Mansfield; +Cc: linux-kernel
> It opens sd twice (AFAIK) - I think mount scans the block devices (an open
> of sd) and then mounts (internal open). The code path in question is
> probably via sd.c functions sd_media_changed and sd_revalidate_disk, and
> the block_dev.c check_disk_change. sd_open calls check_disk_change.
>
> This could be the same problem others are seeing with removable media
> accessed via USB mass storage.
I was seeing problems with ide-floppy on 2.5.66. It kept
trying to re-register the disk, AFAICT... and there were different
errors depending on whether I booted with a disk in the drive. (The
drive was removed, so I can't test anything now.)
--
Chuck
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Re: 2.5.67: ppa driver & preempt == oops
2003-04-15 23:25 ` Patrick Mansfield
@ 2003-04-16 3:30 ` walt
0 siblings, 0 replies; 29+ messages in thread
From: walt @ 2003-04-16 3:30 UTC (permalink / raw)
To: linux-kernel
Patrick Mansfield wrote:
> On Tue, Apr 15, 2003 at 04:04:02PM -0700, walt wrote:
>
>
>>Yes! Thank you. This patch fixes the segfault of modprobe that I've
>>been seeing for ages.
>>
>>Note that the problems I have been seeing are completely different from
>>Geert's problems. I have had no problems mounting a FAT-16 fs with the
>>2.5.x kernels but modprobe has been segfaulting all along, even though
>>the ppa module works fine for me once it has been loaded.
>
>
> The other problem seems to be for removable media. Is your parallel zip
> have removable media and does the boot/dmesg output from sd attach show it
> as such? I haven't used a zip drive, I thought they had to be marked
> removable.
Seems to be:
ppa: Version 2.07 (for Linux 2.4.x)
ppa: Found device at ID 6, Attempting to use EPP 32 bit
ppa: Found device at ID 6, Attempting to use SPP
ppa: Communication established with ID 6 using SPP
scsi0 : Iomega VPI0 (ppa) interface
Vendor: IOMEGA Model: ZIP 100 Rev: C.18
Type: Direct-Access ANSI SCSI revision: 02
SCSI device sda: 196608 512-byte hdwr sectors (101 MB)
sda: Write Protect is off
sda: Mode Sense: 25 00 00 08
sda: cache data unavailable
sda: assuming drive cache: write through
/dev/scsi/host0/bus0/target6/lun0: p4
Attached scsi removable disk sda at scsi0, channel 0, id 6, lun 0
^^^^^^^^^
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Re: 2.5.67: ppa driver & preempt == oops
[not found] ` <fa.jt2b7k8.20qj0c@ifi.uio.no>
@ 2003-04-16 3:19 ` walt
0 siblings, 0 replies; 29+ messages in thread
From: walt @ 2003-04-16 3:19 UTC (permalink / raw)
To: linux-kernel
Randy.Dunlap wrote:
> On Tue, 15 Apr 2003 16:51:53 -0700 walt <wa1ter@myrealbox.com> wrote:
>
> | walt wrote:
> | I can mount and unmount the Zip disk as many times as I want, as long as
> | I don't eject the disk from the drive.
> |
> | Once I eject the disk and insert it again, the mount commant just hangs
> | forever. No error messages anywhere -- it just hangs. I can't even
> | kill the mount command. The only way out is to reboot and then all is
> | well again until the next time I eject the disk from the drive.
>
>
> I don't know that it's _required_, but you can try doing
> umount /mnt/zip (or /dev/sdx)
> eject /mnt/zip (or dev/sdx)
>
> and then eject it, reinsert it, try to mount, etc.?
The eject command works perfectly, just like pushing the eject button.
When I reinsert the disk in the drive I still get a permanent hang when
trying to remount the drive.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Re: 2.5.67: ppa driver & preempt == oops
2003-04-15 23:51 ` walt
@ 2003-04-16 0:07 ` Randy.Dunlap
0 siblings, 0 replies; 29+ messages in thread
From: Randy.Dunlap @ 2003-04-16 0:07 UTC (permalink / raw)
To: walt; +Cc: linux-kernel
On Tue, 15 Apr 2003 16:51:53 -0700 walt <wa1ter@myrealbox.com> wrote:
| walt wrote:
| > Patrick Mansfield wrote:
| >
| >> On Sun, Apr 13, 2003 at 07:44:04PM +0200, Gert Vervoort wrote:
| >>
| >> Here is a patch against 2.5.67, can you try it out?
| >>
| >> I did not compile let alone run with this patch.
| >>
| >> We never hold the host_lock while calling the detect function (unlike the
| >> io_request_lock, see the bizzare 2.4 code), so acquiring it inside
| >> ppa_detect is very wrong. I don't know why your scsi scan did not hang.
| >>
...
| >
| >
| >
| > Yes! Thank you. This patch fixes the segfault of modprobe that I've
| > been seeing for ages.
|
| Hmm. An important addendum --
|
| I can mount and unmount the Zip disk as many times as I want, as long as
| I don't eject the disk from the drive.
|
| Once I eject the disk and insert it again, the mount commant just hangs
| forever. No error messages anywhere -- it just hangs. I can't even
| kill the mount command. The only way out is to reboot and then all is
| well again until the next time I eject the disk from the drive.
I don't know that it's _required_, but you can try doing
umount /mnt/zip (or /dev/sdx)
eject /mnt/zip (or dev/sdx)
and then eject it, reinsert it, try to mount, etc.?
--
~Randy
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Re: 2.5.67: ppa driver & preempt == oops
[not found] ` <fa.fnhqqrs.ok0028@ifi.uio.no>
@ 2003-04-15 23:51 ` walt
2003-04-16 0:07 ` Randy.Dunlap
0 siblings, 1 reply; 29+ messages in thread
From: walt @ 2003-04-15 23:51 UTC (permalink / raw)
To: linux-kernel
walt wrote:
> Patrick Mansfield wrote:
>
>> On Sun, Apr 13, 2003 at 07:44:04PM +0200, Gert Vervoort wrote:
>>
>> Here is a patch against 2.5.67, can you try it out?
>>
>> I did not compile let alone run with this patch.
>>
>> We never hold the host_lock while calling the detect function (unlike the
>> io_request_lock, see the bizzare 2.4 code), so acquiring it inside
>> ppa_detect is very wrong. I don't know why your scsi scan did not hang.
>>
>> --- linux-2.5.67/drivers/scsi/ppa.c-orig Mon Apr 7 10:31:47 2003
>> +++ linux-2.5.67/drivers/scsi/ppa.c Tue Apr 15 11:54:34 2003
>> @@ -219,15 +219,12 @@
>> printk(" supported by the imm (ZIP Plus) driver. If the\n");
>> printk(" cable is marked with \"AutoDetect\", this is what
>> has\n");
>> printk(" happened.\n");
>> - spin_lock_irq(hreg->host_lock);
>> return 0;
>> }
>> try_again = 1;
>> goto retry_entry;
>> - } else {
>> - spin_lock_irq(hreg->host_lock);
>> + } else
>> return 1; /* return number of hosts detected */
>> - }
>> }
>>
>> /* This is to give the ppa driver a way to modify the timings (and other
>
>
>
> Yes! Thank you. This patch fixes the segfault of modprobe that I've
> been seeing for ages.
Hmm. An important addendum --
I can mount and unmount the Zip disk as many times as I want, as long as
I don't eject the disk from the drive.
Once I eject the disk and insert it again, the mount commant just hangs
forever. No error messages anywhere -- it just hangs. I can't even
kill the mount command. The only way out is to reboot and then all is
well again until the next time I eject the disk from the drive.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Re: 2.5.67: ppa driver & preempt == oops
2003-04-15 23:04 ` [PATCH] " walt
@ 2003-04-15 23:25 ` Patrick Mansfield
2003-04-16 3:30 ` walt
0 siblings, 1 reply; 29+ messages in thread
From: Patrick Mansfield @ 2003-04-15 23:25 UTC (permalink / raw)
To: walt; +Cc: linux-kernel
On Tue, Apr 15, 2003 at 04:04:02PM -0700, walt wrote:
> Yes! Thank you. This patch fixes the segfault of modprobe that I've
> been seeing for ages.
>
> Note that the problems I have been seeing are completely different from
> Geert's problems. I have had no problems mounting a FAT-16 fs with the
> 2.5.x kernels but modprobe has been segfaulting all along, even though
> the ppa module works fine for me once it has been loaded.
The other problem seems to be for removable media. Is your parallel zip
have removable media and does the boot/dmesg output from sd attach show it
as such? I haven't used a zip drive, I thought they had to be marked
removable.
-- Patrick Mansfield
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Re: 2.5.67: ppa driver & preempt == oops
[not found] ` <fa.gs8uudl.196640l@ifi.uio.no>
@ 2003-04-15 23:04 ` walt
2003-04-15 23:25 ` Patrick Mansfield
0 siblings, 1 reply; 29+ messages in thread
From: walt @ 2003-04-15 23:04 UTC (permalink / raw)
To: linux-kernel
Patrick Mansfield wrote:
> On Sun, Apr 13, 2003 at 07:44:04PM +0200, Gert Vervoort wrote:
>
> Here is a patch against 2.5.67, can you try it out?
>
> I did not compile let alone run with this patch.
>
> We never hold the host_lock while calling the detect function (unlike the
> io_request_lock, see the bizzare 2.4 code), so acquiring it inside
> ppa_detect is very wrong. I don't know why your scsi scan did not hang.
>
> --- linux-2.5.67/drivers/scsi/ppa.c-orig Mon Apr 7 10:31:47 2003
> +++ linux-2.5.67/drivers/scsi/ppa.c Tue Apr 15 11:54:34 2003
> @@ -219,15 +219,12 @@
> printk(" supported by the imm (ZIP Plus) driver. If the\n");
> printk(" cable is marked with \"AutoDetect\", this is what has\n");
> printk(" happened.\n");
> - spin_lock_irq(hreg->host_lock);
> return 0;
> }
> try_again = 1;
> goto retry_entry;
> - } else {
> - spin_lock_irq(hreg->host_lock);
> + } else
> return 1; /* return number of hosts detected */
> - }
> }
>
> /* This is to give the ppa driver a way to modify the timings (and other
Yes! Thank you. This patch fixes the segfault of modprobe that I've
been seeing for ages.
Note that the problems I have been seeing are completely different from
Geert's problems. I have had no problems mounting a FAT-16 fs with the
2.5.x kernels but modprobe has been segfaulting all along, even though
the ppa module works fine for me once it has been loaded.
When I compile ppa into the kernel I see a kernel panic during bootup.
I will also try compiling your patch into the kernel and see if it
prevents the panic.
The parallel Zip drive is the only scsi device I have, so I can't
comment on the more general situation. This is the scsi section
of my kernel config:
# SCSI device support
#
CONFIG_SCSI=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_REPORT_LUNS is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_AM53C974 is not set# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
CONFIG_SCSI_PPA=m
CONFIG_SCSI_IMM=m
# CONFIG_SCSI_IZIP_EPP16 is not set
# CONFIG_SCSI_IZIP_SLOW_CTR is not set
# CONFIG_SCSI_NCR53C7xx is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_NCR53C8XX is not set
# CONFIG_SCSI_SYM53C8XX is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_DC390T is not set
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2003-04-17 19:36 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-12 15:03 2.5.67: ppa driver & preempt == oops Gert Vervoort
2003-04-12 18:28 ` Robert Love
2003-04-13 10:30 ` Gert Vervoort
2003-04-13 17:32 ` Robert Love
2003-04-13 17:44 ` Gert Vervoort
2003-04-15 19:00 ` [PATCH] " Patrick Mansfield
2003-04-15 20:44 ` Gert Vervoort
2003-04-15 21:40 ` Patrick Mansfield
2003-04-16 17:52 ` Gert Vervoort
2003-04-16 18:05 ` Patrick Mansfield
2003-04-16 19:45 ` Gert Vervoort
2003-04-16 20:07 ` Mike Anderson
2003-04-16 18:03 ` Gert Vervoort
2003-04-15 21:37 ` Robert Love
2003-04-15 21:51 ` Randy.Dunlap
2003-04-15 22:07 ` Patrick Mansfield
2003-04-15 22:29 ` Randy.Dunlap
2003-04-15 22:35 ` Patrick Mansfield
2003-04-12 21:12 ` Andrew Morton
2003-04-13 11:45 ` Gert Vervoort
2003-04-13 20:44 ` Andrew Morton
[not found] <fa.chdor2j.u72387@ifi.uio.no>
[not found] ` <fa.gs8uudl.196640l@ifi.uio.no>
2003-04-15 23:04 ` [PATCH] " walt
2003-04-15 23:25 ` Patrick Mansfield
2003-04-16 3:30 ` walt
[not found] <fa.hdvi4hc.152sj34@ifi.uio.no>
[not found] ` <fa.fnhqqrs.ok0028@ifi.uio.no>
2003-04-15 23:51 ` walt
2003-04-16 0:07 ` Randy.Dunlap
[not found] <fa.fo1ils5.o4kt21@ifi.uio.no>
[not found] ` <fa.jt2b7k8.20qj0c@ifi.uio.no>
2003-04-16 3:19 ` walt
2003-04-16 9:45 Chuck Ebbert
[not found] <fa.cde0mrb.127uv05@ifi.uio.no>
[not found] ` <fa.i9on98t.1gg0toj@ifi.uio.no>
2003-04-17 19:37 ` walt
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).