Date: Tue, 27 Sep 2005 00:35:07 -0400 From: "Julian C. Dunn" <lists@aquezada.com> To: Billy Newsom <smartweb@leadhill.net> Cc: freebsd-stable@freebsd.org Subject: Re: 5.4-STABLE changes breaks IDE boot (was Re: 5.3 -> 5.4 breaks ATA (Intel ICH2)) Message-ID: <1127795707.10060.43.camel@jupiter.acf.aquezada.com> In-Reply-To: <43370A31.1080704@leadhill.net> References: <87y85nuqhy.fsf@beaker.data-secure.net> <4335D1D2.9060501@leadhill.net> <87r7bdt6o3.fsf@beaker.data-secure.net> <20050925142016.L7868@familysquires.net> <43370A31.1080704@leadhill.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2005-09-25 at 15:36 -0500, Billy Newsom wrote: > I would like to concur with this sighting. I will repeat it to emphasize > this for whoever can decipher this for bug fixes: > > 1. In recent 5-Stable > 2. The IDE controller, atapci0, > 3. seems to be detectected, but without a certain memory allocation > 4. namely, 0xfff0-0xffff > 5. while the other memory and I/O segments are detected fine. > > Furthermore, > 6. It won't boot on the affected machines. > 7. More than one controller is affected (ICH2, PIIX3, and possibly PIIX4) > 8. Mine, at least, boots fine to a July 4th 5-Stable. > > Here is an example I found from someone reporting a similar issue > (Julian Dunn) > > Look at this from his dmesg: > > *First* his good booting dmesg line: > atapci0: <Intel PIIX4 UDMA33 controller> port > 0xfff0-0xffff,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 2.1 on pci0 > > *Second* his non-booting dmesg line: > atapci0: <Intel PIIX4 UDMA33 controller> port > 0x376,0x170-0x177,0x3f6,0x1f0-0x1f > atapci0: Lazy allocation of 0x10 bytes rid 0x20 type 4 at 0 > 7 at device 2.1 on pci0 > > Can I point out the fact that these two lines (first from the good, > second from the bad dmesg) seem to say that atapci0 is not getting its > memory segment detected -- the segment at 0xfff0-0xffff. Here's a bit more information about the defect. I discovered this accidentally while testing out a -STABLE kernel built today. When I booted the -STABLE kernel, it went and autoloaded the old /boot/kernel/acpi.ko from the -RELEASE kernel, and the system would boot as normal. However, if I broke to the loader prompt and loaded the -STABLE kernel and its corresponding acpi.ko, the machine would fail to boot (as above, with the memory segment not being detected). Would this help anyone in filing a PR about the issue? - Julian -- [ Julian C. Dunn <jdunn@aquezada.com> * "You can throw confetti, ] [ WWW: www.aquezada.com/staff/julian * but you're still going ] [ PGP: 91B3 7A9D 683C 7C16 715F * through the motions, baby" ] [ 442C 6065 D533 FDC2 05B9 * - Aimee Mann ]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1127795707.10060.43.camel>