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 (by claiming one of it's parameters is zero)? Obviously > it is now. Some of the other crashing complaints (complaints of > crashing only without media in a zip drive, for instance) seem > similar. Hmm, well I dont know of any "malicious hardware" masqurading as ATA disks actually, but that is a point to consider. The ZIP is not an ATA device and doesn't panic the atapi-fd driver neither with nor without a media inserted... > I agree that the real problem in my instance is that the phantom drive > shows up. If I can be any help on that issue, I'd be happy to boot > test code. I've committed code that shoudl fix some of there phantom drives.. > But my question is: would the same parameters passed to ad_print() > result from a pathalogical device (a broken compact flash, hard disk > or whathaveyou)? I put the fix in ad_attach() because I felt that > some other code might break ... but shouldn't we at least protect the > divide-by-zero ... or better reject devices of size zero at this > point. I can't imagine that zero sizes devices are very useful for > storing things. I've newer seen or heard about an ATA device with a zero size, so I think its a bit academic, but I'll keep it in mind.. -SørenReceived on Mon Sep 08 2003 - 06:14:26 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:21 UTC