Date: Tue, 30 Jan 96 22:35 WET From: uhclem@nemesis.lonestar.org (Frank Durda IV) To: joerg_wunsch@uriah.heep.sax.de, bugs@freebsd.org Cc: amora@obelix.cica.es, uhclem@nemesis.lonestar.org Subject: Re: Jesus' matcd problem - looks like hardware to me Message-ID: <m0thUGq-000CPOC@nemesis.lonestar.org>
next in thread | raw e-mail | index | archive | help
[2]Now, that was detailed enough, i think. It happens here: [2] *addr++=inb(port+DATA); [2] ^^^^^^^^^^^^^^^^^^^^^^^ [2] Frank, any clues? Uh, yes and no. First thanks for Ccing me. I am not getting replies from the original poster for some reason, so the info in your reply is all I had sent directly to me that was new to go on. Since this was reported, I finally got the 2.1 disc (Thanks Jordon!) and have downloaded mc (downloaded from the 2.1 port just like a normal user would), and compiled mc on a very plain 2.1.0R system (no X). Installed mc (make install) and rebooted. I then did the following: (being incredibly precise about key sequences) boot: kernel.GENERIC (the 2.1 kernel boots and I see that matcd is Version 1(26) 18-Oct-95 as it should be) login: root password: password # cd / # mount -t cd9660 /dev/matcd0a /cdrom # mc <DOWN-ARROW><DOWN-ARROW><ENTER> (select /cdrom) <DOWN-ARROW> (six times) and <ENTER> (select ports) <PAGE-DOWN><PAGE-DOWN> (pointing at README) <F3> (this is where Jesus got the panic, but I got:) File: README Col 0 500 bytes 100% This is the FreeBSD Ports Collection. Please refer to the FreeBSD handbook on what to do with them. ... and a screen of the README contents. Now I type <F10><F10><ENTER> Back at #. So, no crash here. I tried this repeatedly, both on a custom kernel and on the GENERIC kernel. My test system was a 486DX-33, 128K L2 Cache, 12 Meg RAM, 1.2Gig IDE, two 1.4 (really 2.8)Meg floppies, one CR-563 connected to a SoundBlaster 16 (no sound support configured), one SMC 8013 ethernet (wrong IRQ set while running GENERIC kernel and it kept complaining about that), and a WD 90C31-based video adapter with 1Meg RAM. (I can remove the cache if you like, but I don't think it matters.) I also tried CR-562 drives with three different firmware levels. No crash. Again, I do not have the precise drive firmware revision Jesus has. The location in the above code snippet is the loop that actually transfers the data to an address that was bounds-checked for validity earlier before the read operation was even started. The only way that more than 2048 bytes could be read (assuming no drive malfunction) is if the "c" partition was opened, which causes the drive to read 2532 byte sectors. This is intentional. Partition "c" must never be mounted. So at this point, it looks like a local hardware problem to me. I suggest that Jesus add a loop to count the number of bytes actually read during each sector read (reset counter at start of loop) and printf the count on each byte read if the count is above 2046 or so (to keep it from being too noisy). It is possible that the firmware he has in the system has a bug and the drive returns more data than it should, which could cause a GPF, but such an action would break the Windows driver that also reads bytes until the drive says "All Done" as matcd does. I was planning to change the way this loop was done anyway to improve speed (the 6x TEAC drive bogs badly here) and simply pull in the expected number of bytes and deal with any excess later, but I really can't blame the current implementation as the cause of this reported failure since it won't fail here. Frank Durda IV <uhclem@nemesis.lonestar.org>|"Your choice: run FreeBSD or uhclem%nemesis@rwsystr.nkn.net | or Bob-Pro(TM). See? That ^------(this is the fastest route)| wasn't a tough choice." or ...letni!rwsys!nemesis!uhclem | (C) July 1995 FDIV
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0thUGq-000CPOC>