diff --git a/en/releases/6.1R/todo.sgml b/en/releases/6.1R/todo.sgml index c1cde4d630..cee98da440 100644 --- a/en/releases/6.1R/todo.sgml +++ b/en/releases/6.1R/todo.sgml @@ -1,200 +1,331 @@ - + %navincludes; %includes; %developers; N/A"> Done"> In progress"> Needs testing"> Not done"> Unknown"> Deferred for future release"> ]> &header;

This is a list of open issues that need to be resolved for FreeBSD &local.rel;. If you have any updates for this list, please e-mail re@FreeBSD.org.

Show stopper defects for &local.rel;-RELEASE

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Issue Status Responsible Description
umount -f panics&status.wip;jeffr, ssouhlalpanics from race conditions.
UFS deadlocks on amd64&status.unknown;teggeSeen by Kris Kennaway and Peter Jeremy.
amd64 panics in ipv6 with date(1)&status.unknown;amd64 panics in ipv6 when the date is changed using date(1) or + ntpdate(1). This may be a MI issue.
dhclient causes ipv6 panics.&status.unknown;dougb has more details about this.
sparc64 instability.&status.unknown;Outstanding recurrent issues include:
+panic: uma_small_alloc: free page still has mappings!
+cpuid = 0
+KDB: enter: panic
+[thread pid 9124 tid 100318 ]
+Stopped at      kdb_enter+0x3c: ta              %xcc, 1
+db> wh
+Tracing pid 9124 tid 100318 td 0xfffff800f6fb2720
+panic() at panic+0x164
+uma_small_alloc() at uma_small_alloc+0x9c
+slab_zalloc() at slab_zalloc+0x98
+uma_zone_slab() at uma_zone_slab+0x12c
+uma_zalloc_bucket() at uma_zalloc_bucket+0x16c
+uma_zalloc_arg() at uma_zalloc_arg+0x374
+malloc() at malloc+0x114
+allocbuf() at allocbuf+0x208
+getblk() at getblk+0x598
+breadn() at breadn+0x58
+bread() at bread+0x20
+ffs_blkatoff() at ffs_blkatoff+0x64
+ufs_direnter() at ufs_direnter+0x444
+ufs_makeinode() at ufs_makeinode+0x460
+ufs_create() at ufs_create+0x30
+VOP_CREATE_APV() at VOP_CREATE_APV+0xb4
+vn_open_cred() at vn_open_cred+0x188
+vn_open() at vn_open+0x18
+kern_open() at kern_open+0x8c
+pen() at open+0x14
+syscall() at syscall+0x2dc
+-- syscall (5, FreeBSD ELF64, open) %o7=0x4034d5b8 --
+
+panic: trap: data access error
+cpuid = 1
+KDB: enter: panic
+[thread pid 2724 tid 100224 ]
+Stopped at      kdb_enter+0x3c: ta              %xcc, 1
+db> wh
+Tracing pid 2724 tid 100224 td 0xfffff8004e55a720
+panic() at panic+0x16c
+trap() at trap+0x3f0
+-- data access error %o7=0xc017392c --
+copyout() at copyout+0xb0
+memrw() at memrw+0x2a8
+devfs_read_f() at devfs_read_f+0x9c
+dofileread() at dofileread+0xa4
+read() at read+0x38
+syscall() at syscall+0x2d4
+-- syscall (3, FreeBSD ELF64, read) %o7=0x40339328 --
+
+(this one needs a port of
+
+1.117     +57 -33    src/sys/i386/i386/mem.c
+
+which marius is working on)
+
dhclient causes ipv6 panics.&status.unknown;dougb has more details about this.
sparc64 frequent hangs&status.unknown;no DDB break possible, so impossible to diagnose
serious sparc64 IPv6 panic&status.unknown;Triggered by just ping6'ing the box. gnn keeps promising to + look at this but hasn't found it yet. It may even be a MI + issue, the reporter of this bug only uses IPv6 with + sparc64.

Required features for &local.rel;-RELEASE

Issue Status Responsible Description

Desired features for &local.rel;-RELEASE

+ + + + + + + + + + + + + + + - +
Issue Status Responsible Description
updated hal and ath drivers &status.new; sam
fix ntpdate(1) bogus output on amd64.&status.unknown;roberto
improve sparc64 performance&status.unknown;What seem to be 4BSD scheduler bugs in 6.0 that + cause performance to be anomalously low in certain situations. + davidxu has expressed some interest in this problem.
devfs umount panic &status.new;   There is a race condition between device removal and devfs umounts that causes "Memory modified after free" panics. Can be reproduced by doing 'mdconfig -u' concurrently with unmounting a devfs instance.
/dev/kmem panic &status.new;   Kris has noticed panics on SMP machines when there was ABI breakage of libkvm and world was not rebuilt and utilities like fstat were used. This suggests panics can be caused by incorrect accesses to /dev/kmem.
KLDs on sparc64 &status.new;   On sparc64 machines with more than 4Gb memory KLDs are not usable and will panic the system. The problem is reportedly with how the KLDs are compiled, it only works if the code ends up below 4G.
Max RAM on sparc64 &status.new;   Maximum RAM on sparc64 appears to be limited to 16Gb.
make -jN &status.new;   Doing 'make -jN', then suspending/resuming it may result in make reporting it lost child process(es).
OpenBSM&status.deferred;&status.unknown; &a.rwatson; The integration of OpenBSM is waiting on some final licensing hurdles. Once those are cleared, it will be a very desirable feature for &local.rel;.
update sysinstall disk labeling &status.wip; &a.rodrigc; Sysinstall could use the same fixes recently made to fdisk so it plays nice with GEOM and disk labeling. This does not cause problems during install because nothing on the disk is mounted when its label is being manipulated but it can cause problems if sysinstall gets used on a live system to adjust labels on existing disks which sys-admins tend to do.

Documentation items that must be resolved for &local.rel;

Issue Status Responsible Description

Testing foci for &local.rel;-RELEASE

Issue Status Responsible Description

Stress Test Panics

The system is continuously being subjected to Peter Holm's Kernel Stress Test Suite. The following issues have recently been discovered from this test suite.

&stresstest; &footer;