bugbusting:commonly_reported_issues

This is an old revision of the document!

Commonly reported FreeBSD issues

This is a list of the most commonly reported FreeBSD issues on the mailing lists. There is some overlap with the Well-Known PRs list and the PRs recommended for committer evaluation by the bugbusting team.

Items marked with :!: are of a severe (non-trivial) nature. Users should be very concerned with those items.

ATA/SATA

SCSI and SAS

ZFS

  • After booting into single-user and doing ZFS-related commands, then going back into multi-user, ZFS cannot find any pools to mount (zfs list returns no datasets available)
    • Workaround (confirmed): While in single-user, run /etc/rc.d/hostid start then /etc/rc.d/zfs start.
    • Workaround: Once back in multi-user, use zpool import -a to re-import all known ZFS pools. You should only have to do this once.

GEOM

  • :!: After making a gstripe(8), using newfs -U on the new stripe causes bad things to happen.

dump/restore

Kernel

  • Intel SpeedStep (EIST) incompatibilities with some motherboards
    • Symptom: kernel says things like calcru: negative runtime of -XXXXX usec for pid XX
    • Symptom: kernel says things like calcru: runtime went backwards from XXXXX usec to XXXXX usec for pid XX
    • Reference: http://lists.freebsd.org/pipermail/freebsd-questions/2006-October/133253.html
    • Workaround: Disable the EIST feature in the BIOS. You can still achieve ACPI-based processor frequency throttling by using powerd(8).
  • Scrambled or garbled kernel output, such as:
