Write same error when booting

Dennis Beekman · 2013-07-06 21:42:14

I installed arch linux on my newly purchased (but second hand) T5400 Workstation wich has 2 raid0 SCSI drives and it will not boot.

When the machine starts from the installation dvd (an old one from march) all is fine, but after installation the device refuses to boot and give me a "Write same failed" error.

https://bbs.archlinux.org/viewtopic.php?id=164377 tells me to look for a file called "max_write_same_blocks" in /sys/devices and set the file to 0.
However i cannot fine this file anywhere in any off these folders.

i did find a few entries like "sys/devices/pci0000:00/0000.00.1f.1/ata1/host0/scsi_host/host0/scsi_host" but this folder has no such filein it either.
I added a scsi.conf file in /etc/tmpfiles.d and set it to add the file to each off the 8 ata folders i found across 2 devices and then add the value 0 but it did nothing for me.

This only happened in the latest few kernels i think since the livecd works and Ubuntu works aswell.

what is going on here ? can i not disable the write same command some other way ?

WonderWoofy · 2013-07-06 22:09:26

I see a couple things here that really confuse me. You say that "after installation the device refuses to boot" but then you say that you are looking through /sys/devices/blah/blah. The /sys directory is created dynamically on boot... so how are you looking through it?

Also, you indicate that your "new" machine "has 2 raid0 SCSI drives". Does this mean that you have four drives in two raid0 arrays? Or do you have two drives total arranged in a raid0. Is it hardware raid, software raid, or fake raid? Simply mentioning raid* with Linux really doesn't quite tell the whole story.

Dennis Beekman · 2013-07-07 08:17:25

Sorry i was a bit frustrated last night :-)

I have 2 15000 RPM SAS drives in raid0 via a hardware raid controller from dell.
I have used the boot/installation DVD and a arch-chroot enviroment to check out /sys

the file "max_write_same_blocks" doesn't excist anywhere within /sys and when i try to create these files through tmpfiles.d it doesn't help

skunktrader · 2013-07-07 08:50:58

https://bbs.archlinux.org/viewtopic.php?id=164377

Dennis Beekman · 2013-07-07 15:51:07

I tried that already, i tried it several times and it simply doesn't work for me.
I am going to try upgrading the firmware of the controller and the disks to see if this has any effect.

WonderWoofy · 2013-07-07 18:49:51

Yeah, I was hoping you were going to say it was software raid because I have never actually used a HW raid before. I have used dmraid (fake raid) before.

From all that I have read, unless you have some very specific requirements that would necessitate HW raid, Linux's software raid (mdadm) is of very high quality and is generally the preferrable way to go. I am not saying that you should just give up on what you are trying to do here, as I certainly understand the desire to get hardware that you own working. But if all else fails, just know that there is an amazing option that you can fall back on if raid is a requirement for you.

Sorry I can't be of any more help. Good luck!

Dennis Beekman · 2013-07-08 09:24:29

I found some old RedHat 5 drivers for the controller on the Dell website but they do not work either.
Upgrading the controller did not help either.

Does anyone here have a idea why the kernel no longer work with raid systems ? is it a bug that needs to be fixed or a permanent change that broke my system ?

WonderWoofy · 2013-07-08 14:46:05

As far as I have heard, the kernel continues to work fine with a number of HW raid controllers... but apparently the one you are using has suffered some serious regressions. You say that you have a "raid controller from dell" But maybe it you gave some real specifics about what exactly that piece of hardware is, then maybe someone might be able to give you specific pointers about some funkiness tat they have experienced as well.

Dennis Beekman · 2013-07-09 14:59:57

I have a Dell 6/iR Family Serial Attached SCSI controller with the latest firmware listed on the Dell website.
See this PDF for details on the controller http://www.dell.com/downloads/global/po … -Dixit.pdf

the controller works fine otherwise, asside from the fact that it wrongly report the second drive as "failure predicted: Yes" in smart monitoring.
Even after switching the disk for 2 others via the dealer the controller still keep reporting it that way.
I have also been given another identical raid controller by my dealer to test it with but to no avail either.

During boot with kernel 3.9.9-1 the device tells me this:

[   32.606342] sd 8:1:0:0: [sda] Got wrong page
[   32.606771] sd 8:1:0:0: [sda] Assuming drive cache: write through
[   32.608786] sd 8:1:0:0: [sda] Got wrong page
[   32.609208] sd 8:1:0:0: [sda] Assuming drive cache: write through
[   32.613361] sd 8:1:0:0: [sda] Got wrong page
[   32.613801] sd 8:1:0:0: [sda] Assuming drive cache: write through

systemd-fsck[178] : /dev/sda1: clean 149536/1221600 files, 1072118/4883752 blocks
systemd-fsck[239] : /dev/sda2: clean 11/35332096 files, 2268106/141327056 blocks
[    36.268369] sda1: WRITE SAME failed. Manually zeroing

checking with sg doesn't tell me much either. (check from the 2013-03 image with kernel 3.6.*)

sg_inq /dev/sda

standard INQUIRY:
  PQual=0  Device_type=0  RMB=0  version=0x05  [SPC-3]
  [AERC=0]  [TrmTsk=0]  NormACA=0  HiSUP=0  Resp_data_format=2
  SCCS=0  ACC=0  TPGS=0  3PC=0  Protect=0  [BQue=0]
  EncServ=0  MultiP=0  [MChngr=0]  [ACKREQQ=0]  Addr16=0
  [RelAdr=0]  WBus16=0  Sync=0  Linked=0  [TranDis=0]  CmdQue=1
    length=57 (0x39), but only fetched 56 bytes   Peripheral device type: disk
 Vendor identification: Dell   
 Product identification: VIRTUAL DISK   
 Product revision level: 1028

sg_inq -p 0xb0 /dev/sda

VPD INQUIRY: page=0xb0
inquire: field in cdb illegal (page not supported)

sg_inq -p 0xb0 -H /dev/sda

VPD INQUIRY, page code=0xb0:
inquire: field in cdb illegal (page not supported)

sg_readcap -l /dev/sda

Read Capacity results:
   Protection: prot_en=0, p_type=0, p_i_exponent=0
   Logical block provisioning: lbpme=0, lbprz=0
   Last logical block address=1169686527 (0x45b7ffff), Number of logical blocks=1169686528
   Logical block length=512 bytes
   Logical blocks per physical block exponent=0
   Lowest aligned logical block address=0
Hence:
   Device size: 598879502336 bytes, 571136.0 MiB, 598.88 GB

sg_readcap -l -H /dev/sda

 00     00 00 00 00 45 b7 ff ff  00 00 02 00 00 00 00 00
 10     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

Last edited by Dennis Beekman (2013-07-10 09:57:56)

Dennis Beekman · 2013-07-11 07:24:38

The controller works when i run it as JBOD so i just wonderwoofy's suggestion and use software raid instead without any issue.
I gues i will have to wait and see when they are going to fully resolv this issue.

Arch Linux

#1 2013-07-06 21:42:14

Write same error when booting

#2 2013-07-06 22:09:26

Re: Write same error when booting

#3 2013-07-07 08:17:25

Re: Write same error when booting

#4 2013-07-07 08:50:58

Re: Write same error when booting

#5 2013-07-07 15:51:07

Re: Write same error when booting

#6 2013-07-07 18:49:51

Re: Write same error when booting

#7 2013-07-08 09:24:29

Re: Write same error when booting

#8 2013-07-08 14:46:05

Re: Write same error when booting

#9 2013-07-09 14:59:57

Re: Write same error when booting

#10 2013-07-11 07:24:38

Re: Write same error when booting

Board footer