hdparm APM level when AC adapter is plugged/unplugged
Hi, It seems /usr/lib/pm-utils/power.d/95hdparm-apm script from the hdparm package may be called when AC power adapter is plugged or unplugged (true/false arguments). I see that this script is invoked by /lib/udev/rules.d/85-hdparm.rules through /lib/udev/hdparm on boot or resume. What package should be installed to call the script in response of change or power supply? Is that part of the script survived from the times of HAL? I expect some udev rule that acts for SUBSYSTEM=power_supply. Perhaps laptop-mode-tools may be installed as an alternative solution and I will have once more tool that does something with disks. My worries are that it may interact with hdparm and udisks2 in some strange way. The context of the question is the following. I added a hard disk drive and before I have created partitions I noticed regular sound of parking heads. It is udisks2 that decided to check SMART every 10 minutes for the disk with no mounted partition. The Toshiba disk reports 254 APM level (likely set by hdparm), active/idle state and parks heads with 2minutes timeout. I have not managed to read value of this timeout using hdparm or sdparm. As to udisks2, it is not possible to change polling interval, but likely it can be instructed to ignore particular disk without disabling SMART completely. The price is that udisks will ignore the disk completely. If I explicitly set standby (spindown) timeout <10min (e.g. by creating /etc/udisks2/.conf file) then disk is not waken up from standby state by udisks2 any more. However hdparm may distinguish on battery and connected to mains states, so it is more flexible than udisks. Since I have dug into this problem, I decided to check whether disk APM value is adjusted when power state is changed after resume (during resume 128/254 values are chosen depending on on_ac_power script). So I am disappointed by default behavior of tools, but I hope that I forgot to install some package that calls scripts from hdparm on connect/disconnect of power adapter.
Re: hdparm ignoring spindown_time in config when called with by-id symlink
Il 02/01/19 14:35, Reco ha scritto: So udev is not to blame here. It's shell-based config parsing library. Possibly an upstream issue for hdparm, then. Nice :( Whitelist it. A file should be called /etc/apparmor.d/local/usr.bin.thunderbird. Thanks for the tip, saving for later. echo 1 > /sys/block/sdb/device/delete Assuming that your SATA controller is sane, it'll powerdown the drive until the next reboot or SATA bus scan. Interesting!
Re: hdparm ignoring spindown_time in config when called with by-id symlink
Hi.
On Wed, Jan 02, 2019 at 01:34:14PM +0100, Andrea Borgia wrote:
> Il 02/01/19 12:15, Reco ha scritto:
>
> > What about this:
> > DEVNAME=/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ \
> > sh -x /lib/udev/hdparm >> /tmp/hdparm.log 2>&1
>
> I had tried it, too, and it looks in line with the results:
Good news are - your configuration file comes into play:
> + OPTIONS= -B1 -S6
Bad news are - /lib/hdparm/hdparm-functions screws you over:
> + read KEY SEP VALUE
> + [ -z /dev/sdb ]
> + [ -n -B1 -S6 ]
> + [ /dev/sdb = /dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_
> ]
This corresponds to line 222 of aforementioned script:
if [ -n "$OPTIONS" ] && [ "$DISC" = "$WANTED_DISK" ]
then
echo $OPTIONS
return 0
fi
You have options defined, but second comparison fails. $DISC seems to be
defined at line 113:
DISC=$(readlink -m "$KEY")
DISC=${DISC%%[[:digit:]]*}
And readlink 'helpfully' transforms your 'persistent' HDD name to
/dev/sdb.
So udev is not to blame here. It's shell-based config parsing library.
> (copypasted because I found out only later that Thunderbird could not attach
> files from /tmp because of AppArmor)
Whitelist it. A file should be called
/etc/apparmor.d/local/usr.bin.thunderbird.
> > > 2) am I wrong in testing with the symlink instead of the real device name?
> > I'd rather remove this HDD via /sys interface as it's unused.
>
> Apart from the fact I don't know (yet) how to do that, what good would it do?
echo 1 > /sys/block/sdb/device/delete
Assuming that your SATA controller is sane, it'll powerdown the drive
until the next reboot or SATA bus scan.
Reco
Re: hdparm ignoring spindown_time in config when called with by-id symlink
Il 02/01/19 12:15, Reco ha scritto: What about this: DEVNAME=/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ \ sh -x /lib/udev/hdparm >> /tmp/hdparm.log 2>&1 I had tried it, too, and it looks in line with the results: + set -e + [ -n /dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ ] + . /lib/hdparm/hdparm-functions + [ -e /proc/cmdline ] + grep -wq nohdparm /proc/cmdline + raidstat=OK + [ -e /proc/mdstat ] + egrep -iq resync|repair|recover|check /proc/mdstat + [ OK = OK ] + hdparm_options /dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ + local WANTED_DISK=/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ + local DISC= DEFAULT= DEF_QUIET= COMMAND_LINE= + local OPTIONS OPT_QUIET KEY SEP VALUE + egrep -v ^[[:space:]]*(#|$) /etc/hdparm.conf + hdparm_try_apm /dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ + [ -z ] + udevadm info -n /dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ -q property + sed -n s/^ID_PATH=//p + local ID_PATH=pci-:15:00.1-ata-2 + [ -z ] + udevadm info -n /dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ -q property + sed -n s/^ID_ATA_FEATURE_SET_APM=//p + local ID_ATA_FEATURE_SET_APM=1 + [ 1 = 1 ] + return 0 + hdparm_is_on_battery + on_ac_power + [ 255 -eq 1 ] + hdparm_set_option -B254 + local NEW_OPT= NEW_DEF= + test -n + DEFAULT= -B254 + read KEY SEP VALUE + [ -h /dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ ] + readlink -m /dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ + DISC=/dev/sdb + DISC=/dev/sdb + OPTIONS= -B254 + OPT_QUIET= + read KEY SEP VALUE + hdparm_is_on_battery + on_ac_power + [ 255 -eq 1 ] + hdparm_set_option -B1 + local NEW_OPT= NEW_DEF= + test -n /dev/sdb + test x-B != x-B + NEW_OPT= + OPTIONS= -B1 + read KEY SEP VALUE + hdparm_set_option -S6 + local NEW_OPT= NEW_DEF= + test -n /dev/sdb + test x-B != x-S + NEW_OPT= -B1 + OPTIONS= -B1 -S6 + read KEY SEP VALUE + [ -z /dev/sdb ] + [ -n -B1 -S6 ] + [ /dev/sdb = /dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ ] + COMMAND_LINE= + read KEY SEP VALUE + [ -n -B254 ] + echo -B254 + return 0 + OPTIONS=-B254 + [ -n -B254 ] + /sbin/hdparm -B254 /dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ /dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_: setting Advanced Power Management level to 0xfe (254) APM_level = 254 + exit 0 (copypasted because I found out only later that Thunderbird could not attach files from /tmp because of AppArmor) 1) am I wrong in using the by-id link to achieve a stable configuration? You might get a race here. by-id symlinks are created by udev, so it's possible to call hdparm udev script before actual symlink creation. Right, I had not considered that. However, in real life it seems to be working: I rebooted to check the DEVNAME, the script is being called with the actual "sd" name (now /dev/sda, before /dev/sdb... I might have had a USB stick plugged in during the previous reboot) 2) am I wrong in testing with the symlink instead of the real device name? I'd rather remove this HDD via /sys interface as it's unused. Apart from the fact I don't know (yet) how to do that, what good would it do? I'm not worried about unauthorized access, I just want to spin it down in order to, possibly, preserve it. Would removing it via /sys achieve this goal? Other benefits to your suggestion? 3) if not, should I file a bug on hdparm? I've tried to reproduce your problem, but 'sh -x' invocation with your configuration file got me this: /sbin/hdparm -B1 -S6 \ /dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ I suspect that your problem cannot be explained by hdparm bug. Hmm, you don't have that disk in your system so the readlink call in the script will return the by-id name unchanged (I've tried that) and the comparison isn't really valid, I'm afraid. What happens if you try with an existing "id" for your system? To recap, persistent names in the config seem to be ok, but the script apparently must be invoked with the actual name. This is what udev does and it works. Thank you, Reco, for your help. I'm CC'ing the maintainer for one quick feedback, if possible: SNAFU on my part, right? Regards, Andrea.
Re: hdparm ignoring spindown_time in config when called with by-id symlink
Hi. On Tue, Jan 01, 2019 at 08:39:13PM +0100, Andrea Borgia wrote: > My PC has two disks, a NVME for Debian/testing and an old 2.5 drive for an OS > that shall remain nameless :) > > Since the 2.5 disc isn't at all used by Linux, I figured I might as well set > a very aggressive spindown time of, say, 30s and I wrote this in hdparm.conf: > > Then I tried checking whether hdparm would work when run via udev, with the > following command: > DEVNAME=/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ > /lib/udev/hdparm >> /tmp/hdparm.log 2>&1 > (suggestion taken from: > https://stackoverflow.com/questions/49841690/hdparm-conf-settings-dont-seem-to-run-at-boot) What about this: DEVNAME=/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ \ sh -x /lib/udev/hdparm >> /tmp/hdparm.log 2>&1 > Now, the questions: > 1) am I wrong in using the by-id link to achieve a stable configuration? You might get a race here. by-id symlinks are created by udev, so it's possible to call hdparm udev script before actual symlink creation. > 2) am I wrong in testing with the symlink instead of the real device name? I'd rather remove this HDD via /sys interface as it's unused. > 3) if not, should I file a bug on hdparm? I've tried to reproduce your problem, but 'sh -x' invocation with your configuration file got me this: /sbin/hdparm -B1 -S6 \ /dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ I suspect that your problem cannot be explained by hdparm bug. Reco
hdparm ignoring spindown_time in config when called with by-id symlink
Hi.
My PC has two disks, a NVME for Debian/testing and an old 2.5 drive for
an OS that shall remain nameless :)
Since the 2.5 disc isn't at all used by Linux, I figured I might as well
set a very aggressive spindown time of, say, 30s and I wrote this in
hdparm.conf:
/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ {
apm = 1
spindown_time = 6
}
To check whether the entry was applied, first I manually set the
spindown to 1 unit, that is 5s, woke the drive up with cfdisk, confirmed
it was active with hdparm -C, waited 5s, confirmed it was in standby.
So if the drive sleeps just 5s I'll know the change was ignored.
Then I tried checking whether hdparm would work when run via udev, with
the following command:
DEVNAME=/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_
/lib/udev/hdparm >> /tmp/hdparm.log 2>&1
(suggestion taken from:
https://stackoverflow.com/questions/49841690/hdparm-conf-settings-dont-seem-to-run-at-boot)
No go:
/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_:
setting Advanced Power Management level to 0xfe (254)
APM_level = 254
More importantly, the drive is still on 5s spindown.
I've tried with the apm option and without, no changes.
I've manually verified the by-id link, checks out.
However, if I invoke the udev script with /dev/sdb, the output confirms
it is working:
/dev/sdb:
setting Advanced Power Management level to 0x01 (1)
setting standby to 6 (30 seconds)
APM_level = 1
Now, the questions:
1) am I wrong in using the by-id link to achieve a stable configuration?
2) am I wrong in testing with the symlink instead of the real device name?
3) if not, should I file a bug on hdparm?
Other relevant bugs:
#725884: in my case, running hdparm manually works just fine, it's the
udev script that seems to fail somehow
#795025: my drive does not return any error when hdparm is run with
"verbose"
#880008: interesting...
Thanks,
Andrea.
Re: why is the kernel "unsleeping" a HDD put to sleep with hdparm -Y ?
On Mon, 27 Aug 2018 19:48:18 +1000 Zenaan Harkness wrote: > So I have a 'spare' internal spinning rust bucket which I only use > for backups, and so most of the time when I'm not using it I put it > to sleep with: > > sudo hdparm -Y /dev/sda > > Unfortunately the kernel wakes the drive up again: Since you don't use it that much, why "sleep" it at all? Just unmount it. Check fstab, too, to see if it's list, and make it "noauto" or remove the stanza entirely. That's what I did with a infrequently used drive. B
Re: why is the kernel "unsleeping" a HDD put to sleep with hdparm -Y ?
On 2018-08-27 10:48, Zenaan Harkness wrote: So I have a 'spare' internal spinning rust bucket which I only use for backups, and so most of the time when I'm not using it I put it to sleep with: sudo hdparm -Y /dev/sda sorry cannot help but I have similar disk and this seems like a good idea. Presume have to unmount disk before putting to sleep ? mick -- Key ID4BFEBB31
Re: why is the kernel "unsleeping" a HDD put to sleep with hdparm -Y ?
Zenaan Harkness writes: >So I have a 'spare' internal spinning rust bucket which I only use >for backups, and so most of the time when I'm not using it I put it >to sleep with: > >sudo hdparm -Y /dev/sda > >Unfortunately the kernel wakes the drive up again: > >Aug 27 19:44:40 eye kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 >action 0x6 >Aug 27 19:44:40 eye kernel: ata1.00: waking up from sleep >Aug 27 19:44:40 eye kernel: ata1: hard resetting link >Aug 27 19:44:41 eye kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl >300) >Aug 27 19:44:41 eye kernel: ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET >FEATURES) succeeded >Aug 27 19:44:41 eye kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY >FREEZE LOCK) filtered out >Aug 27 19:44:41 eye kernel: ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET >FEATURES) filtered out >Aug 27 19:44:43 eye kernel: ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET >FEATURES) succeeded >Aug 27 19:44:43 eye kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY >FREEZE LOCK) filtered out >Aug 27 19:44:43 eye kernel: ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET >FEATURES) filtered out >Aug 27 19:44:43 eye kernel: ata1.00: configured for UDMA/133 >Aug 27 19:44:43 eye kernel: ata1: EH complete > >Why is the kernel doing this, and how do I stop it from happening? > >TIA, I do a similar thing but use hdparm -y. I never see the drive spin back up. I would look in the log for a cron job related to the drive comming back up.
Re: why is the kernel "unsleeping" a HDD put to sleep with hdparm -Y ?
On Mon, Aug 27, 2018 at 07:48:18PM +1000, Zenaan Harkness wrote: > So I have a 'spare' internal spinning rust bucket which I only use > for backups, and so most of the time when I'm not using it I put it > to sleep with: > > sudo hdparm -Y /dev/sda > > Unfortunately the kernel wakes the drive up again: > > Aug 27 19:44:40 eye kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 > action 0x6 > Aug 27 19:44:40 eye kernel: ata1.00: waking up from sleep > Aug 27 19:44:40 eye kernel: ata1: hard resetting link > Aug 27 19:44:41 eye kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl > 300) > Aug 27 19:44:41 eye kernel: ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET > FEATURES) succeeded > Aug 27 19:44:41 eye kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY > FREEZE LOCK) filtered out > Aug 27 19:44:41 eye kernel: ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET > FEATURES) filtered out > Aug 27 19:44:43 eye kernel: ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET > FEATURES) succeeded > Aug 27 19:44:43 eye kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY > FREEZE LOCK) filtered out > Aug 27 19:44:43 eye kernel: ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET > FEATURES) filtered out > Aug 27 19:44:43 eye kernel: ata1.00: configured for UDMA/133 > Aug 27 19:44:43 eye kernel: ata1: EH complete > > Why is the kernel doing this, and how do I stop it from happening? How often does it happen? -dsr-
why is the kernel "unsleeping" a HDD put to sleep with hdparm -Y ?
So I have a 'spare' internal spinning rust bucket which I only use for backups, and so most of the time when I'm not using it I put it to sleep with: sudo hdparm -Y /dev/sda Unfortunately the kernel wakes the drive up again: Aug 27 19:44:40 eye kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 Aug 27 19:44:40 eye kernel: ata1.00: waking up from sleep Aug 27 19:44:40 eye kernel: ata1: hard resetting link Aug 27 19:44:41 eye kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Aug 27 19:44:41 eye kernel: ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded Aug 27 19:44:41 eye kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out Aug 27 19:44:41 eye kernel: ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out Aug 27 19:44:43 eye kernel: ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded Aug 27 19:44:43 eye kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out Aug 27 19:44:43 eye kernel: ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out Aug 27 19:44:43 eye kernel: ata1.00: configured for UDMA/133 Aug 27 19:44:43 eye kernel: ata1: EH complete Why is the kernel doing this, and how do I stop it from happening? TIA,
Q: Host protected area (HPA), hdparm, and 4 KB sectors
I have a couple of questions concerning the host protected area (HPA) on SATA disks. All the following is no problem with my Linux system, I just want to understand things: 1. My two Seagate Barracuda 2 TB disks were not bought as part of a completely installed computer but separately as single parts. I.e. there should be no recovery or installation software or similar in the HPA. However, both drives have a HPA of about 1 MB. What could be the reason for Seagate to do that? # hdparm -N /dev/sda /dev/sda: max sectors = 3907027055/3907029168, HPA is enabled 2. The man page of hdparm warns about changing the HPA using hdparm -N, because data loss is extremely likely. Is that only because of the possibility of using the command incorrectly or are there other risks, too? Otherwise, I'd like to disable the HPA and see what's in that ~1 MB space. 3. Does the kernel or hdparm have a problem with HPA and disks that use 4 KB sectors? I have an external 4 TB USB hard disk that is shown like this: # fdisk -l /dev/sdc Disk /dev/sdc: 3.7 TiB, 4000787030016 bytes, 976754646 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0xb6217b1c Device Boot Start End Sectors Size Id Type /dev/sdc1 256 976754645 976754390 3.7T 8e Linux LVM # hdparm -I /dev/sdc | sed /^Cap/q /dev/sdc: ATA device, with non-removable media Model Number: ST4000DM000-1F2168 Serial Number: S301JQ3M Firmware Revision: CC54 Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0 Standards: Used: unknown (minor revision code 0x001f) Supported: 9 8 7 6 5 Likely used: 9 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBAuser addressable sectors: 268435455 LBA48 user addressable sectors: 7814037168 Logical Sector size: 512 bytes Physical Sector size: 4096 bytes Logical Sector-0 offset: 0 bytes device size with M = 1024*1024: 3815447 MBytes device size with M = 1000*1000: 4000787 MBytes (4000 GB) cache/buffer size = unknown Form Factor: 3.5 inch Nominal Media Rotation Rate: 5900 Capabilities: Interestingly, fdisk shows 976754646 logical sectors of size 4096 bytes while hdparm reports 7814037168 sectors of 512 bytes. But when showing the HPA of that disk I get # hdparm -N /dev/sdc /dev/sdc: max sectors = 7814037168/7801454256(18446744072933654192?), HPA setting seems invalid The native max address is 12582912 sectors (exactly 6 GiB) smaller than the end of the accessible disk, i.e beginning of HPA. Nevertheless, I can dd up to the end of the disk without any problem. So what is wrong with this disk? Steve
Re: hdparm reporting a different serial number
On 20/09/17 14:53, Bhasker C V wrote: Hi all, I have a seagate backup plus 5TB. When I plug-in the hdd, I see the serial number (as printed in the back of the HDD) in dmesg. usb 2-1.1: SerialNumber: [5.244161] usbcore: registered new interface driver usb-storage [5.245790] scsi host6: uas [5.246015] usbcore: registered new interface driver uas [5.247071] scsi 6:0:0:0: Direct-Access Seagate BUP BK 0108 PQ: 0 ANSI: 6 [5.285452] sd 6:0:0:0: [sda] 9767541167 512-byte logical blocks: (5.00 TB/4.55 TiB) [5.285458] sd 6:0:0:0: [sda] 4096-byte physical blocks [5.285786] sd 6:0:0:0: [sda] Write Protect is off [5.285790] sd 6:0:0:0: [sda] Mode Sense: 53 00 00 08 This serial number is correct ! (Actuial serial number is obfuscated) Whereas, when I do a hdparm or smartctl -i , I get a different serial number. ATA device, with non-removable media Model Number: ST5000LM000-2AN170 Serial Number: YYY Firmware Revision: 0001 Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, (actual serial number obfuscated) Can someone explain why please ? When I use seagate seatools, it reports both the USB-STORAGE and also the internal HDD with the same serial number (on windows). Your USB hard drive consists of a USB to SATA bridge and a SATA HDD. My guess is that the kernel reports (via dmesg/journalctl) the USB iSerial of the bridge as "SerialNumber" and hdparm reports the SATA serial number of the HDD. Kind regards, -- Ben Caradoc-Davies <b...@transient.nz> Director Transient Software Limited <http://transient.nz/> New Zealand
hdparm reporting a different serial number
Hi all, I have a seagate backup plus 5TB. When I plug-in the hdd, I see the serial number (as printed in the back of the HDD) in dmesg. usb 2-1.1: SerialNumber: [5.244161] usbcore: registered new interface driver usb-storage [5.245790] scsi host6: uas [5.246015] usbcore: registered new interface driver uas [5.247071] scsi 6:0:0:0: Direct-Access Seagate BUP BK 0108 PQ: 0 ANSI: 6 [5.285452] sd 6:0:0:0: [sda] 9767541167 512-byte logical blocks: (5.00 TB/4.55 TiB) [5.285458] sd 6:0:0:0: [sda] 4096-byte physical blocks [5.285786] sd 6:0:0:0: [sda] Write Protect is off [5.285790] sd 6:0:0:0: [sda] Mode Sense: 53 00 00 08 This serial number is correct ! (Actuial serial number is obfuscated) Whereas, when I do a hdparm or smartctl -i , I get a different serial number. ATA device, with non-removable media Model Number: ST5000LM000-2AN170 Serial Number: YYY Firmware Revision: 0001 Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, (actual serial number obfuscated) Can someone explain why please ? When I use seagate seatools, it reports both the USB-STORAGE and also the internal HDD with the same serial number (on windows). Regards Bhasker C V
[stretch] hdparm -B et sortie de veille
Bonjour, J'ai un portable avec 2 disques: un principal et un autre qui ne fonctionne que rarement. J'avais donc décidé de régler le second avec hdparm -B 1afin qu'il soit coupé au maximum. Pour ce faire j'ai 2 scripts dans /etc/pm/power.d et /etc/pm/sleep.d (script en pj). Jusqu'à maintenant ça fonctionnait mais aujourd'hui je m'aperçois qu'en sortie de veille la valeur est à 128 au lieu de 1. Auriez-vous une idée de la cause ? Gaëtan 50-hdparm_pm Description: application/shellscript 50-hdparm_pm Description: application/shellscript signature.asc Description: This is a digitally signed message part
Re: Does hdparm not run at startup anymore?
On 11/12/2016 09:14 PM, Rainer Dorsch wrote:
> Hi Alex,
>
> thank you for your reply and your testing.
>
> On Saturday 12 November 2016 16:40:40 Alex Mestiashvili wrote:
>> On 11/12/2016 08:37 AM, Rainer Dorsch wrote:
>>> + Alexandre, hdparm maintainer
>>>
>>> On Friday 11 November 2016 23:11:24 Rainer Dorsch wrote:
>>>> Hi,
>>>>
>>>> I configure sdb in /etc/hdparm.conf to apm=64, but when I start the
>>>> system, apm does not change. Interesting enough a /etc/init.d/hdparm
>>>> restart fixes the problem:
>>>>
>>>>
>>>> root@Silberkiste:~# cat /etc/hdparm.conf
>>
>>>> /dev/sdb {
>>>> apm = 64
>>>> spindown_time = 5
>>>> }
>>>>
>>>> root@Silberkiste:~# hdparm -I /dev/sdb|grep level
>>>> Advanced power management level: 254
>>>> root@Silberkiste:~# /etc/init.d/hdparm restart
>>>> [ ok ] Restarting hdparm (via systemctl): hdparm.service.
>>>> root@Silberkiste:~# hdparm -I /dev/sdb|grep level
>>>> Advanced power management level: 64
>>>> root@Silberkiste:~#
>>>>
>>>>
>>>> Any insight, why I need the /etc/init.d/hdparm restart is very welcome.
>>>>
>>>> Thanks
>>>> Rainer
>>>>
>>>>
>> Hi Rainer,
>> I can not reproduce this problem on my machine:
>>
>> lsb_release -c
>> Codename:jessie
>>
>> hdparm -V
>> hdparm v9.43
>>
>> egrep -v "^$|^#" /etc/hdparm.conf
>> /dev/sdc {
>> apm = 64
>> acoustic_management = 250
>> }
>> /dev/sdd {
>> apm = 128
>> }
>> /dev/sdf {
>> apm = 48
>> }
>>
>>
>> for disk in sdc sdd sdf; do echo $disk; hdparm -I /dev/$disk | egrep
>> "level:|acoustic"; done
>> sdc
>> Advanced power management level: 64
>> Recommended acoustic management value: 254, current value: 250
>> sdd
>> Advanced power management level: disabled
>> Recommended acoustic management value: 128, current value: 128
>> sdf
>> Advanced power management level: 48
>> Recommended acoustic management value: 208, current value: 0
>>
>> The values are set after reboot or after init script restart.
>>
>
> Hmm...since hdparm works for me if I do a
>
> # /etc/init.d/hdparm restart
>
> after boot (or even in /etc/rc.local, is it possible that hdparm runs for my
> system for whatever reason too early (though it is not special setup, all
> SATA SSDs and HDDs)?
>
> Rainer
>
>
Hi Rainer,
you can try to tweak the init script to see what is really happening,
for example by echoing more information or redirecting the command
outputs to a logfile.
Alternatively you can give hdparm link a higher Start number in
/etc/rc3.d/ to see if it helps.
Best,
Alex
Re: Does hdparm not run at startup anymore?
On 11/12/16, Rainer Dorsch <m...@bokomoko.de> wrote: > > On Saturday 12 November 2016 16:40:40 Alex Mestiashvili wrote: >> On 11/12/2016 08:37 AM, Rainer Dorsch wrote: >> > + Alexandre, hdparm maintainer >> > >> > On Friday 11 November 2016 23:11:24 Rainer Dorsch wrote: >> >> Hi, >> >> >> >> I configure sdb in /etc/hdparm.conf to apm=64, but when I start the >> >> system, apm does not change. Interesting enough a /etc/init.d/hdparm >> >> restart fixes the problem: >> >> >> >> < snipped for brevity > >> >> root@Silberkiste:~# hdparm -I /dev/sdb|grep level >> >> Advanced power management level: 254 >> >> root@Silberkiste:~# /etc/init.d/hdparm restart >> >> [ ok ] Restarting hdparm (via systemctl): hdparm.service. >> >> root@Silberkiste:~# hdparm -I /dev/sdb|grep level >> >> Advanced power management level: 64 >> >> root@Silberkiste:~# >> >> >> >> >> >> Any insight, why I need the /etc/init.d/hdparm restart is very >> >> welcome. >> >> >> >> >> Hi Rainer, >> I can not reproduce this problem on my machine: >> >> lsb_release -c >> Codename:jessie >> >> hdparm -V >> hdparm v9.43 >> >> < snipped for brevity > > > Hmm...since hdparm works for me if I do a > > # /etc/init.d/hdparm restart > > after boot (or even in /etc/rc.local, is it possible that hdparm runs for my > system for whatever reason too early (though it is not special setup, all > SATA SSDs and HDDs)? Hi.. Have CC'd those recently brought into the loop (because it seemed the proper thing to do).. What I'm sharing is "similarly different". It's only one of the problems I'm having with (STILL) attempting to get wireless/Bluetooth to function, but this thread right here is one of the things I'm facing, too. It's been a few days since I... attempted it so I've forgotten which [package] this worked for, but one function that WAS working needed a manual restart after reboots. Whichever [package] it was, that package would be "failed" (or similar error) for a "systemctl status" command issuance. It would then function fine (based on systemctl status query feedback) after a "systemctl restart" terminal command line restart. Again, this was all immediately after a fresh reboot where things become reset. Been a couple threads recently where my instance seemed to potentially apply, as well, actually. Like maybe it's hinting at something more universal involved beyond singular packages. I'm on Sid Unstable (attempting a Stretch debootstrap in just a few). Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * Ya gotta find your crochet-t-t-t-t!!! *
Re: Does hdparm not run at startup anymore?
On Fri, Nov 11, 2016 at 11:11:24PM +0100, Rainer Dorsch wrote: > I configure sdb in /etc/hdparm.conf to apm=64, but when I start the system, > apm > does not change. Interesting enough a /etc/init.d/hdparm restart fixes the > problem: There are two config options available: "apm" and "apm_battery". Which one takes effect depends on your machine's power status: connected to external power or running on battery. Does this help you? If not, please run these commands as root and show us their output: find /etc/rc* \( -name "*hdparm" -o -lname "*hdparm" \) -ls ls -l /sbin/init systemctl status hdparm Regards Mirko
Re: Does hdparm not run at startup anymore?
Hi Alex,
thank you for your reply and your testing.
On Saturday 12 November 2016 16:40:40 Alex Mestiashvili wrote:
> On 11/12/2016 08:37 AM, Rainer Dorsch wrote:
> > + Alexandre, hdparm maintainer
> >
> > On Friday 11 November 2016 23:11:24 Rainer Dorsch wrote:
> >> Hi,
> >>
> >> I configure sdb in /etc/hdparm.conf to apm=64, but when I start the
> >> system, apm does not change. Interesting enough a /etc/init.d/hdparm
> >> restart fixes the problem:
> >>
> >>
> >> root@Silberkiste:~# cat /etc/hdparm.conf
>
> >> /dev/sdb {
> >> apm = 64
> >> spindown_time = 5
> >> }
> >>
> >> root@Silberkiste:~# hdparm -I /dev/sdb|grep level
> >> Advanced power management level: 254
> >> root@Silberkiste:~# /etc/init.d/hdparm restart
> >> [ ok ] Restarting hdparm (via systemctl): hdparm.service.
> >> root@Silberkiste:~# hdparm -I /dev/sdb|grep level
> >> Advanced power management level: 64
> >> root@Silberkiste:~#
> >>
> >>
> >> Any insight, why I need the /etc/init.d/hdparm restart is very welcome.
> >>
> >> Thanks
> >> Rainer
> >>
> >>
> Hi Rainer,
> I can not reproduce this problem on my machine:
>
> lsb_release -c
> Codename:jessie
>
> hdparm -V
> hdparm v9.43
>
> egrep -v "^$|^#" /etc/hdparm.conf
> /dev/sdc {
> apm = 64
> acoustic_management = 250
> }
> /dev/sdd {
> apm = 128
> }
> /dev/sdf {
> apm = 48
> }
>
>
> for disk in sdc sdd sdf; do echo $disk; hdparm -I /dev/$disk | egrep
> "level:|acoustic"; done
> sdc
> Advanced power management level: 64
> Recommended acoustic management value: 254, current value: 250
> sdd
> Advanced power management level: disabled
> Recommended acoustic management value: 128, current value: 128
> sdf
> Advanced power management level: 48
> Recommended acoustic management value: 208, current value: 0
>
> The values are set after reboot or after init script restart.
>
Hmm...since hdparm works for me if I do a
# /etc/init.d/hdparm restart
after boot (or even in /etc/rc.local, is it possible that hdparm runs for my
system for whatever reason too early (though it is not special setup, all SATA
SSDs and HDDs)?
Rainer
--
Rainer Dorsch
http://bokomoko.de/
Re: Does hdparm not run at startup anymore?
On 11/12/2016 08:37 AM, Rainer Dorsch wrote:
> + Alexandre, hdparm maintainer
>
> On Friday 11 November 2016 23:11:24 Rainer Dorsch wrote:
>> Hi,
>>
>> I configure sdb in /etc/hdparm.conf to apm=64, but when I start the system,
>> apm does not change. Interesting enough a /etc/init.d/hdparm restart fixes
>> the problem:
>>
>>
>> root@Silberkiste:~# cat /etc/hdparm.conf
>> /dev/sdb {
>> apm = 64
>> spindown_time = 5
>> }
>>
>> root@Silberkiste:~# hdparm -I /dev/sdb|grep level
>> Advanced power management level: 254
>> root@Silberkiste:~# /etc/init.d/hdparm restart
>> [ ok ] Restarting hdparm (via systemctl): hdparm.service.
>> root@Silberkiste:~# hdparm -I /dev/sdb|grep level
>> Advanced power management level: 64
>> root@Silberkiste:~#
>>
>>
>> Any insight, why I need the /etc/init.d/hdparm restart is very welcome.
>>
>> Thanks
>> Rainer
>>
>>
Hi Rainer,
I can not reproduce this problem on my machine:
lsb_release -c
Codename:jessie
hdparm -V
hdparm v9.43
egrep -v "^$|^#" /etc/hdparm.conf
/dev/sdc {
apm = 64
acoustic_management = 250
}
/dev/sdd {
apm = 128
}
/dev/sdf {
apm = 48
}
for disk in sdc sdd sdf; do echo $disk; hdparm -I /dev/$disk | egrep
"level:|acoustic"; done
sdc
Advanced power management level: 64
Recommended acoustic management value: 254, current value: 250
sdd
Advanced power management level: disabled
Recommended acoustic management value: 128, current value: 128
sdf
Advanced power management level: 48
Recommended acoustic management value: 208, current value: 0
The values are set after reboot or after init script restart.
Best,
Alex
Re: Does hdparm not run at startup anymore?
+ Alexandre, hdparm maintainer
On Friday 11 November 2016 23:11:24 Rainer Dorsch wrote:
> Hi,
>
> I configure sdb in /etc/hdparm.conf to apm=64, but when I start the system,
> apm does not change. Interesting enough a /etc/init.d/hdparm restart fixes
> the problem:
>
>
> root@Silberkiste:~# cat /etc/hdparm.conf
> ## This is the default configuration for hdparm for Debian. It is a
> ## rather simple script, so please follow the following guidelines :)
> ## Any line that begins with a comment is ignored - add as many as you
> ## like. Note that an in-line comment is not supported. If a line
> ## consists of whitespace only (tabs, spaces, carriage return), it will be
> ## ignored, so you can space control fields as you like. ANYTHING ELSE
> ## IS PARSED!! This means that lines with stray characters or lines that
> ## use non # comment characters will be interpreted by the initscript.
> ## This has probably minor, but potentially serious, side effects for your
> ## hard drives, so please follow the guidelines. Patches to improve
> ## flexibilty welcome. Please read /usr/share/doc/hdparm/README.Debian for
> ## notes about known issues, especially if you have an MD array.
> ##
> ## Note that if the init script causes boot problems, you can pass 'nohdparm'
> ## on the kernel command line, and the script will not be run.
> ##
> ## Uncommenting the options below will cause them to be added to the DEFAULT
> ## string which is prepended to options listed in the blocks below.
> ##
> ## If an option is listed twice, the second instance replaces the first.
> ##
> ## /sbin/hdparm is not run unless a block of the form:
> ## DEV {
> ## option
> ## option
> ## ...
> ## }
> ## exists. This blocks will cause /sbin/hdparm OPTIONS DEV to be run.
> ## Where OPTIONS is the concatenation of all options previously defined
> ## outside of a block and all options defined with in the block.
>
> # -q be quiet
> quiet
> # -a sector count for filesystem read-ahead
> #read_ahead_sect = 12
> # -A disable/enable the IDE drive's read-lookahead feature
> #lookahead = on
> # -b bus state
> #bus = on
> # -B apm setting
> #apm = 255
> # -B apm setting when on battery
> #apm_battery = 127
> # -c enable (E)IDE 32-bit I/O support - can be any of 0,1,3
> #io32_support = 1
> # -d disable/enable the "using_dma" flag for this drive
> #dma = off
> # -D enable/disable the on-drive defect management
> #defect_mana = off
> # -E cdrom speed
> #cd_speed = 16
> # -k disable/enable the "keep_settings_over_reset" flag for this drive
> #keep_settings_over_reset = off
> # -K disable/enable the drive's "keep_features_over_reset" flag
> #keep_features_over_reset = on
> # -m sector count for multiple sector I/O
> #mult_sect_io = 32
> # -P maximum sector count for the drive's internal prefetch mechanism
> #prefetch_sect = 12
> # -r read-only flag for device
> #read_only = off
> # -s Turn on/off power on in standby mode
> # poweron_standby = off
> # -S standby (spindown) timeout for the drive
> #spindown_time = 24
> # -u interrupt-unmask flag for the drive
> #interrupt_unmask = on
> # -W Disable/enable the IDE drive's write-caching feature
> #write_cache = off
> # -X IDE transfer mode for newer (E)IDE/ATA2 drives
> #transfer_mode = 34
> # -y force to immediately enter the standby mode
> #standby
> # -Y force to immediately enter the sleep mode
> #sleep
> # -Z Disable the power-saving function of certain Seagate drives
> #disable_seagate
> # -M Set the acoustic management properties of a drive
> #acoustic_management
> # -p Set the chipset PIO mode
> # chipset_pio_mode
> # --security-freeze Freeze the drive's security status
> # security_freeze
> # --security-unlock Unlock the drive's security
> # security_unlock = PWD
> # --security-set-pass Set security password
> # security_pass = password
> # --security-disable Disable drive locking
> # security_disable
> # --user-master Select password to use
> # user-master = u
> # --security-mode Set the security mode
> # security_mode = h
>
> # Root file systems. Please see README.Debian for details
> # ROOTFS = /dev/hda
>
> ## New note - you can use straight hdparm commands in this config file
> ## as well - the set up is ugly, but it keeps backwards compatibility
> ## Additionally, it should be noted that any blocks that begin with
> ## the keyword 'command_line' are not run until after the root filesystem
> ## is mounted. This is done to avoid running blocks twice. If you need
> ## to run hdparm to set parameters for your root disk, please use the
> ## standard format.
>
> #Samples follow:
&
Does hdparm not run at startup anymore?
Hi,
I configure sdb in /etc/hdparm.conf to apm=64, but when I start the system, apm
does not change. Interesting enough a /etc/init.d/hdparm restart fixes the
problem:
root@Silberkiste:~# cat /etc/hdparm.conf
## This is the default configuration for hdparm for Debian. It is a
## rather simple script, so please follow the following guidelines :)
## Any line that begins with a comment is ignored - add as many as you
## like. Note that an in-line comment is not supported. If a line
## consists of whitespace only (tabs, spaces, carriage return), it will be
## ignored, so you can space control fields as you like. ANYTHING ELSE
## IS PARSED!! This means that lines with stray characters or lines that
## use non # comment characters will be interpreted by the initscript.
## This has probably minor, but potentially serious, side effects for your
## hard drives, so please follow the guidelines. Patches to improve
## flexibilty welcome. Please read /usr/share/doc/hdparm/README.Debian for
## notes about known issues, especially if you have an MD array.
##
## Note that if the init script causes boot problems, you can pass 'nohdparm'
## on the kernel command line, and the script will not be run.
##
## Uncommenting the options below will cause them to be added to the DEFAULT
## string which is prepended to options listed in the blocks below.
##
## If an option is listed twice, the second instance replaces the first.
##
## /sbin/hdparm is not run unless a block of the form:
## DEV {
## option
## option
## ...
## }
## exists. This blocks will cause /sbin/hdparm OPTIONS DEV to be run.
## Where OPTIONS is the concatenation of all options previously defined
## outside of a block and all options defined with in the block.
# -q be quiet
quiet
# -a sector count for filesystem read-ahead
#read_ahead_sect = 12
# -A disable/enable the IDE drive's read-lookahead feature
#lookahead = on
# -b bus state
#bus = on
# -B apm setting
#apm = 255
# -B apm setting when on battery
#apm_battery = 127
# -c enable (E)IDE 32-bit I/O support - can be any of 0,1,3
#io32_support = 1
# -d disable/enable the "using_dma" flag for this drive
#dma = off
# -D enable/disable the on-drive defect management
#defect_mana = off
# -E cdrom speed
#cd_speed = 16
# -k disable/enable the "keep_settings_over_reset" flag for this drive
#keep_settings_over_reset = off
# -K disable/enable the drive's "keep_features_over_reset" flag
#keep_features_over_reset = on
# -m sector count for multiple sector I/O
#mult_sect_io = 32
# -P maximum sector count for the drive's internal prefetch mechanism
#prefetch_sect = 12
# -r read-only flag for device
#read_only = off
# -s Turn on/off power on in standby mode
# poweron_standby = off
# -S standby (spindown) timeout for the drive
#spindown_time = 24
# -u interrupt-unmask flag for the drive
#interrupt_unmask = on
# -W Disable/enable the IDE drive's write-caching feature
#write_cache = off
# -X IDE transfer mode for newer (E)IDE/ATA2 drives
#transfer_mode = 34
# -y force to immediately enter the standby mode
#standby
# -Y force to immediately enter the sleep mode
#sleep
# -Z Disable the power-saving function of certain Seagate drives
#disable_seagate
# -M Set the acoustic management properties of a drive
#acoustic_management
# -p Set the chipset PIO mode
# chipset_pio_mode
# --security-freeze Freeze the drive's security status
# security_freeze
# --security-unlock Unlock the drive's security
# security_unlock = PWD
# --security-set-pass Set security password
# security_pass = password
# --security-disable Disable drive locking
# security_disable
# --user-master Select password to use
# user-master = u
# --security-mode Set the security mode
# security_mode = h
# Root file systems. Please see README.Debian for details
# ROOTFS = /dev/hda
## New note - you can use straight hdparm commands in this config file
## as well - the set up is ugly, but it keeps backwards compatibility
## Additionally, it should be noted that any blocks that begin with
## the keyword 'command_line' are not run until after the root filesystem
## is mounted. This is done to avoid running blocks twice. If you need
## to run hdparm to set parameters for your root disk, please use the
## standard format.
#Samples follow:
#First three are good for devfs systems, fourth one for systems that do
#not use devfs. The fifth example uses straight hdparm command line
#syntax. Any of the blocks that use command line syntax must begin with
#the keyword 'command_line', and no attempt is made to validate syntax.
#It is provided for those more comfortable with hdparm syntax.
#/dev/discs/disc0/disc {
# mult_sect_io = 16
# write_cache = off
# spindown_time = 240
#}
#/dev/discs/disc1/disc {
# mult_sect_io = 32
# spindown_time = 36
# write_cache = off
#}
#/dev/cdroms/cdrom0 {
# dma = on
# interrupt_unmask
hdparm consulta
hola, buenas lista hace un corto tiempo atras lei (no recuerdo si en este foro) que los discos SSD no se pueden borrar completamente, es decir, no se puede hacer un borrado seguro. mas alla de eso, hoy leyendo este articulo (0) me encuentro con un parametro que me genera dudas y es el siguiente hdparm -I /dev/sda me da como resultado (entre otros) Security: Master password revision code = 65534 supported notenabled notlocked frozen notexpired: security count supported: enhanced erase 104min for SECURITY ERASE UNIT. 106min for ENHANCED SECURITY ERASE UNIT. o sea, puedo borrar de forma segura un disco mediante hdparm, lo cual seria algo asi como hdparm --user-master u --security-erase Eins /dev/sdb security_password=Eins esto es asi? alguien me puede corroborar? la verdad aun estoy releyendo y buscando mas para enteder mejor el concepto: entre otras dudas que me surgen son; a.- si cambio la contraseña que parece ser por defecto Master password revision code = 65534 por otra a mi gusto, se mantendra? o sera de un solo uso. b.- el borrado es como un shred (por dar un ejemplo) o secure delete? c.- hay otras mas pero seguire leyendo. (0) https://www.thomas-krenn.com/en/wiki/SSD_Secure_Erase saludos -- Windows? Reboot Debian? beRoot -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+0kpa3zKF0vomZy2sApj0OZCi6B2iwci+=bWdU=tldqjzq...@mail.gmail.com
Re: hdparm consulta
El día 25 de julio de 2015, 10:59, Camaleón noela...@gmail.com escribió: El Sat, 25 Jul 2015 10:40:01 -0300, Ricardo Delgado escribió: hace un corto tiempo atras lei (no recuerdo si en este foro) que los discos SSD no se pueden borrar completamente, es decir, no se puede hacer un borrado seguro. Ni los SSD ni los mecánicos (el borrado seguro al 100% no existe), pero vamos, se puede intentar que quede lo más vacío posible. mas alla de eso, hoy leyendo este articulo (0) me encuentro con un parametro que me genera dudas y es el siguiente hdparm -I /dev/sda me da como resultado (entre otros) Security: Master password revision code = 65534 supported notenabled notlocked frozen notexpired: security count supported: enhanced erase 104min for SECURITY ERASE UNIT. 106min for ENHANCED SECURITY ERASE UNIT. o sea, puedo borrar de forma segura un disco mediante hdparm, lo cual seria algo asi como hdparm --user-master u --security-erase Eins /dev/sdb security_password=Eins esto es asi? alguien me puede corroborar? Pues es lo que dice la guía para definir una contraseña, paso previo al borrado. El borrado de datos es el paso 3. OJO. Según la salida del comando que envías más arriba *NO tienes activado* el uso de contraseña. la verdad aun estoy releyendo y buscando mas para enteder mejor el concepto: entre otras dudas que me surgen son; a.- si cambio la contraseña que parece ser por defecto Master password revision code = 65534 No, no... eso no es la contraseña, es sólo el código de revisión de la función. por otra a mi gusto, se mantendra? o sera de un solo uso. Si lees el artículo completo, verás que dice que tras realizar todos los pasos que detalla la contraseña queda desactivada pero entiendo que se podrá habilitar esa funcionalidad después, con una contraseña de libre elección. b.- el borrado es como un shred (por dar un ejemplo) o secure delete? Pues dependerá de cómo haya definido en el firmware esa función el fabricante del disco duro. El artículo habla de algunos modelos de discos Intel, no sé si será aplicable para todos. c.- hay otras mas pero seguire leyendo. (0) https://www.thomas-krenn.com/en/wiki/SSD_Secure_Erase Si no estás seguro de lo que vas a hacer (es lo que parece) no lo hagas a menos que tengas un backup completo de todos los datos. El documento original: https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.07.25.13.59...@gmail.com gracias por responder, no pienso hacer nada aun, simplemente estoy leyendo documentacion, y si con respecto a la contraseña que no esta habilitada lo se, queria corroborar y mas que nada escuchar (leer) comentarios de alguien que haya hecho lo que reza el articulo y sus experiencias. lo de borrado seguro se que no es tal, pero se puede hacer que sea dificil recuperar datos. -- Windows? Reboot Debian? beRoot -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ca+0kpa1rujy5d5kp71wf5qgggqyfiza5ns6ybcc-adx0pvp...@mail.gmail.com
Re: hdparm consulta
El sábado, 25 jul 2015, a las 15:40 UTC+2 horas, Ricardo Delgado escribió: hace un corto tiempo atras lei (no recuerdo si en este foro) que los discos SSD no se pueden borrar completamente, es decir, no se puede hacer un borrado seguro. Esto es nuevo para mí. Siempre he creído que eran los únicos que permitían borrado seguro a costa de degradar su periodo de vida útil. En los magnéticos siempre queda un campo magnético remanente que permite reconstruir la información borrada. ¿Cuál se supone que es el mecanismo que permite rescatarla en los de estado sólido? Saludos. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150725170533.0f267...@gmail.com
Re: hdparm consulta
El Sat, 25 Jul 2015 10:40:01 -0300, Ricardo Delgado escribió: hace un corto tiempo atras lei (no recuerdo si en este foro) que los discos SSD no se pueden borrar completamente, es decir, no se puede hacer un borrado seguro. Ni los SSD ni los mecánicos (el borrado seguro al 100% no existe), pero vamos, se puede intentar que quede lo más vacío posible. mas alla de eso, hoy leyendo este articulo (0) me encuentro con un parametro que me genera dudas y es el siguiente hdparm -I /dev/sda me da como resultado (entre otros) Security: Master password revision code = 65534 supported notenabled notlocked frozen notexpired: security count supported: enhanced erase 104min for SECURITY ERASE UNIT. 106min for ENHANCED SECURITY ERASE UNIT. o sea, puedo borrar de forma segura un disco mediante hdparm, lo cual seria algo asi como hdparm --user-master u --security-erase Eins /dev/sdb security_password=Eins esto es asi? alguien me puede corroborar? Pues es lo que dice la guía para definir una contraseña, paso previo al borrado. El borrado de datos es el paso 3. OJO. Según la salida del comando que envías más arriba *NO tienes activado* el uso de contraseña. la verdad aun estoy releyendo y buscando mas para enteder mejor el concepto: entre otras dudas que me surgen son; a.- si cambio la contraseña que parece ser por defecto Master password revision code = 65534 No, no... eso no es la contraseña, es sólo el código de revisión de la función. por otra a mi gusto, se mantendra? o sera de un solo uso. Si lees el artículo completo, verás que dice que tras realizar todos los pasos que detalla la contraseña queda desactivada pero entiendo que se podrá habilitar esa funcionalidad después, con una contraseña de libre elección. b.- el borrado es como un shred (por dar un ejemplo) o secure delete? Pues dependerá de cómo haya definido en el firmware esa función el fabricante del disco duro. El artículo habla de algunos modelos de discos Intel, no sé si será aplicable para todos. c.- hay otras mas pero seguire leyendo. (0) https://www.thomas-krenn.com/en/wiki/SSD_Secure_Erase Si no estás seguro de lo que vas a hacer (es lo que parece) no lo hagas a menos que tengas un backup completo de todos los datos. El documento original: https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.07.25.13.59...@gmail.com
Re: hdparm consulta
hace un corto tiempo atras lei (no recuerdo si en este foro) que los discos SSD no se pueden borrar completamente, es decir, no se puede hacer un borrado seguro. Esto es nuevo para mí. Siempre he creído que eran los únicos que permitían borrado seguro a costa de degradar su periodo de vida útil. En los magnéticos siempre queda un campo magnético remanente que permite reconstruir la información borrada. ¿Cuál se supone que es el mecanismo que permite rescatarla en los de estado sólido? es precisamente lo que me hizo buscar info al respecto, lamentablemente no pude encontrar el link donde vi esa noticia. quizas lei un FUD. pero bueno mas alla de eso, no invalida lo del hdparm y la consulta realizada. saludos -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ca+0kpa0i+khz00nszfbq_zmyj0sbmo32eeqvcs6qpovhazq...@mail.gmail.com
Re: hdparm consulta
El Sábado, 25 de julio de 2015 13:59:08 Camaleón escribió: El Sat, 25 Jul 2015 10:40:01 -0300, Ricardo Delgado escribió: hace un corto tiempo atras lei (no recuerdo si en este foro) que los discos SSD no se pueden borrar completamente, es decir, no se puede hacer un borrado seguro. Ni los SSD ni los mecánicos (el borrado seguro al 100% no existe), pero vamos, se puede intentar que quede lo más vacío posible. Lo único que yo creo que es factible hacer, no es borrar sin mas, es usar la denegación de acceso. Encriptar el disco después de escribir y reescribir gran cantidad de veces 0 y 1 -- Agur bero bat / a greeting BasaBuru BASATU ~ basatia bihur zaitez ~ gako ID gnupg: F9044F8FC64B2544 hatz-aztarna: 13FF 7B28 D999 B957 F837 D566 F904 4F8F C64B 2544 signature.asc Description: This is a digitally signed message part.
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
I did get to test the 3.15 kernel over the weekend. There' definitely some improvement. as hdparm -t now reports 25-30MB/s for my hard drive instead of 6-7MB/s. The stutter in audio playback is less pronounced and almost unnoticeable. At this point the dn2800mt board is largely useable with hyperthreading enabled. I'll delve more deeply into this as time allows. On 5/14/2014 4:05 PM, Henrique de Moraes Holschuh wrote: On Wed, 14 May 2014, Paul Ausbeck wrote: While examining the kernel log for another reason, I came across evidence that acpi_idle, and not intel_idle, is being used on my dn2800mt system, see below. In fact, it seems that intel_idle cannot be used. Is there some sort of binary blob involved here? Well, I just did a quick hunting for when support was added... commit acead1b0fac5b10d0ae3f1cc5f7820b9f9f924f5 Author: Jan Kiszka jan.kis...@siemens.com Date: Sat Jan 25 22:24:22 2014 +0100 intel_idle: Add CPU model 54 (Atom N2000 series) Add CPU ID for Atom N2600/N2800 processors. Datasheets indicate support for this, detailed information about potential quirks or limitations are missing, though. So we just reuse the definition for the previous ATOM series. Tests on N2800 systems showed that this addition is fine an can reduce power consumption by about 0.25 W (personally confirmed on Intel DN2800MT). Signed-off-by: Jan Kiszka jan.kis...@siemens.com Signed-off-by: Len Brown len.br...@intel.com The bad news is that this commit is present only on kernel 3.15-rc. It should be trivial to backport it to older kernels (it really just adds a single line to the table of supported processors), but I didn't check if the atom code in intel-idle received any fixes lately. It might be worthwhile to test it, or to test the latest development 3.15 kernel (get it directly from Linus' git tree). If you're going to test 3.15, do be aware that there's always increased risk of issues when testing a non-released kernel, so the risks and the procedures I gave you for safe testing of bissected kernels DO apply. BTW, it is actually weird that acpi-idle would malfunction _or_ interact badly with firmware, as it usually the more tested and stable idle driver since it operates more closely to that other OS does than intel-idle :-) Hmm, come to think of it, here's something you can try: http://biosbits.org/ It is an official Intel testsuite for the BIOS/EFI. And I *believe* you can actually get it to boot Debian with replacement firmware it provides (my best guess is that it overrides acpi tables and reprograms the processor and chipset). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/538376be.3040...@alumni.cse.ucsc.edu
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
Curiouser and curiouser. I have a second dn2800mt machine that my girlfriend uses. I ran some tests while there and I'm more uncertain than ever about what is going on. First, hdparm does not report correctly with hyperthreading enabled just as with the original machine. However, the problem is limited to the winchester drive, 3 - 7 MB/s reported read speed, the USB flash drive reports correctly ~30MB/s read timings. Second, the problem shifts following a suspend/resume cycle. The winchester drive then reports ~150MB/s, but the USB flash drive reports ~20MB/s. Third, the hdparm numbers aren't super accurate (well for USB actually pretty accurate) but they correlate to actual read bandwidth. Immediately following boot, USB 680MB 21.5s, winchester 710MB 11.297s. Following suspend/resume, USB 680MB 26.058s, winchester 710MB 5.206s. Caches purged of course and these numbers are repeatable. Fourth, with hyperthreading disabled, hdparm and actual read speeds are as expected, USB 30+MB/s, winchester 120-150MB/s, always. Fifth, boot time to ethernet up with hyperthreading enabled, ~17s, disabled ~27s. Sixth, a CPU bound threading benchmark, sysbench, shows that hyperthreading is accomplishing something, with performance consistent across suspend/resume cycles. Therefore, I'm sort of leaning against a board specific problem and more toward a design specific problem. Also, this problem is tenuous enough to be present in other Intel products but heretofore unnoticed. All experiments with 3.12 kernel. On 5/14/2014 4:05 PM, Henrique de Moraes Holschuh wrote: On Wed, 14 May 2014, Paul Ausbeck wrote: While examining the kernel log for another reason, I came across evidence that acpi_idle, and not intel_idle, is being used on my dn2800mt system, see below. In fact, it seems that intel_idle cannot be used. Is there some sort of binary blob involved here? Well, I just did a quick hunting for when support was added... commit acead1b0fac5b10d0ae3f1cc5f7820b9f9f924f5 Author: Jan Kiszka jan.kis...@siemens.com Date: Sat Jan 25 22:24:22 2014 +0100 intel_idle: Add CPU model 54 (Atom N2000 series) Add CPU ID for Atom N2600/N2800 processors. Datasheets indicate support for this, detailed information about potential quirks or limitations are missing, though. So we just reuse the definition for the previous ATOM series. Tests on N2800 systems showed that this addition is fine an can reduce power consumption by about 0.25 W (personally confirmed on Intel DN2800MT). Signed-off-by: Jan Kiszka jan.kis...@siemens.com Signed-off-by: Len Brown len.br...@intel.com The bad news is that this commit is present only on kernel 3.15-rc. It should be trivial to backport it to older kernels (it really just adds a single line to the table of supported processors), but I didn't check if the atom code in intel-idle received any fixes lately. It might be worthwhile to test it, or to test the latest development 3.15 kernel (get it directly from Linus' git tree). If you're going to test 3.15, do be aware that there's always increased risk of issues when testing a non-released kernel, so the risks and the procedures I gave you for safe testing of bissected kernels DO apply. BTW, it is actually weird that acpi-idle would malfunction _or_ interact badly with firmware, as it usually the more tested and stable idle driver since it operates more closely to that other OS does than intel-idle :-) Hmm, come to think of it, here's something you can try: http://biosbits.org/ It is an official Intel testsuite for the BIOS/EFI. And I *believe* you can actually get it to boot Debian with replacement firmware it provides (my best guess is that it overrides acpi tables and reprograms the processor and chipset). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5375527f.8020...@alumni.cse.ucsc.edu
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
While examining the kernel log for another reason, I came across evidence that acpi_idle, and not intel_idle, is being used on my dn2800mt system, see below. In fact, it seems that intel_idle cannot be used. Is there some sort of binary blob involved here? ---demsg | grep idle-- [0.00] RCU dyntick-idle grace-period acceleration is enabled. [0.197859] cpuidle: using governor ladder [0.197869] cpuidle: using governor menu [1.707710] intel_idle: does not run on family 6 model 54 [5.118568] ACPI: acpi_idle registered with cpuidle -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5373b5bc.8000...@alumni.cse.ucsc.edu
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
On Wed, 14 May 2014, Paul Ausbeck wrote: While examining the kernel log for another reason, I came across evidence that acpi_idle, and not intel_idle, is being used on my dn2800mt system, see below. In fact, it seems that intel_idle cannot be used. Is there some sort of binary blob involved here? Well, I just did a quick hunting for when support was added... commit acead1b0fac5b10d0ae3f1cc5f7820b9f9f924f5 Author: Jan Kiszka jan.kis...@siemens.com Date: Sat Jan 25 22:24:22 2014 +0100 intel_idle: Add CPU model 54 (Atom N2000 series) Add CPU ID for Atom N2600/N2800 processors. Datasheets indicate support for this, detailed information about potential quirks or limitations are missing, though. So we just reuse the definition for the previous ATOM series. Tests on N2800 systems showed that this addition is fine an can reduce power consumption by about 0.25 W (personally confirmed on Intel DN2800MT). Signed-off-by: Jan Kiszka jan.kis...@siemens.com Signed-off-by: Len Brown len.br...@intel.com The bad news is that this commit is present only on kernel 3.15-rc. It should be trivial to backport it to older kernels (it really just adds a single line to the table of supported processors), but I didn't check if the atom code in intel-idle received any fixes lately. It might be worthwhile to test it, or to test the latest development 3.15 kernel (get it directly from Linus' git tree). If you're going to test 3.15, do be aware that there's always increased risk of issues when testing a non-released kernel, so the risks and the procedures I gave you for safe testing of bissected kernels DO apply. BTW, it is actually weird that acpi-idle would malfunction _or_ interact badly with firmware, as it usually the more tested and stable idle driver since it operates more closely to that other OS does than intel-idle :-) Hmm, come to think of it, here's something you can try: http://biosbits.org/ It is an official Intel testsuite for the BIOS/EFI. And I *believe* you can actually get it to boot Debian with replacement firmware it provides (my best guess is that it overrides acpi tables and reprograms the processor and chipset). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140514230506.ga26...@khazad-dum.debian.net
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
On Fri, 09 May 2014, Paul Ausbeck wrote: I've actually done dummy file reads and writes previously. Well actually just writes. And they go at full speed, no matter what hparm says. For example, your example, works at full speed: dd if=/dev/zero of=somefile bs=10M count=100 ; You have to call sync, otherwise you've measured the time to write to the buffer-cache... That said, try this: strace -o /tmp/strace.txt -ttt -T hdparm -t (rest of hdparm command). And check if the timings of the syscalls traced give you any insight on where things are going wrong. Compare HT enabled with HT disabled. but I wasn't able to find a way to purge the disk cache before I got sidetracked. Perhaps you know of a magic incantation for that? Yes. You can drop all caches if you issue, as root: sync ; echo 1 /proc/sys/vm/drop_caches According to https://www.kernel.org/doc/Documentation/sysctl/vm.txt drop_caches --- Writing to this will cause the kernel to drop clean caches, as well as reclaimable slab objects like dentries and inodes. Once dropped, their memory becomes free. To free pagecache: echo 1 /proc/sys/vm/drop_caches To free reclaimable slab objects (includes dentries and inodes): echo 2 /proc/sys/vm/drop_caches To free slab objects and pagecache: echo 3 /proc/sys/vm/drop_caches This is a non-destructive operation and will not free any dirty objects. To increase the number of objects freed by this operation, the user may run `sync' prior to writing to /proc/sys/vm/drop_caches. This will minimize the number of dirty objects on the system and create more candidates to be dropped. This file is not a means to control the growth of the various kernel caches (inodes, dentries, pagecache, etc...) These objects are automatically reclaimed by the kernel when memory is needed elsewhere on the system. Use of this file can cause performance problems. Since it discards cached objects, it may cost a significant amount of I/O and CPU to recreate the dropped objects, especially if they were under heavy use. Because of this, use outside of a testing or debugging environment is not recommended. You may see informational messages in your kernel log when this file is used: cat (1234): drop_caches: 3 These are informational only. They do not mean that anything is wrong with your system. To disable them, echo 4 (bit 3) into drop_caches. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140510214707.ga21...@khazad-dum.debian.net
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
On Thu, 08 May 2014, Paul Ausbeck wrote: Next, I don't agree that this hyperthreading problem reeks of a firmware issue. What it reeks of is a linux kernel issue. I'm not Well, it reeks of bad interaction of Linux and the firmware, which *usually* is caused by bad firmware when an Intel desktop motherboard is involved, and very often fixed by newer firmware. Next, both recommending a firmware update and asking for /proc/cpuinfo were red herrings reminiscent of a conversation with any modern corporate support department. I will state flatly, that *I* asked for cpuinfo because I wanted to know the as-seen-by-the-kernel processor topology, as it is very important for correct operation of the SMP/SMT-aware process scheduler. I also wanted to know the microcode revison level (available in cpuinfo) because Intel did something funny with microcode updates for your processor in the past and I wanted to know if you had a version earlier than version 0x106. that and starting anew with open source. Please give me at least token respect. It's just plain fact that Windows 7 gives one confidence that hyperthreading is functioning properly and linux doesn't Linux Linux interacts very differently with the ACPI and EFI firmware and the low-level hardware (including the processor itself, the interrupt controllers and the memory controllers, the PCIe bridges, the IOMMU...) when compared to Windows 7. Next, from just this one data point, my experience tells me that linux isn't exactly playing friendly with Intel hyperthreading. Given that Intel is not that interested in hyperthreading any more, A single datapoint is indeed not enough. Hyperthreading on Intel Core related microarchs works very well for most workloads, to the point that even the newest Xeon E3v3, E5v2 and E7v2 families have hyperthread-enabled cores on most of the processors. The same goes for most of the Core i5/i7 desktop parts. Intel seems to be still quite interested in HT. It is entirely possible that hyperthreading on Atom does not work nearly as well as in the Core/Xeon as far as I know -- I don't have direct experience with Atom processors -- but a quick google search tells me people usually find HT on Atom to be a performance advantage, though. Next, I don't get what I'm supposed to bisect. Every kernel I've tried, 3.2.0-4, 3.12-0, and 3.12.9 have obvious issues with hyperthreading. So it seems unlikely to me that any kernel would function properly. In order to bisect, the first step is to find a correct kernel. Perhaps someone could recommend one. Well, I misunderstood you. I thought there was at least ONE kernel that worked with HT enabled. Indeed, if there is no kernel that works well with HT on your board, bissection is impossible. Next, it's not the case that I was confused. hdparm is still a reliable canary for hyperthreading problems on the dn2800mt motherboard. See attached data below, kernel 3.2.0-4 only . When I agreed with you that hdparm is a very good way to reproduce the problem (canary). But since my hyperthreading issue has not been trivially resolved on this list, I'm sort of assured that I'm not missing that trivial something. If after a few more days I still don't have a trivial answer, I will file a kernel bug. One thing comes to mind. Try switching the low-level kernel idle-loop driver. There are at least two that should work with your processor: acpi_idle, and intel_idle. Usually, intel_idle will be prefered. Disable it (compile a kernel with just ACPI idle, or if it is a module, blacklist it). The acpi-idle driver does things a lot closer than what windows 7 does. Do keep an eye on processor temperature while doing this test. Other stuff that might show up clues on what is wrong by direct comparison between HT-enabled and HT-disabled: /proc/interrupts (interrupt routing and TLB flush behaviour). /var/log/dmesg output of lspci -vvv *as root*. Compare them in the HT-disabled and HT-enabled states. If it works on your processor, check whether powertop shows something remarkably different in the processor behaviour re. frequency and idle states when you run with HT enabled, and HT disabled. Do this with hdparm running, of course. Alternatively, try it using the turbostat utility you can find in the tools/power/x86/turbostat directory inside the kernel source tree (use the turbostat from 3.12 or 3.13 regardless of kernel version). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140509193036.ga24...@khazad-dum.debian.net
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
Henrique, thanks a lot for the detailed reply. I will look at the stuff that you suggested, if only to learn about what I don't know. FYI, the problem doesn't seem related to temperature to me. I'm not ruling it out, I'm just saying it doesn't have that feel. I look at it like this. hdparm says that disk bandwidth is much lower than it should be, but only when hyperthreading is enabled. But, the system doesn't appear to be THAT much more unresponsive when hyperthreading is enabled over when disabled. So I'm leaning toward the idea that hdparm's calculation is being spoofed somehow. We have bytes/time so either bytes is smaller, or time is larger than an accurate value. Likely, though, the two variables are somewhat conflated. Let's say that hdparm thinks its transferring bytes for '2' seconds, but in reality the system is blocking somewhere and the full '2' seconds is not actually being used. In order to explain the similar responsiveness in actual use, my first guess would be that whenever, say thread 'hdparm' is blocked, another thread, say 'anythingelse' is run instead. I will put this issue in the queue and will work consistently on it as a background task. Forensically, I think the first thing I'll verify is the Timex time between the visual appearance on the display of the various hdparm strings. It's hard to see how the system could be so fooled that watch time is off, but experience begets comfort. Lastly, the difference in boot times may not be due to the hyperthreading issue, at least directly. There are quite a few differences in the kernel log (errors, warnings) between the various versions. So I'll have to spend some time at some point to pin down what these log messages actually mean. On 5/9/2014 12:30 PM, Henrique de Moraes Holschuh wrote: On Thu, 08 May 2014, Paul Ausbeck wrote: Next, I don't agree that this hyperthreading problem reeks of a firmware issue. What it reeks of is a linux kernel issue. I'm not Well, it reeks of bad interaction of Linux and the firmware, which *usually* is caused by bad firmware when an Intel desktop motherboard is involved, and very often fixed by newer firmware. Next, both recommending a firmware update and asking for /proc/cpuinfo were red herrings reminiscent of a conversation with any modern corporate support department. I will state flatly, that *I* asked for cpuinfo because I wanted to know the as-seen-by-the-kernel processor topology, as it is very important for correct operation of the SMP/SMT-aware process scheduler. I also wanted to know the microcode revison level (available in cpuinfo) because Intel did something funny with microcode updates for your processor in the past and I wanted to know if you had a version earlier than version 0x106. that and starting anew with open source. Please give me at least token respect. It's just plain fact that Windows 7 gives one confidence that hyperthreading is functioning properly and linux doesn't Linux Linux interacts very differently with the ACPI and EFI firmware and the low-level hardware (including the processor itself, the interrupt controllers and the memory controllers, the PCIe bridges, the IOMMU...) when compared to Windows 7. Next, from just this one data point, my experience tells me that linux isn't exactly playing friendly with Intel hyperthreading. Given that Intel is not that interested in hyperthreading any more, A single datapoint is indeed not enough. Hyperthreading on Intel Core related microarchs works very well for most workloads, to the point that even the newest Xeon E3v3, E5v2 and E7v2 families have hyperthread-enabled cores on most of the processors. The same goes for most of the Core i5/i7 desktop parts. Intel seems to be still quite interested in HT. It is entirely possible that hyperthreading on Atom does not work nearly as well as in the Core/Xeon as far as I know -- I don't have direct experience with Atom processors -- but a quick google search tells me people usually find HT on Atom to be a performance advantage, though. Next, I don't get what I'm supposed to bisect. Every kernel I've tried, 3.2.0-4, 3.12-0, and 3.12.9 have obvious issues with hyperthreading. So it seems unlikely to me that any kernel would function properly. In order to bisect, the first step is to find a correct kernel. Perhaps someone could recommend one. Well, I misunderstood you. I thought there was at least ONE kernel that worked with HT enabled. Indeed, if there is no kernel that works well with HT on your board, bissection is impossible. Next, it's not the case that I was confused. hdparm is still a reliable canary for hyperthreading problems on the dn2800mt motherboard. See attached data below, kernel 3.2.0-4 only . When I agreed with you that hdparm is a very good way to reproduce the problem (canary). But since my hyperthreading issue has not been trivially resolved on this list, I'm sort of assured that I'm not missing that trivial
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
On Fri, 09 May 2014, Paul Ausbeck wrote: Henrique, thanks a lot for the detailed reply. I will look at the stuff that you suggested, if only to learn about what I don't know. FYI, the problem doesn't seem related to temperature to me. I'm not ruling it out, I'm just saying it doesn't have that feel. What I mean is that when you mess with the low-level idle loop driver, it is not impossible to get all cores and hardware threads of the CPU stuck at C0 state (i.e. running 100% of the time). This *shoudln't* happen, but still it is best that you are aware of the possibility that you might end up testing the cpu heatsink/cooler as well... But, the system doesn't appear to be THAT much more unresponsive when hyperthreading is enabled over when disabled. So I'm leaning toward the idea that hdparm's calculation is being spoofed somehow. Hmm, there's a way to test. Time how much wall-clock time it takes to write a large file to disk and sync (flush to disk) the result, preferably in single-user mode: sync; date ; dd if=/dev/zero of=somefile bs=10M count=100 ; sync; date That should do it (the above creates an 1GiB file). It will also test the scheduler, as that /dev/zero read does cause syscalls and switches to kernel context. BTW, the output of hdparm -T should not vary an order of magnitude. If it does and there is nothing obnoxious running in the background, you've got closer to the problem. I doubt it is something like this, though: your system would be sluggish as all heck... Lastly, the difference in boot times may not be due to the hyperthreading issue, at least directly. There are quite a few Indeed. However, when looking at the timings in the /var/log/dmesg comparison, remember the comparison is less for the timings, and more for everything else. Note that some reordering across boots, even of the same kernel, is perfectly normal. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140509215607.gd24...@khazad-dum.debian.net
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
I've actually done dummy file reads and writes previously. Well actually just writes. And they go at full speed, no matter what hparm says. For example, your example, works at full speed: dd if=/dev/zero of=somefile bs=10M count=100 ; I've tried the analogous read: dd of=/dev/null if=somefile bs=10M count=100 ; but I wasn't able to find a way to purge the disk cache before I got sidetracked. Perhaps you know of a magic incantation for that? Also, if you look at my data again, you'll see that hdparm -T is not affected by the hyperthreading state, it's only hdparm -t that's affected. On 5/9/2014 2:56 PM, Henrique de Moraes Holschuh wrote: On Fri, 09 May 2014, Paul Ausbeck wrote: Henrique, thanks a lot for the detailed reply. I will look at the stuff that you suggested, if only to learn about what I don't know. FYI, the problem doesn't seem related to temperature to me. I'm not ruling it out, I'm just saying it doesn't have that feel. What I mean is that when you mess with the low-level idle loop driver, it is not impossible to get all cores and hardware threads of the CPU stuck at C0 state (i.e. running 100% of the time). This *shoudln't* happen, but still it is best that you are aware of the possibility that you might end up testing the cpu heatsink/cooler as well... But, the system doesn't appear to be THAT much more unresponsive when hyperthreading is enabled over when disabled. So I'm leaning toward the idea that hdparm's calculation is being spoofed somehow. Hmm, there's a way to test. Time how much wall-clock time it takes to write a large file to disk and sync (flush to disk) the result, preferably in single-user mode: sync; date ; dd if=/dev/zero of=somefile bs=10M count=100 ; sync; date That should do it (the above creates an 1GiB file). It will also test the scheduler, as that /dev/zero read does cause syscalls and switches to kernel context. BTW, the output of hdparm -T should not vary an order of magnitude. If it does and there is nothing obnoxious running in the background, you've got closer to the problem. I doubt it is something like this, though: your system would be sluggish as all heck... Lastly, the difference in boot times may not be due to the hyperthreading issue, at least directly. There are quite a few Indeed. However, when looking at the timings in the /var/log/dmesg comparison, remember the comparison is less for the timings, and more for everything else. Note that some reordering across boots, even of the same kernel, is perfectly normal.
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
On Mon, 05 May 2014, Paul Ausbeck wrote: I've attached the contents of /proc/cpuinfo below, two copies, one with hyperthreading disabled and one enabled. As I told you, the *very first thing* you must do is to make sure you're using the latest firmware for your motherboard (*especially* the BIOS/EFI). If you're not, update it. This bug reeks of a firmware issue. cpuinfo looks normal for both cases, and the microcode is newer than anything Intel ever published to the general public. I've also investigated things a bit further and now I'm thinking that the hyperthreading state affects the system as a whole, not just hdparm. That's expected. First, I've attached hdparm output from the same machine booting to Windows 7. The reported disk speed is not affected by the hyperthreading state. I've also attached boot speed measurements for the two states. Windows 7 boot time with hyperthreading enabled is 2/3 that when disabled. This would be expected if hyperthreading is actually worth anything. Second, it turns out that the boot speed of linux is either unaffected by the state of hyperthreading, 3.2 kernel, or adversely affected by enabling hyperthreading, 3.12 kernel. I've attached I believe you will need to take this to LKML, unfortunately. One information that will help track down the issue, is to try several kernel versions in order to try to pinpoint better when things went bad. LKML: linux-kernel mailing list. I'm thinking that the hdparm scenario is a good canary for a more fundamental problem with hyperthreading, at least on my dn2800mt machine. Perhaps the backports 3.12 kernel hasn't been fully vetted Yes. It makes it trivial to reproduce the bug, so it would help tracking the issue down immensely. But you'll still need to do it with help from the LKML people, unless you can handle the git bissecting yourself. About git bissect (guides): https://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html You can do this: git bissect start git bissect good tag for good kernel version git bissect bad tag for bad kernel version repeat git bissect good/bad as required to enter all datapoints you alread have or manually tested. You can move to any kernel version you want with git reset --hard tag, compile, test, and then mark it with git bissect good or git bissect bad. git bissect will offer you a new test point when you do that. Hint: when bissecting, for safety, first you should test and mark as GOOD or BAD released/stable kernels, i.e. v3.12.8, v3.11.5, etc. See above, use git reset --hard to move to different kernel versions, recompile, boot, test, git bissect good/git bissect bad, rinse and repeat. Try to use a binary search pattern, to reduce the number of kernels you will have to test. Only after you got reasonably near the issue using the above, should you let git bissect choose the test point, because it will usually land you somewhere deep into the release-candidate kernels (or even worse, inside the merge window), and those can be quite broken. Therefore, also for safety, when testing these kernels boot to single-user mode, run the hdparm test, note down what happened in a paper somewhere, and reboot to a known release/stable kernel. Only do any real work (such as the git bissect stuff, compiling, etc) on a safe, known release/stable kernel. Obviously, test single-user mode in your known release/stable kernel first, just to make sure the bug doesn't disappear (or always appear) in single-user mode :) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140508134406.ga32...@khazad-dum.debian.net
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
I don't favor the interleaved response technique, so even if that technique is favored on this list, I'll just stay with keeping enough context so that previous messages don't need frequent reference. Next, I don't agree that this hyperthreading problem reeks of a firmware issue. What it reeks of is a linux kernel issue. I'm not going to replace firmware just to hope that it will fix any issue, much less one with hyperthreading. I've already returned the motherboard once for the the HDMI port failing to function, and as far as I can tell, the Intel fix was to downgrade the firmware to a version older than I had on the machine. So I'm especially not going to randomly upgrade away that fix, even more especially when such an upgrade is irreversible. Next, both recommending a firmware update and asking for /proc/cpuinfo were red herrings reminiscent of a conversation with any modern corporate support department. I will state flatly, that my goal was and is to improve linux. I've been using Microsoft stuff since MS-DOS in 1982. But now at 55, I'm basically jettisoning all that and starting anew with open source. Please give me at least token respect. It's just plain fact that Windows 7 gives one confidence that hyperthreading is functioning properly and linux doesn't Next, from just this one data point, my experience tells me that linux isn't exactly playing friendly with Intel hyperthreading. Given that Intel is not that interested in hyperthreading any more, that would be maybe expected. Hyperthreading was in retrospect a mistake, just like pentium IV, Itanium, letting AMD do ia64 first, iAPX 432. Intel is a history of mistakes. But make no mistake, it's still a powerful company. I'd love for open source to have that kind of power. I'll work on it. Next, I don't get what I'm supposed to bisect. Every kernel I've tried, 3.2.0-4, 3.12-0, and 3.12.9 have obvious issues with hyperthreading. So it seems unlikely to me that any kernel would function properly. In order to bisect, the first step is to find a correct kernel. Perhaps someone could recommend one. Next, I wanted to really verify that the 3.2.0-4 kernel also exhibited the hdparm issue as I actually wasn't 100% certain. The reason that I updated the kernel in the first place from 3.2.0-4 to 3.12-0 was to obtain the native resolution on my 1920x1080 monitor and to allow the machine to successfully S3 suspend and resume. The 3.12 kernel did improve those issues, and the machine will now suspend/resume and it will do 1920x1080 albeit at 16 bits/pixel. But for some reason the card still doesn't steal enough memory, it's getting a paltry 4M, to do the 32 bits per pixel that it's perfectly capable of. That's why I've built my own 3.12.9 kernel, to debug the graphics subsystem issue. With all this stuff flying around, I thought that maybe I was confused and hdparm might actually show the correct disk bandwidth on the 3.2.0-4 kernel. Next, it's not the case that I was confused. hdparm is still a reliable canary for hyperthreading problems on the dn2800mt motherboard. See attached data below, kernel 3.2.0-4 only . When hyperthreading is disabled in the bios, hdparm shows the expected disk bandwidth. With hyperthreading enabled, hdparm reports dramatically less than the expected disk bandwidth. The problem is not as severe on 3.2.0-4 as on the 3.12 series, but it's still obviously there. Next as a newbie, I don't want to waste valuable kernel developer time unless I'm kind of sure that I'm not missing something obvious. But since my hyperthreading issue has not been trivially resolved on this list, I'm sort of assured that I'm not missing that trivial something. If after a few more days I still don't have a trivial answer, I will file a kernel bug. Last, I don't want anyone to feel insulted by what I have to say or the way that I say it. I'm just a straight shooter from way back. If I compare linux to MS Windows and it doesn't measure up in some fashion, it just means that it should measure up and I'll work to make that happen. _ Data mentioned above starts here ___ /proc/version: Linux version 3.2.0-4-686-pae (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.54-2 #Hyperthreading enabled sudo hdparm -tT /dev/sda: Timing cached reads: 1744 MB in 2.00 seconds = 871.70 MB/sec Timing buffered disk reads: 120 MB in 3.05 seconds = 39.30 MB/sec /dev/sdb: Timing cached reads: 1648 MB in 2.00 seconds = 823.93 MB/sec Timing buffered disk reads: 264 MB in 3.01 seconds = 87.83 MB/sec /dev/sdc: Timing cached reads: 1682 MB in 2.00 seconds = 840.98 MB/sec Timing buffered disk reads: 92 MB in 3.04 seconds = 30.31 MB/sec # Hyperthreading disabled /dev/sda: Timing cached reads: 1786 MB in 2.00 seconds = 893.04 MB/sec Timing buffered disk reads: 440 MB in 3.01 seconds
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
I've attached the contents of /proc/cpuinfo below, two copies, one with hyperthreading disabled and one enabled. I've also investigated things a bit further and now I'm thinking that the hyperthreading state affects the system as a whole, not just hdparm. First, I've attached hdparm output from the same machine booting to Windows 7. The reported disk speed is not affected by the hyperthreading state. I've also attached boot speed measurements for the two states. Windows 7 boot time with hyperthreading enabled is 2/3 that when disabled. This would be expected if hyperthreading is actually worth anything. Second, it turns out that the boot speed of linux is either unaffected by the state of hyperthreading, 3.2 kernel, or adversely affected by enabling hyperthreading, 3.12 kernel. I've attached lines from dmesg below showing the times at which the eth0 link becomes ready under various scenarios. Boot times with hyperthreading enabled also seem more variable. I've seen even longer reported boot times on the 3.12 kernel and with a 3.12.9 kernel I've built myself; in the 20 - 30 second range. I'm thinking that the hdparm scenario is a good canary for a more fundamental problem with hyperthreading, at least on my dn2800mt machine. Perhaps the backports 3.12 kernel hasn't been fully vetted yet, but the stable 3.2 kernel should be showing some improvement in boot speeds with hyperthreading enabled over that with hyperthreading disabled, but isn't. Lastly, hdparm is adversely affected by hyperthreading no matter what kernel version is loaded. C:\hdparm -t /dev/hda # Windows 7 /dev/hda: # Hyperthreading disabled Timing buffered disk reads: 446 MB in 3.01 seconds = 148.13 MB/sec Boot Duration:31248ms /dev/hda: # Hyperthreading enabled Timing buffered disk reads: 448 MB in 3.01 seconds = 148.80 MB/sec Boot Duration:21692ms # Boot times, hyperthreading enabled Linux version 3.2.0-4-686-pae (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.54-2 [ 14.240113] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Linux version 3.12-0.bpo.1-686-pae (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.12.9-1~bpo70+1 (2014-02-07) [ 15.825840] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready # Boot times, hyperthreading disabled Linux version 3.2.0-4-686-pae (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.54-2 [ 14.049342] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Linux version 3.12-0.bpo.1-686-pae (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.12.9-1~bpo70+1 (2014-02-07) [ 12.556885] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready cat /proc/cpuinfo # hyperthreading disabled processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 54 model name: Intel(R) Atom(TM) CPU N2800 @ 1.86GHz stepping: 1 microcode: 0x10d cpu MHz: 798.000 cache size: 512 KB physical id: 0 siblings: 2 core id: 0 cpu cores: 2 apicid: 0 initial apicid: 0 fdiv_bug: no f00f_bug: no coma_bug: no fpu: yes fpu_exception: yes cpuid level: 10 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm arat dtherm bogomips: 3733.46 clflush size: 64 cache_alignment: 64 address sizes: 36 bits physical, 48 bits virtual power management: processor: 1 vendor_id: GenuineIntel cpu family: 6 model: 54 model name: Intel(R) Atom(TM) CPU N2800 @ 1.86GHz stepping: 1 microcode: 0x10d cpu MHz: 798.000 cache size: 512 KB physical id: 0 siblings: 2 core id: 1 cpu cores: 2 apicid: 2 initial apicid: 2 fdiv_bug: no f00f_bug: no coma_bug: no fpu: yes fpu_exception: yes cpuid level: 10 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm arat dtherm bogomips: 3733.46 clflush size: 64 cache_alignment: 64 address sizes: 36 bits physical, 48 bits virtual power management: cat /proc/cpuinfo # hyperthreading enabled processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 54 model name: Intel(R) Atom(TM) CPU N2800 @ 1.86GHz stepping: 1 microcode: 0x10d cpu MHz: 798.000 cache size: 512 KB physical id: 0 siblings: 4 core id: 0 cpu cores: 2 apicid: 0 initial
hdparm -t yields incorrect timings when Intel hyperthreading is enabled
Running Wheezy 7.4, kernel 3.2.0-4-686-pae, also on Debian backports kernel 3.12-0.bpo.1-686-pae sudo hdparm -t /dev/sda /dev/sda: # Hyperthreading enabled in bios Timing buffered disk reads: 36 MB in 3.06 seconds = 11.77 MB/sec # Apparently not correct /dev/sda: # Hyperthreading disabled in bios Timing buffered disk reads: 444 MB in 3.01 seconds = 147.38 MB/sec # Expected for WD10EZRX I've formed the habit of using hdparm to vet basic disk operation when I build a new system. Recently I built a system based upon the Intel Atom dn2800mt motherboard. When I went to vet disk bandwidth, I obtained unexpectedly slow readings from hdparm. I found that if I disable hyperthreading in the bios, bandwidth readings are as expected. I believe the numbers reported by hdparm are incorrect when hyperthreading is enabled. There is no other evidence of disk bandwidth problems, and with hyperthreading enabled the system boots slightly faster to ethernet up, 11.92s, vs 12.45s: [ 12.454118] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx # hyperthreading disabled in bios Has anyone else experienced this problem? I'm wondering if it is general to hyperthreading or specific to my particular atom based machine. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53668679.4080...@alumni.cse.ucsc.edu
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
On Sun, 04 May 2014, Paul Ausbeck wrote: when I build a new system. Recently I built a system based upon the Intel Atom dn2800mt motherboard. When I went to vet disk bandwidth, Please, can you give us the output of cat /proc/cpuinfo ? I obtained unexpectedly slow readings from hdparm. I found that if I disable hyperthreading in the bios, bandwidth readings are as expected. I believe the numbers reported by hdparm are incorrect Did you update to the latest available BIOS for your motherboard ? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140505001209.ga29...@khazad-dum.debian.net
Kan man vara ner en extern USB-disk mha hdparm -i
Hej! Jag lyckas vara ner inbyggda diskar genom hdparm -i men det fungerar inte på USB-diskar (som jag använder för backup). Är det någon vet om det är möjligt (eller om det inte går)? Mvh Thomas Dahlén -- To UNSUBSCRIBE, email to debian-user-swedish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fb3d5d.1070...@gmail.com
Re: Kan man vara ner en extern USB-disk mha hdparm -i
On Wed, 2014-02-12 at 10:22 +0100, Thomas Dahlén wrote: Jag lyckas vara ner inbyggda diskar genom hdparm -i men det fungerar inte på USB-diskar (som jag använder för backup). Är det någon vet om det är möjligt (eller om det inte går)? Tyvärr tror jag det beror helt på vilket USB-kabinett du använder, vissa stödjer det, vissa gör det inte, det är en likadan situation med att läsa SMART-data från en disk via USB. Se även första svaret här: https://superuser.com/questions/651880/force-spin-down-of-external-hard-drive-on-linux-raspberry-pi -- Cheers, Sven Arvidsson http://www.whiz.se PGP Key ID 760BDD22 signature.asc Description: This is a digitally signed message part
Re: Kan man vara ner en extern USB-disk mha hdparm -i
Hej Sven! Stort tack för ditt svar! Som av en händelse har jag två olika kabinett men hade inte en tanke på att det kunde bero på kabinettet! Nu ska jag testa med det andra... Mvh Thomas Dahlén Den 12 februari 2014 14:23 skrev Sven Arvidsson s...@whiz.se: On Wed, 2014-02-12 at 10:22 +0100, Thomas Dahlén wrote: Jag lyckas vara ner inbyggda diskar genom hdparm -i men det fungerar inte på USB-diskar (som jag använder för backup). Är det någon vet om det är möjligt (eller om det inte går)? Tyvärr tror jag det beror helt på vilket USB-kabinett du använder, vissa stödjer det, vissa gör det inte, det är en likadan situation med att läsa SMART-data från en disk via USB. Se även första svaret här: https://superuser.com/questions/651880/force-spin-down-of-external-hard-drive-on-linux-raspberry-pi -- Cheers, Sven Arvidsson http://www.whiz.se PGP Key ID 760BDD22 -- __ *Thomas Dahlén* mobil: +46 70 710 64 54
Re: Kan man vara ner en extern USB-disk mha hdparm -i
Hej! för några år sedan fick jag förklarat att det beror på USB--SATA chippet. De billigare implementerar bara det minimum av funktionaliteten som behövs, de dyrare mer. /Janne On Wed, 12 Feb 2014 15:08:00 +0100 Thomas Dahlén erikthomasdah...@gmail.com wrote: Hej Sven! Stort tack för ditt svar! Som av en händelse har jag två olika kabinett men hade inte en tanke på att det kunde bero på kabinettet! Nu ska jag testa med det andra... Mvh Thomas Dahlén Den 12 februari 2014 14:23 skrev Sven Arvidsson s...@whiz.se: On Wed, 2014-02-12 at 10:22 +0100, Thomas Dahlén wrote: Jag lyckas vara ner inbyggda diskar genom hdparm -i men det fungerar inte på USB-diskar (som jag använder för backup). Är det någon vet om det är möjligt (eller om det inte går)? Tyvärr tror jag det beror helt på vilket USB-kabinett du använder, vissa stödjer det, vissa gör det inte, det är en likadan situation med att läsa SMART-data från en disk via USB. Se även första svaret här: https://superuser.com/questions/651880/force-spin-down-of-external-hard-drive-on-linux-raspberry-pi -- Cheers, Sven Arvidsson http://www.whiz.se PGP Key ID 760BDD22 -- To UNSUBSCRIBE, email to debian-user-swedish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140212153843.112935b3@igor
Re: Kan man vara ner en extern USB-disk mha hdparm -i
Hej Janne! Tack, det var bra att veta! Då ska jag pröva med de två olika kabinett jag har! Eller köpa något dyrare Mvh Thomas Dahlén Den 12 februari 2014 15:38 skrev j...@lillahusetiskogen.se: Hej! för några år sedan fick jag förklarat att det beror på USB--SATA chippet. De billigare implementerar bara det minimum av funktionaliteten som behövs, de dyrare mer. /Janne On Wed, 12 Feb 2014 15:08:00 +0100 Thomas Dahlén erikthomasdah...@gmail.com wrote: Hej Sven! Stort tack för ditt svar! Som av en händelse har jag två olika kabinett men hade inte en tanke på att det kunde bero på kabinettet! Nu ska jag testa med det andra... Mvh Thomas Dahlén Den 12 februari 2014 14:23 skrev Sven Arvidsson s...@whiz.se: On Wed, 2014-02-12 at 10:22 +0100, Thomas Dahlén wrote: Jag lyckas vara ner inbyggda diskar genom hdparm -i men det fungerar inte på USB-diskar (som jag använder för backup). Är det någon vet om det är möjligt (eller om det inte går)? Tyvärr tror jag det beror helt på vilket USB-kabinett du använder, vissa stödjer det, vissa gör det inte, det är en likadan situation med att läsa SMART-data från en disk via USB. Se även första svaret här: https://superuser.com/questions/651880/force-spin-down-of-external-hard-drive-on-linux-raspberry-pi -- Cheers, Sven Arvidsson http://www.whiz.se PGP Key ID 760BDD22 -- To UNSUBSCRIBE, email to debian-user-swedish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140212153843.112935b3@igor -- __ *Thomas Dahlén* mobil: +46 70 710 64 54
Re: Kan man vara ner en extern USB-disk mha hdparm -i
M, kopplingen pris prestanda är inte helt självklar... /Janne On Wed, 12 Feb 2014 16:37:28 +0100 Thomas Dahlén erikthomasdah...@gmail.com wrote: Hej Janne! Tack, det var bra att veta! Då ska jag pröva med de två olika kabinett jag har! Eller köpa något dyrare Mvh Thomas Dahlén Den 12 februari 2014 15:38 skrev j...@lillahusetiskogen.se: Hej! för några år sedan fick jag förklarat att det beror på USB--SATA chippet. De billigare implementerar bara det minimum av funktionaliteten som behövs, de dyrare mer. /Janne On Wed, 12 Feb 2014 15:08:00 +0100 Thomas Dahlén erikthomasdah...@gmail.com wrote: Hej Sven! Stort tack för ditt svar! Som av en händelse har jag två olika kabinett men hade inte en tanke på att det kunde bero på kabinettet! Nu ska jag testa med det andra... Mvh Thomas Dahlén Den 12 februari 2014 14:23 skrev Sven Arvidsson s...@whiz.se: On Wed, 2014-02-12 at 10:22 +0100, Thomas Dahlén wrote: Jag lyckas vara ner inbyggda diskar genom hdparm -i men det fungerar inte på USB-diskar (som jag använder för backup). Är det någon vet om det är möjligt (eller om det inte går)? Tyvärr tror jag det beror helt på vilket USB-kabinett du använder, vissa stödjer det, vissa gör det inte, det är en likadan situation med att läsa SMART-data från en disk via USB. Se även första svaret här: https://superuser.com/questions/651880/force-spin-down-of-external-hard-drive-on-linux-raspberry-pi -- Cheers, Sven Arvidsson http://www.whiz.se PGP Key ID 760BDD22 -- To UNSUBSCRIBE, email to debian-user-swedish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140212153843.112935b3@igor -- To UNSUBSCRIBE, email to debian-user-swedish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140212172158.76acd665@igor
Re: Kan man vara ner en extern USB-disk mha hdparm -i
On Wed, 2014-02-12 at 16:37 +0100, Thomas Dahlén wrote: Hej Janne! Tack, det var bra att veta! Då ska jag pröva med de två olika kabinett jag har! Eller köpa något dyrare Tyvärr verkar det inte helt enkelt att ta reda på i förväg vilka kabinett som klarar vad, och vad som stöds i Linux. (I alla fall för SMART krävdes chip-specifikt stöd, vet inte vad som krävs för att spinna ner disken). Jag kör med eSATA för backup, smidigt på en stationär dator, men det fungerar ju inte på en bärbar dator om den saknar en sådan port. -- Cheers, Sven Arvidsson http://www.whiz.se PGP Key ID 760BDD22 signature.asc Description: This is a digitally signed message part
Re: Kan man vara ner en extern USB-disk mha hdparm -i
On 2014-02-12 18:21, Sven Arvidsson wrote:
On Wed, 2014-02-12 at 16:37 +0100, Thomas Dahlén wrote:
Hej Janne!
Tack, det var bra att veta!
Då ska jag pröva med de två olika kabinett jag har! Eller köpa något
dyrare
Tyvärr verkar det inte helt enkelt att ta reda på i förväg vilka
kabinett som klarar vad, och vad som stöds i Linux. (I alla fall för
SMART krävdes chip-specifikt stöd, vet inte vad som krävs för att spinna
ner disken).
Jag kör med eSATA för backup, smidigt på en stationär dator, men det
fungerar ju inte på en bärbar dator om den saknar en sådan port.
Hej!
Så sant, inte helt enkelt...
Nu har jag testat med två olika kabinett (Icy Box och Deltaco) och
kommandot
sudo hdparm -i /dev/sdc
får samma felmeddelande med båda kabinetten:
/dev/sdc:
HDIO_GET_IDENTITY failed: Invalid argument
Mvh
Thomas Dahlén
Ps. På systemets inbyggda diskar går det bra:
sudo hdparm -i /dev/sda
**
/dev/sda:
Model=ST500DM002-1BD142, FwRev=KC45, SerialNo=Z3T6ZNXV
Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs RotSpdTol.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=16384kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=976773168
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=no WriteCache=enabled
Drive conforms to: unknown: ATA/ATAPI-4,5,6,7
*
signifies the current active mode
Hdparm DMA on Newer (SATA) Systems
I get: HDIO_GET_DMA failed: Inappropriate ioctl for device on bootup and any attempt to read or set dma for either the IDE or the SATA disk on my system. This is dual core (P4 by hyperthreading?) intel cpu: ~$ lscpu Architecture: i686 CPU op-mode(s):32-bit, 64-bit CPU(s):2 Thread(s) per core:2 Core(s) per socket:1 CPU socket(s): 1 Vendor ID: GenuineIntel CPU family:15 Model: 4 Stepping: 3 CPU MHz: 3000.392 L1d cache: 16K L2 cache: 2048K Running the stock 32-bit kernel from Sid. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101091807.06760.d_ba...@012.net.il
Re: Hdparm DMA on Newer (SATA) Systems
David Baron put forth on 1/9/2011 10:07 AM: I get: HDIO_GET_DMA failed: Inappropriate ioctl for device on bootup and any attempt to read or set dma for either the IDE or the SATA disk on my system. This is dual core (P4 by hyperthreading?) intel cpu: ~$ lscpu Architecture: i686 CPU op-mode(s):32-bit, 64-bit CPU(s):2 Thread(s) per core:2 Core(s) per socket:1 CPU socket(s): 1 Vendor ID: GenuineIntel CPU family:15 Model: 4 Stepping: 3 CPU MHz: 3000.392 L1d cache: 16K L2 cache: 2048K Running the stock 32-bit kernel from Sid. We need a lot more details David. You've been around here long enough to know this isn't sufficient detail to allow us to diagnose or assist. You mentioned a specific disk subsystem problem, but then the specs on the CPU as supportive evidence? David to his mechanic: My engine doesn't run right. Here's a scratch on the rear bumper, see, that might have something to do with it. Sigh... -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d29e946.7050...@hardwarefreak.com
Re: Hdparm DMA on Newer (SATA) Systems
Hello, David Baron a écrit : I get: HDIO_GET_DMA failed: Inappropriate ioctl for device on bootup and any attempt to read or set dma for either the IDE or the SATA disk on my system. AFAIK, the -d (DMA) setting is relevant only with the legacy IDE drivers, not the newer libata-based PATA and SATA drivers. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d29fb3d.3080...@plouf.fr.eu.org
Re: Hdparm DMA on Newer (SATA) Systems
On Sunday 09 January 2011 19:21:08 debian-user-digest-requ...@lists.debian.org wrote: David Baron put forth on 1/9/2011 10:07 AM: I get: HDIO_GET_DMA failed: Inappropriate ioctl for device on bootup and any attempt to read or set dma for either the IDE or the SATA disk on my system. This is dual core (P4 by hyperthreading?) intel cpu: ~$ lscpu Architecture: i686 CPU op-mode(s):32-bit, 64-bit CPU(s):2 Thread(s) per core:2 Core(s) per socket:1 CPU socket(s): 1 Vendor ID: GenuineIntel CPU family:15 Model: 4 Stepping: 3 CPU MHz: 3000.392 L1d cache: 16K L2 cache: 2048K Running the stock 32-bit kernel from Sid. We need a lot more details David. You've been around here long enough to know this isn't sufficient detail to allow us to diagnose or assist. You mentioned a specific disk subsystem problem, but then the specs on the CPU as supportive evidence? David to his mechanic: My engine doesn't run right. Here's a scratch on the rear bumper, see, that might have something to do with it. Sigh... My impression was something from the kernel and the newer SATA drivers but maybe I am wrong about that. (At first I thought the problem was due to a failing IDE drive but the data was removed from it and this disk is no longer around._ So what information might I present? (Hwinfo looks very verbal and uninformative.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101092050.10984.d_ba...@012.net.il
Re: Hdparm DMA on Newer (SATA) Systems
On Sunday 09 January 2011 19:21:08 debian-user-digest-requ...@lists.debian.org wrote: David Baron put forth on 1/9/2011 10:07 AM: I get: HDIO_GET_DMA failed: Inappropriate ioctl for device on bootup and any attempt to read or set dma for either the IDE or the SATA *** And possibly a common fluke. Linux Questions stated something like this: This is normal, benign error: SATA is not fully recognized as DMA capable. Forget about this error. Such was my suspicion since those disks are working just fine :-) Xubuntu forum suggested checking dmesg: ~$ dmesg | grep Direct [0.948971] scsi 0:0:0:0: Direct-Access ATA WDC WD800JB-00ET 77.0 PQ: 0 ANSI: 5 [0.985211] scsi 2:0:1:0: Direct-Access ATA WDC WD10EACS-00Z 01.0 PQ: 0 ANSI: 5 and also suggested ignoring that error message. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101092058.51239.d_ba...@012.net.il
RE: hdparm - dpkg error on update
On Tue, 30 Nov 2010 16:37:47 -0700 b...@proulx.com wrote: That reads like a similar problem to one reported in this (old) bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558478 Has anyone else gotten this issue and did you come across a fix for this version or the dpkg system? I don't recognize the 'nxsensor' service in your output. Is that in the current Debian archive? 'nxsensor was from a remote desktop software called no-machine. I am guessing the problem exists in that script. What is the header for that script, the part between BEGIN INIT INFO and END INIT INFO? Because I think the problem is probably there. You were absolutely correct! I was pressed for time to troubleshoot the init script, so after simply purging the no-machine package I was able to complete the hdparm update. Thanks Bob :) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bay148-w198652c5c2a6604705e12ef...@phx.gbl
hdparm - dpkg error on update
Hello, This morning I discovered an update for the hdparm package on my debian squeeze system. Update have been perfect for numerous other packages. When I tried to update this package I got errors and now the package is in a broken state. I am not too sure where I should be fiddling to remedy there error messages. They seem to be related to init scripts (update-rc.d: error: insserv rejected the script header), and (insserv: exiting now without changing boot order!). DPKG error output: http://paste.debian.net/101135/ Has anyone else gotten this issue and did you come across a fix for this version or the dpkg system? Thanks. -M -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bay148-w179fc9be39e230fa9104d8ef...@phx.gbl
Re: hdparm - dpkg error on update
Mike Viau wrote: DPKG error output: http://paste.debian.net/101135/ That reads like a similar problem to one reported in this (old) bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558478 Has anyone else gotten this issue and did you come across a fix for this version or the dpkg system? I don't recognize the 'nxsensor' service in your output. Is that in the current Debian archive? I am guessing the problem exists in that script. What is the header for that script, the part between BEGIN INIT INFO and END INIT INFO? Because I think the problem is probably there. Bob signature.asc Description: Digital signature
Re: Advices regarding hdparm multcount option
On 22.07.09 14:31, Dominique Dumont wrote: My Gygabyte motherboard (SB700 with AMD4400+) has poor SATA performance. Any disk I/O leads to high system CPU percentage. And the AHCI interrupt is about 1000/s even for low disk usage. Using hdparm, I've found that all my sata disks have multcount set to 0: $ sudo hdparm /dev/sdb /dev/sdb: multcount = 0 (off) IO_support= 0 (default) readonly = 0 (off) readahead = 256 (on) geometry = 38913/255/63, sectors = 625142448, start = 0 As far as I can tell, I should get better performance by setting mulcount to 8 or 16. (ie. hdparm -m 16 /dev/sdb) But, hdparm warns that -m is a dangerous option. What is your opinion on this ? Is this really dangerous ? Or is it only when playing with too high mulcount value ? afaik those options only work when DMA is not in use, and using DMA is usually much faster. Are you using any kind of hardware RAID? Which kernel do you have? I think that you are missing good drivers for the sata... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. They say when you play that M$ CD backward you can hear satanic messages. That's nothing. If you play it forward it will install Windows. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Advices regarding hdparm multcount option
Hello My Gygabyte motherboard (SB700 with AMD4400+) has poor SATA performance. Any disk I/O leads to high system CPU percentage. And the AHCI interrupt is about 1000/s even for low disk usage. Using hdparm, I've found that all my sata disks have multcount set to 0: $ sudo hdparm /dev/sdb /dev/sdb: multcount = 0 (off) IO_support= 0 (default) readonly = 0 (off) readahead = 256 (on) geometry = 38913/255/63, sectors = 625142448, start = 0 As far as I can tell, I should get better performance by setting mulcount to 8 or 16. (ie. hdparm -m 16 /dev/sdb) But, hdparm warns that -m is a dangerous option. What is your opinion on this ? Is this really dangerous ? Or is it only when playing with too high mulcount value ? All the best -- Dominique Dumont Delivering successful solutions requires giving people what they need, not what they want. Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Applying correct hdparm values after resuming from suspend
Florian Kulzer wrote:
On Sat, Jul 12, 2008 at 09:56:35 +0300, Arthur A wrote:
Hi list,
I'm using Debian Lenny with Laptop-mode tools that I've configured to
manage my laptop's hd, which is controlled by firmware that gives insane
load cycle values. Thus, I've enabled laptop-mode-tools and it currently
applies a setting of 254 (disabled) when running on AC and 128 (enabled
and aggressive pm settings) when running on battery. This works fine on
boot, and when removing or inserting the AC power. However, upon resume a
setting of 128 is applied regardless of the machine's powerstate.
I believe that laptop-mode is being restarted correctly since if I remove
and reinsert the AC cord the correct hdparm settings (254) are applied.
My guess is that something is also being re-initialized upon resume from
suspend that is over-riding laptop-mode-tools. In any event, I thought
that the simplest fix for this would be to add a script to
/etc/pm/sleep.d/01-hdparm-power-check which would do nothing if going to
sleep, and if resuming would check whether the computer was running on
ac, and if so apply hdparm -B 254 /dev/sda
My problem lies in this second part, as I'm not sure how to correctly do
a check, the rest of it I can steal from other scripts included under
/usr/lib/pm-utils/sleep.d/
This is what I think 01-hdparm-power-check would look like:
[...]
I would first check if the on_ac_power command works reliably on your
system. If you run
on_ac_power; echo $?
then you should get 0 (true) if you are connected to AC power and 1
(false) if you are running on battery. (See man on_ac_power; the echo
$? part is necessary to print the exit status.)
If that is OK then your script should work like this:
=
#!/bin/sh
# Check to see if we are running on AC power, and if so,
# override mystery program overriding laptop-mode.conf
. ${PM_FUNCTIONS}
on_ac_power || exit $NA
case $1 in
hibernate|suspend)
;;
thaw|resume)
hdparm -B 254 /dev/sda
;;
*) exit $NA
;;
esac
==
The double pipe || is the logical OR operator. If on_ac_power returns
true then the OR expression is already true overall and the shell will
therefore not even bother to evaluate the second argument; it goes
directly to the case structure. If on_ac_power returns false, on the
other hand, then the shell has to evaluate the second argument, which
makes it exit with status $NA.
Note: I have to admit that I am not entirely sure about the role of the
$NA variable; I assume it is properly defined in the context of these
scripts since many of the other sleep.d hooks use it in the same way.
Worked a treat. Wish I could explain how great it feels to finally have this
fixed. :) Thanks much!
Best,
AA
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Applying correct hdparm values after resuming from suspend
Florian Kulzer wrote:
On Sat, Jul 12, 2008 at 09:56:35 +0300, Arthur A wrote:
Hi list,
I'm using Debian Lenny with Laptop-mode tools that I've configured to
manage my laptop's hd, which is controlled by firmware that gives insane
load cycle values. Thus, I've enabled laptop-mode-tools and it currently
applies a setting of 254 (disabled) when running on AC and 128 (enabled
and aggressive pm settings) when running on battery. This works fine on
boot, and when removing or inserting the AC power. However, upon resume a
setting of 128 is applied regardless of the machine's powerstate.
I believe that laptop-mode is being restarted correctly since if I remove
and reinsert the AC cord the correct hdparm settings (254) are applied.
My guess is that something is also being re-initialized upon resume from
suspend that is over-riding laptop-mode-tools. In any event, I thought
that the simplest fix for this would be to add a script to
/etc/pm/sleep.d/01-hdparm-power-check which would do nothing if going to
sleep, and if resuming would check whether the computer was running on
ac, and if so apply hdparm -B 254 /dev/sda
My problem lies in this second part, as I'm not sure how to correctly do
a check, the rest of it I can steal from other scripts included under
/usr/lib/pm-utils/sleep.d/
This is what I think 01-hdparm-power-check would look like:
[...]
I would first check if the on_ac_power command works reliably on your
system. If you run
on_ac_power; echo $?
then you should get 0 (true) if you are connected to AC power and 1
(false) if you are running on battery. (See man on_ac_power; the echo
$? part is necessary to print the exit status.)
If that is OK then your script should work like this:
=
#!/bin/sh
# Check to see if we are running on AC power, and if so,
# override mystery program overriding laptop-mode.conf
. ${PM_FUNCTIONS}
on_ac_power || exit $NA
case $1 in
hibernate|suspend)
;;
thaw|resume)
hdparm -B 254 /dev/sda
;;
*) exit $NA
;;
esac
It worked great. I've tested it resuming on batteries and on ac, and it works
perfect. pm-util.logs show no problems.
Thanks so much!
Best,
AA
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Applying correct hdparm values after resuming from suspend
Hi list,
I'm using Debian Lenny with Laptop-mode tools that I've configured to manage my
laptop's hd, which is controlled by firmware that gives insane load cycle
values. Thus, I've enabled laptop-mode-tools and it currently applies a setting
of 254 (disabled) when running on AC and 128 (enabled and aggressive pm
settings) when running on battery. This works fine on boot, and when removing or
inserting the AC power. However, upon resume a setting of 128 is applied
regardless of the machine's powerstate.
I believe that laptop-mode is being restarted correctly since if I remove and
reinsert the AC cord the correct hdparm settings (254) are applied. My guess is
that something is also being re-initialized upon resume from suspend that is
over-riding laptop-mode-tools. In any event, I thought that the simplest fix for
this would be to add a script to /etc/pm/sleep.d/01-hdparm-power-check which
would do nothing if going to sleep, and if resuming would check whether the
computer was running on ac, and if so apply hdparm -B 254 /dev/sda
My problem lies in this second part, as I'm not sure how to correctly do a
check, the rest of it I can steal from other scripts included under
/usr/lib/pm-utils/sleep.d/
This is what I think 01-hdparm-power-check would look like:
=
#
#!/bin/sh
# Check to see if we are running on AC power, and if so,
# override mystery program overriding laptop-mode.conf
. ${PM_FUNCTIONS}
if cat /proc/acpi/ac_adapter/C1AB/state = off-line || exit $NA
case $1 in
hibernate|suspend)
;;
thaw|resume)
hdparm -B 254 /dev/sda
;;
*) exit $NA
;;
esac
==
As you can see, I don't know much (anything) about bash scripting. Your advice,
assistance, criticism or concerns would be greatly appreciated.
Best,
AA
NOTE: I originally posted this to debian-laptop, but there does not seem to be
much traffic on that list. I have also tried posting this to Bart Samwell's
laptop-mode-tools waiting list, but there appears to be virtually no traffic there.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Applying correct hdparm values after resuming from suspend
On Sat, Jul 12, 2008 at 09:56:35 +0300, Arthur A wrote:
Hi list,
I'm using Debian Lenny with Laptop-mode tools that I've configured to
manage my laptop's hd, which is controlled by firmware that gives insane
load cycle values. Thus, I've enabled laptop-mode-tools and it currently
applies a setting of 254 (disabled) when running on AC and 128 (enabled
and aggressive pm settings) when running on battery. This works fine on
boot, and when removing or inserting the AC power. However, upon resume a
setting of 128 is applied regardless of the machine's powerstate.
I believe that laptop-mode is being restarted correctly since if I remove
and reinsert the AC cord the correct hdparm settings (254) are applied.
My guess is that something is also being re-initialized upon resume from
suspend that is over-riding laptop-mode-tools. In any event, I thought
that the simplest fix for this would be to add a script to
/etc/pm/sleep.d/01-hdparm-power-check which would do nothing if going to
sleep, and if resuming would check whether the computer was running on
ac, and if so apply hdparm -B 254 /dev/sda
My problem lies in this second part, as I'm not sure how to correctly do
a check, the rest of it I can steal from other scripts included under
/usr/lib/pm-utils/sleep.d/
This is what I think 01-hdparm-power-check would look like:
[...]
I would first check if the on_ac_power command works reliably on your
system. If you run
on_ac_power; echo $?
then you should get 0 (true) if you are connected to AC power and 1
(false) if you are running on battery. (See man on_ac_power; the echo
$? part is necessary to print the exit status.)
If that is OK then your script should work like this:
=
#!/bin/sh
# Check to see if we are running on AC power, and if so,
# override mystery program overriding laptop-mode.conf
. ${PM_FUNCTIONS}
on_ac_power || exit $NA
case $1 in
hibernate|suspend)
;;
thaw|resume)
hdparm -B 254 /dev/sda
;;
*) exit $NA
;;
esac
==
The double pipe || is the logical OR operator. If on_ac_power returns
true then the OR expression is already true overall and the shell will
therefore not even bother to evaluate the second argument; it goes
directly to the case structure. If on_ac_power returns false, on the
other hand, then the shell has to evaluate the second argument, which
makes it exit with status $NA.
Note: I have to admit that I am not entirely sure about the role of the
$NA variable; I assume it is properly defined in the context of these
scripts since many of the other sleep.d hooks use it in the same way.
--
Regards,| http://users.icfo.es/Florian.Kulzer
Florian |
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
hdparm -X udma5 /dev/hda
Sorunu çözdüm. Belki siz de ayni problemle karsilasirsiniz diye cozumunu yaziyorum. BIOS tan kontrol etmek aklima geldi ancak BIOS'un da UDMA2 den fazlasini listelemedigini gorunce sorunun Debian veya yuklu suruculerle ilgili olmadigini anladim. Anakart kitapcigini karistirinca ide0 soketi ile Sabit Disk arasindaki 80 lik serit kabloyu tavsiye edilen sekilde takmamis oldugumu farkettim ve duzeltince her sey yoluna girdi. hdparm -t /dev/hda: Timing buffered disk reads: 162 MB in 3.02 seconds = 53.62 MB/sec benim kulustur bilgisayarim icin fazla iyi ___ Yahoo! kullaniyor musunuz? http://tr.mail.yahoo.com Istenmeyen postadan biktiniz mi? Istenmeyen postadan en iyi korunma Yahoo! Posta'da -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
hdparm -X udma5 /dev/hda
Selam oncelikle bu konu hakkinda google da epey bir aratip ugrastim, 3-4 sefer kernel derledim ama netice elde edemedim onu soyleyim. Sabit diskimin performansini hdparm ile 2-3 Mhz'lerden 28-30 Mhz civarina cikarmayi basarmistim. Asagidaki degisiklikler uygulanmistir. hdparm -M254 -d1 -m16 -A1 -a256 -u1 -c3 -S180 -X udma2 /dev/hda Fakat bir türlü transfer hizini ayarlamayi beceremedim. Maksimum udma2 hiziyla transfer ediyor. Sabit diskim Ata 133 MHz. Anakartin IDE girisleri ise 100 MHz ye uygun bu durumda udma5 olarak calismasi gerektigini dusunuyorum. #root: hdparm -X udma5 /dev/hda setting xfermode to 69 (UltraDMA mode3) Sanki olmus gibi gorunuyor fakat sonra dmesg ciktisina bakinca ide0: Speed warnings UDMA 3/4/5 is not functional. gibi bir cikti ile karsilasiyorum. NOT: butun dmesg ciktisi ve kernel ayarlarimi listeye gonderip mesaj kirliligi olusturmak istemedim. Vaktiniz olursa, ilgilenirseniz; asagidaki adreslerden alip inceleyebilirsiniz. http://time78.servehttp.com/time78/dmesgciktisi.txt http://time78.servehttp.com/time78/config ve bunun yaninda bilgisayarin ozellikleri de http://time78.servehttp.com/node/2 adresinde yer aliyor ___ Yahoo! kullaniyor musunuz? http://tr.mail.yahoo.com Istenmeyen postadan biktiniz mi? Istenmeyen postadan en iyi korunma Yahoo! Posta'da -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problema con configuración de disco IDE (con hdparm)
PROBLEMA SOLUCIONADO. Muchas gracias por la ayuda. Ahora me trabajan los dos discos a UDMA5, y además tengo más espacio dentro de la torre :-) Gracias. Santiago José López Borrazás escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 El 30/12/07 01:52, Javier Rey escribió: (...) Por cierto, hoy mismo me habían hablado de ese tipo de cable, voy a comprarlo y probarlo, ya os contaré. Por eso te digo, que esos cables, aunque sólo sirven para tener un disco duro y un CD/DVD, o una regrabadora. Pero nada más. _No_ sirven para dos discos duros, pero únicamente, si el disco duro que lo quieras como viejo, y que no pueda tener más velocidad, ha de estar en el 2º conector IDE, por supuesto, y el primario UDMA, como en el 1er conector. Si no quieres tener problemas, lo mejor, es un cable de esos redondos, que los hay, que tienen los dos, enmarcados como *80 hilos*, en vez de esos 40 habituales. No te dará problemas. En serio. Por cierto, hoy mismo me habían hablado de ese tipo de cable, voy a comprarlo y probarlo, ya os contaré. ¡Pues adelante! No vas a tener ningún problema. Te lo aseguro. ¡Esos sí que son para discos duros! - -- Slds de Santiago José López Borrazás Conocimientos avanzados en seguridad informática. Conocimientos avanzados en redes. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJHdvAeAAoJELuF9/q6J55WkCsP/0A0DLCnzkwAhTdlniBkeYl+ q6X9G75sOMg0jcwv0OsrABUREDUlhfuki2/x6RYKrilYgGWA8zdQx1s1Jw5VqFfv 0UuHrb0nFVtByspywWYetl0U+PK8EeAbFJD29GNu0x4+LbiOC9OZ8hz3Xb7qP8Pl M5mhehDotiJsZb87RZyfcfpcBHOrX+iM37RHkPU2iLvJlc+2bu1YHQrOd5QX2ivo v1BHYpdGxjXmYTKAIYUDObsBy57up4ejrpUKOpzRNyEP259S3OjdEXHKljlRbbzY 7B5m7y9aBFnANtivzqMk+WkIKgyA34SUQYWer5+zJRHqKyMzgFNsKSh4zhQ8erxK rockAxx7LfyBlF82gHeSoii4qNEgVFEMBUBK+NI8XcuNS6ZeRBtVPNZJhzcpt6mJ fESUzorZJWpW6U/HWHgfh0+jOPz/rZQ7CeqAtIbXzXupAdZ+KnANuX49I/V7S7M4 RGrvb/9rtFg6RfKcQZxgUTTfyYGenpQeKfTIfbSe8yEP3UDX3itE7jDDUA98/R4G 50g/cOfgGlU+MUqi6FTRZl4ndT9QlRXs3dwxl7DIrADsM81cMUFgy+JOlWElzWE4 wgIgIv/3ZyG3O9UDWEDAJcnbCnOX42STSC7JfOWQoo3T6ldD/ECXZWOkl8E6pvVX 5T1m65kVt7g1dxpOugQV =avG9 -END PGP SIGNATURE-
Re: Problema con configuración de disco IDE (con hdparm)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 El 10/10/07 01:33, Javier Rey escribió: PROBLEMA SOLUCIONADO. Muchas gracias por la ayuda. Ahora me trabajan los dos discos a UDMA5, y además tengo más espacio dentro de la torre :-) ;- ¡Pues ya sabes! ¡Un problema menos! Como ya dije, las fajas de IDE, las nuevas, tienen eso. Y puedes hacer mucho más, como más te guste y de lo que te guste. No tienes ningún problema, y además, son unos cables que dejas más respirable a la carcasa y los componentes de la placa madre. Como verás,...ya no vas a tener ningún problema con tu Debian. ¡Te irá perfecto! - -- Slds de Santiago José López Borrazás Conocimientos avanzados en seguridad informática. Conocimientos avanzados en redes. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJHd3URAAoJELuF9/q6J55WK3gP/jLzvyjjEEQV0mCStQpdldat gpjURQrsE2HhzyqTYCO0qMQCbJcEnMkiyNwPUL65Yeilwe9K3WeHCpyKQilMgLnt JV+s75pDA7hNiuCKk38qJlm2ACQrOnqUMSMFHhUOxNm8Xrp67IUc6p/YOWnzOfCt Ihgb+FU9fPahZctqBrrmt9To9vwqF9CCL1ZQm+Z6mXJdmsUKLCNAyghplqChDK0k LGJljxe4AQZY+N9U/7CeUA+61QCbHYwTFyNlkBTRCRivtt88yF0ZZCWVWyybdoA1 MJ3Oz/eayWJ9j6WP1p/F7evjxsiFzvEycAufsjEzuStW7Gs79He4VGuJDtZYUIY7 fGunoY3kFSl4M2cSemRjIgZeI17crPnypjS8f1GPojJtTgZf9+DmbhnAYPosrhEL guKxJCE+QN9jr6c2Am5MIUQiwoezpXYnpZY+gy+21ET941JAqd3ikxl5m2Ja0boN V188tHWtAEdXiWt/PV0Rldifq29+TOPsiDdbutJkD5SHgaxopQ4s79RIdR14Q5Fv 8Fjyo/VkBuWAytf/0Hs2dsRuylk+DnXxOvX4B1IqJ9FeJsLrz1ylph+NSmFSuxab 3k3Yy0niyP0E8Tes5iWIHTFxDRWc+YCFK7Gv4uxu7meKvV8CEwBeScIqcZd9aMb+ KSiXB7mxKrAAjh5ShuEg =ajUD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Problema con configuración de disco IDE (con hdparm)
Hola a todos, no son problemas graves, pero sí que me provocan muchas
dudas.
Tengo dos discos duros, conectados a un mismo canal ide (ide0), uno
maestro de 80 GB y otro esclavo de 20 GB. Aquí pongo las características
(he borrado alguna información irrelevante).
/dev/hda:
Model=ST380011A, FwRev=8.01, SerialNo=5JVRFDM2
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 *udma3 udma4 udma5
/dev/hdb:
Model=ST320413A, FwRev=3.35, SerialNo=6ED11CQH
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=512kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=39102336
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 *udma4 udma5
El problema es que cuando arranco Debian (con linux 2.6.18-5-686),
durante la carga del núcleo aparecen los siguientes mensajes de error.
Dec 28 16:48:58 debian kernel: hdb: dma_intr: status=0x51 { DriveReady
SeekComplete Error
}
Dec 28 16:48:58 debian kernel: hdb: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Dec 28 16:48:58 debian kernel: ide: failed opcode was: unknown
Dec 28 16:48:58 debian kernel: hdb: dma_intr: status=0x51 { DriveReady
SeekComplete Error
}
Dec 28 16:48:58 debian kernel: hdb: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Dec 28 16:48:58 debian kernel: ide: failed opcode was: unknown
Dec 28 16:48:58 debian kernel: hdb: dma_intr: status=0x51 { DriveReady
SeekComplete Error
}
Dec 28 16:48:58 debian kernel: hdb: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Dec 28 16:48:58 debian kernel: ide: failed opcode was: unknown
Dec 28 16:48:58 debian kernel: hdb: dma_intr: status=0x51 { DriveReady
SeekComplete Error
}
Dec 28 16:48:58 debian kernel: hdb: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Dec 28 16:48:58 debian kernel: ide: failed opcode was: unknown
Dec 28 16:48:58 debian kernel: hda: DMA disabled
Dec 28 16:48:58 debian kernel: ide0: reset: success
He estado googleando un poco y el error que aparece (fallo con el CRC)
es básicamente que hay algunos sectores del disco no se han podido leer.
Pero he testeado el disco y no me da sectores defectuosos. Lo que sí que
ocurre es que, una vez arrancado el sistema, al comprobar los modos de
transferencias que se están usando, hda está usando el modo PIO4 y hdb
el modo UDMA4 (66 MB/s).
Esto es algo que he solucionado usando en /etc/hdparm.conf la siguiente
configuración:
/dev/hda {
mult_sect_io = 16
write_cache = off
dma = on
transfer_mode = 67 #Modo de transferencia UDMA3 (44 MB/s)
io32_support = 3
}
NOTA: Respecto a hdb, no aplico ninguna configuración respecto al modo de
transferenc
Y consigo que se active el modo UDMA en hda, de manera que queda así
(información aportada por el controlador IDE, he borrado alguna
información irrelevante)
--AMD BusMastering IDE Configuration
Driver Version: 2.13
South Bridge: :00:0f.0
Revision: IDE 0xa2
Highest DMA rate: UDMA133
BM-DMA base:0xf000
PCI clock: 33.3MHz
---Primary IDE---Secondary IDE--
Cable Type: 80w 40w
--drive0--drive1-drive2--drive3-
Transfer Mode: UDMA UDMA UDMA DMA
Transfer Rate: 44.4MB/s 66.6MB/s 33.3MB/s 3.3MB/s
Lo que ocurre es que, si intento aplicar a hda un modo de trasferencia
UDMA4 O UDMA5, los errores antes mencionados de BadCRC me salen también
durante la ejecución de INIT (imagino que cuando se lee la configuración
de /etc/hdparm.conf), pero esta vez el error aparece tanto en los dos
discos, y el resultado es que, hda ahora queda funcionando en modo DMA,
pero hdb queda en modo PIO.
*No comprendo por qué aparecen errores en lectura de sectores si se
cambia el modo de transferencia a uno más rápido*, sobretodo cuando son
modos soportados según las características del disco duro y estoy usando
un cable IDE de 80 hilos (ya comprobé que no es fallo del cable, con
otro cable me ocurre lo mismo).
*Si alguien me supiera decir a qué podría deberse, se lo agradecería*
Por último, a ver si alguien pudiera saber si habría alguna forma de que
se pudieran salvar los errores de BadCRC durante la carga del kernel, lo
he intentado poniendo como parámetro del kernel ide=nodma y persiste el
problema.
Un saludo, y gracias de antemano!
Re: Problema con configuración de disco IDE (con hdparm)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 El 30/12/07 01:18, Javier Rey escribió: (...) Cable Type: 80w 40w ¿Tas seguro que ese cable tiene 80 conexiones, tanto para el primario como para el secundario? Porque, por lo que, estás conectando del 2º con un conector de 40 pines en vez de 80. Mi consejo, es que, te compres un cable de esos, que tiene la faja circular (envuelto en plástico o vulcanizado), y te dejarás de rollos, porque esos cables tienen 80 hilos por los dos conectores. Lo digo, porque, el cable de 80 hilos en faja (normalmente, tiene 40 hilos, ya que, en el principal, te vienen enmarcados como 80 hilos, porque están entrelazados entre sí), no te garantizan que tengas 80 hilos, tanto como uno, como otro. Lo que ocurre es que, si intento aplicar a hda un modo de trasferencia UDMA4 O UDMA5, los errores antes mencionados de BadCRC me salen también durante la ejecución de INIT (imagino que cuando se lee la configuración de /etc/hdparm.conf), pero esta vez el error aparece tanto en los dos discos, y el resultado es que, hda ahora queda funcionando en modo DMA, pero hdb queda en modo PIO. Me temo que, aunque lo tienes bien, esa faja para hda y hdb, tienes en un tramo los 80 hilos, y el otro, de 40. Lo mejor, es que, te compres un cable nuevo, que te viene los 80 hilos ya puestos y entrelazados, que pueden servir perfectamente para los dos discos duros. *No comprendo por qué aparecen errores en lectura de sectores si se cambia el modo de transferencia a uno más rápido*, sobretodo cuando son modos soportados según las características del disco duro y estoy usando un cable IDE de 80 hilos (ya comprobé que no es fallo del cable, con otro cable me ocurre lo mismo). Ya, sí. Pero el cable siendo de 80, el otro extremo (que normalmente, es del medio), pues no tiene los 80 hilitos entrelazados. Sólo que el terminador del cable, si te fijas, tiene unos remaches que hacen que se sientan que son de 80 hilos. El otro, no lo tiene, los tiene como 40. Ya digo, que hay unos cables nuevos ya (y son redondos, y son mejores, que tienen los 80 hilos, tanto como uno, como otro conector sin ningún tipo de problemas. Y pueden servir para ello. ;-) ¿Tiene tu placa madre otro conector IDE? Pruébalo con el otro canal y con el otro cable de 80 hilos,...¡verás que no te falla! Te lo hará a la primera, y a la de cambio, no te va a dar errores. *Si alguien me supiera decir a qué podría deberse, se lo agradecería* Se debe a lo que he dicho arriba. Que la faja de cable IDE, _sólo_ tiene en el último extremo como 80 hilos, en vez de 40, pero si pones el conector al disco principal dicho conector del medio, ¡_claro_ que te va a dar como IDE normal y te dé errores! Por último, a ver si alguien pudiera saber si habría alguna forma de que se pudieran salvar los errores de BadCRC durante la carga del kernel, lo he intentado poniendo como parámetro del kernel ide=nodma y persiste el problema. Eso no es problema. Aunque, te puedo decir, que puedes indicar al inicio que no se ejecute como UDMA (que se puede). Pero no es recomendable, ya que, perderás mucha velocidad. Un saludo, y gracias de antemano! De nadas. - -- Slds de Santiago José López Borrazás Conocimientos avanzados en seguridad informática. Conocimientos avanzados en redes. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJHdud7AAoJELuF9/q6J55We74P/Rn2onEuVsVZvM6zAhud9s+X 34PFcxJPD1h1peXdUW76VzcRghNuDF13qLUQAqZDu1opSlOwE4h7fUsGF4hIsFhr GoSLWwVI6BQC7FJo7P1BxLM6kvsose048nMR2+LkUS0ei9B6JgmVohaRtSZBE5UF 0XhRq8sv58h11+AATEHJwNNpHU2PfKOi8CeW5kvcx+2Tiz8cnJft1WB4aY3YVyhx ExPoDXD2+YINC2ioDtpc2s0RpLapq6KoP9oehQ0lWltYzz9XcuF7qAtX2VaRC7IM w8sfA64jRQFSWQ4g/LdjT57097Clw0xziApoZW1Zbyz4839xYc96/LIpMB72xhYA G9CLWYlRWVtc7ViYNR/KvtzvOJ5vRONmoXp3fFRPhb74O2LRMU4AeW+O8RhDJ+de YxsIaGw9Wx+5D0cjnnZbPKkHBmclpQtdxQ8Nf5GbvWfTtBPZXvchBNXHDTHrPyEm ryj2Acyn9Ws2PZ4n8ZzJTo3tWrwCCGHdLMW4Fsxus3Ab5hcC5inJwGO5hElVm/Z3 ENuJUPuBt8wU2CvG4ZfSuRRzgR0Wgap/oWzF41bTsWMQkC1SjIwUws6CfQAYCgUh ivItOyLTQNig9jrQ0ohJn5U5OjtMD97lpTarlUc5aRqbytUjkg5J/Ce2G2EP36t3 ZwvrWrmOKSlj3VmB1XGG =tJpC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problema con configuración de disco IDE (con hdparm)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 El 30/12/07 01:34, Santiago José López Borrazás escribió: (...) conector de 40 pines en vez de 80. Dije pines. Mejor hubiera dicho 'hilos', en vez de 'pines'. Error garrafal.. :-PP - -- Slds de Santiago José López Borrazás Conocimientos avanzados en seguridad informática. Conocimientos avanzados en redes. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJHduhGAAoJELuF9/q6J55WD20QAK6VhjsTmNI++gb1ebmzv1VV GL7Ge32XhLTTrDiG29NVGuYfzknmxTDSXmIeF9z+04eLdu7m7v+YLtXHUf86tA9O bdTSoVBahuonNVvY2jVTuuWuzMU36A3fPD9asj2bGtekrW/DmYr59bL7OnUpgXSv 5LZ7z5hhg/t35c802D8DHwJp9ipcQnu7m2UvmGqX+KGzaIMqzaJKKisLifTcgahB PzDOsuQW2kkaiCjz4kph037kVOnnjjOWXjYXRMMkHZ3eRTg4DqAkCFf4+uMBrZRD ywZZF/VlJGRMjE6E3KhRCf83nxKxYYHzbttV55hZhc7/u2AL2JCDb5KJvl6nWKkD ktb/dpjKT1lZPJpMA3ffdKR422Pv7vFBixuxpiMuiKvm0l6ei64OTFwnp/rfp3Hr hht3bXT1bv119wgR6XMZsa+pAv+Dkidb+xZkUFqgUFN/BetZWUCWDUfpBRI8LY6+ H4hLsB1DUgCG0ZQtVATx93WVW/nB562jfhcTn81nwFBCEHkpgu9e2ELDKNP6UYHl foolY2rvwD/LMA3y+4KVQb+ZTEbhSDbUL69WrXefLRZfXd1uKuecrQccBOk6CzP3 7wjzbr3FYyltCbWMonhg8PJ60R5T5mLqIGGJKubG+FvEEocnlAfdRTwPg1aYHyN3 a9nrue1+etdfS/xCqohe =z3ZT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problema con configuración de disco IDE (con hdparm)
Pues simplemente decirte que te agradezco la ayuda, ya que estaba un poco bloqueado y ahora ya sé con qué seguir probando. Sí que he de decirte que el cable que tiene 40 hilos y que aparece en Cable Type es el que corresponde al otro canal ide, en el que sólo hay conectado una grabadora de DVD. Por cierto, hoy mismo me habían hablado de ese tipo de cable, voy a comprarlo y probarlo, ya os contaré. Un saludo y gracias!!! Santiago José López Borrazás escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 El 30/12/07 01:18, Javier Rey escribió: (...) Cable Type: 80w 40w ¿Tas seguro que ese cable tiene 80 conexiones, tanto para el primario como para el secundario? Porque, por lo que, estás conectando del 2º con un conector de 40 pines en vez de 80. Mi consejo, es que, te compres un cable de esos, que tiene la faja circular (envuelto en plástico o vulcanizado), y te dejarás de rollos, porque esos cables tienen 80 hilos por los dos conectores. Lo digo, porque, el cable de 80 hilos en faja (normalmente, tiene 40 hilos, ya que, en el principal, te vienen enmarcados como 80 hilos, porque están entrelazados entre sí), no te garantizan que tengas 80 hilos, tanto como uno, como otro. Lo que ocurre es que, si intento aplicar a hda un modo de trasferencia UDMA4 O UDMA5, los errores antes mencionados de BadCRC me salen también durante la ejecución de INIT (imagino que cuando se lee la configuración de /etc/hdparm.conf), pero esta vez el error aparece tanto en los dos discos, y el resultado es que, hda ahora queda funcionando en modo DMA, pero hdb queda en modo PIO. Me temo que, aunque lo tienes bien, esa faja para hda y hdb, tienes en un tramo los 80 hilos, y el otro, de 40. Lo mejor, es que, te compres un cable nuevo, que te viene los 80 hilos ya puestos y entrelazados, que pueden servir perfectamente para los dos discos duros. *No comprendo por qué aparecen errores en lectura de sectores si se cambia el modo de transferencia a uno más rápido*, sobretodo cuando son modos soportados según las características del disco duro y estoy usando un cable IDE de 80 hilos (ya comprobé que no es fallo del cable, con otro cable me ocurre lo mismo). Ya, sí. Pero el cable siendo de 80, el otro extremo (que normalmente, es del medio), pues no tiene los 80 hilitos entrelazados. Sólo que el terminador del cable, si te fijas, tiene unos remaches que hacen que se sientan que son de 80 hilos. El otro, no lo tiene, los tiene como 40. Ya digo, que hay unos cables nuevos ya (y son redondos, y son mejores, que tienen los 80 hilos, tanto como uno, como otro conector sin ningún tipo de problemas. Y pueden servir para ello. ;-) ¿Tiene tu placa madre otro conector IDE? Pruébalo con el otro canal y con el otro cable de 80 hilos,...¡verás que no te falla! Te lo hará a la primera, y a la de cambio, no te va a dar errores. *Si alguien me supiera decir a qué podría deberse, se lo agradecería* Se debe a lo que he dicho arriba. Que la faja de cable IDE, _sólo_ tiene en el último extremo como 80 hilos, en vez de 40, pero si pones el conector al disco principal dicho conector del medio, ¡_claro_ que te va a dar como IDE normal y te dé errores! Por último, a ver si alguien pudiera saber si habría alguna forma de que se pudieran salvar los errores de BadCRC durante la carga del kernel, lo he intentado poniendo como parámetro del kernel ide=nodma y persiste el problema. Eso no es problema. Aunque, te puedo decir, que puedes indicar al inicio que no se ejecute como UDMA (que se puede). Pero no es recomendable, ya que, perderás mucha velocidad. Un saludo, y gracias de antemano! De nadas. - -- Slds de Santiago José López Borrazás Conocimientos avanzados en seguridad informática. Conocimientos avanzados en redes. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJHdud7AAoJELuF9/q6J55We74P/Rn2onEuVsVZvM6zAhud9s+X 34PFcxJPD1h1peXdUW76VzcRghNuDF13qLUQAqZDu1opSlOwE4h7fUsGF4hIsFhr GoSLWwVI6BQC7FJo7P1BxLM6kvsose048nMR2+LkUS0ei9B6JgmVohaRtSZBE5UF 0XhRq8sv58h11+AATEHJwNNpHU2PfKOi8CeW5kvcx+2Tiz8cnJft1WB4aY3YVyhx ExPoDXD2+YINC2ioDtpc2s0RpLapq6KoP9oehQ0lWltYzz9XcuF7qAtX2VaRC7IM w8sfA64jRQFSWQ4g/LdjT57097Clw0xziApoZW1Zbyz4839xYc96/LIpMB72xhYA G9CLWYlRWVtc7ViYNR/KvtzvOJ5vRONmoXp3fFRPhb74O2LRMU4AeW+O8RhDJ+de YxsIaGw9Wx+5D0cjnnZbPKkHBmclpQtdxQ8Nf5GbvWfTtBPZXvchBNXHDTHrPyEm ryj2Acyn9Ws2PZ4n8ZzJTo3tWrwCCGHdLMW4Fsxus3Ab5hcC5inJwGO5hElVm/Z3 ENuJUPuBt8wU2CvG4ZfSuRRzgR0Wgap/oWzF41bTsWMQkC1SjIwUws6CfQAYCgUh ivItOyLTQNig9jrQ0ohJn5U5OjtMD97lpTarlUc5aRqbytUjkg5J/Ce2G2EP36t3 ZwvrWrmOKSlj3VmB1XGG =tJpC -END PGP SIGNATURE-
Re: Problema con configuración de disco IDE (con hdparm)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 El 30/12/07 01:52, Javier Rey escribió: (...) Por cierto, hoy mismo me habían hablado de ese tipo de cable, voy a comprarlo y probarlo, ya os contaré. Por eso te digo, que esos cables, aunque sólo sirven para tener un disco duro y un CD/DVD, o una regrabadora. Pero nada más. _No_ sirven para dos discos duros, pero únicamente, si el disco duro que lo quieras como viejo, y que no pueda tener más velocidad, ha de estar en el 2º conector IDE, por supuesto, y el primario UDMA, como en el 1er conector. Si no quieres tener problemas, lo mejor, es un cable de esos redondos, que los hay, que tienen los dos, enmarcados como *80 hilos*, en vez de esos 40 habituales. No te dará problemas. En serio. Por cierto, hoy mismo me habían hablado de ese tipo de cable, voy a comprarlo y probarlo, ya os contaré. ¡Pues adelante! No vas a tener ningún problema. Te lo aseguro. ¡Esos sí que son para discos duros! - -- Slds de Santiago José López Borrazás Conocimientos avanzados en seguridad informática. Conocimientos avanzados en redes. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJHdvAeAAoJELuF9/q6J55WkCsP/0A0DLCnzkwAhTdlniBkeYl+ q6X9G75sOMg0jcwv0OsrABUREDUlhfuki2/x6RYKrilYgGWA8zdQx1s1Jw5VqFfv 0UuHrb0nFVtByspywWYetl0U+PK8EeAbFJD29GNu0x4+LbiOC9OZ8hz3Xb7qP8Pl M5mhehDotiJsZb87RZyfcfpcBHOrX+iM37RHkPU2iLvJlc+2bu1YHQrOd5QX2ivo v1BHYpdGxjXmYTKAIYUDObsBy57up4ejrpUKOpzRNyEP259S3OjdEXHKljlRbbzY 7B5m7y9aBFnANtivzqMk+WkIKgyA34SUQYWer5+zJRHqKyMzgFNsKSh4zhQ8erxK rockAxx7LfyBlF82gHeSoii4qNEgVFEMBUBK+NI8XcuNS6ZeRBtVPNZJhzcpt6mJ fESUzorZJWpW6U/HWHgfh0+jOPz/rZQ7CeqAtIbXzXupAdZ+KnANuX49I/V7S7M4 RGrvb/9rtFg6RfKcQZxgUTTfyYGenpQeKfTIfbSe8yEP3UDX3itE7jDDUA98/R4G 50g/cOfgGlU+MUqi6FTRZl4ndT9QlRXs3dwxl7DIrADsM81cMUFgy+JOlWElzWE4 wgIgIv/3ZyG3O9UDWEDAJcnbCnOX42STSC7JfOWQoo3T6ldD/ECXZWOkl8E6pvVX 5T1m65kVt7g1dxpOugQV =avG9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hdparm configuration help
--- Hugo Vanwoerkom [EMAIL PROTECTED] wrote: Joris Huizer wrote: Hello, After the recent udev + hdparm problems, I'm thinking of reconfiguring hdparm (hdparm currently is not configured, just reinstalled, so I'm assuming it's currently using default settings) This is the output of `hdparm -v -i /dev/hda`: /dev/hda: multcount= 0 (off) IO_support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 0 (off) keepsettings = 0 (off) readonly = 0 (off) readahead= 256 (on) geometry = 65535/16/63, sectors = 78165360, start = 0 snip /dev/hdb: multcount= 0 (off) IO_support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 0 (off) keepsettings = 0 (off) readonly = 0 (off) readahead= 256 (on) geometry = 65535/16/63, sectors = 80293248, start = 0 How did dma get turned off? Did you do that yourself? Hugo No, I had purged hdparm, just reinstalled it, but didn't edit any of configuration yet. This is the output using only defaults (there are only commented lines in /etc/hdparm.conf) Joris Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
hdparm configuration help
Hello,
After the recent udev + hdparm problems, I'm thinking
of reconfiguring hdparm (hdparm currently is not
configured, just reinstalled, so I'm assuming it's
currently using default settings)
This is the output of `hdparm -v -i /dev/hda`:
/dev/hda:
multcount= 0 (off)
IO_support = 1 (32-bit)
unmaskirq= 1 (on)
using_dma= 0 (off)
keepsettings = 0 (off)
readonly = 0 (off)
readahead= 256 (on)
geometry = 65535/16/63, sectors = 78165360, start
= 0
Model=IC35L040AVER07-0, FwRev=ER4OA46A,
SerialNo=SXPTX283824
Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs
}
RawCHS=16383/16/63, TrkSize=0, SectSize=0,
ECCbytes=40
BuffType=DualPortCache, BuffSize=1916kB,
MaxMultSect=16, MultSect=off
CurCHS=4047/16/255, CurSects=16511760, LBA=yes,
LBAsects=78165360
IORDY=on/off, tPIO={min:240,w/IORDY:120},
tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
udma3 udma4 *udma5
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: ATA/ATAPI-5 T13 1321D revision 1:
ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5
* signifies the current active mode
/dev/hdb:
multcount= 0 (off)
IO_support = 1 (32-bit)
unmaskirq= 1 (on)
using_dma= 0 (off)
keepsettings = 0 (off)
readonly = 0 (off)
readahead= 256 (on)
geometry = 65535/16/63, sectors = 80293248, start
= 0
Model=Maxtor 2F040J0, FwRev=VAM51JJ0,
SerialNo=F10SPCNE
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0,
ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB,
MaxMultSect=16, MultSect=off
CurCHS=4047/16/255, CurSects=16511760, LBA=yes,
LBAsects=80293248
IORDY=on/off, tPIO={min:120,w/IORDY:120},
tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 udma3
udma4 udma5 *udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: ATA/ATAPI-7 T13 1532D revision 0:
ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4
ATA/ATAPI-5 ATA/ATAPI-6 ATA/ATAPI-7
* signifies the current active mode
Could someone tell me what settings are appropiate for
my hard discs? I tried before with, what didn't really
seem to push things, but problems with modules not
loading reappeared
Thanks,
Joris
Building a website is a piece of cake. Yahoo! Small Business gives you all the
tools to get online.
http://smallbusiness.yahoo.com/webhosting
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hdparm configuration help
On Thu, 30 Aug 2007 02:08:28 -0700, Joris Huizer wrote: Hello, After the recent udev + hdparm problems, I'm thinking of reconfiguring hdparm (hdparm currently is not configured, just reinstalled, so I'm assuming it's currently using default settings) This is the output of `hdparm -v -i /dev/hda`: /dev/hda: multcount= 0 (off) IO_support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 0 (off) keepsettings = 0 (off) readonly = 0 (off) readahead= 256 (on) geometry = 65535/16/63, sectors = 78165360, start = 0 snip /dev/hdb: multcount= 0 (off) IO_support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 0 (off) keepsettings = 0 (off) readonly = 0 (off) readahead= 256 (on) geometry = 65535/16/63, sectors = 80293248, start = 0 snip Could someone tell me what settings are appropiate for my hard discs? I tried before with, what didn't really seem to push things, but problems with modules not loading reappeared You need to turn on at least dma. I suppose the output of hdparm -t /dev/yourdisk is not very cheerful with dma turned off. I recently built a new system and it defaults to dma turned on. I've not edited /etc/defaults/hdparm or /etc/hdparm/.conf. So as to why yours seems to be turned off I do not know. I get this: cevnet:~#hdparm /dev/hda /dev/hda: multcount = 0 (off) IO_support= 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 2048 (on) geometry = 65535/16/63, sectors = 80293248, start = 0 cevnet:~#hdparm -t /dev/hda /dev/hda: Timing buffered disk reads: 92 MB in 3.14 seconds = 29.31 MB/sec the other disc does better than that though: cevnet:~#hdparm /dev/hdb /dev/hdb: multcount = 0 (off) IO_support= 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 2048 (on) geometry = 24792/255/63, sectors = 398297088, start = 0 cevnet:~#hdparm -t /dev/hdb /dev/hdb: Timing buffered disk reads: 172 MB in 3.02 seconds = 56.95 MB/sec -- Chris [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hdparm configuration help
Joris Huizer wrote: Hello, After the recent udev + hdparm problems, I'm thinking of reconfiguring hdparm (hdparm currently is not configured, just reinstalled, so I'm assuming it's currently using default settings) This is the output of `hdparm -v -i /dev/hda`: /dev/hda: multcount= 0 (off) IO_support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 0 (off) keepsettings = 0 (off) readonly = 0 (off) readahead= 256 (on) geometry = 65535/16/63, sectors = 78165360, start = 0 snip /dev/hdb: multcount= 0 (off) IO_support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 0 (off) keepsettings = 0 (off) readonly = 0 (off) readahead= 256 (on) geometry = 65535/16/63, sectors = 80293248, start = 0 How did dma get turned off? Did you do that yourself? Hugo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
hdparm SCSI
Hi, and sorry if this appeared twice, I believe my first post did not get through. After upgrading to the latest Ubuntu release, which ships a 2.6.20 kernel, all the drives are treated as SCSI ones. That's fine, there's probably a good reason for that. The only thing is that I'm now not able to use hdparm to change the drives' settings--multicount, acoustic management, etc. I tried sdparm but it doesn't help much or I don't know how to use it. Could somebody give some info on this issue, please? Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hdparm SCSI
On Wed, 2007-04-25 at 11:15 +0100, yag wrote: Hi, and sorry if this appeared twice, I believe my first post did not get through. After upgrading to the latest Ubuntu release, which ships a 2.6.20 kernel, all the drives are treated as SCSI ones. That's fine, there's probably a good reason for that. The only thing is that I'm now not able to use hdparm to change the drives' settings--multicount, acoustic management, etc. I tried sdparm but it doesn't help much or I don't know how to use it. Could somebody give some info on this issue, please? Yep, its currently an Ubuntu release issue. Nothing in Debian currnetly REALLY pushes it. I use 2.6.20 stock *DEBIAN* kernel and it works normally. If you need help with Ubuntu, pleae goto the forums or the mailing lits(??? haven't thought to see if MLs exist at all for Ubuntu) Cheers. -- greg, [EMAIL PROTECTED] Novell's Directory Services is a competitive product to Microsoft's Active Directory in much the same way that the Saturn V is a competitive product to those dinky little model rockets that kids light off down at the playfield. -- Thane Walkup signature.asc Description: This is a digitally signed message part
Re: Hdparm recalcitrant
Hugues LARRIVE a écrit : | Zuthos a écrit : | Bonjour, | J'ai un portable acer travelmate 2103wlmi | J'essaye de mettre en place le DMA. | Toutefois, je n'arrive a rien. | Il semble qu'il me faille le chipset de la carte mére. | Toutefois, je ne sais pas comment avoir cette information. | Existe-t-il quelquechose comme lspci qui indique les spécifications de | la carte mére? | D'avance, merci | | | | Bonjour, | | Il y a lshw qui donne toutes les infos possibles et imaginables sur le | matériel... y compris s'ils sont pris en charge par un module ou non. | Interressant, et assez complet. | Normalement il est facile de savoir quel est le chipset rien qu'avec | lspci car le chipset intègre généralement un certains nombre de | périphérique pci comme les contrôleurs de disque et usb... | Oui, c'est ce que j'avais fait, mais cela ne marchait pas. Pris d'une soudaine illumination, j'ai recompiler mon noyeau en le mettant en dur dans le noyeau (je l'avais mis en module). ET maintenant cela marche. Je pense que le module ne se chargait pas. Merci au personnes qui se sont penché sur mon probléme. ET merci de m'avoir fait découvrir lshw -- Rien ni personne n'a tout à fait tort : même une horloge arrêtée a raison deux fois par jour. -+- John Steinbeck -+- signature.asc Description: Digital signature
Hdparm recalcitrant
Bonjour, J'ai un portable acer travelmate 2103wlmi J'essaye de mettre en place le DMA. Toutefois, je n'arrive a rien. Il semble qu'il me faille le chipset de la carte mére. Toutefois, je ne sais pas comment avoir cette information. Existe-t-il quelquechose comme lspci qui indique les spécifications de la carte mére? D'avance, merci -- L'ambition est l'ultime refuge de l'échec. Oscar Wilde signature.asc Description: Digital signature
Re: Hdparm recalcitrant
Zuthos a écrit : Bonjour, J'ai un portable acer travelmate 2103wlmi J'essaye de mettre en place le DMA. Toutefois, je n'arrive a rien. Il semble qu'il me faille le chipset de la carte mére. Toutefois, je ne sais pas comment avoir cette information. Existe-t-il quelquechose comme lspci qui indique les spécifications de la carte mére? D'avance, merci Bonjour, Il y a lshw qui donne toutes les infos possibles et imaginables sur le matériel... y compris s'ils sont pris en charge par un module ou non. Normalement il est facile de savoir quel est le chipset rien qu'avec lspci car le chipset intègre généralement un certains nombre de périphérique pci comme les contrôleurs de disque et usb... Par exemple sur mon p4 équipé d'un chipset intel 845 lspci me donne : 00:00.0 Host bridge: Intel Corporation 82845 845 (Brookdale) Chipset Host Bridge (rev 11) 00:01.0 PCI bridge: Intel Corporation 82845 845 (Brookdale) Chipset AGP Bridge (rev 11) 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 81) 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] 02:01.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] 02:05.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) et sur l'amd d'à coté avec un chipset via 8237 : 00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge (rev 80) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78) 01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX 440] (rev a3) Par contre il se peut aussi que linux et pciutils ne connaisse pas dutout ton matériel et que lspci te sorte un truc du genre :00:01.0 PCI bridge: Intel Corp.: Unknown device 27a1... dans ce cas tu vas faire un tour sur une liste d'id pci en ligne genre http://pci-ids.ucw.cz/iii/?i=8086 et là tu vois qu'il sagit de Mobile 945GM/PM/GMS, 943/940GML and 945GT Express PCI Express Root Port... Tu peux aussi essayer avec une version plus récente de pciutils et/ou du noyau linux (après tout c'est l'essentiel)... les commandes dmesg | less et lsmod donnent aussi des indications utiles. Après moi j'ai eu le problème (et je l'ai encore en partie) avec un chipset nvidia MCP61 qui intègre tous les périphériques (vidéo, son, réseau, etc.) et qui n'était pas reonnu par linux, même la dernière version (2.6.17 à l'époque) j'ai fait une recherche sur MCP51 (le prédécesseur) dans les sources du noyeau et j'ai rajouté le MCP61 avec les ids pci correspondant dans tous les fichiers en question... L'IDE a fonctionné tout de suite avec ce noyau bidouillé (taux de transfert X20 !) vu que rien n'avait changé de ce coté là entre le mcp51 et le mcp61. Le 2.6.18 a amené le réseau et tout fonctionne avec le 2.6.19 à 1 ou 2 détails près... Bon courage @+ signature.asc Description: OpenPGP digital signature
Re: hdparm question
If memory serves this might be a western digital drive. postgresql recommends disabling drive cacheing if it's on when it's installed or upgraded so that if the data base is in use and a power failure happens you don't loose the data in the cache that didn't manage to get saved to disk before the power goes out. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hdparm question
On Fri, 2007-04-06 at 18:13 -0400, Jude DaShiell wrote: If memory serves this might be a western digital drive. postgresql recommends disabling drive cacheing if it's on when it's installed or upgraded so that if the data base is in use and a power failure happens you don't loose the data in the cache that didn't manage to get saved to disk before the power goes out. That was quite a while ago with the western Digital drives. You could say that about ALL disks that have cache, btw. I have been using systems with cheap IDE drives for year, havne't disabled the cache and *HAVE* had the db need some work when brought back up. The thing is, hdparm can cause many more problems than it solves when using it in this way. It really is not worth it. -- greg, [EMAIL PROTECTED] Novell's Directory Services is a competitive product to Microsoft's Active Directory in much the same way that the Saturn V is a competitive product to those dinky little model rockets that kids light off down at the playfield. -- Thane Walkup -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
hdparm question
I have postgresql running on an ide type system with a 300GB hard drive. For some reason the command hdparm -W 0 /dev/hda fails with error0x04 so drive cacheing can't be turned off by hdparm on this type of drive so far as I now know. There is all of that lvm stuff on the system running so it's possible hdparm and lvm might not like each other all that much and in my case generate this error. That or there's something else I need to do. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hdparm question
On Thu, 2007-04-05 at 16:58 -0400, Jude DaShiell wrote: I have postgresql running on an ide type system with a 300GB hard drive. For some reason the command hdparm -W 0 /dev/hda fails with error0x04 so drive cacheing can't be turned off by hdparm on this type of drive so far as I now know. There is all of that lvm stuff on the system running so it's possible hdparm and lvm might not like each other all that much and in my case generate this error. That or there's something else I need to do. What kind of hard drive is it? And why are you trying to turn of the cache? -- greg, [EMAIL PROTECTED] Novell's Directory Services is a competitive product to Microsoft's Active Directory in much the same way that the Saturn V is a competitive product to those dinky little model rockets that kids light off down at the playfield. -- Thane Walkup -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Festplattenprobleme nach Installation von hdparm
Hallo,
ich weiß nicht genau, ob mein Problem hier vielleicht off-topic ist,
aber ich habe vor ca. 1 1/2 Wochen Debian etch auf einem Rechner
installiert und alles lief bis vorgestern problemlos. Dann habe ich
kaffeine installiert und der brachte auch gleich hdparm mit, das ich bis
dahin vergessen hatte zu installieren. In /etc/hdparm.conf habe ich dann
für meine Festplatten folgende Werte gesetzt: multsectio=16, dma=on,
io32support=3. Ich weiß nicht mehr, ob mein Problem direkt nach dem
nächsten Booten auftrat, aber nun kommen während des Bootvorgangs (schon
vor dem Aufruf von hdparm) solche Fehlermeldungen (nur aus meiner
Erinnerung, besonders der Status-Wert muss nicht stimmen):
hde: error waiting for DMA
hde: dma timeout retry: status=0x51 {DriveReady SeekComplete
DataRequest}
hde: dma timeout retry: status=0x51 {DriveStatusError BadCRC}
hde: dma timeout retry: status=0x51 {Busy}
Manchmal hängt sich der Rechner beim Bootvorgang auf, manchmal läuft er
aber auch ohne Fehler durch.
Wenn er mit Fehlermeldungen durchgebootet hat, sind anschließend für hde
DMA, MultiSektor-IO und 32-Bit IO alle deaktiviert. Ein erneuter Aufruf
von hdparm schaltet aber alles problemlos ein und die Platte läuft ohne
weitere Fehler durch. Die Probleme treten also nur beim Booten auf.
Meine Frage ist nun, ob es sicher ein Zufall ist, dass vielleicht kurz
nach der Installation von hdparm meine Platte den Geist aufgibt oder ob
es einen Zusammenhang zwischen der Installation von hdparm und dem
Plattenproblem geben könnte. Oder könnte hdparm sogar den Controller
zerstören?
Gruß
Christoph
Re: Festplattenprobleme nach Installation von hdparm
On Mon, Oct 30, 2006 at 11:01:58AM +0100, Christoph Pleger wrote:
Hallo,
ich weiß nicht genau, ob mein Problem hier vielleicht off-topic ist,
aber ich habe vor ca. 1 1/2 Wochen Debian etch auf einem Rechner
installiert und alles lief bis vorgestern problemlos. Dann habe ich
kaffeine installiert und der brachte auch gleich hdparm mit, das ich bis
dahin vergessen hatte zu installieren. In /etc/hdparm.conf habe ich dann
für meine Festplatten folgende Werte gesetzt: multsectio=16, dma=on,
io32support=3. Ich weiß nicht mehr, ob mein Problem direkt nach dem
nächsten Booten auftrat, aber nun kommen während des Bootvorgangs (schon
vor dem Aufruf von hdparm) solche Fehlermeldungen (nur aus meiner
Erinnerung, besonders der Status-Wert muss nicht stimmen):
Deine Festplatten können aber diese Werte vertragen?
hde: error waiting for DMA
hde: dma timeout retry: status=0x51 {DriveReady SeekComplete
DataRequest}
hde: dma timeout retry: status=0x51 {DriveStatusError BadCRC}
hde: dma timeout retry: status=0x51 {Busy}
Manchmal hängt sich der Rechner beim Bootvorgang auf, manchmal läuft er
aber auch ohne Fehler durch.
Das Problem kenne ich auch. Ich habe gestern mein System noch einmal
frisch installiert (wg. Software-RAID) und kann dir daher leider jetzt
gerade keine Info geben wie bei mir die hdparm-settings sind.
Was passiert denn wenn du die hdparm-Einstellungen deaktivierst und
dann die Maschine neu startest?
Es gab hier auf der Liste vor ca. 1 Monat mal einen ähnlichen Thread,
in dem dann auch ein Kernel-Patch vorgeschlagen wurde. Inwiefern diese
Meldungen jetzt wirklich Fehler vom Kernel sind, kann ich leider nicht
sagen.
Ich hatte in der letzten Zeit keine Probleme mehr mit diesen Meldungen
(und hatte auch keine Lust dafür extra einen eigenen Kernel zu
backen).
Wenn er mit Fehlermeldungen durchgebootet hat, sind anschließend für hde
DMA, MultiSektor-IO und 32-Bit IO alle deaktiviert. Ein erneuter Aufruf
von hdparm schaltet aber alles problemlos ein und die Platte läuft ohne
weitere Fehler durch. Die Probleme treten also nur beim Booten auf.
Meine Frage ist nun, ob es sicher ein Zufall ist, dass vielleicht kurz
nach der Installation von hdparm meine Platte den Geist aufgibt oder ob
es einen Zusammenhang zwischen der Installation von hdparm und dem
Plattenproblem geben könnte. Oder könnte hdparm sogar den Controller
zerstören?
Den Controller solltest du eigentlich nicht zerstören können...
Paul
--
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Festplattenprobleme nach Installation von hdparm
Hallo, In /etc/hdparm.conf habe ich dann für meine Festplatten folgende Werte gesetzt: multsectio=16, dma=on, io32support=3. Ich weiß nicht mehr, ob mein Problem direkt nach dem nächsten Booten auftrat, aber nun kommen während des Bootvorgangs (schon vor dem Aufruf von hdparm) solche Fehlermeldungen (nur aus meiner Erinnerung, besonders der Status-Wert muss nicht stimmen): Deine Festplatten können aber diese Werte vertragen? Das DMA dürfte kein Problem sein, denn damit ist die Platte schon vorher gelaufen (hatte vorher SuSE drauf). Laut hdparm behauptet zumindest die Platte, dass sie MultiSectorIO mit Maximalwert 16 kann. Den 32-Bit Support habe ich einfach mal eingeschaltet, bis jetzt hatte ich noch nie Probleme damit, auch nicht bei Platten, die älter sind als die, die jetzt Probleme macht. Was passiert denn wenn du die hdparm-Einstellungen deaktivierst und dann die Maschine neu startest? Bleiben denn die gesetzten Werte bei einem Reboot (auch dann, wenn der Rechner ausgeschaltet war) erhalten? Gruß Christoph
Re: Festplattenprobleme nach Installation von hdparm
On Mon, Oct 30, 2006 at 12:24:22PM +0100, Christoph Pleger wrote: Hallo, In /etc/hdparm.conf habe ich dann für meine Festplatten folgende Werte gesetzt: multsectio=16, dma=on, io32support=3. Ich weiß nicht mehr, ob mein Problem direkt nach dem nächsten Booten auftrat, aber nun kommen während des Bootvorgangs (schon vor dem Aufruf von hdparm) solche Fehlermeldungen (nur aus meiner Erinnerung, besonders der Status-Wert muss nicht stimmen): Deine Festplatten können aber diese Werte vertragen? Das DMA dürfte kein Problem sein, denn damit ist die Platte schon vorher gelaufen (hatte vorher SuSE drauf). Laut hdparm behauptet zumindest die Platte, dass sie MultiSectorIO mit Maximalwert 16 kann. Den 32-Bit Support habe ich einfach mal eingeschaltet, bis jetzt hatte ich noch nie Probleme damit, auch nicht bei Platten, die älter sind als die, die jetzt Probleme macht. Probleme könnte höchstens noch der Controller machen. Bei mir hatte ich mit dem Onboard-Controller (nForce2) keine Probleme, lediglich bei dem Promise Ultra 100TX2 (PCI). Da war es dann auch egal von welchem Hersteller die Platte war. Manchmal haben hde und hdg ausgesetzt manchmal hdf und hdh. Immer schön paarweise. Was passiert denn wenn du die hdparm-Einstellungen deaktivierst und dann die Maschine neu startest? Bleiben denn die gesetzten Werte bei einem Reboot (auch dann, wenn der Rechner ausgeschaltet war) erhalten? Welche Werte? Die, die du per hdparm setzt? Ich hatte damit bislang wenig Probleme. Meiner Meinung nach werden die gespeichert. Bringt den MultiSectorIO / iosupport denn was? Paul -- -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Festplattenprobleme nach Installation von hdparm
Hallo, Bleiben denn die gesetzten Werte bei einem Reboot (auch dann, wenn der Rechner ausgeschaltet war) erhalten? Welche Werte? Die, die du per hdparm setzt? Ich hatte damit bislang wenig Probleme. Meiner Meinung nach werden die gespeichert. Hm. Mag sein, dass die gespeichert werden, aber welchen Sinn soll es dann haben, hdparm bei jedem Booten durch ein Init-Skript zu starten? Ich bin wirklich höchst unentschlossen. Die Frage ist nämlich, ob ich dringend eine neue Platte brauche, um noch rechtzeitig die Daten vor dem Verlust zu retten, oder ob ich bei einer neuen Festplatte feststelle, dass es gar nicht an der Platte lag und ich mir das Geld, den Einbau/Ausbau von Platten und die Kopierarbeit hätte sparen können. Gruß Christoph
Re: Festplattenprobleme nach Installation von hdparm
On Mon, Oct 30, 2006 at 01:32:37PM +0100, Christoph Pleger wrote: Hallo, Bleiben denn die gesetzten Werte bei einem Reboot (auch dann, wenn der Rechner ausgeschaltet war) erhalten? Welche Werte? Die, die du per hdparm setzt? Ich hatte damit bislang wenig Probleme. Meiner Meinung nach werden die gespeichert. Hm. Mag sein, dass die gespeichert werden, aber welchen Sinn soll es dann haben, hdparm bei jedem Booten durch ein Init-Skript zu starten? Ich bin wirklich höchst unentschlossen. Die Frage ist nämlich, ob ich dringend eine neue Platte brauche, um noch rechtzeitig die Daten vor dem Verlust zu retten, oder ob ich bei einer neuen Festplatte feststelle, dass es gar nicht an der Platte lag und ich mir das Geld, den Einbau/Ausbau von Platten und die Kopierarbeit hätte sparen können. Ein Backup schadet nie ;-) Wenn die Fehler auch ohne deine Parameter noch auftreten würde ich dir empfehlen die Platte mit dem Hersteller-Tool (soweit vorhanden) zu überprüfen. Interessant dafür: http://www.ultimatebootcd.com/ Paul -- -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Festplattenprobleme nach Installation von hdparm
Hallo, Ich bin wirklich höchst unentschlossen. Die Frage ist nämlich, ob ich dringend eine neue Platte brauche, um noch rechtzeitig die Daten vor dem Verlust zu retten, oder ob ich bei einer neuen Festplatte feststelle, dass es gar nicht an der Platte lag und ich mir das Geld, den Einbau/Ausbau von Platten und die Kopierarbeit hätte sparen können. Ein Backup schadet nie ;-) Wichtige Sachen habe ich schon gesichert, so dass ich nach einer Neuinstallation von Etch-DVD relativ schnell wieder an den jetzigen Paketstatus und andere Einstellungen käme. Aber einfach kopieren wäre leichter. Wenn die Fehler auch ohne deine Parameter noch auftreten würde ich dir empfehlen die Platte mit dem Hersteller-Tool (soweit vorhanden) zu überprüfen. Ich habe gerade mal an einem anderen Rechner (der Problemrechner ist weit von hier entfernt) einen Test gemacht und festgestellt, dass die hdparm-Werte nach einem Reboot nicht erhalten bleiben. Gruß Christoph
Re: Festplattenprobleme nach Installation von hdparm
On Mon, Oct 30, 2006 at 02:15:24PM +0100, Christoph Pleger wrote: Hallo, Ich bin wirklich höchst unentschlossen. Die Frage ist nämlich, ob ich dringend eine neue Platte brauche, um noch rechtzeitig die Daten vor dem Verlust zu retten, oder ob ich bei einer neuen Festplatte feststelle, dass es gar nicht an der Platte lag und ich mir das Geld, den Einbau/Ausbau von Platten und die Kopierarbeit hätte sparen können. Ein Backup schadet nie ;-) Wichtige Sachen habe ich schon gesichert, so dass ich nach einer Neuinstallation von Etch-DVD relativ schnell wieder an den jetzigen Paketstatus und andere Einstellungen käme. Aber einfach kopieren wäre leichter. Wenn die Fehler auch ohne deine Parameter noch auftreten würde ich dir empfehlen die Platte mit dem Hersteller-Tool (soweit vorhanden) zu überprüfen. Ich habe gerade mal an einem anderen Rechner (der Problemrechner ist weit von hier entfernt) einen Test gemacht und festgestellt, dass die hdparm-Werte nach einem Reboot nicht erhalten bleiben. Nun gut. Dann weiß ich das auch mal. Bei mir waren die Standardeinstellungen meist aber so gut, dass ich daran nicht mehr feilen musste. Gruß, Paul -- -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: hdparm oder Kernel - wer sagt die Wahrheit?
Thomas Antepoth [EMAIL PROTECTED] schrieb am Thu, Aug 31, 2006 at 07:46:53PM +0200: On Wed, 30 Aug 2006, Paul Puschmann wrote: Eigentlich gehört nun eine entsprechende Blacklist von Festplatten hier implementiert, die den maximalen Sektor bei 1 statt bei 0 anfangen zu zählen, aber für mich tut's der quick-fix wie oben angegeben. Zu den in Frage kommenden Festplatten gehört mindestens mal die D540X-4K von Maxtor auch dazu. Bei mir ist es auch eine Seagate, eine Hitachi und zwei WD800BB. dann werd ich mal suchen. Und weil's Dir auch vor nix graust, bekommst Du auch gleich den Patch ;-) [EMAIL PROTECTED]:/usr/src/linux/drivers/ide# diff -u ide-disk.c.orig ide-disk.c --- ide-disk.c.orig 2006-08-30 14:54:34.0 +0200 +++ ide-disk.c 2006-08-30 14:55:12.0 +0200 @@ -355,7 +355,7 @@ | ((args.tfRegister[ IDE_HCYL_OFFSET] ) 16) | ((args.tfRegister[ IDE_LCYL_OFFSET] ) 8) | ((args.tfRegister[IDE_SECTOR_OFFSET] )); - addr++; /* since the return value is (maxlba - 1), we add 1 */ + /* addr++; since the return value is (maxlba - 1), we add 1 */ } return addr; } @@ -384,7 +384,7 @@ ((args.tfRegister[IDE_LCYL_OFFSET])8) | (args.tfRegister[IDE_SECTOR_OFFSET]); addr = ((__u64)high 24) | low; - addr++; /* since the return value is (maxlba - 1), we add 1 */ + /* addr++; since the return value is (maxlba - 1), we add 1 */ } return addr; } Seither ist zumindest mal beim Booten Schluss mit den SectorIdNotFound Meldungen. Wie gesagt - eklig - aber pragmatisch. Danke. Wie war das nun, gab es schon einen Bugreport dafuer? Waere doch sicherlich interessant, oder? Gruss, Paul signature.asc Description: Digital signature
Re: hdparm oder Kernel - wer sagt die Wahrheit?
On Wed, 30 Aug 2006, Paul Puschmann wrote: Eigentlich gehört nun eine entsprechende Blacklist von Festplatten hier implementiert, die den maximalen Sektor bei 1 statt bei 0 anfangen zu zählen, aber für mich tut's der quick-fix wie oben angegeben. Zu den in Frage kommenden Festplatten gehört mindestens mal die D540X-4K von Maxtor auch dazu. Bei mir ist es auch eine Seagate, eine Hitachi und zwei WD800BB. dann werd ich mal suchen. Und weil's Dir auch vor nix graust, bekommst Du auch gleich den Patch ;-) [EMAIL PROTECTED]:/usr/src/linux/drivers/ide# diff -u ide-disk.c.orig ide-disk.c --- ide-disk.c.orig 2006-08-30 14:54:34.0 +0200 +++ ide-disk.c 2006-08-30 14:55:12.0 +0200 @@ -355,7 +355,7 @@ | ((args.tfRegister[ IDE_HCYL_OFFSET] ) 16) | ((args.tfRegister[ IDE_LCYL_OFFSET] ) 8) | ((args.tfRegister[IDE_SECTOR_OFFSET] )); - addr++; /* since the return value is (maxlba - 1), we add 1 */ + /* addr++; since the return value is (maxlba - 1), we add 1 */ } return addr; } @@ -384,7 +384,7 @@ ((args.tfRegister[IDE_LCYL_OFFSET])8) | (args.tfRegister[IDE_SECTOR_OFFSET]); addr = ((__u64)high 24) | low; - addr++; /* since the return value is (maxlba - 1), we add 1 */ + /* addr++; since the return value is (maxlba - 1), we add 1 */ } return addr; } Seither ist zumindest mal beim Booten Schluss mit den SectorIdNotFound Meldungen. Wie gesagt - eklig - aber pragmatisch. t++
Re: hdparm oder Kernel - wer sagt die Wahrheit?
Thomas Antepoth [EMAIL PROTECTED] schrieb am Tue, Aug 29, 2006 at 11:11:39PM +0200: Ich habe mal ein wenig in den Kernel-Sourcen gegraben und folgendes herausgefunden: Das Abschalten der HPA findet in der ide-disk.c in der Funktion idedisk_set_max_address() bzw. in der idedisk_set_max_address_ext() statt. Das Auslesen der Plattenparameter findet in idedisk_read_native_max_address_ext() bzw. in idedisk_read_native_max_address() statt. In dem idedisk_read_*() ist in der Tat auch ein addr++ zu finden, das einen um 1 erhöhten Wert des von der Platte gelieferten maximalen Sektors zurückliefert. Auskommentieren von dem Inkrement ist zwar eklig - aber etwas klügeres fiel mir erst mal nicht ein, da ich den Wirkungszusammenhang in der ide-disk.c noch nicht so ganz im Detail verstanden habe. Egal ob eklig, unverstanden oder was auch immer: Der schnelle Erfolg gibt einem Recht. ;-) Die Meldungen vom Boot: *snip* Eigentlich gehört nun eine entsprechende Blacklist von Festplatten hier implementiert, die den maximalen Sektor bei 1 statt bei 0 anfangen zu zählen, aber für mich tut's der quick-fix wie oben angegeben. Zu den in Frage kommenden Festplatten gehört mindestens mal die D540X-4K von Maxtor auch dazu. Bei mir ist es auch eine Seagate, eine Hitachi und zwei WD800BB. dann werd ich mal suchen. Paul signature.asc Description: Digital signature
hdparm oder Kernel - wer sagt die Wahrheit?
Hallo miteinander,
zwei hdparm-Aufrufe - zwei Ergebnisse - soweit es die Plattengeometrie
betrifft:
[EMAIL PROTECTED]:~# hdparm /dev/hda
/dev/hda:
multcount= 16 (on)
IO_support = 1 (32-bit)
unmaskirq= 1 (on)
using_dma= 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead= 256 (on)
geometry = 65535/16/63, sectors = 78165361, start = 0
[EMAIL PROTECTED]:~# hdparm -I /dev/hda
/dev/hda:
ATA device, with non-removable media
Model Number: ST340823A
Serial Number: 7EF0Y1ET
Firmware Revision: 3.05
Standards:
Supported: 4 3 2
Likely used: 6
Configuration:
Logical max current
cylinders 16383 4047
heads 16 16
sectors/track 63 255
--
CHS current addressable sectors: 16511760
LBAuser addressable sectors: 78165360
Anlass der Nachforschung: Diese Fehlermeldung hier taucht nur beim Booten
auf:
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: Host Protected Area detected.
current capacity is 78165360 sectors (40020 MB)
native capacity is 78165361 sectors (40020 MB)
hda: Host Protected Area disabled.
hda: 78165361 sectors (40020 MB) w/1024KiB Cache, CHS=65535/16/63, UDMA(100)
hda: hda1 hda2
hdc: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78165360,
sector=78165360
ide: failed opcode was: unknown
Die Platte hat 0 reallocated Blocks, badblocks findet nichts, es ist ein
80-poliges Kabel an der Platte, sie ist das einzige Gerät am Bus und
eigentlich ist alles bestens.
Das Board ist ein ASROCK K7S8X Bios 2.60. Der Kernel ein 2.6.17
plain vanilla und das System Debian-Etch.
Bei der Angabe sector=78165360 wird man stutzig. Das ist der letzte vom
User benutzbare Sektor der Platte - vorausgesetzt man fängt bei 1 zu
zählen an. Irgendwer sagt hier also dem Kernel nicht ganz die Wahrheit.
Oder ist hier noch ein Kernel-Bug beim Abschalten der HPA vergraben?
t++
Re: hdparm oder Kernel - wer sagt die Wahrheit?
Thomas Antepoth [EMAIL PROTECTED] schrieb am Tue, Aug 29, 2006 at 02:10:36PM
+0200:
Hallo miteinander,
zwei hdparm-Aufrufe - zwei Ergebnisse - soweit es die Plattengeometrie
betrifft:
[EMAIL PROTECTED]:~# hdparm /dev/hda
/dev/hda:
multcount= 16 (on)
IO_support = 1 (32-bit)
unmaskirq= 1 (on)
using_dma= 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead= 256 (on)
geometry = 65535/16/63, sectors = 78165361, start = 0
[EMAIL PROTECTED]:~# hdparm -I /dev/hda
/dev/hda:
ATA device, with non-removable media
Model Number: ST340823A
Serial Number: 7EF0Y1ET
Firmware Revision: 3.05
Standards:
Supported: 4 3 2
Likely used: 6
Configuration:
Logical max current
cylinders 16383 4047
heads 16 16
sectors/track 63 255
--
CHS current addressable sectors: 16511760
LBAuser addressable sectors: 78165360
Anlass der Nachforschung: Diese Fehlermeldung hier taucht nur beim Booten
auf:
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: Host Protected Area detected.
current capacity is 78165360 sectors (40020 MB)
native capacity is 78165361 sectors (40020 MB)
hda: Host Protected Area disabled.
hda: 78165361 sectors (40020 MB) w/1024KiB Cache, CHS=65535/16/63, UDMA(100)
hda: hda1 hda2
hdc: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78165360,
sector=78165360
ide: failed opcode was: unknown
Hi,
das Problem habe ich auch, allerdings nur mit zwei Platten an einem
Promise-IDE-Controller. Das Problem konnte ich bisher auch noch nicht
loesen und ich hatte ehrlich gesagt auch noch keine Lust dazu.
Die Meldungen tauchen bei mir auch nur sproradisch beim Booten auf.
Paul
signature.asc
Description: Digital signature
Re: hdparm oder Kernel - wer sagt die Wahrheit?
On Tue, 29 Aug 2006, Paul Puschmann wrote:
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: Host Protected Area detected.
current capacity is 78165360 sectors (40020 MB)
native capacity is 78165361 sectors (40020 MB)
hda: Host Protected Area disabled.
Das Datenblatt von Seagate[1] sagt, daß der obere Zahlenwert richtig ist:
SECTORS PER DRIVE (LBA mode) _78,165,360
Daher dürfte bei einer bei 0 beginnenden Zählung maximal der
Sektor 78.165.359 angesprochen werden. Außer der Host Protected-Kram wird
abgeschaltet (was irgendwie nicht zu funktionieren scheint). Dann wird
natürlich 78.165.360 adressiert.
Augenblicklich sieht das für mich wie ein Firmware-Bug in der Platte aus,
die einen um 1 zu hohen Wert zurückliefert.
Ich habe mal ein wenig in den Kernel-Sourcen gegraben und folgendes
herausgefunden:
Das Abschalten der HPA findet in der ide-disk.c in der Funktion
idedisk_set_max_address() bzw. in der idedisk_set_max_address_ext() statt.
Das Auslesen der Plattenparameter findet in
idedisk_read_native_max_address_ext() bzw. in
idedisk_read_native_max_address() statt.
In dem idedisk_read_*() ist in der Tat auch ein addr++ zu finden, das
einen um 1 erhöhten Wert des von der Platte gelieferten
maximalen Sektors zurückliefert. Auskommentieren von dem Inkrement ist
zwar eklig - aber etwas klügeres fiel mir erst mal nicht ein, da ich den
Wirkungszusammenhang in der ide-disk.c noch nicht so ganz im
Detail verstanden habe.
hda: 78165361 sectors (40020 MB) w/1024KiB Cache, CHS=65535/16/63, UDMA(100)
hda: hda1 hda2
hdc: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78165360,
sector=78165360
ide: failed opcode was: unknown
Hi,
das Problem habe ich auch, allerdings nur mit zwei Platten an einem
Promise-IDE-Controller. Das Problem konnte ich bisher auch noch nicht
loesen und ich hatte ehrlich gesagt auch noch keine Lust dazu.
Die Meldungen waren früher auch schon mal - aber der Rechner wurde nur 14
mal insgesamt gebootet. Da konnte man schon damit leben. Die Platte soll
nun aber in ein Desktop. Dort ist die Sichtbarkeit dieses Fehlers dann
schon etwas gravierender, wenn bei jedem Systemstart diese ziemlich
beängstigenden (aber harmlosen) Meldungen vorbeihuschen.
Die Meldungen tauchen bei mir auch nur sproradisch beim Booten auf.
Reboots sind für Kernel-Updates und Hardware-Tausch. 14 x booten in ca.
drei Jahren sollten für sich sprechen... ;-)
t++
[1] http://www.seagate.com/support/disc/specs/ata/st340823a.html
