From owner-freebsd-hardware@FreeBSD.ORG Sun Jan 17 13:44:02 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D18DD106566C for ; Sun, 17 Jan 2010 13:44:02 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out0.tiscali.nl (smtp-out0.tiscali.nl [195.241.79.175]) by mx1.freebsd.org (Postfix) with ESMTP id 63A098FC0C for ; Sun, 17 Jan 2010 13:44:02 +0000 (UTC) Received: from [212.123.145.58] (helo=sjakie.klop.ws) by smtp-out0.tiscali.nl with esmtp (Exim) (envelope-from ) id 1NWVEw-0006Qj-6V; Sun, 17 Jan 2010 14:32:26 +0100 Received: from 212-123-145-58.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id DCE93F49F; Sun, 17 Jan 2010 14:32:21 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Marin Atanasov" , freebsd-hardware@freebsd.org References: <717f7a3e1001120714m37aada69gfaa35f0f9b17f435@mail.gmail.com> <44678539@bb.ipt.ru> <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> Date: Sun, 17 Jan 2010 14:32:21 +0100 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: In-Reply-To: <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> User-Agent: Opera Mail/10.10 (FreeBSD) Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Multiple serial consoles via null modem cable X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 13:44:02 -0000 On Fri, 15 Jan 2010 07:34:17 +0100, Marin Atanasov =20 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 port= s =20 > and > then connect each machine to the usb-to-serial hub and manage them =20 > remotely > from a single location (the host having the usb-to-serial hub)? That wa= y =20 > 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, b= ut > 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 =20 > 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= =20 several servers on several serial ports. With serial-over-usb it scales t= o =20 many serial ports. Ronald. > > Thank you and regards, > Marin > > > On Tue, Jan 12, 2010 at 7:04 PM, Boris Samorodov wrote: > >> On Tue, 12 Jan 2010 17:14:44 +0200 Marin Atanasov wrote: >> >> > I'm thinking about the following situation - 1 system acting like a = =20 >> host >> > with a serial port hub, each port of the hub is connected to a =20 >> different >> > machine on sio0, using null modem cables. >> >> Along with milti-io serial cards we use multi-usb serial >> converters, such as SUNIX UTS7009P (7 USB to serial adapter): >> http://www.sunix.com.tw/it/en/LinkCraft/UTS4009P_UTS7009P.htm >> >> -- >> WBR, Boris Samorodov (bsam) >> Research Engineer, http://www.ipt.ru Telephone & Internet SP >> FreeBSD Committer, http://www.FreeBSD.org The Power To Serve >> > > > From owner-freebsd-hardware@FreeBSD.ORG Mon Jan 18 02:55:10 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56BA5106566B for ; Mon, 18 Jan 2010 02:55:10 +0000 (UTC) (envelope-from mureninc@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 27BD18FC18 for ; Mon, 18 Jan 2010 02:55:09 +0000 (UTC) Received: by pxi13 with SMTP id 13so1740680pxi.3 for ; Sun, 17 Jan 2010 18:55:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MakZ0jV4uYoIw3yKeEpPn7TTAl4CWF92iimu/03qN7g=; b=LopdzFD16Vl60j0vFv9ROrZM68H3BzPOfEpvwRD7W1xeQ9xwmemied5FcPeoWWBciI OxkaVEZG3J8otqSTHmhjbGBLMJePliggowwTqdMvMOY0yH1+UVSkVpAq0XxRON4CD2uK 3p/Plma98YzEmZKxv92YzS7sUkJxEC8DCRDv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fMW3374LLZwe+A7exy08iITH5pMUCPRz17IfNPF1jUA8I/7aB9V03GwyU4y9luaZB9 s+Cyd7pKbx+7nvuom/ViFMSCIQT52aTZCYWizdfrMMLY3uuncp+ozkKzlYrMvvwqyGVd AQLKAtOduRag4L0cr2AghBff7DHmnhUlY2ikg= MIME-Version: 1.0 Received: by 10.142.1.35 with SMTP id 35mr3736194wfa.330.1263783309620; Sun, 17 Jan 2010 18:55:09 -0800 (PST) In-Reply-To: <20100107195213.b2c7e942.lehmann@ans-netz.de> References: <20100105192746.cc627795.lehmann@ans-netz.de> <20100107063413.614058fc.lehmann@ans-netz.de> <20100107063831.GA53300@icarus.home.lan> <20100107074805.59556.qmail@avocado.salatschuessel.net> <20100107080914.60245.qmail@avocado.salatschuessel.net> <20100107083908.GA58065@icarus.home.lan> <20100107195213.b2c7e942.lehmann@ans-netz.de> Date: Sun, 17 Jan 2010 21:55:09 -0500 Message-ID: From: "Constantine A. Murenin" To: Oliver Lehmann Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hardware@freebsd.org Subject: Re: smb driver for Nvidia ION (intel ATOM) chipset X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 02:55:10 -0000 2010/1/7 Oliver Lehmann : > Jeremy Chadwick wrote: > >> If you'd like, I can code up something that uses LPC/ISA to communicate >> with this IC via port 0x290 based on the datasheet. > > I now was able to "hack up" mbmon to communicate with my it8720 sensor. > I've attached the patch for sens_it87.c > I also added to Makefile to the DEFS =3D line "-DIT8720" of course. This > made mbmon working with ISA-IO mode working. I'm now getting the > following outputs: > > Temp.=3D 32.0, 34.0, 22.0; Rot.=3D 4591, 1298, =A0 =A00 > Vcore =3D 1.10, 1.81; Volt. =3D 3.39, 4.95, 11.93, -11.93, -4.99 > > I can nearly verify all values with the BIOS and they are matching. I > XXed in the following output (same as above) all values out I was not > able to verify because the BIOS-HWM does not show their values: > > Temp.=3D 32.0, XXX, XXX; Rot.=3D 4591, 1298, =A0 =A00 > Vcore =3D 1.10, XXXX; Volt. =3D 3.39, 4.95, 11.93, -11.93, XXXXX > > For the remaining values I'm pretty sure they are correct. > I enabled the 16Bit RPM mode for the 8720. In this case no devisor is > needed for calculating the RPM. I was not able to get the 2nd FAN-RPM > right in the 8Bit mode. The 1st one was correct even in the 8Bit mode. > About the voltage multipliers... I'm not sure about the last one because > I'm not able to verify this (I could with a multimeter of course but this > would create other deviations). > I'm also not sure why the multipliers (for my board?) are different. I > wonder why they are hardcoded there anyway. I can imagine that they are > depending the board layout or am I mistaken? I mean the IT spec says only > that the input of the pins need to be in the range between 0 and VCC. So > I can choose whatever multiplier I like as long as the resulting voltage > keeps within this range. Keeping the measured voltage somewhere in the > middle of 0 and VCC with the multiplier for the expected value makes > sense but this is no "must be" I guess > > Now - since ISA-IO is working I want to get smbus working too ;) > First I patched src/sys/pci/nfsmb.c to detect the known remaning nforce > SMB controllers including mine. > I then added the device-id of this controller to the pci_pm.h file of > mbmon to make it detect my controller. > But now it still fails to find the it87 sensor on the bus. I guess the > bus can have many "slaves" and mbmon just needs to test all to find out > which identifies itself as it87? (reading from Adress 0x58 should return > 0x90 - at least in ISA mode) > > root@nudel xmbmon205> ./mbmon -S -D -p it87 > Probe Request: it87 >>>> Testing Reg's at SMBus <<< > =A0SMBus slave 0xA0(0x50) found... > =A0SMBus slave 0xA2(0x51) found... > =A0SMBus slave 0xA4(0x52) found... > =A0SMBus slave 0xA6(0x53) found... > =A0SMBus slave 0xA8(0x54) found... > =A0SMBus slave 0xAA(0x55) found... > =A0SMBus slave 0xAC(0x56) found... > =A0SMBus slave 0xAE(0x57) found... > SMBus[NVidia nForce2] found, but No HWM available on it!! > InitMBInfo: Device not configured > Exit 1 > root@nudel xmbmon205> ./mbmon -S -s1 -D -p it87 > Probe Request: it87 >>>> Testing Reg's at SMBus <<< > =A0SMBus slave 0xA0(0x50) found... > =A0SMBus slave 0xA2(0x51) found... > =A0SMBus slave 0xE0(0x70) found... > SMBus[NVidia nForce2] found, but No HWM available on it!! > InitMBInfo: Device not configured > Exit 1 > root@nudel xmbmon205> > > But it looks like at least the smb detection code for it87 is not working > for mine... > > Any ideas how to proceed here? >From my experience, you can hardly ever find these ITE Super I/O chips through the SMBus =97 perhaps no motherboard manufacturer ever bothered to connect the two? (For what it's worth, the situation is somewhat similar with Winbond Super I/O LPC solutions; however, discovering Winbond chips on both ISA and I2C ports is not nearly as uncommon.) C. From owner-freebsd-hardware@FreeBSD.ORG Mon Jan 18 15:01:47 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72E151065679 for ; Mon, 18 Jan 2010 15:01:47 +0000 (UTC) (envelope-from cowens@greatbaysoftware.com) Received: from portcityhosting.com (bayringfw.portcityweb.com [64.140.243.92]) by mx1.freebsd.org (Postfix) with ESMTP id 14ED98FC21 for ; Mon, 18 Jan 2010 15:01:46 +0000 (UTC) Received: from [127.0.0.1] ([173.14.128.81]) by portcityhosting.com with MailEnable ESMTP; Mon, 18 Jan 2010 10:01:47 -0500 X-WatchGuard-Mail-Exception: Allow Message-ID: <4B5478D1.4000900@greatbaysoftware.com> Date: Mon, 18 Jan 2010 10:05:53 -0500 From: Charles Owens MIME-Version: 1.0 To: freebsd-hardware@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-WatchGuard-AntiVirus: part scanned. clean action=allow X-ME-Bayesian: 0.000000 Subject: Minute+ delay between kernel load and initialization X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 15:01:47 -0000 Hello, We have a new system based on the Intel S5520 motherboard that seems to work fine except during _every_ boot it pauses for about one minute 15 seconds just before any kernel initialization messages appear. We see the loader appearing to complete its work (the kernel is loaded) and then... it sits. Once it starts up again (with usual kernel-boot messages) it appears to boot normally (no error messages). This has been seen with both FreeBSD 8.0 and 7.1, using GENERIC kernels. I'd appreciate any and all assistance in figuring this out. Boot output follows (happens to be from a PAE-enabled kernel) Thank you, Charles # again... we see this output immediately _after_ the delay ends: Copyright (c) 1992-2009 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 7.1-RELEASE-p5 #2: Fri Dec 18 15:03:26 UTC 2009 cowens@n_newcastle.greatbaysoftware.com:/usr/obj/usr/src/sys/BEACON Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU E5504 @ 2.00GHz (1995.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Stepping = 5 Features=0xbfebfbff Features2=0x9ce3bd AMD Features=0x28100000 AMD Features2=0x1 Cores per package: 8 Logical CPUs per core: 2 real memory = 8321499136 (7936 MB) avail memory = 6206566400 (5919 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard lapic0: Forcing LINT1 to edge trigger registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 28 at device 1.0 on pci0 pci1: on pcib1 igb0: port 0x3020-0x303f mem 0xb1b20000-0xb1b3ffff,0xb1b44000-0xb1b47fff irq 40 at device 0.0 on pci1 igb0: Using MSIX interrupts with 6 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 00:15:17:ac:52:2d igb1: port 0x3000-0x301f mem 0xb1b00000-0xb1b1ffff,0xb1b40000-0xb1b43fff irq 28 at device 0.1 on pci1 igb1: Using MSIX interrupts with 6 vectors igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: Ethernet address: 00:15:17:ac:52:2c pcib2: irq 24 at device 3.0 on pci0 pci2: on pcib2 pcib3: at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 2.0 on pci3 pci4: on pcib4 em0: port 0x2020-0x203f mem 0xb1a60000-0xb1a7ffff,0xb1a40000-0xb1a5ffff irq 36 at device 0.0 on pci4 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:c6:79:60 em1: port 0x2000-0x201f mem 0xb1a20000-0xb1a3ffff,0xb1a00000-0xb1a1ffff irq 35 at device 0.1 on pci4 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:15:17:c6:79:61 pcib5: at device 4.0 on pci3 pci5: on pcib5 em2: port 0x1020-0x103f mem 0xb1960000-0xb197ffff,0xb1940000-0xb195ffff irq 34 at device 0.0 on pci5 em2: Using MSI interrupt em2: [FILTER] em2: Ethernet address: 00:15:17:c6:79:62 em3: port 0x1000-0x101f mem 0xb1920000-0xb193ffff,0xb1900000-0xb191ffff irq 24 at device 0.1 on pci5 em3: Using MSI interrupt em3: [FILTER] em3: Ethernet address: 00:15:17:c6:79:63 pcib6: irq 32 at device 9.0 on pci0 pci6: on pcib6 pcib7: irq 33 at device 10.0 on pci0 pci7: on pcib7 pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) pci0: at device 17.0 (no driver attached) pci0: at device 17.1 (no driver attached) pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) pci0: at device 22.0 (no driver attached) pci0: at device 22.1 (no driver attached) pci0: at device 22.2 (no driver attached) pci0: at device 22.3 (no driver attached) pci0: at device 22.4 (no driver attached) pci0: at device 22.5 (no driver attached) pci0: at device 22.6 (no driver attached) pci0: at device 22.7 (no driver attached) uhci0: port 0x40e0-0x40ff irq 19 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x40c0-0x40df irq 19 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x40a0-0x40bf irq 19 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xb1c22000-0xb1c223ff irq 19 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcib8: irq 16 at device 28.0 on pci0 pci8: on pcib8 pcib9: irq 16 at device 28.4 on pci0 pci9: on pcib9 vgapci0: mem 0xb0000000-0xb0ffffff,0xb1800000-0xb1803fff,0xb1000000-0xb17fffff irq 16 at device 0.0 on pci9 pcib10: irq 17 at device 28.5 on pci0 pci10: on pcib10 uhci3: port 0x4080-0x409f irq 16 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0x4060-0x407f irq 16 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0x4040-0x405f irq 16 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xb1c21000-0xb1c213ff irq 16 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib11: at device 30.0 on pci0 pci11: on pcib11 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x4108-0x410f,0x4114-0x4117,0x4100-0x4107,0x4110-0x4113,0x4020-0x403f mem 0xb1c20000-0xb1c207ff irq 18 at device 31.2 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.20 controller with 6 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: port not implemented ata3: [ITHREAD] ata4: on atapci0 ata4: port not implemented ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ata6: on atapci0 ata6: port not implemented ata6: [ITHREAD] ata7: on atapci0 ata7: port not implemented ata7: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 sio1: type 16550A, console sio1: [FILTER] ipmi0: port 0xca2,0xca3 on acpi0 ipmi0: KCS mode found at io 0xca2 on acpi cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 device_attach: acpi_perf1 attach returned 6 device_attach: acpi_perf1 attach returned 6 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr f device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 p4tcc2: on cpu2 cpu3: on acpi0 device_attach: acpi_perf3 attach returned 6 device_attach: acpi_perf3 attach returned 6 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr f device_attach: est3 attach returned 6 p4tcc3: on cpu3 ipmi1: on isa0 device_attach: ipmi1 attach returned 16 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xca7ff,0xca800-0xcb7ff,0xcb800-0xcc7ff pnpid ORM0000 on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ukbd0: on uhub2 kbd0 at ukbd0 ums0: on uhub2 ums0: X report 0x0002 not supported device_attach: ums0 attach returned 6 uhub8: on uhub5 uhub8: 4 ports with 4 removable, self powered ukbd1: on uhub8 kbd2 at ukbd1 uhid0: on uhub8 ums0: on uhub8 ums0: 5 buttons and Z dir. ums1: on uhub8 ums1: X report 0x0002 not supported device_attach: ums1 attach returned 6 Timecounters tick every 1.000 msec ad4: 238475MB at ata2-master SATA300 acd0: DVDROM at ata5-master SATA150 ipmi0: GEOM_JOURNAL: Journal 173943913: ad4s1a contains data. GEOM_JOURNAL: Journal 173943913: ad4s1a contains journal.IPMI device rev. 1, firmware rev. 0.2, version 2.0 GEOM_JOURNAL: Journal ad4s1a clean. ipmi0: Number of channels 2 ipmi0: Attached watchdog lapic4: Forcing LINT1 to edge trigger SMP: AP CPU #2 Launched! lapic6: Forcing LINT1 to edge trigger SMP: AP CPU #3 Launched! lapic2: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! GEOM_JOURNAL: Journal 3858085586: ad4s1d contains data. GEOM_JOURNAL: Journal 3858085586: ad4s1d contains journal. GEOM_JOURNAL: Journal ad4s1d clean. WARNING: Expected rawoffset 0, found 63 Trying to mount root from ufs:/dev/ad4s1a.journal -- Charles Owens Great Bay Software, Inc. From owner-freebsd-hardware@FreeBSD.ORG Wed Jan 20 00:53:33 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1E2F106568F for ; Wed, 20 Jan 2010 00:53:33 +0000 (UTC) (envelope-from rdgehlba@gehlbach.com) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) by mx1.freebsd.org (Postfix) with ESMTP id 8DB608FC1C for ; Wed, 20 Jan 2010 00:53:33 +0000 (UTC) Received: from iglou4.iglou.com ([192.107.41.39]:38870 helo=mail.iglou.com) by rdsmtp.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1NXOTB-0001Ok-8F by authid with igloumta_auth for freebsd-hardware@freebsd.org; Tue, 19 Jan 2010 19:30:49 -0500 Received: from smtp.gehlbach.com ([204.255.230.80]:64413 helo=[127.0.0.1]) by smtp.iglou.com with esmtps (TLS cipher TLSv1:AES256-SHA:256) (Exim MTA/8.19.3) (envelope-from ) id 1NXOTA-0007ZB-RP for freebsd-hardware@freebsd.org; Tue, 19 Jan 2010 19:30:48 -0500 Message-ID: <4B564EB7.5060706@gehlbach.com> Date: Tue, 19 Jan 2010 19:30:47 -0500 From: Richard Gehlbach User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-hardware@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 204.255.230.80 X-IgLou-Customer: f08e2c62dd1ea041dbbca8406504a28c Subject: Adaptec ASC-1045 controller not recognized in FBSD 8.0 X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 00:53:33 -0000 I'm setting up an LTO3 SAS tape drive in a FreeBSD version 8.0 using the Adaptec ASC-1045 controller. The controller is fine during machine post, but FreeBSD doesn't see the controller or tape drive after booting up. Are there drivers for this controller? Configuration options? The ASC-1045 and the ASC-1405 should use the same driver, as they are external and internal SAS port versions of the same card. Any help will be appreciated. Richard -- Richard D. Gehlbach Gehlbach Consulting Services rdgehlba@gehlbach.com 3321 Pepperhill Ct. 859.269.6658 Fax 859.266.7446 Lexington, KY 40502 From owner-freebsd-hardware@FreeBSD.ORG Wed Jan 20 05:11:57 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24D661065670 for ; Wed, 20 Jan 2010 05:11:57 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from sopwith.solgatos.com (pool-98-108-131-15.ptldor.fios.verizon.net [98.108.131.15]) by mx1.freebsd.org (Postfix) with ESMTP id D611B8FC0A for ; Wed, 20 Jan 2010 05:11:55 +0000 (UTC) Received: by sopwith.solgatos.com (Postfix, from userid 66) id 38100B64F; Sat, 16 Jan 2010 12:27:01 -0800 (PST) Received: from localhost by sopwith.solgatos.com (8.8.8/6.24) id BAA15886; Wed, 20 Jan 2010 01:06:52 GMT Message-Id: <201001200106.BAA15886@sopwith.solgatos.com> To: freebsd-hardware@freebsd.org In-reply-to: Your message of "Fri, 15 Jan 2010 08:34:17 +0200." <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> Date: Tue, 19 Jan 2010 17:06:52 PST From: Dieter Subject: Re: Multiple serial consoles via null modem cable X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 05:11:57 -0000 >From another thread awhile back, Jeremy Chadwick wrote: ] Anything that ] uses a Prolific chip will work well (supports custom serial rates, and ] does not drop/lose characters). The uplcom(4) driver is for this chip, ] and the man page lists off some consumer models/devices available. Also from the thread awhile back, Bernd Walter wrote: } This is because USB is absolutely crap for this purpose. } RS232 terminals, especially with long cables, can produce several kind } of spikes and ground loops, which USB is very very sensitive about. } The upcoming new USB stack does a lot about handling transmission } errors, but the underlying problem is USB and not FreeBSD. } The best thing software can do about this is avoiding the panics. } Nevertheless the new USB stack is likely not being merged into any alpha } supporting OS release, so even that will not happen for alpha. } } My advise is to use a completely other technology to connect the terminals. } A galvanic isolated USB device might work, but there are lot of PCI and } Ethernet devices on the market which are more solid by design than USB. If different systems are on different UPSs it might create a ground loop? If necessary, you can optically isolate the RS-232 line, which should fix the problem. http://www.rs232-converters.com/opto-isolated_converters/Opto-Isolated_RS232_RS485_RS422_Isolators.htm I have not actually tried this. This is just an example of the isolators available, not a recommendation for this specific product or vender. Google can find similar products. From owner-freebsd-hardware@FreeBSD.ORG Wed Jan 20 06:46:51 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A206106566B; Wed, 20 Jan 2010 06:46:51 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-ew0-f213.google.com (mail-ew0-f213.google.com [209.85.219.213]) by mx1.freebsd.org (Postfix) with ESMTP id 7263D8FC20; Wed, 20 Jan 2010 06:46:50 +0000 (UTC) Received: by ewy5 with SMTP id 5so5489098ewy.14 for ; Tue, 19 Jan 2010 22:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=TXYTK+Sah6uKQ2SMN2ErEUU/vZnbdLvRfAcdcJP6eak=; b=UO9i1j3E87Bd8+zdt3fLeG8e5AYFLYPV0B70zLPvSdOrAHAtrC0PNUOVEmxq7fURqI qEwU5af4jHNgd+TKyYcebn/CbCaWwAHYVbuX27+ZnyK7zkcHVaKM6kYf2HsSDQjgSTus PGmBSR613DaU9MeEobmJosvkx+JRbPjM9KEP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=voL83u5C74hIveS6Uv/cLrzG+eZJtl3nXo6k4OctDRalo4oKe36n6+71nVZbbZkfTR 5WD+IKixBwDmH2sfVL0WL1LX1T5vzA1+96TGOvpUQoGDNS3st3TM8JPZ9D8ATLYf1I3u C+AG4nms6ZY63G69q31nsnAwjVmffoOfI2FG0= MIME-Version: 1.0 Received: by 10.216.88.206 with SMTP id a56mr1119196wef.64.1263970008836; Tue, 19 Jan 2010 22:46:48 -0800 (PST) In-Reply-To: References: <717f7a3e1001120714m37aada69gfaa35f0f9b17f435@mail.gmail.com> <44678539@bb.ipt.ru> <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> Date: Wed, 20 Jan 2010 08:46:48 +0200 Message-ID: <717f7a3e1001192246o4dce4a82q57c05ff3f41b5feb@mail.gmail.com> From: Marin Atanasov To: Ronald Klop Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Multiple serial consoles via null modem cable X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 06:46:51 -0000 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. Regards, Marin On Sun, Jan 17, 2010 at 3:32 PM, Ronald Klop wrote: > On Fri, 15 Jan 2010 07:34:17 +0100, Marin Atanasov > 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 wrote: >> >> On Tue, 12 Jan 2010 17:14:44 +0200 Marin Atanasov wrote: >>> >>> > I'm thinking about the following situation - 1 system acting like a >>> host >>> > with a serial port hub, each port of the hub is connected to a >>> different >>> > machine on sio0, using null modem cables. >>> >>> Along with milti-io serial cards we use multi-usb serial >>> converters, such as SUNIX UTS7009P (7 USB to serial adapter): >>> http://www.sunix.com.tw/it/en/LinkCraft/UTS4009P_UTS7009P.htm >>> >>> -- >>> WBR, Boris Samorodov (bsam) >>> Research Engineer, http://www.ipt.ru Telephone & Internet SP >>> FreeBSD Committer, http://www.FreeBSD.org The Power To Serve >>> >>> >> >> >> > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org From owner-freebsd-hardware@FreeBSD.ORG Wed Jan 20 07:59:32 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40715106566C for ; Wed, 20 Jan 2010 07:59:32 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id D987D8FC14 for ; Wed, 20 Jan 2010 07:59:31 +0000 (UTC) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta03.westchester.pa.mail.comcast.net with comcast id XjlM1d0020mv7h053jlr1H; Wed, 20 Jan 2010 07:45:51 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta11.westchester.pa.mail.comcast.net with comcast id XjmD1d0013S48mS3XjmDps; Wed, 20 Jan 2010 07:46:16 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id ED1FF1E3033; Tue, 19 Jan 2010 23:46:11 -0800 (PST) Date: Tue, 19 Jan 2010 23:46:11 -0800 From: Jeremy Chadwick To: Marin Atanasov Message-ID: <20100120074611.GA405@icarus.home.lan> References: <717f7a3e1001120714m37aada69gfaa35f0f9b17f435@mail.gmail.com> <44678539@bb.ipt.ru> <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> <717f7a3e1001192246o4dce4a82q57c05ff3f41b5feb@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <717f7a3e1001192246o4dce4a82q57c05ff3f41b5feb@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hardware@freebsd.org, freebsd-stable@freebsd.org, Ronald Klop Subject: Re: Multiple serial consoles via null modem cable X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 07:59:32 -0000 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 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. HTH... > On Sun, Jan 17, 2010 at 3:32 PM, Ronald Klop wrote: > > > On Fri, 15 Jan 2010 07:34:17 +0100, Marin Atanasov > > 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 wrote: > >> > >> On Tue, 12 Jan 2010 17:14:44 +0200 Marin Atanasov wrote: > >>> > >>> > I'm thinking about the following situation - 1 system acting like a > >>> host > >>> > with a serial port hub, each port of the hub is connected to a > >>> different > >>> > machine on sio0, using null modem cables. > >>> > >>> Along with milti-io serial cards we use multi-usb serial > >>> converters, such as SUNIX UTS7009P (7 USB to serial adapter): > >>> http://www.sunix.com.tw/it/en/LinkCraft/UTS4009P_UTS7009P.htm -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hardware@FreeBSD.ORG Wed Jan 20 09:31:03 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE7F9106568D for ; Wed, 20 Jan 2010 09:31:03 +0000 (UTC) (envelope-from stephane.lapie@darkbsd.org) Received: from quasar.darkbsd.org (shinigami.darkbsd.org [82.227.96.182]) by mx1.freebsd.org (Postfix) with ESMTP id A62C28FC12 for ; Wed, 20 Jan 2010 09:31:03 +0000 (UTC) Received: from quasar.darkbsd.org (localhost [127.0.0.1]) by quasar.darkbsd.org (Postfix) with ESMTP id 8FB9016EA for ; Wed, 20 Jan 2010 10:30:56 +0100 (CET) Received: from quasar.darkbsd.org ([127.0.0.1]) by quasar.darkbsd.org (quasar.darkbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZLOxBuOPmWE for ; Wed, 20 Jan 2010 10:30:54 +0100 (CET) Received: from [192.168.166.29] (unknown [210.188.173.245]) (Authenticated sender: darksoul) by quasar.darkbsd.org (Postfix) with ESMTPSA id 9362F16E3 for ; Wed, 20 Jan 2010 10:30:53 +0100 (CET) Message-ID: <4B56CD4C.80503@darkbsd.org> Date: Wed, 20 Jan 2010 18:30:52 +0900 From: Stephane LAPIE User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-hardware@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE7F1DEF35E2B614F39635BA7" Subject: DELL SAS5/E Controller bug X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 09:31:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE7F1DEF35E2B614F39635BA7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello list, Basically I'm experiencing the same problem as described here : https://forums.freebsd.org/showthread.php?t=3D9407 (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 : mpt0@pci0:6:8:0: class=3D0x010000 card=3D0x1f041028 chip=3D0x00541000 rev= =3D0x01 hdr=3D0x00 vendor =3D 'LSI Logic (Was: Symbios Logic, NCR)' device =3D 'SAS 3000 series, 8-port with 1068 -StorPort' class =3D mass storage subclass =3D SCSI Did anyone else experience this, or find a proper work-around ? Thanks in advance for your time, --=20 Stephane LAPIE, EPITA SRS, Promo 2005 "Even when they have digital readouts, I can't understand them." --MegaTokyo --------------enigE7F1DEF35E2B614F39635BA7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktWzU0ACgkQ24Ql8u6TF2PHOwCg72hxd9fwISEgt4OAVTbRiBuS FTwAoJuIQL3kYlmtXN48swDcHulk8YDK =7jM8 -----END PGP SIGNATURE----- --------------enigE7F1DEF35E2B614F39635BA7-- From owner-freebsd-hardware@FreeBSD.ORG Wed Jan 20 13:53:23 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48D7E106566B for ; Wed, 20 Jan 2010 13:53:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1CF988FC14 for ; Wed, 20 Jan 2010 13:53:23 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A948F46B09; Wed, 20 Jan 2010 08:53:22 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id E01078A027; Wed, 20 Jan 2010 08:53:21 -0500 (EST) From: John Baldwin To: freebsd-hardware@freebsd.org Date: Wed, 20 Jan 2010 08:48:16 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091231; KDE/4.3.1; amd64; ; ) References: <4B56CD4C.80503@darkbsd.org> In-Reply-To: <4B56CD4C.80503@darkbsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201001200848.16874.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 20 Jan 2010 08:53:21 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Stephane LAPIE Subject: Re: DELL SAS5/E Controller bug X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 13:53:23 -0000 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 : > mpt0@pci0:6:8:0: class=0x010000 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. -- John Baldwin From owner-freebsd-hardware@FreeBSD.ORG Wed Jan 20 15:09:52 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2732106566B for ; Wed, 20 Jan 2010 15:09:52 +0000 (UTC) (envelope-from stephane.lapie@darkbsd.org) Received: from quasar.darkbsd.org (shinigami.darkbsd.org [82.227.96.182]) by mx1.freebsd.org (Postfix) with ESMTP id D7DBA8FC14 for ; Wed, 20 Jan 2010 15:09:51 +0000 (UTC) Received: from quasar.darkbsd.org (localhost [127.0.0.1]) by quasar.darkbsd.org (Postfix) with ESMTP id 0EB581850; Wed, 20 Jan 2010 16:09:45 +0100 (CET) Received: from quasar.darkbsd.org ([127.0.0.1]) by quasar.darkbsd.org (quasar.darkbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuLw14MmONn3; Wed, 20 Jan 2010 16:09:42 +0100 (CET) Received: from [192.168.3.42] (fnttkyo035000.tkyo.fnt.ftth.ppp.infoweb.ne.jp [58.1.242.192]) (Authenticated sender: darksoul) by quasar.darkbsd.org (Postfix) with ESMTPSA id C888A1849; Wed, 20 Jan 2010 16:09:40 +0100 (CET) Message-ID: <4B571CB7.3020303@darkbsd.org> Date: Thu, 21 Jan 2010 00:09:43 +0900 From: Stephane LAPIE User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: John Baldwin References: <4B56CD4C.80503@darkbsd.org> <201001200848.16874.jhb@freebsd.org> In-Reply-To: <201001200848.16874.jhb@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD79D541B2329094271CEA7B1" Cc: freebsd-hardware@freebsd.org Subject: Re: DELL SAS5/E Controller bug X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 15:09:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD79D541B2329094271CEA7B1 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable 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=3D9407 (linking for refere= nce) >> >> 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 unt= il >> 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 : >> mpt0@pci0:6:8:0: class=3D0x010000 card=3D0x1f041028 chip=3D0x00541000 = rev=3D0x01 >> hdr=3D0x00 >> vendor =3D 'LSI Logic (Was: Symbios Logic, NCR)' >> device =3D 'SAS 3000 series, 8-port with 1068 -StorPort' >> class =3D mass storage >> subclass =3D SCSI >> >> Did anyone else experience this, or find a proper work-around ? >=20 > Invoke 'camcontrol rescan' after removing a drive. mptutil(8) does the= =20 > equivalent when adding and removing volumes to make up for the driver n= ot=20 > 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=20 in a "cbwait" state, it can't be bg'ed). I did not wait for a hardware=20 timeout, I tried replugging the drive, which released the ZFS and=20 camcontrol locks. Also, I tried poking around with mptutil and could obtain the following=20 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=20 controller, though a bit jarring) freebsd-r610# mptutil -u 1 show adapter mpt1 Adapter: Board Name: SAS6IR Board Assembly: Chip Name: C1068E Chip Revision: UNUSED RAID Levels: RAID0, RAID1, RAID1E RAID0 Stripes: 64K RAID1E Stripes: 64K RAID0 Drives/Vol: 2-10 RAID1 Drives/Vol: 2 RAID1E Drives/Vol: 3-10 However, the following is a bit disturbing : freebsd-r610# mptutil -u 0 show drives mpt0 Physical Drives: da0 ( 932G) ONLINE SAS bus 0 id 0 da1 ( 932G) ONLINE SAS bus 0 id 1 da2 ( 932G) ONLINE SAS bus 0 id 2 da3 ( 932G) ONLINE SAS bus 0 id 3 da4 ( 932G) ONLINE SAS bus 0 id 4 da5 ( 932G) ONLINE SAS bus 0 id 5 da6 ( 932G) ONLINE SAS bus 0 id 6 da7 ( 932G) ONLINE SAS bus 0 id 7 da8 ( 932G) ONLINE SAS bus 0 id 8 da9 ( 932G) ONLINE SAS bus 0 id 9 da10 ( 932G) ONLINE SAS bus 0 id 10 da11 ( 932G) ONLINE SAS bus 0 id 11 da12 ( 932G) ONLINE SAS bus 0 id 12 da13 ( 932G) ONLINE SAS bus 0 id 13 da14 ( 932G) ONLINE SAS bus 0 id 14 da15 ( 136G) ONLINE SAS bus 0 id 0 The above listing seems weird, as da15 should belong to mpt1. freebsd-r610# mptutil -u 1 show drives mptutil: mpt_fetch_disks got wrong CAM matches mpt1 Physical Drives: 0 ( 137G) ONLINE SAS bus 0 id 1 1 ( 137G) ONLINE SAS bus 0 id 9 Also, checking the device list with camcontrol shows a different output := freebsd-r610# camcontrol devlist -v scbus0 on mpt0 bus 0: at scbus0 target 0 lun 0 (pass0,da0) at scbus0 target 1 lun 0 (pass1,da1) at scbus0 target 2 lun 0 (pass2,da2) at scbus0 target 3 lun 0 (pass3,da3) at scbus0 target 4 lun 0 (pass4,da4) at scbus0 target 5 lun 0 (pass5,da5) at scbus0 target 6 lun 0 (pass6,da6) at scbus0 target 7 lun 0 (pass7,da7) at scbus0 target 8 lun 0 (pass8,da8) at scbus0 target 9 lun 0 (pass9,da9) at scbus0 target 10 lun 0 (pass10,da10= ) at scbus0 target 11 lun 0 (pass11,da11= ) at scbus0 target 12 lun 0 (pass12,da12= ) at scbus0 target 13 lun 0 (pass13,da13= ) at scbus0 target 14 lun 0 (pass14,da14= ) at scbus0 target 15 lun 0 (ses0,pass15= ) <> at scbus0 target -1 lun -1 () scbus1 on mpt1 bus 0: at scbus1 target 0 lun 0 (pass16,da15)= at scbus1 target 8 lun 0 (ses1,pass17)= <> at scbus1 target -1 lun -1 () scbus-1 on xpt0 bus 0: <> at scbus-1 target -1 lun -1 (xpt0) I tried to offline/online a drive as per the manual example, but with no = success : freebsd-r610# mptutil offline 0:1 mptutil: Failed to find drive 0:1: No such file or directory freebsd-r610# mptutil offline 0:15 mptutil: Failed to find drive 0:15: No such file or directory See below for the full dmesg output : Copyright (c) 1992-2009 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 8.0-RELEASE-AZB #1: Mon Dec 28 16:42:58 UTC 2009 root@freebsd-amd64.buildmaster.aozora.lan:/usr/obj/usr/src/sys/GENER= IC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU X5550 @ 2.67GHz (2660.01-MHz=20 K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x106a5 Stepping =3D 5 =20 Features=3D0xbfebfbff =20 Features2=3D0x9ce3bd AMD Features=3D0x28100800 AMD Features2=3D0x1 TSC: P-state invariant real memory =3D 4294967296 (4096 MB) avail memory =3D 4097736704 (3907 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu2 (AP): APIC ID: 18 cpu3 (AP): APIC ID: 19 cpu4 (AP): APIC ID: 20 cpu5 (AP): APIC ID: 21 cpu6 (AP): APIC ID: 22 cpu7 (AP): APIC ID: 23 ioapic1: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on=20 acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 bce0: mem=20 0xd6000000-0xd7ffffff irq 36 at device 0.0 on pci1 miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,=20 1000baseT-FDX, auto bce0: Ethernet address: 00:22:19:66:1e:da bce0: [ITHREAD] bce0: ASIC (0x57092003); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.0.6);=20 Flags (MSI|MFW); MFW (NCSI 2.0.3) bce1: mem=20 0xd8000000-0xd9ffffff irq 48 at device 0.1 on pci1 miibus1: on bce1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,=20 1000baseT-FDX, auto bce1: Ethernet address: 00:22:19:66:1e:dc bce1: [ITHREAD] bce1: ASIC (0x57092003); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.0.6);=20 Flags (MSI|MFW); MFW (NCSI 2.0.3) pcib2: at device 3.0 on pci0 pci2: on pcib2 bce2: mem=20 0xda000000-0xdbffffff irq 32 at device 0.0 on pci2 miibus2: on bce2 brgphy2: PHY 1 on miibus2 brgphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,=20 1000baseT-FDX, auto bce2: Ethernet address: 00:22:19:66:1e:de bce2: [ITHREAD] bce2: ASIC (0x57092003); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.0.6);=20 Flags (MSI|MFW); MFW (NCSI 2.0.3) bce3: mem=20 0xdc000000-0xddffffff irq 42 at device 0.1 on pci2 miibus3: on bce3 brgphy3: PHY 1 on miibus3 brgphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,=20 1000baseT-FDX, auto bce3: Ethernet address: 00:22:19:66:1e:e0 bce3: [ITHREAD] bce3: ASIC (0x57092003); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.0.6);=20 Flags (MSI|MFW); MFW (NCSI 2.0.3) pcib3: at device 7.0 on pci0 pci4: on pcib3 pcib4: at device 9.0 on pci0 pci5: on pcib4 pcib5: at device 0.0 on pci5 pci6: on pcib5 mpt0: port 0xec00-0xecff mem=20 0xdf2ec000-0xdf2effff,0xdf2f0000-0xdf2fffff irq 40 at device 8.0 on pci6 mpt0: [ITHREAD] mpt0: MPI Version=3D1.5.13.0 pci0: at device 20.0 (no driver=20 attached) pci0: at device 20.1 (no driver=20 attached) pci0: at device 20.2 (no driver=20 attached) uhci0: port 0xdc40-0xdc5f irq 17 at = device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup =3D 0x003b usbus0: on uhci0 uhci1: port 0xdc60-0xdc7f irq 18 at = device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup =3D 0x003b usbus1: on uhci1 ehci0: mem=20 0xdf0ff800-0xdf0ffbff irq 19 at device 26.7 on pci0 ehci0: [ITHREAD] usbus2: waiting for BIOS to give up control usbus2: EHCI version 1.0 usbus2: on ehci0 pcib6: at device 28.0 on pci0 pci3: on pcib6 mpt1: port 0xfc00-0xfcff mem=20 0xdf4ec000-0xdf4effff,0xdf4f0000-0xdf4fffff irq 16 at device 0.0 on pci3 mpt1: [ITHREAD] mpt1: MPI Version=3D1.5.18.0 mpt1: mpt_wait_req(6) timed out mpt1: port 0 enable timed out mpt1: failed to enable port 0 mpt1: unable to initialize IOC uhci2: port 0xdc80-0xdc9f irq 21 at = device 29.0 on pci0 uhci2: [ITHREAD] uhci2: LegSup =3D 0x0000 usbus3: on uhci2 uhci3: port 0xdca0-0xdcbf irq 20 at = device 29.1 on pci0 uhci3: [ITHREAD] uhci3: LegSup =3D 0x0000 usbus4: on uhci3 ehci1: mem=20 0xdf0ffc00-0xdf0fffff irq 21 at device 29.7 on pci0 ehci1: [ITHREAD] usbus5: EHCI version 1.0 usbus5: on ehci1 pcib7: at device 30.0 on pci0 pci7: on pcib7 vgapci0: mem=20 0xd5800000-0xd5ffffff,0xde7fc000-0xde7fffff,0xde800000-0xdeffffff irq 19 = at device 3.0 on pci7 isab0: at device 31.0 on pci0 isa0: on isab0 atrtc0: port 0x70-0x7f irq 8 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 15 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 15 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 15 device_attach: est2 attach returned 6 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 15 device_attach: est3 attach returned 6 p4tcc3: on cpu3 cpu4: on acpi0 est4: on cpu4 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 15 device_attach: est4 attach returned 6 p4tcc4: on cpu4 cpu5: on acpi0 est5: on cpu5 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 15 device_attach: est5 attach returned 6 p4tcc5: on cpu5 cpu6: on acpi0 est6: on cpu6 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 15 device_attach: est6 attach returned 6 p4tcc6: on cpu6 cpu7: on acpi0 est7: on cpu7 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 15 device_attach: est7 attach returned 6 p4tcc7: on cpu7 orm0: at iomem=20 0xc0000-0xc7fff,0xce000-0xcefff,0xec000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0= atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range Timecounters tick every 1.000 msec mpt0: mpt_cam_event: 0x16 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub2: 4 ports with 4 removable, self powered uhub5: 4 ports with 4 removable, self powered ugen2.2: at usbus2 uhub6: =20 on usbus2 uhub6: 3 ports with 3 removable, self powered ugen2.3: at usbus2 uhub7: on usbus2 ugen3.2: at usbus3 ukbd0: on usbus3 kbd2 at ukbd0 ums0: on usbus3 ums0: 3 buttons and [Z] coordinates ID=3D0 da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da1 at mpt0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 300.000MB/s transfers da1: Command Queueing enabled da1: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da2 at mpt0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-5 device da2: 300.000MB/s transfers da2: Command Queueing enabled da2: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da3 at mpt0 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-5 device da3: 300.000MB/s transfers da3: Command Queueing enabled da3: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da4 at mpt0 bus 0 target 4 lun 0 da4: Fixed Direct Access SCSI-5 device da4: 300.000MB/s transfers da4: Command Queueing enabled da4: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da5 at mpt0 bus 0 target 5 lun 0 da5: Fixed Direct Access SCSI-5 device da5: 300.000MB/s transfers da5: Command Queueing enabled da5: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da7 at mpt0 bus 0 target 7 lun 0 da7: Fixed Direct Access SCSI-5 device da7: 300.000MB/s transfers da7: Command Queueing enabled da7: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da8 at mpt0 bus 0 target 8 lun 0 da8: Fixed Direct Access SCSI-5 device da8: 300.000MB/s transfers da8: Command Queueing enabled da8: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da9 at mpt0 bus 0 target 9 lun 0 da9: Fixed Direct Access SCSI-5 device da9: 300.000MB/s transfers da9: Command Queueing enabled da9: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da6 at mpt0 bus 0 target 6 lun 0 da6: Fixed Direct Access SCSI-5 device da6: 300.000MB/s transfers da6: Command Queueing enabled da6: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da10 at mpt0 bus 0 target 10 lun 0 da10: Fixed Direct Access SCSI-5 device da10: 300.000MB/s transfers da10: Command Queueing enabled da10: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da11 at mpt0 bus 0 target 11 lun 0 da11: Fixed Direct Access SCSI-5 device da11: 300.000MB/s transfers da11: Command Queueing enabled da11: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da12 at mpt0 bus 0 target 12 lun 0 da12: Fixed Direct Access SCSI-5 device da12: 300.000MB/s transfers da12: Command Queueing enabled da12: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da13 at mpt0 bus 0 target 13 lun 0 da13: Fixed Direct Access SCSI-5 device da13: 300.000MB/s transfers da13: Command Queueing enabled da13: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da14 at mpt0 bus 0 target 14 lun 0 da14: Fixed Direct Access SCSI-5 device da14: 300.000MB/s transfers da14: Command Queueing enabled da14: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da15 at mpt1 bus 0 target 0 lun 0 da15: Fixed Direct Access SCSI-5 device da15: 300.000MB/s transfers da15: Command Queueing enabled da15: 139392MB (285474816 512 byte sectors: 255H 63S/T 17769C) ses0 at mpt0 bus 0 target 15 lun 0 ses0: Fixed Enclosure Services SCSI-5 device ses0: 300.000MB/s transfers ses0: Command Queueing enabled ses0: SCSI-3 SES Device ses1 at mpt1 bus 0 target 8 lun 0 ses1: Fixed Enclosure Services SCSI-5 device ses1: 300.000MB/s transfers ses1: SCSI-3 SES Device SMP: AP CPU #1 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #6 Launched! uhub7: 3 ports with 2 removable, bus powered ugen2.4: at usbus2 ukbd1: on usbus2 kbd3 at ukbd1 uhid0: on usbus2 GEOM: da15: the secondary GPT table is corrupt or invalid. GEOM: da15: using the primary only -- recovery suggested. Trying to mount root from ufs:/dev/label/system0p2 bce0: link state changed to UP ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is=20 present; to enable, add "vfs.zfs.prefetch_disable=3D0" to=20 /boot/loader.conf. ZFS filesystem version 13 ZFS storage pool version 13 --=20 Stephane LAPIE, EPITA SRS, Promo 2005 "Even when they have digital readouts, I can't understand them." --MegaTokyo --------------enigD79D541B2329094271CEA7B1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktXHLcACgkQ24Ql8u6TF2MNGgCfW4C9sKSeZ2MwwuWIsKnGimE8 xuAAoKFw6zb49qfNkTzttGQ9EShHsitr =Dpl4 -----END PGP SIGNATURE----- --------------enigD79D541B2329094271CEA7B1-- From owner-freebsd-hardware@FreeBSD.ORG Wed Jan 20 16:05:47 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E24DD106566B for ; Wed, 20 Jan 2010 16:05:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A3ADF8FC16 for ; Wed, 20 Jan 2010 16:05:47 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 28A0246B35; Wed, 20 Jan 2010 11:05:47 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 3B9808A025; Wed, 20 Jan 2010 11:05:46 -0500 (EST) From: John Baldwin To: Stephane LAPIE Date: Wed, 20 Jan 2010 11:05:26 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091231; KDE/4.3.1; amd64; ; ) References: <4B56CD4C.80503@darkbsd.org> <201001200848.16874.jhb@freebsd.org> <4B571CB7.3020303@darkbsd.org> In-Reply-To: <4B571CB7.3020303@darkbsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201001201105.26367.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 20 Jan 2010 11:05:46 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hardware@freebsd.org Subject: Re: DELL SAS5/E Controller bug X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 16:05:48 -0000 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 : > >> mpt0@pci0:6:8:0: class=0x010000 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 SAS bus 0 id 0 > da1 ( 932G) ONLINE SAS bus 0 id 1 > da2 ( 932G) ONLINE SAS bus 0 id 2 > da3 ( 932G) ONLINE SAS bus 0 id 3 > da4 ( 932G) ONLINE SAS bus 0 id 4 > da5 ( 932G) ONLINE SAS bus 0 id 5 > da6 ( 932G) ONLINE SAS bus 0 id 6 > da7 ( 932G) ONLINE SAS bus 0 id 7 > da8 ( 932G) ONLINE SAS bus 0 id 8 > da9 ( 932G) ONLINE SAS bus 0 id 9 > da10 ( 932G) ONLINE SAS bus 0 id 10 > da11 ( 932G) ONLINE SAS bus 0 id 11 > da12 ( 932G) ONLINE SAS bus 0 id 12 > da13 ( 932G) ONLINE SAS bus 0 id 13 > da14 ( 932G) ONLINE SAS bus 0 id 14 > da15 ( 136G) ONLINE 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 this I used gdb and set a breakpoint in mpt_fetch_disks() so I could examine the structures that CAM returned. This is the code that identifies mptX vs mpt: /* Match mptX bus 0. */ ccb.cdm.patterns[0].type = DEV_MATCH_BUS; b = &ccb.cdm.patterns[0].pattern.bus_pattern; snprintf(b->dev_name, sizeof(b->dev_name), "mpt"); b->unit_number = mpt_unit; b->bus_id = 0; b->flags = BUS_MATCH_NAME | BUS_MATCH_UNIT | BUS_MATCH_BUS_ID; 'mpt_unit' is a global variable that is set to the value of the 'u' parameter. > freebsd-r610# mptutil -u 1 show drives > mptutil: mpt_fetch_disks got wrong CAM matches > mpt1 Physical Drives: > 0 ( 137G) ONLINE SAS bus 0 id 1 > 1 ( 137G) ONLINE SAS bus 0 id 9 Similarly I would use gdb to exmaine the reply from CAM here to see why it got 'wrong CAM matches'. The code expects the first match to match the bus and the next N matches should be 'daX' devices. -- John Baldwin From owner-freebsd-hardware@FreeBSD.ORG Thu Jan 21 00:28:21 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 923F61065670 for ; Thu, 21 Jan 2010 00:28:21 +0000 (UTC) (envelope-from compcent@mail.com) Received: from imr-ma01.mx.aol.com (imr-ma01.mx.aol.com [64.12.206.39]) by mx1.freebsd.org (Postfix) with ESMTP id 44BAC8FC0C for ; Thu, 21 Jan 2010 00:28:20 +0000 (UTC) Received: from imo-da01.mx.aol.com (imo-da01.mx.aol.com [205.188.169.199]) by imr-ma01.mx.aol.com (8.14.1/8.14.1) with ESMTP id o0L0I59n008267 for ; Wed, 20 Jan 2010 19:18:05 -0500 Received: from compcent@mail.com by imo-da01.mx.aol.com (mail_out_v42.5.) id n.cb6.625bac76 (37132); Wed, 20 Jan 2010 19:18:02 -0500 (EST) Received: from smtprly-de02.mx.aol.com (smtprly-de02.mx.aol.com [205.188.249.169]) by cia-ma02.mx.aol.com (v127.7) with ESMTP id MAILCIAMA026-b2364b579d2d192; Wed, 20 Jan 2010 19:17:59 -0500 Received: from web-mmc-m01 (web-mmc-m01.sim.aol.com [64.12.224.134]) by smtprly-de02.mx.aol.com (v127.7) with ESMTP id MAILSMTPRLYDE023-b2364b579d2d192; Wed, 20 Jan 2010 19:17:49 -0500 To: compcent@mail.com, freebsd-hardware@freebsd.org Date: Wed, 20 Jan 2010 19:17:48 -0500 X-MB-Message-Source: WebUI X-AOL-IP: 12.33.10.185 X-MB-Message-Type: User MIME-Version: 1.0 From: compcent@mail.com X-Mailer: Mail.com Webmail 30462-STANDARD Received: from 12.33.10.185 by web-mmc-m01.sysops.aol.com (64.12.224.134) with HTTP (WebMailUI); Wed, 20 Jan 2010 19:17:48 -0500 Message-Id: <8CC68464C10140C-1424-5F3F@web-mmc-m01.sysops.aol.com> X-Spam-Flag: NO X-AOL-SENDER: compcent@mail.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: I would like to buy a Hewlett-Packard laptop (with Intel CPU) with BSD as an OS; AND... X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 00:28:21 -0000 Hello FreeBSD Hardware -=20 I would like to buy a Hewlett-Packard laptop (with Intel CPU) with BSD as= an OS; AND that is compatible=20 with a Verizon Air Card (USB port) for internet access. =20 Several years ago, I tried to install FreeBSD from downloaded discs onto= a PC. Later, I bought=20 the FreeBSD 5.2.1 ? software, and tried to load in on a PC. It booted, bu= t didn't work. =20 Best Buy=E2=80=99s =E2=80=9CGeek Squad=E2=80=9D doesn't want to get involv= ed with a FreeBSD install. I will call Fry's. =20 1. If anyone is using FreeBSD on a HP / Intel laptop, what is the Model= No. of your HP laptop, and what version of BSD are you using? I would= hope that there is a newer model that is still for sale. =20 2. Better yet, - Who can configure an HP / Intel laptop w/ BSD for sale?= ( further discussion required... ) =20 Would consider used / refurbished if dependable & the price is right.= =20 - Compatible with Verizon Air Card preferred / required; AND needs Wi-Fi= =20 - Prefer DVD player / CD-ROM burner=20 - A couple of USB ports=20 - Simple desktop / simple text menu ok=20 - Web browser, prefer Opera=20 - Word processor - prefer WordPerfect - 5.1 compatible , and/or newer WP;= =20 or, a BSD word processor with macros // Open Office as last resort = =20 - GIMP for graphics, works for me=20 - Optional - HTML Web editor - shareware or inexpensive=20 - A (non-MS) DOS partition on the hard drive - optional=20 - Restore / start-up disc, and an image-shot of the hard drive =20 - Program to read / make .pdf files - (One poster suggested alternative= to Adobe...??) =20 - Basic speaker=20 - Best virus / maleware protection (suggestions) =20 - Laptop Owner's manual - optional=20 FYI - I live in Sacramento, CA USA area. I expect to be in San Francisco,= - this Saturday, Jan 23, 2010. =20 Are there any good BSD techs / computer shops in the Sacramento area; or= in the SF Bay area? =20 ** Thanks for any suggestions / info! =20 compcent@mail.com =3D =3D =3D =3D =20 =3D From owner-freebsd-hardware@FreeBSD.ORG Thu Jan 21 07:22:00 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23FE11065679; Thu, 21 Jan 2010 07:22:00 +0000 (UTC) (envelope-from stephane.lapie@darkbsd.org) Received: from quasar.darkbsd.org (shinigami.darkbsd.org [82.227.96.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8432D8FC17; Thu, 21 Jan 2010 07:21:59 +0000 (UTC) Received: from quasar.darkbsd.org (localhost [127.0.0.1]) by quasar.darkbsd.org (Postfix) with ESMTP id D0ADA1D02; Thu, 21 Jan 2010 08:21:52 +0100 (CET) Received: from quasar.darkbsd.org ([127.0.0.1]) by quasar.darkbsd.org (quasar.darkbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXwsPjhsMKPt; Thu, 21 Jan 2010 08:21:50 +0100 (CET) Received: from [192.168.166.29] (unknown [210.188.173.245]) (Authenticated sender: darksoul) by quasar.darkbsd.org (Postfix) with ESMTPSA id 00AC71CFB; Thu, 21 Jan 2010 08:21:48 +0100 (CET) Message-ID: <4B58008C.4050207@darkbsd.org> Date: Thu, 21 Jan 2010 16:21:48 +0900 From: Stephane LAPIE User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: John Baldwin References: <4B56CD4C.80503@darkbsd.org> <201001200848.16874.jhb@freebsd.org> <4B571CB7.3020303@darkbsd.org> <201001201105.26367.jhb@freebsd.org> In-Reply-To: <201001201105.26367.jhb@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig13C762675B37AB0B44CDB19F" Cc: freebsd-hardware@freebsd.org Subject: Re: DELL SAS5/E Controller bug X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 07:22:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig13C762675B37AB0B44CDB19F Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable 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=3D9407 (linking for refe= rence) >>>> >>>> Drives disconnections are not recognized instantly, and instead I ge= t >>>> 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 u= ntil >>>> 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 : >>>> mpt0@pci0:6:8:0: class=3D0x010000 card=3D0x1f041028 chip=3D0x0054100= 0 rev=3D0x01 >>>> hdr=3D0x00 >>>> vendor =3D 'LSI Logic (Was: Symbios Logic, NCR)' >>>> device =3D 'SAS 3000 series, 8-port with 1068 -StorPort' >>>> class =3D mass storage >>>> subclass =3D SCSI >>>> >>>> Did anyone else experience this, or find a proper work-around ? >>> Invoke 'camcontrol rescan' after removing a drive. mptutil(8) does t= he=20 >>> equivalent when adding and removing volumes to make up for the driver= not=20 >>> automatically rescanning. >> I already tried reset/rescan via camcontrol, but after removing a driv= e,=20 >> the process freezes (process status "D", Ctrl+T in terminal shows it's= =20 >> in a "cbwait" state, it can't be bg'ed). I did not wait for a hardware= =20 >> timeout, I tried replugging the drive, which released the ZFS and=20 >> camcontrol locks. >> >> >> Also, I tried poking around with mptutil and could obtain the followin= g=20 >> 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=20 >> controller, though a bit jarring) >=20 > This patch should fix that: >=20 > Index: mpt_show.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- 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; > =20 > if (ac !=3D 1) { > @@ -108,7 +109,7 @@ > =20 > free(man0); > =20 > - ioc2 =3D mpt_read_ioc_page(fd, 2, NULL); > + ioc2 =3D mpt_read_ioc_page(fd, 2, &IOCStatus); > if (ioc2 !=3D NULL) { > printf(" RAID Levels:"); > comma =3D 0; > @@ -151,9 +152,10 @@ > printf(" none"); > printf("\n"); > free(ioc2); > - } > + } else if (IOCStatus !=3D MPI_IOCSTATUS_CONFIG_INVALID_PAGE) > + warnx("mpt_read_ioc_page(2): %s", mpt_ioc_status(IOCStatus)); > =20 > - ioc6 =3D mpt_read_ioc_page(fd, 6, NULL); > + ioc6 =3D mpt_read_ioc_page(fd, 6, &IOCStatus); > if (ioc6 !=3D NULL) { > display_stripe_map(" RAID0 Stripes", > ioc6->SupportedStripeSizeMapIS); > @@ -172,7 +174,8 @@ > printf("-%u", ioc6->MaxDrivesIME); > printf("\n"); > free(ioc6); > - } > + } else if (IOCStatus !=3D MPI_IOCSTATUS_CONFIG_INVALID_PAGE) > + warnx("mpt_read_ioc_page(2): %s", mpt_ioc_status(IOCStatus)); > =20 > /* TODO: Add an ioctl to fetch IOC_FACTS and print firmware version. = */ > =20 >=20 >> However, the following is a bit disturbing : >> >> freebsd-r610# mptutil -u 0 show drives >> mpt0 Physical Drives: >> da0 ( 932G) ONLINE SAS bus 0 id 0 >> da1 ( 932G) ONLINE SAS bus 0 id 1 >> da2 ( 932G) ONLINE SAS bus 0 id 2 >> da3 ( 932G) ONLINE SAS bus 0 id 3 >> da4 ( 932G) ONLINE SAS bus 0 id 4 >> da5 ( 932G) ONLINE SAS bus 0 id 5 >> da6 ( 932G) ONLINE SAS bus 0 id 6 >> da7 ( 932G) ONLINE SAS bus 0 id 7 >> da8 ( 932G) ONLINE SAS bus 0 id 8 >> da9 ( 932G) ONLINE SAS bus 0 id 9 >> da10 ( 932G) ONLINE SAS bus 0 id 10 >> da11 ( 932G) ONLINE SAS bus 0 id 11 >> da12 ( 932G) ONLINE SAS bus 0 id 12 >> da13 ( 932G) ONLINE SAS bus 0 id 13 >> da14 ( 932G) ONLINE SAS bus 0 id 14 >> da15 ( 136G) ONLINE SAS bus 0 id 0 >> >> The above listing seems weird, as da15 should belong to mpt1. >=20 > Agreed. I specifically ask that CAM only return results for devices on= bus 0 > of mptX. Before when I debugged this I used gdb and set a breakpoint i= n > mpt_fetch_disks() so I could examine the structures that CAM returned. = This > is the code that identifies mptX vs mpt: >=20 > /* Match mptX bus 0. */ > ccb.cdm.patterns[0].type =3D DEV_MATCH_BUS; > b =3D &ccb.cdm.patterns[0].pattern.bus_pattern; > snprintf(b->dev_name, sizeof(b->dev_name), "mpt"); > b->unit_number =3D mpt_unit; > b->bus_id =3D 0; > b->flags =3D BUS_MATCH_NAME | BUS_MATCH_UNIT | BUS_MATCH_BUS_ID; >=20 > 'mpt_unit' is a global variable that is set to the value of the 'u' > parameter. >=20 >> freebsd-r610# mptutil -u 1 show drives >> mptutil: mpt_fetch_disks got wrong CAM matches >> mpt1 Physical Drives: >> 0 ( 137G) ONLINE SAS bus 0 id 1 >> 1 ( 137G) ONLINE SAS bus 0 id 9 >=20 > Similarly I would use gdb to exmaine the reply from CAM here to see why= > it got 'wrong CAM matches'. The code expects the first match to match > the bus and the next N matches should be 'daX' devices. >=20 I just applied your patch to mptutil source, which now returns : freebsd-r610# mptutil show adapter mpt0 Adapter: Board Name: SAS5e Board Assembly: Chip Name: C1068 Chip Revision: UNUSED RAID Levels: none mptutil: mpt_read_ioc_page(2): Invalid configuration page I will give a try on the gdb thing once I get a chance of installing the source tree on this test machine. Also, I pasted the dmesg trace of trying to remove da0 and da6 and trying to have the system register the removal via a "camcontrol rescan 0= " : -> Unplugging "da0" and "da6" : mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 -> Then running "camcontrol rescan 0" (which leaves "cbwait" state and finishes at 187s real time) mpt0: request 0xffffff80005bcea0:5936 timed out for ccb 0xffffff00032d4000 (req->ccb 0xffffff00032d4000) mpt0: attempting to abort req 0xffffff80005bcea0:5936 function 0 mpt0: mpt_wait_req(1) timed out mpt0: mpt_recover_commands: abort timed-out. Resetting controller mpt0: mpt_cam_event: 0x0 mpt0: completing timedout/aborted req 0xffffff80005bcea0:5936 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 (da0:mpt0:0:0:0): lost device (da0:mpt0:0:0:0): Synchronize cache failed, status =3D=3D 0x4a, scsi stat= us =3D=3D 0x0 (da0:mpt0:0:0:0): removing device entry (da6:mpt0:0:6:0): lost device (da6:mpt0:0:6:0): Synchronize cache failed, status =3D=3D 0x4a, scsi stat= us =3D=3D 0x0 (da6:mpt0:0:6:0): removing device entry -> Then replugging the drive "da0" : mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 -> Then running "camcontrol rescan 0" (which responds in a few seconds time, between 7~10s) : da0 at mpt0 bus 0 target 6 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) -> Then replugging the drive "da6" : mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 -> Then running "camcontrol rescan 0" (which responds in a few seconds time, between 7~10s) : da6 at mpt0 bus 0 target 6 lun 0 da6: Fixed Direct Access SCSI-5 device da6: 300.000MB/s transfers da6: Command Queueing enabled da6: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) Is there any documentation or hint as to what those mpt_cam_event are ? I could whip myself a quick patch to at least change the display so one would figure what these are. It feels like the 0x12 and 0x16 have to be handled to invalidate the device that has been unplugged so the next request won't timeout but fail directly. This is actually not as crippling as I initially thought for use with ZFS, but waiting 190s (3x60s timeouts + normal execution of camcontrol ?) sounds a bit overboard. On a separate note (and this is not a real problem), my test case of plugging out two drives from a 2xraidz1 pool made me notice a little quirk that has the system reusing the first free daX slot upon replugging a drive and thus getting another device name. I guess that could probably be worked around with either of the two methods : - Binding bus:target:lun to a fixed daX number - zpool export/importing the pool upon disk failure (though this is a bit constraining) Thanks again for your time, --=20 Stephane LAPIE, EPITA SRS, Promo 2005 "Even when they have digital readouts, I can't understand them." --MegaTokyo --------------enig13C762675B37AB0B44CDB19F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktYAIwACgkQ24Ql8u6TF2NhwgCgm3LGsRSL47RB+2hNSPc0Y1nd ZKMAn3VTjkqyQFuB0WJ5AHnaPiHVwhl5 =Pr/d -----END PGP SIGNATURE----- --------------enig13C762675B37AB0B44CDB19F-- From owner-freebsd-hardware@FreeBSD.ORG Thu Jan 21 09:37:10 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FB44106566B; Thu, 21 Jan 2010 09:37:10 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 3C1838FC16; Thu, 21 Jan 2010 09:37:08 +0000 (UTC) Received: by ewy10 with SMTP id 10so672560ewy.34 for ; Thu, 21 Jan 2010 01:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=sqMIkumRMq9TlsPfLK2qQWp4vTtYohm6CdcFeeT/1X0=; b=pc/VYTpqAbnqSNzfQsOYiDz5G6VjIbdV2B9nPENmDqhxyK11T8VsKpmIiQ2Wu14bVs 58YsrvRnuXfCuJVNsKmCfq9LNdPGSdFYZy7k6o+f/mdcJgSZNgl6QnLfF+VXtsHAEVpI blqw7dnsskHj4jRV0EDgGgh1aZqVzqvOjKG4g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=l58jsdOKKqiVmKnsO5/lC9Pv5CkJtyFVtiZB0ZDdVX3qUOkpQ4WdQsHUGnDotEV9sS NcrPZldIgc0/OCsllsCM9NgSoSJ7f59rjGJYLz8hydzSqNPmrIxU9PLK3g9iZ1OCFcI4 TjamWMmzEmJk4cobopRSNjusITCNOnKDAMUBc= MIME-Version: 1.0 Received: by 10.216.87.79 with SMTP id x57mr439612wee.83.1264066626626; Thu, 21 Jan 2010 01:37:06 -0800 (PST) In-Reply-To: <20100120074611.GA405@icarus.home.lan> References: <717f7a3e1001120714m37aada69gfaa35f0f9b17f435@mail.gmail.com> <44678539@bb.ipt.ru> <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> <717f7a3e1001192246o4dce4a82q57c05ff3f41b5feb@mail.gmail.com> <20100120074611.GA405@icarus.home.lan> Date: Thu, 21 Jan 2010 11:37:06 +0200 Message-ID: <717f7a3e1001210137p7884adcbxc66a4f7fff928821@mail.gmail.com> From: Marin Atanasov To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hardware@freebsd.org, freebsd-stable@freebsd.org, Ronald Klop Subject: Re: Multiple serial consoles via null modem cable X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 09:37:10 -0000 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 wrote: > 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-freebsd8@klop.yi.org>wrote: > > > > > On Fri, 15 Jan 2010 07:34:17 +0100, Marin Atanasov > > > 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 wrote: > > >> > > >> On Tue, 12 Jan 2010 17:14:44 +0200 Marin Atanasov wrote: > > >>> > > >>> > I'm thinking about the following situation - 1 system acting like a > > >>> host > > >>> > with a serial port hub, each port of the hub is connected to a > > >>> different > > >>> > machine on sio0, using null modem cables. > > >>> > > >>> Along with milti-io serial cards we use multi-usb serial > > >>> converters, such as SUNIX UTS7009P (7 USB to serial adapter): > > >>> http://www.sunix.com.tw/it/en/LinkCraft/UTS4009P_UTS7009P.htm > > -- > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org From owner-freebsd-hardware@FreeBSD.ORG Thu Jan 21 11:44:23 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECB84106566B for ; Thu, 21 Jan 2010 11:44:22 +0000 (UTC) (envelope-from onitake@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 7DFF98FC19 for ; Thu, 21 Jan 2010 11:44:22 +0000 (UTC) Received: by fxm10 with SMTP id 10so3025459fxm.34 for ; Thu, 21 Jan 2010 03:44:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=t/FAeZ8niX7YLxg4B9vjSkmk4vTRCx/n5/+mWAwHVQM=; b=M6MRFK4YN5MAqZFgQPRrHt7B2gcffa894gUcyyL8+rborE13y+rQT7x2ZOt/ABftYh b4gHx6gPuG1Emxv0dOTU+PD+bU4s9W+H3SmCf9ggysP00Aj9/Uy9UnmhbkrVu4xHOCak sVujvI4u/rioBlTTch9pM9Kqu1AAz2qdJ9FP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=HBDNdYoIdjHNEI62TRTEdG2AdT9iLcMjB/VBOvGseyVafpkU/Q+OnvGIj59OPDVcMi te1iLZzLXP4d1sFiqHdQYaKD8mckE/GSngQ8QHJAiX6epzbhl6F9YVjELVNxGFu3tK/u IfpyH7EnNe6cuJNG/zO0OI4j1X9z3fHT6g1fU= Received: by 10.223.76.77 with SMTP id b13mr1278246fak.74.1264072691367; Thu, 21 Jan 2010 03:18:11 -0800 (PST) Received: from aki.gni.ch (aki.gni.ch [193.53.0.59]) by mx.google.com with ESMTPS id d13sm1173469fka.17.2010.01.21.03.18.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 21 Jan 2010 03:18:10 -0800 (PST) Message-ID: <4B5837F2.7060304@gmail.com> Date: Thu, 21 Jan 2010 12:18:10 +0100 From: onitake@gmail.com User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-hardware@freebsd.org X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Support for Atheros AR9220 X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 11:44:23 -0000 Hello list I got a miniPCI card with the 802.11n capable Atheros chipset AR9220 recently. The PCI ID is identical to the AR9280, which is already supported in FreeBSD. Unfortunately, the Atheros HAL doesn't work correctly with the card. Detection and basic communication is fine, but once I start setting up, the HAL reports errors. In hostap mode, I even experience kernel panics: ---- snip --- Configuring WLAN interface...wlan0: changing name to 'ath0_wlan0' ath0: unable to reset hardware; hal status 14 ath0: ath_chan_set: unable to reset channel 8 (2447 Mhz, flags 0x480), hal status 3 Fatal trap 12: page fault while in kernel mode fault virtual address = 0xe fault code = supervisor read, page not present instruction pointer = 0x20:0xc05bc2aa stack pointer = 0x28:0xc22bbbb4 frame pointer = 0x28:0xc22bbc18 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 = 11 (swi4: clock) [thread pid 11 tid 64005 ] Stopped at ar5416PerCalibrationN+0x2a: movzwl 0xe(%ecx),%edx db> bt Tracing pid 11 tid 64005 td 0xc2438900 ar5416PerCalibrationN(c2522000,0,1,1,c22bbc38,...) at ar5416PerCalibrationN+0x2a ath_detach(c2514000,1,c0cf3554,c251425c,6,...) at ath_detach+0x12f3 softclock(c0cf3520,0,109,c63d9d47,9,...) at softclock+0x1bc intr_event_execute_handlers(c2436aa0,c2434300,c0b5910d,4f6,c2434370,...) at intr_event_execute_handb intr_getaffinity(c24086b0,c22bbd38,0,0,0,...) at intr_getaffinity+0x14a fork_exit(c080dfe0,c24086b0,c22bbd38) at fork_exit+0x90 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc22bbd70, ebp = 0 --- ---- snip --- This occured with pfSense-BETA1 from Dec 31 (the kernel is FreeBSD 8-CURRENT). The system is a Alix 2d13 (http://www.pcengines.ch/alix2d13.htm) and the card a Wistron DNMA92 (http://www.pcengines.ch/dnma92.htm). I believe the topic has been brought up before, but I've been subscribed to the list for a short time only, so I can't respond to the original thread. According to this list, the Linux ath9k driver supports the card: http://linuxwireless.org/en/users/Drivers/ath9k/products/external What's the status of the Atheros HAL in FreeBSD? If there's any coding/porting/testing help needed, I'll be of assistance gladly. Best regards, oni From owner-freebsd-hardware@FreeBSD.ORG Thu Jan 21 13:12:54 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FBD51065692 for ; Thu, 21 Jan 2010 13:12:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 04EFE8FC19 for ; Thu, 21 Jan 2010 13:12:54 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3F60546B46; Thu, 21 Jan 2010 08:12:53 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 50F508A025; Thu, 21 Jan 2010 08:12:52 -0500 (EST) From: John Baldwin To: Stephane LAPIE Date: Thu, 21 Jan 2010 07:49:40 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091231; KDE/4.3.1; amd64; ; ) References: <4B56CD4C.80503@darkbsd.org> <201001201105.26367.jhb@freebsd.org> <4B58008C.4050207@darkbsd.org> In-Reply-To: <4B58008C.4050207@darkbsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201001210749.40575.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 21 Jan 2010 08:12:52 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hardware@freebsd.org Subject: Re: DELL SAS5/E Controller bug X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 13:12:54 -0000 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 : > >>>> mpt0@pci0:6:8:0: class=0x010000 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 SAS bus 0 id 0 > >> da1 ( 932G) ONLINE SAS bus 0 id 1 > >> da2 ( 932G) ONLINE SAS bus 0 id 2 > >> da3 ( 932G) ONLINE SAS bus 0 id 3 > >> da4 ( 932G) ONLINE SAS bus 0 id 4 > >> da5 ( 932G) ONLINE SAS bus 0 id 5 > >> da6 ( 932G) ONLINE SAS bus 0 id 6 > >> da7 ( 932G) ONLINE SAS bus 0 id 7 > >> da8 ( 932G) ONLINE SAS bus 0 id 8 > >> da9 ( 932G) ONLINE SAS bus 0 id 9 > >> da10 ( 932G) ONLINE SAS bus 0 id 10 > >> da11 ( 932G) ONLINE SAS bus 0 id 11 > >> da12 ( 932G) ONLINE SAS bus 0 id 12 > >> da13 ( 932G) ONLINE SAS bus 0 id 13 > >> da14 ( 932G) ONLINE SAS bus 0 id 14 > >> da15 ( 136G) ONLINE 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 this I used gdb and set a breakpoint in > > mpt_fetch_disks() so I could examine the structures that CAM returned. This > > is the code that identifies mptX vs mpt: > > > > /* Match mptX bus 0. */ > > ccb.cdm.patterns[0].type = DEV_MATCH_BUS; > > b = &ccb.cdm.patterns[0].pattern.bus_pattern; > > snprintf(b->dev_name, sizeof(b->dev_name), "mpt"); > > b->unit_number = mpt_unit; > > b->bus_id = 0; > > b->flags = BUS_MATCH_NAME | BUS_MATCH_UNIT | BUS_MATCH_BUS_ID; > > > > 'mpt_unit' is a global variable that is set to the value of the 'u' > > parameter. > > > >> freebsd-r610# mptutil -u 1 show drives > >> mptutil: mpt_fetch_disks got wrong CAM matches > >> mpt1 Physical Drives: > >> 0 ( 137G) ONLINE SAS bus 0 id 1 > >> 1 ( 137G) ONLINE SAS bus 0 id 9 > > > > Similarly I would use gdb to exmaine the reply from CAM here to see why > > it got 'wrong CAM matches'. The code expects the first match to match > > the bus and the next N matches should be 'daX' devices. > > > > I just applied your patch to mptutil source, which now returns : > > freebsd-r610# mptutil show adapter > mpt0 Adapter: > Board Name: SAS5e > Board Assembly: > Chip Name: C1068 > Chip Revision: UNUSED > RAID Levels: none > mptutil: mpt_read_ioc_page(2): Invalid configuration page 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 will give a try on the gdb thing once I get a chance of installing the > source tree on this test machine. > > > Also, I pasted the dmesg trace of trying to remove da0 and da6 and > trying to have the system register the removal via a "camcontrol rescan 0" : > > -> Unplugging "da0" and "da6" : > mpt0: mpt_cam_event: 0x16 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x16 > mpt0: mpt_cam_event: 0x16 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x16 > > -> Then running "camcontrol rescan 0" (which leaves "cbwait" state and > finishes at 187s real time) > mpt0: request 0xffffff80005bcea0:5936 timed out for ccb > 0xffffff00032d4000 (req->ccb 0xffffff00032d4000) > mpt0: attempting to abort req 0xffffff80005bcea0:5936 function 0 > mpt0: mpt_wait_req(1) timed out > mpt0: mpt_recover_commands: abort timed-out. Resetting controller > mpt0: mpt_cam_event: 0x0 > mpt0: completing timedout/aborted req 0xffffff80005bcea0:5936 > mpt0: mpt_cam_event: 0x16 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x16 > (da0:mpt0:0:0:0): lost device > (da0:mpt0:0:0:0): Synchronize cache failed, status == 0x4a, scsi status > == 0x0 > (da0:mpt0:0:0:0): removing device entry > (da6:mpt0:0:6:0): lost device > (da6:mpt0:0:6:0): Synchronize cache failed, status == 0x4a, scsi status > == 0x0 > (da6:mpt0:0:6:0): removing device entry > > -> Then replugging the drive "da0" : > mpt0: mpt_cam_event: 0x16 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x16 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. > Is there any documentation or hint as to what those mpt_cam_event are ? > I could whip myself a quick patch to at least change the display so one > would figure what these are. > > It feels like the 0x12 and 0x16 have to be handled to invalidate the > device that has been unplugged so the next request won't timeout but > fail directly. 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. -- John Baldwin From owner-freebsd-hardware@FreeBSD.ORG Thu Jan 21 16:26:51 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B10D01065679; Thu, 21 Jan 2010 16:26:51 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:198:206::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3375F8FC16; Thu, 21 Jan 2010 16:26:51 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id o0LGQoSA041942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jan 2010 17:26:50 +0100 (CET) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id o0LGQojb041941; Thu, 21 Jan 2010 17:26:50 +0100 (CET) (envelope-from uqs@spoerlein.net) Date: Thu, 21 Jan 2010 17:26:50 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Marin Atanasov Message-ID: <20100121162649.GP96430@acme.spoerlein.net> Mail-Followup-To: Marin Atanasov , freebsd-hardware@freebsd.org, freebsd-stable@freebsd.org References: <717f7a3e1001120714m37aada69gfaa35f0f9b17f435@mail.gmail.com> <44678539@bb.ipt.ru> <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> <717f7a3e1001192246o4dce4a82q57c05ff3f41b5feb@mail.gmail.com> <20100120074611.GA405@icarus.home.lan> <717f7a3e1001210137p7884adcbxc66a4f7fff928821@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <717f7a3e1001210137p7884adcbxc66a4f7fff928821@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Multiple serial consoles via null modem cable X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 16:26:51 -0000 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 From owner-freebsd-hardware@FreeBSD.ORG Thu Jan 21 22:01:48 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C659106566B for ; Thu, 21 Jan 2010 22:01:48 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 076C68FC0C for ; Thu, 21 Jan 2010 22:01:47 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id o0LLVvBH006233 for ; Thu, 21 Jan 2010 16:31:57 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <201001212131.o0LLVvBH006233@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 21 Jan 2010 16:31:55 -0500 To: freebsd-hardware@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: ichwd device ID for Intel H55 Express Watchdog X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 22:01:48 -0000 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=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 mdtancsa@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=0xbfebfbff Features2=0x98e3bd AMD Features=0x28100000 AMD Features2=0x1 TSC: P-state invariant real memory = 1073741824 (1024 MB) avail memory = 894103552 (852 MB) ACPI APIC Table: 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 irqs 0-23 on motherboard kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: 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: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf100-0xf107 mem 0xfe000000-0xfe3fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 pci0: at device 22.0 (no driver attached) atapci0: port 0xf0f0-0xf0f7,0xf0e0-0xf0e3,0xf0d0-0xf0d7,0xf0c0-0xf0c3,0xf0b0-0xf0bf irq 18 at device 22.2 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 22.3 (no driver attached) em0: port 0xf040-0xf05f mem 0xfe400000-0xfe41ffff,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: mem 0xfe427000-0xfe4273ff irq 16 at device 26.0 on pci0 ehci0: [ITHREAD] usbus0: EHCI version 1.0 usbus0: on ehci0 pci0: at device 27.0 (no driver attached) pcib1: irq 17 at device 28.0 on pci0 pci1: on pcib1 pcib2: irq 17 at device 28.4 on pci0 pci2: on pcib2 ehci1: mem 0xfe426000-0xfe4263ff irq 23 at device 29.0 on pci0 ehci1: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci1 pcib3: at device 30.0 on pci0 pci3: on pcib3 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: 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: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: 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: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 pmtimer0 on isa0 orm0: at iomem 0xcd000-0xcdfff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. Waiting 5 seconds for SCSI devices to settle usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 uhub2: 6 ports with 6 removable, self powered uhub3: 8 ports with 8 removable, self powered ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 SATA 1.x device ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO size 8192bytes) ada0: Command Queueing enabled ada0: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C) SMP: AP CPU #1 Launched! Trying to mount root from nfs: NFS ROOT: 10.255.255.1:/usr/home/pxe9/ ichwd0: on isa0 WARNING: /usr/src was not properly dismounted 0(i3)% -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-hardware@FreeBSD.ORG Fri Jan 22 01:55:20 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66C9C106568B; Fri, 22 Jan 2010 01:55:20 +0000 (UTC) (envelope-from stephane.lapie@darkbsd.org) Received: from quasar.darkbsd.org (shinigami.darkbsd.org [82.227.96.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1BC598FC1C; Fri, 22 Jan 2010 01:55:19 +0000 (UTC) Received: from quasar.darkbsd.org (localhost [127.0.0.1]) by quasar.darkbsd.org (Postfix) with ESMTP id 587B212B3; Fri, 22 Jan 2010 02:55:13 +0100 (CET) Received: from quasar.darkbsd.org ([127.0.0.1]) by quasar.darkbsd.org (quasar.darkbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtqRYVkrvcU9; Fri, 22 Jan 2010 02:55:10 +0100 (CET) Received: from [192.168.166.29] (unknown [210.188.173.245]) (Authenticated sender: darksoul) by quasar.darkbsd.org (Postfix) with ESMTPSA id 1043412AC; Fri, 22 Jan 2010 02:55:09 +0100 (CET) Message-ID: <4B59057D.9000500@darkbsd.org> Date: Fri, 22 Jan 2010 10:55:09 +0900 From: Stephane LAPIE User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: John Baldwin References: <4B56CD4C.80503@darkbsd.org> <201001201105.26367.jhb@freebsd.org> <4B58008C.4050207@darkbsd.org> <201001210749.40575.jhb@freebsd.org> In-Reply-To: <201001210749.40575.jhb@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8095763199007976027DA7AA" Cc: freebsd-hardware@freebsd.org Subject: Re: DELL SAS5/E Controller bug X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 01:55:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8095763199007976027DA7AA Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable John Baldwin wrote: > Gah, that should be the case that I ignore. Can you replace the second= =20 > warnx() call I added with this: >=20 > 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 s= uch a=20 > 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 do= cs. 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 SC= SI, subject to rescans and resets and timeouts. It's fighting with the S= AS 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.=20 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. --=20 Stephane LAPIE, EPITA SRS, Promo 2005 "Even when they have digital readouts, I can't understand them." --MegaTokyo --------------enig8095763199007976027DA7AA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktZBX0ACgkQ24Ql8u6TF2PKtwCg1YqKbZkmdeVywKdt2ViPYrwN pqQAn1ASbFYYZbBCfAqQpDJMVRHPaVIm =3Ov1 -----END PGP SIGNATURE----- --------------enig8095763199007976027DA7AA-- From owner-freebsd-hardware@FreeBSD.ORG Fri Jan 22 06:36:53 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 209721065676; Fri, 22 Jan 2010 06:36:53 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 7A8AE8FC13; Fri, 22 Jan 2010 06:36:51 +0000 (UTC) Received: by ewy3 with SMTP id 3so948990ewy.33 for ; Thu, 21 Jan 2010 22:36:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Xn4lfjswCA1iWbd69Hqih7OWN6LC6yL3xllY3SacPHo=; b=i/EC8vfaIbLXjUtp5K8JsTsmAN1X3FMbfpV/JFje9OpN8thN0bonJYJHH6G5kWhb/z an8xY2SoRXmSBvJ/IEm1lQZviNhH56wc5ZPB3cBxnoJ259ezCKzBiieblNtdmTxESCBL OUQCv4qcVVcm31EPQaKMvT1+TzSBQwbAyBNz4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=T4wveQJb30WuT99uVG1uG8f0mNStO6RFOhu+zSqJcb9r4Qdfhwm2uPFTxGvCOanNRX LiEoMS6a8DdWb9gc6JqUUK2CThX5CK6n5B7i7AJd8f+u458Tg8fi/iGU5EE/ioVbo+3o iwNiCOAD9KGJuBZZQZX6mrRyDbpOhErl+fdyo= MIME-Version: 1.0 Received: by 10.216.91.6 with SMTP id g6mr921101wef.212.1264142211124; Thu, 21 Jan 2010 22:36:51 -0800 (PST) In-Reply-To: <20100121162649.GP96430@acme.spoerlein.net> References: <717f7a3e1001120714m37aada69gfaa35f0f9b17f435@mail.gmail.com> <44678539@bb.ipt.ru> <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> <717f7a3e1001192246o4dce4a82q57c05ff3f41b5feb@mail.gmail.com> <20100120074611.GA405@icarus.home.lan> <717f7a3e1001210137p7884adcbxc66a4f7fff928821@mail.gmail.com> <20100121162649.GP96430@acme.spoerlein.net> Date: Fri, 22 Jan 2010 08:36:51 +0200 Message-ID: <717f7a3e1001212236x78c12d1ue22283338e3e179c@mail.gmail.com> From: Marin Atanasov To: Marin Atanasov , freebsd-hardware@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Multiple serial consoles via null modem cable X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 06:36:53 -0000 On Thu, Jan 21, 2010 at 6:26 PM, Ulrich Sp=F6rlein wrot= e: > 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 --=20 Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org From owner-freebsd-hardware@FreeBSD.ORG Fri Jan 22 08:29:10 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70C221065693 for ; Fri, 22 Jan 2010 08:29:10 +0000 (UTC) (envelope-from njm@njm.me.uk) Received: from smtp004.apm-internet.net (smtp004.apm-internet.net [85.119.248.54]) by mx1.freebsd.org (Postfix) with SMTP id EFF888FC0A for ; Fri, 22 Jan 2010 08:29:09 +0000 (UTC) Received: (qmail 41025 invoked from network); 22 Jan 2010 08:02:29 -0000 Received: from unknown (HELO oberon.njm.me.uk) (86.129.211.242) by smtp004.apm-internet.net with SMTP; 22 Jan 2010 08:02:29 -0000 Received: from titania.njm.me.uk (titania.njm.me.uk [192.168.144.130]) by oberon.njm.me.uk (8.14.3/8.14.3) with ESMTP id o0M82TL2084197; Fri, 22 Jan 2010 08:02:29 GMT (envelope-from njm@njm.me.uk) Received: from titania.njm.me.uk (localhost [127.0.0.1]) by titania.njm.me.uk (8.14.3/8.14.3) with ESMTP id o0M82S69015969; Fri, 22 Jan 2010 08:02:28 GMT (envelope-from njm@njm.me.uk) Received: (from njm@localhost) by titania.njm.me.uk (8.14.3/8.14.3/Submit) id o0M82N2e015968; Fri, 22 Jan 2010 08:02:23 GMT (envelope-from njm@njm.me.uk) Date: Fri, 22 Jan 2010 08:02:23 +0000 From: "N.J. Mann" To: Marin Atanasov Message-ID: <20100122080223.GA6681@titania.njm.me.uk> Mail-Followup-To: Marin Atanasov , Jeremy Chadwick , freebsd-hardware@freebsd.org, freebsd-stable@freebsd.org, Ronald Klop References: <717f7a3e1001120714m37aada69gfaa35f0f9b17f435@mail.gmail.com> <44678539@bb.ipt.ru> <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> <717f7a3e1001192246o4dce4a82q57c05ff3f41b5feb@mail.gmail.com> <20100120074611.GA405@icarus.home.lan> <717f7a3e1001210137p7884adcbxc66a4f7fff928821@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <717f7a3e1001210137p7884adcbxc66a4f7fff928821@mail.gmail.com> X-Operating-System: FreeBSD 7.2-STABLE User-Agent: mutt-NJM (2009-12-30) Cc: Ronald Klop , freebsd-stable@freebsd.org, Jeremy Chadwick , freebsd-hardware@freebsd.org Subject: Re: Multiple serial consoles via null modem cable X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 08:29:10 -0000 In message <717f7a3e1001210137p7884adcbxc66a4f7fff928821@mail.gmail.com>, Marin Atanasov (dnaeon@gmail.com) wrote: > 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 > wrote: > > > 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] You need to reduce the number of unknowns, e.g. where is the problem: box1, box3 or in between. So, swap the cables on box1 so that you now have box1:COM1 -> box3:COM1 and box1:COM2 -> box2:COM1. Now repeat the tests above and post your results. Cheers, Nick. -- From owner-freebsd-hardware@FreeBSD.ORG Fri Jan 22 14:32:05 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 639B1106566B for ; Fri, 22 Jan 2010 14:32:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1FCE88FC0C for ; Fri, 22 Jan 2010 14:32:05 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 91B1C46B1A; Fri, 22 Jan 2010 09:32:04 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id B055A8A025; Fri, 22 Jan 2010 09:32:03 -0500 (EST) From: John Baldwin To: Stephane LAPIE Date: Fri, 22 Jan 2010 08:46:17 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091231; KDE/4.3.1; amd64; ; ) References: <4B56CD4C.80503@darkbsd.org> <201001210749.40575.jhb@freebsd.org> <4B59057D.9000500@darkbsd.org> In-Reply-To: <4B59057D.9000500@darkbsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201001220846.17419.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 22 Jan 2010 09:32:03 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hardware@freebsd.org Subject: Re: DELL SAS5/E Controller bug X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 14:32:05 -0000 On Thursday 21 January 2010 8:55:09 pm Stephane LAPIE wrote: > 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) Ah, I need to mask IOCStatus to only get the error code. The patch below should quiet the warning: Index: mpt_show.c =================================================================== --- mpt_show.c (revision 202705) +++ 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,11 @@ printf(" none"); printf("\n"); free(ioc2); - } + } else if ((IOCStatus & MPI_IOCSTATUS_MASK) != + 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 +175,9 @@ printf("-%u", ioc6->MaxDrivesIME); printf("\n"); free(ioc6); - } + } else if ((IOCStatus & MPI_IOCSTATUS_MASK) != + MPI_IOCSTATUS_CONFIG_INVALID_PAGE) + warnx("mpt_read_ioc_page(6): %s", mpt_ioc_status(IOCStatus)); /* TODO: Add an ioctl to fetch IOC_FACTS and print firmware version. */ @@ -541,7 +546,8 @@ for (i = 0; i <= 0xff; i++) { pinfo = mpt_pd_info(fd, i, &IOCStatus); if (pinfo == NULL) { - if (IOCStatus != MPI_IOCSTATUS_CONFIG_INVALID_PAGE) + if ((IOCStatus & MPI_IOCSTATUS_MASK) != + MPI_IOCSTATUS_CONFIG_INVALID_PAGE) warnx("mpt_pd_info(%d): %s", i, mpt_ioc_status(IOCStatus)); continue; > > 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. I have no idea, I'd have to defer to Scott in that regard. -- John Baldwin From owner-freebsd-hardware@FreeBSD.ORG Fri Jan 22 16:10:25 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1AFB10656D6; Fri, 22 Jan 2010 16:10:25 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 129DA8FC15; Fri, 22 Jan 2010 16:10:24 +0000 (UTC) Received: by ewy26 with SMTP id 26so333134ewy.3 for ; Fri, 22 Jan 2010 08:10:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=eL41dN0L5PLt0KdWho/DEzHD6PeOg8dEwFYx/RP4k2g=; b=ozEAzEfNPjkIq3eJKHKL3oBKJRpQ4rGFqFsVpreqt4+xxSdIsHMlQ3kJ6ORFqAdus1 RYZpobm9wxzAulTryoHxFf8biFR9YbB0mvAelbMJjAWi9gMYuo0P38l9y/izZCM3YVRd cDjvq/tCq1IBJBnoMy6skW6KfesKgfs+INTB0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=XZXvAciriQf/ARSDOt50JtrZAB52CgJbUJhU1MWrtkoXDayFUWdn0ArdxLm4pDvfQN zPYcyJXlRRzjAYNKjFm0b1F3Y2F3WNBDqnjDGVMxTo/SUJ/XmRQ+GhlYFLsn56h59RbM MjkHtTugCdIlgFfsZ6UPPBTYNfS3jPS6CJyGw= MIME-Version: 1.0 Received: by 10.216.91.81 with SMTP id g59mr1221978wef.128.1264176623743; Fri, 22 Jan 2010 08:10:23 -0800 (PST) In-Reply-To: <20100122080223.GA6681@titania.njm.me.uk> References: <717f7a3e1001120714m37aada69gfaa35f0f9b17f435@mail.gmail.com> <44678539@bb.ipt.ru> <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> <717f7a3e1001192246o4dce4a82q57c05ff3f41b5feb@mail.gmail.com> <20100120074611.GA405@icarus.home.lan> <717f7a3e1001210137p7884adcbxc66a4f7fff928821@mail.gmail.com> <20100122080223.GA6681@titania.njm.me.uk> Date: Fri, 22 Jan 2010 18:10:23 +0200 Message-ID: <717f7a3e1001220810s11b241b7ve9a9172c51ea531b@mail.gmail.com> From: Marin Atanasov To: Marin Atanasov , Jeremy Chadwick , freebsd-hardware@freebsd.org, freebsd-stable@freebsd.org, Ronald Klop Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Multiple serial consoles via null modem cable X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 16:10:25 -0000 On Fri, Jan 22, 2010 at 10:02 AM, N.J. Mann wrote: > In message <717f7a3e1001210137p7884adcbxc66a4f7fff928821@mail.gmail.com>, > Marin Atanasov (dnaeon@gmail.com) wrote: > > 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 > > wrote: > > > > > 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] > > You need to reduce the number of unknowns, e.g. where is the problem: > box1, box3 or in between. So, swap the cables on box1 so that you now > have box1:COM1 -> box3:COM1 and box1:COM2 -> box2:COM1. Now repeat the > tests above and post your results. > > > Cheers, > Nick. > -- > > Seems I've found the issue, that I'm having - a broken null modem cable :( The last time I was using that cable it was working fine. And now that I connected a second one to the machine, it seemed that only the one connected to COM1 was actually working, and I was left with the impression from the documentation that only COM1 is able to do a serial console connection. I'm very sorry to bother you like that. I'll continue setting up the servers once I get a new null modem cable. Thanks and regards, Marin -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org