RE :sata_sil + UDMA CRC errors

RE :sata_sil + UDMA CRC errors

[Alexander Shaposhnikov]

Hi again.

Some time ago i reported bugs in sata_sil driver.

It seems that latest kernel 2.6.13-git4 solved all the problems for my Seagate SATA drive.
However, nothing has changed with Samsung drive, i am still getting alot of CRC errors.
There is probably some unknown compatibility issue with Samsung drives and sil3114 controller.

If somebody is interested in this, i can provide more detailed information.


Best Regards,
Alexander Shaposhnikov

Re: RE :sata_sil + UDMA CRC errors

[Tejun Heo]

On Tue, Sep 06, 2005 at 06:33:18PM +0700, Alexander Shaposhnikov wrote:
> 
> Hi again.
> 
> Some time ago i reported bugs in sata_sil driver.
> 
> It seems that latest kernel 2.6.13-git4 solved all the problems for my Seagate SATA drive.
> However, nothing has changed with Samsung drive, i am still getting alot of CRC errors.
> There is probably some unknown compatibility issue with Samsung drives and sil3114 controller.
> 
> If somebody is interested in this, i can provide more detailed information.

 Hello, Alexander.

 AFAIK, there has been no change since you reported the problem last
time which can affect your CRC errors.  I think what you're seeing is
a hardware problem - be it the controller, cable or whatever.
Transfer errors due to hardware problems can come and go away with
silly silly reasons.  For example, placing SATA cables differently
inside your case can make CRC errors go away (especially because SATA
cables are not shielded/twisted).

 The thing is that CRC errors can be ignored and commands can be
retried without much performance hit - the head is probably already
there and only data needs to be transferred again.  I believe that's
what's going on when you're on Windows.

  Also, you've previously mentioned that you see much less errors with
my m15w workaround applied.  That's not because the workaround does
something to alleviate transfer errors.  All it does is reducing
number of commands issued, thus reducing number of errors too.

 I have both Segate and Samsung drives and both work happily with my
3112 (not 3114 but still...) controller.  From what you're reporting
(disappearance of CRC errors on a drive without clear reasons), I'm
very inclined to think that you have a faulty hardware.

 To verify, can you please try again the kernel you used when
initially reporting this (2.6.12-rc6, right?) and see if it still
produces CRC errors on the Seagate drive?

 Thanks.

-- 
tejun

Re: RE :sata_sil + UDMA CRC errors

[Tejun Heo]

[Alexander dropped all CC's when replying to my mail.  I'm adding them
 back.  Alexander, please reply to all, not just me. ]

On Tue, Sep 06, 2005 at 09:13:20PM +0700, Alexander Shaposhnikov wrote:
> Hello Tejun
> 
> I dont really know what has changed in sata_sil driver, but:
> 1. I have no more problems with my Seagate drive
> 2. I have now good read and write perfomance (around 50MB/s both) on my
> Seagate drive, without your patch.

 #2 is because we don't apply m15w quirk to 3114's as sii has
confirmed that 3114's are not affected.  Maybe it affected #1 in a
mysterious way, I just don't know.

> The hardware problem was my first sought, naturally.
> I tried several cables with no difference. Probably controller error.
> 
> But there is strong reason against this: i have no errors under Windows.
> These CRC errors are logged and can be be viewed in SMART status of hard
> drives. If, as you suppose, i am getting this errors under Windows too,
> i would see the growth of according UDMA CRC errors number during hard
> disk activity. But this does not happen, no single error under Windows,
> while alot of them under Linux. 
> 
> Is it possible you can test your drives on sil3114 controller?.  Or,
> better, on the same board (ASUS K8N-DL) ?
> 
> Best Regards,
> Alexander Shaposhnikov
> 

 Okay, as SII has kindly opened documents for 3112/3114.  I digged a
little bit and here's something I came up with.  This is highly
experimental and potentially dangerous.

 The chip has a phy configuration register which can adjust
differentail voltage swing.  The following patch adds a module
parameter tx_swing to sata_sil driver.  This is an integer parameter
and has the following meaning.

-1 : don't change transmission voltage swing (default)
0  : 500mV
1  : 600mV
2  : 700mV
3  : 800mV

 So, after building sata_sil as a module and installing it.

