When using a serial console (either "-Dh -S115200" or "-h -S115200") on an Intel D2500CC, the system will hang during boot, shortly after the root filesystem is loaded. More specifically, it will hang (not panic) after printing "Setting hostuuid", and if hostid is disabled in rc.conf, it will hang after printing "Entropy harvesti" (without the "ng" at the end), coincidentally the exact same number of printed characters (16) as would have been printed when trying to set the host UUID. This leads me to believe it's a buffering issue. According to the "Technical Product Specification" from Intel, the board uses a Winbond W83627DHG-P for legacy, including serial, I/O. In dmesg these appear as: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 3 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 4 on acpi0 uart2: <16550 or compatible> port 0x2e8-0x2ef irq 3 on acpi0 uart3: <16550 or compatible> port 0x2e0-0x2e7 irq 4 on acpi0 The problem also occurs with any combination of either amd64 or i386 and FreeBSD 8.2-RELEASE or 9.0-RELEASE. Fix: No known fix. As there are also issues with the GPU on the new Intel Atom boards (see amd64/166639: [boot] Syscons issue Intel D2700) this leaves minimal options for administration of such boards running FreeBSD. Aside from network administration (e.g. sshd), you may be stuck installing a PCI graphics card for installation or configuration if you are unable to do so via the network. How-To-Repeat: Boot FreeBSD 9.0 or 8.2, either amd64 or i386, with a serial console configured (in my case, "-h -S115200" in /boot.config) on a D2500CC or, presumably, any board with a Winbond W83627DHG-P for serial I/O. I also configured a serial tty for the same line at 115200 baud in /etc/ttys, though I don't believe it had any effect as I never got to a login prompt.
I have this same problem in pfSense 2.0.1 (FreeBSD 8.1-RELEASE-p6). It seems that if I enter ddb using real (usb) keyboard, I can control it via serial console. Resuming execution will print more characters and stop. This can be repeated couple of times until entering ddb will cause what looks like a freeze where not even numlock works but repeatedly breaking will get me back to usable ddb. I have disabled all non-essential devices in bios (everything except usb and serial) and tried booting into single user mode.
And here is a verbose bootlog and some ddb output: https://gist.github.com/2568016 According to "show intrcnt" at least serial interrupts seem to be working.
Booting to 9.0R/i386 without serial console works for me (D2500CCE). Launching "getty std.115200 ttyu0" after boot prints exactly "\nFreeBSD/i386 " and serial port hangs but the system is still usable. vmstat -i reports single interrupt that wasn't there before running getty. interrupt total rate irq3: uart0 1 0 irq18: uhci2 3038 0 irq20: hpet0+ 20 0 irq23: uhci0 ehci0 4224 0 cpu0:timer 381634 66 irq256: hdac0 18 0 irq257: em0:rx 0 4267 0 irq258: em0:tx 0 13 0 irq259: em0:link 2 0 irq263: ahci0 53 0 cpu1:timer 79074 13 Total 472344 81
Problem can be worked around by using polled mode. On 9.x one would first need to merge r234194 which completes polling support. Unfortunately I wasn't able to find a way to enable polling, my naive attemt at setting hint.uart.0.irq=-1 failed, which forced me to apply crude hack attached to this message. Once booted, console works somewhat slowly but is usable. Perhaps it can be improved by increasing polling rate. On Tue, May 1, 2012 at 10:51 PM, Marcin WiÅnicki <mwisnicki@gmail.com> wrote: > Booting to 9.0R/i386 without serial console works for me (D2500CCE). > > Launching "getty std.115200 ttyu0" after boot prints exactly > "\nFreeBSD/i386 " and serial port hangs but the system is still > usable. > > vmstat -i reports single interrupt that wasn't there before running getty. > > interrupt              total    rate > irq3: uart0               1      0 > irq18: uhci2             3038      0 > irq20: hpet0+             20      0 > irq23: uhci0 ehci0          4224      0 > cpu0:timer             381634     66 > irq256: hdac0             18      0 > irq257: em0:rx 0           4267      0 > irq258: em0:tx 0            13      0 > irq259: em0:link            2      0 > irq263: ahci0             53      0 > cpu1:timer             79074     13 > Total               472344     81
Just a note to say that I'm seeing this too. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
There is a workaround for this problem. Just add hint.apic.0.disabled="1" into /boot/device.hints or /boot/loader.conf in order to disable APIC support (see man apic) and enable legacy PIC driver. The problem itself has something to do with invalid interrupt config on Intel D2500CC (or similar). Legacy atpic driver just ignores incorrect settings for interrupt handling ( trig == INTR_TRIGGER_EDGE && pol == INTR_POLARITY_LOW) || (trig == INTR_TRIGGER_LEVEL && pol == INTR_POLARITY_HIGH ) while apic forcing these incorrect settings, resulting interrupts not being handled properly.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped