Re: Serial console not working for IBM Aptiva
On 3/13/07, Damon McMahon [EMAIL PROTECTED] wrote: For the archives, the Aptiva BIOS had incorrect IRQ/address values for Serial Port 1 and Serial Port 2. A BIOS flash to the latest available version (perhaps unnecessary) and then setting these to match the values specified in pccom(4) resolved the issue. Just for the record: the same works here. OpenBSD 4.1-current (GENERIC) #1445: Thu Mar 22 11:06:59 MDT 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium (P54C) (GenuineIntel 586-class) 150 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8 cpu0: F00F bug workaround installed real mem = 48852992 (47708K) avail mem = 35954688 (35112K) using 627 buffers containing 2568192 bytes (2508K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+ BIOS, date 11/23/96, BIOS32 rev. 0 @ 0xfd981 pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: PCI BIOS has 6 Interrupt Routing table entries pcibios0: PCI Interrupt Router at 000:01:0 (SiS 85C503 System rev 0x00) pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xc/0x8000 0xc8000/0x1000 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 SiS 5511 rev 0x00 pcib0 at pci0 dev 1 function 0 SiS 85C503 System rev 0x01 pciide0 at pci0 dev 1 function 1 SiS 5513 EIDE rev 0x08: 5597/5598: DMA, chann el 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: QUANTUM FIREBALL540A wd0: 8-sector PIO, LBA, 519MB, 1064448 sectors wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 pciide0: channel 1 disabled (no drives) rl0 at pci0 dev 7 function 0 Realtek 8139 rev 0x10: irq 12, address 00:20:18:c 0:84:d1 rlphy0 at rl0 phy 0: RTL internal PHY siop0 at pci0 dev 11 function 0 Symbios Logic 53c815 rev 0x04: irq 11 scsibus0 at siop0: 8 targets sd0 at scsibus0 targ 6 lun 0: NEC, D3825, 5F14 SCSI2 0/direct fixed sd0: 696MB, 1416 cyl, 16 head, 63 sec, 512 bytes/sec, 1427328 sec total vga1 at pci0 dev 20 function 0 SiS 86C205 rev 0xd3: aperture at 0x2000, si ze 0x40 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pccom0: console fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 biomask ef6d netmask ff6d ttymask ffef pctr: 586-class performance counters and user-level cycle counter enabled dkcsum: wd0 matches BIOS drive 0x80 siop0: target 6 now using 8 bit 10.0 MHz 8 REQ/ACK offset xfers dkcsum: sd0 matches BIOS drive 0x81 root on wd0a rootdev=0x0 rrootdev=0x300 rawdev=0x302
Re: Serial console not working for IBM Aptiva
On 19/02/2007, at 10:46 PM, Nick Holland wrote: Damon McMahon wrote: Thanks for the response, Nick, I'm almost there and just one further query: On 18/02/07, Nick Holland [EMAIL PROTECTED] wrote: ... The Aptiva has an anaemic BIOS program, but by disabling one of the two serial interfaces I now appear to have eliminated IRQ conflicts and acquired a working serial console - BUT I lose nearly all of the dmesg(8) and init(8) output at boot, with it being directed to the screen instead. I also note that boot(8) tells me I have com0 and no com1 (which is expected since I disabled it in the BIOS) whereas dmesg(8) tells me I have pccom1 but no pccom0 and this seems a little strange to me. boot(8) tells you what the BIOS tells it. boot(8) uses the BIOS to communicate. dmesg(8) tells you what hardware OpenBSD actually found. The BIOS can define ports as it wishes. OpenBSD defines ports as spec'd in /usr/src/sys/arch/i386/conf/GENERIC From your dmesg, pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo That's not the standard definition for com0 (DOS COM1), but rather, com1 (DOS COM2:) From pccom(4): pccom0 at isa? port 0x3f8 irq 4 pccom1 at isa? port 0x2f8 irq 3 To clarify, boot(8) tells me I have com0 available at boot. So in /etc/boot.conf I tell it: set tty com0 and it switches to the console but all that is output to the console is: OpenBSD/i386 BOOT 2.10 boot booting hd0a:/bsd: 4966344+867848 [52+255872+237161]=0x608d64 entry point at 0x100120 so once the kernel is loaded, your redirection is screwed up... That's it for the output seen on the terminal, at this point the dmesg(8) and init(8) output is directed to the screen. Then when getty(8) is executed interactivity for _both_ the keyboard and the serial console are restored. I haven't played with this kind of config, but my guess is you are sending the output to a non-existant com0, so the system falls back to using the screen. You get the serial IO again after boot because of your ttys setting which has tty01 turned on, you would get the login prompt on the serial port even if you didn't do the set tty com0. Any further thoughts will be appreciated; dmesg(8) and ttys(5) are included below: ...thanks, snipped for size # head -n 20 /etc/ttys # # $OpenBSD: ttys,v 1.17 2002/06/09 06:15:14 todd Exp $ # # name getty typestatus comments # console /usr/libexec/getty Pc vt220 off secure ttyC0 /usr/libexec/getty Pc vt220 on secure ttyC1 /usr/libexec/getty Pc vt220 on secure ttyC2 /usr/libexec/getty Pc vt220 on secure ttyC3 /usr/libexec/getty Pc vt220 on secure ttyC4 /usr/libexec/getty Pc vt220 off secure ttyC5 /usr/libexec/getty Pc vt220 on secure ttyC6 /usr/libexec/getty Pc vt220 off secure ttyC7 /usr/libexec/getty Pc vt220 off secure ttyC8 /usr/libexec/getty Pc vt220 off secure ttyC9 /usr/libexec/getty Pc vt220 off secure ttyCa /usr/libexec/getty Pc vt220 off secure ttyCb /usr/libexec/getty Pc vt220 off secure tty00 /usr/libexec/getty std.9600 vt220on secure tty01 /usr/libexec/getty std.9600 vt220on secure What's hurting you is that non-standard first com port. Take another look at your BIOS setup, see if there is anything that allows you to change how it is defined. Also check to make sure you don't have any BIOS-based redirection going..that can cause various problems that might be similar to this on some machines. (BIOS redirection is great, but unfortunately, not at all standardized, so results are sometimes unpredictable.) Nick. Thanks, Nick. You were indeed correct, and as always the inbuilt documentation - specifically for pccom(4) - had the answers. For the archives, the Aptiva BIOS had incorrect IRQ/address values for Serial Port 1 and Serial Port 2. A BIOS flash to the latest available version (perhaps unnecessary) and then setting these to match the values specified in pccom(4) resolved the issue. Your assistance is very much appreciated! Kind regards, Damon
Re: Serial console not working for IBM Aptiva
Damon McMahon wrote: Thanks for the response, Nick, I'm almost there and just one further query: On 18/02/07, Nick Holland [EMAIL PROTECTED] wrote: ... The Aptiva has an anaemic BIOS program, but by disabling one of the two serial interfaces I now appear to have eliminated IRQ conflicts and acquired a working serial console - BUT I lose nearly all of the dmesg(8) and init(8) output at boot, with it being directed to the screen instead. I also note that boot(8) tells me I have com0 and no com1 (which is expected since I disabled it in the BIOS) whereas dmesg(8) tells me I have pccom1 but no pccom0 and this seems a little strange to me. boot(8) tells you what the BIOS tells it. boot(8) uses the BIOS to communicate. dmesg(8) tells you what hardware OpenBSD actually found. The BIOS can define ports as it wishes. OpenBSD defines ports as spec'd in /usr/src/sys/arch/i386/conf/GENERIC From your dmesg, pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo That's not the standard definition for com0 (DOS COM1), but rather, com1 (DOS COM2:) From pccom(4): pccom0 at isa? port 0x3f8 irq 4 pccom1 at isa? port 0x2f8 irq 3 To clarify, boot(8) tells me I have com0 available at boot. So in /etc/boot.conf I tell it: set tty com0 and it switches to the console but all that is output to the console is: OpenBSD/i386 BOOT 2.10 boot booting hd0a:/bsd: 4966344+867848 [52+255872+237161]=0x608d64 entry point at 0x100120 so once the kernel is loaded, your redirection is screwed up... That's it for the output seen on the terminal, at this point the dmesg(8) and init(8) output is directed to the screen. Then when getty(8) is executed interactivity for _both_ the keyboard and the serial console are restored. I haven't played with this kind of config, but my guess is you are sending the output to a non-existant com0, so the system falls back to using the screen. You get the serial IO again after boot because of your ttys setting which has tty01 turned on, you would get the login prompt on the serial port even if you didn't do the set tty com0. Any further thoughts will be appreciated; dmesg(8) and ttys(5) are included below: ...thanks, snipped for size # head -n 20 /etc/ttys # # $OpenBSD: ttys,v 1.17 2002/06/09 06:15:14 todd Exp $ # # name getty typestatus comments # console /usr/libexec/getty Pc vt220 off secure ttyC0 /usr/libexec/getty Pc vt220 on secure ttyC1 /usr/libexec/getty Pc vt220 on secure ttyC2 /usr/libexec/getty Pc vt220 on secure ttyC3 /usr/libexec/getty Pc vt220 on secure ttyC4 /usr/libexec/getty Pc vt220 off secure ttyC5 /usr/libexec/getty Pc vt220 on secure ttyC6 /usr/libexec/getty Pc vt220 off secure ttyC7 /usr/libexec/getty Pc vt220 off secure ttyC8 /usr/libexec/getty Pc vt220 off secure ttyC9 /usr/libexec/getty Pc vt220 off secure ttyCa /usr/libexec/getty Pc vt220 off secure ttyCb /usr/libexec/getty Pc vt220 off secure tty00 /usr/libexec/getty std.9600 vt220on secure tty01 /usr/libexec/getty std.9600 vt220on secure What's hurting you is that non-standard first com port. Take another look at your BIOS setup, see if there is anything that allows you to change how it is defined. Also check to make sure you don't have any BIOS-based redirection going..that can cause various problems that might be similar to this on some machines. (BIOS redirection is great, but unfortunately, not at all standardized, so results are sometimes unpredictable.) Nick.
Re: Serial console not working for IBM Aptiva
Thanks for the response, Nick, I'm almost there and just one further query: On 18/02/07, Nick Holland [EMAIL PROTECTED] wrote: [snip] Been there, seen that, kicked self in butt once I realized the port I was trying to use as a serial terminal was also configured as a serial console for the terminal machine (D'oh!). Basically, the two machines start bouncing back and forth off each other, and nothing works as desired. Yup, makes perfect sense now. [snip] pccom1: irq 3 already in use pccom2: irq 5 already in use And that tells us more. Note that it's pccom1 and pccom2, but no pccom0... pccom devices are ISA devices, so they can't share IRQs with PCI devices (though, of course, PCI devices can share IRQs with each other). So that's why com0 didn't work, and the IRQ conflict won't make com1 and com2 work very well... Take a close look at your machine config (most likely, the BIOS setup program), you will probably find non-standard configs for the two serial ports. You might need to tag IRQ 3 as Reserved for ISA or similar. The Aptiva has an anaemic BIOS program, but by disabling one of the two serial interfaces I now appear to have eliminated IRQ conflicts and acquired a working serial console - BUT I lose nearly all of the dmesg(8) and init(8) output at boot, with it being directed to the screen instead. I also note that boot(8) tells me I have com0 and no com1 (which is expected since I disabled it in the BIOS) whereas dmesg(8) tells me I have pccom1 but no pccom0 and this seems a little strange to me. To clarify, boot(8) tells me I have com0 available at boot. So in /etc/boot.conf I tell it: set tty com0 and it switches to the console but all that is output to the console is: OpenBSD/i386 BOOT 2.10 boot booting hd0a:/bsd: 4966344+867848 [52+255872+237161]=0x608d64 entry point at 0x100120 That's it for the output seen on the terminal, at this point the dmesg(8) and init(8) output is directed to the screen. Then when getty(8) is executed interactivity for _both_ the keyboard and the serial console are restored. Any further thoughts will be appreciated; dmesg(8) and ttys(5) are included below: # dmesg OpenBSD 3.9 (GENERIC) #617: Thu Mar 2 02:26:48 MST 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium III (GenuineIntel 686-class, 512KB L2 cache) 549 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,SER,MMX ,FXSR,SSE cpu0: disabling processor serial number real mem = 66625536 (65064K) avail mem = 53170176 (51924K) using 838 buffers containing 3432448 bytes (3352K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(ff) BIOS, date 06/30/99, BIOS32 rev. 0 @ 0xf0210 pcibios0 at bios0: rev 2.1 @ 0xf0200/0xb00 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf9e00/128 (6 entries) pcibios0: PCI Interrupt Router at 000:07:0 (Intel 82371AB PIIX4 ISA rev 0x00) pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc/0xa000 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82443BX AGP rev 0x03 ppb0 at pci0 dev 1 function 0 Intel 82443BX AGP rev 0x03 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 S3 Savage 4 rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) pcib0 at pci0 dev 7 function 0 Intel 82371AB PIIX4 ISA rev 0x02 pciide0 at pci0 dev 7 function 1 Intel 82371AB IDE rev 0x01: DMA, channel 0 wi red to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: Maxtor 91021U2 wd0: 16-sector PIO, LBA, 9770MB, 20010816 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: SONY, CD-RW CRX100E, 2.0h SCSI0 5/cdrom removabl e cd0(pciide0:1:0): using PIO mode 4, DMA mode 2 uhci0 at pci0 dev 7 function 2 Intel 82371AB USB rev 0x01: irq 11 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered piixpm0 at pci0 dev 7 function 3 Intel 82371AB Power rev 0x02: polling iic0 at piixpm0 eso0 at pci0 dev 11 function 0 ESS SOLO-1 AudioDrive rev 0x01: ES1946, irq 10 eso0: mapping Audio 1 DMA using VC I/O space at 0x8cc0 audio0 at eso0 opl0 at eso0: model OPL3 midi0 at opl0: ESO Yamaha OPL3 Conexant 56k Winmodem rev 0x08 at pci0 dev 13 function 0 not configured sis0 at pci0 dev 14 function 0 NS DP83815 10/100 rev 0x00, DP83815C: irq 10, a ddress 00:a0:cc:74:48:46 nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1 rl0 at pci0 dev 16 function 0 Accton MPX 5030/5038 rev 0x10: irq 9, address 00 :10:b5:08:5c:32 rlphy0 at rl0 phy 0: RTL internal PHY isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pcppi0 at isa0 port 0x61 midi1 at pcppi0: PC speaker spkr0 at pcppi0 npx0 at isa0 port
Serial console not working for IBM Aptiva
Greetings, I've installed OBSD 3.9 on an old (circa 2000) IBM Aptiva successfully, but I'm having trouble configuring a serial console for it. Firstly, selecting a serial console at installation produced an incorrect boot.conf as follows: # cat /etc/boot.conf stty com 9600 set tty com Unsurprisingly this didn't boot with boot(8) reporting the device com was not a proper console device. boot(8) did find pc0, com0 and com1 however, so I changed boot.conf: # cat /etc/boot.conf stty com0 9600 set tty com0 After connecting a known working null modem cable to COM2 [yes, COM2 not COM1] on the Aptiva we make progress attempting to connect a serial console from another OBSD 3.9 machine and then booting the Aptiva, but not much: # tip tty00 connected boot 10 boting hd0a:10: open hd0a:10: No such file or directory failed(2). will try /obsd boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot boot