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
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
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
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/d
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/hdpa
-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
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 kern
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
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 1
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 kern
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
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
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
] 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
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
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 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
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 ava
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:
> >>
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. Intere
+ 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:
>
>
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
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
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
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
), 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
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
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
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
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
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?
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
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
, 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
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
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
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
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
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
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
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
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
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
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
, 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
:
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
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å
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
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
, 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
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):
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
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
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
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
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
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
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
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
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
.
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
.
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
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
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
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
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
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
-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
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,
-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
-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
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
-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
--- 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
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
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
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
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
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
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.
|
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
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
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
* 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
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
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
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
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
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
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
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
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
, dass die
hdparm-Werte nach einem Reboot nicht erhalten bleiben.
Gruß
Christoph
(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ß
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
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
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
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
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
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
1 - 100 of 814 matches
Mail list logo
