Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)

[Chavdar Ivanov]

It supports AHCI mode only on the regular internal disk, not on a disk
connected via a tray to the CDROM.

On Thu, 12 Oct 2017, 00:11 Michael van Elst,  wrote:

> On Wed, Oct 11, 2017 at 08:19:13PM +, Chavdar Ivanov wrote:
> > I see you are on a ThinkPad as well. I have mentioned it elsewhere, on my
> > ThinkPad T61p I am getting reliably since the NCQ update the following:
> > ...
> > wd0 at atabus0 drive 0
> > wd0: 
> > wd0: drive supports 16-sector PIO transfers, LBA48 addressing
> > wd0: 298 GB, 620181 cyl, 16 head, 63 sec, 512 bytes/sect x 625142448
> sectors
> > piixide0:0:0: bad state 0 in wdc_ata_bio_intr
> > panic: wdc_ata_bio_intr: bad state
> > fatal breakpoint trap in supervisor mode
> > trap type 1 code 0 rip 0x8021c0c5 cs 0x8 rflags 0x246 cr2 0
> ilevel
> > 0x8 rsp 0xe40040003c38
> > curlwp 0xe4013bb27840 pid 0.2 lowest kstack 0xe40042c0
> > rebooting...
>
> Looks like bad handling of the drives RESET state.
>
> N.B. the T61p supports AHCI mode too, any reason why this is not
> selected in the BIOS? AHCI mode so far didn't show problems.
>
>
> Greetings,
> --
> Michael van Elst
> Internet: mlel...@serpens.de
> "A potential Snark may lurk in every tree."
>

Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)

[Chavdar Ivanov]

I see you are on a ThinkPad as well. I have mentioned it elsewhere, on my
ThinkPad T61p I am getting reliably since the NCQ update the following:
...
wd0 at atabus0 drive 0
wd0: 
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 298 GB, 620181 cyl, 16 head, 63 sec, 512 bytes/sect x 625142448 sectors
piixide0:0:0: bad state 0 in wdc_ata_bio_intr
panic: wdc_ata_bio_intr: bad state
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip 0x8021c0c5 cs 0x8 rflags 0x246 cr2 0 ilevel
0x8 rsp 0xe40040003c38
curlwp 0xe4013bb27840 pid 0.2 lowest kstack 0xe40042c0
rebooting...
...

The disk is on the place of the CD with an appropriate tray, this happens
with kernels from releng, not only with mine. There is another disk, an SSD
in the internal bay, with a Windows 10 and some Linux installation, the
default boot is NetBSD from the tray.

Chavdar Ivanov


On Wed, 11 Oct 2017 at 20:57 Michael van Elst  wrote:

> t...@panix.com (Thor Lancelot Simon) writes:
>
> >It probably has to do with our small maximum transfer size.  The disk is
> >probably trying to be safer and *not* caching tagged writes as
> aggressively,
> >but with only 32 commands in-flight (SCSI/SAS allow 256) and a maximum
> >transfer size of 64K (our MAXPHYS), that's only 2MB of in-flight data;
> >maybe not enough to keep up with the actual bandwidth of the media at
> >its real latency.
>
> With a larger MAXPHYS there wouldn't be as many transfers in flight.
>
> The disk here in the Thinkpad behaves differently. With up to 5 concurrent
> transfers (320k buffer size for dd reading the raw partition) everything
> is fine. With 6 concurrent transfers the speed goes down again, with
> 30 transfers we are at half speed.
>
> --
> --
> Michael van Elst
> Internet: mlel...@serpens.de
> "A potential Snark may lurk in every tree."
>

daily CVS update output

[NetBSD source update]

Updating src tree:
P src/lib/libedit/chared.c
P src/share/man/man8/rc.8
P src/sys/arch/amd64/amd64/machdep.c
P src/sys/arch/amd64/stand/prekern/elf.c
P src/sys/arch/amd64/stand/prekern/locore.S
P src/sys/arch/amd64/stand/prekern/prekern.ldscript
P src/sys/arch/arm/sunxi/files.sunxi
P src/sys/arch/arm/sunxi/sun8i_h3_ccu.c
P src/sys/arch/arm/sunxi/sunxi_gpio.c
P src/sys/arch/arm/sunxi/sunxi_platform.c
cvs update: `src/sys/arch/evbarm/conf/HUMMINGBIRD_A31' is no longer in the 
repository
cvs update: `src/sys/arch/evbarm/conf/HUMMINGBIRD_A31_INSTALL' is no longer in 
the repository
P src/sys/arch/evbarm/conf/SUNXI
P src/sys/arch/i386/stand/boot/boot2.c
P src/sys/dev/pci/pci_subr.c
P src/sys/dev/pci/radeonfb.c
P src/sys/net/if_vlan.c
P src/tests/net/if_vlan/t_vlan.sh

Updating xsrc tree:


Killing core files:




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  50618024 Oct 12 03:03 ls-lRA.gz

Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)

[Michael van Elst]

