It seems Hiroyuki Aizu wrote:
> Hi.
>
> The original ata_reset() lost ATA-master drive and remove main file system
> after suspend/resume. Of cource it occors panic!
> I think that the ata_reset() in ata-lowlevel.c is bogus and I can not
> understand the code. So I study ATA and rewrite ata_reset(
> Date: Thu, 16 Oct 2003 23:17:47 +0900
> From: Hiroyuki Aizu <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
>
> This is a multi-part message in MIME format.
>
> --Multipart_Thu__16_Oct_2003_23_17_47_+0900_0865e200
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
>
At Thu, 16 Oct 2003 23:17:47 +0900,
Hiroyuki Aizu wrote:
>
> [1 ]
> Hi.
>
> The original ata_reset() lost ATA-master drive and remove main file system
> after suspend/resume. Of cource it occors panic!
> I think that the ata_reset() in ata-lowlevel.c is bogus and I can not
> understand the code.
It seems David Gilbert wrote:
> Soren> Uhm, I'm working on finding the real problem, and I'd like that
> Soren> to be the solution. However the above may be a good workaround
> Soren> for those bitten by this...
>
> Well... is it not possible for malicious hardware to claim to have
> zero blocks (
> "Soren" == Soren Schmidt <[EMAIL PROTECTED]> writes:
Soren> It seems David Gilbert wrote:
>> I submitted kern/56572 a few minutes ago. It patches ata-disk.c to
>> reject a disk that has zero blocks.
>>
>> This is a good thing ... malicious or broken disks (compact flash,
>> whatever) shoul
It seems David Gilbert wrote:
> I submitted kern/56572 a few minutes ago. It patches ata-disk.c to
> reject a disk that has zero blocks.
>
> This is a good thing ... malicious or broken disks (compact flash,
> whatever) shouldn't crash machines.
>
> But in this case, the detected ad3 doesn't exi
