Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1272027 > unrolled thread
| Started by | Finn Thain <fthain@telegraphics.com.au> |
|---|---|
| First post | 2015-11-18 10:20 +0100 |
| Last post | 2015-11-30 06:00 +0100 |
| Articles | 20 on this page of 44 — 5 participants |
Back to article view | Back to linux.kernel
[PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-18 10:20 +0100
[PATCH 04/71] ncr5380: Remove more pointless macros Finn Thain <fthain@telegraphics.com.au> - 2015-11-18 10:30 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-18 12:40 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-19 03:30 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Michael Schmitz <schmitzmic@gmail.com> - 2015-11-19 04:00 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-19 08:50 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-20 00:00 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-20 02:50 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-20 08:30 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Christoph Hellwig <hch@infradead.org> - 2015-11-20 08:40 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-20 09:20 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-20 10:20 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Christoph Hellwig <hch@infradead.org> - 2015-11-20 11:10 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-20 12:00 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Christoph Hellwig <hch@infradead.org> - 2015-11-20 12:50 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-20 12:50 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Geert Uytterhoeven <geert@linux-m68k.org> - 2015-11-20 13:30 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-20 13:50 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-20 08:40 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-20 19:30 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-21 03:10 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-21 14:10 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-22 00:10 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-22 00:40 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-24 00:00 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-24 02:30 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-24 09:10 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-24 10:20 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-24 13:10 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-24 19:10 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-24 22:50 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-25 03:20 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-25 10:10 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-25 13:00 +0100
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-26 00:10 +0100
[PATCH 72/71] ncr5380: Fix pseudo-DMA Ondrej Zary <linux@rainbow-software.org> - 2015-11-25 22:40 +0100
[RFC PATCH 73/71] ncr5380: Use runtime register mapping Ondrej Zary <linux@rainbow-software.org> - 2015-11-29 10:50 +0100
Re: [RFC PATCH 73/71] ncr5380: Use runtime register mapping Finn Thain <fthain@telegraphics.com.au> - 2015-11-30 13:00 +0100
[RFC PATCH 74/71] ncr5380: Enable PDMA for NCR53C400A Ondrej Zary <linux@rainbow-software.org> - 2015-11-29 10:50 +0100
Re: [RFC PATCH 74/71] ncr5380: Enable PDMA for NCR53C400A Finn Thain <fthain@telegraphics.com.au> - 2015-11-30 13:00 +0100
Re: [RFC PATCH 74/71] ncr5380: Enable PDMA for NCR53C400A Finn Thain <fthain@telegraphics.com.au> - 2015-11-30 13:10 +0100
Re: [RFC PATCH 74/71] ncr5380: Enable PDMA for NCR53C400A Ondrej Zary <linux@rainbow-software.org> - 2015-11-30 14:50 +0100
[RFC PATCH 75/71] ncr5380: Remove FLAG_DTC3181E Ondrej Zary <linux@rainbow-software.org> - 2015-11-29 11:10 +0100
Re: [RFC PATCH 75/71] ncr5380: Remove FLAG_DTC3181E Finn Thain <fthain@telegraphics.com.au> - 2015-11-30 06:00 +0100
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
| From | Finn Thain <fthain@telegraphics.com.au> |
|---|---|
| Date | 2015-11-21 03:10 +0100 |
| Subject | Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers |
| Message-ID | <qx5MJ-7gC-3@gated-at.bofh.it> |
| In reply to | #1274332 |
Hi Ondrej,
On Fri, 20 Nov 2015, Ondrej Zary wrote:
> On Friday 20 November 2015 02:41:19 Finn Thain wrote:
> >
> >
> > My tests involved 3 different scsi targets (two disks and a CD-ROM)
> > but none of these send a SDTR. Your log says the driver correctly
> > rejected the SDTR message but that doesn't mean the target actually
> > went to MSG IN phase and got the message. Do you have any older
> > targets you can test?
>
> Another disk, without patches:
>
> [ 84.481582] pnp 01:01.00: activated
> [ 84.489650] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, USLEEP_POLL 3, USLEEP_WAITLONG 1250, options { AUTOPROBE_IRQ PSEUDO_DMA NCR53C400 }
> [ 84.953332] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6 PQ: 0 ANSI: 2 CCS
> [ 86.786475] sd 2:0:1:0: Attached scsi generic sg1 type 0
> [ 86.793753] sd 2:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234 MiB)
> [ 86.998555] sd 2:0:1:0: [sdb] Write Protect is off
> [ 87.406068] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> [ 118.888271] sd 2:0:1:0: [sdb] aborting command
> [ 118.888738] sd 2:0:1:0: [sdb] aborting command
>
> With patches:
>
> [ 258.473748] pnp 01:01.00: activated
> [ 258.483592] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, options { AUTOPROBE_IRQ PSEUDO_DMA }
> [ 261.347632] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6 PQ: 0 ANSI: 2 CCS
> [ 275.560451] sd 2:0:1:0: Attached scsi generic sg1 type 0
> [ 275.632519] sd 2:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234 MiB)
> [ 275.635533] sd 2:0:1:0: [sdb] Write Protect is off
> [ 275.642315] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> [ 469.076347] sd 2:0:1:0: [sdb] FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_SENSE
> [ 469.076613] sd 2:0:1:0: [sdb] Sense Key : Aborted Command [current]
> [ 469.076851] sd 2:0:1:0: [sdb] Add. Sense: No additional sense information
> [ 469.077086] sd 2:0:1:0: [sdb] CDB: Read(10) 28 00 00 00 00 02 00 00 02 00
> [ 469.077306] blk_update_request: I/O error, dev sdb, sector 2
> [ 469.077522] Buffer I/O error on dev sdb, logical block 1, async page read
> [ 480.108255] INFO: task kworker/u2:2:60 blocked for more than 120 seconds.
> [ 480.109773] Not tainted 4.3.0-rc1+ #74
> [ 480.109973] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 480.110179] kworker/u2:2 D 00000040 0 60 2 0x00000000
> [ 480.110671] Workqueue: events_unbound async_run_entry_fn
> [ 480.110999] cf9e8780 00000046 2eff25f7 00000040 c117f111 2ee82733 00000040 0016fec4
> [ 480.112390] 00000000 cfaa6000 00000000 7fffffff c139c7d2 c139c504 7fffffff c139d9d3
> [ 480.113661] 00000040 cfaa5cfc c106f460 00161108 00000000 0000c648 2106dcce 00000040
> [ 480.114893] Call Trace:
> [ 480.115124] [<c117f111>] ? blk_queue_bio+0x1e8/0x1fb
> [ 480.115344] [<c139c7d2>] ? bit_wait_io_timeout+0x3d/0x3d
> [ 480.115564] [<c139c504>] ? schedule+0x5b/0x67
> [ 480.115794] [<c139d9d3>] ? schedule_timeout+0x13/0xc5
> [ 480.116007] [<c106f460>] ? timekeeping_get_ns+0x10/0x69
> [ 480.116406] [<c139c7d2>] ? bit_wait_io_timeout+0x3d/0x3d
> [ 480.116636] [<c106fae7>] ? ktime_get+0x38/0x48
> [ 480.116843] [<c139bf83>] ? io_schedule_timeout+0x83/0xd7
> [ 480.117062] [<c139c7f3>] ? bit_wait_io+0x21/0x26
> [ 480.117256] [<c139c697>] ? __wait_on_bit+0x2f/0x5a
> [ 480.117486] [<c10ff1eb>] ? blkdev_readpages+0x15/0x15
> [ 480.117704] [<c10ad361>] ? wait_on_page_bit+0x57/0x5e
> [ 480.117942] [<c1054a98>] ? wake_atomic_t_function+0x2a/0x2a
> [ 480.118151] [<c10ad386>] ? wait_on_page_read+0xf/0x2a
> [ 480.118373] [<c10ae0e1>] ? do_read_cache_page+0x8e/0x116
> [ 480.118587] [<c10ff1eb>] ? blkdev_readpages+0x15/0x15
> [ 480.118809] [<c10ae192>] ? read_cache_page+0x14/0x18
> [ 480.119008] [<c1189b0e>] ? read_dev_sector+0x25/0x57
> [ 480.119222] [<c118a8a8>] ? adfspart_check_ICS+0x30/0x1ac
> [ 480.119438] [<c119a3f1>] ? vsnprintf+0x78/0x25d
> [ 480.119671] [<c119a614>] ? snprintf+0x16/0x18
> [ 480.119874] [<c118a7ea>] ? check_partition+0xd7/0x165
> [ 480.120253] [<c118a067>] ? rescan_partitions+0x95/0x283
> [ 480.120443] [<c1254b50>] ? scsi_block_when_processing_errors+0x13/0xae
> [ 480.120693] [<c139cbc6>] ? mutex_lock+0x9/0x21
> [ 480.120915] [<c1100046>] ? __blkdev_get+0x155/0x2f6
> [ 480.121133] [<c110032f>] ? blkdev_get+0x148/0x258
> [ 480.121350] [<c10ec747>] ? unlock_new_inode+0x36/0x3c
> [ 480.121570] [<c10ff106>] ? bdget+0xdc/0xe6
> [ 480.121761] [<c118854f>] ? add_disk+0x221/0x368
> [ 480.121996] [<c126321a>] ? sd_probe_async+0xed/0x157
> [ 480.122214] [<c10443a0>] ? async_run_entry_fn+0x2c/0xad
> [ 480.122437] [<c103f060>] ? process_one_work+0x130/0x21f
> [ 480.122639] [<c103f2f6>] ? worker_thread+0x18a/0x247
> [ 480.122854] [<c103f16c>] ? process_scheduled_works+0x1d/0x1d
> [ 480.123069] [<c1042c46>] ? kthread+0x7c/0x81
> [ 480.123288] [<c139e201>] ? ret_from_kernel_thread+0x21/0x30
> [ 480.123493] [<c1042bca>] ? kthread_parkme+0x11/0x11
> [ 480.123733] INFO: task modprobe:1977 blocked for more than 120 seconds.
> [ 480.123919] Not tainted 4.3.0-rc1+ #74
> [ 480.124239] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 480.124410] modprobe D 00000040 0 1977 1969 0x00000000
> [ 480.124864] cfb20000 00000086 29042653 00000040 c1525f88 28a83a17 00000040 005bec3c
> [ 480.126123] 00000000 ccdd0000 ffffffff ffffffff d2057280 c139c504 00000000 c104416d
> [ 480.127354] 00000000 cfb20000 c1054a45 c151fd8c c151fd8c d2057280 00000000 ccd621f0
> [ 480.128746] Call Trace:
> [ 480.128961] [<c139c504>] ? schedule+0x5b/0x67
> [ 480.129202] [<c104416d>] ? async_synchronize_cookie_domain+0x73/0x9f
> [ 480.129449] [<c1054a45>] ? abort_exclusive_wait+0x6e/0x6e
> [ 480.129667] [<c10ac9bc>] ? do_init_module+0xa4/0x1a3
> [ 480.129899] [<c107ddb5>] ? load_module+0x14de/0x18ca
> [ 480.130119] [<c107e2a0>] ? SyS_finit_module+0x47/0x56
> [ 480.130346] [<c139e2c0>] ? sysenter_do_call+0x12/0x12
> [ 502.100317] sd 2:0:1:0: [sdb] FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_SENSE
> [ 502.100578] sd 2:0:1:0: [sdb] Sense Key : Aborted Command [current]
> [ 502.100818] sd 2:0:1:0: [sdb] Add. Sense: No additional sense information
> [ 502.101057] sd 2:0:1:0: [sdb] CDB: Read(10) 28 00 00 00 00 04 00 00 02 00
> [ 502.101279] blk_update_request: I/O error, dev sdb, sector 4
> [ 502.101495] Buffer I/O error on dev sdb, logical block 2, async page read
> [ 600.128255] INFO: task kworker/u2:2:60 blocked for more than 120 seconds.
> [ 600.128486] Not tainted 4.3.0-rc1+ #74
> [ 600.128687] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 600.128891] kworker/u2:2 D 00000040 0 60 2 0x00000000
> [ 600.129381] Workqueue: events_unbound async_run_entry_fn
> [ 600.129709] cf9e8780 00000046 2eff25f7 00000040 c117f111 2ee82733 00000040 0016fec4
> [ 600.130941] 00000000 cfaa6000 00000000 7fffffff c139c7d2 c139c504 7fffffff c139d9d3
> [ 600.132342] 00000040 cfaa5cfc c106f460 00161108 00000000 0000c648 2106dcce 00000040
> [ 600.133613] Call Trace:
> [ 600.133821] [<c117f111>] ? blk_queue_bio+0x1e8/0x1fb
> [ 600.134065] [<c139c7d2>] ? bit_wait_io_timeout+0x3d/0x3d
> [ 600.134283] [<c139c504>] ? schedule+0x5b/0x67
> [ 600.134509] [<c139d9d3>] ? schedule_timeout+0x13/0xc5
> [ 600.134723] [<c106f460>] ? timekeeping_get_ns+0x10/0x69
> [ 600.134948] [<c139c7d2>] ? bit_wait_io_timeout+0x3d/0x3d
> [ 600.135154] [<c106fae7>] ? ktime_get+0x38/0x48
> [ 600.135377] [<c139bf83>] ? io_schedule_timeout+0x83/0xd7
> [ 600.135576] [<c139c7f3>] ? bit_wait_io+0x21/0x26
> [ 600.135788] [<c139c697>] ? __wait_on_bit+0x2f/0x5a
> [ 600.136000] [<c10ff1eb>] ? blkdev_readpages+0x15/0x15
> [ 600.136399] [<c10ad361>] ? wait_on_page_bit+0x57/0x5e
> [ 600.136607] [<c1054a98>] ? wake_atomic_t_function+0x2a/0x2a
> [ 600.136838] [<c10ad386>] ? wait_on_page_read+0xf/0x2a
> [ 600.137044] [<c10ae0e1>] ? do_read_cache_page+0x8e/0x116
> [ 600.137276] [<c10ff1eb>] ? blkdev_readpages+0x15/0x15
> [ 600.137481] [<c10ae192>] ? read_cache_page+0x14/0x18
> [ 600.137699] [<c1189b0e>] ? read_dev_sector+0x25/0x57
> [ 600.137901] [<c118a8a8>] ? adfspart_check_ICS+0x30/0x1ac
> [ 600.138131] [<c119a3f1>] ? vsnprintf+0x78/0x25d
> [ 600.138329] [<c119a614>] ? snprintf+0x16/0x18
> [ 600.138544] [<c118a7ea>] ? check_partition+0xd7/0x165
> [ 600.138738] [<c118a067>] ? rescan_partitions+0x95/0x283
> [ 600.138962] [<c1254b50>] ? scsi_block_when_processing_errors+0x13/0xae
> [ 600.139189] [<c139cbc6>] ? mutex_lock+0x9/0x21
> [ 600.139427] [<c1100046>] ? __blkdev_get+0x155/0x2f6
> [ 600.139632] [<c110032f>] ? blkdev_get+0x148/0x258
> [ 600.139865] [<c10ec747>] ? unlock_new_inode+0x36/0x3c
> [ 600.140263] [<c10ff106>] ? bdget+0xdc/0xe6
> [ 600.140448] [<c118854f>] ? add_disk+0x221/0x368
> [ 600.140689] [<c126321a>] ? sd_probe_async+0xed/0x157
> [ 600.140908] [<c10443a0>] ? async_run_entry_fn+0x2c/0xad
> [ 600.141133] [<c103f060>] ? process_one_work+0x130/0x21f
> [ 600.141336] [<c103f2f6>] ? worker_thread+0x18a/0x247
> [ 600.141552] [<c103f16c>] ? process_scheduled_works+0x1d/0x1d
> [ 600.141764] [<c1042c46>] ? kthread+0x7c/0x81
> [ 600.141982] [<c139e201>] ? ret_from_kernel_thread+0x21/0x30
> [ 600.142186] [<c1042bca>] ? kthread_parkme+0x11/0x11
> [ 600.142426] INFO: task modprobe:1977 blocked for more than 120 seconds.
> [ 600.142612] Not tainted 4.3.0-rc1+ #74
> [ 600.142787] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 600.142991] modprobe D 00000040 0 1977 1969 0x00000000
> [ 600.143444] cfb20000 00000086 29042653 00000040 c1525f88 28a83a17 00000040 005bec3c
> [ 600.144819] 00000000 ccdd0000 ffffffff ffffffff d2057280 c139c504 00000000 c104416d
> [ 600.146052] 00000000 cfb20000 c1054a45 c151fd8c c151fd8c d2057280 00000000 ccd621f0
> [ 600.147279] Call Trace:
> [ 600.147489] [<c139c504>] ? schedule+0x5b/0x67
> [ 600.147729] [<c104416d>] ? async_synchronize_cookie_domain+0x73/0x9f
> [ 600.147992] [<c1054a45>] ? abort_exclusive_wait+0x6e/0x6e
> [ 600.148390] [<c10ac9bc>] ? do_init_module+0xa4/0x1a3
> [ 600.148627] [<c107ddb5>] ? load_module+0x14de/0x18ca
> [ 600.148846] [<c107e2a0>] ? SyS_finit_module+0x47/0x56
> [ 600.149073] [<c139e2c0>] ? sysenter_do_call+0x12/0x12
> [ 662.100333] sd 2:0:1:0: [sdb] FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_SENSE
> [ 662.100598] sd 2:0:1:0: [sdb] Sense Key : Aborted Command [current]
> [ 662.100838] sd 2:0:1:0: [sdb] Add. Sense: No additional sense information
> [ 662.101076] sd 2:0:1:0: [sdb] CDB: Read(10) 28 00 00 00 00 06 00 00 02 00
> [ 662.101297] blk_update_request: I/O error, dev sdb, sector 6
> [ 662.101512] Buffer I/O error on dev sdb, logical block 3, async page read
> [ 720.148270] INFO: task modprobe:1977 blocked for more than 120 seconds.
> [ 720.148499] Not tainted 4.3.0-rc1+ #74
> [ 720.148699] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 720.148903] modprobe D 00000040 0 1977 1969 0x00000000
> [ 720.149360] cfb20000 00000086 29042653 00000040 c1525f88 28a83a17 00000040 005bec3c
> [ 720.150615] 00000000 ccdd0000 ffffffff ffffffff d2057280 c139c504 00000000 c104416d
> [ 720.151836] 00000000 cfb20000 c1054a45 c151fd8c c151fd8c d2057280 00000000 ccd621f0
> [ 720.153221] Call Trace:
> [ 720.153465] [<c139c504>] ? schedule+0x5b/0x67
> [ 720.153689] [<c104416d>] ? async_synchronize_cookie_domain+0x73/0x9f
> [ 720.153931] [<c1054a45>] ? abort_exclusive_wait+0x6e/0x6e
> [ 720.154149] [<c10ac9bc>] ? do_init_module+0xa4/0x1a3
> [ 720.154379] [<c107ddb5>] ? load_module+0x14de/0x18ca
> [ 720.154593] [<c107e2a0>] ? SyS_finit_module+0x47/0x56
> [ 720.154820] [<c139e2c0>] ? sysenter_do_call+0x12/0x12
> [ 781.025039] systemd-logind[1942]: New session c2 of user rainbow.
> [ 840.152254] INFO: task kworker/u2:2:60 blocked for more than 120 seconds.
> [ 840.152486] Not tainted 4.3.0-rc1+ #74
> [ 840.152693] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 840.152903] kworker/u2:2 D 0000009a 0 60 2 0x00000000
> [ 840.153399] Workqueue: events_unbound async_run_entry_fn
> [ 840.153730] cf9e8780 00000046 2860b1ff 0000009a c117f111 284404dd 0000009a 001cad22
> [ 840.156408] 00000000 cfaa6000 00000000 7fffffff c139c7d2 c139c504 7fffffff c139d9d3
> [ 840.157689] 0000009a cfaa5c64 c106f460 00161e18 00000000 00013d94 006b70ce 0000009a
> [ 840.158925] Call Trace:
> [ 840.159158] [<c117f111>] ? blk_queue_bio+0x1e8/0x1fb
> [ 840.159379] [<c139c7d2>] ? bit_wait_io_timeout+0x3d/0x3d
> [ 840.159600] [<c139c504>] ? schedule+0x5b/0x67
> [ 840.159834] [<c139d9d3>] ? schedule_timeout+0x13/0xc5
> [ 840.160052] [<c106f460>] ? timekeeping_get_ns+0x10/0x69
> [ 840.160446] [<c139c7d2>] ? bit_wait_io_timeout+0x3d/0x3d
> [ 840.160677] [<c106fae7>] ? ktime_get+0x38/0x48
> [ 840.160884] [<c139bf83>] ? io_schedule_timeout+0x83/0xd7
> [ 840.161105] [<c139c7f3>] ? bit_wait_io+0x21/0x26
> [ 840.161306] [<c139c697>] ? __wait_on_bit+0x2f/0x5a
> [ 840.161541] [<c10ad361>] ? wait_on_page_bit+0x57/0x5e
> [ 840.161767] [<c1054a98>] ? wake_atomic_t_function+0x2a/0x2a
> [ 840.161997] [<c10ad386>] ? wait_on_page_read+0xf/0x2a
> [ 840.162206] [<c10ae14f>] ? do_read_cache_page+0xfc/0x116
> [ 840.162445] [<c10ff1eb>] ? blkdev_readpages+0x15/0x15
> [ 840.162651] [<c10ae192>] ? read_cache_page+0x14/0x18
> [ 840.162872] [<c1189b0e>] ? read_dev_sector+0x25/0x57
> [ 840.163073] [<c118e22f>] ? read_lba+0x94/0x10b
> [ 840.163289] [<c118e7eb>] ? efi_partition+0xbc/0x451
> [ 840.163506] [<c10b5c33>] ? put_page+0x16/0x24
> [ 840.163732] [<c10ad39d>] ? wait_on_page_read+0x26/0x2a
> [ 840.163968] [<c10ff1eb>] ? blkdev_readpages+0x15/0x15
> [ 840.164348] [<c10ae192>] ? read_cache_page+0x14/0x18
> [ 840.164541] [<c118a8a8>] ? adfspart_check_ICS+0x30/0x1ac
> [ 840.164777] [<c119a3f1>] ? vsnprintf+0x78/0x25d
> [ 840.164977] [<c119a614>] ? snprintf+0x16/0x18
> [ 840.165187] [<c118a7ea>] ? check_partition+0xd7/0x165
> [ 840.165382] [<c118a067>] ? rescan_partitions+0x95/0x283
> [ 840.165603] [<c1254b50>] ? scsi_block_when_processing_errors+0x13/0xae
> [ 840.165829] [<c139cbc6>] ? mutex_lock+0x9/0x21
> [ 840.166066] [<c1100046>] ? __blkdev_get+0x155/0x2f6
> [ 840.166270] [<c110032f>] ? blkdev_get+0x148/0x258
> [ 840.166501] [<c10ec747>] ? unlock_new_inode+0x36/0x3c
> [ 840.166707] [<c10ff106>] ? bdget+0xdc/0xe6
> [ 840.166914] [<c118854f>] ? add_disk+0x221/0x368
> [ 840.167134] [<c126321a>] ? sd_probe_async+0xed/0x157
> [ 840.167372] [<c10443a0>] ? async_run_entry_fn+0x2c/0xad
> [ 840.167582] [<c103f060>] ? process_one_work+0x130/0x21f
> [ 840.167802] [<c103f2f6>] ? worker_thread+0x18a/0x247
> [ 840.168006] [<c103f16c>] ? process_scheduled_works+0x1d/0x1d
> [ 840.168416] [<c1042c46>] ? kthread+0x7c/0x81
> [ 840.168642] [<c139e201>] ? ret_from_kernel_thread+0x21/0x30
> [ 840.168847] [<c1042bca>] ? kthread_parkme+0x11/0x11
> [ 840.169094] INFO: task modprobe:1977 blocked for more than 120 seconds.
> [ 840.169281] Not tainted 4.3.0-rc1+ #74
> [ 840.169454] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 840.169659] modprobe D 00000040 0 1977 1969 0x00000000
> [ 840.170114] cfb20000 00000086 29042653 00000040 c1525f88 28a83a17 00000040 005bec3c
> [ 840.171368] 00000000 ccdd0000 ffffffff ffffffff d2057280 c139c504 00000000 c104416d
> [ 840.172741] 00000000 cfb20000 c1054a45 c151fd8c c151fd8c d2057280 00000000 ccd621f0
> [ 840.173986] Call Trace:
> [ 840.174200] [<c139c504>] ? schedule+0x5b/0x67
> [ 840.174443] [<c104416d>] ? async_synchronize_cookie_domain+0x73/0x9f
> [ 840.174689] [<c1054a45>] ? abort_exclusive_wait+0x6e/0x6e
> [ 840.174910] [<c10ac9bc>] ? do_init_module+0xa4/0x1a3
> [ 840.175141] [<c107ddb5>] ? load_module+0x14de/0x18ca
> [ 840.175359] [<c107e2a0>] ? SyS_finit_module+0x47/0x56
> [ 840.175607] [<c139e2c0>] ? sysenter_do_call+0x12/0x12
> [ 856.020359] sd 2:0:1:0: [sdb] FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_SENSE
> [ 856.020623] sd 2:0:1:0: [sdb] Sense Key : Aborted Command [current]
> [ 856.020862] sd 2:0:1:0: [sdb] Add. Sense: No additional sense information
> [ 856.021101] sd 2:0:1:0: [sdb] CDB: Read(10) 28 00 00 00 00 02 00 00 02 00
> [ 856.021324] blk_update_request: I/O error, dev sdb, sector 2
> [ 856.021539] Buffer I/O error on dev sdb, logical block 1, async page read
> [ 857.025325] sd 2:0:1:0: [sdb] FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
> [ 857.025596] sd 2:0:1:0: [sdb] CDB: Read(10) 28 00 00 00 00 04 00 00 02 00
> [ 857.025830] blk_update_request: I/O error, dev sdb, sector 4
> [ 857.026043] Buffer I/O error on dev sdb, logical block 2, async page read
>
>
> And a CD-ROM, first without patches:
> [ 655.929795] pnp 01:01.00: activated
> [ 655.939503] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, USLEEP_POLL 3, USLEEP_WAITLONG 1250, options { AUTOPROBE_IRQ PSEUDO_DMA NCR53C400 }
> [ 656.441943] scsi 2:0:2:0: CD-ROM SONY CD-ROM CDU-55S 1.0t PQ: 0 ANSI: 2
> [ 657.829087] scsi 2:0:2:0: Attached scsi generic sg1 type 5
> [ 658.325517] sr 2:0:2:0: [sr0] scsi-1 drive
> [ 658.325731] cdrom: Uniform CD-ROM driver Revision: 3.20
>
> Modprobe succeeded but mount resulted in this & hang:
> [ 694.056266] sr 2:0:2:0: [sr0] aborting command
>
> Then with patches:
>
> [ 109.753273] pnp 01:01.00: activated
> [ 109.763039] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, options { AUTOPROBE_IRQ PSEUDO_DMA }
> [ 115.456294] scsi 2:0:2:0: CD-ROM SONY CD-ROM CDU-55S 1.0t PQ: 0 ANSI: 2
> [ 126.823400] scsi 2:0:2:0: Attached scsi generic sg1 type 5
> [ 126.909680] sr 2:0:2:0: [sr0] scsi-1 drive
> [ 126.909888] cdrom: Uniform CD-ROM driver Revision: 3.20
>
> Modprobe succeeded but mount failed after some time with this:
> [ 1005.149546] sr 2:0:2:0: [sr0] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> [ 1005.149764] sr 2:0:2:0: [sr0] Sense Key : Illegal Request [current]
> [ 1005.149992] sr 2:0:2:0: [sr0] Add. Sense: Logical block address out of range
> [ 1005.150222] sr 2:0:2:0: [sr0] CDB: Read(10) 28 00 00 05 7a 94 00 00 02 00
> [ 1005.150433] blk_update_request: critical target error, dev sr0, sector 1436240
> [ 1005.154101] sr 2:0:2:0: [sr0] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> [ 1005.154309] sr 2:0:2:0: [sr0] Sense Key : Illegal Request [current]
> [ 1005.154533] sr 2:0:2:0: [sr0] Add. Sense: Logical block address out of range
> [ 1005.156209] sr 2:0:2:0: [sr0] CDB: Read(10) 28 00 00 05 7a 94 00 00 02 00
> [ 1005.156404] blk_update_request: critical target error, dev sr0, sector 1436240
> [ 1005.156607] Buffer I/O error on dev sr0, logical block 179530, async page read
>
> mount: unknown filesystem type 'iso9660'
>
>
Thanks for these test results! It looks like READ(10) commands don't work.
I don't know the cause of the failures but it appears to be an old bug.
Did you find any regression?
I gather that your setup here is a QUANTUM LP240S target with Domex 3181
(DTC-436) card and g_NCR5380 module. I've been testing a similar setup:
QUANTUM LPS540S target with a Domex 3191D (DTC-536) card and dmx3191d
module. In both setups PIO is used exclusively, no IRQ is used, and
FLAG_DTC3181E is set. I didn't see any issues in my tests, so your results
are surprising.
Let me know off-list if you want any help to debug this. Unfortunately,
Domex Technology Corporation in Taiwan never responded to my requests for
data on the DTC-536 device so there's probably no point in asking them for
data on the DTC-436 device either.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ondrej Zary <linux@rainbow-software.org> |
|---|---|
| Date | 2015-11-21 14:10 +0100 |
| Message-ID | <qxg5r-5GU-11@gated-at.bofh.it> |
| In reply to | #1274590 |
On Saturday 21 November 2015 02:58:57 Finn Thain wrote:
>
> Hi Ondrej,
>
> On Fri, 20 Nov 2015, Ondrej Zary wrote:
>
> > On Friday 20 November 2015 02:41:19 Finn Thain wrote:
> > >
> > >
> > > My tests involved 3 different scsi targets (two disks and a CD-ROM)
> > > but none of these send a SDTR. Your log says the driver correctly
> > > rejected the SDTR message but that doesn't mean the target actually
> > > went to MSG IN phase and got the message. Do you have any older
> > > targets you can test?
> >
> > Another disk, without patches:
> >
> > [ 84.481582] pnp 01:01.00: activated
> > [ 84.489650] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, USLEEP_POLL 3, USLEEP_WAITLONG 1250, options { AUTOPROBE_IRQ PSEUDO_DMA NCR53C400 }
> > [ 84.953332] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6 PQ: 0 ANSI: 2 CCS
> > [ 86.786475] sd 2:0:1:0: Attached scsi generic sg1 type 0
> > [ 86.793753] sd 2:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234 MiB)
> > [ 86.998555] sd 2:0:1:0: [sdb] Write Protect is off
> > [ 87.406068] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> > [ 118.888271] sd 2:0:1:0: [sdb] aborting command
> > [ 118.888738] sd 2:0:1:0: [sdb] aborting command
> >
> > With patches:
> >
> > [ 258.473748] pnp 01:01.00: activated
> > [ 258.483592] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, options { AUTOPROBE_IRQ PSEUDO_DMA }
> > [ 261.347632] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6 PQ: 0 ANSI: 2 CCS
> > [ 275.560451] sd 2:0:1:0: Attached scsi generic sg1 type 0
> > [ 275.632519] sd 2:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234 MiB)
> > [ 275.635533] sd 2:0:1:0: [sdb] Write Protect is off
> > [ 275.642315] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> > [ 469.076347] sd 2:0:1:0: [sdb] FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_SENSE
> > [ 469.076613] sd 2:0:1:0: [sdb] Sense Key : Aborted Command [current]
> > [ 469.076851] sd 2:0:1:0: [sdb] Add. Sense: No additional sense information
> > [ 469.077086] sd 2:0:1:0: [sdb] CDB: Read(10) 28 00 00 00 00 02 00 00 02 00
> > [ 469.077306] blk_update_request: I/O error, dev sdb, sector 2
> > [ 469.077522] Buffer I/O error on dev sdb, logical block 1, async page read
> > [ 480.108255] INFO: task kworker/u2:2:60 blocked for more than 120 seconds.
> > [ 480.109773] Not tainted 4.3.0-rc1+ #74
> > [ 480.109973] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > [ 480.110179] kworker/u2:2 D 00000040 0 60 2 0x00000000
> > [ 480.110671] Workqueue: events_unbound async_run_entry_fn
> > [ 480.110999] cf9e8780 00000046 2eff25f7 00000040 c117f111 2ee82733 00000040 0016fec4
> > [ 480.112390] 00000000 cfaa6000 00000000 7fffffff c139c7d2 c139c504 7fffffff c139d9d3
> > [ 480.113661] 00000040 cfaa5cfc c106f460 00161108 00000000 0000c648 2106dcce 00000040
> > [ 480.114893] Call Trace:
> > [ 480.115124] [<c117f111>] ? blk_queue_bio+0x1e8/0x1fb
> > [ 480.115344] [<c139c7d2>] ? bit_wait_io_timeout+0x3d/0x3d
> > [ 480.115564] [<c139c504>] ? schedule+0x5b/0x67
> > [ 480.115794] [<c139d9d3>] ? schedule_timeout+0x13/0xc5
> > [ 480.116007] [<c106f460>] ? timekeeping_get_ns+0x10/0x69
> > [ 480.116406] [<c139c7d2>] ? bit_wait_io_timeout+0x3d/0x3d
> > [ 480.116636] [<c106fae7>] ? ktime_get+0x38/0x48
> > [ 480.116843] [<c139bf83>] ? io_schedule_timeout+0x83/0xd7
> > [ 480.117062] [<c139c7f3>] ? bit_wait_io+0x21/0x26
> > [ 480.117256] [<c139c697>] ? __wait_on_bit+0x2f/0x5a
> > [ 480.117486] [<c10ff1eb>] ? blkdev_readpages+0x15/0x15
> > [ 480.117704] [<c10ad361>] ? wait_on_page_bit+0x57/0x5e
> > [ 480.117942] [<c1054a98>] ? wake_atomic_t_function+0x2a/0x2a
> > [ 480.118151] [<c10ad386>] ? wait_on_page_read+0xf/0x2a
> > [ 480.118373] [<c10ae0e1>] ? do_read_cache_page+0x8e/0x116
> > [ 480.118587] [<c10ff1eb>] ? blkdev_readpages+0x15/0x15
> > [ 480.118809] [<c10ae192>] ? read_cache_page+0x14/0x18
> > [ 480.119008] [<c1189b0e>] ? read_dev_sector+0x25/0x57
> > [ 480.119222] [<c118a8a8>] ? adfspart_check_ICS+0x30/0x1ac
> > [ 480.119438] [<c119a3f1>] ? vsnprintf+0x78/0x25d
> > [ 480.119671] [<c119a614>] ? snprintf+0x16/0x18
> > [ 480.119874] [<c118a7ea>] ? check_partition+0xd7/0x165
> > [ 480.120253] [<c118a067>] ? rescan_partitions+0x95/0x283
> > [ 480.120443] [<c1254b50>] ? scsi_block_when_processing_errors+0x13/0xae
> > [ 480.120693] [<c139cbc6>] ? mutex_lock+0x9/0x21
> > [ 480.120915] [<c1100046>] ? __blkdev_get+0x155/0x2f6
> > [ 480.121133] [<c110032f>] ? blkdev_get+0x148/0x258
> > [ 480.121350] [<c10ec747>] ? unlock_new_inode+0x36/0x3c
> > [ 480.121570] [<c10ff106>] ? bdget+0xdc/0xe6
> > [ 480.121761] [<c118854f>] ? add_disk+0x221/0x368
> > [ 480.121996] [<c126321a>] ? sd_probe_async+0xed/0x157
> > [ 480.122214] [<c10443a0>] ? async_run_entry_fn+0x2c/0xad
> > [ 480.122437] [<c103f060>] ? process_one_work+0x130/0x21f
> > [ 480.122639] [<c103f2f6>] ? worker_thread+0x18a/0x247
> > [ 480.122854] [<c103f16c>] ? process_scheduled_works+0x1d/0x1d
> > [ 480.123069] [<c1042c46>] ? kthread+0x7c/0x81
> > [ 480.123288] [<c139e201>] ? ret_from_kernel_thread+0x21/0x30
> > [ 480.123493] [<c1042bca>] ? kthread_parkme+0x11/0x11
> > [ 480.123733] INFO: task modprobe:1977 blocked for more than 120 seconds.
> > [ 480.123919] Not tainted 4.3.0-rc1+ #74
> > [ 480.124239] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > [ 480.124410] modprobe D 00000040 0 1977 1969 0x00000000
> > [ 480.124864] cfb20000 00000086 29042653 00000040 c1525f88 28a83a17 00000040 005bec3c
> > [ 480.126123] 00000000 ccdd0000 ffffffff ffffffff d2057280 c139c504 00000000 c104416d
> > [ 480.127354] 00000000 cfb20000 c1054a45 c151fd8c c151fd8c d2057280 00000000 ccd621f0
> > [ 480.128746] Call Trace:
> > [ 480.128961] [<c139c504>] ? schedule+0x5b/0x67
> > [ 480.129202] [<c104416d>] ? async_synchronize_cookie_domain+0x73/0x9f
> > [ 480.129449] [<c1054a45>] ? abort_exclusive_wait+0x6e/0x6e
> > [ 480.129667] [<c10ac9bc>] ? do_init_module+0xa4/0x1a3
> > [ 480.129899] [<c107ddb5>] ? load_module+0x14de/0x18ca
> > [ 480.130119] [<c107e2a0>] ? SyS_finit_module+0x47/0x56
> > [ 480.130346] [<c139e2c0>] ? sysenter_do_call+0x12/0x12
> > [ 502.100317] sd 2:0:1:0: [sdb] FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_SENSE
> > [ 502.100578] sd 2:0:1:0: [sdb] Sense Key : Aborted Command [current]
> > [ 502.100818] sd 2:0:1:0: [sdb] Add. Sense: No additional sense information
> > [ 502.101057] sd 2:0:1:0: [sdb] CDB: Read(10) 28 00 00 00 00 04 00 00 02 00
> > [ 502.101279] blk_update_request: I/O error, dev sdb, sector 4
> > [ 502.101495] Buffer I/O error on dev sdb, logical block 2, async page read
> > [ 600.128255] INFO: task kworker/u2:2:60 blocked for more than 120 seconds.
> > [ 600.128486] Not tainted 4.3.0-rc1+ #74
> > [ 600.128687] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > [ 600.128891] kworker/u2:2 D 00000040 0 60 2 0x00000000
> > [ 600.129381] Workqueue: events_unbound async_run_entry_fn
> > [ 600.129709] cf9e8780 00000046 2eff25f7 00000040 c117f111 2ee82733 00000040 0016fec4
> > [ 600.130941] 00000000 cfaa6000 00000000 7fffffff c139c7d2 c139c504 7fffffff c139d9d3
> > [ 600.132342] 00000040 cfaa5cfc c106f460 00161108 00000000 0000c648 2106dcce 00000040
> > [ 600.133613] Call Trace:
> > [ 600.133821] [<c117f111>] ? blk_queue_bio+0x1e8/0x1fb
> > [ 600.134065] [<c139c7d2>] ? bit_wait_io_timeout+0x3d/0x3d
> > [ 600.134283] [<c139c504>] ? schedule+0x5b/0x67
> > [ 600.134509] [<c139d9d3>] ? schedule_timeout+0x13/0xc5
> > [ 600.134723] [<c106f460>] ? timekeeping_get_ns+0x10/0x69
> > [ 600.134948] [<c139c7d2>] ? bit_wait_io_timeout+0x3d/0x3d
> > [ 600.135154] [<c106fae7>] ? ktime_get+0x38/0x48
> > [ 600.135377] [<c139bf83>] ? io_schedule_timeout+0x83/0xd7
> > [ 600.135576] [<c139c7f3>] ? bit_wait_io+0x21/0x26
> > [ 600.135788] [<c139c697>] ? __wait_on_bit+0x2f/0x5a
> > [ 600.136000] [<c10ff1eb>] ? blkdev_readpages+0x15/0x15
> > [ 600.136399] [<c10ad361>] ? wait_on_page_bit+0x57/0x5e
> > [ 600.136607] [<c1054a98>] ? wake_atomic_t_function+0x2a/0x2a
> > [ 600.136838] [<c10ad386>] ? wait_on_page_read+0xf/0x2a
> > [ 600.137044] [<c10ae0e1>] ? do_read_cache_page+0x8e/0x116
> > [ 600.137276] [<c10ff1eb>] ? blkdev_readpages+0x15/0x15
> > [ 600.137481] [<c10ae192>] ? read_cache_page+0x14/0x18
> > [ 600.137699] [<c1189b0e>] ? read_dev_sector+0x25/0x57
> > [ 600.137901] [<c118a8a8>] ? adfspart_check_ICS+0x30/0x1ac
> > [ 600.138131] [<c119a3f1>] ? vsnprintf+0x78/0x25d
> > [ 600.138329] [<c119a614>] ? snprintf+0x16/0x18
> > [ 600.138544] [<c118a7ea>] ? check_partition+0xd7/0x165
> > [ 600.138738] [<c118a067>] ? rescan_partitions+0x95/0x283
> > [ 600.138962] [<c1254b50>] ? scsi_block_when_processing_errors+0x13/0xae
> > [ 600.139189] [<c139cbc6>] ? mutex_lock+0x9/0x21
> > [ 600.139427] [<c1100046>] ? __blkdev_get+0x155/0x2f6
> > [ 600.139632] [<c110032f>] ? blkdev_get+0x148/0x258
> > [ 600.139865] [<c10ec747>] ? unlock_new_inode+0x36/0x3c
> > [ 600.140263] [<c10ff106>] ? bdget+0xdc/0xe6
> > [ 600.140448] [<c118854f>] ? add_disk+0x221/0x368
> > [ 600.140689] [<c126321a>] ? sd_probe_async+0xed/0x157
> > [ 600.140908] [<c10443a0>] ? async_run_entry_fn+0x2c/0xad
> > [ 600.141133] [<c103f060>] ? process_one_work+0x130/0x21f
> > [ 600.141336] [<c103f2f6>] ? worker_thread+0x18a/0x247
> > [ 600.141552] [<c103f16c>] ? process_scheduled_works+0x1d/0x1d
> > [ 600.141764] [<c1042c46>] ? kthread+0x7c/0x81
> > [ 600.141982] [<c139e201>] ? ret_from_kernel_thread+0x21/0x30
> > [ 600.142186] [<c1042bca>] ? kthread_parkme+0x11/0x11
> > [ 600.142426] INFO: task modprobe:1977 blocked for more than 120 seconds.
> > [ 600.142612] Not tainted 4.3.0-rc1+ #74
> > [ 600.142787] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > [ 600.142991] modprobe D 00000040 0 1977 1969 0x00000000
> > [ 600.143444] cfb20000 00000086 29042653 00000040 c1525f88 28a83a17 00000040 005bec3c
> > [ 600.144819] 00000000 ccdd0000 ffffffff ffffffff d2057280 c139c504 00000000 c104416d
> > [ 600.146052] 00000000 cfb20000 c1054a45 c151fd8c c151fd8c d2057280 00000000 ccd621f0
> > [ 600.147279] Call Trace:
> > [ 600.147489] [<c139c504>] ? schedule+0x5b/0x67
> > [ 600.147729] [<c104416d>] ? async_synchronize_cookie_domain+0x73/0x9f
> > [ 600.147992] [<c1054a45>] ? abort_exclusive_wait+0x6e/0x6e
> > [ 600.148390] [<c10ac9bc>] ? do_init_module+0xa4/0x1a3
> > [ 600.148627] [<c107ddb5>] ? load_module+0x14de/0x18ca
> > [ 600.148846] [<c107e2a0>] ? SyS_finit_module+0x47/0x56
> > [ 600.149073] [<c139e2c0>] ? sysenter_do_call+0x12/0x12
> > [ 662.100333] sd 2:0:1:0: [sdb] FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_SENSE
> > [ 662.100598] sd 2:0:1:0: [sdb] Sense Key : Aborted Command [current]
> > [ 662.100838] sd 2:0:1:0: [sdb] Add. Sense: No additional sense information
> > [ 662.101076] sd 2:0:1:0: [sdb] CDB: Read(10) 28 00 00 00 00 06 00 00 02 00
> > [ 662.101297] blk_update_request: I/O error, dev sdb, sector 6
> > [ 662.101512] Buffer I/O error on dev sdb, logical block 3, async page read
> > [ 720.148270] INFO: task modprobe:1977 blocked for more than 120 seconds.
> > [ 720.148499] Not tainted 4.3.0-rc1+ #74
> > [ 720.148699] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > [ 720.148903] modprobe D 00000040 0 1977 1969 0x00000000
> > [ 720.149360] cfb20000 00000086 29042653 00000040 c1525f88 28a83a17 00000040 005bec3c
> > [ 720.150615] 00000000 ccdd0000 ffffffff ffffffff d2057280 c139c504 00000000 c104416d
> > [ 720.151836] 00000000 cfb20000 c1054a45 c151fd8c c151fd8c d2057280 00000000 ccd621f0
> > [ 720.153221] Call Trace:
> > [ 720.153465] [<c139c504>] ? schedule+0x5b/0x67
> > [ 720.153689] [<c104416d>] ? async_synchronize_cookie_domain+0x73/0x9f
> > [ 720.153931] [<c1054a45>] ? abort_exclusive_wait+0x6e/0x6e
> > [ 720.154149] [<c10ac9bc>] ? do_init_module+0xa4/0x1a3
> > [ 720.154379] [<c107ddb5>] ? load_module+0x14de/0x18ca
> > [ 720.154593] [<c107e2a0>] ? SyS_finit_module+0x47/0x56
> > [ 720.154820] [<c139e2c0>] ? sysenter_do_call+0x12/0x12
> > [ 781.025039] systemd-logind[1942]: New session c2 of user rainbow.
> > [ 840.152254] INFO: task kworker/u2:2:60 blocked for more than 120 seconds.
> > [ 840.152486] Not tainted 4.3.0-rc1+ #74
> > [ 840.152693] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > [ 840.152903] kworker/u2:2 D 0000009a 0 60 2 0x00000000
> > [ 840.153399] Workqueue: events_unbound async_run_entry_fn
> > [ 840.153730] cf9e8780 00000046 2860b1ff 0000009a c117f111 284404dd 0000009a 001cad22
> > [ 840.156408] 00000000 cfaa6000 00000000 7fffffff c139c7d2 c139c504 7fffffff c139d9d3
> > [ 840.157689] 0000009a cfaa5c64 c106f460 00161e18 00000000 00013d94 006b70ce 0000009a
> > [ 840.158925] Call Trace:
> > [ 840.159158] [<c117f111>] ? blk_queue_bio+0x1e8/0x1fb
> > [ 840.159379] [<c139c7d2>] ? bit_wait_io_timeout+0x3d/0x3d
> > [ 840.159600] [<c139c504>] ? schedule+0x5b/0x67
> > [ 840.159834] [<c139d9d3>] ? schedule_timeout+0x13/0xc5
> > [ 840.160052] [<c106f460>] ? timekeeping_get_ns+0x10/0x69
> > [ 840.160446] [<c139c7d2>] ? bit_wait_io_timeout+0x3d/0x3d
> > [ 840.160677] [<c106fae7>] ? ktime_get+0x38/0x48
> > [ 840.160884] [<c139bf83>] ? io_schedule_timeout+0x83/0xd7
> > [ 840.161105] [<c139c7f3>] ? bit_wait_io+0x21/0x26
> > [ 840.161306] [<c139c697>] ? __wait_on_bit+0x2f/0x5a
> > [ 840.161541] [<c10ad361>] ? wait_on_page_bit+0x57/0x5e
> > [ 840.161767] [<c1054a98>] ? wake_atomic_t_function+0x2a/0x2a
> > [ 840.161997] [<c10ad386>] ? wait_on_page_read+0xf/0x2a
> > [ 840.162206] [<c10ae14f>] ? do_read_cache_page+0xfc/0x116
> > [ 840.162445] [<c10ff1eb>] ? blkdev_readpages+0x15/0x15
> > [ 840.162651] [<c10ae192>] ? read_cache_page+0x14/0x18
> > [ 840.162872] [<c1189b0e>] ? read_dev_sector+0x25/0x57
> > [ 840.163073] [<c118e22f>] ? read_lba+0x94/0x10b
> > [ 840.163289] [<c118e7eb>] ? efi_partition+0xbc/0x451
> > [ 840.163506] [<c10b5c33>] ? put_page+0x16/0x24
> > [ 840.163732] [<c10ad39d>] ? wait_on_page_read+0x26/0x2a
> > [ 840.163968] [<c10ff1eb>] ? blkdev_readpages+0x15/0x15
> > [ 840.164348] [<c10ae192>] ? read_cache_page+0x14/0x18
> > [ 840.164541] [<c118a8a8>] ? adfspart_check_ICS+0x30/0x1ac
> > [ 840.164777] [<c119a3f1>] ? vsnprintf+0x78/0x25d
> > [ 840.164977] [<c119a614>] ? snprintf+0x16/0x18
> > [ 840.165187] [<c118a7ea>] ? check_partition+0xd7/0x165
> > [ 840.165382] [<c118a067>] ? rescan_partitions+0x95/0x283
> > [ 840.165603] [<c1254b50>] ? scsi_block_when_processing_errors+0x13/0xae
> > [ 840.165829] [<c139cbc6>] ? mutex_lock+0x9/0x21
> > [ 840.166066] [<c1100046>] ? __blkdev_get+0x155/0x2f6
> > [ 840.166270] [<c110032f>] ? blkdev_get+0x148/0x258
> > [ 840.166501] [<c10ec747>] ? unlock_new_inode+0x36/0x3c
> > [ 840.166707] [<c10ff106>] ? bdget+0xdc/0xe6
> > [ 840.166914] [<c118854f>] ? add_disk+0x221/0x368
> > [ 840.167134] [<c126321a>] ? sd_probe_async+0xed/0x157
> > [ 840.167372] [<c10443a0>] ? async_run_entry_fn+0x2c/0xad
> > [ 840.167582] [<c103f060>] ? process_one_work+0x130/0x21f
> > [ 840.167802] [<c103f2f6>] ? worker_thread+0x18a/0x247
> > [ 840.168006] [<c103f16c>] ? process_scheduled_works+0x1d/0x1d
> > [ 840.168416] [<c1042c46>] ? kthread+0x7c/0x81
> > [ 840.168642] [<c139e201>] ? ret_from_kernel_thread+0x21/0x30
> > [ 840.168847] [<c1042bca>] ? kthread_parkme+0x11/0x11
> > [ 840.169094] INFO: task modprobe:1977 blocked for more than 120 seconds.
> > [ 840.169281] Not tainted 4.3.0-rc1+ #74
> > [ 840.169454] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > [ 840.169659] modprobe D 00000040 0 1977 1969 0x00000000
> > [ 840.170114] cfb20000 00000086 29042653 00000040 c1525f88 28a83a17 00000040 005bec3c
> > [ 840.171368] 00000000 ccdd0000 ffffffff ffffffff d2057280 c139c504 00000000 c104416d
> > [ 840.172741] 00000000 cfb20000 c1054a45 c151fd8c c151fd8c d2057280 00000000 ccd621f0
> > [ 840.173986] Call Trace:
> > [ 840.174200] [<c139c504>] ? schedule+0x5b/0x67
> > [ 840.174443] [<c104416d>] ? async_synchronize_cookie_domain+0x73/0x9f
> > [ 840.174689] [<c1054a45>] ? abort_exclusive_wait+0x6e/0x6e
> > [ 840.174910] [<c10ac9bc>] ? do_init_module+0xa4/0x1a3
> > [ 840.175141] [<c107ddb5>] ? load_module+0x14de/0x18ca
> > [ 840.175359] [<c107e2a0>] ? SyS_finit_module+0x47/0x56
> > [ 840.175607] [<c139e2c0>] ? sysenter_do_call+0x12/0x12
> > [ 856.020359] sd 2:0:1:0: [sdb] FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_SENSE
> > [ 856.020623] sd 2:0:1:0: [sdb] Sense Key : Aborted Command [current]
> > [ 856.020862] sd 2:0:1:0: [sdb] Add. Sense: No additional sense information
> > [ 856.021101] sd 2:0:1:0: [sdb] CDB: Read(10) 28 00 00 00 00 02 00 00 02 00
> > [ 856.021324] blk_update_request: I/O error, dev sdb, sector 2
> > [ 856.021539] Buffer I/O error on dev sdb, logical block 1, async page read
> > [ 857.025325] sd 2:0:1:0: [sdb] FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
> > [ 857.025596] sd 2:0:1:0: [sdb] CDB: Read(10) 28 00 00 00 00 04 00 00 02 00
> > [ 857.025830] blk_update_request: I/O error, dev sdb, sector 4
> > [ 857.026043] Buffer I/O error on dev sdb, logical block 2, async page read
> >
> >
> > And a CD-ROM, first without patches:
> > [ 655.929795] pnp 01:01.00: activated
> > [ 655.939503] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, USLEEP_POLL 3, USLEEP_WAITLONG 1250, options { AUTOPROBE_IRQ PSEUDO_DMA NCR53C400 }
> > [ 656.441943] scsi 2:0:2:0: CD-ROM SONY CD-ROM CDU-55S 1.0t PQ: 0 ANSI: 2
> > [ 657.829087] scsi 2:0:2:0: Attached scsi generic sg1 type 5
> > [ 658.325517] sr 2:0:2:0: [sr0] scsi-1 drive
> > [ 658.325731] cdrom: Uniform CD-ROM driver Revision: 3.20
> >
> > Modprobe succeeded but mount resulted in this & hang:
> > [ 694.056266] sr 2:0:2:0: [sr0] aborting command
> >
> > Then with patches:
> >
> > [ 109.753273] pnp 01:01.00: activated
> > [ 109.763039] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, options { AUTOPROBE_IRQ PSEUDO_DMA }
> > [ 115.456294] scsi 2:0:2:0: CD-ROM SONY CD-ROM CDU-55S 1.0t PQ: 0 ANSI: 2
> > [ 126.823400] scsi 2:0:2:0: Attached scsi generic sg1 type 5
> > [ 126.909680] sr 2:0:2:0: [sr0] scsi-1 drive
> > [ 126.909888] cdrom: Uniform CD-ROM driver Revision: 3.20
> >
> > Modprobe succeeded but mount failed after some time with this:
> > [ 1005.149546] sr 2:0:2:0: [sr0] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> > [ 1005.149764] sr 2:0:2:0: [sr0] Sense Key : Illegal Request [current]
> > [ 1005.149992] sr 2:0:2:0: [sr0] Add. Sense: Logical block address out of range
> > [ 1005.150222] sr 2:0:2:0: [sr0] CDB: Read(10) 28 00 00 05 7a 94 00 00 02 00
> > [ 1005.150433] blk_update_request: critical target error, dev sr0, sector 1436240
> > [ 1005.154101] sr 2:0:2:0: [sr0] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> > [ 1005.154309] sr 2:0:2:0: [sr0] Sense Key : Illegal Request [current]
> > [ 1005.154533] sr 2:0:2:0: [sr0] Add. Sense: Logical block address out of range
> > [ 1005.156209] sr 2:0:2:0: [sr0] CDB: Read(10) 28 00 00 05 7a 94 00 00 02 00
> > [ 1005.156404] blk_update_request: critical target error, dev sr0, sector 1436240
> > [ 1005.156607] Buffer I/O error on dev sr0, logical block 179530, async page read
> >
> > mount: unknown filesystem type 'iso9660'
> >
> >
>
> Thanks for these test results! It looks like READ(10) commands don't work.
> I don't know the cause of the failures but it appears to be an old bug.
> Did you find any regression?
>
> I gather that your setup here is a QUANTUM LP240S target with Domex 3181
> (DTC-436) card and g_NCR5380 module. I've been testing a similar setup:
> QUANTUM LPS540S target with a Domex 3191D (DTC-536) card and dmx3191d
> module. In both setups PIO is used exclusively, no IRQ is used, and
> FLAG_DTC3181E is set. I didn't see any issues in my tests, so your results
> are surprising.
I agree that the results are surprising. Even tried 2.4 kernels (Debian 3.1)
and even 2.2 (Debian 3.0) and nothing worked.
HW is fine - the drive is accessible in Windows 98 (with Domex driver
installed).
Now testing the Canon FG2-5202 controller - a simple 8-bit ISA card with only
two chips: NCR 53C400 and 74LS245. It's memory mapped, IRQ hardwired to 7.
# modprobe g_NCR5380_mmio ncr_irq=255 ncr_addr=0xd8000 ncr_53c400=1
[ 1245.919223] scsi2 : interrupts not enabled. for better interactive performance,
[ 1245.919326] scsi2 : please jumper the board for a free IRQ.
[ 1245.919389] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0, n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { NCR53C400 }, USLEEP_POLL 3, USLEEP_WAITLONG 1250, options { AUTOPROBE_IRQ PSEUDO_DMA NCR53C400 }
[ 1246.376738] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6 PQ: 0 ANSI: 2 CCS
[ 1248.202198] sd 2:0:1:0: Attached scsi generic sg1 type 0
[ 1248.420856] 53C400r: no 53C80 gated irq after transfer
[ 1248.420948] 53C400r: no end dma signal
[ 1248.422459] sd 2:0:1:0: [sdb] Sector size 0 reported, assuming 512.
Seems that the PSEUDO_DMA is broken. After adding FLAG_NO_PSEUDO_DMA:
# modprobe g_NCR5380_mmio ncr_irq=255 ncr_addr=0xd8000 ncr_53c400=1
[ 67.974362] scsi2 : interrupts not enabled. for better interactive performance,
[ 67.974463] scsi2 : please jumper the board for a free IRQ.
[ 67.974526] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0, n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { NCR53C400 NO_PSEUDO_DMA }, USLEEP_POLL 3, USLEEP_WAITLONG 1250, options { AUTOPROBE_IRQ PSEUDO_DMA NCR53C400 }
[ 68.432728] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6 PQ: 0 ANSI: 2 CCS
[ 70.258258] sd 2:0:1:0: Attached scsi generic sg1 type 0
[ 70.277265] sd 2:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234 MiB)
[ 70.482252] sd 2:0:1:0: [sdb] Write Protect is off
[ 70.482335] sd 2:0:1:0: [sdb] Mode Sense: 8b 00 00 08
[ 70.889646] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 73.159513] sdb: sdb1
[ 74.617099] sd 2:0:1:0: [sdb] Attached SCSI disk
Yeah, first success! I can even mount the filesystem, although it takes ages
(a minute) and these messages:
[ 160.872074] sd 2:0:1:0: [sdb] aborting command
[ 161.816083] sd 2:0:1:0: [sdb] aborting command
# hdparm -t --direct /dev/sdb
/dev/sdb:
[ 244.840075] sd 2:0:1:0: [sdb] aborting command
[ 248.824078] sd 2:0:1:0: [sdb] aborting command
[ 293.864069] sd 2:0:1:0: [sdb] aborting command
[ 297.824075] sd 2:0:1:0: [sdb] aborting command
[ 319.765020] blk_update_request: critical target error, dev sdb, sector 0
[ 319.972994] blk_update_request: critical target error, dev sdb, sector 0
Timing O_DIRECT disk reads: 2 MB in 105.26 seconds = 19.46 kB/sec
With your patches (and adding FLAG_NO_PSEUDO_DMA), modprobe is slower but
mount faster (4 seconds) and then works better:
# modprobe g_NCR5380_mmio ncr_irq=255 ncr_addr=0xd8000 ncr_53c400=1
[ 130.126185] scsi2 : interrupts not enabled. for better interactive performance,
[ 130.126284] scsi2 : please jumper the board for a free IRQ.
[ 130.126347] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0, n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { NO_PSEUDO_DMA }, options { AUTOPROBE_IRQ PSEUDO_DMA }
[ 145.221755] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6 PQ: 0 ANSI: 2 CCS
[ 220.629912] sd 2:0:1:0: Attached scsi generic sg1 type 0
[ 220.651400] sd 2:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234 MiB)
[ 220.654061] sd 2:0:1:0: [sdb] Write Protect is off
[ 220.659344] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 220.732415] sdb: sdb1
[ 220.749760] sd 2:0:1:0: [sdb] Attached SCSI disk
# hdparm -t --direct /dev/sdb
/dev/sdb:
Timing O_DIRECT disk reads: 2 MB in 18.25 seconds = 112.20 kB/sec
IRQ seems to work too, although driver always shows "irq 0":
# modprobe g_NCR5380_mmio ncr_irq=7 ncr_addr=0xd8000 ncr_53c400=1
[ 117.263062] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0, n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { NO_PSEUDO_DMA }, options { AUTOPROBE_IRQ PSEUDO_DMA }
[ 132.357474] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6 PQ: 0 ANSI: 2 CCS
[ 207.765080] sd 2:0:1:0: Attached scsi generic sg1 type 0
[ 207.783415] sd 2:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234 MiB)
[ 207.786167] sd 2:0:1:0: [sdb] Write Protect is off
[ 207.790260] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 207.859669] sdb: sdb1
[ 207.876556] sd 2:0:1:0: [sdb] Attached SCSI disk
# hdparm -t --direct /dev/sdb
/dev/sdb:
Timing O_DIRECT disk reads: 2 MB in 18.30 seconds = 111.94 kB/sec
# mount /dev/sdb1 /mnt
# umount /mnt
# head /proc/interrupts
CPU0
0: 44793 XT-PIC timer
1: 9 XT-PIC i8042
2: 0 XT-PIC cascade
7: 86 XT-PIC NCR5380
8: 1 XT-PIC rtc0
9: 0 XT-PIC uhci_hcd:usb1, uhci_hcd:usb2
10: 1179 XT-PIC eth0
12: 136 XT-PIC i8042
14: 3411 XT-PIC pata_via
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ondrej Zary <linux@rainbow-software.org> |
|---|---|
| Date | 2015-11-22 00:10 +0100 |
| Message-ID | <qxps5-3E3-11@gated-at.bofh.it> |
| In reply to | #1274645 |
On Saturday 21 November 2015 14:01:39 Ondrej Zary wrote:
> On Saturday 21 November 2015 02:58:57 Finn Thain wrote:
> >
> > Hi Ondrej,
> >
> > On Fri, 20 Nov 2015, Ondrej Zary wrote:
> >
> > > On Friday 20 November 2015 02:41:19 Finn Thain wrote:
> > > >
> > > >
> > > > My tests involved 3 different scsi targets (two disks and a CD-ROM)
> > > > but none of these send a SDTR. Your log says the driver correctly
> > > > rejected the SDTR message but that doesn't mean the target actually
> > > > went to MSG IN phase and got the message. Do you have any older
> > > > targets you can test?
> > >
[...]
> > >
> >
> > Thanks for these test results! It looks like READ(10) commands don't work.
> > I don't know the cause of the failures but it appears to be an old bug.
> > Did you find any regression?
> >
> > I gather that your setup here is a QUANTUM LP240S target with Domex 3181
> > (DTC-436) card and g_NCR5380 module. I've been testing a similar setup:
> > QUANTUM LPS540S target with a Domex 3191D (DTC-536) card and dmx3191d
> > module. In both setups PIO is used exclusively, no IRQ is used, and
> > FLAG_DTC3181E is set. I didn't see any issues in my tests, so your results
> > are surprising.
>
> I agree that the results are surprising. Even tried 2.4 kernels (Debian 3.1)
> and even 2.2 (Debian 3.0) and nothing worked.
> HW is fine - the drive is accessible in Windows 98 (with Domex driver
> installed).
>
> Now testing the Canon FG2-5202 controller - a simple 8-bit ISA card with only
> two chips: NCR 53C400 and 74LS245. It's memory mapped, IRQ hardwired to 7.
>
> # modprobe g_NCR5380_mmio ncr_irq=255 ncr_addr=0xd8000 ncr_53c400=1
>
> [ 1245.919223] scsi2 : interrupts not enabled. for better interactive performance,
> [ 1245.919326] scsi2 : please jumper the board for a free IRQ.
> [ 1245.919389] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0, n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { NCR53C400 }, USLEEP_POLL 3, USLEEP_WAITLONG 1250, options { AUTOPROBE_IRQ PSEUDO_DMA NCR53C400 }
> [ 1246.376738] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6 PQ: 0 ANSI: 2 CCS
> [ 1248.202198] sd 2:0:1:0: Attached scsi generic sg1 type 0
> [ 1248.420856] 53C400r: no 53C80 gated irq after transfer
> [ 1248.420948] 53C400r: no end dma signal
> [ 1248.422459] sd 2:0:1:0: [sdb] Sector size 0 reported, assuming 512.
>
> Seems that the PSEUDO_DMA is broken. After adding FLAG_NO_PSEUDO_DMA:
>
> # modprobe g_NCR5380_mmio ncr_irq=255 ncr_addr=0xd8000 ncr_53c400=1
>
> [ 67.974362] scsi2 : interrupts not enabled. for better interactive performance,
> [ 67.974463] scsi2 : please jumper the board for a free IRQ.
> [ 67.974526] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0, n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { NCR53C400 NO_PSEUDO_DMA }, USLEEP_POLL 3, USLEEP_WAITLONG 1250, options { AUTOPROBE_IRQ PSEUDO_DMA NCR53C400 }
> [ 68.432728] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6 PQ: 0 ANSI: 2 CCS
> [ 70.258258] sd 2:0:1:0: Attached scsi generic sg1 type 0
> [ 70.277265] sd 2:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234 MiB)
> [ 70.482252] sd 2:0:1:0: [sdb] Write Protect is off
> [ 70.482335] sd 2:0:1:0: [sdb] Mode Sense: 8b 00 00 08
> [ 70.889646] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> [ 73.159513] sdb: sdb1
> [ 74.617099] sd 2:0:1:0: [sdb] Attached SCSI disk
>
> Yeah, first success! I can even mount the filesystem, although it takes ages
> (a minute) and these messages:
> [ 160.872074] sd 2:0:1:0: [sdb] aborting command
> [ 161.816083] sd 2:0:1:0: [sdb] aborting command
>
> # hdparm -t --direct /dev/sdb
>
> /dev/sdb:
> [ 244.840075] sd 2:0:1:0: [sdb] aborting command
> [ 248.824078] sd 2:0:1:0: [sdb] aborting command
> [ 293.864069] sd 2:0:1:0: [sdb] aborting command
> [ 297.824075] sd 2:0:1:0: [sdb] aborting command
> [ 319.765020] blk_update_request: critical target error, dev sdb, sector 0
> [ 319.972994] blk_update_request: critical target error, dev sdb, sector 0
> Timing O_DIRECT disk reads: 2 MB in 105.26 seconds = 19.46 kB/sec
>
>
>
> With your patches (and adding FLAG_NO_PSEUDO_DMA), modprobe is slower but
> mount faster (4 seconds) and then works better:
>
> # modprobe g_NCR5380_mmio ncr_irq=255 ncr_addr=0xd8000 ncr_53c400=1
>
> [ 130.126185] scsi2 : interrupts not enabled. for better interactive performance,
> [ 130.126284] scsi2 : please jumper the board for a free IRQ.
> [ 130.126347] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0, n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { NO_PSEUDO_DMA }, options { AUTOPROBE_IRQ PSEUDO_DMA }
> [ 145.221755] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6 PQ: 0 ANSI: 2 CCS
> [ 220.629912] sd 2:0:1:0: Attached scsi generic sg1 type 0
> [ 220.651400] sd 2:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234 MiB)
> [ 220.654061] sd 2:0:1:0: [sdb] Write Protect is off
> [ 220.659344] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> [ 220.732415] sdb: sdb1
> [ 220.749760] sd 2:0:1:0: [sdb] Attached SCSI disk
>
> # hdparm -t --direct /dev/sdb
>
> /dev/sdb:
> Timing O_DIRECT disk reads: 2 MB in 18.25 seconds = 112.20 kB/sec
>
>
>
> IRQ seems to work too, although driver always shows "irq 0":
>
> # modprobe g_NCR5380_mmio ncr_irq=7 ncr_addr=0xd8000 ncr_53c400=1
>
> [ 117.263062] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0, n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { NO_PSEUDO_DMA }, options { AUTOPROBE_IRQ PSEUDO_DMA }
> [ 132.357474] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6 PQ: 0 ANSI: 2 CCS
> [ 207.765080] sd 2:0:1:0: Attached scsi generic sg1 type 0
> [ 207.783415] sd 2:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234 MiB)
> [ 207.786167] sd 2:0:1:0: [sdb] Write Protect is off
> [ 207.790260] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> [ 207.859669] sdb: sdb1
> [ 207.876556] sd 2:0:1:0: [sdb] Attached SCSI disk
>
> # hdparm -t --direct /dev/sdb
>
> /dev/sdb:
> Timing O_DIRECT disk reads: 2 MB in 18.30 seconds = 111.94 kB/sec
>
> # mount /dev/sdb1 /mnt
> # umount /mnt
> # head /proc/interrupts
> CPU0
> 0: 44793 XT-PIC timer
> 1: 9 XT-PIC i8042
> 2: 0 XT-PIC cascade
> 7: 86 XT-PIC NCR5380
> 8: 1 XT-PIC rtc0
> 9: 0 XT-PIC uhci_hcd:usb1, uhci_hcd:usb2
> 10: 1179 XT-PIC eth0
> 12: 136 XT-PIC i8042
> 14: 3411 XT-PIC pata_via
>
Even the HP C2502 (that never worked) works now. It's 8-bit card based on
NCR 53C400A (there are also 74ALS245 and 3 PALCE chips).
Configuration is by using magic numbers, wrote a simple userspace enabler:
#include <stdio.h>
#include <sys/io.h>
const unsigned short io_ports[] = { 0x280, 0x290, 0x300, 0x310, 0x330, 0x340, 0x348, 0x350 };
/* IRQs: 2,3,4,5,7 */
void configure_hp400a(int idx, unsigned char irq) {
unsigned char b = 0;
outb(0x0f, 0x779);
outb(0x22, 0x379);
outb(0xf0, 0x379);
outb(0x20, 0x379);
outb(0x80, 0x379);
if (irq != 2 && irq != 3 && irq != 4 && irq != 5 && irq != 7)
irq = 0;
if (idx >= 0 && idx <= 7)
b = 0x80 | idx | (irq << 4);
outb(b, 0x379);
}
int main(void) {
if (iopl(3)) {
perror("iopl");
return 1;
}
configure_hp400a(0, 7);
return 0;
}
And now:
# modprobe g_NCR5380 ncr_irq=255 ncr_addr=0x280 ncr_53c400a=1
[ 79.051669] scsi2 : interrupts not enabled. for better interactive performance,
[ 79.051770] scsi2 : please jumper the board for a free IRQ.
[ 79.051833] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x280, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { NO_PSEUDO_DMA }, options { AUTOPROBE_IRQ PSEUDO_DMA }
[ 95.390329] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6 PQ: 0 ANSI: 2 CCS
[ 177.022776] sd 2:0:1:0: Attached scsi generic sg1 type 0
[ 177.041505] sd 2:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234 MiB)
[ 177.044491] sd 2:0:1:0: [sdb] Write Protect is off
[ 177.049605] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 177.129093] sdb: sdb1
[ 177.145439] sd 2:0:1:0: [sdb] Attached SCSI disk
# hdparm -t --direct /dev/sdb
/dev/sdb:
Timing O_DIRECT disk reads: 2 MB in 21.38 seconds = 95.77 kB/sec
Seems to work without IRQ.
With IRQ is enabled, no interrupts are shown in /proc/interrupts.
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Finn Thain <fthain@telegraphics.com.au> |
|---|---|
| Date | 2015-11-22 00:40 +0100 |
| Subject | Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers |
| Message-ID | <qxpV8-3RO-15@gated-at.bofh.it> |
| In reply to | #1274645 |
On Sat, 21 Nov 2015, Ondrej Zary wrote:
> On Saturday 21 November 2015 02:58:57 Finn Thain wrote:
>
> >
> > I gather that your setup here is a QUANTUM LP240S target with Domex
> > 3181 (DTC-436) card and g_NCR5380 module. I've been testing a similar
> > setup: QUANTUM LPS540S target with a Domex 3191D (DTC-536) card and
> > dmx3191d module. In both setups PIO is used exclusively, no IRQ is
> > used, and FLAG_DTC3181E is set. I didn't see any issues in my tests,
> > so your results are surprising.
>
> I agree that the results are surprising. Even tried 2.4 kernels (Debian
> 3.1) and even 2.2 (Debian 3.0) and nothing worked. HW is fine - the
> drive is accessible in Windows 98 (with Domex driver installed).
That's good to know (and very thorough).
>
> Now testing the Canon FG2-5202 controller - a simple 8-bit ISA card with
> only two chips: NCR 53C400 and 74LS245. It's memory mapped, IRQ
> hardwired to 7.
>
> # modprobe g_NCR5380_mmio ncr_irq=255 ncr_addr=0xd8000 ncr_53c400=1
>
> [ 1245.919223] scsi2 : interrupts not enabled. for better interactive performance,
> [ 1245.919326] scsi2 : please jumper the board for a free IRQ.
> [ 1245.919389] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0, n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { NCR53C400 }, USLEEP_POLL 3, USLEEP_WAITLONG 1250, options { AUTOPROBE_IRQ PSEUDO_DMA NCR53C400 }
> [ 1246.376738] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6 PQ: 0 ANSI: 2 CCS
> [ 1248.202198] sd 2:0:1:0: Attached scsi generic sg1 type 0
> [ 1248.420856] 53C400r: no 53C80 gated irq after transfer
> [ 1248.420948] 53C400r: no end dma signal
> [ 1248.422459] sd 2:0:1:0: [sdb] Sector size 0 reported, assuming 512.
>
> Seems that the PSEUDO_DMA is broken.
That's been my experience with mac_scsi also (going back 10 years). I'm
told that it used to work in v2.2. PIO was always usable though hopelessly
slow.
I haven't yet done any work on the PDMA problem with mac_scsi because
crashing bugs and the forked core driver seemed to be the more pressing
problems. And resolving the fork has implications for all of the DMA
variations anyway.
> After adding FLAG_NO_PSEUDO_DMA:
>
> # modprobe g_NCR5380_mmio ncr_irq=255 ncr_addr=0xd8000 ncr_53c400=1
>
> [ 67.974362] scsi2 : interrupts not enabled. for better interactive performance,
> [ 67.974463] scsi2 : please jumper the board for a free IRQ.
> [ 67.974526] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0, n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { NCR53C400 NO_PSEUDO_DMA }, USLEEP_POLL 3, USLEEP_WAITLONG 1250, options { AUTOPROBE_IRQ PSEUDO_DMA NCR53C400 }
> [ 68.432728] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6 PQ: 0 ANSI: 2 CCS
> [ 70.258258] sd 2:0:1:0: Attached scsi generic sg1 type 0
> [ 70.277265] sd 2:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234 MiB)
> [ 70.482252] sd 2:0:1:0: [sdb] Write Protect is off
> [ 70.482335] sd 2:0:1:0: [sdb] Mode Sense: 8b 00 00 08
> [ 70.889646] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> [ 73.159513] sdb: sdb1
> [ 74.617099] sd 2:0:1:0: [sdb] Attached SCSI disk
>
> Yeah, first success! I can even mount the filesystem, although it takes ages
> (a minute) and these messages:
> [ 160.872074] sd 2:0:1:0: [sdb] aborting command
> [ 161.816083] sd 2:0:1:0: [sdb] aborting command
>
> # hdparm -t --direct /dev/sdb
>
> /dev/sdb:
> [ 244.840075] sd 2:0:1:0: [sdb] aborting command
> [ 248.824078] sd 2:0:1:0: [sdb] aborting command
> [ 293.864069] sd 2:0:1:0: [sdb] aborting command
> [ 297.824075] sd 2:0:1:0: [sdb] aborting command
> [ 319.765020] blk_update_request: critical target error, dev sdb, sector 0
> [ 319.972994] blk_update_request: critical target error, dev sdb, sector 0
> Timing O_DIRECT disk reads: 2 MB in 105.26 seconds = 19.46 kB/sec
>
>
>
> With your patches (and adding FLAG_NO_PSEUDO_DMA), modprobe is slower but
> mount faster (4 seconds) and then works better:
>
> # modprobe g_NCR5380_mmio ncr_irq=255 ncr_addr=0xd8000 ncr_53c400=1
>
> [ 130.126185] scsi2 : interrupts not enabled. for better interactive performance,
> [ 130.126284] scsi2 : please jumper the board for a free IRQ.
> [ 130.126347] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0, n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { NO_PSEUDO_DMA }, options { AUTOPROBE_IRQ PSEUDO_DMA }
> [ 145.221755] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6 PQ: 0 ANSI: 2 CCS
> [ 220.629912] sd 2:0:1:0: Attached scsi generic sg1 type 0
> [ 220.651400] sd 2:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234 MiB)
> [ 220.654061] sd 2:0:1:0: [sdb] Write Protect is off
> [ 220.659344] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> [ 220.732415] sdb: sdb1
> [ 220.749760] sd 2:0:1:0: [sdb] Attached SCSI disk
>
> # hdparm -t --direct /dev/sdb
>
> /dev/sdb:
> Timing O_DIRECT disk reads: 2 MB in 18.25 seconds = 112.20 kB/sec
>
>
>
> IRQ seems to work too, although driver always shows "irq 0":
Your right, there's a superficial bug there that affects the banner in the
log. But it doesn't affect behaviour (the IRQ should still work). It isn't
a new bug.
>
> # modprobe g_NCR5380_mmio ncr_irq=7 ncr_addr=0xd8000 ncr_53c400=1
>
> [ 117.263062] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0, n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { NO_PSEUDO_DMA }, options { AUTOPROBE_IRQ PSEUDO_DMA }
> [ 132.357474] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6 PQ: 0 ANSI: 2 CCS
> [ 207.765080] sd 2:0:1:0: Attached scsi generic sg1 type 0
> [ 207.783415] sd 2:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234 MiB)
> [ 207.786167] sd 2:0:1:0: [sdb] Write Protect is off
> [ 207.790260] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> [ 207.859669] sdb: sdb1
> [ 207.876556] sd 2:0:1:0: [sdb] Attached SCSI disk
>
> # hdparm -t --direct /dev/sdb
>
> /dev/sdb:
> Timing O_DIRECT disk reads: 2 MB in 18.30 seconds = 111.94 kB/sec
>
> # mount /dev/sdb1 /mnt
> # umount /mnt
> # head /proc/interrupts
> CPU0
> 0: 44793 XT-PIC timer
> 1: 9 XT-PIC i8042
> 2: 0 XT-PIC cascade
> 7: 86 XT-PIC NCR5380
> 8: 1 XT-PIC rtc0
> 9: 0 XT-PIC uhci_hcd:usb1, uhci_hcd:usb2
> 10: 1179 XT-PIC eth0
> 12: 136 XT-PIC i8042
> 14: 3411 XT-PIC pata_via
>
Nice! Thanks for your perseverance. It is gratifying to see it working.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ondrej Zary <linux@rainbow-software.org> |
|---|---|
| Date | 2015-11-24 00:00 +0100 |
| Message-ID | <qy8fw-89o-17@gated-at.bofh.it> |
| In reply to | #1274770 |
On Sunday 22 November 2015 00:32:31 Finn Thain wrote:
>
> On Sat, 21 Nov 2015, Ondrej Zary wrote:
>
> > On Saturday 21 November 2015 02:58:57 Finn Thain wrote:
> >
> > >
> > > I gather that your setup here is a QUANTUM LP240S target with Domex
> > > 3181 (DTC-436) card and g_NCR5380 module. I've been testing a similar
> > > setup: QUANTUM LPS540S target with a Domex 3191D (DTC-536) card and
> > > dmx3191d module. In both setups PIO is used exclusively, no IRQ is
> > > used, and FLAG_DTC3181E is set. I didn't see any issues in my tests,
> > > so your results are surprising.
> >
> > I agree that the results are surprising. Even tried 2.4 kernels (Debian
> > 3.1) and even 2.2 (Debian 3.0) and nothing worked. HW is fine - the
> > drive is accessible in Windows 98 (with Domex driver installed).
>
> That's good to know (and very thorough).
>
> >
> > Now testing the Canon FG2-5202 controller - a simple 8-bit ISA card with
> > only two chips: NCR 53C400 and 74LS245. It's memory mapped, IRQ
> > hardwired to 7.
> >
> > # modprobe g_NCR5380_mmio ncr_irq=255 ncr_addr=0xd8000 ncr_53c400=1
> >
> > [ 1245.919223] scsi2 : interrupts not enabled. for better interactive performance,
> > [ 1245.919326] scsi2 : please jumper the board for a free IRQ.
> > [ 1245.919389] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0, n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { NCR53C400 }, USLEEP_POLL 3, USLEEP_WAITLONG 1250, options { AUTOPROBE_IRQ PSEUDO_DMA NCR53C400 }
> > [ 1246.376738] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6 PQ: 0 ANSI: 2 CCS
> > [ 1248.202198] sd 2:0:1:0: Attached scsi generic sg1 type 0
> > [ 1248.420856] 53C400r: no 53C80 gated irq after transfer
> > [ 1248.420948] 53C400r: no end dma signal
> > [ 1248.422459] sd 2:0:1:0: [sdb] Sector size 0 reported, assuming 512.
> >
> > Seems that the PSEUDO_DMA is broken.
>
> That's been my experience with mac_scsi also (going back 10 years). I'm
> told that it used to work in v2.2. PIO was always usable though hopelessly
> slow.
>
> I haven't yet done any work on the PDMA problem with mac_scsi because
> crashing bugs and the forked core driver seemed to be the more pressing
> problems. And resolving the fork has implications for all of the DMA
> variations anyway.
PDMA seems to be broken in multiple ways. NCR5380_pread cannot process less
than 128 bytes. In fact, 53C400 datasheet says that it's HW limitation:
non-modulo-128-byte transfers should use PIO.
Adding
transfersize = round_down(transfersize, 128);
to generic_NCR5380_dma_xfer_len() improves the situation a bit.
After modprobe, some small reads (8, 4, 24 and 64 bytes) are done using PIO,
then eight 512-byte reads using PDMA and then it fails on a 254-byte read.
First 128 bytes are read using PDMA and the next PDMA operation hangs waiting
forever for the host buffer to be ready.
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Finn Thain <fthain@telegraphics.com.au> |
|---|---|
| Date | 2015-11-24 02:30 +0100 |
| Subject | Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers |
| Message-ID | <qyaAH-1iQ-13@gated-at.bofh.it> |
| In reply to | #1275944 |
On Mon, 23 Nov 2015, Ondrej Zary wrote: > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot process > less than 128 bytes. In fact, 53C400 datasheet says that it's HW > limitation: non-modulo-128-byte transfers should use PIO. > > Adding > transfersize = round_down(transfersize, 128); > to generic_NCR5380_dma_xfer_len() improves the situation a bit. > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are done using > PIO, then eight 512-byte reads using PDMA and then it fails on a > 254-byte read. First 128 bytes are read using PDMA and the next PDMA > operation hangs waiting forever for the host buffer to be ready. > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't see how that is possible given round_down(126, 128) == 0. Was this the actual 'len' argument to NCR5380_pread() in g_NCR5380.c? BTW, I presume that FLAG_NO_DMA_FIXUPS was set (which is the case if you pass ncr_53c400=1 option with modprobe). Otherwise you could see PDMA IO sizes like 127 etc. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ondrej Zary <linux@rainbow-software.org> |
|---|---|
| Date | 2015-11-24 09:10 +0100 |
| Message-ID | <qygPM-5uK-9@gated-at.bofh.it> |
| In reply to | #1276007 |
On Tuesday 24 November 2015, Finn Thain wrote: > > On Mon, 23 Nov 2015, Ondrej Zary wrote: > > > > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot process > > less than 128 bytes. In fact, 53C400 datasheet says that it's HW > > limitation: non-modulo-128-byte transfers should use PIO. > > > > Adding > > transfersize = round_down(transfersize, 128); > > to generic_NCR5380_dma_xfer_len() improves the situation a bit. > > > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are done using > > PIO, then eight 512-byte reads using PDMA and then it fails on a > > 254-byte read. First 128 bytes are read using PDMA and the next PDMA > > operation hangs waiting forever for the host buffer to be ready. > > > > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't see how > that is possible given round_down(126, 128) == 0. Was this the actual > 'len' argument to NCR5380_pread() in g_NCR5380.c? No 126-byte PDMA. The 126 bytes were probably lost (or mixed with the next read?). The next read was also 254 bytes so another 128-byte PDMA transfer. Then modified NCR5380_information_transfer() to transfer the remaining data (126 bytes in this case) using PIO. It did not help, the next PDMA transfer failed too. > BTW, I presume that FLAG_NO_DMA_FIXUPS was set (which is the case if you > pass ncr_53c400=1 option with modprobe). Otherwise you could see PDMA IO > sizes like 127 etc. Yes, the flag was set. -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Finn Thain <fthain@telegraphics.com.au> |
|---|---|
| Date | 2015-11-24 10:20 +0100 |
| Subject | Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers |
| Message-ID | <qyhVv-6c8-7@gated-at.bofh.it> |
| In reply to | #1276134 |
On Tue, 24 Nov 2015, Ondrej Zary wrote:
> On Tuesday 24 November 2015, Finn Thain wrote:
> >
> > On Mon, 23 Nov 2015, Ondrej Zary wrote:
> >
> > >
> > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot
> > > process less than 128 bytes. In fact, 53C400 datasheet says that
> > > it's HW limitation: non-modulo-128-byte transfers should use PIO.
> > >
> > > Adding
> > > transfersize = round_down(transfersize, 128);
> > > to generic_NCR5380_dma_xfer_len() improves the situation a bit.
> > >
> > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are done
> > > using PIO, then eight 512-byte reads using PDMA and then it fails on
> > > a 254-byte read. First 128 bytes are read using PDMA and the next
> > > PDMA operation hangs waiting forever for the host buffer to be
> > > ready.
> > >
> >
> > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't see
> > how that is possible given round_down(126, 128) == 0. Was this the
> > actual 'len' argument to NCR5380_pread() in g_NCR5380.c?
>
> No 126-byte PDMA. The 126 bytes were probably lost (or mixed with the
> next read?).
When you said, the "PDMA operation hangs waiting forever", I figured that
you had hit an infinite loop in NCR5380_pread()... but now I'm lost.
My main concern here is to confirm that I didn't break anything e.g. with
patch 24 or 41. It would be nice to know that this hang is not the result
of a new bug.
> The next read was also 254 bytes so another 128-byte PDMA transfer.
>
> Then modified NCR5380_information_transfer() to transfer the remaining
> data (126 bytes in this case) using PIO. It did not help, the next PDMA
> transfer failed too.
>
AFAICT, no change to NCR5380_information_transfer() should be needed. It
was always meant to cope with the need to split a transfer between (P)DMA
and PIO.
If the target is expecting the remaining 126 bytes, it will keep the bus
in DATA OUT phase, and the next iteration of the loop
while ((cmd = hostdata->connected)) { }
will call NCR5380_transfer_pio() for the remaining bytes. If the target
never asserts REQ, that transfer will never happen, but then the command
should timeout and get aborted, to handle the possibility that a "PDMA
operation hangs waiting forever".
A protocol analyzer would be useful to debug this. I get a lot of value
from a bus terminator block that has LEDs for the various control signals.
Failing that, you might need to place,
#define NDEBUG (NDEBUG_INFORMATION | NDEBUG_HANDSHAKE | NDEBUG_PIO | NDEBUG_DMA | NDEBUG_MAIN)
at the top of g_NCR5380.c.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ondrej Zary <linux@rainbow-software.org> |
|---|---|
| Date | 2015-11-24 13:10 +0100 |
| Message-ID | <qykA2-7Vh-27@gated-at.bofh.it> |
| In reply to | #1276185 |
On Tuesday 24 November 2015, Finn Thain wrote:
>
> On Tue, 24 Nov 2015, Ondrej Zary wrote:
>
> > On Tuesday 24 November 2015, Finn Thain wrote:
> > >
> > > On Mon, 23 Nov 2015, Ondrej Zary wrote:
> > >
> > > >
> > > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot
> > > > process less than 128 bytes. In fact, 53C400 datasheet says that
> > > > it's HW limitation: non-modulo-128-byte transfers should use PIO.
> > > >
> > > > Adding
> > > > transfersize = round_down(transfersize, 128);
> > > > to generic_NCR5380_dma_xfer_len() improves the situation a bit.
> > > >
> > > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are done
> > > > using PIO, then eight 512-byte reads using PDMA and then it fails on
> > > > a 254-byte read. First 128 bytes are read using PDMA and the next
> > > > PDMA operation hangs waiting forever for the host buffer to be
> > > > ready.
> > > >
> > >
> > > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't see
> > > how that is possible given round_down(126, 128) == 0. Was this the
> > > actual 'len' argument to NCR5380_pread() in g_NCR5380.c?
> >
> > No 126-byte PDMA. The 126 bytes were probably lost (or mixed with the
> > next read?).
>
> When you said, the "PDMA operation hangs waiting forever", I figured that
> you had hit an infinite loop in NCR5380_pread()... but now I'm lost.
The first 128-byte PDMA ended successfully (ignoring what happened to the
remaining 126 bytes), then a next request for 254 bytes came. This resulted
in a new 128-byte PDMA and that hanged (in one of its possibly infinite loops
without a timeout).
> My main concern here is to confirm that I didn't break anything e.g. with
> patch 24 or 41. It would be nice to know that this hang is not the result
> of a new bug.
PDMA was already broken before so it's hard to tell. I can try to modify
the unpatched driver to see if PDMA is broken the same way.
> > The next read was also 254 bytes so another 128-byte PDMA transfer.
> >
> > Then modified NCR5380_information_transfer() to transfer the remaining
> > data (126 bytes in this case) using PIO. It did not help, the next PDMA
> > transfer failed too.
> >
>
> AFAICT, no change to NCR5380_information_transfer() should be needed. It
> was always meant to cope with the need to split a transfer between (P)DMA
> and PIO.
>
> If the target is expecting the remaining 126 bytes, it will keep the bus
> in DATA OUT phase, and the next iteration of the loop
> while ((cmd = hostdata->connected)) { }
> will call NCR5380_transfer_pio() for the remaining bytes. If the target
> never asserts REQ, that transfer will never happen, but then the command
> should timeout and get aborted, to handle the possibility that a "PDMA
> operation hangs waiting forever".
Thanks for explanation.
> A protocol analyzer would be useful to debug this. I get a lot of value
> from a bus terminator block that has LEDs for the various control signals.
> Failing that, you might need to place,
> #define NDEBUG (NDEBUG_INFORMATION | NDEBUG_HANDSHAKE | NDEBUG_PIO | NDEBUG_DMA | NDEBUG_MAIN)
> at the top of g_NCR5380.c.
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ondrej Zary <linux@rainbow-software.org> |
|---|---|
| Date | 2015-11-24 19:10 +0100 |
| Message-ID | <qyqcq-3aV-9@gated-at.bofh.it> |
| In reply to | #1276372 |
On Tuesday 24 November 2015 13:03:17 Ondrej Zary wrote: > On Tuesday 24 November 2015, Finn Thain wrote: > > > > On Tue, 24 Nov 2015, Ondrej Zary wrote: > > > > > On Tuesday 24 November 2015, Finn Thain wrote: > > > > > > > > On Mon, 23 Nov 2015, Ondrej Zary wrote: > > > > > > > > > > > > > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot > > > > > process less than 128 bytes. In fact, 53C400 datasheet says that > > > > > it's HW limitation: non-modulo-128-byte transfers should use PIO. > > > > > > > > > > Adding > > > > > transfersize = round_down(transfersize, 128); > > > > > to generic_NCR5380_dma_xfer_len() improves the situation a bit. > > > > > > > > > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are done > > > > > using PIO, then eight 512-byte reads using PDMA and then it fails on > > > > > a 254-byte read. First 128 bytes are read using PDMA and the next > > > > > PDMA operation hangs waiting forever for the host buffer to be > > > > > ready. > > > > > > > > > > > > > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't see > > > > how that is possible given round_down(126, 128) == 0. Was this the > > > > actual 'len' argument to NCR5380_pread() in g_NCR5380.c? > > > > > > No 126-byte PDMA. The 126 bytes were probably lost (or mixed with the > > > next read?). > > > > When you said, the "PDMA operation hangs waiting forever", I figured that > > you had hit an infinite loop in NCR5380_pread()... but now I'm lost. > > The first 128-byte PDMA ended successfully (ignoring what happened to the > remaining 126 bytes), then a next request for 254 bytes came. This resulted > in a new 128-byte PDMA and that hanged (in one of its possibly infinite loops > without a timeout). > > > My main concern here is to confirm that I didn't break anything e.g. with > > patch 24 or 41. It would be nice to know that this hang is not the result > > of a new bug. > > PDMA was already broken before so it's hard to tell. I can try to modify > the unpatched driver to see if PDMA is broken the same way. Just tested the driver without your patches and it's broken exactly the same way. -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ondrej Zary <linux@rainbow-software.org> |
|---|---|
| Date | 2015-11-24 22:50 +0100 |
| Message-ID | <qytDj-5dS-3@gated-at.bofh.it> |
| In reply to | #1276185 |
On Tuesday 24 November 2015 10:13:17 Finn Thain wrote: > > On Tue, 24 Nov 2015, Ondrej Zary wrote: > > > On Tuesday 24 November 2015, Finn Thain wrote: > > > > > > On Mon, 23 Nov 2015, Ondrej Zary wrote: > > > > > > > > > > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot > > > > process less than 128 bytes. In fact, 53C400 datasheet says that > > > > it's HW limitation: non-modulo-128-byte transfers should use PIO. > > > > > > > > Adding > > > > transfersize = round_down(transfersize, 128); > > > > to generic_NCR5380_dma_xfer_len() improves the situation a bit. > > > > > > > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are done > > > > using PIO, then eight 512-byte reads using PDMA and then it fails on > > > > a 254-byte read. First 128 bytes are read using PDMA and the next > > > > PDMA operation hangs waiting forever for the host buffer to be > > > > ready. > > > > > > > > > > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't see > > > how that is possible given round_down(126, 128) == 0. Was this the > > > actual 'len' argument to NCR5380_pread() in g_NCR5380.c? > > > > No 126-byte PDMA. The 126 bytes were probably lost (or mixed with the > > next read?). > > When you said, the "PDMA operation hangs waiting forever", I figured that > you had hit an infinite loop in NCR5380_pread()... but now I'm lost. > > My main concern here is to confirm that I didn't break anything e.g. with > patch 24 or 41. It would be nice to know that this hang is not the result > of a new bug. > > > The next read was also 254 bytes so another 128-byte PDMA transfer. > > > > Then modified NCR5380_information_transfer() to transfer the remaining > > data (126 bytes in this case) using PIO. It did not help, the next PDMA > > transfer failed too. > > > > AFAICT, no change to NCR5380_information_transfer() should be needed. It > was always meant to cope with the need to split a transfer between (P)DMA > and PIO. Instead of fixing split transfers, simply forced everything non-modulo-128 to PIO: --- a/drivers/scsi/g_NCR5380.c +++ b/drivers/scsi/g_NCR5380.c @@ -703,6 +703,10 @@ static int generic_NCR5380_dma_xfer_len(struct scsi_cmnd *cmd) !(cmd->SCp.this_residual % transfersize)) transfersize = 32 * 1024; + /* 53C400 datasheet: non-modulo-128-byte transfers should use PIO */ + if (transfersize % 128) + transfersize = 0; + return transfersize; } It seems to work and greatly improves performance: # hdparm -t --direct /dev/sdb /dev/sdb: Timing O_DIRECT disk reads: 4 MB in 4.84 seconds = 846.15 kB/sec -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Finn Thain <fthain@telegraphics.com.au> |
|---|---|
| Date | 2015-11-25 03:20 +0100 |
| Subject | Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers |
| Message-ID | <qyxQC-89y-7@gated-at.bofh.it> |
| In reply to | #1276780 |
On Tue, 24 Nov 2015, Ondrej Zary wrote: > On Tuesday 24 November 2015 10:13:17 Finn Thain wrote: > > > > On Tue, 24 Nov 2015, Ondrej Zary wrote: > > > > > On Tuesday 24 November 2015, Finn Thain wrote: > > > > > > > > On Mon, 23 Nov 2015, Ondrej Zary wrote: > > > > > > > > > > > > > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot > > > > > process less than 128 bytes. In fact, 53C400 datasheet says that > > > > > it's HW limitation: non-modulo-128-byte transfers should use > > > > > PIO. > > > > > > > > > > Adding > > > > > transfersize = round_down(transfersize, 128); > > > > > to generic_NCR5380_dma_xfer_len() improves the situation a bit. > > > > > > > > > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are > > > > > done using PIO, then eight 512-byte reads using PDMA and then it > > > > > fails on a 254-byte read. First 128 bytes are read using PDMA > > > > > and the next PDMA operation hangs waiting forever for the host > > > > > buffer to be ready. > > > > > > > > > > > > > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't > > > > see how that is possible given round_down(126, 128) == 0. Was this > > > > the actual 'len' argument to NCR5380_pread() in g_NCR5380.c? > > > > > > No 126-byte PDMA. The 126 bytes were probably lost (or mixed with > > > the next read?). > > [...] > > > The next read was also 254 bytes so another 128-byte PDMA transfer. > > > > > > Then modified NCR5380_information_transfer() to transfer the > > > remaining data (126 bytes in this case) using PIO. It did not help, > > > the next PDMA transfer failed too. > > > > > > > AFAICT, no change to NCR5380_information_transfer() should be needed. > > It was always meant to cope with the need to split a transfer between > > (P)DMA and PIO. > > Instead of fixing split transfers, simply forced everything > non-modulo-128 to PIO: The need to split a transfer arises from early chip errata relating to DMA and the workarounds for them (see the comments in the source). That's why I believe that the driver was meant to be cope with this. But I don't have any experimental evidence for it. I'm almost certain that these errata aren't applicable to your hardware. So I don't have any reason to think that your card will allow part of a transfer to be performed with PDMA and the rest with PIO. So I don't really object to the patch. But I don't understand the need for it either: I have no idea what state the driver, chip and scsi bus were in when the 126-byte PIO transfer failed. If the PIO transfer didn't succeed then the entire command should have failed. > --- a/drivers/scsi/g_NCR5380.c > +++ b/drivers/scsi/g_NCR5380.c > @@ -703,6 +703,10 @@ static int generic_NCR5380_dma_xfer_len(struct scsi_cmnd *cmd) > !(cmd->SCp.this_residual % transfersize)) > transfersize = 32 * 1024; > > + /* 53C400 datasheet: non-modulo-128-byte transfers should use PIO */ Do you have a download link for this datasheet? > + if (transfersize % 128) > + transfersize = 0; > + > return transfersize; > } > > It seems to work and greatly improves performance: > # hdparm -t --direct /dev/sdb > > /dev/sdb: > Timing O_DIRECT disk reads: 4 MB in 4.84 seconds = 846.15 kB/sec > Sounds about right... -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ondrej Zary <linux@rainbow-software.org> |
|---|---|
| Date | 2015-11-25 10:10 +0100 |
| Message-ID | <qyEfo-48i-29@gated-at.bofh.it> |
| In reply to | #1276969 |
On Wednesday 25 November 2015, Finn Thain wrote:
>
> On Tue, 24 Nov 2015, Ondrej Zary wrote:
>
> > On Tuesday 24 November 2015 10:13:17 Finn Thain wrote:
> > >
> > > On Tue, 24 Nov 2015, Ondrej Zary wrote:
> > >
> > > > On Tuesday 24 November 2015, Finn Thain wrote:
> > > > >
> > > > > On Mon, 23 Nov 2015, Ondrej Zary wrote:
> > > > >
> > > > > >
> > > > > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot
> > > > > > process less than 128 bytes. In fact, 53C400 datasheet says that
> > > > > > it's HW limitation: non-modulo-128-byte transfers should use
> > > > > > PIO.
> > > > > >
> > > > > > Adding
> > > > > > transfersize = round_down(transfersize, 128);
> > > > > > to generic_NCR5380_dma_xfer_len() improves the situation a bit.
> > > > > >
> > > > > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are
> > > > > > done using PIO, then eight 512-byte reads using PDMA and then it
> > > > > > fails on a 254-byte read. First 128 bytes are read using PDMA
> > > > > > and the next PDMA operation hangs waiting forever for the host
> > > > > > buffer to be ready.
> > > > > >
> > > > >
> > > > > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't
> > > > > see how that is possible given round_down(126, 128) == 0. Was this
> > > > > the actual 'len' argument to NCR5380_pread() in g_NCR5380.c?
> > > >
> > > > No 126-byte PDMA. The 126 bytes were probably lost (or mixed with
> > > > the next read?).
> > > [...]
> > > > The next read was also 254 bytes so another 128-byte PDMA transfer.
> > > >
> > > > Then modified NCR5380_information_transfer() to transfer the
> > > > remaining data (126 bytes in this case) using PIO. It did not help,
> > > > the next PDMA transfer failed too.
> > > >
> > >
> > > AFAICT, no change to NCR5380_information_transfer() should be needed.
> > > It was always meant to cope with the need to split a transfer between
> > > (P)DMA and PIO.
> >
> > Instead of fixing split transfers, simply forced everything
> > non-modulo-128 to PIO:
>
> The need to split a transfer arises from early chip errata relating to DMA
> and the workarounds for them (see the comments in the source). That's why
> I believe that the driver was meant to be cope with this. But I don't have
> any experimental evidence for it.
>
> I'm almost certain that these errata aren't applicable to your hardware.
> So I don't have any reason to think that your card will allow part of a
> transfer to be performed with PDMA and the rest with PIO. So I don't
> really object to the patch.
>
> But I don't understand the need for it either: I have no idea what state
> the driver, chip and scsi bus were in when the 126-byte PIO transfer
> failed. If the PIO transfer didn't succeed then the entire command should
> have failed.
The patch was just a quick hack to confirm that PDMA is not completely broken.
Now we know that it mostly works so I can investigate the partial PIO problem.
> > --- a/drivers/scsi/g_NCR5380.c
> > +++ b/drivers/scsi/g_NCR5380.c
> > @@ -703,6 +703,10 @@ static int generic_NCR5380_dma_xfer_len(struct scsi_cmnd *cmd)
> > !(cmd->SCp.this_residual % transfersize))
> > transfersize = 32 * 1024;
> >
> > + /* 53C400 datasheet: non-modulo-128-byte transfers should use PIO */
>
> Do you have a download link for this datasheet?
http://bitsavers.trailing-edge.com/pdf/ncr/scsi/NCR_53C400.pdf
53C400A datasheet would be great too but haven't found any.
I think that PDMA should work with 53C400A too but seems that the driver was
never able to do it.
Although there is code for port-mapped transfer in NCR5380_pread(),
NCR53C400_register_offset is defined to 0 in the port-mapped case. The C400_
register offsets are thus defined with negative offset:
#define C400_CONTROL_STATUS_REG NCR53C400_register_offset-8
#define C400_BLOCK_COUNTER_REG NCR53C400_register_offset-7
#define C400_RESUME_TRANSFER_REG NCR53C400_register_offset-6
#define C400_HOST_BUFFER NCR53C400_register_offset-4
This is probably OK for a port-mapped 53C400 (such card must have some glue
decoding logic as the 53C400 chip itself can do memory-mapping only) because:
/*
* On NCR53C400 boards, NCR5380 registers are mapped 8 past
* the base address.
*/
if (overrides[current_override].board == BOARD_NCR53C400)
instance->io_port += 8;
This means that on a 53C400, first 5380 register will be at base+8 and first
C400_ register at base.
But on a 53C400A, the 5380 registers are mapped on the base address so the
C400_ registers would be below the base, which is obviously wrong. I hope that
PDMA will work if I fix the C400_ registers mapping.
> > + if (transfersize % 128)
> > + transfersize = 0;
> > +
> > return transfersize;
> > }
> >
> > It seems to work and greatly improves performance:
> > # hdparm -t --direct /dev/sdb
> >
> > /dev/sdb:
> > Timing O_DIRECT disk reads: 4 MB in 4.84 seconds = 846.15 kB/sec
> >
>
> Sounds about right...
>
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Finn Thain <fthain@telegraphics.com.au> |
|---|---|
| Date | 2015-11-25 13:00 +0100 |
| Subject | Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers |
| Message-ID | <qyGTU-5MV-19@gated-at.bofh.it> |
| In reply to | #1277118 |
On Wed, 25 Nov 2015, Ondrej Zary wrote: > On Wednesday 25 November 2015, Finn Thain wrote: > > > > On Tue, 24 Nov 2015, Ondrej Zary wrote: > > > > > Instead of fixing split transfers, simply forced everything > > > non-modulo-128 to PIO: > > > > [...] > > I don't have any reason to think that your card will allow part of > > a transfer to be performed with PDMA and the rest with PIO. So I don't > > really object to the patch. > > From looking at the datasheet, I think your patch is correct. Your patch needs to be applied after mine, so if you will sign-off, I'll include it in the series with your Signed-off-by and "From:" header. > > But I don't understand the need for it either: I have no idea what > > state the driver, chip and scsi bus were in when the 126-byte PIO > > transfer failed. If the PIO transfer didn't succeed then the entire > > command should have failed. > > The patch was just a quick hack to confirm that PDMA is not completely > broken. > Now we know that it mostly works so I can investigate the partial PIO > problem. > There may not be any problem to investigate. Because this 53C80 core is embedded in other logic, it's hard to say whether or not the partial PIO algorithm could be expected to work at all. Besides, the DMA errata don't apply to this core. And large transfers will always be divisible by 128 bytes so there's very little to be gained. > [...] > > 53C400A datasheet would be great too but haven't found any. I don't have one either. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ondrej Zary <linux@rainbow-software.org> |
|---|---|
| Date | 2015-11-26 00:10 +0100 |
| Message-ID | <qyRmi-4ml-11@gated-at.bofh.it> |
| In reply to | #1277118 |
On Wednesday 25 November 2015 10:04:10 Ondrej Zary wrote:
> I think that PDMA should work with 53C400A too but seems that the driver was
> never able to do it.
>
> Although there is code for port-mapped transfer in NCR5380_pread(),
> NCR53C400_register_offset is defined to 0 in the port-mapped case. The C400_
> register offsets are thus defined with negative offset:
>
> #define C400_CONTROL_STATUS_REG NCR53C400_register_offset-8
> #define C400_BLOCK_COUNTER_REG NCR53C400_register_offset-7
> #define C400_RESUME_TRANSFER_REG NCR53C400_register_offset-6
> #define C400_HOST_BUFFER NCR53C400_register_offset-4
>
> This is probably OK for a port-mapped 53C400 (such card must have some glue
> decoding logic as the 53C400 chip itself can do memory-mapping only) because:
>
> /*
> * On NCR53C400 boards, NCR5380 registers are mapped 8 past
> * the base address.
> */
> if (overrides[current_override].board == BOARD_NCR53C400)
> instance->io_port += 8;
>
> This means that on a 53C400, first 5380 register will be at base+8 and first
> C400_ register at base.
>
> But on a 53C400A, the 5380 registers are mapped on the base address so the
> C400_ registers would be below the base, which is obviously wrong. I hope that
> PDMA will work if I fix the C400_ registers mapping.
A quick hack (breaks other chips, needs more work for proper mapping on all
chips):
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -163,7 +163,7 @@
/* Write any value to this register to start an ini mode DMA receive */
#define START_DMA_INITIATOR_RECEIVE_REG 7 /* wo */
-#define C400_CONTROL_STATUS_REG NCR53C400_register_offset-8 /* rw */
+#define C400_CONTROL_STATUS_REG 9 /* rw */
#define CSR_RESET 0x80 /* wo Resets 53c400 */
#define CSR_53C80_REG 0x80 /* ro 5380 registers busy */
@@ -182,13 +182,13 @@
#endif
/* Number of 128-byte blocks to be transferred */
-#define C400_BLOCK_COUNTER_REG NCR53C400_register_offset-7 /* rw */
+#define C400_BLOCK_COUNTER_REG 10 /* rw */
/* Resume transfer after disconnect */
-#define C400_RESUME_TRANSFER_REG NCR53C400_register_offset-6 /* wo */
+#define C400_RESUME_TRANSFER_REG 11 /* wo */
/* Access to host buffer stack */
-#define C400_HOST_BUFFER NCR53C400_register_offset-4 /* rw */
+#define C400_HOST_BUFFER 8 /* rw */
/* Note : PHASE_* macros are based on the values of the STATUS register */
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -323,7 +323,10 @@ static int __init generic_NCR5380_detect(struct scsi_host_template *tpnt)
#endif
break;
case BOARD_NCR53C400A:
+ flags = FLAG_NO_DMA_FIXUP;
+#ifndef PSEUDO_DMA
flags = FLAG_NO_PSEUDO_DMA;
+#endif
ports = ncr_53c400a_ports;
break;
case BOARD_DTC3181E:
@@ -414,7 +417,8 @@ static int __init generic_NCR5380_detect(struct scsi_host_template *tpnt)
if (NCR5380_init(instance, flags))
goto out_unregister;
- if (overrides[current_override].board == BOARD_NCR53C400)
+ if (overrides[current_override].board == BOARD_NCR53C400 ||
+ overrides[current_override].board == BOARD_NCR53C400A)
NCR5380_write(C400_CONTROL_STATUS_REG, CSR_BASE);
NCR5380_maybe_reset_bus(instance);
And PDMA works on I/O mapped 53C400A (HP C2502)!
# modprobe g_NCR5380 ncr_irq=7 ncr_addr=0x280 ncr_53c400a=1
[ 1799.939856] scsi host4: Generic NCR5380/NCR53C400 SCSI, io_port 0x280, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { NO_DMA_FIXUP }, options { AUTOPROBE_IRQ PSEUDO_DMA }
[ 1816.277018] scsi 4:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6 PQ: 0 ANSI: 2 CCS
[ 1897.899648] sd 4:0:1:0: Attached scsi generic sg1 type 0
[ 1897.917842] sd 4:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234 MiB)
[ 1897.920872] sd 4:0:1:0: [sdb] Write Protect is off
[ 1897.924744] sd 4:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1897.967857] sdb: sdb1
[ 1897.993822] sd 4:0:1:0: [sdb] Attached SCSI disk
Nice performance improvement (although it's slower than the memory-mapped
53C400):
# hdparm -t --direct /dev/sdb
/dev/sdb:
Timing O_DIRECT disk reads: 2 MB in 3.99 seconds = 513.57 kB/sec
And it even fixed the IRQ:
# head /proc/interrupts
CPU0
0: 151228 XT-PIC timer
1: 9 XT-PIC i8042
2: 0 XT-PIC cascade
7: 115 XT-PIC NCR5380
8: 1 XT-PIC rtc0
9: 0 XT-PIC uhci_hcd:usb1, uhci_hcd:usb2
10: 3256 XT-PIC eth0
12: 136 XT-PIC i8042
14: 3833 XT-PIC pata_via
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ondrej Zary <linux@rainbow-software.org> |
|---|---|
| Date | 2015-11-25 22:40 +0100 |
| Subject | [PATCH 72/71] ncr5380: Fix pseudo-DMA |
| Message-ID | <qyPXc-3kj-9@gated-at.bofh.it> |
| In reply to | #1272027 |
Pseudo-DMA (PDMA) has been broken for ages, resulting in hangs on 53C400-based cards. According to 53C400 datasheet, PDMA transfer length must be a multiple of 128. Check if that's true and use PIO if it's not. This makes PDMA work on 53C400 (Canon FG2-5202). Signed-off-by: Ondrej Zary <linux@rainbow-software.org> --- drivers/scsi/g_NCR5380.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c index 0daffe2..a9a237f 100644 --- a/drivers/scsi/g_NCR5380.c +++ b/drivers/scsi/g_NCR5380.c @@ -703,6 +703,10 @@ static int generic_NCR5380_dma_xfer_len(struct scsi_cmnd *cmd) !(cmd->SCp.this_residual % transfersize)) transfersize = 32 * 1024; + /* 53C400 datasheet: non-modulo-128-byte transfers should use PIO */ + if (transfersize % 128) + transfersize = 0; + return transfersize; } -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ondrej Zary <linux@rainbow-software.org> |
|---|---|
| Date | 2015-11-29 10:50 +0100 |
| Subject | [RFC PATCH 73/71] ncr5380: Use runtime register mapping |
| Message-ID | <qA6Mi-4ud-5@gated-at.bofh.it> |
| In reply to | #1272027 |
Convert compile-time C400_ register mapping to runtime mapping.
This removes the weird negative register offsets and allows adding
additional mappings.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
---
drivers/scsi/NCR5380.h | 13 +---------
drivers/scsi/g_NCR5380.c | 61 ++++++++++++++++++++++++++--------------------
drivers/scsi/g_NCR5380.h | 12 ++++++---
3 files changed, 43 insertions(+), 43 deletions(-)
diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
index 36779df..0d8ec43 100644
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -163,8 +163,7 @@
/* Write any value to this register to start an ini mode DMA receive */
#define START_DMA_INITIATOR_RECEIVE_REG 7 /* wo */
-#define C400_CONTROL_STATUS_REG NCR53C400_register_offset-8 /* rw */
-
+/* C400_CONTROL_STATUS_REG */
#define CSR_RESET 0x80 /* wo Resets 53c400 */
#define CSR_53C80_REG 0x80 /* ro 5380 registers busy */
#define CSR_TRANS_DIR 0x40 /* rw Data transfer direction */
@@ -181,16 +180,6 @@
#define CSR_BASE CSR_53C80_INTR
#endif
-/* Number of 128-byte blocks to be transferred */
-#define C400_BLOCK_COUNTER_REG NCR53C400_register_offset-7 /* rw */
-
-/* Resume transfer after disconnect */
-#define C400_RESUME_TRANSFER_REG NCR53C400_register_offset-6 /* wo */
-
-/* Access to host buffer stack */
-#define C400_HOST_BUFFER NCR53C400_register_offset-4 /* rw */
-
-
/* Note : PHASE_* macros are based on the values of the STATUS register */
#define PHASE_MASK (SR_MSG | SR_CD | SR_IO)
diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index a9a237f..ce444da 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -253,6 +253,7 @@ static int __init generic_NCR5380_detect(struct scsi_host_template *tpnt)
};
int flags;
struct Scsi_Host *instance;
+ struct NCR5380_hostdata *hostdata;
#ifdef SCSI_G_NCR5380_MEM
unsigned long base;
void __iomem *iomem;
@@ -395,6 +396,7 @@ static int __init generic_NCR5380_detect(struct scsi_host_template *tpnt)
instance = scsi_register(tpnt, sizeof(struct NCR5380_hostdata));
if (instance == NULL)
goto out_release;
+ hostdata = shost_priv(instance);
#ifndef SCSI_G_NCR5380_MEM
instance->io_port = overrides[current_override].NCR5380_map_name;
@@ -404,18 +406,27 @@ static int __init generic_NCR5380_detect(struct scsi_host_template *tpnt)
* On NCR53C400 boards, NCR5380 registers are mapped 8 past
* the base address.
*/
- if (overrides[current_override].board == BOARD_NCR53C400)
+ if (overrides[current_override].board == BOARD_NCR53C400) {
instance->io_port += 8;
+ hostdata->c400_ctl_status = 0;
+ hostdata->c400_blk_cnt = 1;
+ hostdata->c400_host_buf = 4;
+ }
#else
instance->base = overrides[current_override].NCR5380_map_name;
- ((struct NCR5380_hostdata *)instance->hostdata)->iomem = iomem;
+ hostdata->iomem = iomem;
+ if (overrides[current_override].board == BOARD_NCR53C400) {
+ hostdata->c400_ctl_status = 0x100;
+ hostdata->c400_blk_cnt = 0x101;
+ hostdata->c400_host_buf = 0x104;
+ }
#endif
if (NCR5380_init(instance, flags))
goto out_unregister;
if (overrides[current_override].board == BOARD_NCR53C400)
- NCR5380_write(C400_CONTROL_STATUS_REG, CSR_BASE);
+ NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
NCR5380_maybe_reset_bus(instance);
@@ -523,30 +534,28 @@ generic_NCR5380_biosparam(struct scsi_device *sdev, struct block_device *bdev,
static inline int NCR5380_pread(struct Scsi_Host *instance, unsigned char *dst, int len)
{
-#ifdef SCSI_G_NCR5380_MEM
struct NCR5380_hostdata *hostdata = shost_priv(instance);
-#endif
int blocks = len / 128;
int start = 0;
int bl;
- NCR5380_write(C400_CONTROL_STATUS_REG, CSR_BASE | CSR_TRANS_DIR);
- NCR5380_write(C400_BLOCK_COUNTER_REG, blocks);
+ NCR5380_write(hostdata->c400_ctl_status, CSR_BASE | CSR_TRANS_DIR);
+ NCR5380_write(hostdata->c400_blk_cnt, blocks);
while (1) {
- if ((bl = NCR5380_read(C400_BLOCK_COUNTER_REG)) == 0) {
+ if ((bl = NCR5380_read(hostdata->c400_blk_cnt)) == 0) {
break;
}
- if (NCR5380_read(C400_CONTROL_STATUS_REG) & CSR_GATED_53C80_IRQ) {
+ if (NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ) {
printk(KERN_ERR "53C400r: Got 53C80_IRQ start=%d, blocks=%d\n", start, blocks);
return -1;
}
- while (NCR5380_read(C400_CONTROL_STATUS_REG) & CSR_HOST_BUF_NOT_RDY);
+ while (NCR5380_read(hostdata->c400_ctl_status) & CSR_HOST_BUF_NOT_RDY);
#ifndef SCSI_G_NCR5380_MEM
{
int i;
for (i = 0; i < 128; i++)
- dst[start + i] = NCR5380_read(C400_HOST_BUFFER);
+ dst[start + i] = NCR5380_read(hostdata->c400_host_buf);
}
#else
/* implies SCSI_G_NCR5380_MEM */
@@ -558,7 +567,7 @@ static inline int NCR5380_pread(struct Scsi_Host *instance, unsigned char *dst,
}
if (blocks) {
- while (NCR5380_read(C400_CONTROL_STATUS_REG) & CSR_HOST_BUF_NOT_RDY)
+ while (NCR5380_read(hostdata->c400_ctl_status) & CSR_HOST_BUF_NOT_RDY)
{
// FIXME - no timeout
}
@@ -567,7 +576,7 @@ static inline int NCR5380_pread(struct Scsi_Host *instance, unsigned char *dst,
{
int i;
for (i = 0; i < 128; i++)
- dst[start + i] = NCR5380_read(C400_HOST_BUFFER);
+ dst[start + i] = NCR5380_read(hostdata->c400_host_buf);
}
#else
/* implies SCSI_G_NCR5380_MEM */
@@ -578,7 +587,7 @@ static inline int NCR5380_pread(struct Scsi_Host *instance, unsigned char *dst,
blocks--;
}
- if (!(NCR5380_read(C400_CONTROL_STATUS_REG) & CSR_GATED_53C80_IRQ))
+ if (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ))
printk("53C400r: no 53C80 gated irq after transfer");
#if 0
@@ -586,7 +595,7 @@ static inline int NCR5380_pread(struct Scsi_Host *instance, unsigned char *dst,
* DON'T DO THIS - THEY NEVER ARRIVE!
*/
printk("53C400r: Waiting for 53C80 registers\n");
- while (NCR5380_read(C400_CONTROL_STATUS_REG) & CSR_53C80_REG)
+ while (NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG)
;
#endif
if (!(NCR5380_read(BUS_AND_STATUS_REG) & BASR_END_DMA_TRANSFER))
@@ -607,31 +616,29 @@ static inline int NCR5380_pread(struct Scsi_Host *instance, unsigned char *dst,
static inline int NCR5380_pwrite(struct Scsi_Host *instance, unsigned char *src, int len)
{
-#ifdef SCSI_G_NCR5380_MEM
struct NCR5380_hostdata *hostdata = shost_priv(instance);
-#endif
int blocks = len / 128;
int start = 0;
int bl;
int i;
- NCR5380_write(C400_CONTROL_STATUS_REG, CSR_BASE);
- NCR5380_write(C400_BLOCK_COUNTER_REG, blocks);
+ NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
+ NCR5380_write(hostdata->c400_blk_cnt, blocks);
while (1) {
- if (NCR5380_read(C400_CONTROL_STATUS_REG) & CSR_GATED_53C80_IRQ) {
+ if (NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ) {
printk(KERN_ERR "53C400w: Got 53C80_IRQ start=%d, blocks=%d\n", start, blocks);
return -1;
}
- if ((bl = NCR5380_read(C400_BLOCK_COUNTER_REG)) == 0) {
+ if ((bl = NCR5380_read(hostdata->c400_blk_cnt)) == 0) {
break;
}
- while (NCR5380_read(C400_CONTROL_STATUS_REG) & CSR_HOST_BUF_NOT_RDY)
+ while (NCR5380_read(hostdata->c400_ctl_status) & CSR_HOST_BUF_NOT_RDY)
; // FIXME - timeout
#ifndef SCSI_G_NCR5380_MEM
{
for (i = 0; i < 128; i++)
- NCR5380_write(C400_HOST_BUFFER, src[start + i]);
+ NCR5380_write(hostdata->c400_host_buf, src[start + i]);
}
#else
/* implies SCSI_G_NCR5380_MEM */
@@ -642,13 +649,13 @@ static inline int NCR5380_pwrite(struct Scsi_Host *instance, unsigned char *src,
blocks--;
}
if (blocks) {
- while (NCR5380_read(C400_CONTROL_STATUS_REG) & CSR_HOST_BUF_NOT_RDY)
+ while (NCR5380_read(hostdata->c400_ctl_status) & CSR_HOST_BUF_NOT_RDY)
; // FIXME - no timeout
#ifndef SCSI_G_NCR5380_MEM
{
for (i = 0; i < 128; i++)
- NCR5380_write(C400_HOST_BUFFER, src[start + i]);
+ NCR5380_write(hostdata->c400_host_buf, src[start + i]);
}
#else
/* implies SCSI_G_NCR5380_MEM */
@@ -661,7 +668,7 @@ static inline int NCR5380_pwrite(struct Scsi_Host *instance, unsigned char *src,
#if 0
printk("53C400w: waiting for registers to be available\n");
- THEY NEVER DO ! while (NCR5380_read(C400_CONTROL_STATUS_REG) & CSR_53C80_REG);
+ THEY NEVER DO ! while (NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG);
printk("53C400w: Got em\n");
#endif
@@ -669,7 +676,7 @@ static inline int NCR5380_pwrite(struct Scsi_Host *instance, unsigned char *src,
/* All documentation says to check for this. Maybe my hardware is too
* fast. Waiting for it seems to work fine! KLL
*/
- while (!(i = NCR5380_read(C400_CONTROL_STATUS_REG) & CSR_GATED_53C80_IRQ))
+ while (!(i = NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ))
; // FIXME - no timeout
/*
diff --git a/drivers/scsi/g_NCR5380.h b/drivers/scsi/g_NCR5380.h
index fd201e9..633edd0 100644
--- a/drivers/scsi/g_NCR5380.h
+++ b/drivers/scsi/g_NCR5380.h
@@ -29,7 +29,6 @@
#define NCR5380_map_type int
#define NCR5380_map_name port
-#define NCR53C400_register_offset 0
#ifdef CONFIG_SCSI_GENERIC_NCR53C400
#define NCR5380_region_size 16
@@ -42,7 +41,10 @@
#define NCR5380_write(reg, value) \
outb(value, instance->io_port + (reg))
-#define NCR5380_implementation_fields /* none */
+#define NCR5380_implementation_fields \
+ int c400_ctl_status;\
+ int c400_blk_cnt;\
+ int c400_host_buf;
#else
/* therefore SCSI_G_NCR5380_MEM */
@@ -50,7 +52,6 @@
#define NCR5380_map_type unsigned long
#define NCR5380_map_name base
-#define NCR53C400_register_offset 0x108
#define NCR53C400_mem_base 0x3880
#define NCR53C400_host_buffer 0x3900
#define NCR5380_region_size 0x3a00
@@ -63,7 +64,10 @@
NCR53C400_mem_base + (reg))
#define NCR5380_implementation_fields \
- void __iomem *iomem;
+ void __iomem *iomem;\
+ int c400_ctl_status;\
+ int c400_blk_cnt;\
+ int c400_host_buf;
#endif
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Finn Thain <fthain@telegraphics.com.au> |
|---|---|
| Date | 2015-11-30 13:00 +0100 |
| Subject | Re: [RFC PATCH 73/71] ncr5380: Use runtime register mapping |
| Message-ID | <qAvhE-38r-11@gated-at.bofh.it> |
| In reply to | #1279309 |
On Sun, 29 Nov 2015, Ondrej Zary wrote:
> Convert compile-time C400_ register mapping to runtime mapping.
> This removes the weird negative register offsets and allows adding
> additional mappings.
>
> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
> ---
> drivers/scsi/NCR5380.h | 13 +---------
> drivers/scsi/g_NCR5380.c | 61 ++++++++++++++++++++++++++--------------------
> drivers/scsi/g_NCR5380.h | 12 ++++++---
> 3 files changed, 43 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
> index 36779df..0d8ec43 100644
> --- a/drivers/scsi/NCR5380.h
> +++ b/drivers/scsi/NCR5380.h
> @@ -163,8 +163,7 @@
> /* Write any value to this register to start an ini mode DMA receive */
> #define START_DMA_INITIATOR_RECEIVE_REG 7 /* wo */
>
> -#define C400_CONTROL_STATUS_REG NCR53C400_register_offset-8 /* rw */
> -
> +/* C400_CONTROL_STATUS_REG */
That symbol is removed by this patch. No need for abbreviations. How about
/* NCR 53C400 and 53C400A Control Status Register bits: */
> #define CSR_RESET 0x80 /* wo Resets 53c400 */
> #define CSR_53C80_REG 0x80 /* ro 5380 registers busy */
> #define CSR_TRANS_DIR 0x40 /* rw Data transfer direction */
> @@ -181,16 +180,6 @@
> #define CSR_BASE CSR_53C80_INTR
> #endif
>
> -/* Number of 128-byte blocks to be transferred */
> -#define C400_BLOCK_COUNTER_REG NCR53C400_register_offset-7 /* rw */
> -
> -/* Resume transfer after disconnect */
> -#define C400_RESUME_TRANSFER_REG NCR53C400_register_offset-6 /* wo */
> -
> -/* Access to host buffer stack */
> -#define C400_HOST_BUFFER NCR53C400_register_offset-4 /* rw */
> -
> -
> /* Note : PHASE_* macros are based on the values of the STATUS register */
> #define PHASE_MASK (SR_MSG | SR_CD | SR_IO)
>
> diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
> index a9a237f..ce444da 100644
> --- a/drivers/scsi/g_NCR5380.c
> +++ b/drivers/scsi/g_NCR5380.c
> @@ -253,6 +253,7 @@ static int __init generic_NCR5380_detect(struct scsi_host_template *tpnt)
> };
> int flags;
> struct Scsi_Host *instance;
> + struct NCR5380_hostdata *hostdata;
> #ifdef SCSI_G_NCR5380_MEM
> unsigned long base;
> void __iomem *iomem;
> @@ -395,6 +396,7 @@ static int __init generic_NCR5380_detect(struct scsi_host_template *tpnt)
> instance = scsi_register(tpnt, sizeof(struct NCR5380_hostdata));
> if (instance == NULL)
> goto out_release;
> + hostdata = shost_priv(instance);
>
> #ifndef SCSI_G_NCR5380_MEM
> instance->io_port = overrides[current_override].NCR5380_map_name;
> @@ -404,18 +406,27 @@ static int __init generic_NCR5380_detect(struct scsi_host_template *tpnt)
> * On NCR53C400 boards, NCR5380 registers are mapped 8 past
> * the base address.
> */
> - if (overrides[current_override].board == BOARD_NCR53C400)
> + if (overrides[current_override].board == BOARD_NCR53C400) {
> instance->io_port += 8;
> + hostdata->c400_ctl_status = 0;
> + hostdata->c400_blk_cnt = 1;
> + hostdata->c400_host_buf = 4;
> + }
> #else
> instance->base = overrides[current_override].NCR5380_map_name;
> - ((struct NCR5380_hostdata *)instance->hostdata)->iomem = iomem;
> + hostdata->iomem = iomem;
> + if (overrides[current_override].board == BOARD_NCR53C400) {
> + hostdata->c400_ctl_status = 0x100;
> + hostdata->c400_blk_cnt = 0x101;
> + hostdata->c400_host_buf = 0x104;
> + }
> #endif
>
> if (NCR5380_init(instance, flags))
> goto out_unregister;
>
> if (overrides[current_override].board == BOARD_NCR53C400)
> - NCR5380_write(C400_CONTROL_STATUS_REG, CSR_BASE);
> + NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
>
> NCR5380_maybe_reset_bus(instance);
>
> @@ -523,30 +534,28 @@ generic_NCR5380_biosparam(struct scsi_device *sdev, struct block_device *bdev,
>
> static inline int NCR5380_pread(struct Scsi_Host *instance, unsigned char *dst, int len)
> {
> -#ifdef SCSI_G_NCR5380_MEM
> struct NCR5380_hostdata *hostdata = shost_priv(instance);
> -#endif
> int blocks = len / 128;
> int start = 0;
> int bl;
>
> - NCR5380_write(C400_CONTROL_STATUS_REG, CSR_BASE | CSR_TRANS_DIR);
> - NCR5380_write(C400_BLOCK_COUNTER_REG, blocks);
> + NCR5380_write(hostdata->c400_ctl_status, CSR_BASE | CSR_TRANS_DIR);
> + NCR5380_write(hostdata->c400_blk_cnt, blocks);
> while (1) {
> - if ((bl = NCR5380_read(C400_BLOCK_COUNTER_REG)) == 0) {
> + if ((bl = NCR5380_read(hostdata->c400_blk_cnt)) == 0) {
> break;
> }
> - if (NCR5380_read(C400_CONTROL_STATUS_REG) & CSR_GATED_53C80_IRQ) {
> + if (NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ) {
> printk(KERN_ERR "53C400r: Got 53C80_IRQ start=%d, blocks=%d\n", start, blocks);
> return -1;
> }
> - while (NCR5380_read(C400_CONTROL_STATUS_REG) & CSR_HOST_BUF_NOT_RDY);
> + while (NCR5380_read(hostdata->c400_ctl_status) & CSR_HOST_BUF_NOT_RDY);
>
> #ifndef SCSI_G_NCR5380_MEM
> {
> int i;
> for (i = 0; i < 128; i++)
> - dst[start + i] = NCR5380_read(C400_HOST_BUFFER);
> + dst[start + i] = NCR5380_read(hostdata->c400_host_buf);
> }
> #else
> /* implies SCSI_G_NCR5380_MEM */
> @@ -558,7 +567,7 @@ static inline int NCR5380_pread(struct Scsi_Host *instance, unsigned char *dst,
> }
>
> if (blocks) {
> - while (NCR5380_read(C400_CONTROL_STATUS_REG) & CSR_HOST_BUF_NOT_RDY)
> + while (NCR5380_read(hostdata->c400_ctl_status) & CSR_HOST_BUF_NOT_RDY)
> {
> // FIXME - no timeout
> }
> @@ -567,7 +576,7 @@ static inline int NCR5380_pread(struct Scsi_Host *instance, unsigned char *dst,
> {
> int i;
> for (i = 0; i < 128; i++)
> - dst[start + i] = NCR5380_read(C400_HOST_BUFFER);
> + dst[start + i] = NCR5380_read(hostdata->c400_host_buf);
> }
> #else
> /* implies SCSI_G_NCR5380_MEM */
> @@ -578,7 +587,7 @@ static inline int NCR5380_pread(struct Scsi_Host *instance, unsigned char *dst,
> blocks--;
> }
>
> - if (!(NCR5380_read(C400_CONTROL_STATUS_REG) & CSR_GATED_53C80_IRQ))
> + if (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ))
> printk("53C400r: no 53C80 gated irq after transfer");
>
> #if 0
> @@ -586,7 +595,7 @@ static inline int NCR5380_pread(struct Scsi_Host *instance, unsigned char *dst,
> * DON'T DO THIS - THEY NEVER ARRIVE!
> */
> printk("53C400r: Waiting for 53C80 registers\n");
> - while (NCR5380_read(C400_CONTROL_STATUS_REG) & CSR_53C80_REG)
> + while (NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG)
> ;
> #endif
> if (!(NCR5380_read(BUS_AND_STATUS_REG) & BASR_END_DMA_TRANSFER))
> @@ -607,31 +616,29 @@ static inline int NCR5380_pread(struct Scsi_Host *instance, unsigned char *dst,
>
> static inline int NCR5380_pwrite(struct Scsi_Host *instance, unsigned char *src, int len)
> {
> -#ifdef SCSI_G_NCR5380_MEM
> struct NCR5380_hostdata *hostdata = shost_priv(instance);
> -#endif
> int blocks = len / 128;
> int start = 0;
> int bl;
> int i;
>
> - NCR5380_write(C400_CONTROL_STATUS_REG, CSR_BASE);
> - NCR5380_write(C400_BLOCK_COUNTER_REG, blocks);
> + NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
> + NCR5380_write(hostdata->c400_blk_cnt, blocks);
> while (1) {
> - if (NCR5380_read(C400_CONTROL_STATUS_REG) & CSR_GATED_53C80_IRQ) {
> + if (NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ) {
> printk(KERN_ERR "53C400w: Got 53C80_IRQ start=%d, blocks=%d\n", start, blocks);
> return -1;
> }
>
> - if ((bl = NCR5380_read(C400_BLOCK_COUNTER_REG)) == 0) {
> + if ((bl = NCR5380_read(hostdata->c400_blk_cnt)) == 0) {
> break;
> }
> - while (NCR5380_read(C400_CONTROL_STATUS_REG) & CSR_HOST_BUF_NOT_RDY)
> + while (NCR5380_read(hostdata->c400_ctl_status) & CSR_HOST_BUF_NOT_RDY)
> ; // FIXME - timeout
> #ifndef SCSI_G_NCR5380_MEM
> {
> for (i = 0; i < 128; i++)
> - NCR5380_write(C400_HOST_BUFFER, src[start + i]);
> + NCR5380_write(hostdata->c400_host_buf, src[start + i]);
> }
> #else
> /* implies SCSI_G_NCR5380_MEM */
> @@ -642,13 +649,13 @@ static inline int NCR5380_pwrite(struct Scsi_Host *instance, unsigned char *src,
> blocks--;
> }
> if (blocks) {
> - while (NCR5380_read(C400_CONTROL_STATUS_REG) & CSR_HOST_BUF_NOT_RDY)
> + while (NCR5380_read(hostdata->c400_ctl_status) & CSR_HOST_BUF_NOT_RDY)
> ; // FIXME - no timeout
>
> #ifndef SCSI_G_NCR5380_MEM
> {
> for (i = 0; i < 128; i++)
> - NCR5380_write(C400_HOST_BUFFER, src[start + i]);
> + NCR5380_write(hostdata->c400_host_buf, src[start + i]);
> }
> #else
> /* implies SCSI_G_NCR5380_MEM */
> @@ -661,7 +668,7 @@ static inline int NCR5380_pwrite(struct Scsi_Host *instance, unsigned char *src,
>
> #if 0
> printk("53C400w: waiting for registers to be available\n");
> - THEY NEVER DO ! while (NCR5380_read(C400_CONTROL_STATUS_REG) & CSR_53C80_REG);
> + THEY NEVER DO ! while (NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG);
> printk("53C400w: Got em\n");
> #endif
>
> @@ -669,7 +676,7 @@ static inline int NCR5380_pwrite(struct Scsi_Host *instance, unsigned char *src,
> /* All documentation says to check for this. Maybe my hardware is too
> * fast. Waiting for it seems to work fine! KLL
> */
> - while (!(i = NCR5380_read(C400_CONTROL_STATUS_REG) & CSR_GATED_53C80_IRQ))
> + while (!(i = NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ))
> ; // FIXME - no timeout
>
> /*
> diff --git a/drivers/scsi/g_NCR5380.h b/drivers/scsi/g_NCR5380.h
> index fd201e9..633edd0 100644
> --- a/drivers/scsi/g_NCR5380.h
> +++ b/drivers/scsi/g_NCR5380.h
> @@ -29,7 +29,6 @@
>
> #define NCR5380_map_type int
> #define NCR5380_map_name port
> -#define NCR53C400_register_offset 0
>
> #ifdef CONFIG_SCSI_GENERIC_NCR53C400
> #define NCR5380_region_size 16
> @@ -42,7 +41,10 @@
> #define NCR5380_write(reg, value) \
> outb(value, instance->io_port + (reg))
>
> -#define NCR5380_implementation_fields /* none */
> +#define NCR5380_implementation_fields \
> + int c400_ctl_status;\
> + int c400_blk_cnt;\
> + int c400_host_buf;
>
> #else
> /* therefore SCSI_G_NCR5380_MEM */
A space before the backslash would be more consistent.
> @@ -50,7 +52,6 @@
>
> #define NCR5380_map_type unsigned long
> #define NCR5380_map_name base
> -#define NCR53C400_register_offset 0x108
> #define NCR53C400_mem_base 0x3880
> #define NCR53C400_host_buffer 0x3900
> #define NCR5380_region_size 0x3a00
> @@ -63,7 +64,10 @@
> NCR53C400_mem_base + (reg))
>
> #define NCR5380_implementation_fields \
> - void __iomem *iomem;
> + void __iomem *iomem;\
> + int c400_ctl_status;\
> + int c400_blk_cnt;\
> + int c400_host_buf;
>
> #endif
>
Same here.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ondrej Zary <linux@rainbow-software.org> |
|---|---|
| Date | 2015-11-29 10:50 +0100 |
| Subject | [RFC PATCH 74/71] ncr5380: Enable PDMA for NCR53C400A |
| Message-ID | <qA6Mi-4ud-7@gated-at.bofh.it> |
| In reply to | #1272027 |
Add I/O register mapping for NCR53C400A and enable PDMA mode to
improve performance and fix non-working IRQ.
Tested with HP C2502 (and user-space enabler).
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
---
drivers/scsi/g_NCR5380.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index ce444da..c3abe48 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -324,7 +324,10 @@ static int __init generic_NCR5380_detect(struct scsi_host_template *tpnt)
#endif
break;
case BOARD_NCR53C400A:
+ flags = FLAG_NO_DMA_FIXUP;
+#ifndef PSEUDO_DMA
flags = FLAG_NO_PSEUDO_DMA;
+#endif
ports = ncr_53c400a_ports;
break;
case BOARD_DTC3181E:
@@ -412,6 +415,11 @@ static int __init generic_NCR5380_detect(struct scsi_host_template *tpnt)
hostdata->c400_blk_cnt = 1;
hostdata->c400_host_buf = 4;
}
+ if (overrides[current_override].board == BOARD_NCR53C400A) {
+ hostdata->c400_ctl_status = 9;
+ hostdata->c400_blk_cnt = 10;
+ hostdata->c400_host_buf = 8;
+ }
#else
instance->base = overrides[current_override].NCR5380_map_name;
hostdata->iomem = iomem;
@@ -425,7 +433,8 @@ static int __init generic_NCR5380_detect(struct scsi_host_template *tpnt)
if (NCR5380_init(instance, flags))
goto out_unregister;
- if (overrides[current_override].board == BOARD_NCR53C400)
+ if (overrides[current_override].board == BOARD_NCR53C400 ||
+ overrides[current_override].board == BOARD_NCR53C400A)
NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
NCR5380_maybe_reset_bus(instance);
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Finn Thain <fthain@telegraphics.com.au> |
|---|---|
| Date | 2015-11-30 13:00 +0100 |
| Subject | Re: [RFC PATCH 74/71] ncr5380: Enable PDMA for NCR53C400A |
| Message-ID | <qAvhG-38r-55@gated-at.bofh.it> |
| In reply to | #1279310 |
On Sun, 29 Nov 2015, Ondrej Zary wrote:
> Add I/O register mapping for NCR53C400A and enable PDMA mode to
> improve performance and fix non-working IRQ.
>
> Tested with HP C2502 (and user-space enabler).
>
> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
> ---
> drivers/scsi/g_NCR5380.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
> index ce444da..c3abe48 100644
> --- a/drivers/scsi/g_NCR5380.c
> +++ b/drivers/scsi/g_NCR5380.c
> @@ -324,7 +324,10 @@ static int __init generic_NCR5380_detect(struct scsi_host_template *tpnt)
> #endif
> break;
> case BOARD_NCR53C400A:
> + flags = FLAG_NO_DMA_FIXUP;
> +#ifndef PSEUDO_DMA
> flags = FLAG_NO_PSEUDO_DMA;
> +#endif
FLAG_NO_PSEUDO_DMA is not tested unless defined(PSEUDO_DMA), so it
shouldn't be set here. I know I made the same mistake in patch 8; it will
be fixed in the next submission.
--
> ports = ncr_53c400a_ports;
> break;
> case BOARD_DTC3181E:
> @@ -412,6 +415,11 @@ static int __init generic_NCR5380_detect(struct scsi_host_template *tpnt)
> hostdata->c400_blk_cnt = 1;
> hostdata->c400_host_buf = 4;
> }
> + if (overrides[current_override].board == BOARD_NCR53C400A) {
> + hostdata->c400_ctl_status = 9;
> + hostdata->c400_blk_cnt = 10;
> + hostdata->c400_host_buf = 8;
> + }
> #else
> instance->base = overrides[current_override].NCR5380_map_name;
> hostdata->iomem = iomem;
> @@ -425,7 +433,8 @@ static int __init generic_NCR5380_detect(struct scsi_host_template *tpnt)
> if (NCR5380_init(instance, flags))
> goto out_unregister;
>
> - if (overrides[current_override].board == BOARD_NCR53C400)
> + if (overrides[current_override].board == BOARD_NCR53C400 ||
> + overrides[current_override].board == BOARD_NCR53C400A)
> NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
>
> NCR5380_maybe_reset_bus(instance);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | linux.kernel
csiph-web