On Wed, Oct 11, 2017 at 08:19:13PM +, Chavdar Ivanov wrote:
> I see you are on a ThinkPad as well. I have mentioned it elsewhere, on my
> ThinkPad T61p I am getting reliably since the NCQ update the following:
> ...
> wd0 at atabus0 drive 0
> wd0: 
> wd0: drive supports 16-sector PIO transfers, LBA48 addressing
> wd0: 298 GB, 620181 cyl, 16 head, 63 sec, 512 bytes/sect x 625142448 sectors
> piixide0:0:0: bad state 0 in wdc_ata_bio_intr
> panic: wdc_ata_bio_intr: bad state
> fatal breakpoint trap in supervisor mode
> trap type 1 code 0 rip 0x8021c0c5 cs 0x8 rflags 0x246 cr2 0 ilevel
> 0x8 rsp 0xe40040003c38
> curlwp 0xe4013bb27840 pid 0.2 lowest kstack 0xe40042c0
> rebooting...

Looks like bad handling of the drives RESET state.

N.B. the T61p supports AHCI mode too, any reason why this is not
selected in the BIOS? AHCI mode so far didn't show problems.


Greetings,
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: New panic in wdc_ata_bio_intr

[Michael van Elst]

jaromir.dole...@gmail.com (=?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?=) writes:

>can you try with dev/scsipi/atapi_wdc.c 1.128? That should resolve the
>timeouts for atapi, at least it did for me.

For testing I did disable ahci mode, and promptly got timeouts
("interrupt lost") from pciide when accessing an ATAPI CD-ROM.
So I tested again with a pre-NCQ kernel and did get the same.

ahci mode itself is fine.


-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)

[Michael van Elst]

macal...@netbsd.org (Michael) writes:

>/home/ml# sysctl -w hw.wd1.use_ncq=0
>hw.wd1.use_ncq: 1 -> 0
>/home/ml# dd if=/dev/rwd1c of=/dev/null bs=1m count=2048
>2048+0 records in
>2048+0 records out
>2147483648 bytes transferred in 21.747 secs (98748500 bytes/sec)

Please try to use different buffer sizes. Maybe there is a
pattern too.


-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)

[Michael van Elst]

t...@panix.com (Thor Lancelot Simon) writes:

>It probably has to do with our small maximum transfer size.  The disk is
>probably trying to be safer and *not* caching tagged writes as aggressively,
>but with only 32 commands in-flight (SCSI/SAS allow 256) and a maximum
>transfer size of 64K (our MAXPHYS), that's only 2MB of in-flight data;
>maybe not enough to keep up with the actual bandwidth of the media at
>its real latency.

With a larger MAXPHYS there wouldn't be as many transfers in flight.

The disk here in the Thinkpad behaves differently. With up to 5 concurrent
transfers (320k buffer size for dd reading the raw partition) everything
is fine. With 6 concurrent transfers the speed goes down again, with
30 transfers we are at half speed.

-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)

[Michael]

Hello,

On Tue, 10 Oct 2017 23:11:54 +0200
Jaromír Doleček  wrote:

> I've seen this on one of my disks, too. It seems it's much slower in NCQ
> mode. I think the firmware might not utilise the disk cache properly when
> in NCQ mode.
> 
> You can try switching it off via sysctl, hw.wdX.use_ncq. You can also try
> to turn off use_ncq_prio if that makes any difference.

/home/ml# sysctl -w hw.wd1.use_ncq=0
hw.wd1.use_ncq: 1 -> 0
/home/ml# dd if=/dev/rwd1c of=/dev/null bs=1m count=2048
2048+0 records in
2048+0 records out
2147483648 bytes transferred in 21.747 secs (98748500 bytes/sec)

/home/ml# sysctl -w hw.wd1.use_ncq=1
hw.wd1.use_ncq: 0 -> 1
/home/ml# dd if=/dev/rwd1c of=/dev/null bs=1m count=2048
2048+0 records in
2048+0 records out
2147483648 bytes transferred in 26.125 secs (82200331 bytes/sec)

/home/ml# sysctl -w hw.wd1.use_ncq_prio=0
hw.wd1.use_ncq_prio: 1 -> 0
/home/ml# dd if=/dev/rwd1c of=/dev/null bs=1m count=2048
2048+0 records in
2048+0 records out
2147483648 bytes transferred in 24.187 secs (88786689 bytes/sec)

... that's the siisata:
siisata0 at pci0 dev 2 function 0: vendor 1095 product 3124 (rev. 0x02)
siisata0: interrupting at ivec 700
siisata0: SiI3124, 3.0Gb/s
siisata0: 64-bit 66MHz PCI

... with one of these:

siisata0 port 0: device present, speed: 3.0Gb/s
wd1(siisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100) 
(using DMA), NCQ (30 tags) w/PRIO

Model: WDC WD5000AAKX-083CA1, Rev: 17.01H17, Serial #:  WD-WCAYUCL72135
World Wide Name: 50014EE104595309
Device type: ATA, fixed
Capacity 500 Gbytes, 976773168 sectors, 512 bytes/sector
Cylinders: 16383, heads: 16, sec/track: 63
...
Serial ATA capabilities:
1.5Gb/s signaling
3.0Gb/s signaling
6.0Gb/s signaling
Native Command Queuing
PHY Event Counters

have fun
Michael