# modprobe sata_sil
sata_sil(0000:01:02.0): phy_conf 0x80f1 (nominal output swing 500mV)
ata5: SATA max UDMA/100 cmd 0xE1020C80 ctl 0xE1020C8A bmdma 0xE1020C00 irq 19
ata6: SATA max UDMA/100 cmd 0xE1020CC0 ctl 0xE1020CCA bmdma 0xE1020C08 irq 19
ata5: no device found (phy stat 00000000)
scsi5 : sata_sil
ata6: dev 0 ATA, max UDMA7, 312581808 sectors: lba48
ata6: dev 0 configured for UDMA/100
scsi6 : sata_sil
  Vendor: ATA       Model: SAMSUNG HD160JJ   Rev: WU10
  Type:   Direct-Access                      ANSI SCSI revision: 05
~~~~~

 Note that the driver prints current phy_conf setting on
initialization.  Mine is initialized to default 500mV.  Let's bump it
up to 600mV.

# modprobe sata_sil tx_swing=1
sata_sil(0000:01:02.0): overwriting phy_conf to 0xc0f1
sata_sil(0000:01:02.0): phy_conf 0xc0f1 (nominal output swing 600mV)
ata7: SATA max UDMA/100 cmd 0xE1020C80 ctl 0xE1020C8A bmdma 0xE1020C00 irq 19
ata8: SATA max UDMA/100 cmd 0xE1020CC0 ctl 0xE1020CCA bmdma 0xE1020C08 irq 19
ata7: no device found (phy stat 00000000)
scsi7 : sata_sil
ata8: dev 0 ATA, max UDMA7, 312581808 sectors: lba48
ata8: dev 0 configured for UDMA/100
scsi8 : sata_sil
  Vendor: ATA       Model: SAMSUNG HD160JJ   Rev: WU10
  Type:   Direct-Access                      ANSI SCSI revision: 05
~~~~~

 You can see that now tx swing voltage is set to 600mV.  In my case,
both settings work fine.  So, if you're brave enough to try this....

1. First load the module without any argument and see what's the
   default value is.  It probably is 500mV unless your BIOS has
   twicked it.

2. If the default is 500mV, try 600mV with tx_swing=1.  Theoretically
   this should be safe.  According to SATA spec, max value of both
   Vdiff,tx and Vdiff,rx is 600mV, so setting 600mV is inside the
   limit and shouldn't cause any problem.  Well, that's the theory.

   If the default is not 500mV, try the next higher setting.  This
   can be dangerous, but my bet is that this shouldn't cause any
   damage on the drive.  The BIOS should be configuring for 500mV
   at the connector and increasing 100mV shouldn't make the swing
   voltage go over 600mV at the rx side.  But this is just my guess
   and it's unlikely but possible that you fry the PHY of your drive.

3. See if CRC errors continue to occur.

 Again, though unlikely, this might fry PHY of your drive, so try it
at your own risk.


