February 1, 201115 yr Thanks for the input RobJ. I'll give it a try although I did shut down the server and changed the power splitter and pushed the data cables in to make sure all was set in place and rebooted to find the error's gone (some info I read in another post), seems at this piont it might have been my problem not sure I'll keep an eye on it for a while and hope errors are solved. Thanks Again Lou
February 3, 201115 yr Upgraded my 4.6 to 4.7 by dropping the two files and rebooting. No issues. Very happy. I have EARS Green 4K drives without jumpers, but I am not going to bother changing them over to the new format. New disks joining the system will be formatted correctly.
February 3, 201115 yr New disks joining the system will be formatted correctly. They will be "partitioned" correctly, but only if you set the MBR 4k-aligned option in the settings. The default for 4.7 is un-aligned, so before you let unRAID clear a new drive for you, set the MBR 4k-aligned option on the settings page. Joe L.
February 3, 201115 yr Another drive replaced with -4 error here. I followed instructions in first round of posts and it seems to have gotten worse. Don't want to risk any data so asking for help. 1) Upgraded from 4.6.5 to 4.7 by copying memtest, bzimage, bzroot to flash share 2) Rebooted 3) Came up with issue 1 in screenshot, drive replaced with smaller, off by size of 4 4) Searched syslog for HPA 5) Found line Feb 2 19:23:46 Tower kernel: ata2.00: HPA detected: current 586112591, native 586114704 Also found line referencing ata7, but there was only one error on screen so I assumed it was cache drive and not a problem. 6) Ran commands with results root@Tower:/var/log# hdparm -N p3907029168 /dev/sdf /dev/sdf: setting max visible sectors to 3907029168 (permanent) max sectors = 2950727856/14715056(18446744073321613488?), HPA setting seems invalid (buggy kernel device driver?) root@Tower:/var/log# hdparm -N /dev/sdf /dev/sdf: max sectors = 2950727856/14715056(18446744073321613488?), HPA setting seems invalid (buggy kernel device driver?) root@Tower:/var/log# Rebooted 9) Error 2 on screenshot now shows Help?? Looks like my parity got way smaller somehow.
February 3, 201115 yr Sorry forgot screenshot. Also noticed that now in the syslog there are 3 refs to HPA. ata2, 7 and 9. I think I used the ata7 or 9 number mistakenly. That explains why it got worse. Feb 2 19:23:46 Tower kernel: ata2.00: HPA detected: current 586112591, native 586114704 Feb 2 19:23:46 Tower kernel: ata9.00: HPA detected: current 2950727856, native 3907029168 Feb 2 19:23:46 Tower kernel: ata7.00: HPA detected: current 3907027055, native 3907029168
February 3, 201115 yr Sorry forgot screenshot. Looks like you forgot to attach the syslog too. Joe L.
February 3, 201115 yr Ok I understand now that I applied the hdparm cmd to the wrong drive. It should have been disk1 (sde) instead of disk2 (sdf). What I don't understand is how doing that messed up my parity disk0 (sdg).
February 3, 201115 yr Ok I understand now that I applied the hdparm cmd to the wrong drive. It should have been disk1 (sde) instead of disk2 (sdf). What I don't understand is how doing that messed up my parity disk0 (sdg). Disk designations are not guaranteed to be the same from one boot to the next. It all depends on which hardware initializes itself on the motherboard first. It could have changed from one boot to the next. Second, it looks like you typed the correct command but it set the size smaller than you requested. It might be that the hdparm command will not work with that specific drive. Might need to use seatools to set the HPA.
February 3, 201115 yr Ok I understand now that I applied the hdparm cmd to the wrong drive. It should have been disk1 (sde) instead of disk2 (sdf). What I don't understand is how doing that messed up my parity disk0 (sdg). You must have issued a command directly on your parity disk, thus setting the parity drive smaller than your data drives. As Joe L already indicated, disk designations are not guaranteed to be the same between reboots and even less guaranteed between unRAID version upgrades.
February 3, 201115 yr It does look like right size for the cmd right? If I read this line correctly Feb 2 19:23:46 Tower kernel: ata9.00: 2950727856 sectors, multi 16: LBA48 NCQ (depth 0/32) then I don't see why it would be set to 29... It should be set to 39... My command should have had no effect since it was run on a drive with that size already. Just so I understand clearly and don't go down the wrong path, I should shutdown my unraid, disconnect my parity drive, set it up as an external on another computer and run seatools to set the HPA. Is that correct?
February 3, 201115 yr It does look like right size for the cmd right? If I read this line correctly Feb 2 19:23:46 Tower kernel: ata9.00: 2950727856 sectors, multi 16: LBA48 NCQ (depth 0/32) then I don't see why it would be set to 29... It should be set to 39... My command should have had no effect since it was run on a drive with that size already. Just so I understand clearly and don't go down the wrong path, I should shutdown my unraid, disconnect my parity drive, set it up as an external on another computer and run seatools to set the HPA. Is that correct? That should work.
February 3, 201115 yr The "hdparm -N" command is a dangerous command, and if used wrongly can cause data loss. I'm going to recommend that we always instruct users to use the -N parameter without the sector count first (eg. hdparm -N /dev/sda), so that (1) the user can verify first that they are working on the correct drive, and (2) can verify the correct native sector count to use. Stucco needs to be absolutely sure that the "save BIOS to disk" feature is disabled for this machine, or it may just create another HPA. And Stucco, I think we all thought that most users would realize that the use of sdf and ata7 were specific to peter_sm's machine, and would be different for every other machine. Sorry. We need to make that point clear to new users. I would leave the Cache drive alone, even though it has an HPA. Just to be safe though, since you probably don't know how long it has had it, I would run a file system check on it. With the array stopped, at a console type the following command (and answer Yes when asked): (that sda1 is sda plus a one, not an el) reiserfsck --check /dev/sda1 You should however remove the HPA from Disk 1, and correct the Parity drive, by using the hdparm commands below. Then run a parity check, which will probably report errors, but will also fix them. Afterward, run Check Disk File systems on Disk 1, but NOT the Parity drive. (using drive ID's sde and sdg from the attached syslog, which you will need to verify) hdparm -N /dev/sdg (make sure the numbers match the parity drive, if they don't then abort this. if they match current=2950727856 and native=3907029168, then continue) hdparm -N p3907029168 /dev/sdg (then verify the change) hdparm -N /dev/sdg (then repeat for Disk 1) hdparm -N /dev/sde (make sure the numbers match Disk 1, if they don't then abort this. if they match current=3907027055 and native=3907029168, then continue) hdparm -N p3907029168 /dev/sde (then verify the change) hdparm -N /dev/sde (if correct, I *think* you start the array and let the Reiser file system rebuild itself on Disk 1, the proceed with the instructions above) Update: I see you are considering removing the parity drive. Joe, is there anything wrong with the procedure above? Update2: Ahh, I see why you are going to try SeaTools instead.
February 3, 201115 yr After re-reading I see it was...dumb of me. Sorry, less familiar with linux than most I suppose. Thanks for help! root@Tower:/var/log# reiserfsck --check /dev/sda1 reiserfsck 3.6.21 (2009 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will read-only check consistency of the filesystem on /dev/sda1 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --check started at Wed Feb 2 21:45:07 2011 ########### Replaying journal: Done. Reiserfs journal '/dev/sda1' in blocks [18..8211]: 0 transactions replayed Checking internal tree.. finished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 323 Internal nodes 4 Directories 116 Other files 1225 Data block pointers 11581 (0 of them are zero) Safe links 0 ########### reiserfsck finished at Wed Feb 2 21:45:23 2011 ########### root@Tower:/var/log# root@Tower:/var/log# hdparm -N /dev/sdg /dev/sdg: max sectors = 2950727856/14715056(18446744073321613488?), HPA setting seems invalid (buggy kernel device driver?) root@Tower:/var/log# hdparm -N p3907029168 /dev/sdg /dev/sdg: setting max visible sectors to 3907029168 (permanent) SET_MAX_ADDRESS failed: Input/output error max sectors = 2950727856/14715056(18446744073321613488?), HPA setting seems invalid (buggy kernel device driver?) root@Tower:/var/log# Number matched so ran on sdg, but then stopped because of failure. No reboots.
February 3, 201115 yr You can only set the HPA once per power cycle on a given disk. Perhaps power down/up and try again. Joe L.
February 3, 201115 yr And if that does not work, then Joe was right, off to SeaTools with that drive.
February 3, 201115 yr Might SeaTools have a problem with this being a WD drive? Is there a WD equivalent tool, that can remove HPA's?
February 3, 201115 yr i had a similar problem and used hdat2 to fix the hpa issue. i didn't manage to boot from the hdat2 iso image (off a usb flash drive), so i had to create a freedos boot flash, copy hdat2 to the flash drive and run it from there.
February 4, 201115 yr I can't seem to find the HPA feature in bios to turn off. I have scoured for "copy bios to disk", "hidden protected area" or "HPA". Anyone have a clue? I have an Award 6.00 F11 on a Gigabyte GS-965P-DS3 Rev 1.3.
February 4, 201115 yr I can't seem to find the HPA feature in bios to turn off. I have scoured for "copy bios to disk", "hidden protected area" or "HPA". Anyone have a clue? I have an Award 6.00 F11 on a Gigabyte GS-965P-DS3 Rev 1.3. There was a series of Gigabyte motherboards where it could not be disabled. most people end up replacing the motherboards, or if possible, upgrading the BIOS, as they are a ticking time bomb for any RAID system.
February 4, 201115 yr Hi I just started a preclear on a EARS Green 4K drives without the jumpers using the preclear_disk.sh -A /dev/sdb command it's at 13% and going. Questions: Once completed and put into array do I have to change the setting in unraid 4.7 to MRB:4K-aligned? And in my syslog I have these errors are these normal when doing a preclear? Thanks in advance for any feed back on this. Lou eb 4 11:04:38 Unraid kernel: Pid: 6025, comm: hdparm Tainted: G W 2.6.32.9-unRAID #8 Feb 4 11:04:38 Unraid kernel: Call Trace: Feb 4 11:04:38 Unraid kernel: [<c102449e>] warn_slowpath_common+0x60/0x77 Feb 4 11:04:38 Unraid kernel: [<c10244c2>] warn_slowpath_null+0xd/0x10 Feb 4 11:04:38 Unraid kernel: [<c11b624d>] ata_qc_issue+0x10b/0x308 Feb 4 11:04:38 Unraid kernel: [<c11ba260>] ata_scsi_translate+0xd1/0xff Feb 4 11:04:38 Unraid kernel: [<c11a816c>] ? scsi_done+0x0/0xd Feb 4 11:04:38 Unraid kernel: [<c11a816c>] ? scsi_done+0x0/0xd Feb 4 11:04:38 Unraid kernel: [<c11baa40>] ata_sas_queuecmd+0x120/0x1d7 Feb 4 11:04:38 Unraid kernel: [<c11bc6df>] ? ata_scsi_pass_thru+0x0/0x21d Feb 4 11:04:38 Unraid kernel: [<f842169a>] sas_queuecommand+0x65/0x20d [libsas] Feb 4 11:04:38 Unraid kernel: [<c11a816c>] ? scsi_done+0x0/0xd Feb 4 11:04:38 Unraid kernel: [<c11a82c0>] scsi_dispatch_cmd+0x147/0x181 Feb 4 11:04:38 Unraid kernel: [<c11ace4d>] scsi_request_fn+0x351/0x376 Feb 4 11:04:38 Unraid kernel: [<c1126798>] __blk_run_queue+0x78/0x10c Feb 4 11:04:38 Unraid kernel: [<c1124446>] elv_insert+0x67/0x153 Feb 4 11:04:38 Unraid kernel: [<c11245b8>] __elv_add_request+0x86/0x8b Feb 4 11:04:38 Unraid kernel: [<c1129343>] blk_execute_rq_nowait+0x4f/0x73 Feb 4 11:04:38 Unraid kernel: [<c11293dc>] blk_execute_rq+0x75/0x91 Feb 4 11:04:38 Unraid kernel: [<c11292cc>] ? blk_end_sync_rq+0x0/0x28 Feb 4 11:04:38 Unraid kernel: [<c112636f>] ? get_request+0x204/0x28d Feb 4 11:04:38 Unraid kernel: [<c11269d6>] ? get_request_wait+0x2b/0xd9 Feb 4 11:04:38 Unraid kernel: [<c112c2bf>] sg_io+0x22d/0x30a Feb 4 11:04:38 Unraid kernel: [<c112c5a8>] scsi_cmd_ioctl+0x20c/0x3bc Feb 4 11:04:38 Unraid kernel: [<c104cd4f>] ? __alloc_pages_nodemask+0xdb/0x42f Feb 4 11:04:38 Unraid kernel: [<c11b3257>] sd_ioctl+0x6a/0x8c Feb 4 11:04:38 Unraid kernel: [<c112a420>] __blkdev_driver_ioctl+0x50/0x62 Feb 4 11:04:38 Unraid kernel: [<c112ad1c>] blkdev_ioctl+0x8b0/0x8dc Feb 4 11:04:38 Unraid kernel: [<c1131e2d>] ? kobject_get+0x12/0x17 Feb 4 11:04:38 Unraid kernel: [<c112b0f8>] ? get_disk+0x4a/0x61 Feb 4 11:04:38 Unraid kernel: [<c101b028>] ? kmap_atomic+0x14/0x16 Feb 4 11:04:38 Unraid kernel: [<c11334a5>] ? radix_tree_lookup_slot+0xd/0xf Feb 4 11:04:38 Unraid kernel: [<c104a179>] ? filemap_fault+0xb8/0x305 Feb 4 11:04:38 Unraid kernel: [<c1048c43>] ? unlock_page+0x18/0x1b Feb 4 11:04:38 Unraid kernel: [<c1057c63>] ? __do_fault+0x3a7/0x3da Feb 4 11:04:38 Unraid kernel: [<c105985f>] ? handle_mm_fault+0x42d/0x8f1 Feb 4 11:04:38 Unraid kernel: [<c108b6c6>] block_ioctl+0x2a/0x32 Feb 4 11:04:38 Unraid kernel: [<c108b69c>] ? block_ioctl+0x0/0x32 Feb 4 11:04:38 Unraid kernel: [<c10769d5>] vfs_ioctl+0x22/0x67 Feb 4 11:04:38 Unraid kernel: [<c1076f33>] do_vfs_ioctl+0x478/0x4ac Feb 4 11:04:38 Unraid kernel: [<c105dcdd>] ? do_mmap_pgoff+0x232/0x294 Feb 4 11:04:38 Unraid kernel: [<c1076f93>] sys_ioctl+0x2c/0x45 Feb 4 11:04:38 Unraid kernel: [<c1002935>] syscall_call+0x7/0xb Feb 4 11:04:38 Unraid kernel: ---[ end trace d30d5becdb4af75b ]---
February 4, 201115 yr Hi I just started a preclear on a EARS Green 4K drives without the jumpers using the preclear_disk.sh -A /dev/sdb command it's at 13% and going. Questions: Once completed and put into array do I have to change the setting in unraid 4.7 to MRB:4K-aligned? If it is properly precleared, the MBR setting is ignored and the preclear MBR used. If the preclear signature is not valid, and there is not already a valid MBR, the MBR-4k or MBR-unaligned setting is used. And in my syslog I have these errors are these normal when doing a preclear? Thanks in advance for any feed back on this. Lou Those errors are not normal. Are they continuing? They seem to be occurring when hdparm is trying to map some memory. Are you running multiple preclears? Or running other process that may limit the memory available?) How much memory do you have? What does the free command show? Joe L.
February 4, 201115 yr Hi I just started a preclear on a EARS Green 4K drives without the jumpers using the preclear_disk.sh -A /dev/sdb command it's at 13% and going. Questions: Once completed and put into array do I have to change the setting in unraid 4.7 to MRB:4K-aligned? If it is properly precleared, the MBR setting is ignored and the preclear MBR used. If the preclear signature is not valid, and there is not already a valid MBR, the MBR-4k or MBR-unaligned setting is used. And in my syslog I have these errors are these normal when doing a preclear? Thanks in advance for any feed back on this. Lou Those errors are not normal. Are they continuing? No They seem to be occurring when hdparm is trying to map some memory. Are you running multiple preclears? No just the one Or running other process that may limit the memory available?) Mabey something in unmenu i'll check How much memory do you have? 4GiG What does the free command show? In unmenu memory info it shows 2844360 free Joe L.
February 5, 201115 yr Lou, I noted 3 other cases very similar to yours (almost identical Call Traces), and summarized them here. You may want to monitor that thread. Also, it may be helpful if you could provide the 3 or 4 lines preceding the syslog piece you included above.
February 5, 201115 yr Lou, I noted 3 other cases very similar to yours (almost identical Call Traces), and summarized them here. You may want to monitor that thread. Also, it may be helpful if you could provide the 3 or 4 lines preceding the syslog piece you included above. Thanks RobJ here is the full syslog. [ syslog-2011-02-04.txt
Archived
This topic is now archived and is closed to further replies.