Skip to contentSkip to conversation

2.5.67: ppa driver & preempt == oops

DISCUSSION Gert Vervoort 6 participants 21 messages Apr 12, 2003 – Apr 16, 2003 SCSI

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw
Quoted 3 lines · Gert Vervoort

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

#2 lore raw
Quoted 5 lines

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.

Quoted 7 lines

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

#3 lore raw
Quoted 3 lines · Gert Vervoort

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

#4 lore raw
Quoted 4 lines · Robert Love

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

#5 lore raw

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.

drivers/scsi/ppa.c renamed from drivers/scsi/ppa.c-orig +1 -4
@@ -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
#6 lore raw
Quoted 7 lines · Patrick Mansfield

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

#7 lore raw
Quoted 18 lines · Gert Vervoort

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:

Quoted 2 lines

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

#8 lore raw
Quoted 9 lines

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:

Quoted 9 lines

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

#9 lore raw
Quoted 6 lines · Gert Vervoort

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

Quoted 8 lines

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(-)
drivers/scsi/scsi.c renamed from drivers/scsi/scsi.c~scsi-release-req +2 -0
diff -puN drivers/scsi/scsi.c~scsi-release-req drivers/scsi/scsi.c
@@ -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);
drivers/scsi/scsi_error.c renamed from drivers/scsi/scsi_error.c~scsi-release-req +0 -4
diff -puN drivers/scsi/scsi_error.c~scsi-release-req drivers/scsi/scsi_error.c
@@ -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);
 }
#10 lore raw
Quoted 7 lines · Patrick Mansfield

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).

Quoted 3 lines

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 2003-04-16 21:23:46.000000000 +0200 renamed from scsi_lib.c.1 2003-04-16 21:23:37.000000000 +0200 +0 -0
@@ -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

Quoted 43 lines

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

drivers/scsi/scsi.c renamed from drivers/scsi/scsi.c~scsi-release-req +2 -0
@@ -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

drivers/scsi/scsi_error.c renamed from drivers/scsi/scsi_error.c~scsi-release-req +0 -4
@@ -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);
 }
 

.

#11 lore raw
Quoted 14 lines · Gert Vervoort [[email protected]] 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 2003-04-16 21:23:46.000000000 +0200 renamed from scsi_lib.c.1 2003-04-16 21:23:37.000000000 +0200 +0 -0
@@ -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)

Quoted 3 lines
{
       struct scsi_device *sdev, *sdev2;
       struct Scsi_Host *shost;

The static removal is present already in bk current.

-andmike
--
Michael Anderson
[email protected]

#12 lore raw
In reply to Patrick Mansfield
Quoted 6 lines

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

#13 lore raw
In reply to Patrick Mansfield
Quoted 3 lines · Patrick Mansfield

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

#14 lore raw

On 15 Apr 2003 17:37:56 -0400 Robert Love <[email protected]> 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

#15 lore raw
Quoted 2 lines · Randy.Dunlap

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).

Quoted 1 line

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

#16 lore raw

On Tue, 15 Apr 2003 15:07:46 -0700 Patrick Mansfield <[email protected]> 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

#17 lore raw
Quoted 3 lines · Randy.Dunlap

On Tue, 15 Apr 2003 15:07:46 -0700 Patrick Mansfield <[email protected]> wrote:

So I should test (and fix) 2.5.67-k.o and PREEMPT=y ??

I think it's independent of preempt.

Quoted 1 line

Maybe you'll have to walk across the street tomorrow.

I can do that :)

-- Patrick Mansfield

#18 lore raw
In reply to Gert Vervoort
Quoted 6 lines · Gert Vervoort

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?

drivers/scsi/ppa.c renamed from drivers/scsi/ppa.c~ppa-null-pointer-fix +4 -2
diff -puN drivers/scsi/ppa.c~ppa-null-pointer-fix drivers/scsi/ppa.c
@@ -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 */
     }
 }

_

#19 lore raw
Quoted 3 lines · Andrew Morton

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

Quoted 5 lines

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

#20 lore raw
Quoted 8 lines · Gert Vervoort
Quoted 3 lines · Andrew Morton

This patch should make the warnings go away.

The warnings are still there:

Quoted 8 lines

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.

Quoted 1 line

error in initcall at 0xc0391ad0: returned with preemption imbalance

ick.

Quoted 12 lines

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

Quoted 2 lines

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.