SdMaP0::  AP1 6C0P.U0 0#0M1B /Lsa utnrcahnesdf!e
da0: <SSMEPA:G AATPE  CSPTU3 3#617 5L3auLnWc hHePdS!3> }}}
    {{{
Sep  5 00:34:38 test kernel: Waiting (max 60
Sep  5 00:34:38 test kernel: seScyonncdisn)g  fdoirs kssy,s tvenmo dperso
creesmsa i`nsiynngc.e.r.' to3  stop...0 0 done
Sep  5 00:34:38 test kernel: All buffers synced. }}}
    * Reference: [[http://lists.freebsd.org/pipermail/freebsd-current/2007-October/078145.html]]
    * Reference: [[http://lists.freebsd.org/pipermail/freebsd-current/2007-November/079130.html]]
    * Reference: [[http://lists.freebsd.org/pipermail/freebsd-stable/2007-December/038727.html]]
    * Workaround (partial): Use `options PRINTF_BUFR_SIZE=256` in your kernel configuration.  This will decrease the amount of interspersed output, but will not entirely solve it.

  * <!> Panic occurs when a mounted device (USB, SATA, local image file, etc.) is removed
    * Workaround: Be sure to umount all filesystems before removing the physical device.
    * Fix: kris@ tells me this problem has been fixed in HEAD (on or prior to 2008/02/21).

  * <!> Panic occurs when `vm.kmem_size` or `vm.kmem_size_max` set to values larger than 1536M
    * Kernel will panic with a message that looks very similar to either of the following:
      {{{
panic: kmem_malloc(4096): kmem_map too small: 1073741824 total allocated
kmem_suballoc(): bad status return of 3 }}}
    * Limit is caused by a 2GB limit for kmem.
    * Affects i386 and amd64, regardless of how much physical memory is installed.
    * Greatly impacts ZFS stability.
    * Reference: [[http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042764.html]]
    * Reference: [[http://lists.freebsd.org/pipermail/freebsd-hackers/2008-May/024708.html]]
    * Fix: HEAD/8.0-CURRENT expands limitation to 512GB.  MFC of fix is unlikely.

  * System does not automatically reboot after a kernel panic
    * System reboots fine using `shutdown -r` or `reboot`.
    * Reference: [[http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042250.html]]
    * Reference: [[http://lists.freebsd.org/pipermail/freebsd-stable/2008-June/043011.html]]

=== ACPI ===

  * NULL (`\0`) characters in ACPI namespace results in kernel panic
    * Affects some MSI motherboards
    * Reference: [[http://bsd.haofood.net/2005/11/21/work-around-for-busted-rs-acpi-long/]]
    * Reference: [[http://lists.freebsd.org/pipermail/freebsd-stable/2008-April/041789.html]]

  * Some FreeBSD devices do not work, functionality is limited, or kernel panics early during boot stage; system works with ACPI disabled.
    * Check `dmesg(8)` to see if the kernel spits out any ACPI errors on boot.
    * Workaround: Check motherboard vendor's website for an updated BIOS, which may/may not fix applicable ACPI tables.

=== Firewall (pf, ipfilter, ipfw) ===

  * <!> `pf(4)`: "modulate state" appears to function oddly/incorrectly on FreeBSD
    * Reference: [[http://lists.freebsd.org/pipermail/freebsd-pf/2008-March/004223.html]]
    * Workaround (confirmed): Use "keep state" instead.
  * <!> `pf(4)`: State mismatches can occur when a TCP port is re-used before the state table entry is removed
    * Confirmed to exist on OpenBSD 4.2 as well; fixed in OpenBSD 4.3.
    * Reference: [[http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/125261]]
    * Reference: [[http://www.openbsd.org/plus43.html]]
    * Fix: [[http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/pf/net/pf.c]]
    * Fix: Committed to CURRENT on 2008/08/04.
    * Fix: Committed to RELENG_7 on 2008/08/11.

=== Network devices ===

  * Attansic/Atheros L1E NIC unsupported
    * Used on Asus P5Q-series motherboards
    * NIC does not work with `age(4)` due to too many differences; will require a new driver
    * Sent Yong-Hyeon PYUN an Asus P5Q SE motherboard which uses this NIC.
    * On 2008/10/25, Yong-Hyeon finished the code for the driver; it's called `ate(4)`, and is in no way "production-ready" (performance is not perfected).  The driver supports Atheros AR8121/AR8113/AR8114 chips, and hardware Tx checksum offloading is disabled on the AR8121 due to a hardware checksum offload bug.  TSO does work, however.
    * The above driver is not publicly available yet.

  * Marvel 88E8040 NIC unsupported
    * There is a [[http://people.freebsd.org/~yongari/msk/|patch available]] from Yong-Hyeon PYUN (yongari@gmail.com) that adds support for this NIC.  However, there are numerous problems which should be noted:
       * [[http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/044871.html|Ethernet link establishment does not work]] with this patch, severely limiting its usability
       * [[http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/044871.html|A lack of documentation for this NIC]] makes driver development difficult
       * At present, in the US market, only two computers use this NIC: the Dell Inspiron 1525 and the Dell XPS M1530.  There are no consumer network cards which use this chip.  This limits the ability for one to send hardware to Yong-Hyeon for development.

  * <!> `em(4)` watchdog timeouts on Intel 82573 NICs
    * Reference: [[http://e1000.sourceforge.net/doku.php?id=known_issues#v_l_e_tx_unit_hang_messages]]
    * Fix: [[http://people.freebsd.org/~koitsu/em_82573_manc_fix.zip|DOS-based EEPROM patcher from Intel]]
    * Fix: Boot Linux, install `ethtool(8)`, and follow [[http://e1000.sourceforge.net/doku.php?id=known_issues#v_l_e_tx_unit_hang_messages|this procedure]]
    * Troubleshooting: when using `em(4)` driver 6.7.3 or later, you can dump the contents of the EEPROM by doing `sysctl dev.em.X.debug=2` (0=em0, 1=em1, etc.).  You'll see something like this from the kernel:
      {{{
Interface EEPROM Dump:
Offset
0x0000  3000 8f48 d903 0d20 f746 0057 ffff ffff
0x0010  ffff ffff 026b 109a 15d9 109a 8086 80df
0x0020  0000 2000 7e54 0000 1000 00da 0004 2700
0x0030  6cc9 3150 0732 040b 2984 0000 c000 0706 }}}
    Since the above code prints things in little-endian-stored words, you need to look at the value at offset 0x1f (and not 0x1e like Linux `ethtool`!), which in the above example is value 0xdf.  Bit 0 should be set (1), which disables the power-saving feature that causes the problem.  In the above example, the bit is set, which means that the above NIC is not succeptable to the bug.

  * <!> `em(4)` watchdog timeouts on other NICs
    * Open PR: [[http://www.freebsd.org/cgi/query-pr.cgi?pr=122928]]

=== USB ===

  * Removal of a mounted USB device without umount'ing first results in a kernel panic
    * See above, re: "Kernel - Panic occurs when a mounted device (USB, SATA, local image file, etc.) is removed"

  * System freezes (briefly) when switching vcons (e.g. Alt-F2) or pressing !CapsLock/NumLock/ScrollLock
    * Reference: [[http://lists.freebsd.org/pipermail/freebsd-hackers/2006-March/015724.html]]
    * Reference: [[http://lists.freebsd.org/pipermail/freebsd-hackers/2008-May/024647.html]]
    * Workaround: Remove `kbdmux` from the kernel.
    * Workaround: Remove `atkbd` from the kernel.
    * Workaround: Plug in a PS/2 keyboard (even if not used).

  * Keyboard LEDs do not work

  * F-Lock key on Microsoft Natural Ergonomic Keyboard does not function on RELENG_7
    * Reference: [[http://lists.freebsd.org/pipermail/freebsd-usb/2007-July/003806.html]]
    * Patch: [[http://sonic.net/~artemb/freebsd/usb-hid.patch.gz]]

  * Modifier keys (Control/Alt/Shift) act as if they are stuck
    * Reference: [[http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041426.html]]

=== Bootstraps (BTX, boot2, and loader) ===

  * <!> Cannot boot FreeBSD from a USB device (flash, disk, etc.)
    * Reference: [[http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041112.html]]
    * Reference: [[http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041287.html]]

  * Loading of gzip'd mfsroot from `pxeboot(8)` causes loader reload/reset
    * Open PR: [[http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120127]]

  * <!> BTX crashes on start (screen continually scrolls registers or dumps registers then reboots)
    * Some systems behave badly when executing BIOS interrupts while in virtual 86 mode.  Use real mode instead.
    * Reference: [[http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/btx/btx/Makefile]] - see revision 1.19.10.1
    * Workaround: Download a snapshot ISO from [[http://pub.allbsd.org/FreeBSD-snapshots/]]
    * Fix: John Baldwin committed fixes to RELENG_[467] on March 18th, 2008.

  * <!> `loader` version 1.02 hangs, or prints
    {{{
Can't work out which disk we are booting from.
Guessed BIOS device 0xffffffff not found by probes, defaulting to disk0 }}}
    * Problem #1: v86 structure not initialised prior to being called
    * Problem #2: eflags register not initialised prior to vm86 requests (interrupts randomly disabled/enabled)
    * Reference #1: [[http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042650.html]]
    * Reference #2: [[http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044204.html]]
    * Fix #1: Committed to HEAD on 2008/03/10.  Revision 1.46.
    * Fix #1: Committed to RELENG_[67] on 2008/03/18.  Revisions 1.38.2.3 and 1.44.2.1.
    * Fix #2: Committed to HEAD on 2008/08/08.  Revision 1.47.
    * Fix #2: Committed to RELENG_[67] on 2008/08/15.  Revisions 1.38.2.4 and 1.44.2.2.

=== Other ===

  * When switching consoles (e.g. `Alt-F2` to switch to `ttyv1`), a 2-3 second delay is experienced
    * Often seen when using a USB keyboard on the VGA console, and with `atkbd/atkbdc/psm` enabled in the kernel.
    * Doesn't matter if "USB Legacy" is enabled in the BIOS or not.
    * I've personally spent some time tracking this down, and the issue is definitely with kbdmux.
    * Workaround: disable kbdmux in `loader.conf` -- see the `kbdmux(4)` man page for how to accomplish this.
  • bugbusting/commonly_reported_issues.1225887125.txt.gz
  • Last modified: 2008/11/05 12:12
  • by JeremyChadwick