Re: 5.3-RELEASE TODO

From: Scott Long <scottl_at_freebsd.org>
Date: Sat, 30 Oct 2004 16:39:22 -0600
Emanuel Strobl wrote:
> Am Freitag, 29. Oktober 2004 09:41 schrieb Scott Long:
> 
>>This is an automated weekly mailing of the FreeBSD 5.3 open issues list.
>>The live version of this list is available at:
>>
>>    http://www.FreeBSD.org/releases/5.3R/todo.html
>>
>>Automated mailing of this list will continue through the release of
>>FreeBSD 5.3
>>
>>
>>                          FreeBSD 5.3 Open Issues
>>
>>                                Open Issues
>>
>> This is a list of open issues that need to be resolved for FreeBSD 5.3. If
>> you have any updates for this list, please e-mail re_at_FreeBSD.org.
>>
>>Issues that require investigation
>>
>> +------------------------------------------------------------------------+
>>
>> | Issue |   Status    | Responsible |            Description             |
>> |-------+-------------+-------------+------------------------------------|
>> |
>> |       |             |             | More 'wedging' problems have been  |
>> |       |             |             | reported with specific if_em       |
>> |       |             |             | hardware. The hardware found in    |
>> |
>> | if_em | In progress | Bruce M.    | the IBM T-41 seems to be a         |
>> | wedge |             | Simpson     | suspect. Removing ALTQ support     |
>> |
>> |       |             |             | from the driver might help this    |
>> |       |             |             | problem, but reports are           |
>> |       |             |             | inconsistent.                      |
>>
>> +------------------------------------------------------------------------+
>>
>>Show stopper defects for 5.3-RELEASE
>>
>> +------------------------------------------------------------------------+
>>
>> |     Issue      |   Status    |  Responsible   |      Description       |
>> |----------------+-------------+----------------+------------------------|
>> |
>> |                |             |                | Attaching GDB to a     |
>> |                |             |                | threaded process will  |
>> |                |             |                | leave the process in   |
>> |                |             |                | an unkillable state.   |
>> |                |             |                | Rebooting the machine  |
>> |
>> | Threaded       |             |                | is the only way to     |
>> | application    |             |                | recover from this.     |
>> | get stuck in   |             |                | This is easily         |
>> | an unkillable  | In progress | David Xu       | triggered when a KDE   |
>> | state when     |             |                | app crashes and KDE    |
>> | touched by GDB |             |                | automatically attaches |
>> |
>> |                |             |                | GDB to it to extract a |
>> |                |             |                | stack trace. A         |
>> |                |             |                | candidate fix is in    |
>> |                |             |                | 6-CURRENT. More        |
>> |                |             |                | testing and review is  |
>> |                |             |                | needed.                |
>> |
>> |----------------+-------------+----------------+------------------------|
>> |
>> |                |             |                | There have been        |
>> |                |             |                | reports that, under    |
>> |                |             |                | extremely high load,   |
>> |                |             |                | the tcp_output()       |
>> |                |             |                | routine may appear to  |
>> |                |             |                | run for extended       |
>> |                |             |                | periods, resulting in  |
>> |                |             |                | the appearance of a    |
>> |                |             |                | hang for an extended   |
>> |                |             |                | period (up to 30       |
>> |
>> | Reports of     |             |                | minutes), followed by  |
>> | TCP-related    |             |                | recovery. This may be  |
>> | instability    |             | George V.      | a result of a bug in   |
>> | under          |             | Neville-Neil,  | the TCP selective      |
>> | extremely high | In progress | Robert Watson, | acknowledgement        |
>> | load; possibly |             | Scott Long     | implementation         |
>> | related to     |             |                | introduced following   |
>> | SACK           |             |                | 5.2; the release       |
>> |
>> |                |             |                | engineering team is    |
>> |                |             |                | currently working with |
>> |                |             |                | the submitters to      |
>> |                |             |                | diagnose the problem.  |
>> |                |             |                | Depending on the       |
>> |                |             |                | nature of the problem, |
>> |                |             |                | it may be appropriate  |
>> |                |             |                | to release with SACK   |
>> |                |             |                | disabled, or to        |
>> |                |             |                | correct the bug prior  |
>> |                |             |                | to 5.3.                |
>>
>> +------------------------------------------------------------------------+
>>
> 
> 
> Showstoppers:
> 
> What about misc/72895, i386/73251 and misc/72896? The latter is not that 
> critical but GEOM_GPT really has edges on i386 which aren't suitable for 
> -stable! Removing GEOM_GPT from GENERIC would be one solution IMO, fixing of 
> course was even better, but I can't help.
> And then there's kern/71355 which has been closed without any improovement. 
> The opposite: I can confirm that this also applies to the sil3114 chipset 
> when the BIOS (of the PCI Card (Dawicontrol DC-154))) is enabled (so booting 
> from it is possible) and two drives are set up as mirror!
> 
> -Harry

72895 is indeed serious, but it doesn't prevent a normal install so long 
and you specifically avoid the problem.  Unfortunately there are no 
patches attached to this PR, so it's hard for us to evaluate how hard it
would be to fix it.  I probably should have landed on the TODO list a 
long time ago, and I'll make sure it gets on the 5.3 TODO list.  But 
again it's not a show-stopper because it doesn't prevent a normal 
install from succeeding.

73251 is strange.  No one that I've seen can possibly imagine why ACPI
would affect GPT.  But again, GPT is not the normal way to install and
boot an i386.  While I know of a few Intel systems that have EFI and GPT
for i386, MBR partitioning still works.

72896 is another GPT one, and again GPT is just not the predominate way
to deal with i386.  I'd really like to see these fixed for 5.4.

So I don't want to discount your concern, but given the very small user
base that is concerned about GPT, it's hard to justify delaying the
release further for these bugs.

Scott
Received on Sat Oct 30 2004 - 20:41:17 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:20 UTC