Re: Multiple serial consoles via null modem cable
Hello Jeremy, Now I'm a little confused :) I've made some tests with my machines and a couple of null modem cables, and here's what I've got. On Wed, Jan 20, 2010 at 9:46 AM, Jeremy Chadwick free...@jdc.parodius.comwrote: On Wed, Jan 20, 2010 at 08:46:48AM +0200, Marin Atanasov wrote: Hello, Using `cu' only works with COM1 for me. Currently I have two serial ports on the system, and only the first is able to make the connection - the serial consoles are enabled in /etc/tty, but as I said only COM1 is able to make the connection. I'm a little confused by this statement, so I'll add some clarify: /etc/ttys is for configuring a machine to tie getty (think login prompt) to a device (in this case, a serial port). Meaning: the device on the other end of the serial cable will start seeing login: and so on assuming you attach to the serial port there. For example: box1 COM1/ttyu0 is wired to box2 COM3/ttyu2 using a null modem cable. box1 COM2/ttyu1 is wired to box2 COM4/ttyu3 using a null modem cable. On box1, you'd have something like this in /etc/ttys: ttyu0 /usr/libexec/getty std.9600 vt100 on secure ttyu1 /usr/libexec/getty std.9600 vt100 on secure Here's what I did: box1 COM1/ttyd0 - box2 COM1/ttyd0 - using null modem cable box1 COM2/ttyd1 - box3 COM1/ttyd0 - using null modem cable On box1 I have this in /etc/ttys: ttyd0 /usr/libexec/getty std.9600 vt100 on secure ttyd1 /usr/libexec/getty std.9600 vt100 on secure Now if I want to connect to box1 from box2 or box3 through the serial connection it should work, right? But I only can connect to box1 from box2, because box2's COM port is connected to box1's COM1 port. From box2 I can get a login prompt box2# cu -l /dev/cuad0 -s 9600 Connected login: ) (host.domain) (ttyd0) login: ~ [EOT] But if I try to connect to box1 from box3 - no success there. box3# cu -l /dev/cuad0 -s 9600 Connected ~ [EOT] This means that login prompts for box1 will be spawned/available on both serial ports (ttyu0 and ttyu1). If you get on box2 and do cu -l ttyu2, this will connect you to box2's COM3 port, which is physically connected to box1's COM1 port. Hit enter and you should see a login: prompt for box1. The same applies if you get on box2 and do cu -l ttyu3 (but for box2's COM4 port, which is wired to box1's COM2 port). With the above configuration in mind, you SHOULD NOT: - Mess with /etc/ttys on box2 - Execute cu -l ttyu0 or cu -l ttyu1 on box1 -- this probably won't work (likely will return some message about the device being locked or in use already). You cannot do something like where box1 COM1 is wired to box2 COM1, and depending on what box you're on doing the cu -l ttyu0 from, get a login prompt on the other. It doesn't work like that. :-) Now, about actual *serial console* itself -- that is to say, kernel output during boot, etc... on a serial port. AFAIK, on FreeBSD you can only set serial console to a single serial port, and that defaults to COM1/ttyu0. You can change what port/device, but there can only be one. Yes, probably I didn't explain myself better, but you did it good - what I was trying to say is that I can use only one COM port for serial console, which of course defaults to COM1. Also is conserver/conserver-com able to handle more than one serial consoles on a machine? I haven't tried conserver yet. Thanks for the good explanation again :) Marin HTH... Now On Sun, Jan 17, 2010 at 3:32 PM, Ronald Klop ronald-freeb...@klop.yi.orgwrote: On Fri, 15 Jan 2010 07:34:17 +0100, Marin Atanasov dna...@gmail.com wrote: Thank you a lot for your feedback! Now to the real question again, because I'm a little confused now - can I still get a usb-to-serial port converter having let's say 8 serial ports and then connect each machine to the usb-to-serial hub and manage them remotely from a single location (the host having the usb-to-serial hub)? That way I just specify a serial port number and I get to a specific machine? The model provided by Boris looks nice, and that was my initial idea, but I'm not sure if I could get it working under FreeBSD. Is conserver or conserver-com able to handle this? I know that cu uses COM1 only, but will conserver able to handle serial consoles on different ports, since the usb-to-serial port would appear as multiple serial ports. You can provide cu with the port to connect to on the command line. cu -l cuaU0 -s 115200 cu -l cuaU1 -s 115200 etc. You can not connect several servers on 1 serial port, but you can connect several servers on several serial ports. With serial-over-usb it scales to many serial ports. Ronald. Thank you and regards, Marin On Tue, Jan 12, 2010 at 7:04 PM, Boris Samorodov b...@ipt.ru wrote: On Tue, 12 Jan 2010 17:14:44 +0200 Marin Atanasov wrote: I'm thinking about the
Re: DELL SAS5/E Controller bug
On Thursday 21 January 2010 2:21:48 am Stephane LAPIE wrote:
John Baldwin wrote:
On Wednesday 20 January 2010 10:09:43 am Stephane LAPIE wrote:
John Baldwin wrote:
On Wednesday 20 January 2010 4:30:52 am Stephane LAPIE wrote:
Hello list,
Basically I'm experiencing the same problem as described here :
https://forums.freebsd.org/showthread.php?t=9407 (linking for
reference)
Drives disconnections are not recognized instantly, and instead I get
the following dmesg entries :
mpt0: mpt_cam_event: 0x16
mpt0: mpt_cam_event: 0x16
(Sometimes I also get mpt0: mpt_cam_event: 0x12 events)
This is really crippling as this litterally paralyzes the ZFS pool
until
the controller finally comes to its senses (...or until a disk gets
replugged in, which provokes a flush of all the buffered failed SCSI
requests).
Hardware is recognized as :
m...@pci0:6:8:0: class=0x01 card=0x1f041028 chip=0x00541000
rev=0x01
hdr=0x00
vendor = 'LSI Logic (Was: Symbios Logic, NCR)'
device = 'SAS 3000 series, 8-port with 1068 -StorPort'
class = mass storage
subclass = SCSI
Did anyone else experience this, or find a proper work-around ?
Invoke 'camcontrol rescan' after removing a drive. mptutil(8) does the
equivalent when adding and removing volumes to make up for the driver
not
automatically rescanning.
I already tried reset/rescan via camcontrol, but after removing a drive,
the process freezes (process status D, Ctrl+T in terminal shows it's
in a cbwait state, it can't be bg'ed). I did not wait for a hardware
timeout, I tried replugging the drive, which released the ZFS and
camcontrol locks.
Also, I tried poking around with mptutil and could obtain the following
information, if it can be of any help :
freebsd-r610# mptutil -u 0 show adapter
mpt0 Adapter:
Board Name: SAS5e
Board Assembly:
Chip Name: C1068
Chip Revision: UNUSED
RAID Levels: none
mptutil: Reading config page header failed: Invalid configuration page
(The above error message should be normal since this is not a RAID
controller, though a bit jarring)
This patch should fix that:
Index: mpt_show.c
===
--- mpt_show.c (revision 202640)
+++ mpt_show.c (working copy)
@@ -78,6 +78,7 @@
CONFIG_PAGE_MANUFACTURING_0 *man0;
CONFIG_PAGE_IOC_2 *ioc2;
CONFIG_PAGE_IOC_6 *ioc6;
+ U16 IOCStatus;
int fd, comma;
if (ac != 1) {
@@ -108,7 +109,7 @@
free(man0);
- ioc2 = mpt_read_ioc_page(fd, 2, NULL);
+ ioc2 = mpt_read_ioc_page(fd, 2, IOCStatus);
if (ioc2 != NULL) {
printf( RAID Levels:);
comma = 0;
@@ -151,9 +152,10 @@
printf( none);
printf(\n);
free(ioc2);
- }
+ } else if (IOCStatus != MPI_IOCSTATUS_CONFIG_INVALID_PAGE)
+ warnx(mpt_read_ioc_page(2): %s, mpt_ioc_status(IOCStatus));
- ioc6 = mpt_read_ioc_page(fd, 6, NULL);
+ ioc6 = mpt_read_ioc_page(fd, 6, IOCStatus);
if (ioc6 != NULL) {
display_stripe_map(RAID0 Stripes,
ioc6-SupportedStripeSizeMapIS);
@@ -172,7 +174,8 @@
printf(-%u, ioc6-MaxDrivesIME);
printf(\n);
free(ioc6);
- }
+ } else if (IOCStatus != MPI_IOCSTATUS_CONFIG_INVALID_PAGE)
+ warnx(mpt_read_ioc_page(2): %s, mpt_ioc_status(IOCStatus));
/* TODO: Add an ioctl to fetch IOC_FACTS and print firmware version. */
However, the following is a bit disturbing :
freebsd-r610# mptutil -u 0 show drives
mpt0 Physical Drives:
da0 ( 932G) ONLINE SEAGATE ST31000640SS MS04 SAS bus 0 id 0
da1 ( 932G) ONLINE SEAGATE ST31000640SS MS04 SAS bus 0 id 1
da2 ( 932G) ONLINE SEAGATE ST31000640SS MS04 SAS bus 0 id 2
da3 ( 932G) ONLINE SEAGATE ST31000640SS MS04 SAS bus 0 id 3
da4 ( 932G) ONLINE SEAGATE ST31000640SS MS04 SAS bus 0 id 4
da5 ( 932G) ONLINE SEAGATE ST31000640SS MS04 SAS bus 0 id 5
da6 ( 932G) ONLINE SEAGATE ST31000640SS MS05 SAS bus 0 id 6
da7 ( 932G) ONLINE SEAGATE ST31000640SS MS05 SAS bus 0 id 7
da8 ( 932G) ONLINE SEAGATE ST31000640SS MS05 SAS bus 0 id 8
da9 ( 932G) ONLINE SEAGATE ST31000640SS MS05 SAS bus 0 id 9
da10 ( 932G) ONLINE SEAGATE ST31000640SS MS05 SAS bus 0 id 10
da11 ( 932G) ONLINE SEAGATE ST31000640SS MS05 SAS bus 0 id 11
da12 ( 932G) ONLINE SEAGATE ST31000640SS MS05 SAS bus 0 id 12
da13 ( 932G) ONLINE SEAGATE ST31000640SS MS05 SAS bus 0 id 13
da14 ( 932G) ONLINE SEAGATE ST31000640SS MS05 SAS bus 0 id 14
da15 ( 136G) ONLINE Dell VIRTUAL DISK 1028 SAS bus 0 id 0
The above listing seems weird, as da15 should belong to mpt1.
Agreed. I specifically ask that CAM only return results for devices on
bus 0
of mptX. Before when I debugged
Re: Multiple serial consoles via null modem cable
On Thu, 21.01.2010 at 11:37:06 +0200, Marin Atanasov wrote: Here's what I did: box1 COM1/ttyd0 - box2 COM1/ttyd0 - using null modem cable box1 COM2/ttyd1 - box3 COM1/ttyd0 - using null modem cable On box1 I have this in /etc/ttys: ttyd0 /usr/libexec/getty std.9600 vt100 on secure ttyd1 /usr/libexec/getty std.9600 vt100 on secure Now if I want to connect to box1 from box2 or box3 through the serial connection it should work, right? But I only can connect to box1 from box2, because box2's COM port is connected to box1's COM1 port. Are there actually two gettys running on the serial ports? Did you do kill -1 1 after the changes to /etc/ttys? On box1, what do the following commands produce egrep uart|sio /var/run/dmesg.boot pgrep -fl getty Regards, Uli ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to freebsd-hardware-unsubscr...@freebsd.org
ichwd device ID for Intel H55 Express Watchdog
In case anyone else is looking to enable this for their Intel i3 MB, you just need to add the device ID http://www.freebsd.org/cgi/query-pr.cgi?pr=143068http://www.freebsd.org/cgi/query-pr.cgi?pr=143068 0(i3)% dmesg Copyright (c) 1992-2010 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #0: Thu Jan 21 15:14:14 EST 2010 mdtan...@ich10.sentex.ca:/usr/HEAD/obj/usr/HEAD/src/sys/alix i386 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz (2926.02-MHz 686-class CPU) Origin = GenuineIntel Id = 0x20652 Stepping = 2 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x98e3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT AMD Features=0x2810NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 1073741824 (1024 MB) avail memory = 894103552 (852 MB) ACPI APIC Table: INTEL DH55TC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 4 ACPI Warning: 32/64X FACS address mismatch in FADT - 3762AE40/ 03762AD40, using 32 (20091214/tbfadt-586) ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 cryptosoft0: software crypto on motherboard acpi0: INTEL DH55TC on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 vgapci0: VGA-compatible display port 0xf100-0xf107 mem 0xfe00-0xfe3f,0xd000-0xdfff irq 16 at device 2.0 on pci0 pci0: simple comms at device 22.0 (no driver attached) atapci0: Intel ATA controller port 0xf0f0-0xf0f7,0xf0e0-0xf0e3,0xf0d0-0xf0d7,0xf0c0-0xf0c3,0xf0b0-0xf0bf irq 18 at device 22.2 on pci0 atapci0: [ITHREAD] ata2: ATA channel 0 on atapci0 ata2: [ITHREAD] ata3: ATA channel 1 on atapci0 ata3: [ITHREAD] pci0: simple comms, UART at device 22.3 (no driver attached) em0: Intel(R) PRO/1000 Network Connection 6.9.24 port 0xf040-0xf05f mem 0xfe40-0xfe41,0xfe428000-0xfe428fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:27:0e:09:5e:00 ehci0: Intel PCH USB 2.0 controller USB-B mem 0xfe427000-0xfe4273ff irq 16 at device 26.0 on pci0 ehci0: [ITHREAD] usbus0: EHCI version 1.0 usbus0: Intel PCH USB 2.0 controller USB-B on ehci0 pci0: multimedia, HDA at device 27.0 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 17 at device 28.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge irq 17 at device 28.4 on pci0 pci2: ACPI PCI bus on pcib2 ehci1: Intel PCH USB 2.0 controller USB-A mem 0xfe426000-0xfe4263ff irq 23 at device 29.0 on pci0 ehci1: [ITHREAD] usbus1: EHCI version 1.0 usbus1: Intel PCH USB 2.0 controller USB-A on ehci1 pcib3: ACPI PCI-PCI bridge at device 30.0 on pci0 pci3: ACPI PCI bus on pcib3 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 ahci0: Intel PCH AHCI SATA controller port 0xf090-0xf097,0xf080-0xf083,0xf070-0xf077,0xf060-0xf063,0xf020-0xf03f mem 0xfe425000-0xfe4257ff irq 19 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.30 with 6 3Gbps ports, Port Multiplier not supported ahcich0: AHCI channel at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: AHCI channel at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: AHCI channel at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: AHCI channel at channel 3 on ahci0 ahcich3: [ITHREAD] ahcich4: AHCI channel at channel 4 on ahci0 ahcich4: [ITHREAD] ahcich5: AHCI channel at channel 5 on ahci0 ahcich5: [ITHREAD] pci0: serial bus, SMBus at device 31.3 (no driver attached) acpi_button0: Power Button on acpi0 atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] uart0: 16550 or compatible port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (9600,n,8,1) cpu0: ACPI CPU on acpi0 est0: Enhanced SpeedStep Frequency Control on cpu0 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 est1: Enhanced SpeedStep Frequency Control on cpu1 p4tcc1: CPU Frequency Thermal Control on cpu1 pmtimer0 on isa0 orm0: ISA Option ROM at iomem 0xcd000-0xcdfff pnpid ORM on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem
Re: DELL SAS5/E Controller bug
John Baldwin wrote: Gah, that should be the case that I ignore. Can you replace the second warnx() call I added with this: warnx(mpt_read_ioc_page(6): %s (%x), mpt_ioc_status(IOCStatus), IOCStatus); I now get the following message : mptutil: mpt_read_ioc_page(6): Invalid configuration page (8022) (Though I guess this doesn't tell anything that we did not know initially) I know that the rescan after removing a device is a bit messy (lots of messages before daX actually goes away), but I don't recall it taking such a long time. Even without rescanning the bus, the device actually goes away on its own after the same delay of three minutes. The documentation is not public. The 0x12 and 0x16 messages are events that I have seen. You can try talking to scottl@ as he has access to the docs. I could contact Scott, and here are the relevant bits of his answer : The basic problem is that FreeBSD still sees all of this as parallel SCSI, subject to rescans and resets and timeouts. It's fighting with the SAS controller. I'll explain more below. I'm working on code that will make FreeBSD more aware of how SAS works. It's several months from being done, though. Reposting here for reference the meaning of 0x12 and 0x16 events : 0x12 : SAS Link status changed 0x16 : SAS Discovery Event I was wondering if using an Areca SAS controller could be a better solution, but Scott's answer has me wondering if this is a common issue to all SAS controllers on FreeBSD. -- Stephane LAPIE, EPITA SRS, Promo 2005 Even when they have digital readouts, I can't understand them. --MegaTokyo signature.asc Description: OpenPGP digital signature
Re: Multiple serial consoles via null modem cable
On Thu, Jan 21, 2010 at 6:26 PM, Ulrich Spörlein u...@spoerlein.net wrote: On Thu, 21.01.2010 at 11:37:06 +0200, Marin Atanasov wrote: Here's what I did: box1 COM1/ttyd0 - box2 COM1/ttyd0 - using null modem cable box1 COM2/ttyd1 - box3 COM1/ttyd0 - using null modem cable On box1 I have this in /etc/ttys: ttyd0 /usr/libexec/getty std.9600 vt100 on secure ttyd1 /usr/libexec/getty std.9600 vt100 on secure Now if I want to connect to box1 from box2 or box3 through the serial connection it should work, right? But I only can connect to box1 from box2, because box2's COM port is connected to box1's COM1 port. Are there actually two gettys running on the serial ports? Did you do kill -1 1 after the changes to /etc/ttys? On box1, what do the following commands produce egrep uart|sio /var/run/dmesg.boot pgrep -fl getty Regards, Uli Hi, This is the output from the requested commands: box1# egrep 'uart|sio' /var/run/dmesg.boot usb0: USB revision 1.0 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: 16550A-compatible COM port port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A box1# pgrep -fl getty 3066 /usr/libexec/getty std.9600 ttyd1 3065 /usr/libexec/getty std.9600 ttyd0 534 /usr/libexec/getty Pc ttyv7 533 /usr/libexec/getty Pc ttyv6 532 /usr/libexec/getty Pc ttyv5 531 /usr/libexec/getty Pc ttyv4 530 /usr/libexec/getty Pc ttyv3 529 /usr/libexec/getty Pc ttyv2 528 /usr/libexec/getty Pc ttyv1 527 /usr/libexec/getty Pc ttyv0 Regards, Marin -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to freebsd-hardware-unsubscr...@freebsd.org
