Peter Zijlstra wrote:
>
> but I have an increasing seek error rate as well. I got the ST disk
> because thinkwiki suggested it.
>
Apparently Seagate has their own definition of seek error rate.
Large numbers are normal, or at least very common.
Now I wonder if they have their own way of doing
Peter Zijlstra wrote:
but I have an increasing seek error rate as well. I got the ST disk
because thinkwiki suggested it.
Apparently Seagate has their own definition of seek error rate.
Large numbers are normal, or at least very common.
Now I wonder if they have their own way of doing
On Wed, 2007-04-18 at 17:27 -0400, Chuck Ebbert wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday 18 April 2007, Chuck Ebbert wrote:
> >> Mark Lord wrote:
> >>> Mark Lord wrote:
> With the patch applied, I don't see *any* new activity in those
> S.M.A.R.T.
> attributes over
Jan,
mine does not pop running Linux but only during the shutdown. As I
wrote before, switching from PATA to IDE has solved the problem for
me.
Regards,
Fabio
On 4/21/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>On Apr 20 2007 21:57, Fabio Comolli wrote:
>
> hda: TOSHIBA MK8025GAS, ATA
>On Apr 20 2007 21:57, Fabio Comolli wrote:
>
> hda: TOSHIBA MK8025GAS, ATA DISK drive
MK...? These sort of disks do that stupid pop. Mine -- a MK2003GAH --
does it even while running Linux, if the disk is _idle_.
See http://lkml.org/lkml/2006/11/15/413 - hope it provides some pointers.
Hi.
On 4/21/07, emisca <[EMAIL PROTECTED]> wrote:
So, removing -d halt option solves this problem?
According to the halt manpage, -n implies -d (in other words, -d is
not removed at all).
Regards,
Fabio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
So, removing -d halt option solves this problem?
2007/4/20, Fabio Comolli <[EMAIL PROTECTED]>:
Bingo!
I switched from ata_piix.c to piix_ide.c and the "pop" disappeared.
I must say that the "pop" also disappeared after suspending to disk
using suspend2 (obviously without executing halt -n -h
So, removing -d halt option solves this problem?
2007/4/20, Fabio Comolli [EMAIL PROTECTED]:
Bingo!
I switched from ata_piix.c to piix_ide.c and the pop disappeared.
I must say that the pop also disappeared after suspending to disk
using suspend2 (obviously without executing halt -n -h -p) .
Hi.
On 4/21/07, emisca [EMAIL PROTECTED] wrote:
So, removing -d halt option solves this problem?
According to the halt manpage, -n implies -d (in other words, -d is
not removed at all).
Regards,
Fabio
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On Apr 20 2007 21:57, Fabio Comolli wrote:
hda: TOSHIBA MK8025GAS, ATA DISK drive
MK...? These sort of disks do that stupid pop. Mine -- a MK2003GAH --
does it even while running Linux, if the disk is _idle_.
See http://lkml.org/lkml/2006/11/15/413 - hope it provides some pointers.
Regards,
Jan,
mine does not pop running Linux but only during the shutdown. As I
wrote before, switching from PATA to IDE has solved the problem for
me.
Regards,
Fabio
On 4/21/07, Jan Engelhardt [EMAIL PROTECTED] wrote:
On Apr 20 2007 21:57, Fabio Comolli wrote:
hda: TOSHIBA MK8025GAS, ATA DISK
On Wed, 2007-04-18 at 17:27 -0400, Chuck Ebbert wrote:
Bartlomiej Zolnierkiewicz wrote:
On Wednesday 18 April 2007, Chuck Ebbert wrote:
Mark Lord wrote:
Mark Lord wrote:
With the patch applied, I don't see *any* new activity in those
S.M.A.R.T.
attributes over multiple hibernates
Bingo!
I switched from ata_piix.c to piix_ide.c and the "pop" disappeared.
I must say that the "pop" also disappeared after suspending to disk
using suspend2 (obviously without executing halt -n -h -p) . In both
cases it was present with the previous setup.
This is with a pure PATA setup with
Chuck Ebbert wrote:
Stephen Clark wrote:
Mark Lord wrote:
Mark Lord wrote:
With the patch applied, I don't see *any* new activity in those
S.M.A.R.T.
attributes over multiple hibernates (Linux "suspend-to-disk").
Scratch that -- operator failure. ;)
The patch
Chuck Ebbert wrote:
Stephen Clark wrote:
Mark Lord wrote:
Mark Lord wrote:
With the patch applied, I don't see *any* new activity in those
S.M.A.R.T.
attributes over multiple hibernates (Linux suspend-to-disk).
Scratch that -- operator failure. ;)
The patch
Bingo!
I switched from ata_piix.c to piix_ide.c and the pop disappeared.
I must say that the pop also disappeared after suspending to disk
using suspend2 (obviously without executing halt -n -h -p) . In both
cases it was present with the previous setup.
This is with a pure PATA setup with no
Stephen Clark wrote:
> Mark Lord wrote:
>
>> Mark Lord wrote:
>>
>>
>>> With the patch applied, I don't see *any* new activity in those
>>> S.M.A.R.T.
>>> attributes over multiple hibernates (Linux "suspend-to-disk").
>>>
>>
>> Scratch that -- operator failure. ;)
>> The patch makes no
Stephen Clark wrote:
It is definitely the disk drive. It is located in the right front corner
of my laptop so I put my ear
by it during shutdown and that is where the click is coming from.
Isn't there also a speaker located there?
-
To unsubscribe from this list: send the line "unsubscribe
From the debian etch 4.0 /etc/init.d/halt script:
# Don't shut down drives if we're using RAID.
hddown="-h"
if grep -qs '^md.*active' /proc/mdstat
then
hddown=""
fi
# If INIT_HALT=HALT don't poweroff.
poweroff="-p"
if [
Jan Engelhardt wrote:
On Apr 18 2007 09:39, Stephen Clark wrote:
So this is the pop I hear on my new laptop that is using
libata=combined_mode when I shut my system down. I didn't get the
pop with the same disk drive in an older laptop that was only ide.
It sounds like a relay closing or
On Apr 18 2007 09:39, Stephen Clark wrote:
>>
> So this is the pop I hear on my new laptop that is using
> libata=combined_mode when I shut my system down. I didn't get the
> pop with the same disk drive in an older laptop that was only ide.
> It sounds like a relay closing or opening, but is
On Apr 18 2007 09:39, Stephen Clark wrote:
So this is the pop I hear on my new laptop that is using
libata=combined_mode when I shut my system down. I didn't get the
pop with the same disk drive in an older laptop that was only ide.
It sounds like a relay closing or opening, but is really my
Jan Engelhardt wrote:
On Apr 18 2007 09:39, Stephen Clark wrote:
So this is the pop I hear on my new laptop that is using
libata=combined_mode when I shut my system down. I didn't get the
pop with the same disk drive in an older laptop that was only ide.
It sounds like a relay closing or
From the debian etch 4.0 /etc/init.d/halt script:
# Don't shut down drives if we're using RAID.
hddown=-h
if grep -qs '^md.*active' /proc/mdstat
then
hddown=
fi
# If INIT_HALT=HALT don't poweroff.
poweroff=-p
if [
Stephen Clark wrote:
It is definitely the disk drive. It is located in the right front corner
of my laptop so I put my ear
by it during shutdown and that is where the click is coming from.
Isn't there also a speaker located there?
-
To unsubscribe from this list: send the line unsubscribe
Stephen Clark wrote:
Mark Lord wrote:
Mark Lord wrote:
With the patch applied, I don't see *any* new activity in those
S.M.A.R.T.
attributes over multiple hibernates (Linux suspend-to-disk).
Scratch that -- operator failure. ;)
The patch makes no difference over hibernates in
Mark Lord wrote:
Tejun Heo wrote:
1. shutdown(8) issues SYNCHRONIZE_CACHE followed by STANDBY_NOW
2. kernel shutdown starts
3. libata shutdown issues SYNCHRONIZE_CACHE
4. power goes off
Okay, after some experimentatino, it's the STANDBY_NOW that
is causing the Power-Off_Retract_Count to
Tejun Heo wrote:
1. shutdown(8) issues SYNCHRONIZE_CACHE followed by STANDBY_NOW
2. kernel shutdown starts
3. libata shutdown issues SYNCHRONIZE_CACHE
4. power goes off
Okay, after some experimentatino, it's the STANDBY_NOW that
is causing the Power-Off_Retract_Count to increment on my
Robert Hancock wrote:
> Tejun Heo wrote:
>> This really isn't a regression. It's been always like that with libata.
>> libata doesn't make devices go into standby mode and shutdown(8) does
>> it for libata. The problem here is that libata does issue
>> SYNCHRONIZE_CACHE on shutdown. So, the
Tejun Heo wrote:
This really isn't a regression. It's been always like that with libata.
libata doesn't make devices go into standby mode and shutdown(8) does
it for libata. The problem here is that libata does issue
SYNCHRONIZE_CACHE on shutdown. So, the sequence of event is...
1.
Stephen Clark wrote:
So this is the pop I hear on my new laptop that is using
libata=combined_mode
when I shut my system down. I didn't get the pop with the same disk
drive in an older
laptop that was only ide. It sounds like a relay closing or opening, but
is really my
drive head doing an
Stephen Clark wrote:
I tried this on 2.6.20.2 it applied to libata with some fuzz and I had
to manually edit libata.h
When I did a shutdown I still got the click/pop.
I also noticed the last thing displayed on the lcd before it goes blank is
Synchronizing SCSI Disks - then the click/pop.
HTH,
On 4/18/07, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
On Wednesday 18 April 2007, Chuck Ebbert wrote:
> Mark Lord wrote:
> > Mark Lord wrote:
> >>
> >> With the patch applied, I don't see *any* new activity in those
> >> S.M.A.R.T.
> >> attributes over multiple hibernates (Linux
Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 18 April 2007, Chuck Ebbert wrote:
>> Mark Lord wrote:
>>> Mark Lord wrote:
With the patch applied, I don't see *any* new activity in those
S.M.A.R.T.
attributes over multiple hibernates (Linux "suspend-to-disk").
>>> Scratch that --
On Wednesday 18 April 2007, Tejun Heo wrote:
> Mark Lord wrote:
> > Chuck Ebbert wrote:
> >> Mark Lord wrote:
> >>> I'll patch it locally on my own machines, but what about the tens
> >>> of thousands of other Seagate notebook drive owners out there?
> >>>
> >>
> >> This is a problem with Seagate
On Wednesday 18 April 2007, Chuck Ebbert wrote:
> Mark Lord wrote:
> > Mark Lord wrote:
> >>
> >> With the patch applied, I don't see *any* new activity in those
> >> S.M.A.R.T.
> >> attributes over multiple hibernates (Linux "suspend-to-disk").
> >
> > Scratch that -- operator failure. ;)
> >
Mark Lord wrote:
> Mark Lord wrote:
>>
>> With the patch applied, I don't see *any* new activity in those
>> S.M.A.R.T.
>> attributes over multiple hibernates (Linux "suspend-to-disk").
>
> Scratch that -- operator failure. ;)
> The patch makes no difference over hibernates in the SMART logs.
>
Mark Lord wrote:
Mark Lord wrote:
With the patch applied, I don't see *any* new activity in those S.M.A.R.T.
attributes over multiple hibernates (Linux "suspend-to-disk").
Scratch that -- operator failure. ;)
The patch makes no difference over hibernates in the SMART logs.
It's
Mark Lord wrote:
With the patch applied, I don't see *any* new activity in those S.M.A.R.T.
attributes over multiple hibernates (Linux "suspend-to-disk").
Scratch that -- operator failure. ;)
The patch makes no difference over hibernates in the SMART logs.
It's still logging extra
Tejun Heo wrote:
Mark Lord wrote:
..
It would be nice if somebody who can hear the "pop" would also test this,
as it will confirm that this is a complete fix for the problem.
You'll probably be able to here the "pop" on sleep-to-disk.
My "pop" drives are busy elsewhere right now.
The
Mark Lord wrote:
Alan Cox wrote:
+ if (dev->needs_flush && ata_try_flush_cache(dev)) {
return ata_scsi_flush_xlat;
+ dev->needs_flush = 0;
Works better if you swap the dev-> and return lines
Heh, yeah, I noticed
Mark Lord wrote:
> Alan Cox wrote:
>>> +if (dev->needs_flush && ata_try_flush_cache(dev)) {
>>> return ata_scsi_flush_xlat;
>>> +dev->needs_flush = 0;
>>
>> Works better if you swap the dev-> and return lines
>
> Heh, yeah, I noticed that!
>
> Here it is,
Alan Cox wrote:
+ if (dev->needs_flush && ata_try_flush_cache(dev)) {
return ata_scsi_flush_xlat;
+ dev->needs_flush = 0;
Works better if you swap the dev-> and return lines
Heh, yeah, I noticed that!
Here it is, *tested* now, with
> + if (dev->needs_flush && ata_try_flush_cache(dev)) {
> return ata_scsi_flush_xlat;
> + dev->needs_flush = 0;
Works better if you swap the dev-> and return lines
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Mark Lord wrote:
Alan Cox wrote:
If you see a synchronize cache succeed and you then see the drive
shutdown succeed then you know that a sync cache can be faked as ok
safely. Any other command in between or after and it doesn't get faked
This seems pretty easy to deal with at command issue.
Alan Cox wrote:
If you see a synchronize cache succeed and you then see the drive
shutdown succeed then you know that a sync cache can be faked as ok
safely. Any other command in between or after and it doesn't get faked
This seems pretty easy to deal with at command issue.
Yup. It could be
Alan Cox wrote:
Thought about that and querying power state before doing shutdown
sequence but things get somewhat ugly because shutdown sequence is
driven from sd->shutdown(). We'll have to snoop both sync and shutdown
commands and check whether the system is shutting down. Also, I felt
Alan Cox wrote:
Thought about that and querying power state before doing shutdown
sequence but things get somewhat ugly because shutdown sequence is
driven from sd->shutdown(). We'll have to snoop both sync and shutdown
commands and check whether the system is shutting down. Also, I felt
> Thought about that and querying power state before doing shutdown
> sequence but things get somewhat ugly because shutdown sequence is
> driven from sd->shutdown(). We'll have to snoop both sync and shutdown
> commands and check whether the system is shutting down. Also, I felt
> very
Tejun Heo wrote:
Alan Cox wrote:
Not that simple. Most disks don't spin up on SYNCHRONIZE_CACHE if
its cache is clean. Sadly some disks actually spin up when it
receives spin down command while spun down to immediately spin down
again, so we would be fixing problem for some number of disks
Alan Cox wrote:
Not that simple. Most disks don't spin up on SYNCHRONIZE_CACHE if its
cache is clean. Sadly some disks actually spin up when it receives spin
down command while spun down to immediately spin down again, so we would
be fixing problem for some number of disks while breaking
> Not that simple. Most disks don't spin up on SYNCHRONIZE_CACHE if its
> cache is clean. Sadly some disks actually spin up when it receives spin
> down command while spun down to immediately spin down again, so we would
> be fixing problem for some number of disks while breaking others. :-(
Bodo Eggert wrote:
SCSI part of the fix is queued in scsi-misc-2.6 tree and libata-dev part
is acked and waiting to be merged, so the fix will be available in
2.6.22. However, it's disabled by default to remain compatible with the
Tejun Heo <[EMAIL PROTECTED]> wrote:
> This really isn't a regression. It's been always like that with libata.
> libata doesn't make devices go into standby mode and shutdown(8) does
> it for libata. The problem here is that libata does issue
> SYNCHRONIZE_CACHE on shutdown. So, the sequence
Tejun Heo [EMAIL PROTECTED] wrote:
This really isn't a regression. It's been always like that with libata.
libata doesn't make devices go into standby mode and shutdown(8) does
it for libata. The problem here is that libata does issue
SYNCHRONIZE_CACHE on shutdown. So, the sequence of
Bodo Eggert wrote:
SCSI part of the fix is queued in scsi-misc-2.6 tree and libata-dev part
is acked and waiting to be merged, so the fix will be available in
2.6.22. However, it's disabled by default to remain compatible with the
Not that simple. Most disks don't spin up on SYNCHRONIZE_CACHE if its
cache is clean. Sadly some disks actually spin up when it receives spin
down command while spun down to immediately spin down again, so we would
be fixing problem for some number of disks while breaking others. :-(
Alan Cox wrote:
Not that simple. Most disks don't spin up on SYNCHRONIZE_CACHE if its
cache is clean. Sadly some disks actually spin up when it receives spin
down command while spun down to immediately spin down again, so we would
be fixing problem for some number of disks while breaking
Tejun Heo wrote:
Alan Cox wrote:
Not that simple. Most disks don't spin up on SYNCHRONIZE_CACHE if
its cache is clean. Sadly some disks actually spin up when it
receives spin down command while spun down to immediately spin down
again, so we would be fixing problem for some number of disks
Thought about that and querying power state before doing shutdown
sequence but things get somewhat ugly because shutdown sequence is
driven from sd-shutdown(). We'll have to snoop both sync and shutdown
commands and check whether the system is shutting down. Also, I felt
very uneasy
Alan Cox wrote:
Thought about that and querying power state before doing shutdown
sequence but things get somewhat ugly because shutdown sequence is
driven from sd-shutdown(). We'll have to snoop both sync and shutdown
commands and check whether the system is shutting down. Also, I felt
Alan Cox wrote:
Thought about that and querying power state before doing shutdown
sequence but things get somewhat ugly because shutdown sequence is
driven from sd-shutdown(). We'll have to snoop both sync and shutdown
commands and check whether the system is shutting down. Also, I felt
Alan Cox wrote:
If you see a synchronize cache succeed and you then see the drive
shutdown succeed then you know that a sync cache can be faked as ok
safely. Any other command in between or after and it doesn't get faked
This seems pretty easy to deal with at command issue.
Yup. It could be
Mark Lord wrote:
Alan Cox wrote:
If you see a synchronize cache succeed and you then see the drive
shutdown succeed then you know that a sync cache can be faked as ok
safely. Any other command in between or after and it doesn't get faked
This seems pretty easy to deal with at command issue.
+ if (dev-needs_flush ata_try_flush_cache(dev)) {
return ata_scsi_flush_xlat;
+ dev-needs_flush = 0;
Works better if you swap the dev- and return lines
Alan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Alan Cox wrote:
+ if (dev-needs_flush ata_try_flush_cache(dev)) {
return ata_scsi_flush_xlat;
+ dev-needs_flush = 0;
Works better if you swap the dev- and return lines
Heh, yeah, I noticed that!
Here it is, *tested* now, with
Mark Lord wrote:
Alan Cox wrote:
+if (dev-needs_flush ata_try_flush_cache(dev)) {
return ata_scsi_flush_xlat;
+dev-needs_flush = 0;
Works better if you swap the dev- and return lines
Heh, yeah, I noticed that!
Here it is, *tested* now, with another
Mark Lord wrote:
Alan Cox wrote:
+ if (dev-needs_flush ata_try_flush_cache(dev)) {
return ata_scsi_flush_xlat;
+ dev-needs_flush = 0;
Works better if you swap the dev- and return lines
Heh, yeah, I noticed that!
Tejun Heo wrote:
Mark Lord wrote:
..
It would be nice if somebody who can hear the pop would also test this,
as it will confirm that this is a complete fix for the problem.
You'll probably be able to here the pop on sleep-to-disk.
My pop drives are busy elsewhere right now.
The system I
Mark Lord wrote:
With the patch applied, I don't see *any* new activity in those S.M.A.R.T.
attributes over multiple hibernates (Linux suspend-to-disk).
Scratch that -- operator failure. ;)
The patch makes no difference over hibernates in the SMART logs.
It's still logging extra
Mark Lord wrote:
Mark Lord wrote:
With the patch applied, I don't see *any* new activity in those S.M.A.R.T.
attributes over multiple hibernates (Linux suspend-to-disk).
Scratch that -- operator failure. ;)
The patch makes no difference over hibernates in the SMART logs.
It's still
Mark Lord wrote:
Mark Lord wrote:
With the patch applied, I don't see *any* new activity in those
S.M.A.R.T.
attributes over multiple hibernates (Linux suspend-to-disk).
Scratch that -- operator failure. ;)
The patch makes no difference over hibernates in the SMART logs.
It's still
On Wednesday 18 April 2007, Chuck Ebbert wrote:
Mark Lord wrote:
Mark Lord wrote:
With the patch applied, I don't see *any* new activity in those
S.M.A.R.T.
attributes over multiple hibernates (Linux suspend-to-disk).
Scratch that -- operator failure. ;)
The patch makes no
On Wednesday 18 April 2007, Tejun Heo wrote:
Mark Lord wrote:
Chuck Ebbert wrote:
Mark Lord wrote:
I'll patch it locally on my own machines, but what about the tens
of thousands of other Seagate notebook drive owners out there?
This is a problem with Seagate specifically, spinning
On 4/18/07, Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:
On Wednesday 18 April 2007, Chuck Ebbert wrote:
Mark Lord wrote:
Mark Lord wrote:
With the patch applied, I don't see *any* new activity in those
S.M.A.R.T.
attributes over multiple hibernates (Linux suspend-to-disk).
Bartlomiej Zolnierkiewicz wrote:
On Wednesday 18 April 2007, Chuck Ebbert wrote:
Mark Lord wrote:
Mark Lord wrote:
With the patch applied, I don't see *any* new activity in those
S.M.A.R.T.
attributes over multiple hibernates (Linux suspend-to-disk).
Scratch that -- operator failure. ;)
Stephen Clark wrote:
I tried this on 2.6.20.2 it applied to libata with some fuzz and I had
to manually edit libata.h
When I did a shutdown I still got the click/pop.
I also noticed the last thing displayed on the lcd before it goes blank is
Synchronizing SCSI Disks - then the click/pop.
HTH,
Stephen Clark wrote:
So this is the pop I hear on my new laptop that is using
libata=combined_mode
when I shut my system down. I didn't get the pop with the same disk
drive in an older
laptop that was only ide. It sounds like a relay closing or opening, but
is really my
drive head doing an
Tejun Heo wrote:
This really isn't a regression. It's been always like that with libata.
libata doesn't make devices go into standby mode and shutdown(8) does
it for libata. The problem here is that libata does issue
SYNCHRONIZE_CACHE on shutdown. So, the sequence of event is...
1.
Robert Hancock wrote:
Tejun Heo wrote:
This really isn't a regression. It's been always like that with libata.
libata doesn't make devices go into standby mode and shutdown(8) does
it for libata. The problem here is that libata does issue
SYNCHRONIZE_CACHE on shutdown. So, the sequence of
Tejun Heo wrote:
1. shutdown(8) issues SYNCHRONIZE_CACHE followed by STANDBY_NOW
2. kernel shutdown starts
3. libata shutdown issues SYNCHRONIZE_CACHE
4. power goes off
Okay, after some experimentatino, it's the STANDBY_NOW that
is causing the Power-Off_Retract_Count to increment on my
Mark Lord wrote:
Tejun Heo wrote:
1. shutdown(8) issues SYNCHRONIZE_CACHE followed by STANDBY_NOW
2. kernel shutdown starts
3. libata shutdown issues SYNCHRONIZE_CACHE
4. power goes off
Okay, after some experimentatino, it's the STANDBY_NOW that
is causing the Power-Off_Retract_Count to
Mark Lord wrote:
> Chuck Ebbert wrote:
>> Mark Lord wrote:
>>> I'll patch it locally on my own machines, but what about the tens
>>> of thousands of other Seagate notebook drive owners out there?
>>>
>>
>> This is a problem with Seagate specifically, spinning back up
>> on receipt of some command
Chuck Ebbert wrote:
Mark Lord wrote:
I'll patch it locally on my own machines, but what about the tens
of thousands of other Seagate notebook drive owners out there?
This is a problem with Seagate specifically, spinning back up
on receipt of some command after spindown?
No, they just seem
Mark Lord wrote:
>
> I'll patch it locally on my own machines, but what about the tens
> of thousands of other Seagate notebook drive owners out there?
>
This is a problem with Seagate specifically, spinning back up
on receipt of some command after spindown?
-
To unsubscribe from this list:
emisca wrote:
I can confirm this, I have a Seagate Momentus 5400.3 sata disk, and it
spins off, respin up and again off when I halt my notebook.
I had before this disk an IBM/Hitachi one, and it doesn't have this
behaviour.
Take a look at this bug report:
On Mon, 16 Apr 2007, Chuck Ebbert wrote:
> It looks like there are two problems here:
>
> (1) Some notebooks power off and back on when restarting.
If it happens just under Linux, this is something that really needs to be
addressed post-haste. Maybe someone should open a bug in bugzilla to help
Hi.
On 4/17/07, Chuck Ebbert <[EMAIL PROTECTED]> wrote:
(2) Linux (alone) gives a very muted pop on shutdown. This could
be from bad interaction with the shutdown command, or some
other reason (drive not given enough time to shut down?)
The noise is not very loud, maybe the head
2007/4/17, Chuck Ebbert <[EMAIL PROTECTED]>:
Jan Engelhardt wrote:
> On Apr 15 2007 12:53, Henrique de Moraes Holschuh wrote:
>> On Sat, 14 Apr 2007, Pavel Machek wrote:
>>> How common are notebooks that cut power to disks during reboot?
>> Assuming it also does this when running Windows, I'd
2007/4/17, Chuck Ebbert [EMAIL PROTECTED]:
Jan Engelhardt wrote:
On Apr 15 2007 12:53, Henrique de Moraes Holschuh wrote:
On Sat, 14 Apr 2007, Pavel Machek wrote:
How common are notebooks that cut power to disks during reboot?
Assuming it also does this when running Windows, I'd report it as
Hi.
On 4/17/07, Chuck Ebbert [EMAIL PROTECTED] wrote:
snip
(2) Linux (alone) gives a very muted pop on shutdown. This could
be from bad interaction with the shutdown command, or some
other reason (drive not given enough time to shut down?)
The noise is not very loud, maybe the head
On Mon, 16 Apr 2007, Chuck Ebbert wrote:
It looks like there are two problems here:
(1) Some notebooks power off and back on when restarting.
If it happens just under Linux, this is something that really needs to be
addressed post-haste. Maybe someone should open a bug in bugzilla to help
emisca wrote:
I can confirm this, I have a Seagate Momentus 5400.3 sata disk, and it
spins off, respin up and again off when I halt my notebook.
I had before this disk an IBM/Hitachi one, and it doesn't have this
behaviour.
Take a look at this bug report:
Mark Lord wrote:
I'll patch it locally on my own machines, but what about the tens
of thousands of other Seagate notebook drive owners out there?
This is a problem with Seagate specifically, spinning back up
on receipt of some command after spindown?
-
To unsubscribe from this list: send
Chuck Ebbert wrote:
Mark Lord wrote:
I'll patch it locally on my own machines, but what about the tens
of thousands of other Seagate notebook drive owners out there?
This is a problem with Seagate specifically, spinning back up
on receipt of some command after spindown?
No, they just seem
Mark Lord wrote:
Chuck Ebbert wrote:
Mark Lord wrote:
I'll patch it locally on my own machines, but what about the tens
of thousands of other Seagate notebook drive owners out there?
This is a problem with Seagate specifically, spinning back up
on receipt of some command after spindown?
Jan Engelhardt wrote:
> On Apr 15 2007 12:53, Henrique de Moraes Holschuh wrote:
>> On Sat, 14 Apr 2007, Pavel Machek wrote:
>>> How common are notebooks that cut power to disks during reboot?
>> Assuming it also does this when running Windows, I'd report it as a grave
>> bug to the vendor and
Jan Engelhardt wrote:
On Apr 15 2007 12:53, Henrique de Moraes Holschuh wrote:
On Sat, 14 Apr 2007, Pavel Machek wrote:
How common are notebooks that cut power to disks during reboot?
Assuming it also does this when running Windows, I'd report it as a grave
bug to the vendor and demand it to
On Sunday 15 April 2007 19:07, emisca wrote:
> I can confirm this, I have a Seagate Momentus 5400.3 sata disk, and it
> spins off, respin up and again off when I halt my notebook.
> I had before this disk an IBM/Hitachi one, and it doesn't have this
> behaviour.
>
> Take a look at this bug report:
On Apr 15 2007 12:53, Henrique de Moraes Holschuh wrote:
>On Sat, 14 Apr 2007, Pavel Machek wrote:
>> How common are notebooks that cut power to disks during reboot?
>
>Assuming it also does this when running Windows, I'd report it as a grave
>bug to the vendor and demand it to be fixed, or the
1 - 100 of 128 matches
Mail list logo
