Lou Posted February 1, 2011 Share Posted February 1, 2011 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 Quote Link to comment
kortina Posted February 3, 2011 Share Posted February 3, 2011 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. Quote Link to comment
Joe L. Posted February 3, 2011 Share Posted February 3, 2011 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. Quote Link to comment
Stucco Posted February 3, 2011 Share Posted February 3, 2011 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. Quote Link to comment
Stucco Posted February 3, 2011 Share Posted February 3, 2011 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 Quote Link to comment
Joe L. Posted February 3, 2011 Share Posted February 3, 2011 Sorry forgot screenshot. Looks like you forgot to attach the syslog too. Joe L. Quote Link to comment
Stucco Posted February 3, 2011 Share Posted February 3, 2011 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). Quote Link to comment
Joe L. Posted February 3, 2011 Share Posted February 3, 2011 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. Quote Link to comment
BRiT Posted February 3, 2011 Share Posted February 3, 2011 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. Quote Link to comment
Stucco Posted February 3, 2011 Share Posted February 3, 2011 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? Quote Link to comment
Joe L. Posted February 3, 2011 Share Posted February 3, 2011 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. Quote Link to comment
RobJ Posted February 3, 2011 Share Posted February 3, 2011 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. Quote Link to comment
Stucco Posted February 3, 2011 Share Posted February 3, 2011 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. Quote Link to comment
Joe L. Posted February 3, 2011 Share Posted February 3, 2011 You can only set the HPA once per power cycle on a given disk. Perhaps power down/up and try again. Joe L. Quote Link to comment
RobJ Posted February 3, 2011 Share Posted February 3, 2011 And if that does not work, then Joe was right, off to SeaTools with that drive. Quote Link to comment
RobJ Posted February 3, 2011 Share Posted February 3, 2011 Might SeaTools have a problem with this being a WD drive? Is there a WD equivalent tool, that can remove HPA's? Quote Link to comment
jbrodriguez Posted February 3, 2011 Share Posted February 3, 2011 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. Quote Link to comment
Stucco Posted February 4, 2011 Share Posted February 4, 2011 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. Quote Link to comment
Joe L. Posted February 4, 2011 Share Posted February 4, 2011 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. Quote Link to comment
Lou Posted February 4, 2011 Share Posted February 4, 2011 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 ]--- Quote Link to comment
Joe L. Posted February 4, 2011 Share Posted February 4, 2011 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. Quote Link to comment
Lou Posted February 4, 2011 Share Posted February 4, 2011 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. Quote Link to comment
RobJ Posted February 5, 2011 Share Posted February 5, 2011 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. Quote Link to comment
Lou Posted February 5, 2011 Share Posted February 5, 2011 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 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.