diff --git a/drivers/scsi/sata_sil.c b/drivers/scsi/sata_sil.c
--- a/drivers/scsi/sata_sil.c
+++ b/drivers/scsi/sata_sil.c
@@ -73,6 +73,7 @@ enum {
 	SIL_MASK_4PORT		= SIL_MASK_2PORT |
 				  SIL_MASK_IDE2_INT | SIL_MASK_IDE3_INT,
 
+	SIL_PHY_CONF		= 0x144,
 	SIL_IDE2_BMDMA		= 0x200,
 
 	SIL_INTR_STEERING	= (1 << 1),
@@ -231,6 +232,9 @@ MODULE_LICENSE("GPL");
 MODULE_DEVICE_TABLE(pci, sil_pci_tbl);
 MODULE_VERSION(DRV_VERSION);
 
+static int tx_swing = -1;
+module_param(tx_swing, int, 0444);
+
 static unsigned char sil_get_device_cache_line(struct pci_dev *pdev)
 {
 	u8 cache_line = 0;
@@ -379,7 +383,7 @@ static int sil_init_one (struct pci_dev 
 	int rc;
 	unsigned int i;
 	int pci_dev_busy = 0;
-	u32 tmp, irq_mask;
+	u32 phy_conf, tmp, irq_mask;
 	u8 cls;
 
 	if (!printed_version++)
@@ -445,6 +449,25 @@ static int sil_init_one (struct pci_dev 
 		ata_std_ports(&probe_ent->port[i]);
 	}
 
+	/* PHY configuration */
+	if (tx_swing >= 0) {
+		if (tx_swing <= 3) {
+			phy_conf = readl(mmio_base + SIL_PHY_CONF);
+			phy_conf &= ~((1 << 19) | (1 << 14));
+			phy_conf |= ((tx_swing & (1 << 1)) << 18) | ((tx_swing & (1 << 0)) << 14);
+			printk(KERN_INFO DRV_NAME "(%s): overwriting phy_conf to 0x%x\n",
+			       pci_name(pdev), phy_conf);
+			writel(phy_conf, mmio_base + SIL_PHY_CONF);
+		} else
+			printk(KERN_WARNING DRV_NAME "(%s): tx_swing out of range\n",
+			       pci_name(pdev));
+	}
+
+	phy_conf = readl(mmio_base + SIL_PHY_CONF);
+	tmp = ((phy_conf & (1 << 19)) >> 18) | ((phy_conf & (1 << 14)) >> 14);
+	printk(KERN_INFO DRV_NAME "(%s): phy_conf 0x%x (nominal output swing %dmV)\n",
+	       pci_name(pdev), phy_conf, 500 + 100 * tmp);
+
 	/* Initialize FIFO PCI bus arbitration */
 	cls = sil_get_device_cache_line(pdev);
 	if (cls) {

RE: RE :sata_sil + UDMA CRC errors

[Alexander Shaposhnikov]

Hellow Tejun

I tried your patch (by the way, it cannot be applied by patch utility -it
complains about malformed expression on line 19 and so on)
Default reads in 500mv. With 600mv, I am starting to get CRC errors for
Seagate drive (no errors with 2.6.13-git4). Samsung drive produces so many
errors, that it is unusable both with and without patch.

Concerning K8N-DL motherboard -current BIOS 1004 is very buggy. It has
screwed up ACPI APIC table. To use onboard lan and usb, I have to boot with 
pci=noacpi boot option. And I cannot use 1003, as I have DualCore Opterons, 
and 1004 the only one which supports them!

There is long problem with Nvidia CK804 southbridge sata under Linux.
Despite that the board was released some 8 month ago, it still cannot be
used! And nobody seems to care about this. ASUS in the least. 
I was able to boot from NVidia SATA with latest kernel and irqpoll option.
At first I thought that all my problems are gone at last, but the god
decided differently. It works at light disk load, but havy load lead to
system freeze. No errors, just dead freeze. I returned to silicon3114 sata.
At least, I have one working drive now:)

Best Regards,
Alexander Shaposhnikov


-----Original Message-----
From: Tejun Heo [mailto:htejun@gmail.com] 
Sent: Tuesday, September 06, 2005 10:38 PM
To: Alexander Shaposhnikov
Cc: Jeff Garzik; linux-ide@vger.kernel.org; Carlos.Pardo@siliconimage.com;
Paul.Taylor@siliconimage.com; lbattraw@insightbb.com; Yuri Kirsanov
Subject: Re: RE :sata_sil + UDMA CRC errors

[Alexander dropped all CC's when replying to my mail.  I'm adding them
 back.  Alexander, please reply to all, not just me. ]

On Tue, Sep 06, 2005 at 09:13:20PM +0700, Alexander Shaposhnikov wrote:
> Hello Tejun
> 
> I dont really know what has changed in sata_sil driver, but:
> 1. I have no more problems with my Seagate drive
> 2. I have now good read and write perfomance (around 50MB/s both) on my
> Seagate drive, without your patch.

 #2 is because we don't apply m15w quirk to 3114's as sii has
confirmed that 3114's are not affected.  Maybe it affected #1 in a
mysterious way, I just don't know.

> The hardware problem was my first sought, naturally.
> I tried several cables with no difference. Probably controller error.
> 
> But there is strong reason against this: i have no errors under Windows.
> These CRC errors are logged and can be be viewed in SMART status of hard
> drives. If, as you suppose, i am getting this errors under Windows too,
> i would see the growth of according UDMA CRC errors number during hard
> disk activity. But this does not happen, no single error under Windows,
> while alot of them under Linux. 
> 
> Is it possible you can test your drives on sil3114 controller?.  Or,
> better, on the same board (ASUS K8N-DL) ?
> 
> Best Regards,
> Alexander Shaposhnikov
> 

 Okay, as SII has kindly opened documents for 3112/3114.  I digged a
little bit and here's something I came up with.  This is highly
experimental and potentially dangerous.

 The chip has a phy configuration register which can adjust
differentail voltage swing.  The following patch adds a module
parameter tx_swing to sata_sil driver.  This is an integer parameter
and has the following meaning.

-1 : don't change transmission voltage swing (default)
0  : 500mV
1  : 600mV
2  : 700mV
3  : 800mV

 So, after building sata_sil as a module and installing it.

# modprobe sata_sil
sata_sil(0000:01:02.0): phy_conf 0x80f1 (nominal output swing 500mV)
ata5: SATA max UDMA/100 cmd 0xE1020C80 ctl 0xE1020C8A bmdma 0xE1020C00 irq
19
ata6: SATA max UDMA/100 cmd 0xE1020CC0 ctl 0xE1020CCA bmdma 0xE1020C08 irq
19
ata5: no device found (phy stat 00000000)
scsi5 : sata_sil
ata6: dev 0 ATA, max UDMA7, 312581808 sectors: lba48
ata6: dev 0 configured for UDMA/100
scsi6 : sata_sil
  Vendor: ATA       Model: SAMSUNG HD160JJ   Rev: WU10
  Type:   Direct-Access                      ANSI SCSI revision: 05
~~~~~

 Note that the driver prints current phy_conf setting on
initialization.  Mine is initialized to default 500mV.  Let's bump it
up to 600mV.

# modprobe sata_sil tx_swing=1
sata_sil(0000:01:02.0): overwriting phy_conf to 0xc0f1
sata_sil(0000:01:02.0): phy_conf 0xc0f1 (nominal output swing 600mV)
ata7: SATA max UDMA/100 cmd 0xE1020C80 ctl 0xE1020C8A bmdma 0xE1020C00 irq
19
ata8: SATA max UDMA/100 cmd 0xE1020CC0 ctl 0xE1020CCA bmdma 0xE1020C08 irq
19
ata7: no device found (phy stat 00000000)
scsi7 : sata_sil
ata8: dev 0 ATA, max UDMA7, 312581808 sectors: lba48
ata8: dev 0 configured for UDMA/100
scsi8 : sata_sil
  Vendor: ATA       Model: SAMSUNG HD160JJ   Rev: WU10
  Type:   Direct-Access                      ANSI SCSI revision: 05
~~~~~

 You can see that now tx swing voltage is set to 600mV.  In my case,
both settings work fine.  So, if you're brave enough to try this....

1. First load the module without any argument and see what's the
   default value is.  It probably is 500mV unless your BIOS has
   twicked it.

2. If the default is 500mV, try 600mV with tx_swing=1.  Theoretically
   this should be safe.  According to SATA spec, max value of both
   Vdiff,tx and Vdiff,rx is 600mV, so setting 600mV is inside the
   limit and shouldn't cause any problem.  Well, that's the theory.

   If the default is not 500mV, try the next higher setting.  This
   can be dangerous, but my bet is that this shouldn't cause any
   damage on the drive.  The BIOS should be configuring for 500mV
   at the connector and increasing 100mV shouldn't make the swing
   voltage go over 600mV at the rx side.  But this is just my guess
   and it's unlikely but possible that you fry the PHY of your drive.

3. See if CRC errors continue to occur.

 Again, though unlikely, this might fry PHY of your drive, so try it
at your own risk.


diff --git a/drivers/scsi/sata_sil.c b/drivers/scsi/sata_sil.c
--- a/drivers/scsi/sata_sil.c
+++ b/drivers/scsi/sata_sil.c
@@ -73,6 +73,7 @@ enum {
 	SIL_MASK_4PORT		= SIL_MASK_2PORT |
 				  SIL_MASK_IDE2_INT | SIL_MASK_IDE3_INT,
 
+	SIL_PHY_CONF		= 0x144,
 	SIL_IDE2_BMDMA		= 0x200,
 
 	SIL_INTR_STEERING	= (1 << 1),
@@ -231,6 +232,9 @@ MODULE_LICENSE("GPL");
 MODULE_DEVICE_TABLE(pci, sil_pci_tbl);
 MODULE_VERSION(DRV_VERSION);
 
+static int tx_swing = -1;
+module_param(tx_swing, int, 0444);
+
 static unsigned char sil_get_device_cache_line(struct pci_dev *pdev)
 {
 	u8 cache_line = 0;
@@ -379,7 +383,7 @@ static int sil_init_one (struct pci_dev 
 	int rc;
 	unsigned int i;
 	int pci_dev_busy = 0;
-	u32 tmp, irq_mask;
+	u32 phy_conf, tmp, irq_mask;
 	u8 cls;
 
 	if (!printed_version++)
@@ -445,6 +449,25 @@ static int sil_init_one (struct pci_dev 
 		ata_std_ports(&probe_ent->port[i]);
 	}
 
+	/* PHY configuration */
+	if (tx_swing >= 0) {
+		if (tx_swing <= 3) {
+			phy_conf = readl(mmio_base + SIL_PHY_CONF);
+			phy_conf &= ~((1 << 19) | (1 << 14));
+			phy_conf |= ((tx_swing & (1 << 1)) << 18) |
((tx_swing & (1 << 0)) << 14);
+			printk(KERN_INFO DRV_NAME "(%s): overwriting
phy_conf to 0x%x\n",
+			       pci_name(pdev), phy_conf);
+			writel(phy_conf, mmio_base + SIL_PHY_CONF);
+		} else
+			printk(KERN_WARNING DRV_NAME "(%s): tx_swing out of
range\n",
+			       pci_name(pdev));
+	}
+
+	phy_conf = readl(mmio_base + SIL_PHY_CONF);
+	tmp = ((phy_conf & (1 << 19)) >> 18) | ((phy_conf & (1 << 14)) >>
14);
+	printk(KERN_INFO DRV_NAME "(%s): phy_conf 0x%x (nominal output swing
%dmV)\n",
+	       pci_name(pdev), phy_conf, 500 + 100 * tmp);
+
 	/* Initialize FIFO PCI bus arbitration */
 	cls = sil_get_device_cache_line(pdev);
 	if (cls) {

Re: RE :sata_sil + UDMA CRC errors

[Tejun Heo]

  Hello, Alexander & Jeremy.

Alexander Shaposhnikov wrote:
> Hellow Tejun
> 
> I tried your patch (by the way, it cannot be applied by patch utility -it
> complains about malformed expression on line 19 and so on)
> Default reads in 500mv. With 600mv, I am starting to get CRC errors for
> Seagate drive (no errors with 2.6.13-git4). Samsung drive produces so many
> errors, that it is unusable both with and without patch.

  Ugh... that's ugly. :-/

  Jeremy, apparantly my little patch doesn't do any good.  Please ignore it.

> Concerning K8N-DL motherboard -current BIOS 1004 is very buggy. It has
> screwed up ACPI APIC table. To use onboard lan and usb, I have to boot with 
> pci=noacpi boot option. And I cannot use 1003, as I have DualCore Opterons, 
> and 1004 the only one which supports them!
> 
> There is long problem with Nvidia CK804 southbridge sata under Linux.
> Despite that the board was released some 8 month ago, it still cannot be
> used! And nobody seems to care about this. ASUS in the least. 
> I was able to boot from NVidia SATA with latest kernel and irqpoll option.
> At first I thought that all my problems are gone at last, but the god
> decided differently. It works at light disk load, but havy load lead to
> system freeze. No errors, just dead freeze. I returned to silicon3114 sata.
> At least, I have one working drive now:)
> 

  I fear that there's nothing much else I can do about this K8N-DL sil 
CRC error.  I've read the hw doc but couldn't find anything which seems 
helpful.  Let's hope something (BIOS update?) comes up soon.

  Sorry.

-- 
tejun

Re: RE :sata_sil + UDMA CRC errors

[Jeremy Smith]

On Wed, 7 Sep 2005, Tejun Heo wrote:

>
> Hello, Alexander & Jeremy.
>
> Alexander Shaposhnikov wrote:
>> Hellow Tejun
>> 
>> I tried your patch (by the way, it cannot be applied by patch utility -it
>> complains about malformed expression on line 19 and so on)
>> Default reads in 500mv. With 600mv, I am starting to get CRC errors for
>> Seagate drive (no errors with 2.6.13-git4). Samsung drive produces so many
>> errors, that it is unusable both with and without patch.
>
> Ugh... that's ugly. :-/
>
> Jeremy, apparantly my little patch doesn't do any good.  Please ignore it.
>
>> Concerning K8N-DL motherboard -current BIOS 1004 is very buggy. It has
>> screwed up ACPI APIC table. To use onboard lan and usb, I have to boot with 
>> pci=noacpi boot option. And I cannot use 1003, as I have DualCore Opterons, 
>> and 1004 the only one which supports them!

> I fear that there's nothing much else I can do about this K8N-DL sil CRC 
> error.  I've read the hw doc but couldn't find anything which seems helpful. 
> Let's hope something (BIOS update?) comes up soon.

Well, myself I think I'm going to be getting a known-good hardware RAID 
controller (probably the 3ware) for this board.  I'm getting the lockups 
after 1-3 hours, and that's not enough uptime for me.  Kinda sucks to have 
two SATA chips onboard and problems with both of them.  If there are any 
thoughts or patches you folks have, I'm happy to try them out.

Jer

Re: RE :sata_sil + UDMA CRC errors

[Jeremy Smith]

One other bit of information on this problem: When I first set up this 
machine, I had two drives hooked up to the controller, but was only using 
one for the install for the first couple of days.

As far as I could tell, as long as I was only ever touching the first 
channel/first disk, I wasn't experiencing this problem.  I set up a 
logical volume manager volume across both disks--and then the problem 
started to happen in earnest.  Is it possible that this problem only 
surfaces with two disks hooked up to the controller on this particular 
board--and that with only one it isn't an issue?  I intend to remove one 
of the disks and hit the other one hard and see if it's a problem.

Alexander, were you ever working with the linux driver where you only ever 
hit one disk?

Thanks,
Jer


On Wed, 7 Sep 2005, Tejun Heo wrote:

>
> Hello, Alexander & Jeremy.
>
> Alexander Shaposhnikov wrote:
>> Hellow Tejun
>> 
>> I tried your patch (by the way, it cannot be applied by patch utility -it
>> complains about malformed expression on line 19 and so on)
>> Default reads in 500mv. With 600mv, I am starting to get CRC errors for
>> Seagate drive (no errors with 2.6.13-git4). Samsung drive produces so many
>> errors, that it is unusable both with and without patch.
>
> Ugh... that's ugly. :-/
>
> Jeremy, apparantly my little patch doesn't do any good.  Please ignore it.
>
>> Concerning K8N-DL motherboard -current BIOS 1004 is very buggy. It has
>> screwed up ACPI APIC table. To use onboard lan and usb, I have to boot with 
>> pci=noacpi boot option. And I cannot use 1003, as I have DualCore Opterons, 
>> and 1004 the only one which supports them!
>> 
>> There is long problem with Nvidia CK804 southbridge sata under Linux.
>> Despite that the board was released some 8 month ago, it still cannot be
>> used! And nobody seems to care about this. ASUS in the least. I was able to 
>> boot from NVidia SATA with latest kernel and irqpoll option.
>> At first I thought that all my problems are gone at last, but the god
>> decided differently. It works at light disk load, but havy load lead to
>> system freeze. No errors, just dead freeze. I returned to silicon3114 sata.
>> At least, I have one working drive now:)
>> 
>
> I fear that there's nothing much else I can do about this K8N-DL sil CRC 
> error.  I've read the hw doc but couldn't find anything which seems helpful. 
> Let's hope something (BIOS update?) comes up soon.
>
> Sorry.
>
> -- 
> tejun
>

RE :sata_sil + UDMA CRC errors

[Alexander Shaposhnikov]

I can reproducibly hang the system by copying alot of files (some
several gigs) to some directory and than making "sync". It hangs with
the repeated messages :

Aug 22 04:18:11 m00 kernel: ata4: command 0x35 timeout, stat 0xd1
host_stat 0x1
Aug 22 04:18:11 m00 kernel: ata4: status=0xd1 { Busy }
Aug 22 04:18:11 m00 kernel: SCSI error : <3 0 0 0> return code =
0x8000002
Aug 22 04:18:11 m00 kernel: sdb: Current: sense key: Aborted Command
Aug 22 04:18:11 m00 kernel:     Additional sense: Scsi parity error
Aug 22 04:18:11 m00 kernel: end_request: I/O error, dev sdb, sector
22213847
Aug 22 04:18:11 m00 kernel: ATA: abnormal status 0xD1 on port
0xFFFFC200000042C7
Aug 22 04:18:11 m00 last message repeated 2 times