> >
> > Public description text is just "Please see comments."
> >
> > Was this a software corruption? That is, the root filesystem became
> > corrupted?
> > Or was it a hardware corruption / defect? That is, something like
> > "the ATA HDD became unusable, after using the new ata/dadk/cmdk code
> > that implements ata power management"?
>
> Hi Juergen,
> there are two other bugs referred to in the report:
>
> 6397774 marrakesh often hangs in suspend-state 33
> 6455736 ata/dadk/cmdk should support DDI_SUSPEND/DDI_RESUME
>
>
> and the evaluation indicates that 6398361 was tentatively
> assumed to have been resolved along the way with 6455736.
>
> This is an excerpt from the comments:
>
> My guess is that this corruptions is due to a disk driver problem
> (also the likely cause of 6397774). If the driver doesn't properly
> suspend, or disk activity is attempted _after_ the driver is suspended,
> I believe that corruption can occur.
This was a project bug found while developing suspend/resume on x86.
At that time, a lot of the test system was unstable as we were making
drivers and various other components try to successfully suspend and
resume.
In this case, a set of tests to read and write the disk caused data
to become corrupt (in one case the OS wouldn't boot). Around the same
time, we obtained some assistance from the team in Beijing in updating
the driver to what it is now.
>
>
>
> > I'm asking because a "Western Digital WD1000BB" ATA HDD appears to
> > have died after the box was bfu'ed to current onnv-gate bits,
> > which are containing the changes for "6455736 ata/dadk/cmdk should
> > support DDI_SUSPEND/DDI_RESUME" as part of the "PSARC/2005/469 X86
> > Energy Star compliance" putback. (The "Western Digital WD1000BB"
> > ATA HDD has been frequently spinning down, and the BIOS doesn't
> > detect the HDD any more) And a replacement HDD is making similar
> > strange noises (HDD stops and restarts) during S-x86 kernel boot
> > time, which I've now traced to the ATC_STANDBY_IM 0xe0 command in
> > the ata_power() entry point.
>
> If you bfu to the night before Randy's putback does the issue
> go away? Can you bfu to the night before?
I would expect so, as this item was added to the aformentioned
driver with the suspend/resume putback. I was also asked by Juergen
to provide what I know about this implementation, and it does appear
is if ATC_IDLE_IMMED would have been a better choice. I would like to
test it against a suspend/resume cycle.
Juergen- does this happen only on boot, or does it happen frequently
while running?
---- Randy
>
>
>
> James C. McPherson
> --
> Senior Kernel Software Engineer, Solaris
> Sun Microsystems
> _______________________________________________
> driver-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/driver-discuss
>
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
