ok, just spent the last couple hours on the phone with my brother, he has replaced a 320gb drive with a 1tb drive to expand, but is having problems writing to it.

 

he pulled everything off the 320 to start with the night before getting the 1tb, removed it and replaced, started it up and it added it and started a parity sync, no format nothing.

 

then when going to write it would just freeze up, now before all this, the computer was getting stuck in bios where it comes up press bla bla to enter raid utility(drives arn't raided) when he added the 1tb, so he went into bios and disabled raid feature, which got it booting up into unraid.

 

we've got him to try a few things, but the main is we pulled the drive out and put it into his main computer to check if it was a fualty drive, gone into drive manager, deleted the volume/partition, formated it(in ntfs), all was good so replaced back into unraid,

 

motherboard is an abit ic7-max3

 

the main 2 sata ports, have a 1tb(parity) and a 750gb data

the 4 sillicon 3114 chip has the new 1tb and 3x320gb

 

tried swaping the 750 and 1tb data discs ports around, and with the thing in bios set to auto it froze on the raid thing again, so disabled again swaped back to the original way and rebooted

 

booted up, it's seen drive replaced, checked and hit restore to just reset everything, then it's come up with start, and it's doing the parity sync again. did no clearing and did no option to format??

 

weather it's going to allow writing after the parity sync is done this time or not, time will tell.... but why isn't it doing a format, thats whats throwing me

 

>> Oct  4 19:55:35 Tower kernel: PCI: Using ACPI for IRQ routing

>> Oct  4 19:55:35 Tower kernel: PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report

 

Don't know id this has anything to do with it.

It could be related to the speed of the new drive and ACPI IRQ routing.

I know with my MSI boards, I have to put parameters on the syslinux line to get the board to be stable.

symptoms were... the board and drive would work, but any heavy I/O and the board would freeze.

options uised and tested with 

noacpi 

irqpoll

pci=routeirq

 

A lot of the 3114 cards need a firmware update to access drives over 500 megabytes. An update is on the Silicon Image web site.

A lot of the 3114 cards need a firmware update to access drives over 500 megabytes. An update is on the Silicon Image web site.

 

it's not a card, it's onboard

 

i'll get him to try putting them lines into the syslinux.cfg file when he's on

I think this may be a simple methodology misunderstanding.

 

he pulled everything off the 320 to start with the night before getting the 1tb, removed it and replaced, started it up and it added it and started a parity sync, no format nothing.

 

You don't mention what status messages he saw, or buttons clicked, or what changes he made to drive assignments on the Devices tab, so I may be wrong here, but I'll try and indicate what I think may have happened.  After removing one drive and installing another drive and booting unRAID, he would probably see the unRAID array with a drive missing, the one he removed.  Until he goes to the Devices tab and assigns the new drive to the same Disk number as the drive that was removed, unRAID does not include the new drive.  So if he clicks the Restore button, the config will be reset and a parity sync will begin, building parity info from the drives that remain, basically removing the old drive from the parity info.  If instead he went to the Devices tab and assigned the new drive to the old ones disk number, then Started the array, a data drive rebuild would begin, copying the contents of the old drive (reconstructed) to the new drive and clearing the remainder of the new drive.  No format or clearing is necessary, because the process of rebuilding a drive copies all of the logical blocks of one drive to the other, including its formatting and file system and files and folders, if any.  I may not have guessed right here, but I hope that this explanation will help you and he figure out what was actually happening, each time he tried to get the new drive up and running.

 

As to the apparent freeze up on attempted writing, is it possible it was rebuilding parity at the time?  That looks like a slower CPU with only 512MB, so everything would be very slow during a parity sync.  Other than that, I don't know.  Perhaps a syslog might help, if it covers the period of the freeze up.

 

As to the RAID boot issue, it would have been nice if that SiI3114 controller was on a card, because you could have obtained a firmware that was not only updated for the larger drives, but was the non-RAID version, removing the RAID issue.  Since it is onboard, your only hope is to check Abit for a BIOS upgrade, that includes a 3114 update.

 

As to the "pci=routeirq" parameter, that unfortunately will probably not help, although you are welcome to try it and the other suggestions.  Those lines are found in most syslogs, as a generic instruction in case you discover a device that will not start, and is mostly a relic from the past.  In fact, it appears to have been removed from the 2.6.26 kernel, because I can't find it in any of the v4.4 beta syslogs.

 

From my reading on it, the programmer that added that parameter, did so because of a change made in how the IRQ's were allocated, from the old method of figuring out which IRQ was tied to which device, to a new method that read the ACPI tables for IRQ assignments.  It was discovered that there were old or broken drivers that had not been updated to use the new method, and so he added this parameter to force the use of the old method.  The symptom that this parameter fixes is a device will not start, at all, because it does not get an IRQ assigned to it.  He also added in syslogs a note to email him if this parameter made a device work, and he would then fix that old or broken driver.  Later, he asked that the syslog message be toned down to the current message, quoted above, probably because he was tired of the emails, but also probably because it was no longer needed as drivers had been updated.  He also mentioned at the same time, that he would recommend that the message be removed completely in a month or two (I believe this was 2004 or early 2005).  But it was discovered that manufacturers would occasionally make a mistake in the ACPI tables about the correct IRQ.  This parameter was therefore still useful, because it would allow a user to tell his kernel to ignore the ACPI tables, and use the old method, and once again his device would work.  With 2.6.26, it looks like the message may have been removed again, perhaps for good.

ok, he's just tried writting another file to disk 2, it came up with all this stuff on the console screen, had him capture a syslog.. and here it is

 

ps. robJ, yes he did assign the new disk to the slot the 320 came from, and did restore

Now that's bad, indicates a crash of the ReiserFS subsystem, perhaps a corrupted Reiser file system on Disk 2.  So I took a closer look at both syslogs, to see how the mounting of the drive and its Reiser file system went, and found some 'strangeness'.

 

I have to start by apologizing, I was in a hurry and somewhat distracted when I read your first post and looked at the first syslog, and I didn't see anything wrong, or inconsistent with what you reported.  Then when I wrote the above, I never went back to examine that syslog in more depth.

 

One of the things that is strange is that in both syslogs, a good Reiser file system is found on the drive, and it even checks out fine, with a good transaction log and no transactions to be replayed the first time, and the expected two the second time.  The only way that a good Reiser file system is mounting correctly, is if this is a drive that had already been prepared and mounted in an unRAID or other Linux system, or was rebuilt, at least partly, in a previous session, or what it found and tested was the virtual Disk 2 (more on that later).

 

What is even more strange, is that in the first syslog, Disk 2 shows up first as replaced, not missing or good.  When you first install a drive, it is not assigned yet, so it will appear in the Device Inventory, but is not yet a part of the array.  The status of the disk being replaced should begin as missing, not replaced.  You will then see in the syslog a users' actions in assigning the new drive, and once assigned, it should show as replaced (as I recall).  Following that, you should see, in the syslog, actions consistent with Starting or Restoring, either parity being rebuilt or the drive being rebuilt, and when that finishes, the drive is fully online, and the drive status is no longer replaced.  The fact that it begins with the status of replaced seems to point to a previous rebuild of that drive, but one that did not finish completely.  Perhaps that is why the reiserfs module crashed later.

 

One thing that concerns me (and will perhaps concern Tom) is that there is no way to tell in the syslog if a disk is referring to its physical manifestation, or its virtual form, if it had been disabled.  In my own case, when a drive was disabled from timeout errors (unrelated to this), there was absolutely no indication in the syslog of a disabled drive (or of any issues at all), that that drive was actually being accessed as a virtual, reconstructed drive.  The only indication was a red ball in the web page.  I have to wonder therefore if it is possible that the discovery and mounting of the reiserfs was of the virtual drive, and not the physical drive!  More logging of the actual status of a drive would be very helpful, both of the real and the virtual.

 

Coming back to your drive, what I would suggest is: don't bother trying to 'fix' the Reiser system with reiserfsck, but to un-assign the new drive, run fdisk on it and remove all partitions, Start the array without it assigned, so that parity will be built without it, then shut down and reboot, then assign the drive and it should then be treated as a New drive and be cleared and formatted.

 

 

Edit: one more 'strangeness' in the first syslog, it wrote an MBR to Disk 2, then immediately found and mounted a good Reiser file system!  Obviously something is very wrong.

so far so good, removed, reassigned disk5 into disk2 slot, restored, rebuilt parity, readded 1tb into disk5, it did a clear, format, and been copying files onto it now for the past hour.

 

so definatly would seem to be fixed, something definatly went wrong when it added the 1tb as a replacment to the 320