5.2-RELEASE TODO

[John Baldwin]

On 02-Dec-2003 Scott Long wrote:
> On Tue, 2 Dec 2003, Greg 'groggy' Lehey wrote:
>> On Monday,  1 December 2003 at 10:01:23 -0500, Robert Watson wrote:
>> > This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list.
>> >
>> > Show stopper defects for 5.2-RELEASE
>> >
>> >  +------------------------------------------------------------------------+
>> >  |   Issue   |  Status   |Responsible |            Description            |
>> >  |-----------+-----------+------------+-----------------------------------|
>> >  |           |           |            |The new i386 interrupt code        |
>> >  |ACPI kernel|           |            |requires that ACPI be compiled into|
>> >  |module     |In progress|John Baldwin|the kernel if it to be used. Work  |
>> >  |           |           |            |is underway to restore the ability |
>> >  |           |           |            |to load it as a module.            |
>> >  |-----------+-----------+------------+-----------------------------------|
>>
>> I'm currently investigating ACPI problems on a dual processor Intel
>> motherboard (re@ knows about this).  It looks as if the new code is
>> much fussier than the old code about the quality of the motherboard
>> BIOS: this machine runs fine on 5.1, but won't finish booting on
>> 5.2-BETA.  Yes, this is probably an ACPI bug, but users aren't going
>> to see it that way: if we release a 5.2 which won't boot on a lot of
>> machines, people are going to blame 5.2, not the machine.  I think we
>> should ensure that there's at least a fallback for machines with
>> broken ACPI.
> 
> This argument is exactly why I added the 'disable acpi' option in the boot
> loader menu.  Of course, we STILL need to get good debugging information
> from you as to why you get a Trap 9 when ACPI is disabled.  This is the
> more important issue.

This is actually a known issue on Intel motherboards.  Somehow we broke
something in our bios32 code.  4.x works fine using the BIOS to enumerate
PNP BIOS devices, but 5.x (including 5.0 and 5.1) get a GPF (Trap 9)
with the code segment set to 0x58 trying to enumerate the last PNPBIOS
device.  Somehow the BIOS routine jumps off into lala land where it
eventually traps.  I dumped the BIOS and dissassembled and tried to walk
it to figure out how it was breaking but couldn't see anything obvious.

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/