From owner-freebsd-i386@FreeBSD.ORG Sun Jul 30 17:40:15 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D94216A4E0 for ; Sun, 30 Jul 2006 17:40:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 498AE43D46 for ; Sun, 30 Jul 2006 17:40:13 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k6UHeD9X054811 for ; Sun, 30 Jul 2006 17:40:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k6UHeDrI054808; Sun, 30 Jul 2006 17:40:13 GMT (envelope-from gnats) Resent-Date: Sun, 30 Jul 2006 17:40:13 GMT Resent-Message-Id: <200607301740.k6UHeDrI054808@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, MArtin Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B27116A4DD for ; Sun, 30 Jul 2006 17:37:33 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 255EF43D45 for ; Sun, 30 Jul 2006 17:37:33 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k6UHbWhh010332 for ; Sun, 30 Jul 2006 17:37:32 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k6UHbWEB010314; Sun, 30 Jul 2006 17:37:32 GMT (envelope-from nobody) Message-Id: <200607301737.k6UHbWEB010314@www.freebsd.org> Date: Sun, 30 Jul 2006 17:37:32 GMT From: MArtin To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: i386/101062: Freeze on detect Intel 900 VGA on boot with ACPI X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 17:40:15 -0000 >Number: 101062 >Category: i386 >Synopsis: Freeze on detect Intel 900 VGA on boot with ACPI >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Jul 30 17:40:12 GMT 2006 >Closed-Date: >Last-Modified: >Originator: MArtin >Release: 6.1 >Organization: fbinet >Environment: FreeBSD sam.local 6.1-RELEASE-p3 FreeBSD 6.1-RELEASE-p3 #4: Sun Jul 30 17:51:36 CEST 2006 root@sam.local:/usr/obj/usr/src/sys/SAM i386 >Description: I have Samsung Q30 plus, Freeze on detect VGA on boot with ACPI but without going without right VGAcard intel 900 The bios is uptodate http://notebook.samsung.de/article.asp?artid=B5EBC2DD-17F8-43A6-8D6D-B4222464CA1D&show=specs Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.1-RELEASE-p3 #4: Sun Jul 30 17:51:36 CEST 2006 root@sam.local:/usr/obj/usr/src/sys/SAM Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1.20GHz (1196.14-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 Features=0xafe9f9ff Features2=0x180 AMD Features=0x100000 real memory = 1332609024 (1270 MB) avail memory = 1296105472 (1236 MB) wlan: mac acl policy registered kbd1 at kbdmux0 cpu0 on motherboard pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 0.3 (no driver attached) agp0: port 0x1800-0x1807 mem 0xe8000000-0xefffffff,0xe0000000-0xe007ffff irq 10 at device 2.0 on pci0 agp0: detected 8060k stolen memory agp0: aperture size is 128M pci0: at device 2.1 (no driver attached) uhci0: port 0x1820-0x183f irq 10 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1840-0x185f irq 5 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1860-0x187f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xe0100000-0xe01003ff at device 29.7 on pci0 $PIR: No matching entry for 0.29.INTD ehci0: Could not allocate irq device_attach: ehci0 attach returned 6 pcib1: at device 30.0 on pci0 pci2: on pcib1 cbb0: at device 3.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: at device 3.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 fwohci0: mem 0xe0203000-0xe02037ff irq 5 at device 3.2 on pci2 fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:f0:41:20:0b:51:ad fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 sbp0: on firewire0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:f0:0b:51:ad fwe0: Ethernet address: 02:00:f0:0b:51:ad fwe0: if_start running deferred for Giant fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) bfe0: mem 0xe0200000-0xe0201fff irq 5 at device 5.0 on pci2 miibus0: on bfe0 bmtphy0: on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: Ethernet address: 00:00:f0:7a:29:42 iwi0: mem 0xe0202000-0xe0202fff irq 11 at device 7.0 on pci2 iwi0: Ethernet address: 00:12:f0:dd:a6:98 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff mem 0xe0100c00-0xe0100dff,0xe0100800-0xe01008ff irq 11 at device 31.5 on pci0 pcm0: pci0: at device 31.6 (no driver attached) pmtimer0 on isa0 orm0: at iomem 0xd8000-0xdbfff,0xdc000-0xdffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (memory) unknown: can't assign resources (memory) unknown: can't assign resources (irq) ums0: Microsoft Microsoft Notebook/Mobile Optical Mouse 2.0, rev 1.10/2.00, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. Timecounter "TSC" frequency 1196143713 Hz quality 800 Timecounters tick every 1.000 msec ad0: 38147MB at ata0-master UDMA100 Trying to mount root from ufs:/dev/ad0s2a iwi0: Please load firmware iwi0: link state changed to UP drmsub1: mem 0xf0000000-0xf7ffffff,0xe0080000-0xe00fffff at device 2.1 on pci0 info: [drm] AGP at 0xe8000000 128MB info: [drm] Initialized i915 1.2.0 20041217 ehci0: mem 0xe0100000-0xe01003ff at device 29.7 on pci0 $PIR: No matching entry for 0.29.INTD ehci0: Could not allocate irq device_attach: ehci0 attach returned 6 root@sam:/home/happy# >How-To-Repeat: Th sam problem with Current BootOnly Freebsd 7 , >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-i386@FreeBSD.ORG Mon Jul 31 09:55:49 2006 Return-Path: X-Original-To: freebsd-i386@FreeBSD.org Delivered-To: freebsd-i386@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E57D816A4DA; Mon, 31 Jul 2006 09:55:49 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FE5143D70; Mon, 31 Jul 2006 09:55:49 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id BC08E5A1D50; Mon, 31 Jul 2006 19:55:47 +1000 (EST) Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k6V9tgOm028834; Mon, 31 Jul 2006 19:55:44 +1000 Date: Mon, 31 Jul 2006 19:55:42 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Jo Rhett In-Reply-To: <200607252036.k6PKanFd072593@www.freebsd.org> Message-ID: <20060731191302.S1172@epsplex.bde.org> References: <200607252036.k6PKanFd072593@www.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-i386@FreeBSD.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 09:55:50 -0000 On Tue, 25 Jul 2006, Jo Rhett wrote: >> Description: > For our motherboard, "Serial A" in hardwired on the board with a 9-pin connector. "Serial B" is a normal serial connector that can be wired anywhere. Rackable uses this connector to connect to their out-of-band management interface. > > So in the BIOS configuration, we assign COM1 = "Serial B" and COM2 = "Serial A". This works perfectly for the POST console redirection and FreeBSD boot process. > > /boot.config contains "-Dh" and /boot/loader.rc contains "console=comconsole" > > In the middle of the boot process, right after saying "Mounting ", com1 becomes com2 and vice versa. The console output suddenly starts going to Serial A -- which is connected to a modem. Not useful. > > During the shutdown process, console output reverts to the proper com1 assignment. I think you just need to swap the ports in /boot/device.hints? Consoles are mostly low-level, and console initialization is very low level. The initialization is supposed to run before ACPI, etc. have had a chance to change the resource values dynamically (so that ACPI, etc. can print messages and otherwise be debugged), so when sio console initialization uses the apparently-higher-level resource access functions it is actually just using the hints, so the hints had better be correct -- they are more than hints. I don't know exactly what happens with ACPI. Ideally, ACPI should set the resource values to match the BIOS, and this might involve ignoring most hints and this changing the values from their defaults, but for consoles any changes in the values would be wrong and might result in the high-level console (/dev/console) being attached to a different device than the low-level console (the one used for kernel printfs). Bruce From owner-freebsd-i386@FreeBSD.ORG Mon Jul 31 10:00:38 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51F9616A4EB for ; Mon, 31 Jul 2006 10:00:38 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA03343D45 for ; Mon, 31 Jul 2006 10:00:37 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k6VA0bUW044789 for ; Mon, 31 Jul 2006 10:00:37 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k6VA0b4v044788; Mon, 31 Jul 2006 10:00:37 GMT (envelope-from gnats) Date: Mon, 31 Jul 2006 10:00:37 GMT Message-Id: <200607311000.k6VA0b4v044788@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Bruce Evans Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 10:00:38 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Bruce Evans To: Jo Rhett Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-i386@FreeBSD.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Mon, 31 Jul 2006 19:55:42 +1000 (EST) On Tue, 25 Jul 2006, Jo Rhett wrote: >> Description: > For our motherboard, "Serial A" in hardwired on the board with a 9-pin connector. "Serial B" is a normal serial connector that can be wired anywhere. Rackable uses this connector to connect to their out-of-band management interface. > > So in the BIOS configuration, we assign COM1 = "Serial B" and COM2 = "Serial A". This works perfectly for the POST console redirection and FreeBSD boot process. > > /boot.config contains "-Dh" and /boot/loader.rc contains "console=comconsole" > > In the middle of the boot process, right after saying "Mounting ", com1 becomes com2 and vice versa. The console output suddenly starts going to Serial A -- which is connected to a modem. Not useful. > > During the shutdown process, console output reverts to the proper com1 assignment. I think you just need to swap the ports in /boot/device.hints? Consoles are mostly low-level, and console initialization is very low level. The initialization is supposed to run before ACPI, etc. have had a chance to change the resource values dynamically (so that ACPI, etc. can print messages and otherwise be debugged), so when sio console initialization uses the apparently-higher-level resource access functions it is actually just using the hints, so the hints had better be correct -- they are more than hints. I don't know exactly what happens with ACPI. Ideally, ACPI should set the resource values to match the BIOS, and this might involve ignoring most hints and this changing the values from their defaults, but for consoles any changes in the values would be wrong and might result in the high-level console (/dev/console) being attached to a different device than the low-level console (the one used for kernel printfs). Bruce From owner-freebsd-i386@FreeBSD.ORG Mon Jul 31 11:03:46 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9ECED16A547 for ; Mon, 31 Jul 2006 11:03:46 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id F292A43DBF for ; Mon, 31 Jul 2006 11:03:01 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k6VB2w8N051813 for ; Mon, 31 Jul 2006 11:02:58 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k6VB2vD0051807 for freebsd-i386@freebsd.org; Mon, 31 Jul 2006 11:02:57 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 31 Jul 2006 11:02:57 GMT Message-Id: <200607311102.k6VB2vD0051807@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-i386@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 11:03:46 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/04/28] i386/66039 i386 [panic] system panic with file system cor o [2004/09/09] i386/71538 i386 [install] multi-homed install trashes exi o [2005/09/19] i386/86317 i386 Kernel launch results in poweroff [HP zv5 o [2005/09/20] i386/86364 i386 [ata] ATA woes, SATA controller: failed w f [2005/10/07] i386/87026 i386 [hang] Bootup hang on atkbdc on Compaq 18 o [2005/11/10] i386/88802 i386 [iwi] [cardbus] CARDBUS related kernel cr o [2006/01/02] i386/91214 i386 [ata] Disk corruption with Asus K8S-LA: b 7 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/02/11] i386/24997 i386 [biosdisk] [patch] /boot/loader cannot ha s [2001/09/29] i386/30921 i386 [kbd] ACER mechanic ps/2 keyboard donīt w o [2001/11/14] i386/31979 i386 [kbd] Setup and boot locks Compaq Armada o [2002/02/18] i386/35078 i386 [i386] [patch] Uninitialized pointer dere o [2002/03/17] i386/36003 i386 [panic] Cyclades Cyclom YeP causes panics o [2002/04/10] i386/36943 i386 [smp] [hang] reboot hangs on Tyan Thunder s [2002/06/19] i386/39536 i386 [loader] FreeBSD default bootloader does o [2002/07/05] i386/40219 i386 [apm] apm breaks removable media o [2002/09/07] i386/42539 i386 [panic] Fatal Trap 12 resulting from Conn o [2002/10/16] i386/44130 i386 [apm] Enabled apm hangs up FreeBSD kernel o [2002/11/04] i386/44867 i386 [hang] Frequent hard hangs on ASUS P4T-E/ o [2002/11/27] i386/45773 i386 [bge] Softboot causes autoconf failure on o [2002/12/11] i386/46194 i386 [install] 5.0-RC1 kern floppy load fails o [2003/01/08] i386/46865 i386 [panic] kernel panic on SuperMicro 6012-8 o [2003/01/20] i386/47236 i386 Console missing during bootup on Sony Pic o [2003/01/24] i386/47449 i386 [boot] Thinkpad 755CD floppy boot fails o [2003/02/26] i386/48691 i386 [panic] kernel panics on ASUS A7N266-VM M o [2003/05/12] i386/52128 i386 [install] Unable to floppy install on Tos o [2003/05/22] i386/52581 i386 [loader] boot loaders reading more than o o [2003/06/16] i386/53382 i386 Repetable panics in ffs_vget() on Prolian o [2003/06/23] i386/53620 i386 [install] Kernel panics / reboots during s [2003/07/16] i386/54549 i386 [panic] panic on install on Dell 600sc o [2003/08/15] i386/55603 i386 [mly] unable to reboot when system runs f o [2003/09/17] i386/56937 i386 panic: system panic during high network l o [2003/09/20] i386/57043 i386 [ar] [hang] ar driver with 2 port PCI car p [2003/10/01] i386/57480 i386 Removing very large files using rm doesn' o [2003/10/09] i386/57818 i386 4.9-RC panics when kernel is built with a o [2003/10/16] i386/58139 i386 [panic] -CURRENT panics on Thinkpad A31p o [2003/10/26] i386/58580 i386 After sysinstall, F2 fails; wrong device o [2003/11/13] i386/59260 i386 [panic] Panic by integer divide fault in o [2003/11/25] i386/59683 i386 panic: signal 12 4.9-STABLE - frequent cr o [2003/11/26] i386/59701 i386 System hungup, after resume from suspend. o [2003/11/26] i386/59719 i386 [crash] 4.9 Crashes on SuperMicro with SM o [2003/12/02] i386/59898 i386 [boot] pxe boot: BTX halted o [2003/12/08] i386/60050 i386 Toshiba/3Com 3CXM056-BNW: Open Causes Int o [2003/12/14] i386/60226 i386 [ichsmb] [patch] ichsmb driver doesn't de o [2003/12/17] i386/60328 i386 [panic] installing 5.1, 5.2RC and 5-CURRE o [2003/12/27] i386/60633 i386 [sis] SIS motherboard with the SIS 5591 ( o [2003/12/28] i386/60646 i386 [hang] VIA C3 system hangs on reboot o [2003/12/29] i386/60681 i386 wicontrol -L critical crash (sigbus) o [2004/01/04] i386/60887 i386 can't boot when fbsd exists with other op o [2004/01/12] i386/61253 i386 [panic] page fault on installation freebs o [2004/01/13] i386/61303 i386 5.2-REL hangs during boot with 3-port pyr o [2004/01/13] i386/61326 i386 Reboot while booting from 5.2-RELEASE CD o [2004/01/14] i386/61342 i386 [hang] CD-based installation crashes [4.9 o [2004/01/20] i386/61646 i386 [workaround] Strange irq20 weirdness caus o [2004/01/22] i386/61709 i386 [panic] 5.2-REL i386 Crashes hard; panics o [2004/01/26] i386/61970 i386 [panic] on boot, 5.1/5.2 (but not 5.0), S o [2004/02/09] i386/62565 i386 device.hints are not honored in 5.2.1-RC o [2004/02/13] i386/62807 i386 4.9 SMP does not work with Compaq Smart o [2004/02/15] i386/62888 i386 ad4: WARNING - WRITE_DMA interrupt was se o [2004/02/24] i386/63305 i386 [udf] reading udf filesystem on dvd+rw le o [2004/02/27] i386/63441 i386 [panic] fatal trap 12 in pmap.c [4.9 with o [2004/02/27] i386/63449 i386 [boot] FreeBSD 5.2 and 5.2.1 releases won o [2004/03/03] i386/63678 i386 5.2.1 installation hangs on t30 o [2004/03/04] i386/63731 i386 [boot] PATA to SATA converter on Promise o [2004/03/06] i386/63828 i386 [hang] when installing Release 5.2.1 (i38 o [2004/03/07] i386/63871 i386 [panic] kernel panic in swi8 after 1 hour o [2004/03/09] i386/63992 i386 [hang] XFree86 4.3 hangs on IBM ThinkPad o [2004/03/12] i386/64158 i386 5.2.1-RELEASE CD won't boot on acer Trave o [2004/03/19] i386/64450 i386 Lucent Technologies WaveLAN/IEEE (PCI) fr o [2004/03/25] i386/64680 i386 5.2.1 pci-cfgintr steals serial mouse irq o [2004/03/25] i386/64716 i386 [nis] mv crashes FreeBSD 5.2.1-p3 o [2004/03/25] i386/64727 i386 [boot] cannot find disk on asus p4s533mx o [2004/04/02] i386/65072 i386 hang on reboot not syncing drives on ibm o [2004/04/03] i386/65137 i386 [boot] 5.2.1 Intall Boot from floppies pa o [2004/04/12] i386/65457 i386 BTX Halted when trying boot after success o [2004/04/14] i386/65523 i386 [loader] [patch] PXE loader malfunction i o [2004/04/19] i386/65775 i386 [panic] Transmeta crusoe without longrun o [2004/04/29] i386/66087 i386 [install] hang at PCI config [5.2.1] o [2004/05/01] i386/66133 i386 [boot] nvidia motherboard installer locks o [2004/05/06] i386/66306 i386 pnpbios_identify() queries for more devic o [2004/05/07] i386/66368 i386 [install] 4.9 install fails with MODE_SEN o [2004/05/22] i386/67047 i386 [mpt] mpt driver does not recognize messa o [2004/06/01] i386/67469 i386 src/lib/msun/i387/s_tan.S gives incorrect o [2004/06/07] i386/67688 i386 5.2.1 initial floppy boot fails with Fata o [2004/06/11] i386/67833 i386 [boot] 4.10 does not boot after enabling a [2004/06/15] i386/67955 i386 [panic] -current on T40p kernel trap 12 i o [2004/06/19] i386/68103 i386 [panic] ASUS P4P8X mb at ffs/ffs_softdep. o [2004/06/20] i386/68149 i386 FreeBSD 4.10 installation blocking on ASU o [2004/06/24] i386/68277 i386 [kbd] Compact Evo N610c (Laptop): Using e o [2004/06/27] i386/68411 i386 VMware Virtual Machine - Network Fails Du o [2004/06/28] i386/68438 i386 bootloader cannot read from icp vortex ar o [2004/06/29] i386/68486 i386 logo screensaver kills compaq ML370 conso o [2004/07/01] i386/68554 i386 [hang] system freeze on Compaq Evo 600c [ o [2004/07/10] i386/68899 i386 Problems reading and writing DVD-RAM disc o [2004/07/14] i386/69049 i386 [install] error "anic: page fault" o [2004/08/05] i386/70028 i386 [umass] umass issue in the boot prcess on o [2004/08/13] i386/70386 i386 IBM x345 Freezes Randomly o [2004/08/15] i386/70482 i386 Array adapter problems o [2004/08/16] i386/70525 i386 [boot] boot0cfg: -o packet not effective o [2004/08/16] i386/70531 i386 [boot0] [patch] boot0 hides Lilo in exten o [2004/08/20] i386/70747 i386 ddos attack causes box to crash on kernel o [2004/08/25] i386/70925 i386 [hang] 5.3Beta1 acpi-pci driver failure, o [2004/08/26] i386/71000 i386 [boot] BTX halted when booting from CD on o [2004/08/27] i386/71035 i386 [kbd] SMP boot hangs in bus_space_write_1 o [2004/08/27] i386/71048 i386 [hang] ASUS TUV4X hangs when SONY CRX140E o [2004/08/28] i386/71087 i386 [hang] 5.3-beta(2-5) fail to install on e o [2004/08/30] i386/71144 i386 FBSD5.3b2 doesn't boot on a Compaq Armada o [2004/08/30] i386/71158 i386 pci bus number 3 devices are missing on l o [2004/08/31] i386/71190 i386 Dead thinkpad R31 after installing 5.2.1 o [2004/09/06] i386/71428 i386 DMA does not work on VIA 82C586 [4.10] f [2004/09/12] i386/71641 i386 5.3-BETA3: wi0 hangs during kernel load o [2004/09/22] i386/72004 i386 [boot] FreeBSD 5.2.1 install hangs with e o [2004/09/24] i386/72065 i386 4.x and 5.2.1 doesn't recognize PCnet/ISA o [2004/10/05] i386/72343 i386 Suspend resets system on Inspiron 5160. o [2004/10/06] i386/72376 i386 acpi is mutually exclusive with snd_mss o o [2004/10/07] i386/72416 i386 FreeBSD 5.3-BETA7: The alternate systemcl f [2004/10/17] i386/72778 i386 5.3beta7 never boots, suspected SMP probl o [2004/10/21] i386/72960 i386 BTX halted with Promise Tx2000 Raid o [2004/10/21] i386/72976 i386 [panic] trap 9 on boot [ACPI-related] o [2004/10/27] i386/73196 i386 [hang] 5.2.1 boot CD hangs during boot on o [2004/10/29] i386/73265 i386 FreeBSD kernel crashes when booting on EC o [2004/11/08] i386/73666 i386 5.3 UDMA error WD1600 can't partition dri o [2004/11/14] i386/73934 i386 fdisk sees disk as empty o [2004/11/16] i386/74008 i386 IBM eServer x225 cannot boot any v5.x - e o [2004/11/17] i386/74044 i386 ServerWorks OSB4 SMBus interface does not o [2004/11/19] i386/74124 i386 ata0 failure on HP(Vectra) VL6/350 [intro o [2004/12/01] i386/74601 i386 Cardbus fails after busdma_machdep.c upda o [2004/12/07] i386/74816 i386 OS crash with kernel trap 12 in different o [2004/12/12] i386/74988 i386 dma errors with large maxtor hard drives o [2005/01/06] i386/75887 i386 [pcvt] with vt0.disabled=0 and PCVT in ke o [2005/01/17] i386/76372 i386 cannot burn iso image disk2 of any releas s [2005/01/18] i386/76397 i386 [ata] ata raid crashes in g_down (heavy l o [2005/01/20] i386/76487 i386 Compiled GENERIC kernel (and non-GENERIC) o [2005/01/25] i386/76666 i386 Booting and Sound are mutually exclusive o [2005/01/27] i386/76737 i386 CardBus problem (cbb1: Could not map regi o [2005/01/31] i386/76925 i386 standard pci-ide, install - "NO DISKS FOU o [2005/02/01] i386/76944 i386 [busdma] [patch] i386 bus_dmamap_create() o [2005/02/01] i386/76948 i386 [rl] Slow network with rl0 o [2005/02/10] i386/77335 i386 Can not initial Ethernet Broadcom UDI PXE o [2005/02/13] i386/77443 i386 [fdc] can't access floppy -- regression o o [2005/02/14] i386/77529 i386 installation of freebsd 5.3 in laptop an o [2005/03/01] i386/78219 i386 Netgear FA-410TX is incorrectly detected o [2005/03/03] i386/78339 i386 BTX loader crashes on boot on HP Proliant o [2005/03/07] i386/78517 i386 [ata] WRITE_DMA and READ_DMA timeouts wit o [2005/03/10] i386/78657 i386 [xe] [hang] error installing 5.3-RELEASE o [2005/03/16] i386/78929 i386 atapicam prevents boot, system hangs o [2005/03/16] i386/78930 i386 SuperMicro web server with 5.3-RELEASE ke o [2005/03/21] i386/79073 i386 System panic and hang after creating a la o [2005/03/22] i386/79141 i386 [agp] 5.4Beta1 does not recognize my inte o [2005/03/23] i386/79169 i386 freeze with striped USB Drives under high o [2005/03/27] i386/79268 i386 5.3-RELEASE won't boot on Compaq Armada 4 o [2005/03/31] i386/79409 i386 Coming back from idles make the server re o [2005/04/08] i386/79686 i386 Spurious notebook disk errors from ATA dr o [2005/04/09] i386/79729 i386 umass, da0 not detected by devfs for o [2005/04/09] i386/79730 i386 SLIM DRIVE COMBO fails with READ_BIG erro o [2005/04/11] i386/79779 i386 If system memory is above 4GB, one parts o [2005/04/11] i386/79784 i386 [bfe] Broadcom BCM4401 : no carrier o [2005/04/12] i386/79807 i386 Lock Up on Old Acer P1 Comp o [2005/04/12] i386/79833 i386 BTX crashes on boot when using Promise TX o [2005/04/14] i386/79943 i386 Very High interupt rate on PCM o [2005/04/22] i386/80268 i386 [crash] System with Transmeta Efficeon cp o [2005/05/13] i386/80989 i386 Cannot install 5.4-RELEASE both in my sys p [2005/05/16] i386/81111 i386 /boot/loader causes reboot due to CFLAGS+ o [2005/05/18] i386/81215 i386 X Freeze on Dell Inspiron 9100 with Radeo o [2005/05/19] i386/81235 i386 /sys/i386/conf/GENERIC needs "options ASR o [2005/05/20] i386/81311 i386 [smp] [hang] Athlon MP SMP + 3ware + em0 o [2005/06/04] i386/81903 i386 Installer hangs on all menu entries on To o [2005/06/08] i386/82029 i386 Boot Loader installation on MegaRAID cont o [2005/06/15] i386/82285 i386 [race] kernel panic during reboot o [2005/07/16] i386/83574 i386 installation failure o [2005/07/19] i386/83735 i386 [re] network card (realtek 8139) and soun o [2005/07/21] i386/83826 i386 can't install any version on Toshiba Satt o [2005/07/22] i386/83925 i386 [boot] can't boot Dell Latitude D610 afte o [2005/07/24] i386/84008 i386 /dev/X? should be /dev/ad1s* o [2005/07/25] i386/84088 i386 Panic with nforce2 platform on FreeBSD 6. o [2005/07/29] i386/84303 i386 boot sometimes stops at "uhci0: 3.5GB o [2005/08/09] i386/84717 i386 [hang] 5.4-rel booting locks-up on Superm o [2005/08/15] i386/84943 i386 "Invalid Partition Table" Intel ICH6 SATA o [2005/08/18] i386/85072 i386 [psm] ps/2 Mouse detection failure on com o [2005/08/19] i386/85101 i386 [libm] nearbyint always returns nan o [2005/08/29] i386/85450 i386 panic: subdisk6 detached (appears to be a o [2005/08/29] i386/85454 i386 Panic while booting: No virtual memory fo o [2005/09/08] i386/85866 i386 [hang] bootloader freezes on Pentium2/3 o [2005/09/10] i386/85938 i386 Install fails, unable to write partitions o [2005/09/10] i386/85944 i386 FreeBSD restarts after showing "Welcome t o [2005/09/19] i386/86325 i386 [install] unable to install FreeBSD on IB o [2005/09/20] i386/86380 i386 i386_set_ioperm doesn't take effect immed o [2005/09/26] i386/86612 i386 SCSI DAT Drive Issue o [2005/09/27] i386/86651 i386 FAILURE ATA-IDENTIFY o [2005/09/28] i386/86667 i386 GNOME Battery Applet causing keyboard to o [2005/10/01] i386/86806 i386 Couldn't alloc kernel virtual memory o [2005/10/04] i386/86880 i386 [hang] 6.0 hangs or reboots whilst 5.4 is o [2005/10/05] i386/86920 i386 [ndis] ifconfig: SIOCS80211: Invalid argu o [2005/10/07] i386/87085 i386 Will not install on Microtel system o [2005/10/08] i386/87122 i386 Installer of 6.0-BETA5 can't find HDD par o [2005/10/09] i386/87155 i386 [boot] [panic] Can't Alloc Virtual Memory o [2005/10/13] i386/87356 i386 6.0 RC1 cannot see 250GB drive o [2005/10/17] i386/87576 i386 no installation on Acer aspire 1304xc lap o [2005/10/18] i386/87630 i386 [ndis] No match for NdisIMGetCurrentPacke o [2005/10/19] i386/87654 i386 Marvell Yukon 88E8036 NIC not detected by o [2005/10/20] i386/87750 i386 [boot] btx halted error while installatio o [2005/10/23] i386/87876 i386 Installation Problems for i368 Compaq R30 o [2005/10/28] i386/88124 i386 [hang] X -configure freezes 6.0rc1 o [2005/10/28] i386/88130 i386 [hang] Machine hangs on dhcp o [2005/10/28] i386/88139 i386 [i386] feature request: 53C875 Chipset HP o [2005/11/01] i386/88315 i386 [sym] [hang] Symbios/LSI-HBA (SYM83C895) o [2005/11/03] i386/88459 i386 [panic] Fatal trap 19 (process: idle: cpu o [2005/11/07] i386/88583 i386 i can't install freebsd in server ibm xse o [2005/11/07] i386/88610 i386 FreeBSD 6.0 bootonly crashes during boot o [2005/11/09] i386/88717 i386 freebsd 5.4 boots from lsi 53c1030 only i o [2005/11/09] i386/88755 i386 [panic] FreeBSD R6.0 on ThinkPad R40 inst o [2005/11/10] i386/88808 i386 V6.0 crashing on install with ICH7 RAID 5 o [2005/11/11] i386/88853 i386 [hang] SMP system FreeBSD 6.0-STABLE cras o [2005/11/13] i386/88929 i386 FreeBSD 6.0 install CD fails to find disk o [2005/11/18] i386/89249 i386 HighPoint RocketRAID 1520 (HPT372N) can't o [2005/11/19] i386/89288 i386 [acpi] DMA error while booting with acpi o [2005/11/21] i386/89340 i386 [panic] 6.0-STABLE (2005-11-07) panic whe o [2005/11/21] i386/89353 i386 [ata] invalid disk controller recognition o [2005/11/21] i386/89383 i386 [sio] [panic] page fault o [2005/12/07] i386/90059 i386 panic in 2 mins after power on PC o [2005/12/07] i386/90065 i386 [wi] System hangs if wireless card wasn't o [2005/12/09] i386/90134 i386 [irq] IDE and SATA disks not detected on o [2005/12/16] i386/90519 i386 Resume after suspend results in g_vfs_don o [2005/12/27] i386/90949 i386 [panic] kernel panic with opera o [2005/12/29] i386/91038 i386 [panic] 6.0-RELEASE on Fujitsu Siemens Am o [2006/01/03] i386/91282 i386 6.0R install CD crashes at eip=0x90db (Pr o [2006/01/05] i386/91331 i386 system hangs after citrix_ica_client(wfcm o [2006/01/13] i386/91745 i386 Second processor not detected on Proliant o [2006/01/13] i386/91748 i386 acpi problem on Acer TravelMare 4652LMi ( o [2006/01/23] i386/92193 i386 Can't boot from 6.0 Installation CD: BTX o [2006/01/25] i386/92303 i386 [ips] Cannot install FreeBSD 6 on an IBM o [2006/02/15] i386/93385 i386 Fatal trap 12 occasionally on reboot (Abi o [2006/02/18] i386/93524 i386 Automatic reboot o [2006/02/21] i386/93615 i386 Operating system wont install. Problem w o [2006/02/23] i386/93752 i386 Cannot activate the serial ports on boot o [2006/02/23] i386/93762 i386 Machine lockup at boot loader countdown o o [2006/02/24] i386/93787 i386 freebsd 6.0 hangs on atkbd0 on Proliant 1 o [2006/02/24] i386/93809 i386 panic: could not copy LDT on RELENG_5_3 t o [2006/02/26] i386/93845 i386 cross-machine installworld broken in sys/ o [2006/02/28] i386/93923 i386 [ata] FreeBSD Install, Sil3112: Cannot du o [2006/03/01] i386/93989 i386 Can't install FreeBSD from IEEE1394 DVD-R o [2006/03/06] i386/94141 i386 [iwi] iwi doesn't work on Acer Laptop o [2006/03/11] i386/94364 i386 [kbd] Unable to boot on NX9110 laptop o [2006/03/13] i386/94420 i386 FreeBSD does NOT support the pcChips M925 o [2006/03/18] i386/94653 i386 Fatal trap 12: page fault while in kernel o [2006/03/24] i386/94911 i386 [ata] ata regression with DOM-IDE o [2006/03/28] i386/95021 i386 PAE enabled kernel boot panic o [2006/03/29] i386/95087 i386 System freeze irrespective of load on Pro o [2006/03/31] i386/95151 i386 Fatal trap 12: page fault while in kernel o [2006/04/05] i386/95365 i386 stability problems: interface not reachab o [2006/04/08] i386/95515 i386 unable to boot FreeBSD 6.x with SATA150 P f [2006/04/17] i386/95964 i386 cannot boot 6.X o [2006/04/18] i386/96014 i386 HP Pavilion zv5000(Intel) reboot installa o [2006/04/19] i386/96049 i386 Generic SMP Kernel Panic in 6.1-RC1 durin o [2006/04/23] i386/96225 i386 Toshiba M70-CL3 Hangs Up During Booting o [2006/04/25] i386/96302 i386 [ata] nVidia nForce CK804 SATA300 control o [2006/04/26] i386/96357 i386 FreeBSD cannot recognize all the logical o [2006/04/26] i386/96371 i386 Freeze up when booting FBSD 6.0 RELEASE o o [2006/04/26] i386/96382 i386 [bge] In 6.1-RC1 the bge driver does not o [2006/05/02] i386/96652 i386 kernel page fault o [2006/05/06] i386/96870 i386 Crash on loader with ibm intellistation z o [2006/05/09] i386/97025 i386 fbsd (2 cd) dont install in vmware 5.5.0 o [2006/05/11] i386/97127 i386 IBM Intellistation Z Pro crash when boot f [2006/05/13] i386/97191 i386 HP Pavilion PII System crash when install o [2006/05/14] i386/97263 i386 [ata] FreeBSD only detects first drive o [2006/05/15] i386/97287 i386 Screen Corruption In FreeBSD 6.X When App o [2006/05/20] i386/97525 i386 System freezes when cable modem connected o [2006/05/22] i386/97589 i386 [ata] FAILURE - READ_DMA (regression from o [2006/05/30] i386/98154 i386 6-STABLE crashes when being online via mo o [2006/05/31] i386/98215 i386 [geode] regression: FreeBSD can no longer o [2006/06/09] i386/98765 i386 [ata] timeouts on sata drive o [2006/06/15] i386/98964 i386 [iwi] iwi totally freezes system o [2006/06/18] i386/99089 i386 Kernel Panic o [2006/06/28] i386/99570 i386 [kbd] keyboard freezes when installing fr o [2006/06/29] i386/99608 i386 ATAPI or CAM crash on FreeBSD 6.1-stable o [2006/07/12] i386/100160 i386 [mfid] Perc5i: FreeBSD doesn't recognize o [2006/07/13] i386/100194 i386 On Intel D945GTPLKR delay at start FreeBS o [2006/07/17] i386/100420 i386 boot1/boot2 lba error o [2006/07/25] i386/100831 i386 [sio] sio ignores BIOS information about 275 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/04/22] i386/18154 i386 [sysctl] [patch] Add cpu class and featur o [2001/02/09] i386/24963 i386 [perfmon] perfmon(4) doesn't work on SMP o [2001/09/03] i386/30276 i386 CPUTYPE=486 built on a CPUTYPE=p3 WORLD b o [2001/10/18] i386/31353 i386 [apm] [patch] 'shutdown -p' does not work o [2002/07/24] i386/40958 i386 [apm] apm on Acer TravelMate 351 could no o [2002/08/21] i386/41856 i386 VESA splash screen problems on ThinkPad 2 o [2002/09/14] i386/42766 i386 [vm] [patch] proposal to perform reboot v o [2002/09/22] i386/43262 i386 [hang] command 'shutdown -r' (also reboot o [2002/09/30] i386/43539 i386 [fdc] Cannot mout floppy on Compaq Prolia o [2002/12/09] i386/46113 i386 [bus] [patch] busspace bugs in parameter o [2003/01/19] i386/47223 i386 [pcvt] [PATCH] pcvt(4), ESC sequences do o [2003/01/22] i386/47376 i386 [pcvt] [PATCH], pcvt(4), COLOR_KERNEL_FG, o [2003/05/19] i386/52427 i386 DVD replay under MSI "655 MAX" mobo inter o [2003/08/21] i386/55838 i386 [kbd] [patch] Dual characters from keyboa o [2003/10/31] i386/58784 i386 [ata] ATA does not work in DMA mode (ASUS o [2003/12/17] i386/60319 i386 [hang] read error 34/0 during installatio o [2004/01/07] i386/61005 i386 [boot] The Boot Manager in FreeBSD 5.2RC o [2004/01/13] i386/61308 i386 Maxproc Limits counts Zombie Processes wh o [2004/01/14] i386/61348 i386 Adaptec 1460D PCI SCSI Card does not work o [2004/01/16] i386/61442 i386 Highpoint RocketRAID 1520 uses only UDMA2 o [2004/01/17] i386/61481 i386 [patch] a mechanism to wire io-channel-ch o [2004/01/18] i386/61545 i386 5.2 release cannot see NIC on Dell 1750 o [2004/01/19] i386/61579 i386 [hang] sis 645dx is not working (but on t o [2004/01/20] i386/61603 i386 [sysinstall] wrong geometry guessed o [2004/01/27] i386/62003 i386 [loader] [patch] make /boot/loader "reboo o [2004/02/03] i386/62288 i386 reopened raid disks on a running system o [2004/02/17] i386/62977 i386 Mouse daemon during install/setup o [2004/03/05] i386/63815 i386 boot loader waste a lot of time (10 min) o [2004/03/23] i386/64626 i386 AP initialization problem on GIGABYTE GA- o [2004/04/03] i386/65124 i386 Unable to disable TERM_EMU cleanly o [2004/04/14] i386/65528 i386 [psm] mouse cursor disapears on moving o [2004/05/22] i386/67055 i386 [psm] Mouse (wheel) detection problem on o [2004/05/30] i386/67383 i386 [i386] [patch] do a better job disassembl o [2004/06/04] i386/67578 i386 [kbd] Keyboard error IBM xSeries 335 o [2004/06/10] i386/67773 i386 5.x series - md5 on dev no longer works e o [2004/06/19] i386/68117 i386 serious network collisions after NIC "med o [2004/06/20] i386/68140 i386 Problem with Sony AIT ATAPI Tape dirve o [2004/06/30] i386/68518 i386 [agp] [hang] hangs while loading 82443BX o [2004/07/07] i386/68754 i386 [hang] SMP reset bug (Tyan Thunder100, 44 o [2004/07/18] i386/69257 i386 [i386] [patch] in_cksum_hdr is non-functi o [2004/07/28] i386/69722 i386 [wi] wi0: init failed, Lucent Technologie o [2004/08/18] i386/70610 i386 [speaker] [patch] spkr(4): hardcoded assu o [2004/08/22] i386/70832 i386 [re] serious problems with RealTek NIC us o [2004/09/11] i386/71586 i386 FreeBSD 5.3-BETA3 #3 hang during boot on o [2004/09/20] i386/71924 i386 timeouts with ata+hpt366 controller on BE o [2004/09/29] i386/72179 i386 [acpi] [patch] Inconsistent apm(8) output o [2004/10/30] i386/73308 i386 unable to install on AMD 2500+,NF2,GF MX4 o [2004/11/09] i386/73742 i386 5.3 rel i386 disk2 image not copying o [2004/11/14] i386/73921 i386 [sysctl] [patch] sysctlbyname for machdep o [2004/11/20] i386/74153 i386 [pst] FreeBSD 5.3 cannot boot ftom pst o [2004/11/21] i386/74216 i386 system halts o [2004/11/21] i386/74218 i386 boot floppy (2nd time) read error o [2004/11/24] i386/74327 i386 [pmap] [patch] mlock() causes physical me o [2004/11/27] i386/74454 i386 [bsd.cpu.mk] [patch] Adding VIA Eden fami o [2004/12/03] i386/74650 i386 System Reboot with umount command o [2004/12/03] i386/74658 i386 [ata] ATAPI CD not recognized after booti o [2004/12/07] i386/74803 i386 regression: lost 3Com509B in 5.X o [2004/12/12] i386/74966 i386 [rl] Realtek driver seems to misinterpret o [2004/12/15] i386/75090 i386 [ata] READ_BIG errors with Sony CRX1611 o [2004/12/17] i386/75185 i386 ACPI doesn't power off Tyan S2460 o [2004/12/23] i386/75420 i386 CMD 648 PCI not work o [2004/12/28] i386/75583 i386 Installation fails o [2005/01/04] i386/75776 i386 NO ps/2 keyboard using USB keyboard under o [2005/01/06] i386/75881 i386 ACPI suspend/resume doesn't work on ASUS o [2005/01/06] i386/75898 i386 Exception and reboot: Loader and kernel u o [2005/01/23] i386/76587 i386 ps2 mouse weird... o [2005/01/25] i386/76653 i386 Problem with Asahi Optical usb device (Pe o [2005/02/14] i386/77477 i386 AHA-1542CP SCSI failed to probe o [2005/03/21] i386/79091 i386 [i386] [patch] Small optimization for i38 o [2005/03/22] i386/79136 i386 disk controller not detected o [2005/03/27] i386/79274 i386 Autoconfigure fails for O2Micro OZ6812/68 o [2005/03/28] i386/79317 i386 Freebsd Erasing NVRAM o [2005/04/12] i386/79840 i386 Partitioning and formating a new disk fai o [2005/04/14] i386/79890 i386 burncd fails on a Pioneer DVD drive o [2005/04/18] i386/80081 i386 [if_ndis] Problem loading a NDIS kernel m o [2005/04/19] i386/80092 i386 PC Cards do not work at all on laptop Com o [2005/04/19] i386/80095 i386 ld-elf.so.1 crashes with executables prod o [2005/05/15] i386/81082 i386 Failure to detect Pioneer CD drive on Int o [2005/05/22] i386/81358 i386 [geode] [patch] add PC Engines WRAP suppo o [2005/05/28] i386/81597 i386 My POS-460 system based on a Western Digi o [2005/06/22] i386/82548 i386 VBE video driver incorrectly switches to/ o [2005/07/05] i386/83018 i386 Installer will not boot o [2005/08/04] i386/84555 i386 boot2 unable to load kernel directly. o [2005/08/23] i386/85246 i386 unable to install from CD on Asus PC-DL D o [2005/08/24] i386/85273 i386 FreeBSD (NetBSD or OpenBSD) not install o o [2005/08/28] i386/85417 i386 [i386] [patch] Possible bug in ia32 float o [2005/08/28] i386/85423 i386 [ex] ex(4) does not correctly recognize N o [2005/09/02] i386/85652 i386 [loader] [patch] deal with out-of-memory o [2005/09/02] i386/85653 i386 [i386] [patch] relieve hangs in tight loo o [2005/09/02] i386/85654 i386 [i386] [patch] separate max cpu from max o [2005/09/02] i386/85655 i386 [i386] [patch] expose cpu info for i386 s o [2005/09/02] i386/85656 i386 [i386] [patch] expose more i386 specific o [2005/09/07] i386/85851 i386 system hangs on during booting the machin o [2005/09/25] i386/86563 i386 System doesn't reboot on "shutdown -r now f [2005/10/01] i386/86820 i386 ISO Install Disk hangs after acd0: o [2005/10/25] i386/87968 i386 [fdc] cannot access the floppy device o [2005/10/26] i386/88020 i386 cannot boot unless: hint.apic.0.disabled= o [2005/11/04] i386/88491 i386 [panic] Panic when boot installation CD1 f [2005/11/07] i386/88585 i386 [fdc] Cannot mount floppy (HP Proliant ML o [2005/11/14] i386/88965 i386 vidcontrol hangs with 2 modules of RAM o [2005/11/19] i386/89294 i386 [identcpu] [patch] unknown CPU (i386/amd6 f [2005/11/26] i386/89568 i386 [NOTES] XBOX options missing from NOTES o [2005/12/11] i386/90243 i386 Laptop fan doesn't turn off (ACPI enabled o [2005/12/23] i386/90839 i386 [ata] burncd gets error on CDRIOCFIXATE w o [2006/01/10] i386/91594 i386 FreeBSD > 5.4 w/ACPI fails to detect Inte o [2006/01/10] i386/91609 i386 Booting takes *a long time* unless power o [2006/01/13] i386/91761 i386 [ata] NEC_DVD-RW + system start: semaphor o [2006/01/16] i386/91871 i386 [boot1] [patch] boot1: jump to 0xf000:0xf o [2006/01/29] i386/92501 i386 [irq] Hang on boot with ACPI enabled on A o [2006/02/24] i386/93793 i386 [kbd] Keyboard stops working after a shut o [2006/03/23] i386/94850 i386 [bge] FreeBSD 6.0 on Fujitsu BX300, netwo o [2006/03/30] i386/95106 i386 cannot install freebsd o [2006/04/18] i386/95993 i386 Cyrix 5530 unable to map interrupt o [2006/04/26] i386/96373 i386 install CD - don't boot o [2006/04/27] i386/96397 i386 [dc] strange behaveour of the dc driver o o [2006/04/27] i386/96406 i386 System freezes on IBM xSeries 335 with Fr o [2006/04/27] i386/96430 i386 boot2 is unable to load kernel directly o [2006/04/28] i386/96452 i386 twiddle in cdboot does not work o [2006/05/18] i386/97468 i386 [acpi] ACPI on ASUS A7V hangs on shutdown o [2006/06/02] i386/98366 i386 [em] Intel PRO/1000 MT Dual PCI-X: simula o [2006/06/14] i386/98932 i386 [i386] [patch] Kernel compilation failed s [2006/06/16] i386/99039 i386 [ata] SATA timeouts on HP DL140 G2 o [2006/06/26] i386/99485 i386 Disk IO Causes mplayer To Drop Frames o [2006/07/06] i386/99851 i386 setting rootdev crashes loader(8) o [2006/07/12] i386/100142 i386 [smb] [patch] /dev/smb0 device not availa o [2006/07/13] i386/100204 i386 FreeBSD reports raid as broken - but it i o [2006/07/30] i386/101062 i386 Freeze on detect Intel 900 VGA on boot wi 127 problems total. From owner-freebsd-i386@FreeBSD.ORG Mon Jul 31 15:32:45 2006 Return-Path: X-Original-To: freebsd-i386@FreeBSD.org Delivered-To: freebsd-i386@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C905516A4DE; Mon, 31 Jul 2006 15:32:45 +0000 (UTC) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5363043D45; Mon, 31 Jul 2006 15:32:45 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k6VFWhim052461; Mon, 31 Jul 2006 08:32:44 -0700 (PDT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k6VFUsBv069233; Mon, 31 Jul 2006 08:30:54 -0700 (PDT) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k6VFUrVD069230; Mon, 31 Jul 2006 08:30:53 -0700 (PDT) (envelope-from jrhett) Date: Mon, 31 Jul 2006 08:30:53 -0700 From: Jo Rhett To: Bruce Evans Message-ID: <20060731153053.GA68160@svcolo.com> References: <200607252036.k6PKanFd072593@www.freebsd.org> <20060731191302.S1172@epsplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060731191302.S1172@epsplex.bde.org> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-i386@FreeBSD.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 15:32:45 -0000 On Mon, Jul 31, 2006 at 07:55:42PM +1000, Bruce Evans wrote: > On Tue, 25 Jul 2006, Jo Rhett wrote: > >>Description: > >For our motherboard, "Serial A" in hardwired on the board with a 9-pin > >connector. "Serial B" is a normal serial connector that can be wired > >anywhere. Rackable uses this connector to connect to their out-of-band > >management interface. > > > >So in the BIOS configuration, we assign COM1 = "Serial B" and COM2 = > >"Serial A". This works perfectly for the POST console redirection and > >FreeBSD boot process. > I think you just need to swap the ports in /boot/device.hints? device.hints contains what you expect. 0x3f8 should be sio0, but its not. This is apparently ignored. > initialization uses the apparently-higher-level resource access functions > it is actually just using the hints, so the hints had better be correct > -- they are more than hints. Sure, but they aren't working. That's the nature of this beast/bug. > I don't know exactly what happens with ACPI. Ideally, ACPI should set > the resource values to match the BIOS, and this might involve ignoring > most hints and this changing the values from their defaults, but for > consoles any changes in the values would be wrong and might result in > the high-level console (/dev/console) being attached to a different > device than the low-level console (the one used for kernel printfs). Exactly what I'm worried about. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-i386@FreeBSD.ORG Mon Jul 31 15:40:16 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE4AA16A4DA for ; Mon, 31 Jul 2006 15:40:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C28C43D45 for ; Mon, 31 Jul 2006 15:40:16 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k6VFeGrG080985 for ; Mon, 31 Jul 2006 15:40:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k6VFeGWs080984; Mon, 31 Jul 2006 15:40:16 GMT (envelope-from gnats) Date: Mon, 31 Jul 2006 15:40:16 GMT Message-Id: <200607311540.k6VFeGWs080984@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Jo Rhett Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jo Rhett List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 15:40:16 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Jo Rhett To: Bruce Evans Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-i386@FreeBSD.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Mon, 31 Jul 2006 08:30:53 -0700 On Mon, Jul 31, 2006 at 07:55:42PM +1000, Bruce Evans wrote: > On Tue, 25 Jul 2006, Jo Rhett wrote: > >>Description: > >For our motherboard, "Serial A" in hardwired on the board with a 9-pin > >connector. "Serial B" is a normal serial connector that can be wired > >anywhere. Rackable uses this connector to connect to their out-of-band > >management interface. > > > >So in the BIOS configuration, we assign COM1 = "Serial B" and COM2 = > >"Serial A". This works perfectly for the POST console redirection and > >FreeBSD boot process. > I think you just need to swap the ports in /boot/device.hints? device.hints contains what you expect. 0x3f8 should be sio0, but its not. This is apparently ignored. > initialization uses the apparently-higher-level resource access functions > it is actually just using the hints, so the hints had better be correct > -- they are more than hints. Sure, but they aren't working. That's the nature of this beast/bug. > I don't know exactly what happens with ACPI. Ideally, ACPI should set > the resource values to match the BIOS, and this might involve ignoring > most hints and this changing the values from their defaults, but for > consoles any changes in the values would be wrong and might result in > the high-level console (/dev/console) being attached to a different > device than the low-level console (the one used for kernel printfs). Exactly what I'm worried about. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-i386@FreeBSD.ORG Mon Jul 31 18:00:30 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07B2516A4E0 for ; Mon, 31 Jul 2006 18:00:30 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9794B43D46 for ; Mon, 31 Jul 2006 18:00:28 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k6VI0STX092976 for ; Mon, 31 Jul 2006 18:00:28 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k6VI0SLX092970; Mon, 31 Jul 2006 18:00:28 GMT (envelope-from gnats) Resent-Date: Mon, 31 Jul 2006 18:00:28 GMT Resent-Message-Id: <200607311800.k6VI0SLX092970@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, "John C. Archambeau" Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7700F16A4DE for ; Mon, 31 Jul 2006 17:52:53 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4699943D53 for ; Mon, 31 Jul 2006 17:52:53 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k6VHqr3J047744 for ; Mon, 31 Jul 2006 17:52:53 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k6VHqqcN047743; Mon, 31 Jul 2006 17:52:52 GMT (envelope-from nobody) Message-Id: <200607311752.k6VHqqcN047743@www.freebsd.org> Date: Mon, 31 Jul 2006 17:52:52 GMT From: "John C. Archambeau" To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: i386/101114: icmptype names not in icmp(4) manpage X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 18:00:30 -0000 >Number: 101114 >Category: i386 >Synopsis: icmptype names not in icmp(4) manpage >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Mon Jul 31 18:00:27 GMT 2006 >Closed-Date: >Last-Modified: >Originator: John C. Archambeau >Release: 6.1 >Organization: BSDWorks >Environment: FreeBSD fw3.bsdworks 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun Jul 30 18:28:51 PDT 2006 nxiv@fw3.bsdworks:/usr/src/sys/i386/compile/S1564D i386 >Description: The icmptypes mentioned in FreeBSD pf.conf manpage are not mentioned in the FreeBSD 6.1 icmp(4) manpage. >How-To-Repeat: man 4 icmp and look for icmp types to use in your pf.conf rules. >Fix: Append the OpenBSD 3.7 icmptype section for icmptype names to use in your pf rules or pf.conf file. Consult the OpenBSD 3.7 manpage for icmptypes to use until committed to the manpages. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-i386@FreeBSD.ORG Mon Jul 31 19:40:43 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8987516A4F0 for ; Mon, 31 Jul 2006 19:40:43 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C832943DD6 for ; Mon, 31 Jul 2006 19:40:27 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k6VJeIKr002772 for ; Mon, 31 Jul 2006 19:40:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k6VJeIYD002771; Mon, 31 Jul 2006 19:40:18 GMT (envelope-from gnats) Resent-Date: Mon, 31 Jul 2006 19:40:18 GMT Resent-Message-Id: <200607311940.k6VJeIYD002771@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Robert French Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FB4C16A4DD for ; Mon, 31 Jul 2006 19:39:23 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9317143D86 for ; Mon, 31 Jul 2006 19:39:14 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k6VJdDlO069063 for ; Mon, 31 Jul 2006 19:39:13 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k6VJdD6X069062; Mon, 31 Jul 2006 19:39:13 GMT (envelope-from nobody) Message-Id: <200607311939.k6VJdD6X069062@www.freebsd.org> Date: Mon, 31 Jul 2006 19:39:13 GMT From: Robert French To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: i386/101121: Everytime I install: after the install the harddisk becomes 512m+/-? X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 19:40:43 -0000 >Number: 101121 >Category: i386 >Synopsis: Everytime I install: after the install the harddisk becomes 512m+/-? >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Jul 31 19:40:17 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Robert French >Release: It's been going on since 5 and now in 6.1 >Organization: >Environment: celeron 360mhz 256megs ram 6g harddisk maxtor >Description: I install freebsd go to boot and then the 6gig harddrive is 558megs or something, 586megs I think. >How-To-Repeat: Install Freebsd standard way 1,2,3 Get done, then reboot!!! There it is 568megs or something. I thought it might be LBA or something? >Fix: Use 4.11 FreeBSD? >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-i386@FreeBSD.ORG Tue Aug 1 03:20:14 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3646C16A4DE for ; Tue, 1 Aug 2006 03:20:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CDD443D49 for ; Tue, 1 Aug 2006 03:20:13 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k713KDaB044709 for ; Tue, 1 Aug 2006 03:20:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k713KD21044708; Tue, 1 Aug 2006 03:20:13 GMT (envelope-from gnats) Resent-Date: Tue, 1 Aug 2006 03:20:13 GMT Resent-Message-Id: <200608010320.k713KD21044708@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Huidae Cho Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77F8216A4DA for ; Tue, 1 Aug 2006 03:19:53 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A9CB43D45 for ; Tue, 1 Aug 2006 03:19:53 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k713JrbP028468 for ; Tue, 1 Aug 2006 03:19:53 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k713JrGh028467; Tue, 1 Aug 2006 03:19:53 GMT (envelope-from nobody) Message-Id: <200608010319.k713JrGh028467@www.freebsd.org> Date: Tue, 1 Aug 2006 03:19:53 GMT From: Huidae Cho To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: i386/101135: iwi goes up and down X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 03:20:14 -0000 >Number: 101135 >Category: i386 >Synopsis: iwi goes up and down >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Aug 01 03:20:12 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Huidae Cho >Release: kern.osreldate: 601103 (6.1-STABLE July 31, 2006) >Organization: >Environment: FreeBSD localhost 6.1-STABLE FreeBSD 6.1-STABLE #0: Mon Jul 31 20:46:04 CDT 2006 geni@localhost:/usr/obj/usr/src/sys/GENI i386 >Description: I've updated to today's (July 31, 2006) 6.1-STABLE to use /usr/ports/net/iwi-firmware-kmod because iwi(4) with /usr/ports/net/iwi-firmware freezes the system so often. After build/installing kernel, everything looked fine, but I found iwi(4) does not work at all. Looking into /var/log/messages, iwi(4) driver goes up and down every about 5 seconds. It makes the driver unusable. I added firmware(9) and iwi(4) into the kernel and compiled a recent version of iwi-firmware-kmod port. My previous environment was 6.1-STABLE of the last month. Do I have to rebuild vpnc and "world" to make dhclient work with the new firmware framework? $ pciconf -lv iwi0@pci2:11:0: class=0x028000 card=0x27518086 chip=0x42208086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/Wireless 2200BG Network Connection' class = network $ tail -f /var/log/messages Jul 31 21:35:04 localhost kernel: iwi0: link state changed to UP Jul 31 21:35:04 localhost vpnc[784]: routing loop to 165.91.140.250 Jul 31 21:35:04 localhost dhclient: New IP Address (iwi0): 10.32.19.182 Jul 31 21:35:04 localhost dhclient: New Subnet Mask (iwi0): 255.255.255.0 Jul 31 21:35:04 localhost dhclient: New Broadcast Address (iwi0): 10.32.19.255 Jul 31 21:35:04 localhost dhclient: New Routers (iwi0): 10.32.19.1 Jul 31 21:35:05 localhost vpnc[784]: routing loop to 165.91.140.250 Jul 31 21:35:06 localhost last message repeated 6 times Jul 31 21:35:06 localhost kernel: iwi0: link state changed to DOWN Jul 31 21:35:06 localhost vpnc[784]: routing loop to 165.91.140.250 Jul 31 21:35:07 localhost last message repeated 4 times Jul 31 21:35:08 localhost kernel: iwi0: link state changed to UP Jul 31 21:35:08 localhost dhclient: New IP Address (iwi0): 10.32.19.182 Jul 31 21:35:08 localhost dhclient: New Subnet Mask (iwi0): 255.255.255.0 Jul 31 21:35:08 localhost dhclient: New Broadcast Address (iwi0): 10.32.19.255 Jul 31 21:35:08 localhost dhclient: New Routers (iwi0): 10.32.19.1 Jul 31 21:35:08 localhost vpnc[784]: routing loop to 165.91.140.250 Jul 31 21:35:10 localhost last message repeated 5 times Jul 31 21:35:10 localhost kernel: iwi0: link state changed to DOWN Jul 31 21:35:11 localhost kernel: iwi0: link state changed to UP Jul 31 21:35:12 localhost dhclient: New IP Address (iwi0): 10.32.19.182 Jul 31 21:35:12 localhost dhclient: New Subnet Mask (iwi0): 255.255.255.0 Jul 31 21:35:12 localhost dhclient: New Broadcast Address (iwi0): 10.32.19.255 Jul 31 21:35:12 localhost dhclient: New Routers (iwi0): 10.32.19.1 Jul 31 21:35:12 localhost vpnc[784]: routing loop to 165.91.140.250 Jul 31 21:35:14 localhost last message repeated 6 times >How-To-Repeat: 1. Build kernel with firmware(9) and iwi(4) built-in (6.1-STABLE, July 31, 2006) 2. Use vpnc to connect to the network 3. tail -f /var/log/messages >Fix: No idea >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-i386@FreeBSD.ORG Tue Aug 1 12:50:17 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A047216A4DA for ; Tue, 1 Aug 2006 12:50:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77C4F43D7C for ; Tue, 1 Aug 2006 12:50:15 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k71CoFMA005058 for ; Tue, 1 Aug 2006 12:50:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k71CoFER005057; Tue, 1 Aug 2006 12:50:15 GMT (envelope-from gnats) Resent-Date: Tue, 1 Aug 2006 12:50:15 GMT Resent-Message-Id: <200608011250.k71CoFER005057@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Maik Ehinger Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3CA916A4DA for ; Tue, 1 Aug 2006 12:43:38 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D8CD43D90 for ; Tue, 1 Aug 2006 12:43:18 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k71ChHa0024464 for ; Tue, 1 Aug 2006 12:43:17 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k71ChHj5024463; Tue, 1 Aug 2006 12:43:17 GMT (envelope-from nobody) Message-Id: <200608011243.k71ChHj5024463@www.freebsd.org> Date: Tue, 1 Aug 2006 12:43:17 GMT From: Maik Ehinger To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: i386/101168: ncp kernel panic X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 12:50:17 -0000 >Number: 101168 >Category: i386 >Synopsis: ncp kernel panic >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Aug 01 12:50:14 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Maik Ehinger >Release: 6.1-Stable >Organization: >Environment: FreeBSD pcmcb3-104.mcbad.net 6.1-STABLE FreeBSD 6.1-STABLE #0: Tue Aug 1 11:33:31 CEST 2006 root@pcmcb3-104.mcbad.net:/usr/obj/usr/src/sys/GENERIC i386 >Description: I get an kernel panic after entering the password for an ncp connection. Using ncplogin or mount_nwfs makes no difference. I try to connect to an Novell 6.5 Server with TCP only. Worked well with FreeBSD 4.11 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x20:0xc068a3fc stack pointer = 0x28:0xdcebc8dc frame pointer = 0x28:0xdcebc8e4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 772 (ncplogin) trap number = 12 panic: page fault Uptime: 16m46s Dumping 494 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 495MB (126511 pages) 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 ... ok Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... >How-To-Repeat: Try to mount an NetWare volume using mount_nwfs. >Fix: Not really a fix only a panic workaround. It seems to work for me so far without any recognized problems. I also get some md_get_mem(461): Incomplete copy messages without any known problem. --- ncp_sock.c.orig Fri Jan 7 02:45:49 2005 +++ ncp_sock.c Thu Jul 20 14:12:45 2006 @@ -189,7 +189,12 @@ struct thread *td = curthread; struct ucred *cred = NULL; - return so->so_proto->pr_usrreqs->pru_sopoll(so, events, cred, td); + if ( td->td_selq.tqh_last == NULL ) { + printf("ncp_poll: td->td_selq.tqh_last == NULL\n"); + return 0; + } + + return so->so_proto->pr_usrreqs->pru_sopoll(so, events, cred, td); } int >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-i386@FreeBSD.ORG Tue Aug 1 21:00:28 2006 Return-Path: X-Original-To: freebsd-i386@FreeBSD.org Delivered-To: freebsd-i386@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCF4316A4EC; Tue, 1 Aug 2006 21:00:28 +0000 (UTC) (envelope-from jrhett@svcolo.com) Received: from outbound0.sv.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5871043D66; Tue, 1 Aug 2006 21:00:25 +0000 (GMT) (envelope-from jrhett@svcolo.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k71L0HjN078444; Tue, 1 Aug 2006 14:00:24 -0700 (PDT) (envelope-from jrhett@svcolo.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k71Kxj11077410; Tue, 1 Aug 2006 13:59:45 -0700 (PDT) (envelope-from jrhett@svcolo.com) In-Reply-To: <20060731191302.S1172@epsplex.bde.org> References: <200607252036.k6PKanFd072593@www.freebsd.org> <20060731191302.S1172@epsplex.bde.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6EFF87DF-280C-402C-8C2A-10F3144CF41F@svcolo.com> Content-Transfer-Encoding: 7bit From: Jo Rhett Date: Tue, 1 Aug 2006 13:59:44 -0700 To: Bruce Evans X-Mailer: Apple Mail (2.752.2) Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-i386@FreeBSD.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 21:00:28 -0000 > On Tue, 25 Jul 2006, Jo Rhett wrote: >> In the middle of the boot process, right after saying "Mounting >> ", com1 becomes com2 and vice versa. The console >> output suddenly starts going to Serial A -- which is connected to >> a modem. Not useful. On Jul 31, 2006, at 2:55 AM, Bruce Evans wrote: > I think you just need to swap the ports in /boot/device.hints? > Consoles > are mostly low-level, and console initialization is very low level. > The initialization is supposed to run before ACPI, etc. have had a > chance to change the resource values dynamically (so that ACPI, etc. > can print messages and otherwise be debugged), so when sio console > initialization uses the apparently-higher-level resource access > functions > it is actually just using the hints, so the hints had better be > correct > -- they are more than hints. The hints are normal/standard but not working. Here's proof: root@arran 23# grep sio device.hints hint.sio.0.at="isa" hint.sio.0.port="0x3F8" hint.sio.0.flags="0x10" hint.sio.0.irq="4" hint.sio.1.at="isa" hint.sio.1.port="0x2F8" hint.sio.1.irq="3" root@arran 24# dmesg |grep sio sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 sio0: type 16550A, console sio1: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0 sio1: type 16550A Heh? Hints says 0x3f8 should be sio0 and console... > I don't know exactly what happens with ACPI. Ideally, ACPI should set > the resource values to match the BIOS, and this might involve ignoring > most hints and this changing the values from their defaults, but for > consoles any changes in the values would be wrong and might result in > the high-level console (/dev/console) being attached to a different > device than the low-level console (the one used for kernel printfs). It appears that ACPI is setting the sio order to match the order that the BIOS lists them, which is completely arbitrary and downright wrong. -- Jo Rhett senior geek Silicon Valley Colocation From owner-freebsd-i386@FreeBSD.ORG Tue Aug 1 21:10:19 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA9CE16A4DD for ; Tue, 1 Aug 2006 21:10:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F7F243D58 for ; Tue, 1 Aug 2006 21:10:19 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k71LAJ2K058506 for ; Tue, 1 Aug 2006 21:10:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k71LAJFX058505; Tue, 1 Aug 2006 21:10:19 GMT (envelope-from gnats) Date: Tue, 1 Aug 2006 21:10:19 GMT Message-Id: <200608012110.k71LAJFX058505@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Jo Rhett Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jo Rhett List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 21:10:20 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Jo Rhett To: Bruce Evans Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-i386@FreeBSD.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Tue, 1 Aug 2006 13:59:44 -0700 > On Tue, 25 Jul 2006, Jo Rhett wrote: >> In the middle of the boot process, right after saying "Mounting >> ", com1 becomes com2 and vice versa. The console >> output suddenly starts going to Serial A -- which is connected to >> a modem. Not useful. On Jul 31, 2006, at 2:55 AM, Bruce Evans wrote: > I think you just need to swap the ports in /boot/device.hints? > Consoles > are mostly low-level, and console initialization is very low level. > The initialization is supposed to run before ACPI, etc. have had a > chance to change the resource values dynamically (so that ACPI, etc. > can print messages and otherwise be debugged), so when sio console > initialization uses the apparently-higher-level resource access > functions > it is actually just using the hints, so the hints had better be > correct > -- they are more than hints. The hints are normal/standard but not working. Here's proof: root@arran 23# grep sio device.hints hint.sio.0.at="isa" hint.sio.0.port="0x3F8" hint.sio.0.flags="0x10" hint.sio.0.irq="4" hint.sio.1.at="isa" hint.sio.1.port="0x2F8" hint.sio.1.irq="3" root@arran 24# dmesg |grep sio sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 sio0: type 16550A, console sio1: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0 sio1: type 16550A Heh? Hints says 0x3f8 should be sio0 and console... > I don't know exactly what happens with ACPI. Ideally, ACPI should set > the resource values to match the BIOS, and this might involve ignoring > most hints and this changing the values from their defaults, but for > consoles any changes in the values would be wrong and might result in > the high-level console (/dev/console) being attached to a different > device than the low-level console (the one used for kernel printfs). It appears that ACPI is setting the sio order to match the order that the BIOS lists them, which is completely arbitrary and downright wrong. -- Jo Rhett senior geek Silicon Valley Colocation From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 00:20:19 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E21E16A4E7 for ; Wed, 2 Aug 2006 00:20:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FDE343D46 for ; Wed, 2 Aug 2006 00:20:19 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k720KIR6076316 for ; Wed, 2 Aug 2006 00:20:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k720KIXH076310; Wed, 2 Aug 2006 00:20:18 GMT (envelope-from gnats) Date: Wed, 2 Aug 2006 00:20:18 GMT Message-Id: <200608020020.k720KIXH076310@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Jo Rhett Cc: Subject: Re: i386/100831: [sio] sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jo Rhett List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 00:20:19 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Jo Rhett To: bug-followup@FreeBSD.org Cc: Subject: Re: i386/100831: [sio] sio ignores BIOS information about serial ports - bounty offered Date: Tue, 1 Aug 2006 17:10:42 -0700 This bug might have the subject changed to "sio orders ports by BIOS order regardless of device.hints" -- Jo Rhett senior geek Silicon Valley Colocation From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 05:17:57 2006 Return-Path: X-Original-To: i386@freebsd.org Delivered-To: freebsd-i386@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C059A16A4DA; Wed, 2 Aug 2006 05:17:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55F6143D46; Wed, 2 Aug 2006 05:17:57 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k725Ht6W033705; Wed, 2 Aug 2006 01:17:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.6/8.13.6) with ESMTP id k725Hu1L002469; Wed, 2 Aug 2006 01:17:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0C8717302F; Wed, 2 Aug 2006 01:17:56 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060802051756.0C8717302F@freebsd-current.sentex.ca> Date: Wed, 2 Aug 2006 01:17:56 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 05:17:57 -0000 TB --- 2006-08-02 03:49:44 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-08-02 03:49:44 - starting HEAD tinderbox run for i386/i386 TB --- 2006-08-02 03:49:45 - cleaning the object tree TB --- 2006-08-02 03:50:19 - checking out the source tree TB --- 2006-08-02 03:50:19 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-08-02 03:50:19 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-08-02 03:57:26 - building world (CFLAGS=-O2 -pipe) TB --- 2006-08-02 03:57:26 - cd /src TB --- 2006-08-02 03:57:26 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2006-08-02 05:06:15 - generating LINT kernel config TB --- 2006-08-02 05:06:15 - cd /src/sys/i386/conf TB --- 2006-08-02 05:06:15 - /usr/bin/make -B LINT TB --- 2006-08-02 05:06:15 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-08-02 05:06:15 - cd /src TB --- 2006-08-02 05:06:15 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Aug 2 05:06:15 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/net/bridgestp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/net/bsd_comp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/net/if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/net/if_arcsubr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/net/if_atmsubr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/net/if_bridge.c /src/sys/net/if_bridge.c: In function `bridge_clone_create': /src/sys/net/if_bridge.c:569: error: too few arguments to function `bstp_attach' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-08-02 05:17:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-08-02 05:17:55 - ERROR: failed to build lint kernel TB --- 2006-08-02 05:17:55 - tinderbox aborted TB --- 1.19 user 6.07 system 5290.94 real From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 06:34:24 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AF4C16A4DF for ; Wed, 2 Aug 2006 06:34:24 +0000 (UTC) (envelope-from sync_mastar@yahoo.com) Received: from web42208.mail.scd.yahoo.com (web42208.mail.scd.yahoo.com [66.218.93.209]) by mx1.FreeBSD.org (Postfix) with SMTP id 3255143D49 for ; Wed, 2 Aug 2006 06:34:24 +0000 (GMT) (envelope-from sync_mastar@yahoo.com) Received: (qmail 72644 invoked by uid 60001); 2 Aug 2006 06:34:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=h+jydo+/YYa3CHFt5+Nq9B63srUtd/tYK11BRdCLuYDi7FVX9F48kyMuqK0RPQdKp3RDnAsykQLBN5mTqaVtlTrXnPYeHvWNbVblovVjamex0UxQ2cz8763P6e83Qah4Hay+CShlvg9YE+Nap0YZS9uFIvYVNd9U2cMnoFQ2XOA= ; Message-ID: <20060802063424.72641.qmail@web42208.mail.scd.yahoo.com> Received: from [203.128.26.39] by web42208.mail.yahoo.com via HTTP; Tue, 01 Aug 2006 23:34:24 PDT Date: Tue, 1 Aug 2006 23:34:24 -0700 (PDT) From: Umar Draz To: freebsd-i386@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: TX and RX X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 06:34:24 -0000 Dear Members! In Linux I get rx/tx when I type ifconfig. In FreeBSD not. How can I get these infos ? linux: ifconfig eth0 eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx inet6 addr: xx:xx:xx:xx:x:xx64 Scope:Link UP BROADCAST SLAVE MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:20 Regards, Umar Draz --------------------------------- See the all-new, redesigned Yahoo.com. Check it out. From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 12:25:59 2006 Return-Path: X-Original-To: freebsd-i386@FreeBSD.org Delivered-To: freebsd-i386@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B280B16A4E1; Wed, 2 Aug 2006 12:25:59 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0652C43D49; Wed, 2 Aug 2006 12:25:59 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout1.pacific.net.au (Postfix) with ESMTP id 5513069FCA5; Wed, 2 Aug 2006 22:25:57 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k72CPr4O010480; Wed, 2 Aug 2006 22:25:54 +1000 Date: Wed, 2 Aug 2006 22:25:53 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Jo Rhett In-Reply-To: <6EFF87DF-280C-402C-8C2A-10F3144CF41F@svcolo.com> Message-ID: <20060802205230.N90692@delplex.bde.org> References: <200607252036.k6PKanFd072593@www.freebsd.org> <20060731191302.S1172@epsplex.bde.org> <6EFF87DF-280C-402C-8C2A-10F3144CF41F@svcolo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: njl@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org, freebsd-i386@FreeBSD.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 12:25:59 -0000 On Tue, 1 Aug 2006, Jo Rhett wrote: >> On Tue, 25 Jul 2006, Jo Rhett wrote: >>> In the middle of the boot process, right after saying "Mounting >>> ", com1 becomes com2 and vice versa. The console output >>> suddenly starts going to Serial A -- which is connected to a modem. Not >>> useful. > > On Jul 31, 2006, at 2:55 AM, Bruce Evans wrote: >> I think you just need to swap the ports in /boot/device.hints? Consoles >> are mostly low-level, and console initialization is very low level. >> The initialization is supposed to run before ACPI, etc. have had a >> chance to change the resource values dynamically (so that ACPI, etc. >> can print messages and otherwise be debugged), so when sio console >> initialization uses the apparently-higher-level resource access functions >> it is actually just using the hints, so the hints had better be correct >> -- they are more than hints. > > The hints are normal/standard but not working. Here's proof: > > root@arran 23# grep sio device.hints > hint.sio.0.at="isa" > hint.sio.0.port="0x3F8" > hint.sio.0.flags="0x10" > hint.sio.0.irq="4" > hint.sio.1.at="isa" > hint.sio.1.port="0x2F8" > hint.sio.1.irq="3" > > root@arran 24# dmesg |grep sio > sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 > sio0: type 16550A, console > sio1: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0 > sio1: type 16550A > > Heh? Hints says 0x3f8 should be sio0 and console... I can duplicate this. After swapping vanilla com ports in the BIOS on an A7N8X-E (Asus nForce2), ACPI in the 6.0-RELEASE kernel uses the flags hint but not the port or irq hints), gives the same inconsistent configuration: sio0: irq maps: 0x821 0x829 0x821 0x821 sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x90 on acpi0 sio0: type 16550A sio1: irq maps: 0x821 0x831 0x821 0x821 sio1: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0 sio1: type 16550A I think this indicates a workaround. Just configure sio1 with flags 0x90 in device.hints. I think acpi will use this hint but still ignore the others, so you would end up with the console port on the right hardware. The unit numbers of high-level sio ports ({cua,tty}d[0-1]) would be swapped but this wouldn't matter at all if you only the console port for a console. I think the fix for ACPI (and/or other "buses") would involve matching on all relevant hints for a given unit number. The port number is clearly relevant here (it is still "at" isa like device.hints says, although the above says "on acpi"). However, the irq number is irrelevant. >> I don't know exactly what happens with ACPI. Ideally, ACPI should set >> the resource values to match the BIOS, and this might involve ignoring >> most hints and this changing the values from their defaults, but for >> consoles any changes in the values would be wrong and might result in >> the high-level console (/dev/console) being attached to a different >> device than the low-level console (the one used for kernel printfs). > > It appears that ACPI is setting the sio order to match the order that the > BIOS lists them, which is completely arbitrary and downright wrong. Yes, the list order is bogus, but not very different from bus and/or probe order which tends to move disk drives around. Sio console configuration itself is documented to depend on a list order, but this was broken long ago. Partial fix for the documentation but not the bug: % Index: NOTES % =================================================================== % RCS file: /home/ncvs/src/sys/conf/NOTES,v % retrieving revision 1.1233 % diff -u -2 -r1.1233 NOTES % --- NOTES 22 Jun 2004 22:02:57 -0000 1.1233 % +++ NOTES 7 Apr 2005 20:27:21 -0000 % @@ -1520,10 +1520,18 @@ % # 0x10 enable console support for this unit. Other console flags % # (if applicable) are ignored unless this is set. Enabling % -# console support does not make the unit the preferred console. % -# Boot with -h or set boot_serial=YES in the loader. For sio(4) % +# console support does not make a serial device the % +# preferred console. % +# Boot with -h or set boot_serial=YES in the loader for that. % +# For sio(4) % # specifically, the 0x20 flag can also be set (see above). % # Currently, at most one unit can have console support; the % -# first one (in config file order) with this flag set is ^^^^^ ^^^^^^^^^^^^^^^^^^^^ % -# preferred. Setting this flag for sio0 gives the old behaviour. % +# last one (in unit number order) that has the 0x10 flag set ^^^^ ^^^^^^^^^^^^^^^^^^^^ % +# is selected. % +# Setting the 0x20 flag for _any_ sio unit that also has the % +# 0x10 flag set then makes the selected unit the preferred % +# console. % +# Setting the 0x40 flag for an sio unit cancels any settings % +# of the 0x10 and 0x20 flags (and most other flags) for that % +# unit. % # 0x80 use this port for serial line gdb support in ddb. Also known % # as debug port. This is missing documentation of the breakage of the search over all entries in the config file. The search is now limited unit numbers 0-15. In other words, precedence was determined by config file list order but is now determined by inverse unit number order except unit numbers >= 16 are now ignored. These bugs make putting an 0x10 flag on more than 1 port (with 0x20 to give extra precedence) even less useful than before. It used to be easy to control the order by moving lines in the config file, but unit numbers depend on hardware or firmware configuration which is harder to change. I'm still surprised that ACPI seems to affect the low-level sio console. The above boot messages are for high-level probes that don't do much with the console except avoid clobbering it and print where it is. If low-level console initialization used the correct flags hint but ACPI moved the hint later, then things would be very confusing. The code that avoids clobbering the decides where the console is by comparing the port number already decided from the flags earlier by lower-level code, while the code that prints where the console is use the current flags. If ACPI moves the flags hint late, then moving this hint to a consistently wrong port in device.hints like I suggested above would fix it for non-console flags but break it for most console flags. Non-console flags are rarely set so using the wrong flags hint would rarely affect non-consoles. Bruce From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 12:30:27 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1B5F16A4E5 for ; Wed, 2 Aug 2006 12:30:27 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7F6643D4C for ; Wed, 2 Aug 2006 12:30:21 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k72CULTW046902 for ; Wed, 2 Aug 2006 12:30:21 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k72CUL3f046901; Wed, 2 Aug 2006 12:30:21 GMT (envelope-from gnats) Date: Wed, 2 Aug 2006 12:30:21 GMT Message-Id: <200608021230.k72CUL3f046901@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Bruce Evans Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 12:30:28 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Bruce Evans To: Jo Rhett Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-i386@FreeBSD.org, njl@FreeBSD.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Wed, 2 Aug 2006 22:25:53 +1000 (EST) On Tue, 1 Aug 2006, Jo Rhett wrote: >> On Tue, 25 Jul 2006, Jo Rhett wrote: >>> In the middle of the boot process, right after saying "Mounting >>> ", com1 becomes com2 and vice versa. The console output >>> suddenly starts going to Serial A -- which is connected to a modem. Not >>> useful. > > On Jul 31, 2006, at 2:55 AM, Bruce Evans wrote: >> I think you just need to swap the ports in /boot/device.hints? Consoles >> are mostly low-level, and console initialization is very low level. >> The initialization is supposed to run before ACPI, etc. have had a >> chance to change the resource values dynamically (so that ACPI, etc. >> can print messages and otherwise be debugged), so when sio console >> initialization uses the apparently-higher-level resource access functions >> it is actually just using the hints, so the hints had better be correct >> -- they are more than hints. > > The hints are normal/standard but not working. Here's proof: > > root@arran 23# grep sio device.hints > hint.sio.0.at="isa" > hint.sio.0.port="0x3F8" > hint.sio.0.flags="0x10" > hint.sio.0.irq="4" > hint.sio.1.at="isa" > hint.sio.1.port="0x2F8" > hint.sio.1.irq="3" > > root@arran 24# dmesg |grep sio > sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 > sio0: type 16550A, console > sio1: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0 > sio1: type 16550A > > Heh? Hints says 0x3f8 should be sio0 and console... I can duplicate this. After swapping vanilla com ports in the BIOS on an A7N8X-E (Asus nForce2), ACPI in the 6.0-RELEASE kernel uses the flags hint but not the port or irq hints), gives the same inconsistent configuration: sio0: irq maps: 0x821 0x829 0x821 0x821 sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x90 on acpi0 sio0: type 16550A sio1: irq maps: 0x821 0x831 0x821 0x821 sio1: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0 sio1: type 16550A I think this indicates a workaround. Just configure sio1 with flags 0x90 in device.hints. I think acpi will use this hint but still ignore the others, so you would end up with the console port on the right hardware. The unit numbers of high-level sio ports ({cua,tty}d[0-1]) would be swapped but this wouldn't matter at all if you only the console port for a console. I think the fix for ACPI (and/or other "buses") would involve matching on all relevant hints for a given unit number. The port number is clearly relevant here (it is still "at" isa like device.hints says, although the above says "on acpi"). However, the irq number is irrelevant. >> I don't know exactly what happens with ACPI. Ideally, ACPI should set >> the resource values to match the BIOS, and this might involve ignoring >> most hints and this changing the values from their defaults, but for >> consoles any changes in the values would be wrong and might result in >> the high-level console (/dev/console) being attached to a different >> device than the low-level console (the one used for kernel printfs). > > It appears that ACPI is setting the sio order to match the order that the > BIOS lists them, which is completely arbitrary and downright wrong. Yes, the list order is bogus, but not very different from bus and/or probe order which tends to move disk drives around. Sio console configuration itself is documented to depend on a list order, but this was broken long ago. Partial fix for the documentation but not the bug: % Index: NOTES % =================================================================== % RCS file: /home/ncvs/src/sys/conf/NOTES,v % retrieving revision 1.1233 % diff -u -2 -r1.1233 NOTES % --- NOTES 22 Jun 2004 22:02:57 -0000 1.1233 % +++ NOTES 7 Apr 2005 20:27:21 -0000 % @@ -1520,10 +1520,18 @@ % # 0x10 enable console support for this unit. Other console flags % # (if applicable) are ignored unless this is set. Enabling % -# console support does not make the unit the preferred console. % -# Boot with -h or set boot_serial=YES in the loader. For sio(4) % +# console support does not make a serial device the % +# preferred console. % +# Boot with -h or set boot_serial=YES in the loader for that. % +# For sio(4) % # specifically, the 0x20 flag can also be set (see above). % # Currently, at most one unit can have console support; the % -# first one (in config file order) with this flag set is ^^^^^ ^^^^^^^^^^^^^^^^^^^^ % -# preferred. Setting this flag for sio0 gives the old behaviour. % +# last one (in unit number order) that has the 0x10 flag set ^^^^ ^^^^^^^^^^^^^^^^^^^^ % +# is selected. % +# Setting the 0x20 flag for _any_ sio unit that also has the % +# 0x10 flag set then makes the selected unit the preferred % +# console. % +# Setting the 0x40 flag for an sio unit cancels any settings % +# of the 0x10 and 0x20 flags (and most other flags) for that % +# unit. % # 0x80 use this port for serial line gdb support in ddb. Also known % # as debug port. This is missing documentation of the breakage of the search over all entries in the config file. The search is now limited unit numbers 0-15. In other words, precedence was determined by config file list order but is now determined by inverse unit number order except unit numbers >= 16 are now ignored. These bugs make putting an 0x10 flag on more than 1 port (with 0x20 to give extra precedence) even less useful than before. It used to be easy to control the order by moving lines in the config file, but unit numbers depend on hardware or firmware configuration which is harder to change. I'm still surprised that ACPI seems to affect the low-level sio console. The above boot messages are for high-level probes that don't do much with the console except avoid clobbering it and print where it is. If low-level console initialization used the correct flags hint but ACPI moved the hint later, then things would be very confusing. The code that avoids clobbering the decides where the console is by comparing the port number already decided from the flags earlier by lower-level code, while the code that prints where the console is use the current flags. If ACPI moves the flags hint late, then moving this hint to a consistently wrong port in device.hints like I suggested above would fix it for non-console flags but break it for most console flags. Non-console flags are rarely set so using the wrong flags hint would rarely affect non-consoles. Bruce From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 12:59:17 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FEF416A4DD; Wed, 2 Aug 2006 12:59:17 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D913C43D45; Wed, 2 Aug 2006 12:59:16 +0000 (GMT) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k72CxGhH050560; Wed, 2 Aug 2006 12:59:16 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k72CxG13050556; Wed, 2 Aug 2006 12:59:16 GMT (envelope-from bms) Date: Wed, 2 Aug 2006 12:59:16 GMT From: Bruce M Simpson Message-Id: <200608021259.k72CxG13050556@freefall.freebsd.org> To: bms@FreeBSD.org, bms@FreeBSD.org, freebsd-i386@FreeBSD.org Cc: Subject: Re: i386/61858: bus_dmamap_sync with BUS_DMASYNC_POSTREAD needs memory barrier. X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 12:59:17 -0000 Synopsis: bus_dmamap_sync with BUS_DMASYNC_POSTREAD needs memory barrier. Responsible-Changed-From-To: bms->freebsd-i386 Responsible-Changed-By: bms Responsible-Changed-When: Wed Aug 2 12:59:04 UTC 2006 Responsible-Changed-Why: back to the free pool http://www.freebsd.org/cgi/query-pr.cgi?pr=61858 From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 14:42:10 2006 Return-Path: X-Original-To: freebsd-i386@FreeBSD.org Delivered-To: freebsd-i386@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 376A216A4DE; Wed, 2 Aug 2006 14:42:10 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id B93AB43D72; Wed, 2 Aug 2006 14:42:04 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id 35E68209356; Thu, 3 Aug 2006 00:42:03 +1000 (EST) Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k72Eg01L004661; Thu, 3 Aug 2006 00:42:01 +1000 Date: Thu, 3 Aug 2006 00:42:00 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Jo Rhett In-Reply-To: <20060802205230.N90692@delplex.bde.org> Message-ID: <20060802234330.J1249@epsplex.bde.org> References: <200607252036.k6PKanFd072593@www.freebsd.org> <20060731191302.S1172@epsplex.bde.org> <6EFF87DF-280C-402C-8C2A-10F3144CF41F@svcolo.com> <20060802205230.N90692@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: njl@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org, freebsd-i386@FreeBSD.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 14:42:10 -0000 On Wed, 2 Aug 2006, Bruce Evans wrote: > ... > I'm still surprised that ACPI seems to affect the low-level sio console. > The above boot messages are for high-level probes that don't do much > with the console except avoid clobbering it and print where it is. If > low-level console initialization used the correct flags hint but ACPI > moved the hint later, then things would be very confusing. The code > that avoids clobbering the decides where the console is by comparing > the port number already decided from the flags earlier by lower-level > code, while the code that prints where the console is use the current > flags. If ACPI moves the flags hint late, then moving this hint to > a consistently wrong port in device.hints like I suggested above would > fix it for non-console flags but break it for most console flags. > Non-console flags are rarely set so using the wrong flags hint would > rarely affect non-consoles. In fact, ACPI doesn't affect the low-level console. The low-level unit and port are set to 0 and 0x3f8 here even after the swap. This is consistent with with what you reported: >* In the middle of the boot process, right after saying "Mounting ", >* com1 becomes com2 and vice versa. The console output suddenly starts going >* to Serial A -- which is connected to a modem. Not useful. >* During the shutdown process, console output reverts to the proper com1 >* assignment. I missed that the switch occurs quite late. I think it doesn't occur for the boot messages before "Mounting " and doesn't occur at all for low-level messages from kernel printfs (messages in the shutdown are a special case of these). I now think I understand the bug: - low-level console output works because low-level initialization just uses the hints and confusion between unit numbers later doesn't cause any relevant problems - high-level output doesn't work because low-level initialization decides the unit number for both the low level and the high level. It is typically 0 for port 0x3f8. High level i/o is then done on a different physical device (perhaps a nonexistent one) if high level initialization associates the relevant port with a different unit number. ACPI does this for swapped ports. ACPI also leaves the flags hint on the unit number specified in device.hints. This gives less obvious bugs. So only a limited workaround seems to be possible. There is currently no way to control ACPI's assignment of unit numbers, so device.hints must match that assignment. ACPI will use BIOS list order which associates unit 1 with port 0x3f8 in your preferred configuration. device.hints must match that to avoid later confusion but can't affect the unit numbers. You could keep COM1 == 0x3f8 in the boot loader and outside of FreeBSD but would have to swap unit numbers in device.hints and in all references to {tty,cua}d[0-1] in FreeBSD. Consoles actually cause the fewest problems here, since they can be refered to without using a unit number in most places and nothing except device.hints (or the driver) should need to be changed to make the references consistent. Bruce From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 14:50:22 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6F3916A4E0 for ; Wed, 2 Aug 2006 14:50:22 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB2E343D5E for ; Wed, 2 Aug 2006 14:50:17 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k72EoH0Z061422 for ; Wed, 2 Aug 2006 14:50:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k72EoHa0061421; Wed, 2 Aug 2006 14:50:17 GMT (envelope-from gnats) Date: Wed, 2 Aug 2006 14:50:17 GMT Message-Id: <200608021450.k72EoHa0061421@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Bruce Evans Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 14:50:22 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Bruce Evans To: Jo Rhett Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-i386@FreeBSD.org, njl@FreeBSD.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Thu, 3 Aug 2006 00:42:00 +1000 (EST) On Wed, 2 Aug 2006, Bruce Evans wrote: > ... > I'm still surprised that ACPI seems to affect the low-level sio console. > The above boot messages are for high-level probes that don't do much > with the console except avoid clobbering it and print where it is. If > low-level console initialization used the correct flags hint but ACPI > moved the hint later, then things would be very confusing. The code > that avoids clobbering the decides where the console is by comparing > the port number already decided from the flags earlier by lower-level > code, while the code that prints where the console is use the current > flags. If ACPI moves the flags hint late, then moving this hint to > a consistently wrong port in device.hints like I suggested above would > fix it for non-console flags but break it for most console flags. > Non-console flags are rarely set so using the wrong flags hint would > rarely affect non-consoles. In fact, ACPI doesn't affect the low-level console. The low-level unit and port are set to 0 and 0x3f8 here even after the swap. This is consistent with with what you reported: >* In the middle of the boot process, right after saying "Mounting ", >* com1 becomes com2 and vice versa. The console output suddenly starts going >* to Serial A -- which is connected to a modem. Not useful. >* During the shutdown process, console output reverts to the proper com1 >* assignment. I missed that the switch occurs quite late. I think it doesn't occur for the boot messages before "Mounting " and doesn't occur at all for low-level messages from kernel printfs (messages in the shutdown are a special case of these). I now think I understand the bug: - low-level console output works because low-level initialization just uses the hints and confusion between unit numbers later doesn't cause any relevant problems - high-level output doesn't work because low-level initialization decides the unit number for both the low level and the high level. It is typically 0 for port 0x3f8. High level i/o is then done on a different physical device (perhaps a nonexistent one) if high level initialization associates the relevant port with a different unit number. ACPI does this for swapped ports. ACPI also leaves the flags hint on the unit number specified in device.hints. This gives less obvious bugs. So only a limited workaround seems to be possible. There is currently no way to control ACPI's assignment of unit numbers, so device.hints must match that assignment. ACPI will use BIOS list order which associates unit 1 with port 0x3f8 in your preferred configuration. device.hints must match that to avoid later confusion but can't affect the unit numbers. You could keep COM1 == 0x3f8 in the boot loader and outside of FreeBSD but would have to swap unit numbers in device.hints and in all references to {tty,cua}d[0-1] in FreeBSD. Consoles actually cause the fewest problems here, since they can be refered to without using a unit number in most places and nothing except device.hints (or the driver) should need to be changed to make the references consistent. Bruce From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 15:07:28 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB5B616A4DF; Wed, 2 Aug 2006 15:07:28 +0000 (UTC) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D94643D5A; Wed, 2 Aug 2006 15:07:26 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k72F7Iix039916; Wed, 2 Aug 2006 08:07:25 -0700 (PDT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k72F6v6H051461; Wed, 2 Aug 2006 08:06:57 -0700 (PDT) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k72F6uVJ051456; Wed, 2 Aug 2006 08:06:56 -0700 (PDT) (envelope-from jrhett) Date: Wed, 2 Aug 2006 08:06:56 -0700 From: Jo Rhett To: Bruce Evans Message-ID: <20060802150656.GB47835@svcolo.com> References: <200607252036.k6PKanFd072593@www.freebsd.org> <20060731191302.S1172@epsplex.bde.org> <6EFF87DF-280C-402C-8C2A-10F3144CF41F@svcolo.com> <20060802205230.N90692@delplex.bde.org> <20060802234330.J1249@epsplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060802234330.J1249@epsplex.bde.org> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: njl@freebsd.org, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 15:07:28 -0000 On Thu, Aug 03, 2006 at 12:42:00AM +1000, Bruce Evans wrote: > So only a limited workaround seems to be possible. There is currently > no way to control ACPI's assignment of unit numbers, so device.hints > must match that assignment. ACPI will use BIOS list order which > associates unit 1 with port 0x3f8 in your preferred configuration. > device.hints must match that to avoid later confusion but can't affect > the unit numbers. You could keep COM1 == 0x3f8 in the boot loader and > outside of FreeBSD but would have to swap unit numbers in device.hints > and in all references to {tty,cua}d[0-1] in FreeBSD. Consoles actually > cause the fewest problems here, since they can be refered to without > using a unit number in most places and nothing except device.hints (or > the driver) should need to be changed to make the references consistent. Okay, I'm going to restate this in really simple terms. Tell me if I have it right. 1. We can't/won't fix the sio0<->sio1 problem because fixing ACPI is hard 2. The sio units are thus going to swap when entering high-level sio mode 3. The workaround is to put flags 0x10 (or 0x90) on sio1 4. There should be no ill effect from doing this. Console will never break and go to the wrong port. #4 is crucial to us. Many of these machines are completely unavailable to me for an emergency. This console is our "last chance access" -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 15:10:28 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53A5E16A4DE for ; Wed, 2 Aug 2006 15:10:28 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1E0343D77 for ; Wed, 2 Aug 2006 15:10:20 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k72FAKo2062617 for ; Wed, 2 Aug 2006 15:10:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k72FAK9k062616; Wed, 2 Aug 2006 15:10:20 GMT (envelope-from gnats) Date: Wed, 2 Aug 2006 15:10:20 GMT Message-Id: <200608021510.k72FAK9k062616@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Jo Rhett Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jo Rhett List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 15:10:28 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Jo Rhett To: Bruce Evans Cc: freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org, njl@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Wed, 2 Aug 2006 08:06:56 -0700 On Thu, Aug 03, 2006 at 12:42:00AM +1000, Bruce Evans wrote: > So only a limited workaround seems to be possible. There is currently > no way to control ACPI's assignment of unit numbers, so device.hints > must match that assignment. ACPI will use BIOS list order which > associates unit 1 with port 0x3f8 in your preferred configuration. > device.hints must match that to avoid later confusion but can't affect > the unit numbers. You could keep COM1 == 0x3f8 in the boot loader and > outside of FreeBSD but would have to swap unit numbers in device.hints > and in all references to {tty,cua}d[0-1] in FreeBSD. Consoles actually > cause the fewest problems here, since they can be refered to without > using a unit number in most places and nothing except device.hints (or > the driver) should need to be changed to make the references consistent. Okay, I'm going to restate this in really simple terms. Tell me if I have it right. 1. We can't/won't fix the sio0<->sio1 problem because fixing ACPI is hard 2. The sio units are thus going to swap when entering high-level sio mode 3. The workaround is to put flags 0x10 (or 0x90) on sio1 4. There should be no ill effect from doing this. Console will never break and go to the wrong port. #4 is crucial to us. Many of these machines are completely unavailable to me for an emergency. This console is our "last chance access" -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 17:25:33 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FCE216A4E2; Wed, 2 Aug 2006 17:25:33 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB8B643D49; Wed, 2 Aug 2006 17:25:32 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id A7290209391; Thu, 3 Aug 2006 03:25:31 +1000 (EST) Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k72HPTBk030684; Thu, 3 Aug 2006 03:25:30 +1000 Date: Thu, 3 Aug 2006 03:25:28 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Jo Rhett In-Reply-To: <20060802150656.GB47835@svcolo.com> Message-ID: <20060803024810.X1573@epsplex.bde.org> References: <200607252036.k6PKanFd072593@www.freebsd.org> <20060731191302.S1172@epsplex.bde.org> <6EFF87DF-280C-402C-8C2A-10F3144CF41F@svcolo.com> <20060802205230.N90692@delplex.bde.org> <20060802234330.J1249@epsplex.bde.org> <20060802150656.GB47835@svcolo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: njl@freebsd.org, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 17:25:33 -0000 On Wed, 2 Aug 2006, Jo Rhett wrote: > Okay, I'm going to restate this in really simple terms. Tell me if I have > it right. > > 1. We can't/won't fix the sio0<->sio1 problem because fixing ACPI is hard _I_ can't/won't fix it because not just the above :-). Swapping of consoles only could be fixed within the driver (so that ACPI is not involved and you don't have to change device.hints) since consoles have to be hard-wired in some way and the hints are good enough for wiring the unit number to the i/o address (provided it's an old ISA port -- otherwise hints based on the i/o address don't work). > 2. The sio units are thus going to swap when entering high-level sio mode > > 3. The workaround is to put flags 0x10 (or 0x90) on sio1 It also needs the port numbers swapped (for consoles to work) and other hints swapped (to be consistent, so as to work if there is no ACPI so the other hints are actually used). > 4. There should be no ill effect from doing this. Console will never break > and go to the wrong port. > > #4 is crucial to us. Many of these machines are completely unavailable to > me for an emergency. This console is our "last chance access" Yes, "should be". The wiring should be fairly deterministic once you get it to work. I think it will continue to work even if someone fixes (?) ACPI to prefer the hints order to the ACPI order. However, it would break if someone fixes (?) ACPI to prefer the BIOS order to both the hints order and the ACPI order (I think ACPI is using its own order and doesn't know that you've swapped the order in the BIOS). I just happened to boot an early version of 5.x for other reasons, and notices that it doesn't print the flags for sio devices on acpi0. This is because flags weren't propagated to sub-buses/devices at all until a year or two ago. njl fixed this. Not propagating flags mainly broke the non-console case since the console flags are mostly used at levels below the bus level. Bruce From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 17:30:30 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5312216A4DA for ; Wed, 2 Aug 2006 17:30:30 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58D9843D70 for ; Wed, 2 Aug 2006 17:30:24 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k72HUNPx075541 for ; Wed, 2 Aug 2006 17:30:23 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k72HUN4U075540; Wed, 2 Aug 2006 17:30:23 GMT (envelope-from gnats) Date: Wed, 2 Aug 2006 17:30:23 GMT Message-Id: <200608021730.k72HUN4U075540@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Bruce Evans Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 17:30:30 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Bruce Evans To: Jo Rhett Cc: freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org, njl@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Thu, 3 Aug 2006 03:25:28 +1000 (EST) On Wed, 2 Aug 2006, Jo Rhett wrote: > Okay, I'm going to restate this in really simple terms. Tell me if I have > it right. > > 1. We can't/won't fix the sio0<->sio1 problem because fixing ACPI is hard _I_ can't/won't fix it because not just the above :-). Swapping of consoles only could be fixed within the driver (so that ACPI is not involved and you don't have to change device.hints) since consoles have to be hard-wired in some way and the hints are good enough for wiring the unit number to the i/o address (provided it's an old ISA port -- otherwise hints based on the i/o address don't work). > 2. The sio units are thus going to swap when entering high-level sio mode > > 3. The workaround is to put flags 0x10 (or 0x90) on sio1 It also needs the port numbers swapped (for consoles to work) and other hints swapped (to be consistent, so as to work if there is no ACPI so the other hints are actually used). > 4. There should be no ill effect from doing this. Console will never break > and go to the wrong port. > > #4 is crucial to us. Many of these machines are completely unavailable to > me for an emergency. This console is our "last chance access" Yes, "should be". The wiring should be fairly deterministic once you get it to work. I think it will continue to work even if someone fixes (?) ACPI to prefer the hints order to the ACPI order. However, it would break if someone fixes (?) ACPI to prefer the BIOS order to both the hints order and the ACPI order (I think ACPI is using its own order and doesn't know that you've swapped the order in the BIOS). I just happened to boot an early version of 5.x for other reasons, and notices that it doesn't print the flags for sio devices on acpi0. This is because flags weren't propagated to sub-buses/devices at all until a year or two ago. njl fixed this. Not propagating flags mainly broke the non-console case since the console flags are mostly used at levels below the bus level. Bruce From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 17:41:26 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7838016A4DE; Wed, 2 Aug 2006 17:41:26 +0000 (UTC) (envelope-from jrhett@svcolo.com) Received: from outbound0.sv.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id D73AF43D70; Wed, 2 Aug 2006 17:41:24 +0000 (GMT) (envelope-from jrhett@svcolo.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k72HfKjI056410; Wed, 2 Aug 2006 10:41:24 -0700 (PDT) (envelope-from jrhett@svcolo.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k72HepZP006133; Wed, 2 Aug 2006 10:40:51 -0700 (PDT) (envelope-from jrhett@svcolo.com) In-Reply-To: <20060803024810.X1573@epsplex.bde.org> References: <200607252036.k6PKanFd072593@www.freebsd.org> <20060731191302.S1172@epsplex.bde.org> <6EFF87DF-280C-402C-8C2A-10F3144CF41F@svcolo.com> <20060802205230.N90692@delplex.bde.org> <20060802234330.J1249@epsplex.bde.org> <20060802150656.GB47835@svcolo.com> <20060803024810.X1573@epsplex.bde.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <83D35AA9-61D2-4977-AFEC-C498F4147FC2@svcolo.com> Content-Transfer-Encoding: 7bit From: Jo Rhett Date: Wed, 2 Aug 2006 10:40:49 -0700 To: Bruce Evans X-Mailer: Apple Mail (2.752.2) Cc: njl@freebsd.org, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 17:41:26 -0000 > On Wed, 2 Aug 2006, Jo Rhett wrote: >> 1. We can't/won't fix the sio0<->sio1 problem because fixing ACPI >> is hard On Aug 2, 2006, at 10:25 AM, Bruce Evans wrote: > _I_ can't/won't fix it because not just the above :-). Swapping of > consoles > only could be fixed within the driver (so that ACPI is not involved > and > you don't have to change device.hints) since consoles have to be > hard-wired > in some way and the hints are good enough for wiring the unit > number to > the i/o address (provided it's an old ISA port -- otherwise hints > based > on the i/o address don't work). Sorry, color me dumb. I'm getting lost here. The problem I was observing is that device hints is being (mostly) ignored by ACPI and thus this is the root problem to fix. I'm not sure what you're trying to say here. >> 2. The sio units are thus going to swap when entering high-level >> sio mode >> 3. The workaround is to put flags 0x10 (or 0x90) on sio1 > > It also needs the port numbers swapped (for consoles to work) and > other hints > swapped (to be consistent, so as to work if there is no ACPI so the > other > hints are actually used) Can you provide a clear list of instructions then? I have no idea what you mean by "port numbers swapped". Swapped where? I was assuming /boot.config has -Dh /boot/loader.conf has console="comconsole" /boot/device.hints comment out #hint.sio.0.flags="0x10" /boot/device.hints add hint.sio.1.flags="0x10" /etc/ttys - put a getty on ttyd1 What am I missing? If I understand correctly, the boot loader compiled in option sio0 on 0x3f8 flags 0x10 will be in effect until the higher level sio driver is loaded, at which point it reassigns all the ports based on ACPI and device.hints and the two changes to device.hints above will take effect, yes? >> 4. There should be no ill effect from doing this. Console will >> never break >> and go to the wrong port. > > Yes, "should be". The wiring should be fairly deterministic once you > get it to work. I think it will continue to work even if someone > fixes > (?) ACPI to prefer the hints order to the ACPI order. However, it > would > break if someone fixes (?) ACPI to prefer the BIOS order to both > the hints > order and the ACPI order (I think ACPI is using its own order and > doesn't > know that you've swapped the order in the BIOS). I'm not sure I understand the difference. The ACPI order is the order that the BIOS presents them in when querying it via ACPI, yes? -- Jo Rhett senior geek Silicon Valley Colocation From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 17:50:19 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76C7E16A4E0 for ; Wed, 2 Aug 2006 17:50:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A52343D45 for ; Wed, 2 Aug 2006 17:50:19 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k72HoIJ5077808 for ; Wed, 2 Aug 2006 17:50:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k72HoImP077807; Wed, 2 Aug 2006 17:50:18 GMT (envelope-from gnats) Date: Wed, 2 Aug 2006 17:50:18 GMT Message-Id: <200608021750.k72HoImP077807@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Jo Rhett Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jo Rhett List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 17:50:19 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Jo Rhett To: Bruce Evans Cc: freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org, njl@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Wed, 2 Aug 2006 10:40:49 -0700 > On Wed, 2 Aug 2006, Jo Rhett wrote: >> 1. We can't/won't fix the sio0<->sio1 problem because fixing ACPI >> is hard On Aug 2, 2006, at 10:25 AM, Bruce Evans wrote: > _I_ can't/won't fix it because not just the above :-). Swapping of > consoles > only could be fixed within the driver (so that ACPI is not involved > and > you don't have to change device.hints) since consoles have to be > hard-wired > in some way and the hints are good enough for wiring the unit > number to > the i/o address (provided it's an old ISA port -- otherwise hints > based > on the i/o address don't work). Sorry, color me dumb. I'm getting lost here. The problem I was observing is that device hints is being (mostly) ignored by ACPI and thus this is the root problem to fix. I'm not sure what you're trying to say here. >> 2. The sio units are thus going to swap when entering high-level >> sio mode >> 3. The workaround is to put flags 0x10 (or 0x90) on sio1 > > It also needs the port numbers swapped (for consoles to work) and > other hints > swapped (to be consistent, so as to work if there is no ACPI so the > other > hints are actually used) Can you provide a clear list of instructions then? I have no idea what you mean by "port numbers swapped". Swapped where? I was assuming /boot.config has -Dh /boot/loader.conf has console="comconsole" /boot/device.hints comment out #hint.sio.0.flags="0x10" /boot/device.hints add hint.sio.1.flags="0x10" /etc/ttys - put a getty on ttyd1 What am I missing? If I understand correctly, the boot loader compiled in option sio0 on 0x3f8 flags 0x10 will be in effect until the higher level sio driver is loaded, at which point it reassigns all the ports based on ACPI and device.hints and the two changes to device.hints above will take effect, yes? >> 4. There should be no ill effect from doing this. Console will >> never break >> and go to the wrong port. > > Yes, "should be". The wiring should be fairly deterministic once you > get it to work. I think it will continue to work even if someone > fixes > (?) ACPI to prefer the hints order to the ACPI order. However, it > would > break if someone fixes (?) ACPI to prefer the BIOS order to both > the hints > order and the ACPI order (I think ACPI is using its own order and > doesn't > know that you've swapped the order in the BIOS). I'm not sure I understand the difference. The ACPI order is the order that the BIOS presents them in when querying it via ACPI, yes? -- Jo Rhett senior geek Silicon Valley Colocation From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 18:30:17 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D08F116A4DA for ; Wed, 2 Aug 2006 18:30:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 488B443D46 for ; Wed, 2 Aug 2006 18:30:17 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k72IUHe3080305 for ; Wed, 2 Aug 2006 18:30:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k72IUH3d080300; Wed, 2 Aug 2006 18:30:17 GMT (envelope-from gnats) Resent-Date: Wed, 2 Aug 2006 18:30:17 GMT Resent-Message-Id: <200608021830.k72IUH3d080300@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Patrick Wolfe Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B6D316A4DD for ; Wed, 2 Aug 2006 18:21:53 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2822243D53 for ; Wed, 2 Aug 2006 18:21:53 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k72ILqi2021400 for ; Wed, 2 Aug 2006 18:21:52 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k72ILqdv021399; Wed, 2 Aug 2006 18:21:52 GMT (envelope-from nobody) Message-Id: <200608021821.k72ILqdv021399@www.freebsd.org> Date: Wed, 2 Aug 2006 18:21:52 GMT From: Patrick Wolfe To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: i386/101275: bug fixed in sudo that prevented use in LDAP user account environment X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 18:30:18 -0000 >Number: 101275 >Category: i386 >Synopsis: bug fixed in sudo that prevented use in LDAP user account environment >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Aug 02 18:30:16 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Patrick Wolfe >Release: 6.1 >Organization: Employease Inc >Environment: FreeBSD kobe.tek.eease.com 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04:42:56 UTC 2006 root@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP i386 >Description: Our network uses LDAP login authentication. It's working fine on CentOS 4.3, FreeBSD 5.4 and FreeBSD 6.1, except on the FreeBSD boxes, sudo V1.6.8p12 (from the ports tree) only works if the user has an entry in the local password file. LDAP accounts get the error message "uid ##### does not exist in the passwd file". I did some troubleshooting, and discovered that if I comment out line 174 of file sudo.c (environ = zero_env(envp);) sudo works for ldap accounts. I searched for the use of "environ" variable, and learned that line 174 of sudo.c, "environ = zero_env(envp);", is not needed at all, since the value of environ is never used before it's reassigned later at line 414. I have reported this to the SUDO maintainers as well, but thought the FreeBSD ports maintainers and any other FREEBSD/LDAP users might like to know about this fix as well. Attached is a simple patch to fix the problem. >How-To-Repeat: - configure a FreeBSD box to use pam_ldap and nss_ldap for centralized network account management - login to said box using an account that is defined in LDAP database, NOT in the local /etc/passwd file. - attempt to run "sudo" - stare in amazement when sudo reports your uid is not found in /etc/passwd (well DUH!) >Fix: Apply this patch *** sudo.c.orig Wed Aug 2 14:13:27 2006 --- sudo.c Wed Aug 2 14:18:17 2006 *************** *** 171,177 **** #endif /* HAVE_GETPRPWNAM && HAVE_SET_AUTH_PARAMETERS */ /* Zero out the environment. */ ! environ = zero_env(envp); if (geteuid() != 0) errx(1, "must be setuid root"); --- 171,183 ---- #endif /* HAVE_GETPRPWNAM && HAVE_SET_AUTH_PARAMETERS */ /* Zero out the environment. */ ! /* ! * after the call to zero_env, all later calls to ! * getpwuid(getuid()) are broken for NON-LOCAL accounts, ! * and besides that, the value assigned to environ is NEVER USED. ! * ... pjw 2006-08-02 ! */ ! /*environ = zero_env(envp);*/ if (geteuid() != 0) errx(1, "must be setuid root"); >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 19:32:41 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AC3B16A4E5; Wed, 2 Aug 2006 19:32:41 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9AB143D45; Wed, 2 Aug 2006 19:32:40 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id 82C0910A2D7; Thu, 3 Aug 2006 05:32:39 +1000 (EST) Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k72JWaYZ030904; Thu, 3 Aug 2006 05:32:37 +1000 Date: Thu, 3 Aug 2006 05:32:35 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Jo Rhett In-Reply-To: <83D35AA9-61D2-4977-AFEC-C498F4147FC2@svcolo.com> Message-ID: <20060803041522.F2135@epsplex.bde.org> References: <200607252036.k6PKanFd072593@www.freebsd.org> <20060731191302.S1172@epsplex.bde.org> <6EFF87DF-280C-402C-8C2A-10F3144CF41F@svcolo.com> <20060802205230.N90692@delplex.bde.org> <20060802234330.J1249@epsplex.bde.org> <20060802150656.GB47835@svcolo.com> <20060803024810.X1573@epsplex.bde.org> <83D35AA9-61D2-4977-AFEC-C498F4147FC2@svcolo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: njl@freebsd.org, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 19:32:41 -0000 On Wed, 2 Aug 2006, Jo Rhett wrote: >> On Wed, 2 Aug 2006, Jo Rhett wrote: >>> 1. We can't/won't fix the sio0<->sio1 problem because fixing ACPI is hard > > On Aug 2, 2006, at 10:25 AM, Bruce Evans wrote: >> _I_ can't/won't fix it because not just the above :-). Swapping of >> consoles >> only could be fixed within the driver (so that ACPI is not involved and >> you don't have to change device.hints) since consoles have to be hard-wired >> in some way and the hints are good enough for wiring the unit number to >> the i/o address (provided it's an old ISA port -- otherwise hints based >> on the i/o address don't work). > > Sorry, color me dumb. I'm getting lost here. The problem I was observing is > that device hints is being (mostly) ignored by ACPI and thus this is the root > problem to fix. I'm not sure what you're trying to say here. Console drivers have to and do use the hints directly so as to work before bus stuff like ACPI is initializated. After bus stuff is initialized, they could keep using the working configuration read from device.hints. sio already does this in most places, but in one place it neither checks for nor fixes up inconsistencies caused by ACPI ignoring the hints. >>> 2. The sio units are thus going to swap when entering high-level sio mode >>> 3. The workaround is to put flags 0x10 (or 0x90) on sio1 >> >> It also needs the port numbers swapped (for consoles to work) and other >> hints >> swapped (to be consistent, so as to work if there is no ACPI so the other >> hints are actually used) > > Can you provide a clear list of instructions then? I have no idea what you > mean by "port numbers swapped". Swapped where? Since it is too hard to change ACPI to use the hints, change the hints to give the same configuration as ACPI will give. For 2 ports, you've already swapped them in the BIOS, but ACPI doesn't see that so they must be swapped back in device.hints to match. This loses the benefits of the swapping inside FreeBSD but keeps them outside of FreeBSD including in the boot loader. I don't know if this is enough for you or if the benefits of the swapping are larger enough for it to be worth doing when you lose them inside FreeBSD. > I was assuming > /boot.config has -Dh > /boot/loader.conf has console="comconsole" Not changes to booting -- it keeps using COM1. > /boot/device.hints comment out #hint.sio.0.flags="0x10" > /boot/device.hints add hint.sio.1.flags="0x10" Swap all sio.0 entries, with the corresponding sio.1 entries, or if you only need to use the port at 0x3f8, then comment out or remove all sio.0 entries and change all sio.1 entries to have the previous values of the sio.0 entries. If both units had a console flag like 0x10 set for some reason, then to avoid complications, remove the one that you don't want instead of swapping it. > /etc/ttys - put a getty on ttyd1 Yes, since ttyd* is a logically separate device from the console, it is not affected by changing device.hints. > What am I missing? > > If I understand correctly, the boot loader compiled in option sio0 on 0x3f8 > flags 0x10 will be in effect until the higher level sio driver is loaded, at Right. At this point, unit numbers are only partly used. I think they are used by sio0 to talk to the BIOS and there is a numerical unit number 0 or 1 to talk to the BIOS on COM1 (or whatever is configured), but this is a bug -- the BIOS is limited to 9600 bps but everyone/everything should use 115200 bps or larger. Then in boot2, there is only an i/o port address to select the port, and 115200 bps has always been supported. > which point it reassigns all the ports based on ACPI and device.hints and the > two changes to device.hints above will take effect, yes? Not quite. The sio driver first initializes the low-level parts of the console driver (if the console is on sio) using device.hints, and some other subsystems and/or drivers print messages on the console. At this point, the unit number is only used to associate the hint for sio.N's flags with the hint for sio.N's port. Eventually the ACPI subsystem runs and sets up a different association. ACPI also uses the console to print messages about itself (ACPI). Some time later, the sio driver initializes high-level parts of itself including high-level parts of the console driver. This gives an inconsistency because the ACPI unit number association is different and the difference is not detected or fixed up. The high-level parts are not used at this point, and sio uses the console driver uses itself to print messages about itself (including the console part of itself). Next, other subsystems and drivers print messages on the low-level console. Eventually, the high-level console is used and i/o to it will go to an inconsistent plays if ACPI disagrees with device.hints about the unit numbers. Changes to device.hints take effect in the first step by avoiding inconsistencies later, but the effects of the inconsistencies are not visible until the last step. >>> 4. There should be no ill effect from doing this. Console will never >>> break >>> and go to the wrong port. >> >> Yes, "should be". The wiring should be fairly deterministic once you >> get it to work. I think it will continue to work even if someone fixes >> (?) ACPI to prefer the hints order to the ACPI order. However, it would >> break if someone fixes (?) ACPI to prefer the BIOS order to both the hints >> order and the ACPI order (I think ACPI is using its own order and doesn't >> know that you've swapped the order in the BIOS). > > I'm not sure I understand the difference. The ACPI order is the order that > the BIOS presents them in when querying it via ACPI, yes? I don't completely understand this either. I think there is a non-ACPI part of the BIOS that FreeBSD (or all OS's doesn't see). As I understand your configuration, you start with COM1 and COM2 at the usual places but don't want to use COM1 so you change the BIOS settings for COM2 to the usual ones for COM1 and maybe vice versa. This changes soft jumpers or whatever is needed for FreeBSD to see it. Then you use a BIOS option to swap the ports so that everything is supposed to see COM2 as COM1. The boot loader sees this but ACPI in FreeBSD doesn't. I think this changes is only made in some BIOS table that ACPI in FreeBSD doesn't know about. In my test, I only swapped the settings of COM1 and COM2 in the BIOS, since I couldn't find a BIOS option to swap the unit number assignments, so it was not completely incorrect for ACPI in FreeBSD to swap the settings. Bruce From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 19:40:20 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB89916A4E2 for ; Wed, 2 Aug 2006 19:40:20 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 775B843D5E for ; Wed, 2 Aug 2006 19:40:19 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k72JeIeP087225 for ; Wed, 2 Aug 2006 19:40:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k72JeIAR087224; Wed, 2 Aug 2006 19:40:18 GMT (envelope-from gnats) Date: Wed, 2 Aug 2006 19:40:18 GMT Message-Id: <200608021940.k72JeIAR087224@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Bruce Evans Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 19:40:20 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Bruce Evans To: Jo Rhett Cc: freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org, njl@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Thu, 3 Aug 2006 05:32:35 +1000 (EST) On Wed, 2 Aug 2006, Jo Rhett wrote: >> On Wed, 2 Aug 2006, Jo Rhett wrote: >>> 1. We can't/won't fix the sio0<->sio1 problem because fixing ACPI is hard > > On Aug 2, 2006, at 10:25 AM, Bruce Evans wrote: >> _I_ can't/won't fix it because not just the above :-). Swapping of >> consoles >> only could be fixed within the driver (so that ACPI is not involved and >> you don't have to change device.hints) since consoles have to be hard-wired >> in some way and the hints are good enough for wiring the unit number to >> the i/o address (provided it's an old ISA port -- otherwise hints based >> on the i/o address don't work). > > Sorry, color me dumb. I'm getting lost here. The problem I was observing is > that device hints is being (mostly) ignored by ACPI and thus this is the root > problem to fix. I'm not sure what you're trying to say here. Console drivers have to and do use the hints directly so as to work before bus stuff like ACPI is initializated. After bus stuff is initialized, they could keep using the working configuration read from device.hints. sio already does this in most places, but in one place it neither checks for nor fixes up inconsistencies caused by ACPI ignoring the hints. >>> 2. The sio units are thus going to swap when entering high-level sio mode >>> 3. The workaround is to put flags 0x10 (or 0x90) on sio1 >> >> It also needs the port numbers swapped (for consoles to work) and other >> hints >> swapped (to be consistent, so as to work if there is no ACPI so the other >> hints are actually used) > > Can you provide a clear list of instructions then? I have no idea what you > mean by "port numbers swapped". Swapped where? Since it is too hard to change ACPI to use the hints, change the hints to give the same configuration as ACPI will give. For 2 ports, you've already swapped them in the BIOS, but ACPI doesn't see that so they must be swapped back in device.hints to match. This loses the benefits of the swapping inside FreeBSD but keeps them outside of FreeBSD including in the boot loader. I don't know if this is enough for you or if the benefits of the swapping are larger enough for it to be worth doing when you lose them inside FreeBSD. > I was assuming > /boot.config has -Dh > /boot/loader.conf has console="comconsole" Not changes to booting -- it keeps using COM1. > /boot/device.hints comment out #hint.sio.0.flags="0x10" > /boot/device.hints add hint.sio.1.flags="0x10" Swap all sio.0 entries, with the corresponding sio.1 entries, or if you only need to use the port at 0x3f8, then comment out or remove all sio.0 entries and change all sio.1 entries to have the previous values of the sio.0 entries. If both units had a console flag like 0x10 set for some reason, then to avoid complications, remove the one that you don't want instead of swapping it. > /etc/ttys - put a getty on ttyd1 Yes, since ttyd* is a logically separate device from the console, it is not affected by changing device.hints. > What am I missing? > > If I understand correctly, the boot loader compiled in option sio0 on 0x3f8 > flags 0x10 will be in effect until the higher level sio driver is loaded, at Right. At this point, unit numbers are only partly used. I think they are used by sio0 to talk to the BIOS and there is a numerical unit number 0 or 1 to talk to the BIOS on COM1 (or whatever is configured), but this is a bug -- the BIOS is limited to 9600 bps but everyone/everything should use 115200 bps or larger. Then in boot2, there is only an i/o port address to select the port, and 115200 bps has always been supported. > which point it reassigns all the ports based on ACPI and device.hints and the > two changes to device.hints above will take effect, yes? Not quite. The sio driver first initializes the low-level parts of the console driver (if the console is on sio) using device.hints, and some other subsystems and/or drivers print messages on the console. At this point, the unit number is only used to associate the hint for sio.N's flags with the hint for sio.N's port. Eventually the ACPI subsystem runs and sets up a different association. ACPI also uses the console to print messages about itself (ACPI). Some time later, the sio driver initializes high-level parts of itself including high-level parts of the console driver. This gives an inconsistency because the ACPI unit number association is different and the difference is not detected or fixed up. The high-level parts are not used at this point, and sio uses the console driver uses itself to print messages about itself (including the console part of itself). Next, other subsystems and drivers print messages on the low-level console. Eventually, the high-level console is used and i/o to it will go to an inconsistent plays if ACPI disagrees with device.hints about the unit numbers. Changes to device.hints take effect in the first step by avoiding inconsistencies later, but the effects of the inconsistencies are not visible until the last step. >>> 4. There should be no ill effect from doing this. Console will never >>> break >>> and go to the wrong port. >> >> Yes, "should be". The wiring should be fairly deterministic once you >> get it to work. I think it will continue to work even if someone fixes >> (?) ACPI to prefer the hints order to the ACPI order. However, it would >> break if someone fixes (?) ACPI to prefer the BIOS order to both the hints >> order and the ACPI order (I think ACPI is using its own order and doesn't >> know that you've swapped the order in the BIOS). > > I'm not sure I understand the difference. The ACPI order is the order that > the BIOS presents them in when querying it via ACPI, yes? I don't completely understand this either. I think there is a non-ACPI part of the BIOS that FreeBSD (or all OS's doesn't see). As I understand your configuration, you start with COM1 and COM2 at the usual places but don't want to use COM1 so you change the BIOS settings for COM2 to the usual ones for COM1 and maybe vice versa. This changes soft jumpers or whatever is needed for FreeBSD to see it. Then you use a BIOS option to swap the ports so that everything is supposed to see COM2 as COM1. The boot loader sees this but ACPI in FreeBSD doesn't. I think this changes is only made in some BIOS table that ACPI in FreeBSD doesn't know about. In my test, I only swapped the settings of COM1 and COM2 in the BIOS, since I couldn't find a BIOS option to swap the unit number assignments, so it was not completely incorrect for ACPI in FreeBSD to swap the settings. Bruce From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 19:54:02 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45FF516A4DE; Wed, 2 Aug 2006 19:54:02 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EB1543D45; Wed, 2 Aug 2006 19:54:01 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id BC08410A1C7; Thu, 3 Aug 2006 05:54:00 +1000 (EST) Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k72JrwWh009679; Thu, 3 Aug 2006 05:53:59 +1000 Date: Thu, 3 Aug 2006 05:53:58 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Jo Rhett In-Reply-To: <20060803041522.F2135@epsplex.bde.org> Message-ID: <20060803055353.K635@epsplex.bde.org> References: <200607252036.k6PKanFd072593@www.freebsd.org> <20060731191302.S1172@epsplex.bde.org> <6EFF87DF-280C-402C-8C2A-10F3144CF41F@svcolo.com> <20060802205230.N90692@delplex.bde.org> <20060802234330.J1249@epsplex.bde.org> <20060802150656.GB47835@svcolo.com> <20060803024810.X1573@epsplex.bde.org> <83D35AA9-61D2-4977-AFEC-C498F4147FC2@svcolo.com> <20060803041522.F2135@epsplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: njl@freebsd.org, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 19:54:02 -0000 On Thu, 3 Aug 2006, Bruce Evans wrote: > On Wed, 2 Aug 2006, Jo Rhett wrote: >>>> 4. There should be no ill effect from doing this. Console will never >>>> break >>>> and go to the wrong port. >>> >>> Yes, "should be". The wiring should be fairly deterministic once you >>> get it to work. I think it will continue to work even if someone fixes >>> (?) ACPI to prefer the hints order to the ACPI order. However, it would >>> break if someone fixes (?) ACPI to prefer the BIOS order to both the hints >>> order and the ACPI order (I think ACPI is using its own order and doesn't >>> know that you've swapped the order in the BIOS). >> >> I'm not sure I understand the difference. The ACPI order is the order that >> the BIOS presents them in when querying it via ACPI, yes? > > I don't completely understand this either. I think there is a non-ACPI part > of the BIOS that FreeBSD (or all OS's doesn't see). As I understand your > configuration, you start with COM1 and COM2 at the usual places but don't > want to use COM1 so you change the BIOS settings for COM2 to the usual ones > for COM1 and maybe vice versa. This changes soft jumpers or whatever is > needed for FreeBSD to see it. Then you use a BIOS option to swap the ports > so that everything is supposed to see COM2 as COM1. The boot loader sees > this but ACPI in FreeBSD doesn't. I think this changes is only made in > some BIOS table that ACPI in FreeBSD doesn't know about. In my test, I > only swapped the settings of COM1 and COM2 in the BIOS, since I couldn't > find a BIOS option to swap the unit number assignments, so it was not > completely incorrect for ACPI in FreeBSD to swap the settings. More details on my test: - after swapping the settings of COM1 and COM2, both FreeBSD-ACPI and WinXP see only the settings swapped. WinXP didn't report any changes to the devices. I now think this is completely correct. Swapping like this requires swapping in device.hints to keep the same assignment of physical devices to unit numbers. - after swapping the settings and then disabling COM1, FreeBSD-ACPI moves COM2 down to COM1 (sio0) and sio1 goes away, while WinXP doesn't change unit numbers and COM1 goes away. I think the WinXP behaviour is correct and FreeBSD-ACPI just allocates unit numbers starting at 0. Bruce From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 20:00:45 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9BC716A4DE for ; Wed, 2 Aug 2006 20:00:45 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 188F543D70 for ; Wed, 2 Aug 2006 20:00:43 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k72K0g8R088459 for ; Wed, 2 Aug 2006 20:00:42 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k72K0g8w088458; Wed, 2 Aug 2006 20:00:42 GMT (envelope-from gnats) Date: Wed, 2 Aug 2006 20:00:42 GMT Message-Id: <200608022000.k72K0g8w088458@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Bruce Evans Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 20:00:46 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Bruce Evans To: Jo Rhett Cc: freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org, njl@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Thu, 3 Aug 2006 05:53:58 +1000 (EST) On Thu, 3 Aug 2006, Bruce Evans wrote: > On Wed, 2 Aug 2006, Jo Rhett wrote: >>>> 4. There should be no ill effect from doing this. Console will never >>>> break >>>> and go to the wrong port. >>> >>> Yes, "should be". The wiring should be fairly deterministic once you >>> get it to work. I think it will continue to work even if someone fixes >>> (?) ACPI to prefer the hints order to the ACPI order. However, it would >>> break if someone fixes (?) ACPI to prefer the BIOS order to both the hints >>> order and the ACPI order (I think ACPI is using its own order and doesn't >>> know that you've swapped the order in the BIOS). >> >> I'm not sure I understand the difference. The ACPI order is the order that >> the BIOS presents them in when querying it via ACPI, yes? > > I don't completely understand this either. I think there is a non-ACPI part > of the BIOS that FreeBSD (or all OS's doesn't see). As I understand your > configuration, you start with COM1 and COM2 at the usual places but don't > want to use COM1 so you change the BIOS settings for COM2 to the usual ones > for COM1 and maybe vice versa. This changes soft jumpers or whatever is > needed for FreeBSD to see it. Then you use a BIOS option to swap the ports > so that everything is supposed to see COM2 as COM1. The boot loader sees > this but ACPI in FreeBSD doesn't. I think this changes is only made in > some BIOS table that ACPI in FreeBSD doesn't know about. In my test, I > only swapped the settings of COM1 and COM2 in the BIOS, since I couldn't > find a BIOS option to swap the unit number assignments, so it was not > completely incorrect for ACPI in FreeBSD to swap the settings. More details on my test: - after swapping the settings of COM1 and COM2, both FreeBSD-ACPI and WinXP see only the settings swapped. WinXP didn't report any changes to the devices. I now think this is completely correct. Swapping like this requires swapping in device.hints to keep the same assignment of physical devices to unit numbers. - after swapping the settings and then disabling COM1, FreeBSD-ACPI moves COM2 down to COM1 (sio0) and sio1 goes away, while WinXP doesn't change unit numbers and COM1 goes away. I think the WinXP behaviour is correct and FreeBSD-ACPI just allocates unit numbers starting at 0. Bruce From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 20:33:35 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 669F616A4DE; Wed, 2 Aug 2006 20:33:35 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id E047643D45; Wed, 2 Aug 2006 20:33:34 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.5.252] (dhcp52.wlan.xcllnt.net [192.168.5.252]) by ns1.xcllnt.net (8.13.6/8.13.6) with ESMTP id k72KXVKX018350; Wed, 2 Aug 2006 13:33:31 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20060803041522.F2135@epsplex.bde.org> References: <200607252036.k6PKanFd072593@www.freebsd.org> <20060731191302.S1172@epsplex.bde.org> <6EFF87DF-280C-402C-8C2A-10F3144CF41F@svcolo.com> <20060802205230.N90692@delplex.bde.org> <20060802234330.J1249@epsplex.bde.org> <20060802150656.GB47835@svcolo.com> <20060803024810.X1573@epsplex.bde.org> <83D35AA9-61D2-4977-AFEC-C498F4147FC2@svcolo.com> <20060803041522.F2135@epsplex.bde.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6097EF2A-BFD8-4E85-86E7-BCCE9A57E245@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Wed, 2 Aug 2006 13:33:19 -0700 To: Bruce Evans X-Mailer: Apple Mail (2.752.2) Cc: Jo Rhett , njl@freebsd.org, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 20:33:35 -0000 On Aug 2, 2006, at 12:32 PM, Bruce Evans wrote: > On Wed, 2 Aug 2006, Jo Rhett wrote: > >>> On Wed, 2 Aug 2006, Jo Rhett wrote: >>>> 1. We can't/won't fix the sio0<->sio1 problem because fixing >>>> ACPI is hard >> >> On Aug 2, 2006, at 10:25 AM, Bruce Evans wrote: >>> _I_ can't/won't fix it because not just the above :-). Swapping >>> of consoles >>> only could be fixed within the driver (so that ACPI is not >>> involved and >>> you don't have to change device.hints) since consoles have to be >>> hard-wired >>> in some way and the hints are good enough for wiring the unit >>> number to >>> the i/o address (provided it's an old ISA port -- otherwise hints >>> based >>> on the i/o address don't work). >> >> Sorry, color me dumb. I'm getting lost here. The problem I was >> observing is that device hints is being (mostly) ignored by ACPI >> and thus this is the root problem to fix. I'm not sure what >> you're trying to say here. > > Console drivers have to and do use the hints directly so as to work > before > bus stuff like ACPI is initializated. It is a mistake for console drivers to use the hints. It's a mistake even to use hints for anything else. The fundamental problem with hints is that they use a device numbering for identification. This is totally wrong for low-level consoles, because device numbers mean nothing at that time and are mostly wrong during bus enumeration, because you cannot generally predict device numbers. Low-level console drivers should only use I/O port or memory mapped I/O information to get to the hardware and hints for non-enumerating busses should only provide resource information. During bus enumeration this will eventually be mapped to device numbers and one can establish the logical connection between low-level consoles and high-level devices. Thus: hints are not hints, but a convoluted mix of enforced settings and suggestions that are partially and inconsistently used and there- fore much sooner the cause of problems that a solution to it. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 20:40:33 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DECFD16A4EE for ; Wed, 2 Aug 2006 20:40:33 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22F2B43D5E for ; Wed, 2 Aug 2006 20:40:23 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k72KeMan092961 for ; Wed, 2 Aug 2006 20:40:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k72KeMlH092960; Wed, 2 Aug 2006 20:40:22 GMT (envelope-from gnats) Date: Wed, 2 Aug 2006 20:40:22 GMT Message-Id: <200608022040.k72KeMlH092960@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Marcel Moolenaar Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marcel Moolenaar List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 20:40:34 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Marcel Moolenaar To: Bruce Evans Cc: Jo Rhett , njl@freebsd.org, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Wed, 2 Aug 2006 13:33:19 -0700 On Aug 2, 2006, at 12:32 PM, Bruce Evans wrote: > On Wed, 2 Aug 2006, Jo Rhett wrote: > >>> On Wed, 2 Aug 2006, Jo Rhett wrote: >>>> 1. We can't/won't fix the sio0<->sio1 problem because fixing >>>> ACPI is hard >> >> On Aug 2, 2006, at 10:25 AM, Bruce Evans wrote: >>> _I_ can't/won't fix it because not just the above :-). Swapping >>> of consoles >>> only could be fixed within the driver (so that ACPI is not >>> involved and >>> you don't have to change device.hints) since consoles have to be >>> hard-wired >>> in some way and the hints are good enough for wiring the unit >>> number to >>> the i/o address (provided it's an old ISA port -- otherwise hints >>> based >>> on the i/o address don't work). >> >> Sorry, color me dumb. I'm getting lost here. The problem I was >> observing is that device hints is being (mostly) ignored by ACPI >> and thus this is the root problem to fix. I'm not sure what >> you're trying to say here. > > Console drivers have to and do use the hints directly so as to work > before > bus stuff like ACPI is initializated. It is a mistake for console drivers to use the hints. It's a mistake even to use hints for anything else. The fundamental problem with hints is that they use a device numbering for identification. This is totally wrong for low-level consoles, because device numbers mean nothing at that time and are mostly wrong during bus enumeration, because you cannot generally predict device numbers. Low-level console drivers should only use I/O port or memory mapped I/O information to get to the hardware and hints for non-enumerating busses should only provide resource information. During bus enumeration this will eventually be mapped to device numbers and one can establish the logical connection between low-level consoles and high-level devices. Thus: hints are not hints, but a convoluted mix of enforced settings and suggestions that are partially and inconsistently used and there- fore much sooner the cause of problems that a solution to it. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 21:43:56 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4130B16A4DD; Wed, 2 Aug 2006 21:43:56 +0000 (UTC) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF50E43D4C; Wed, 2 Aug 2006 21:43:55 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k72LhCj6075897; Wed, 2 Aug 2006 14:43:55 -0700 (PDT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k72LghQG090312; Wed, 2 Aug 2006 14:42:43 -0700 (PDT) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k72LghuN090310; Wed, 2 Aug 2006 14:42:43 -0700 (PDT) (envelope-from jrhett) Date: Wed, 2 Aug 2006 14:42:43 -0700 From: Jo Rhett To: Bruce Evans Message-ID: <20060802214243.GD86509@svcolo.com> References: <200607252036.k6PKanFd072593@www.freebsd.org> <20060731191302.S1172@epsplex.bde.org> <6EFF87DF-280C-402C-8C2A-10F3144CF41F@svcolo.com> <20060802205230.N90692@delplex.bde.org> <20060802234330.J1249@epsplex.bde.org> <20060802150656.GB47835@svcolo.com> <20060803024810.X1573@epsplex.bde.org> <83D35AA9-61D2-4977-AFEC-C498F4147FC2@svcolo.com> <20060803041522.F2135@epsplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060803041522.F2135@epsplex.bde.org> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: njl@freebsd.org, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 21:43:56 -0000 On Thu, Aug 03, 2006 at 05:32:35AM +1000, Bruce Evans wrote: > I don't completely understand this either. I think there is a non-ACPI part > of the BIOS that FreeBSD (or all OS's doesn't see). As I understand your > configuration, you start with COM1 and COM2 at the usual places but don't > want to use COM1 so you change the BIOS settings for COM2 to the usual ones > for COM1 and maybe vice versa. This changes soft jumpers or whatever is > needed for FreeBSD to see it. Then you use a BIOS option to swap the ports > so that everything is supposed to see COM2 as COM1. The boot loader sees > this but ACPI in FreeBSD doesn't. I think this changes is only made in > some BIOS table that ACPI in FreeBSD doesn't know about. In my test, I > only swapped the settings of COM1 and COM2 in the BIOS, since I couldn't > find a BIOS option to swap the unit number assignments, so it was not > completely incorrect for ACPI in FreeBSD to swap the settings. Huh? I separated this to make it clear. You can't make COM1 be COM2. What you're saying is nonsense. (not an insult, it just doesn't make sense) There are two serial ports: A and B. I can assign 03f8 irq 4 to either of them, and 02f8 irq 3 to the other. (or com3 or com4 doesn't matter) FreeBSD is currently assigning sio0 to serial A, regardless of the IO and IRQ settings. Likewise sio1 to Serial B, regardless of configuration. It appears likely that they are assigned based entirely on the order that they are presented via ACPI, and device hints are ignored entirely. However, the boot loader console does use device hints and does work properly. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 21:48:08 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E97C16A4E8; Wed, 2 Aug 2006 21:48:08 +0000 (UTC) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DB6543D46; Wed, 2 Aug 2006 21:48:06 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k72LlJiu076233; Wed, 2 Aug 2006 14:48:06 -0700 (PDT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k72Ll17J091601; Wed, 2 Aug 2006 14:47:01 -0700 (PDT) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k72Ll1js091600; Wed, 2 Aug 2006 14:47:01 -0700 (PDT) (envelope-from jrhett) Date: Wed, 2 Aug 2006 14:47:01 -0700 From: Jo Rhett To: Bruce Evans Message-ID: <20060802214701.GE86509@svcolo.com> References: <200607252036.k6PKanFd072593@www.freebsd.org> <20060731191302.S1172@epsplex.bde.org> <6EFF87DF-280C-402C-8C2A-10F3144CF41F@svcolo.com> <20060802205230.N90692@delplex.bde.org> <20060802234330.J1249@epsplex.bde.org> <20060802150656.GB47835@svcolo.com> <20060803024810.X1573@epsplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060803024810.X1573@epsplex.bde.org> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: njl@freebsd.org, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 21:48:08 -0000 > >4. There should be no ill effect from doing this. Console will never break > >and go to the wrong port. > > > >#4 is crucial to us. Many of these machines are completely unavailable to > >me for an emergency. This console is our "last chance access" On Thu, Aug 03, 2006 at 03:25:28AM +1000, Bruce Evans wrote: > Yes, "should be". The wiring should be fairly deterministic once you > get it to work. I think it will continue to work even if someone fixes > (?) ACPI to prefer the hints order to the ACPI order. However, it would > break if someone fixes (?) ACPI to prefer the BIOS order to both the hints > order and the ACPI order (I think ACPI is using its own order and doesn't > know that you've swapped the order in the BIOS). Actually, it doesn't work right now. I just tested it. /boot/device.hints: hint.sio.1.flags="0x90" If you change the flags in device hints, the low-level (boot loader 2?) console gets moved to wherever you put the flags. So now I have the exact reverse behavior. The initialization part of the console goes to the wrong port, and then halfway through booting I suddently get console on the right port. I think I have to agree with Marcel on this -- device hints aren't used consistently, and having two different processes read it with two completely different interpretations of it is nonsense. I can't fix one without breaking the other. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 21:50:23 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BB6216A4DD for ; Wed, 2 Aug 2006 21:50:23 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E675C43D45 for ; Wed, 2 Aug 2006 21:50:22 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k72LoM7a098638 for ; Wed, 2 Aug 2006 21:50:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k72LoMTN098634; Wed, 2 Aug 2006 21:50:22 GMT (envelope-from gnats) Date: Wed, 2 Aug 2006 21:50:22 GMT Message-Id: <200608022150.k72LoMTN098634@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Jo Rhett Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jo Rhett List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 21:50:23 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Jo Rhett To: Bruce Evans Cc: freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org, njl@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Wed, 2 Aug 2006 14:42:43 -0700 On Thu, Aug 03, 2006 at 05:32:35AM +1000, Bruce Evans wrote: > I don't completely understand this either. I think there is a non-ACPI part > of the BIOS that FreeBSD (or all OS's doesn't see). As I understand your > configuration, you start with COM1 and COM2 at the usual places but don't > want to use COM1 so you change the BIOS settings for COM2 to the usual ones > for COM1 and maybe vice versa. This changes soft jumpers or whatever is > needed for FreeBSD to see it. Then you use a BIOS option to swap the ports > so that everything is supposed to see COM2 as COM1. The boot loader sees > this but ACPI in FreeBSD doesn't. I think this changes is only made in > some BIOS table that ACPI in FreeBSD doesn't know about. In my test, I > only swapped the settings of COM1 and COM2 in the BIOS, since I couldn't > find a BIOS option to swap the unit number assignments, so it was not > completely incorrect for ACPI in FreeBSD to swap the settings. Huh? I separated this to make it clear. You can't make COM1 be COM2. What you're saying is nonsense. (not an insult, it just doesn't make sense) There are two serial ports: A and B. I can assign 03f8 irq 4 to either of them, and 02f8 irq 3 to the other. (or com3 or com4 doesn't matter) FreeBSD is currently assigning sio0 to serial A, regardless of the IO and IRQ settings. Likewise sio1 to Serial B, regardless of configuration. It appears likely that they are assigned based entirely on the order that they are presented via ACPI, and device hints are ignored entirely. However, the boot loader console does use device hints and does work properly. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 21:50:27 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 464F616A4DD for ; Wed, 2 Aug 2006 21:50:27 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CCF943D49 for ; Wed, 2 Aug 2006 21:50:27 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k72LoQ3N098667 for ; Wed, 2 Aug 2006 21:50:26 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k72LoQtn098666; Wed, 2 Aug 2006 21:50:26 GMT (envelope-from gnats) Date: Wed, 2 Aug 2006 21:50:26 GMT Message-Id: <200608022150.k72LoQtn098666@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Jo Rhett Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jo Rhett List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 21:50:27 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Jo Rhett To: Bruce Evans Cc: freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org, njl@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Wed, 2 Aug 2006 14:47:01 -0700 > >4. There should be no ill effect from doing this. Console will never break > >and go to the wrong port. > > > >#4 is crucial to us. Many of these machines are completely unavailable to > >me for an emergency. This console is our "last chance access" On Thu, Aug 03, 2006 at 03:25:28AM +1000, Bruce Evans wrote: > Yes, "should be". The wiring should be fairly deterministic once you > get it to work. I think it will continue to work even if someone fixes > (?) ACPI to prefer the hints order to the ACPI order. However, it would > break if someone fixes (?) ACPI to prefer the BIOS order to both the hints > order and the ACPI order (I think ACPI is using its own order and doesn't > know that you've swapped the order in the BIOS). Actually, it doesn't work right now. I just tested it. /boot/device.hints: hint.sio.1.flags="0x90" If you change the flags in device hints, the low-level (boot loader 2?) console gets moved to wherever you put the flags. So now I have the exact reverse behavior. The initialization part of the console goes to the wrong port, and then halfway through booting I suddently get console on the right port. I think I have to agree with Marcel on this -- device hints aren't used consistently, and having two different processes read it with two completely different interpretations of it is nonsense. I can't fix one without breaking the other. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-i386@FreeBSD.ORG Thu Aug 3 01:32:29 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAD2116A4DD; Thu, 3 Aug 2006 01:32:28 +0000 (UTC) (envelope-from nate@root.org) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CB1443D49; Thu, 3 Aug 2006 01:32:28 +0000 (GMT) (envelope-from nate@root.org) X-ORBL: [67.119.74.222] Received: from [10.0.0.53] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by ylpvm15.prodigy.net (8.13.7 out spool5000 dk/8.13.7) with ESMTP id k731VPjV032642; Wed, 2 Aug 2006 21:31:26 -0400 Message-ID: <44D151DF.10000@root.org> Date: Wed, 02 Aug 2006 18:31:11 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: Bruce Evans References: <200607252036.k6PKanFd072593@www.freebsd.org> <20060731191302.S1172@epsplex.bde.org> <6EFF87DF-280C-402C-8C2A-10F3144CF41F@svcolo.com> <20060802205230.N90692@delplex.bde.org> <20060802234330.J1249@epsplex.bde.org> <20060802150656.GB47835@svcolo.com> <20060803024810.X1573@epsplex.bde.org> <83D35AA9-61D2-4977-AFEC-C498F4147FC2@svcolo.com> <20060803041522.F2135@epsplex.bde.org> <20060803055353.K635@epsplex.bde.org> In-Reply-To: <20060803055353.K635@epsplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jo Rhett , freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 01:32:29 -0000 Bruce Evans wrote: > On Thu, 3 Aug 2006, Bruce Evans wrote: >> I don't completely understand this either. I think there is a >> non-ACPI part >> of the BIOS that FreeBSD (or all OS's doesn't see). As I understand your >> configuration, you start with COM1 and COM2 at the usual places but don't >> want to use COM1 so you change the BIOS settings for COM2 to the usual >> ones >> for COM1 and maybe vice versa. This changes soft jumpers or whatever is >> needed for FreeBSD to see it. Then you use a BIOS option to swap the >> ports >> so that everything is supposed to see COM2 as COM1. The boot loader sees >> this but ACPI in FreeBSD doesn't. I think this changes is only made in >> some BIOS table that ACPI in FreeBSD doesn't know about. In my test, I >> only swapped the settings of COM1 and COM2 in the BIOS, since I couldn't >> find a BIOS option to swap the unit number assignments, so it was not >> completely incorrect for ACPI in FreeBSD to swap the settings. > > More details on my test: > - after swapping the settings of COM1 and COM2, both FreeBSD-ACPI and WinXP > see only the settings swapped. WinXP didn't report any changes to the > devices. I now think this is completely correct. Swapping like this > requires swapping in device.hints to keep the same assignment of > physical > devices to unit numbers. > - after swapping the settings and then disabling COM1, FreeBSD-ACPI moves > COM2 down to COM1 (sio0) and sio1 goes away, while WinXP doesn't change > unit numbers and COM1 goes away. I think the WinXP behaviour is correct > and FreeBSD-ACPI just allocates unit numbers starting at 0. > > Bruce Please see the thread titled "acpi on msi-9218 (-current) swaps sio0 and sio1" on the freebsd-acpi@ list. John Baldwin's approach is the one I like, where hints can be used to wire device unit numbers to a particular device with a bus-specific string. For instance, hint.fxp.0.location="0:4:0" would mean a bus/slot/function to PCI and be meaningless to other busses. Another example: hint.sio.0.location="COMA" would mean a Device node in ACPI named "COMA" would be wired to sio0 and meaningless to other devices. As marcel@ pointed out, for serial ports in particular, you want the resource of I/O port as the primary identifier. So the default hint would be something like hint.sio.0.location="io=0x3f8". Other than some minor logic to allocate device units in newbus, the only change would be to decide on location naming schemes for the relevant bus types. Something like "io=0x3f8" might always match resources via RIDs and be bus-independent. I haven't thought much about the best naming scheme but I like the general idea of attaching a named ID to a unit to wire it to a known device, where the name means something to only a particular bus. -- Nate From owner-freebsd-i386@FreeBSD.ORG Thu Aug 3 01:40:20 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98EC516A4DA for ; Thu, 3 Aug 2006 01:40:20 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51E2E43D45 for ; Thu, 3 Aug 2006 01:40:20 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k731eKEF018903 for ; Thu, 3 Aug 2006 01:40:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k731eKQb018902; Thu, 3 Aug 2006 01:40:20 GMT (envelope-from gnats) Date: Thu, 3 Aug 2006 01:40:20 GMT Message-Id: <200608030140.k731eKQb018902@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Nate Lawson Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nate Lawson List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 01:40:20 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Nate Lawson To: Bruce Evans Cc: Jo Rhett , freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Wed, 02 Aug 2006 18:31:11 -0700 Bruce Evans wrote: > On Thu, 3 Aug 2006, Bruce Evans wrote: >> I don't completely understand this either. I think there is a >> non-ACPI part >> of the BIOS that FreeBSD (or all OS's doesn't see). As I understand your >> configuration, you start with COM1 and COM2 at the usual places but don't >> want to use COM1 so you change the BIOS settings for COM2 to the usual >> ones >> for COM1 and maybe vice versa. This changes soft jumpers or whatever is >> needed for FreeBSD to see it. Then you use a BIOS option to swap the >> ports >> so that everything is supposed to see COM2 as COM1. The boot loader sees >> this but ACPI in FreeBSD doesn't. I think this changes is only made in >> some BIOS table that ACPI in FreeBSD doesn't know about. In my test, I >> only swapped the settings of COM1 and COM2 in the BIOS, since I couldn't >> find a BIOS option to swap the unit number assignments, so it was not >> completely incorrect for ACPI in FreeBSD to swap the settings. > > More details on my test: > - after swapping the settings of COM1 and COM2, both FreeBSD-ACPI and WinXP > see only the settings swapped. WinXP didn't report any changes to the > devices. I now think this is completely correct. Swapping like this > requires swapping in device.hints to keep the same assignment of > physical > devices to unit numbers. > - after swapping the settings and then disabling COM1, FreeBSD-ACPI moves > COM2 down to COM1 (sio0) and sio1 goes away, while WinXP doesn't change > unit numbers and COM1 goes away. I think the WinXP behaviour is correct > and FreeBSD-ACPI just allocates unit numbers starting at 0. > > Bruce Please see the thread titled "acpi on msi-9218 (-current) swaps sio0 and sio1" on the freebsd-acpi@ list. John Baldwin's approach is the one I like, where hints can be used to wire device unit numbers to a particular device with a bus-specific string. For instance, hint.fxp.0.location="0:4:0" would mean a bus/slot/function to PCI and be meaningless to other busses. Another example: hint.sio.0.location="COMA" would mean a Device node in ACPI named "COMA" would be wired to sio0 and meaningless to other devices. As marcel@ pointed out, for serial ports in particular, you want the resource of I/O port as the primary identifier. So the default hint would be something like hint.sio.0.location="io=0x3f8". Other than some minor logic to allocate device units in newbus, the only change would be to decide on location naming schemes for the relevant bus types. Something like "io=0x3f8" might always match resources via RIDs and be bus-independent. I haven't thought much about the best naming scheme but I like the general idea of attaching a named ID to a unit to wire it to a known device, where the name means something to only a particular bus. -- Nate From owner-freebsd-i386@FreeBSD.ORG Thu Aug 3 17:14:43 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68FAA16A4DA; Thu, 3 Aug 2006 17:14:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2435343D45; Thu, 3 Aug 2006 17:14:43 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k73HCh5a074580; Thu, 3 Aug 2006 11:12:43 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 03 Aug 2006 11:12:43 -0600 (MDT) Message-Id: <20060803.111243.74675763.imp@bsdimp.com> To: nate@root.org From: Warner Losh In-Reply-To: <44D151DF.10000@root.org> References: <20060803041522.F2135@epsplex.bde.org> <20060803055353.K635@epsplex.bde.org> <44D151DF.10000@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 03 Aug 2006 11:12:44 -0600 (MDT) Cc: jrhett@svcolo.com, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 17:14:43 -0000 > Please see the thread titled "acpi on msi-9218 (-current) swaps sio0 and > sio1" on the freebsd-acpi@ list. John Baldwin's approach is the one I > like, where hints can be used to wire device unit numbers to a > particular device with a bus-specific string. For instance, > hint.fxp.0.location="0:4:0" would mean a bus/slot/function to PCI and be > meaningless to other busses. Another example: > hint.sio.0.location="COMA" would mean a Device node in ACPI named "COMA" > would be wired to sio0 and meaningless to other devices. I have patches that implement the parts of John's ideas that will actually work. I have pci wiring working. I have some ACPI wiring working, but not all of it. > As marcel@ pointed out, for serial ports in particular, you want the > resource of I/O port as the primary identifier. So the default hint > would be something like hint.sio.0.location="io=0x3f8". I hate this notation, since the hints functions don't search that space well. > Other than some minor logic to allocate device units in newbus, the only > change would be to decide on location naming schemes for the relevant > bus types. Something like "io=0x3f8" might always match resources via > RIDs and be bus-independent. I haven't thought much about the best > naming scheme but I like the general idea of attaching a named ID to a > unit to wire it to a known device, where the name means something to > only a particular bus. The "minor logic" in newbus is actually kicking my ass right now. I have stuff in p4 that should implement all the things we need, but the unit allocation is kicking my butt. I fear that the only real way is to subclass isa three times: hints-only, pnp+hint-augment, acpi+hint-augment. In the latter two, how does one tell a 'this hint is for a card that's there' versus a 'this hint is a wiring hint'? And for the wiring hints, how much of the device matching do you do? If the I/O matches, but the IRQ doesn't, is that a match? What about vice versa? The main problem right now is that hints are designed either to populate a bus, or to look up stuff after unit numbers are assigned. If you want to do something before unit numbers are assigned, it gets a lot harder. Many of the ideas that you've suggested require extensive, and expensive, algorithims to find what the right DWIM is for this situation. When a bus adds a device, there are no resources associated with it. The bus might be in a position to assign specific device names/units to individual devices at the time it adds it, but not always. ACPI, for example, adds the device, then uses that device to parse the resources. This means that looking things up in the hints table before adding them is hard. It also means that the bus has to necessarily get into the middle of pre-assigning device/units. Anyway, like I said, I'll post something when I get the last bit of the unit matching working. Warner From owner-freebsd-i386@FreeBSD.ORG Thu Aug 3 17:20:20 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D64D16A4DD for ; Thu, 3 Aug 2006 17:20:20 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8898B43D55 for ; Thu, 3 Aug 2006 17:20:19 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k73HKJxv006632 for ; Thu, 3 Aug 2006 17:20:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k73HKJc1006625; Thu, 3 Aug 2006 17:20:19 GMT (envelope-from gnats) Date: Thu, 3 Aug 2006 17:20:19 GMT Message-Id: <200608031720.k73HKJc1006625@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Warner Losh Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Warner Losh List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 17:20:20 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Warner Losh To: nate@root.org Cc: bde@zeta.org.au, jrhett@svcolo.com, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Thu, 03 Aug 2006 11:12:43 -0600 (MDT) > Please see the thread titled "acpi on msi-9218 (-current) swaps sio0 and > sio1" on the freebsd-acpi@ list. John Baldwin's approach is the one I > like, where hints can be used to wire device unit numbers to a > particular device with a bus-specific string. For instance, > hint.fxp.0.location="0:4:0" would mean a bus/slot/function to PCI and be > meaningless to other busses. Another example: > hint.sio.0.location="COMA" would mean a Device node in ACPI named "COMA" > would be wired to sio0 and meaningless to other devices. I have patches that implement the parts of John's ideas that will actually work. I have pci wiring working. I have some ACPI wiring working, but not all of it. > As marcel@ pointed out, for serial ports in particular, you want the > resource of I/O port as the primary identifier. So the default hint > would be something like hint.sio.0.location="io=0x3f8". I hate this notation, since the hints functions don't search that space well. > Other than some minor logic to allocate device units in newbus, the only > change would be to decide on location naming schemes for the relevant > bus types. Something like "io=0x3f8" might always match resources via > RIDs and be bus-independent. I haven't thought much about the best > naming scheme but I like the general idea of attaching a named ID to a > unit to wire it to a known device, where the name means something to > only a particular bus. The "minor logic" in newbus is actually kicking my ass right now. I have stuff in p4 that should implement all the things we need, but the unit allocation is kicking my butt. I fear that the only real way is to subclass isa three times: hints-only, pnp+hint-augment, acpi+hint-augment. In the latter two, how does one tell a 'this hint is for a card that's there' versus a 'this hint is a wiring hint'? And for the wiring hints, how much of the device matching do you do? If the I/O matches, but the IRQ doesn't, is that a match? What about vice versa? The main problem right now is that hints are designed either to populate a bus, or to look up stuff after unit numbers are assigned. If you want to do something before unit numbers are assigned, it gets a lot harder. Many of the ideas that you've suggested require extensive, and expensive, algorithims to find what the right DWIM is for this situation. When a bus adds a device, there are no resources associated with it. The bus might be in a position to assign specific device names/units to individual devices at the time it adds it, but not always. ACPI, for example, adds the device, then uses that device to parse the resources. This means that looking things up in the hints table before adding them is hard. It also means that the bus has to necessarily get into the middle of pre-assigning device/units. Anyway, like I said, I'll post something when I get the last bit of the unit matching working. Warner From owner-freebsd-i386@FreeBSD.ORG Thu Aug 3 18:47:15 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB8C616A4DA; Thu, 3 Aug 2006 18:47:15 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60C4943D4C; Thu, 3 Aug 2006 18:47:15 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.150] (pptp0.pn.xcllnt.net [192.168.4.150]) by ns1.xcllnt.net (8.13.6/8.13.6) with ESMTP id k73Il66G024439; Thu, 3 Aug 2006 11:47:07 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20060803.111243.74675763.imp@bsdimp.com> References: <20060803041522.F2135@epsplex.bde.org> <20060803055353.K635@epsplex.bde.org> <44D151DF.10000@root.org> <20060803.111243.74675763.imp@bsdimp.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4D601BDF-4D76-43CB-A565-30837492E3DE@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Thu, 3 Aug 2006 11:46:54 -0700 To: Warner Losh X-Mailer: Apple Mail (2.752.2) Cc: jrhett@svcolo.com, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org, nate@root.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 18:47:15 -0000 On Aug 3, 2006, at 10:12 AM, Warner Losh wrote: > The "minor logic" in newbus is actually kicking my ass right now. I > have stuff in p4 that should implement all the things we need, but the > unit allocation is kicking my butt. I fear that the only real way is > to subclass isa three times: hints-only, pnp+hint-augment, > acpi+hint-augment. In the latter two, how does one tell a 'this hint > is for a card that's there' versus a 'this hint is a wiring hint'? > And for the wiring hints, how much of the device matching do you do? > If the I/O matches, but the IRQ doesn't, is that a match? What about > vice versa? Like I said before: hints are abused for way too many purposes. It's better to come up with a new scheme where you clearly separate the different functions we're looking for and design *as many* different mechanisms to implement these functions. One approach would be to make ACPI unconditional, as it's there to describe the existence of legacy devices and thus serves the same purpose as our current hints and define hints to *only* allow wiring down hardware to unit numbers. These can be called hints because I'm sure we can not always guarantee it. Marking devices as special, like the sio flags is an entirely different function alltogether and should therefore not be done with the same hints. That would just create the convolution, so you create different hints for that. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-i386@FreeBSD.ORG Thu Aug 3 18:50:26 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11F9116A506 for ; Thu, 3 Aug 2006 18:50:26 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 363C143D6E for ; Thu, 3 Aug 2006 18:50:22 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k73IoMiJ014296 for ; Thu, 3 Aug 2006 18:50:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k73IoMSU014295; Thu, 3 Aug 2006 18:50:22 GMT (envelope-from gnats) Date: Thu, 3 Aug 2006 18:50:22 GMT Message-Id: <200608031850.k73IoMSU014295@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Marcel Moolenaar Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marcel Moolenaar List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 18:50:26 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Marcel Moolenaar To: Warner Losh Cc: nate@root.org, jrhett@svcolo.com, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Thu, 3 Aug 2006 11:46:54 -0700 On Aug 3, 2006, at 10:12 AM, Warner Losh wrote: > The "minor logic" in newbus is actually kicking my ass right now. I > have stuff in p4 that should implement all the things we need, but the > unit allocation is kicking my butt. I fear that the only real way is > to subclass isa three times: hints-only, pnp+hint-augment, > acpi+hint-augment. In the latter two, how does one tell a 'this hint > is for a card that's there' versus a 'this hint is a wiring hint'? > And for the wiring hints, how much of the device matching do you do? > If the I/O matches, but the IRQ doesn't, is that a match? What about > vice versa? Like I said before: hints are abused for way too many purposes. It's better to come up with a new scheme where you clearly separate the different functions we're looking for and design *as many* different mechanisms to implement these functions. One approach would be to make ACPI unconditional, as it's there to describe the existence of legacy devices and thus serves the same purpose as our current hints and define hints to *only* allow wiring down hardware to unit numbers. These can be called hints because I'm sure we can not always guarantee it. Marking devices as special, like the sio flags is an entirely different function alltogether and should therefore not be done with the same hints. That would just create the convolution, so you create different hints for that. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-i386@FreeBSD.ORG Thu Aug 3 21:29:55 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68F5916A4DD; Thu, 3 Aug 2006 21:29:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC0B343D46; Thu, 3 Aug 2006 21:29:54 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k73LSG5i082659; Thu, 3 Aug 2006 15:28:16 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 03 Aug 2006 15:28:16 -0600 (MDT) Message-Id: <20060803.152816.112545225.imp@bsdimp.com> To: marcel@xcllnt.net From: Warner Losh In-Reply-To: <4D601BDF-4D76-43CB-A565-30837492E3DE@xcllnt.net> References: <44D151DF.10000@root.org> <20060803.111243.74675763.imp@bsdimp.com> <4D601BDF-4D76-43CB-A565-30837492E3DE@xcllnt.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 03 Aug 2006 15:28:17 -0600 (MDT) Cc: jrhett@svcolo.com, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org, nate@root.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 21:29:55 -0000 > On Aug 3, 2006, at 10:12 AM, Warner Losh wrote: > > > The "minor logic" in newbus is actually kicking my ass right now. I > > have stuff in p4 that should implement all the things we need, but the > > unit allocation is kicking my butt. I fear that the only real way is > > to subclass isa three times: hints-only, pnp+hint-augment, > > acpi+hint-augment. In the latter two, how does one tell a 'this hint > > is for a card that's there' versus a 'this hint is a wiring hint'? > > And for the wiring hints, how much of the device matching do you do? > > If the I/O matches, but the IRQ doesn't, is that a match? What about > > vice versa? > > Like I said before: hints are abused for way too many purposes. > It's better to come up with a new scheme where you clearly separate > the different functions we're looking for and design *as many* > different mechanisms to implement these functions. The only thing that's not well suited for hints is the 'what is my console' function. The others can be made to work well with only a few engineering compromises :-). I'll agree that the flags in sio used to specify which UNIT is the console is lame and should be replaced with a generalization of the uart method. > One approach would be to make ACPI unconditional, as it's there > to describe the existence of legacy devices and thus serves the > same purpose as our current hints and define hints to *only* > allow wiring down hardware to unit numbers. These can be called > hints because I'm sure we can not always guarantee it. ACPI unconditional can't happen. There are many machines being made today that simply do not implement ACPI. I have several boards at work that implement PNPBIOS, but don't implement ACPI. These are boards that are brand new. I think ACPI is an extra cost option, but I might be confusing things. We do need to deal with cases like this because they are common enough that we'll alienate folks embedding FreeBSD if we take such a course. > Marking devices as special, like the sio flags is an entirely > different function alltogether and should therefore not be done > with the same hints. That would just create the convolution, so > you create different hints for that. Agreed. However, the sio flags to designate a unit as console is the only thing that doesn't fit well with hints, as presently implemented. It should really be something like: console.type={serial,video} console.location= so that would could use a video card not mapped to the default address as the console, etc. It would be up to the driver at attach time to look at the available console meta-information to see if this driver matches that information. Then it wouldn't matter for a serial console point of view what driver unit is assigned. It might matter for other reasons... Warner From owner-freebsd-i386@FreeBSD.ORG Thu Aug 3 21:30:23 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BD2616A52F for ; Thu, 3 Aug 2006 21:30:23 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABD0243D45 for ; Thu, 3 Aug 2006 21:30:22 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k73LUMRO029838 for ; Thu, 3 Aug 2006 21:30:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k73LUM8g029837; Thu, 3 Aug 2006 21:30:22 GMT (envelope-from gnats) Date: Thu, 3 Aug 2006 21:30:22 GMT Message-Id: <200608032130.k73LUM8g029837@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Warner Losh Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Warner Losh List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 21:30:23 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Warner Losh To: marcel@xcllnt.net Cc: nate@root.org, jrhett@svcolo.com, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Thu, 03 Aug 2006 15:28:16 -0600 (MDT) > On Aug 3, 2006, at 10:12 AM, Warner Losh wrote: > > > The "minor logic" in newbus is actually kicking my ass right now. I > > have stuff in p4 that should implement all the things we need, but the > > unit allocation is kicking my butt. I fear that the only real way is > > to subclass isa three times: hints-only, pnp+hint-augment, > > acpi+hint-augment. In the latter two, how does one tell a 'this hint > > is for a card that's there' versus a 'this hint is a wiring hint'? > > And for the wiring hints, how much of the device matching do you do? > > If the I/O matches, but the IRQ doesn't, is that a match? What about > > vice versa? > > Like I said before: hints are abused for way too many purposes. > It's better to come up with a new scheme where you clearly separate > the different functions we're looking for and design *as many* > different mechanisms to implement these functions. The only thing that's not well suited for hints is the 'what is my console' function. The others can be made to work well with only a few engineering compromises :-). I'll agree that the flags in sio used to specify which UNIT is the console is lame and should be replaced with a generalization of the uart method. > One approach would be to make ACPI unconditional, as it's there > to describe the existence of legacy devices and thus serves the > same purpose as our current hints and define hints to *only* > allow wiring down hardware to unit numbers. These can be called > hints because I'm sure we can not always guarantee it. ACPI unconditional can't happen. There are many machines being made today that simply do not implement ACPI. I have several boards at work that implement PNPBIOS, but don't implement ACPI. These are boards that are brand new. I think ACPI is an extra cost option, but I might be confusing things. We do need to deal with cases like this because they are common enough that we'll alienate folks embedding FreeBSD if we take such a course. > Marking devices as special, like the sio flags is an entirely > different function alltogether and should therefore not be done > with the same hints. That would just create the convolution, so > you create different hints for that. Agreed. However, the sio flags to designate a unit as console is the only thing that doesn't fit well with hints, as presently implemented. It should really be something like: console.type={serial,video} console.location= so that would could use a video card not mapped to the default address as the console, etc. It would be up to the driver at attach time to look at the available console meta-information to see if this driver matches that information. Then it wouldn't matter for a serial console point of view what driver unit is assigned. It might matter for other reasons... Warner From owner-freebsd-i386@FreeBSD.ORG Thu Aug 3 22:16:50 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA5E216A4E8; Thu, 3 Aug 2006 22:16:50 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id E749F43D77; Thu, 3 Aug 2006 22:16:40 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.5.252] (dhcp52.wlan.xcllnt.net [192.168.5.252]) by ns1.xcllnt.net (8.13.6/8.13.6) with ESMTP id k73MGYXM025585; Thu, 3 Aug 2006 15:16:34 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20060803.152816.112545225.imp@bsdimp.com> References: <44D151DF.10000@root.org> <20060803.111243.74675763.imp@bsdimp.com> <4D601BDF-4D76-43CB-A565-30837492E3DE@xcllnt.net> <20060803.152816.112545225.imp@bsdimp.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0D55A079-32B9-49B4-998C-7B5E67A2E434@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Thu, 3 Aug 2006 15:16:22 -0700 To: Warner Losh X-Mailer: Apple Mail (2.752.2) Cc: jrhett@svcolo.com, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org, nate@root.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 22:16:50 -0000 On Aug 3, 2006, at 2:28 PM, Warner Losh wrote: > Agreed. However, the sio flags to designate a unit as console is the > only thing that doesn't fit well with hints, as presently implemented. > It should really be something like: console.type={serial,video} > console.location= > > so that would could use a video card not mapped to the default address > as the console, etc. It would be up to the driver at attach time to > look at the available console meta-information to see if this driver > matches that information. Then it wouldn't matter for a serial > console point of view what driver unit is assigned. It might matter > for other reasons... This is exactly what I implemented for uart(4). As long as the I/O location used by the low-level console is actually being "found" during bus-enumeration and the right driver is being attached, then you always have a working console for going to single-user mode. Not to mention that the firmware typically exports console information in terms of I/O location (see DIG64 HCDP or Microsoft SPCR), so you can trivially use that too (see for a real example src/sys/dev/uart/uart_cpu_ia64.c). -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-i386@FreeBSD.ORG Thu Aug 3 22:20:16 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB87F16A4DD for ; Thu, 3 Aug 2006 22:20:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50DE143D58 for ; Thu, 3 Aug 2006 22:20:16 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k73MKGYE033946 for ; Thu, 3 Aug 2006 22:20:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k73MKGGG033945; Thu, 3 Aug 2006 22:20:16 GMT (envelope-from gnats) Date: Thu, 3 Aug 2006 22:20:16 GMT Message-Id: <200608032220.k73MKGGG033945@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Marcel Moolenaar Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marcel Moolenaar List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 22:20:16 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Marcel Moolenaar To: Warner Losh Cc: nate@root.org, jrhett@svcolo.com, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Thu, 3 Aug 2006 15:16:22 -0700 On Aug 3, 2006, at 2:28 PM, Warner Losh wrote: > Agreed. However, the sio flags to designate a unit as console is the > only thing that doesn't fit well with hints, as presently implemented. > It should really be something like: console.type={serial,video} > console.location= > > so that would could use a video card not mapped to the default address > as the console, etc. It would be up to the driver at attach time to > look at the available console meta-information to see if this driver > matches that information. Then it wouldn't matter for a serial > console point of view what driver unit is assigned. It might matter > for other reasons... This is exactly what I implemented for uart(4). As long as the I/O location used by the low-level console is actually being "found" during bus-enumeration and the right driver is being attached, then you always have a working console for going to single-user mode. Not to mention that the firmware typically exports console information in terms of I/O location (see DIG64 HCDP or Microsoft SPCR), so you can trivially use that too (see for a real example src/sys/dev/uart/uart_cpu_ia64.c). -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-i386@FreeBSD.ORG Fri Aug 4 11:40:25 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E3C616A522 for ; Fri, 4 Aug 2006 11:40:25 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69D3943D5C for ; Fri, 4 Aug 2006 11:40:23 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k74BeM7X001231 for ; Fri, 4 Aug 2006 11:40:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k74BeMGU001226; Fri, 4 Aug 2006 11:40:22 GMT (envelope-from gnats) Date: Fri, 4 Aug 2006 11:40:22 GMT Message-Id: <200608041140.k74BeMGU001226@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: "Alexander Mogilny" Cc: Subject: Re: i386/92501: [irq] Hang on boot with ACPI enabled on ASUS A6R notebook X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Mogilny List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 11:40:25 -0000 The following reply was made to PR i386/92501; it has been noted by GNATS. From: "Alexander Mogilny" To: bug-followup@FreeBSD.org, sg@astral.ntu-kpi.kiev.ua Cc: Subject: Re: i386/92501: [irq] Hang on boot with ACPI enabled on ASUS A6R notebook Date: Fri, 4 Aug 2006 14:39:44 +0300 I have just updated system to CURRENT and found that since recent commits to ACPI subsystem this no more happens again so I can normally work under FreeBSD on this notebook. So the PR can be closed. -- AIM-UANIC +-----[ FreeBSD ]-----+ Alexander Mogilny | The Power to Serve! | <> sg@portaone.com +---------------------+ From owner-freebsd-i386@FreeBSD.ORG Fri Aug 4 12:10:24 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D5FF16A4DA for ; Fri, 4 Aug 2006 12:10:24 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C644143D76 for ; Fri, 4 Aug 2006 12:10:22 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k74CAMrQ003414 for ; Fri, 4 Aug 2006 12:10:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k74CAMb7003412; Fri, 4 Aug 2006 12:10:22 GMT (envelope-from gnats) Date: Fri, 4 Aug 2006 12:10:22 GMT Message-Id: <200608041210.k74CAMb7003412@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: "Alexander Mogilny" Cc: Subject: Re: i386/99089: Kernel Panic X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Mogilny List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 12:10:24 -0000 The following reply was made to PR i386/99089; it has been noted by GNATS. From: "Alexander Mogilny" To: bug-followup@FreeBSD.org, aloha@operamail.com Cc: Subject: Re: i386/99089: Kernel Panic Date: Fri, 4 Aug 2006 15:01:33 +0300 > > 6.0 and 6.1 both give me a kernel panic sometimes when rebooting. > > Here is a picture taken showing the message: > http://img149.imageshack.us/my.php?image=picture0823in.jpg > Could you please build a debug version of KERNEL and try to perform some backtrace procedures while panic occures for us to get more information on what could cause this. -- AIM-UANIC +-----[ FreeBSD ]-----+ Alexander Mogilny | The Power to Serve! | <> sg@portaone.com +---------------------+ From owner-freebsd-i386@FreeBSD.ORG Fri Aug 4 12:30:14 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE23716A4E0; Fri, 4 Aug 2006 12:30:13 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 127EC43D45; Fri, 4 Aug 2006 12:30:13 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 3B77164D2B1; Fri, 4 Aug 2006 22:29:44 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k74CTf3Z022367; Fri, 4 Aug 2006 22:29:42 +1000 Date: Fri, 4 Aug 2006 22:29:40 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Jo Rhett In-Reply-To: <20060802214243.GD86509@svcolo.com> Message-ID: <20060804215751.J97440@delplex.bde.org> References: <200607252036.k6PKanFd072593@www.freebsd.org> <20060731191302.S1172@epsplex.bde.org> <6EFF87DF-280C-402C-8C2A-10F3144CF41F@svcolo.com> <20060802205230.N90692@delplex.bde.org> <20060802234330.J1249@epsplex.bde.org> <20060802150656.GB47835@svcolo.com> <20060803024810.X1573@epsplex.bde.org> <83D35AA9-61D2-4977-AFEC-C498F4147FC2@svcolo.com> <20060803041522.F2135@epsplex.bde.org> <20060802214243.GD86509@svcolo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: njl@freebsd.org, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 12:30:14 -0000 On Wed, 2 Aug 2006, Jo Rhett wrote: > On Thu, Aug 03, 2006 at 05:32:35AM +1000, Bruce Evans wrote: >> I don't completely understand this either. I think there is a non-ACPI part >> of the BIOS that FreeBSD (or all OS's doesn't see). As I understand your >> configuration, you start with COM1 and COM2 at the usual places but don't >> want to use COM1 so you change the BIOS settings for COM2 to the usual ones >> for COM1 and maybe vice versa. This changes soft jumpers or whatever is >> needed for FreeBSD to see it. Then you use a BIOS option to swap the ports >> so that everything is supposed to see COM2 as COM1. The boot loader sees >> this but ACPI in FreeBSD doesn't. I think this changes is only made in >> some BIOS table that ACPI in FreeBSD doesn't know about. In my test, I >> only swapped the settings of COM1 and COM2 in the BIOS, since I couldn't >> find a BIOS option to swap the unit number assignments, so it was not >> completely incorrect for ACPI in FreeBSD to swap the settings. > > Huh? I separated this to make it clear. > > You can't make COM1 be COM2. What you're saying is nonsense. > (not an insult, it just doesn't make sense) > > There are two serial ports: A and B. I can assign 03f8 irq 4 to either of > them, and 02f8 irq 3 to the other. (or com3 or com4 doesn't matter) It makes perfects sense when you understand that the unit number may be assigned at many levels, starting with the BIOS. Whether you can make COM1 be COM2 at the BIOS level depends on BIOS support for this. I've never seen a BIOS that supports this but thought that you had one with this feature and were using it (actually to make COMB be COM1), since you said that it works for booting and I forgot that boot2 doesn't use the BIOS. Later we mentioned boot0. boot0 does use the BIOS and has COM1 hard-wired, so assignment of COMB to COM1 at the BIOS level is the only way to make boot0 use COM1. Whether you can make COMB be COM1 at other levels depends on the other level's support for this. Whether settings at lower levels are honored at higher levels also depends on the other levels' support for this. > FreeBSD is currently assigning sio0 to serial A, regardless of the IO and > IRQ settings. Likewise sio1 to Serial B, regardless of configuration. It > appears likely that they are assigned based entirely on the order that they > are presented via ACPI, and device hints are ignored entirely. This now seems a reasonable thing to do. WinXP behaves similarly here (see another reply). The hints are only hints, so they shouldn't be used if the hardware has been reconfigured but not moved. Only something stronger than a hint should move the unit numbers if the hardware hasn't moved. The problems are that the hints get used partially and there is nothing stronger. > However, the boot loader console does use device hints and does work > properly. Actually, the boot loader doesn't use hints: - boot0 has COM1 hard-coded in the source - boot2 has i/o port address 0x3f8 not so hard-coded in the Makefile. This can be changed using make.conf. - loader seems to be the same as boot2. There has been some discussion of propagating the settings used by the boot loader (at all stages) to subsequent stages, but nothing related seems to be implemented for the port/unit number. Some of the settings (mainly the speed) are inherited by the sio console from the previous stage (boot2 or loader) provided the stages agree on the port/unit. Bruce From owner-freebsd-i386@FreeBSD.ORG Fri Aug 4 12:35:51 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E568616A4E5 for ; Fri, 4 Aug 2006 12:35:51 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 111A843D58 for ; Fri, 4 Aug 2006 12:35:51 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id E8A905A3F7E; Fri, 4 Aug 2006 22:35:44 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k74CZh6T026441; Fri, 4 Aug 2006 22:35:43 +1000 Date: Fri, 4 Aug 2006 22:35:42 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Jo Rhett In-Reply-To: <200608022150.k72LoQtn098666@freefall.freebsd.org> Message-ID: <20060804223000.P97440@delplex.bde.org> References: <200608022150.k72LoQtn098666@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 12:35:52 -0000 On Wed, 2 Aug 2006, Jo Rhett wrote: > The following reply was made to PR i386/100831; it has been noted by GNATS. > > From: Jo Rhett > To: Bruce Evans > Cc: freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org, > njl@freebsd.org > Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered > Date: Wed, 2 Aug 2006 14:47:01 -0700 > > > >4. There should be no ill effect from doing this. Console will never break > > >and go to the wrong port. > > > > > >#4 is crucial to us. Many of these machines are completely unavailable to > > >me for an emergency. This console is our "last chance access" > > On Thu, Aug 03, 2006 at 03:25:28AM +1000, Bruce Evans wrote: > > Yes, "should be". The wiring should be fairly deterministic once you > > get it to work. I think it will continue to work even if someone fixes > > (?) ACPI to prefer the hints order to the ACPI order. However, it would > > break if someone fixes (?) ACPI to prefer the BIOS order to both the hints > > order and the ACPI order (I think ACPI is using its own order and doesn't > > know that you've swapped the order in the BIOS). > > Actually, it doesn't work right now. I just tested it. > /boot/device.hints: hint.sio.1.flags="0x90" > > If you change the flags in device hints, the low-level (boot loader 2?) > console gets moved to wherever you put the flags. > > So now I have the exact reverse behavior. The initialization part of the > console goes to the wrong port, and then halfway through booting I > suddently get console on the right port. Everything is working as expected if you only changed the flags hint. I said that the port hint must be changed too. > I think I have to agree with Marcel on this -- device hints aren't used > consistently, and having two different processes read it with two > completely different interpretations of it is nonsense. I can't fix one > without breaking the other. Just avoid inconsistencies by making all the hints match the unit number assignments that you get although these are not the unit number assignments that you want. Bruce From owner-freebsd-i386@FreeBSD.ORG Fri Aug 4 12:40:21 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D09F416A4DA for ; Fri, 4 Aug 2006 12:40:21 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78B6E43D68 for ; Fri, 4 Aug 2006 12:40:18 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k74CeIRK009292 for ; Fri, 4 Aug 2006 12:40:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k74CeIaq009291; Fri, 4 Aug 2006 12:40:18 GMT (envelope-from gnats) Date: Fri, 4 Aug 2006 12:40:18 GMT Message-Id: <200608041240.k74CeIaq009291@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Bruce Evans Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 12:40:22 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Bruce Evans To: Jo Rhett Cc: freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org, njl@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Fri, 4 Aug 2006 22:29:40 +1000 (EST) On Wed, 2 Aug 2006, Jo Rhett wrote: > On Thu, Aug 03, 2006 at 05:32:35AM +1000, Bruce Evans wrote: >> I don't completely understand this either. I think there is a non-ACPI part >> of the BIOS that FreeBSD (or all OS's doesn't see). As I understand your >> configuration, you start with COM1 and COM2 at the usual places but don't >> want to use COM1 so you change the BIOS settings for COM2 to the usual ones >> for COM1 and maybe vice versa. This changes soft jumpers or whatever is >> needed for FreeBSD to see it. Then you use a BIOS option to swap the ports >> so that everything is supposed to see COM2 as COM1. The boot loader sees >> this but ACPI in FreeBSD doesn't. I think this changes is only made in >> some BIOS table that ACPI in FreeBSD doesn't know about. In my test, I >> only swapped the settings of COM1 and COM2 in the BIOS, since I couldn't >> find a BIOS option to swap the unit number assignments, so it was not >> completely incorrect for ACPI in FreeBSD to swap the settings. > > Huh? I separated this to make it clear. > > You can't make COM1 be COM2. What you're saying is nonsense. > (not an insult, it just doesn't make sense) > > There are two serial ports: A and B. I can assign 03f8 irq 4 to either of > them, and 02f8 irq 3 to the other. (or com3 or com4 doesn't matter) It makes perfects sense when you understand that the unit number may be assigned at many levels, starting with the BIOS. Whether you can make COM1 be COM2 at the BIOS level depends on BIOS support for this. I've never seen a BIOS that supports this but thought that you had one with this feature and were using it (actually to make COMB be COM1), since you said that it works for booting and I forgot that boot2 doesn't use the BIOS. Later we mentioned boot0. boot0 does use the BIOS and has COM1 hard-wired, so assignment of COMB to COM1 at the BIOS level is the only way to make boot0 use COM1. Whether you can make COMB be COM1 at other levels depends on the other level's support for this. Whether settings at lower levels are honored at higher levels also depends on the other levels' support for this. > FreeBSD is currently assigning sio0 to serial A, regardless of the IO and > IRQ settings. Likewise sio1 to Serial B, regardless of configuration. It > appears likely that they are assigned based entirely on the order that they > are presented via ACPI, and device hints are ignored entirely. This now seems a reasonable thing to do. WinXP behaves similarly here (see another reply). The hints are only hints, so they shouldn't be used if the hardware has been reconfigured but not moved. Only something stronger than a hint should move the unit numbers if the hardware hasn't moved. The problems are that the hints get used partially and there is nothing stronger. > However, the boot loader console does use device hints and does work > properly. Actually, the boot loader doesn't use hints: - boot0 has COM1 hard-coded in the source - boot2 has i/o port address 0x3f8 not so hard-coded in the Makefile. This can be changed using make.conf. - loader seems to be the same as boot2. There has been some discussion of propagating the settings used by the boot loader (at all stages) to subsequent stages, but nothing related seems to be implemented for the port/unit number. Some of the settings (mainly the speed) are inherited by the sio console from the previous stage (boot2 or loader) provided the stages agree on the port/unit. Bruce From owner-freebsd-i386@FreeBSD.ORG Fri Aug 4 14:50:14 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BC4E16A4DF for ; Fri, 4 Aug 2006 14:50:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E290B43D46 for ; Fri, 4 Aug 2006 14:50:13 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k74EoDVr020824 for ; Fri, 4 Aug 2006 14:50:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k74EoDiA020823; Fri, 4 Aug 2006 14:50:13 GMT (envelope-from gnats) Resent-Date: Fri, 4 Aug 2006 14:50:13 GMT Resent-Message-Id: <200608041450.k74EoDiA020823@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Bram Kuijper Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F9D816A4DD for ; Fri, 4 Aug 2006 14:41:06 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCE6243D5A for ; Fri, 4 Aug 2006 14:40:56 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k74Eeusn086243 for ; Fri, 4 Aug 2006 14:40:56 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k74EeuOL086242; Fri, 4 Aug 2006 14:40:56 GMT (envelope-from nobody) Message-Id: <200608041440.k74EeuOL086242@www.freebsd.org> Date: Fri, 4 Aug 2006 14:40:56 GMT From: Bram Kuijper To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: i386/101361: graphicsmagick failed to build X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 14:50:14 -0000 >Number: 101361 >Category: i386 >Synopsis: graphicsmagick failed to build >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Aug 04 14:50:13 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Bram Kuijper >Release: FreeBSD 6.1-STABLE #2 >Organization: >Environment: FreeBSD 145.98.213.240 6.1-STABLE FreeBSD 6.1-STABLE #2: Wed Jul 5 00:36:08 CEST 2006 BramKuijper@145.98.213.240:/usr/obj/usr/src/sys/EUODICE i386 >Description: ?> portupgrade GraphicsMagick if /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I../magick -I../magick -I.. -I.. -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/X11R6/include -I/usr/local/include/libxml2 -O -pipe -march=pentium4 -Wall -MT png.lo -MD -MP -MF ".deps/png.Tpo" -c -o png.lo png.c; then mv -f ".deps/png.Tpo" ".deps/png.Plo"; else rm -f ".deps/png.Tpo"; exit 1; fi png.c: In function `ReadOnePNGImage': png.c:1712: warning: implicit declaration of function `png_access_version' png.c:1721: error: `png_ptr' undeclared (first use in this function) png.c:1721: error: (Each undeclared identifier is reported only once png.c:1721: error: for each function it appears in.) *** Error code 1 Stop in /usr/ports/graphics/GraphicsMagick/work/GraphicsMagick-1.1.6/coders. *** Error code 1 Stop in /usr/ports/graphics/GraphicsMagick/work/GraphicsMagick-1.1.6. *** Error code 1 Stop in /usr/ports/graphics/GraphicsMagick. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade71901.0 env PORT_UPGRADE=yes make PORT_UPGRADE=yes ** Fix the problem and try again. ** Listing the failed packages (*:skipped / !:failed) ! graphics/GraphicsMagick (GraphicsMagick-1.1.6_1) (compiler error) >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-i386@FreeBSD.ORG Fri Aug 4 16:20:31 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A0F616A512; Fri, 4 Aug 2006 16:20:31 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA7E243D7C; Fri, 4 Aug 2006 16:20:18 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id 773426E458; Sat, 5 Aug 2006 02:20:17 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k74GKC7H026390; Sat, 5 Aug 2006 02:20:13 +1000 Date: Sat, 5 Aug 2006 02:20:12 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Warner Losh In-Reply-To: <20060803.152816.112545225.imp@bsdimp.com> Message-ID: <20060805005106.I97912@delplex.bde.org> References: <44D151DF.10000@root.org> <20060803.111243.74675763.imp@bsdimp.com> <4D601BDF-4D76-43CB-A565-30837492E3DE@xcllnt.net> <20060803.152816.112545225.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: jrhett@svcolo.com, freebsd-gnats-submit@freebsd.org, nate@root.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 16:20:31 -0000 On Thu, 3 Aug 2006, Warner Losh wrote: >> On Aug 3, 2006, at 10:12 AM, Warner Losh wrote: [Warner Losh didn't write:] >> Like I said before: hints are abused for way too many purposes. >> It's better to come up with a new scheme where you clearly separate >> the different functions we're looking for and design *as many* >> different mechanisms to implement these functions. > > The only thing that's not well suited for hints is the 'what is my > console' function. The others can be made to work well with only a Hints are actually almost perfectly suited to specifying the console, though not for other things. This is because the console wiring must be decided early so whatever specifies the wiring must be simple and non-ambiguous. Then whatever wiring is used for the console must be respected by more general wiring in ACPI etc. It doesn't matter much whether the console wiring is determined by hints that are actually "forces" or by "forces" that have to have precedence over other wiring possibilities later. It is just clearer for hints to never be forces. > few engineering compromises :-). I'll agree that the flags in sio > used to specify which UNIT is the console is lame and should be > replaced with a generalization of the uart method. I'll disagree with this. The flags actually work almost perfectly for specifying which physical device is the console, but not for other things. This is again because the console wiring must be decided early, etc., and because the unit number is mostly used only to correlate the hint that specifies flags with the hint that specifies the i/o port address. Low-level consoles are associated in this way with the i/o port address, and work because the unit number is only used in similar ways at a low level (it used to be an index, but is now more like a cookie, and it still works at low levels because the cookie is always the same although it is different from the high-level logical unit number in broken cases). Problems occur if ACPI etc., associates a different unit number with the i/o port address being used for the console. High-level sio probe/attach matches on the port address to avoid problems, but a critical part of high-level console attachment happens too early, and sio neither detects nor fixes up the problem. uart fixes up the problem using a partially delayed attachment ("Yedi trick"). This helps a bit for consoles but has no effect for non-consoles. Even for consoles, non-console flags don't work when the unit numbers are inconsistently chosen -- all flags remain on the original unit number where they probably no longer apply since flags are more associated with port addresses than with logical unit numbers; the flags for sio consoles have almost no effect when they are on a wrong unit (they are just printed in the boot messages), but the flags for non-consoles on any device are misapplied. >> One approach would be to make ACPI unconditional, as it's there >> to describe the existence of legacy devices and thus serves the >> same purpose as our current hints and define hints to *only* >> allow wiring down hardware to unit numbers. These can be called >> hints because I'm sure we can not always guarantee it. > > ACPI unconditional can't happen. There are many machines being made > today that simply do not implement ACPI. I have several boards at > work that implement PNPBIOS, but don't implement ACPI. These are > boards that are brand new. I think ACPI is an extra cost option, but I thought that the idea was to use ACPI's configuration format even if the BIOS doesn't support it. >> Marking devices as special, like the sio flags is an entirely >> different function alltogether and should therefore not be done >> with the same hints. That would just create the convolution, so >> you create different hints for that. > > Agreed. However, the sio flags to designate a unit as console is the > only thing that doesn't fit well with hints, as presently implemented. > It should really be something like: console.type={serial,video} > console.location= > > so that would could use a video card not mapped to the default address > as the console, etc. It would be up to the driver at attach time to > look at the available console meta-information to see if this driver > matches that information. Then it wouldn't matter for a serial > console point of view what driver unit is assigned. It might matter > for other reasons... Marcel wrote in a reply: % This is exactly what I implemented for uart(4). As long as the I/O % location used by the low-level console is actually being "found" % during bus-enumeration and the right driver is being attached, % then you always have a working console for going to single-user % mode. Not to mention that the firmware typically exports console % information in terms of I/O location (see DIG64 HCDP or Microsoft % SPCR), so you can trivially use that too (see for a real example % src/sys/dev/uart/uart_cpu_ia64.c). sio mostly uses the i/o location too. Something higher-level should really be used. The firmware may decide to put the location in a different place on each boot. Memory mapped i/o locations tend to change when new hardware is added. It takes something like a dummy boot and reading the boot messages just to see where things moved to. Bruce From owner-freebsd-i386@FreeBSD.ORG Fri Aug 4 16:30:32 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D134A16A5B9 for ; Fri, 4 Aug 2006 16:30:32 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E24243D46 for ; Fri, 4 Aug 2006 16:30:32 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k74GUVNC030167 for ; Fri, 4 Aug 2006 16:30:31 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k74GUV01030166; Fri, 4 Aug 2006 16:30:31 GMT (envelope-from gnats) Date: Fri, 4 Aug 2006 16:30:31 GMT Message-Id: <200608041630.k74GUV01030166@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Bruce Evans Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 16:30:32 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Bruce Evans To: Warner Losh Cc: marcel@xcllnt.net, jrhett@svcolo.com, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org, nate@root.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Sat, 5 Aug 2006 02:20:12 +1000 (EST) On Thu, 3 Aug 2006, Warner Losh wrote: >> On Aug 3, 2006, at 10:12 AM, Warner Losh wrote: [Warner Losh didn't write:] >> Like I said before: hints are abused for way too many purposes. >> It's better to come up with a new scheme where you clearly separate >> the different functions we're looking for and design *as many* >> different mechanisms to implement these functions. > > The only thing that's not well suited for hints is the 'what is my > console' function. The others can be made to work well with only a Hints are actually almost perfectly suited to specifying the console, though not for other things. This is because the console wiring must be decided early so whatever specifies the wiring must be simple and non-ambiguous. Then whatever wiring is used for the console must be respected by more general wiring in ACPI etc. It doesn't matter much whether the console wiring is determined by hints that are actually "forces" or by "forces" that have to have precedence over other wiring possibilities later. It is just clearer for hints to never be forces. > few engineering compromises :-). I'll agree that the flags in sio > used to specify which UNIT is the console is lame and should be > replaced with a generalization of the uart method. I'll disagree with this. The flags actually work almost perfectly for specifying which physical device is the console, but not for other things. This is again because the console wiring must be decided early, etc., and because the unit number is mostly used only to correlate the hint that specifies flags with the hint that specifies the i/o port address. Low-level consoles are associated in this way with the i/o port address, and work because the unit number is only used in similar ways at a low level (it used to be an index, but is now more like a cookie, and it still works at low levels because the cookie is always the same although it is different from the high-level logical unit number in broken cases). Problems occur if ACPI etc., associates a different unit number with the i/o port address being used for the console. High-level sio probe/attach matches on the port address to avoid problems, but a critical part of high-level console attachment happens too early, and sio neither detects nor fixes up the problem. uart fixes up the problem using a partially delayed attachment ("Yedi trick"). This helps a bit for consoles but has no effect for non-consoles. Even for consoles, non-console flags don't work when the unit numbers are inconsistently chosen -- all flags remain on the original unit number where they probably no longer apply since flags are more associated with port addresses than with logical unit numbers; the flags for sio consoles have almost no effect when they are on a wrong unit (they are just printed in the boot messages), but the flags for non-consoles on any device are misapplied. >> One approach would be to make ACPI unconditional, as it's there >> to describe the existence of legacy devices and thus serves the >> same purpose as our current hints and define hints to *only* >> allow wiring down hardware to unit numbers. These can be called >> hints because I'm sure we can not always guarantee it. > > ACPI unconditional can't happen. There are many machines being made > today that simply do not implement ACPI. I have several boards at > work that implement PNPBIOS, but don't implement ACPI. These are > boards that are brand new. I think ACPI is an extra cost option, but I thought that the idea was to use ACPI's configuration format even if the BIOS doesn't support it. >> Marking devices as special, like the sio flags is an entirely >> different function alltogether and should therefore not be done >> with the same hints. That would just create the convolution, so >> you create different hints for that. > > Agreed. However, the sio flags to designate a unit as console is the > only thing that doesn't fit well with hints, as presently implemented. > It should really be something like: console.type={serial,video} > console.location= > > so that would could use a video card not mapped to the default address > as the console, etc. It would be up to the driver at attach time to > look at the available console meta-information to see if this driver > matches that information. Then it wouldn't matter for a serial > console point of view what driver unit is assigned. It might matter > for other reasons... Marcel wrote in a reply: % This is exactly what I implemented for uart(4). As long as the I/O % location used by the low-level console is actually being "found" % during bus-enumeration and the right driver is being attached, % then you always have a working console for going to single-user % mode. Not to mention that the firmware typically exports console % information in terms of I/O location (see DIG64 HCDP or Microsoft % SPCR), so you can trivially use that too (see for a real example % src/sys/dev/uart/uart_cpu_ia64.c). sio mostly uses the i/o location too. Something higher-level should really be used. The firmware may decide to put the location in a different place on each boot. Memory mapped i/o locations tend to change when new hardware is added. It takes something like a dummy boot and reading the boot messages just to see where things moved to. Bruce From owner-freebsd-i386@FreeBSD.ORG Fri Aug 4 18:29:57 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1293816A4DF; Fri, 4 Aug 2006 18:29:57 +0000 (UTC) (envelope-from jrhett@svcolo.com) Received: from outbound0.sv.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id B746843D73; Fri, 4 Aug 2006 18:29:51 +0000 (GMT) (envelope-from jrhett@svcolo.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k74ITmij048164; Fri, 4 Aug 2006 11:29:51 -0700 (PDT) (envelope-from jrhett@svcolo.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k74ITEdM097231; Fri, 4 Aug 2006 11:29:14 -0700 (PDT) (envelope-from jrhett@svcolo.com) In-Reply-To: <20060804215751.J97440@delplex.bde.org> References: <200607252036.k6PKanFd072593@www.freebsd.org> <20060731191302.S1172@epsplex.bde.org> <6EFF87DF-280C-402C-8C2A-10F3144CF41F@svcolo.com> <20060802205230.N90692@delplex.bde.org> <20060802234330.J1249@epsplex.bde.org> <20060802150656.GB47835@svcolo.com> <20060803024810.X1573@epsplex.bde.org> <83D35AA9-61D2-4977-AFEC-C498F4147FC2@svcolo.com> <20060803041522.F2135@epsplex.bde.org> <20060802214243.GD86509@svcolo.com> <20060804215751.J97440@delplex.bde.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <74CE7BDD-F743-42E6-B4E9-9FE6411579BE@svcolo.com> Content-Transfer-Encoding: 7bit From: Jo Rhett Date: Fri, 4 Aug 2006 11:29:12 -0700 To: Bruce Evans X-Mailer: Apple Mail (2.752.2) Cc: njl@freebsd.org, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 18:29:57 -0000 On Aug 4, 2006, at 5:29 AM, Bruce Evans wrote: > It makes perfects sense when you understand that the unit number > may be > assigned at many levels, starting with the BIOS. Whether you can make > COM1 be COM2 at the BIOS level depends on BIOS support for this. I've Sorry, saying nonsense like this confuses the issue. COM1 is a CPM/ DOS designation that means 0x3f8 irq 4. Saying COM1 = COM2 means "IO 0x3f8 irq 4 == 0x2f8 irq 3". Can you understand that this makes no sense? Physical port ordering has no meaning with regards to COM1 ports. Even on the original IBM hardware you could set jumpers and swap which physical port was COM1 and which was COM2. I spent years doing this! :-) -- Jo Rhett senior geek Silicon Valley Colocation From owner-freebsd-i386@FreeBSD.ORG Fri Aug 4 18:30:24 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC7AA16A4DA for ; Fri, 4 Aug 2006 18:30:24 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C80743D4C for ; Fri, 4 Aug 2006 18:30:24 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k74IUOKX042914 for ; Fri, 4 Aug 2006 18:30:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k74IUOL9042913; Fri, 4 Aug 2006 18:30:24 GMT (envelope-from gnats) Date: Fri, 4 Aug 2006 18:30:24 GMT Message-Id: <200608041830.k74IUOL9042913@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Jo Rhett Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jo Rhett List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 18:30:25 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Jo Rhett To: Bruce Evans Cc: freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org, njl@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Fri, 4 Aug 2006 11:29:12 -0700 On Aug 4, 2006, at 5:29 AM, Bruce Evans wrote: > It makes perfects sense when you understand that the unit number > may be > assigned at many levels, starting with the BIOS. Whether you can make > COM1 be COM2 at the BIOS level depends on BIOS support for this. I've Sorry, saying nonsense like this confuses the issue. COM1 is a CPM/ DOS designation that means 0x3f8 irq 4. Saying COM1 = COM2 means "IO 0x3f8 irq 4 == 0x2f8 irq 3". Can you understand that this makes no sense? Physical port ordering has no meaning with regards to COM1 ports. Even on the original IBM hardware you could set jumpers and swap which physical port was COM1 and which was COM2. I spent years doing this! :-) -- Jo Rhett senior geek Silicon Valley Colocation From owner-freebsd-i386@FreeBSD.ORG Fri Aug 4 18:37:41 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27FEF16A4DD; Fri, 4 Aug 2006 18:37:41 +0000 (UTC) (envelope-from jrhett@svcolo.com) Received: from outbound0.sv.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0D2F43D4C; Fri, 4 Aug 2006 18:37:40 +0000 (GMT) (envelope-from jrhett@svcolo.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k74Ibcij048720; Fri, 4 Aug 2006 11:37:40 -0700 (PDT) (envelope-from jrhett@svcolo.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k74IaxkK000586; Fri, 4 Aug 2006 11:36:59 -0700 (PDT) (envelope-from jrhett@svcolo.com) In-Reply-To: <20060804215751.J97440@delplex.bde.org> References: <200607252036.k6PKanFd072593@www.freebsd.org> <20060731191302.S1172@epsplex.bde.org> <6EFF87DF-280C-402C-8C2A-10F3144CF41F@svcolo.com> <20060802205230.N90692@delplex.bde.org> <20060802234330.J1249@epsplex.bde.org> <20060802150656.GB47835@svcolo.com> <20060803024810.X1573@epsplex.bde.org> <83D35AA9-61D2-4977-AFEC-C498F4147FC2@svcolo.com> <20060803041522.F2135@epsplex.bde.org> <20060802214243.GD86509@svcolo.com> <20060804215751.J97440@delplex.bde.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <268CFB29-628B-48F4-9548-C5CDDCFF5FD4@svcolo.com> Content-Transfer-Encoding: 7bit From: Jo Rhett Date: Fri, 4 Aug 2006 11:36:56 -0700 To: Bruce Evans X-Mailer: Apple Mail (2.752.2) Cc: njl@freebsd.org, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 18:37:41 -0000 On Aug 4, 2006, at 5:29 AM, Bruce Evans wrote: > Later we mentioned boot0. boot0 does use the BIOS and has COM1 > hard-wired, so assignment of COMB to COM1 at the BIOS level is the > only way to make boot0 use COM1. > > Whether you can make COMB be COM1 at other levels depends on the other > level's support for this. Whether settings at lower levels are > honored > at higher levels also depends on the other levels' support for this. > >> FreeBSD is currently assigning sio0 to serial A, regardless of the >> IO and >> IRQ settings. Likewise sio1 to Serial B, regardless of >> configuration. It >> appears likely that they are assigned based entirely on the order >> that they >> are presented via ACPI, and device hints are ignored entirely. > > This now seems a reasonable thing to do. WinXP behaves similarly here > (see another reply). The hints are only hints, so they shouldn't be > used if the hardware has been reconfigured but not moved. Only > something > stronger than a hint should move the unit numbers if the hardware > hasn't > moved. The problems are that the hints get used partially and > there is > nothing stronger. I'd like to note for the record that all of this is goobly-gook. None of what you're saying rhymes with the documentation, and even you guys talking about this on the thread seem to have different views of what is happening here. I am finding this conversation nearly impossible to follow. Not because it's technically difficult -- this stuff is fairly simple! -- but because I have no useful reference documentation, and it's not always clear that everyone in the conversation is on the same page to start with. In particular, I'd like to argue this point: > This now seems a reasonable thing to do. WinXP behaves similarly here Absolutely not. 0x3f8 is ALWAYS COM1 to Windows, no matter what version and no matter what physical port 0x3f8 is assigned to. If you'd like to argue that assigning sio numbers based on physical hardware ordering makes sense -- I can't argue with that. Except to point out that if each and every level of the boot process does it differently then it becomes impossible to have a serial console except in the one condition that 0x3f8 is assigned to the first port provided via acpi. ^^ Note that this latter condition has been possible in less than 50% of the production environments on which I have worked over the last 17 years. -- Jo Rhett senior geek Silicon Valley Colocation From owner-freebsd-i386@FreeBSD.ORG Fri Aug 4 18:40:20 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA89216A4DD for ; Fri, 4 Aug 2006 18:40:20 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id F011B43D46 for ; Fri, 4 Aug 2006 18:40:19 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k74IeJLG044551 for ; Fri, 4 Aug 2006 18:40:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k74IeJhj044550; Fri, 4 Aug 2006 18:40:19 GMT (envelope-from gnats) Date: Fri, 4 Aug 2006 18:40:19 GMT Message-Id: <200608041840.k74IeJhj044550@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Jo Rhett Cc: Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jo Rhett List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 18:40:20 -0000 The following reply was made to PR i386/100831; it has been noted by GNATS. From: Jo Rhett To: Bruce Evans Cc: freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org, njl@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Date: Fri, 4 Aug 2006 11:36:56 -0700 On Aug 4, 2006, at 5:29 AM, Bruce Evans wrote: > Later we mentioned boot0. boot0 does use the BIOS and has COM1 > hard-wired, so assignment of COMB to COM1 at the BIOS level is the > only way to make boot0 use COM1. > > Whether you can make COMB be COM1 at other levels depends on the other > level's support for this. Whether settings at lower levels are > honored > at higher levels also depends on the other levels' support for this. > >> FreeBSD is currently assigning sio0 to serial A, regardless of the >> IO and >> IRQ settings. Likewise sio1 to Serial B, regardless of >> configuration. It >> appears likely that they are assigned based entirely on the order >> that they >> are presented via ACPI, and device hints are ignored entirely. > > This now seems a reasonable thing to do. WinXP behaves similarly here > (see another reply). The hints are only hints, so they shouldn't be > used if the hardware has been reconfigured but not moved. Only > something > stronger than a hint should move the unit numbers if the hardware > hasn't > moved. The problems are that the hints get used partially and > there is > nothing stronger. I'd like to note for the record that all of this is goobly-gook. None of what you're saying rhymes with the documentation, and even you guys talking about this on the thread seem to have different views of what is happening here. I am finding this conversation nearly impossible to follow. Not because it's technically difficult -- this stuff is fairly simple! -- but because I have no useful reference documentation, and it's not always clear that everyone in the conversation is on the same page to start with. In particular, I'd like to argue this point: > This now seems a reasonable thing to do. WinXP behaves similarly here Absolutely not. 0x3f8 is ALWAYS COM1 to Windows, no matter what version and no matter what physical port 0x3f8 is assigned to. If you'd like to argue that assigning sio numbers based on physical hardware ordering makes sense -- I can't argue with that. Except to point out that if each and every level of the boot process does it differently then it becomes impossible to have a serial console except in the one condition that 0x3f8 is assigned to the first port provided via acpi. ^^ Note that this latter condition has been possible in less than 50% of the production environments on which I have worked over the last 17 years. -- Jo Rhett senior geek Silicon Valley Colocation From owner-freebsd-i386@FreeBSD.ORG Fri Aug 4 18:41:17 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C95616A4DA for ; Fri, 4 Aug 2006 18:41:17 +0000 (UTC) (envelope-from jrhett@svcolo.com) Received: from outbound0.sv.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAF0943D45 for ; Fri, 4 Aug 2006 18:41:16 +0000 (GMT) (envelope-from jrhett@svcolo.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k74Iewj3048970; Fri, 4 Aug 2006 11:41:16 -0700 (PDT) (envelope-from jrhett@svcolo.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k74IeKOV002137; Fri, 4 Aug 2006 11:40:20 -0700 (PDT) (envelope-from jrhett@svcolo.com) In-Reply-To: <20060804223000.P97440@delplex.bde.org> References: <200608022150.k72LoQtn098666@freefall.freebsd.org> <20060804223000.P97440@delplex.bde.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5F770D91-34A1-4406-AEF8-719E29AFFA87@svcolo.com> Content-Transfer-Encoding: 7bit From: Jo Rhett Date: Fri, 4 Aug 2006 11:40:17 -0700 To: Bruce Evans X-Mailer: Apple Mail (2.752.2) Cc: freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 18:41:17 -0000 >> So now I have the exact reverse behavior. The initialization part >> of the >> console goes to the wrong port, and then halfway through booting I >> suddently get console on the right port. Everything is working as expected if you only changed the flags hint. > I said that the port hint must be changed too. I asked for specific instructions. You didn't supply any. I told you what I was going to do, and you said that this should work. Now you're saying I didn't do what I should have. Please provide exact instructions. >> I think I have to agree with Marcel on this -- device hints aren't >> used >> consistently, and having two different processes read it with two >> completely different interpretations of it is nonsense. I can't >> fix one >> without breaking the other. > > Just avoid inconsistencies by making all the hints match the unit > number > assignments that you get although these are not the unit number > assignments > that you want. I haven't the foggiest idea what you mean by this. Exact instructions please? I'm not kidding, this statement doesn't make sense to me. Everything is fine right now except where the console is directed. I have no problem with the console being sio1, as long as sio1 is the console for all parts of the boot/run/shutdown process. Therefore the console flags are the only thing I know to change. -- Jo Rhett senior geek Silicon Valley Colocation From owner-freebsd-i386@FreeBSD.ORG Fri Aug 4 18:51:52 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EC5816A4DA for ; Fri, 4 Aug 2006 18:51:52 +0000 (UTC) (envelope-from jrhett@svcolo.com) Received: from outbound0.sv.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id F348E43D45 for ; Fri, 4 Aug 2006 18:51:51 +0000 (GMT) (envelope-from jrhett@svcolo.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k74Ipmj1049595; Fri, 4 Aug 2006 11:51:51 -0700 (PDT) (envelope-from jrhett@svcolo.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k74Ip9PK006946; Fri, 4 Aug 2006 11:51:09 -0700 (PDT) (envelope-from jrhett@svcolo.com) In-Reply-To: <5F770D91-34A1-4406-AEF8-719E29AFFA87@svcolo.com> References: <200608022150.k72LoQtn098666@freefall.freebsd.org> <20060804223000.P97440@delplex.bde.org> <5F770D91-34A1-4406-AEF8-719E29AFFA87@svcolo.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3FB8BF25-F047-427C-9062-07ADF85D5169@svcolo.com> Content-Transfer-Encoding: 7bit From: Jo Rhett Date: Fri, 4 Aug 2006 11:51:08 -0700 To: Bruce Evans X-Mailer: Apple Mail (2.752.2) Cc: freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 18:51:52 -0000 On Aug 4, 2006, at 11:40 AM, Jo Rhett wrote: >>> I think I have to agree with Marcel on this -- device hints >>> aren't used >>> consistently, and having two different processes read it with two >>> completely different interpretations of it is nonsense. I can't >>> fix one >>> without breaking the other. >> >> Just avoid inconsistencies by making all the hints match the unit >> number >> assignments that you get although these are not the unit number >> assignments >> that you want. > > I haven't the foggiest idea what you mean by this. Exact > instructions please? I'm not kidding, this statement doesn't make > sense to me. Everything is fine right now except where the console > is directed. > > I have no problem with the console being sio1, as long as sio1 is > the console for all parts of the boot/run/shutdown process. > Therefore the console flags are the only thing I know to change. Maybe I was being dense when I wrote this. Rethinking "making all the hints match" comment I swapped the io port and irq assignments in device.hints to match what is actually happening, rebooted, and it seems to work: hint.sio.0.at="isa" hint.sio.0.port="0x2F8" #hint.sio.0.flags="0x10" hint.sio.0.irq="3" hint.sio.1.at="isa" hint.sio.1.port="0x3F8" hint.sio.1.irq="4" hint.sio.1.flags="0x90" Okay, so if this works then I'm guessing that boot0 or boot2 or both were determining console based on the IO address from device.hints? Can we use what we know now to improve the documentation? boot0 determines console how? Compiled in...? Can device.hints influence that? Since we don't yet have sio numbers assigned, how does it know which port to use? IO address? boot2 determines console how? (repeat all questions above) loader determines console how? (repeat all questions above) If I didn't name a process in the boot, add it to the list. -- Jo Rhett senior geek Silicon Valley Colocation From owner-freebsd-i386@FreeBSD.ORG Fri Aug 4 21:50:14 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0564B16A4DD for ; Fri, 4 Aug 2006 21:50:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54CDF43D49 for ; Fri, 4 Aug 2006 21:50:13 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k74LoDxf060858 for ; Fri, 4 Aug 2006 21:50:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k74LoDX3060857; Fri, 4 Aug 2006 21:50:13 GMT (envelope-from gnats) Resent-Date: Fri, 4 Aug 2006 21:50:13 GMT Resent-Message-Id: <200608042150.k74LoDX3060857@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Tijl Coosemans Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 329C316A4DA for ; Fri, 4 Aug 2006 21:48:24 +0000 (UTC) (envelope-from tijl@kalimero.kotnet.org) Received: from outmx017.isp.belgacom.be (outmx017.isp.belgacom.be [195.238.4.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id 855EB43D46 for ; Fri, 4 Aug 2006 21:48:23 +0000 (GMT) (envelope-from tijl@kalimero.kotnet.org) Received: from outmx017.isp.belgacom.be (localhost [127.0.0.1]) by outmx017.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22) with ESMTP id k74LmISX000900 for ; Fri, 4 Aug 2006 23:48:19 +0200 (envelope-from ) Received: from kalimero.kotnet.org (224.54-245-81.adsl-dyn.isp.belgacom.be [81.245.54.224]) by outmx017.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22) with ESMTP id k74LmFCC000873 for ; Fri, 4 Aug 2006 23:48:15 +0200 (envelope-from ) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.6/8.13.6) with ESMTP id k74Lm91w022086 for ; Fri, 4 Aug 2006 23:48:09 +0200 (CEST) (envelope-from tijl@kalimero.kotnet.org) Received: (from tijl@localhost) by kalimero.kotnet.org (8.13.6/8.13.6/Submit) id k74Lm8BM022085; Fri, 4 Aug 2006 23:48:08 +0200 (CEST) (envelope-from tijl) Message-Id: <200608042148.k74Lm8BM022085@kalimero.kotnet.org> Date: Fri, 4 Aug 2006 23:48:08 +0200 (CEST) From: Tijl Coosemans To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: i386/101379: page fault clobbers error code in trap frame X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tijl Coosemans List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 21:50:14 -0000 >Number: 101379 >Category: i386 >Synopsis: page fault clobbers error code in trap frame >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Aug 04 21:50:12 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Tijl Coosemans >Release: FreeBSD 6.1-STABLE i386 >Organization: >Environment: >Description: In case of a page fault the trap handler stores the faulting address in trapframe.tf_err to pass it on to sendsig. This is no longer necessary because the address is now passed on to sendsig in a ksiginfo_t. An example of a program that depends on the correct tf_err ending up in the signal handler's sigcontext is Wine. >How-To-Repeat: >Fix: (this is a patch against HEAD) --- trap.c.diff begins here --- --- sys/i386/i386/trap.c.orig Fri Aug 4 23:20:16 2006 +++ sys/i386/i386/trap.c Fri Aug 4 23:20:36 2006 @@ -777,9 +777,6 @@ return (-1); } - /* kludge to pass faulting virtual address to sendsig */ - frame->tf_err = eva; - return((rv == KERN_PROTECTION_FAILURE) ? SIGBUS : SIGSEGV); } --- trap.c.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-i386@FreeBSD.ORG Sat Aug 5 03:00:42 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E06716A4DA for ; Sat, 5 Aug 2006 03:00:42 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8FB643D46 for ; Sat, 5 Aug 2006 03:00:41 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k7530fI4086793 for ; Sat, 5 Aug 2006 03:00:41 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k7530fQ4086792; Sat, 5 Aug 2006 03:00:41 GMT (envelope-from gnats) Date: Sat, 5 Aug 2006 03:00:41 GMT Message-Id: <200608050300.k7530fQ4086792@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: "S.A.R." Cc: Subject: Re: i386/99089: Kernel Panic X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "S.A.R." List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 03:00:42 -0000 The following reply was made to PR i386/99089; it has been noted by GNATS. From: "S.A.R." To: "Alexander Mogilny" , bug-followup@FreeBSD.org Cc: Subject: Re: i386/99089: Kernel Panic Date: Sat, 05 Aug 2006 03:59:08 +0100 I don't have FreeBSD installed anymore. > ----- Original Message ----- > From: "Alexander Mogilny" > To: bug-followup@FreeBSD.org, aloha@operamail.com > Subject: Re: i386/99089: Kernel Panic > Date: Fri, 4 Aug 2006 15:01:33 +0300 >=20 >=20 > > > > 6.0 and 6.1 both give me a kernel panic sometimes when rebooting. > > > > Here is a picture taken showing the message: > > http://img149.imageshack.us/my.php?image=3Dpicture0823in.jpg > > >=20 > Could you please build a debug version of KERNEL and try to perform > some backtrace procedures while panic occures for us to get more > information on what could cause this. >=20 > -- AIM-UANIC +-----[ FreeBSD ]-----+ > Alexander Mogilny | The Power to Serve! | > <> sg@portaone.com +---------------------+ > --=20 _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze From owner-freebsd-i386@FreeBSD.ORG Sat Aug 5 23:33:53 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8250C16A4DF for ; Sat, 5 Aug 2006 23:33:53 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id E068143D69 for ; Sat, 5 Aug 2006 23:33:52 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id 60F641291F4; Sun, 6 Aug 2006 09:33:18 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k75NXFqv014758; Sun, 6 Aug 2006 09:33:16 +1000 Date: Sun, 6 Aug 2006 09:33:15 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Jo Rhett In-Reply-To: <3FB8BF25-F047-427C-9062-07ADF85D5169@svcolo.com> Message-ID: <20060806085626.S2624@delplex.bde.org> References: <200608022150.k72LoQtn098666@freefall.freebsd.org> <20060804223000.P97440@delplex.bde.org> <5F770D91-34A1-4406-AEF8-719E29AFFA87@svcolo.com> <3FB8BF25-F047-427C-9062-07ADF85D5169@svcolo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 23:33:53 -0000 [freebsd-gnats-sbmit somewhat intentionally lost from the Cc] On Fri, 4 Aug 2006, Jo Rhett wrote: > On Aug 4, 2006, at 11:40 AM, Jo Rhett wrote: >>> Just avoid inconsistencies by making all the hints match the unit number >>> assignments that you get although these are not the unit number >>> assignments >>> that you want. >> >> I haven't the foggiest idea what you mean by this. Exact instructions >> please? I'm not kidding, this statement doesn't make sense to me. >> Everything is fine right now except where the console is directed. >> >> I have no problem with the console being sio1, as long as sio1 is the >> console for all parts of the boot/run/shutdown process. Therefore the >> console flags are the only thing I know to change. > > Maybe I was being dense when I wrote this. Rethinking "making all the hints > match" comment I swapped the io port and irq assignments in device.hints to > match what is actually happening, rebooted, and it seems to work: > > hint.sio.0.at="isa" > hint.sio.0.port="0x2F8" > #hint.sio.0.flags="0x10" > hint.sio.0.irq="3" > hint.sio.1.at="isa" > hint.sio.1.port="0x3F8" > hint.sio.1.irq="4" > hint.sio.1.flags="0x90" Good. I only tested it by understanding the source. COM1 might mean 0x3F8 in DOS, but in FreeBSD sio0 just means whatever port is mapped to unit 0 by hints or by another mechanism. The hints give more control over the mapping than in DOS, but don't always work now that there is ACPI etc. COM1 doesn't mean 0x3F8 in WinXP like you claimed in another reply and I expected before I tested it. Maybe WinXP would have mapped 0x3F8 to COM1 if I had reinstalled WinXP or if WinXP had rebuilt its driver database, but when I just swapped COM1 with COM2 in the BIOS and rebooted, WinXP didn't say that it was rebuilding its driver database and the ports were just swapped in WinXP too. My BIOS's labels for the ports are also inconsistent with COM1 meaning 0x3F8 -- the first port is named COM1 (not COMA) and that port can be set to an address != 0x3F8, etc. When COM1 and COM2 were on ISA cards (especially when they were on separate cards), it made much more sense for DOS to map the port at 0x3F8 to COM1, etc. ISTR that DOS has fixed mappings for COM1-COM4 but not for COM5 up, and that it has magic mappings which don't work as well for LPT1-LPT2. > Okay, so if this works then I'm guessing that boot0 or boot2 or both were > determining console based on the IO address from device.hints? Can we use > what we know now to improve the documentation? boot0 uses BIOS COM1 and boot2 uses non-BIOS whatever i/o address is configured (default 0x3F8). At least in man pages, the documentation for this is hard to find. I could only find it in boot0cfg(8) for boot0 and and make.conf(5) for boot2. > boot0 determines console how? Compiled in...? Can device.hints influence > that? Since we don't yet have sio numbers assigned, how does it know which > port to use? IO address? As above; yes; no; hard-coded in assembler; BIOS unit number 0 (= COM1). > boot2 determines console how? (repeat all questions above) As above; yes; no; soft-hard-coded in makefiles; i/o address. > loader determines console how? (repeat all questions above) Same as boot2 (?). Hopefully for everything except the port address, it inherits settings (speed and parity etc.) from boot2. > If I didn't name a process in the boot, add it to the list. Kernel part of the boot. Now uses hints. Normally inherits all settings from the previous stage provides it agrees on the port address (it reads the settings from the port). Bruce From owner-freebsd-i386@FreeBSD.ORG Sat Aug 5 23:53:52 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B698D16A4DE for ; Sat, 5 Aug 2006 23:53:52 +0000 (UTC) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D97543D46 for ; Sat, 5 Aug 2006 23:53:52 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k75Nr7iq035673; Sat, 5 Aug 2006 16:53:51 -0700 (PDT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k75Nr6qF082650; Sat, 5 Aug 2006 16:53:06 -0700 (PDT) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k75Nr6K7082649; Sat, 5 Aug 2006 16:53:06 -0700 (PDT) (envelope-from jrhett) Date: Sat, 5 Aug 2006 16:53:06 -0700 From: Jo Rhett To: Bruce Evans Message-ID: <20060805235306.GA80053@svcolo.com> References: <200608022150.k72LoQtn098666@freefall.freebsd.org> <20060804223000.P97440@delplex.bde.org> <5F770D91-34A1-4406-AEF8-719E29AFFA87@svcolo.com> <3FB8BF25-F047-427C-9062-07ADF85D5169@svcolo.com> <20060806085626.S2624@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060806085626.S2624@delplex.bde.org> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 23:53:52 -0000 On Sun, Aug 06, 2006 at 09:33:15AM +1000, Bruce Evans wrote: > COM1 might mean 0x3F8 in DOS, but in FreeBSD sio0 just means whatever port > is mapped to unit 0 by hints or by another mechanism. The hints give more > control over the mapping than in DOS, but don't always work now that there > is ACPI etc. I know this. COM1 is a DOS/Windows term, and not a hardware term. > COM1 doesn't mean 0x3F8 in WinXP like you claimed in another reply and I > expected before I tested it. Maybe WinXP would have mapped 0x3F8 to COM1 > if I had reinstalled WinXP or if WinXP had rebuilt its driver database, > but when I just swapped COM1 with COM2 in the BIOS and rebooted, WinXP Again, this is a nonsense statement. It's much like saying > didn't say that it was rebuilding its driver database and the ports were > just swapped in WinXP too. My BIOS's labels for the ports are also > inconsistent with COM1 meaning 0x3F8 -- the first port is named COM1 > (not COMA) and that port can be set to an address != 0x3F8, etc. When Then your BIOS is intentionally confusing and the vendor should be rebuked. These aren't vague terms, they have established and well defined meanings. If someone is using the terms to refer to physical hardware ports then they are not using the terms correctly. What if I said to you that I assigned sio0 to sio1 ? You'd raise your eyebrows and think I was a fool or ignorant. Exactly so. COM1 can be assigned to COM2 no more than sio0 can be assigned to sio1. > >Okay, so if this works then I'm guessing that boot0 or boot2 or both were > >determining console based on the IO address from device.hints? Can we use > >what we know now to improve the documentation? > > boot0 uses BIOS COM1 Meaning what? I doubt that you have loaded a piece of DOS code in to determine what COM1 is. IO address, or first serial port? FYI: it must be IO address because we're currently and always have had boot0 using the SerialB port just fine... > and boot2 uses non-BIOS whatever i/o address is configured (default 0x3F8). What is the difference here? Seriously, both have always worked in this configuration. It's only when it switches over to sio that it failed. > At least in man pages, the documentation for > this is hard to find. I could only find it in boot0cfg(8) for boot0 and > and make.conf(5) for boot2. Man pages are not useful documentation. They're only useful if you know where to look, which is effectively the secret handshake to the club. I was referring to the Handbook. Which is welcome to refer to the appropriate manpages, and thus the secret handshake is not necessary. > >boot0 determines console how? Compiled in...? Can device.hints influence > >that? Since we don't yet have sio numbers assigned, how does it know > >which port to use? IO address? > > As above; yes; no; hard-coded in assembler; BIOS unit number 0 (= COM1). This is untrue. Or if true, then it raises questions about how the sio numbers are assigned, because boot0 has always used the proper (unit 1) port. > >boot2 determines console how? (repeat all questions above) > > As above; yes; no; soft-hard-coded in makefiles; i/o address. This is also not true, because it appears to reference device.hints for the console flags, based on our last test. > >loader determines console how? (repeat all questions above) > > Same as boot2 (?). Hopefully for everything except the port address, it > inherits settings (speed and parity etc.) from boot2. No, this clearly does read device.hints. > >If I didn't name a process in the boot, add it to the list. > > Kernel part of the boot. Now uses hints. Normally inherits all > settings from the previous stage provides it agrees on the port address > (it reads the settings from the port). I'm really not sure I know the difference between boot2, loader and kernel. Where does each leave off? -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation