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 cas
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
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,
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 s
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
> >
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:
> > > >
> > > > >
> > > > >
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
> > > > proc
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
> > >
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
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(tran
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'
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 Do
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 diff
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 S
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 t
On Friday 20 November 2015 02:41:19 Finn Thain wrote:
>
> On Thu, 19 Nov 2015, Ondrej Zary wrote:
>
> > On Thursday 19 November 2015 03:24:56 Finn Thain wrote:
> >
> > > On Wed, 18 Nov 2015, Ondrej Zary wrote:
> > >
> > > >
> > > > I have some NCR5380 ISA cards and can test them.
> > >
> > > Than
On Friday 20 November 2015, Geert Uytterhoeven wrote:
> On Fri, Nov 20, 2015 at 12:40 PM, Ondrej Zary
> wrote:
> > Working ISA means more testing possibilities. It's much easier to get an
> > ISA card than a Sun or Atari. Also faster CPU (such as 1 GHz P3) means
> > quicker testing.
>
> Faster
On Fri, Nov 20, 2015 at 12:40 PM, Ondrej Zary
wrote:
> Working ISA means more testing possibilities. It's much easier to get an ISA
> card than a Sun or Atari. Also faster CPU (such as 1 GHz P3) means quicker
> testing.
Faster PCs without ISA slots? ;-)
Gr{oetje,eeting}s,
On Fri, Nov 20, 2015 at 12:40:03PM +0100, Ondrej Zary wrote:
> > > I'd love to be able to get rid of the ISA drivers to be honest.
> >
> > Is that because of their use of scsi_module.c or their general decrepitude
> > or something else?
>
> scsi_module.c usage shouldn't be hard to fix. I can do
On Friday 20 November 2015, Finn Thain wrote:
>
> On Fri, 20 Nov 2015, Christoph Hellwig wrote:
>
> > On Fri, Nov 20, 2015 at 07:19:21PM +1100, Finn Thain wrote:
> >
> > > Yes. I didn't do that conversion because I don't have ISA hardware and
> > > I don't understand ISA probing.
> > >
> > > Th
On Fri, 20 Nov 2015, Christoph Hellwig wrote:
> On Fri, Nov 20, 2015 at 07:19:21PM +1100, Finn Thain wrote:
>
> > Yes. I didn't do that conversion because I don't have ISA hardware and
> > I don't understand ISA probing.
> >
> > The present patch set doesn't seek to resurrect the ISA drivers. B
On Fri, Nov 20, 2015 at 07:19:21PM +1100, Finn Thain wrote:
> Yes. I didn't do that conversion because I don't have ISA hardware and I
> don't understand ISA probing.
>
> The present patch set doesn't seek to resurrect the ISA drivers. But I am
> trying to avoid regressions.
>
> I have mixed fe
On Friday 20 November 2015, Finn Thain wrote:
>
> On Thu, 19 Nov 2015, Christoph Hellwig wrote:
>
> > On Fri, Nov 20, 2015 at 06:21:06PM +1100, Finn Thain wrote:
> >
> > > > Not sure what module was being probed here. I presume it was
> > > > g_NCR5380 or g_NCR5380_mmio. Neither of these calls
On Thu, 19 Nov 2015, Christoph Hellwig wrote:
> On Fri, Nov 20, 2015 at 06:21:06PM +1100, Finn Thain wrote:
>
> > > Not sure what module was being probed here. I presume it was
> > > g_NCR5380 or g_NCR5380_mmio. Neither of these calls
> > > 'scsi_scan_host'. I'm not sure what the implications a
On Friday 20 November 2015, Finn Thain wrote:
>
> On Thu, 19 Nov 2015, Ondrej Zary wrote:
>
> > On Thursday 19 November 2015 03:24:56 Finn Thain wrote:
> >
> > > On Wed, 18 Nov 2015, Ondrej Zary wrote:
> > >
> > > >
> > > > I have some NCR5380 ISA cards and can test them.
> > >
> > > Thanks Ondre
On Fri, Nov 20, 2015 at 06:21:06PM +1100, Finn Thain wrote:
> > Not sure what module was being probed here. I presume it was g_NCR5380
> > or g_NCR5380_mmio. Neither of these calls 'scsi_scan_host'. I'm not sure
> > what the implications are (?)
>
> Nevermind. The call is in scsi_module.c.
Whic
On Fri, 20 Nov 2015, I wrote:
> On Thu, 19 Nov 2015, Ondrej Zary wrote:
>
> > [ 240.108501] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> > this message.
> > [ 240.108597] modprobeD 001a 0 1957 1950 0x
> > [ 240.108790] ce0fad00 0086 53881781 0
On Thu, 19 Nov 2015, Ondrej Zary wrote:
> On Thursday 19 November 2015 03:24:56 Finn Thain wrote:
>
> > On Wed, 18 Nov 2015, Ondrej Zary wrote:
> >
> > >
> > > I have some NCR5380 ISA cards and can test them.
> >
> > Thanks Ondrej. I've no idea which ISA drivers are presently working in
> > main
On Thursday 19 November 2015 03:24:56 Finn Thain wrote:
> On Wed, 18 Nov 2015, Ondrej Zary wrote:
> > On Wednesday 18 November 2015, Finn Thain wrote:
> > > Like my previous work on the NCR5380 drivers, this patch series has
> > > bug fixes, code cleanup and modernization. These drivers suffer fr
On Thursday 19 November 2015, Finn Thain wrote:
> On Wed, 18 Nov 2015, Ondrej Zary wrote:
> > On Wednesday 18 November 2015, Finn Thain wrote:
> > > Like my previous work on the NCR5380 drivers, this patch series has
> > > bug fixes, code cleanup and modernization. These drivers suffer from
> > > m
Hi Finn,
>>>
>>> I have compile-tested all patches to all NCR5380 drivers (x86, ARM,
>>> m68k) and regression tested mac_scsi and dmx3191d modules on suitable
>>> hardware. Testing the mac_scsi and dmx3191d modules provides only
>>> limited coverage. It would be good to see some testing of ISA
On Wed, 18 Nov 2015, Ondrej Zary wrote:
> On Wednesday 18 November 2015, Finn Thain wrote:
>
> > Like my previous work on the NCR5380 drivers, this patch series has
> > bug fixes, code cleanup and modernization. These drivers suffer from
> > mistakes, poor style and neglect and this long serie
On Wednesday 18 November 2015, Finn Thain wrote:
> Like my previous work on the NCR5380 drivers, this patch series has bug
> fixes, code cleanup and modernization. These drivers suffer from mistakes,
> poor style and neglect and this long series addresses the worst of it,
> covering all ten wrapper
Like my previous work on the NCR5380 drivers, this patch series has bug
fixes, code cleanup and modernization. These drivers suffer from mistakes,
poor style and neglect and this long series addresses the worst of it,
covering all ten wrapper drivers and both of the core driver forks. The
combined
34 matches
Mail list logo
