Date: Sat, 30 Oct 2004 23:46:16 +0200 From: Emanuel Strobl <Emanuel.Strobl@gmx.net> To: freebsd-current@freebsd.org, re@freebsd.org Cc: current@freebsd.org Subject: Re: 5.3-RELEASE TODO Message-ID: <200410302346.18306.Emanuel.Strobl@gmx.net> In-Reply-To: <200410290741.i9T7f8DW095035@pooker.samsco.org> References: <200410290741.i9T7f8DW095035@pooker.samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart4599725.xsNb84ZYf4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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@FreeBSD.org. > > Issues that require investigation > > +-----------------------------------------------------------------------= =2D+ > > | Issue | Status | Responsible | Description = | > |-------+-------------+-------------+-----------------------------------= =2D| > | > | | | | 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. = | > > +-----------------------------------------------------------------------= =2D+ > > Show stopper defects for 5.3-RELEASE > > +-----------------------------------------------------------------------= =2D+ > > | Issue | Status | Responsible | Description = | > |----------------+-------------+----------------+-----------------------= =2D| > | > | | | | 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. = | > | > |----------------+-------------+----------------+-----------------------= =2D| > | > | | | | 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. = | > > +-----------------------------------------------------------------------= =2D+ > Showstoppers: What about misc/72895, i386/73251 and misc/72896? The latter is not that=20 critical but GEOM_GPT really has edges on i386 which aren't suitable for=20 =2Dstable! Removing GEOM_GPT from GENERIC would be one solution IMO, fixing= of=20 course was even better, but I can't help. And then there's kern/71355 which has been closed without any improovement.= =20 The opposite: I can confirm that this also applies to the sil3114 chipset=20 when the BIOS (of the PCI Card (Dawicontrol DC-154))) is enabled (so bootin= g=20 from it is possible) and two drives are set up as mirror! =2DHarry --nextPart4599725.xsNb84ZYf4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBhAuqBylq0S4AzzwRAig9AJ0alBY1S717WwwDem8iXxWXXhPE1QCeJmBe s72VmweEIpvHc/9/m+zn4c4= =ur9y -----END PGP SIGNATURE----- --nextPart4599725.xsNb84ZYf4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410302346.18306.Emanuel.Strobl>