Re: PATCH for ATAng
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() completely. New device detect algorism using ata command ATA_IDENTIFY_DEVICE and ATA_IDENTIFY_PACKET_DEVICE for judge ATA and ATAPI devices. This patch works fine with my TOSHIBA Libretto L5. But not yet test ATAPI devices and ATA-slave channel. Maybe there is need to adjust wait DELAY time. Please test and replace ata_reset(). Hold your horses just a bit please, I suggest that you try to understand the current code first, then we can talk about improving it.. I hope this solve ATAng troubles. It will probably solve some troubles but I'll bet it will produce quite a few new ones :) Anyhow I'll look at your code asap, but from a quick look it shows that you havn't looked seriously at the existing code, and that is not a good sign in my book sorry... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PATCH for ATAng
At Thu, 16 Oct 2003 23:17:47 +0900, Hiroyuki Aizu wrote: [1 text/plain; US-ASCII (7bit)] 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() completely. New device detect algorism using ata command ATA_IDENTIFY_DEVICE and ATA_IDENTIFY_PACKET_DEVICE for judge ATA and ATAPI devices. This patch works fine with my TOSHIBA Libretto L5. But not yet test ATAPI devices and ATA-slave channel. Maybe there is need to adjust wait DELAY time. Please test and replace ata_reset(). I hope this solve ATAng troubles. -- Hiroyuki Aizu [2 ata-lowlevel.c.diff application/octet-stream (base64)] This patch fixes resume problem of my laptop (Toshiba Tecra). Thanks, /\ Hidetoshi Shimokawa \/ [EMAIL PROTECTED] PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PATCH for ATAng
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 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() completely. New device detect algorism using ata command ATA_IDENTIFY_DEVICE and ATA_IDENTIFY_PACKET_DEVICE for judge ATA and ATAPI devices. This patch works fine with my TOSHIBA Libretto L5. But not yet test ATAPI devices and ATA-slave channel. Maybe there is need to adjust wait DELAY time. Please test and replace ata_reset(). I hope this solve ATAng troubles. I applied your patch and rebuilt my kernel on my ThinkPad T30 and the behavior is changed, but not really improved. Now, instead of hanging after ata0: resetting devices .. I now get: ata0: Resetting devices .. GEOM: destroy disk ad0 dp=0xc4945d70 ad0: WARNING - removed from configuration done ata1: resetting devices .. ata1: check for dev existence:lsb=00 msb=00 ata1: check for dev existence:lsb=00 msb=00 done I have only one ATA device which is master on ata0. (ad0). Thanks for trying. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patch for ATAng bug
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 exist. The machine is a laptop with a drive on channel 0 and a DVD+R on channel 1. If the DVD is removed, the phantom ad3 doesn't show up, either. ... so that issue with ATAng is unresolved. Uhm, I'm working on finding the real problem, and I'd like that to be the solution. However the above may be a good workaround for those bitten by this... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patch for ATAng bug
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) shouldn't crash machines. But in this case, the detected ad3 doesn't exist. The machine is a laptop with a drive on channel 0 and a DVD+R on channel 1. If the DVD is removed, the phantom ad3 doesn't show up, either. ... so that issue with ATAng is unresolved. 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. 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. 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. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patch for ATAng bug
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øren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
