From onemda at gmail.com Sun Nov 1 16:02:59 2009 From: onemda at gmail.com (Paul B Mahol) Date: Sun Nov 1 16:03:05 2009 Subject: hostapd "deauthenticated due to local deauth request" In-Reply-To: <3a142e750910310916labe85e5ke804386a834c49c8@mail.gmail.com> References: <9bbcef730910310830s43237918g1489beb1fe9fae9a@mail.gmail.com> <3a142e750910310916labe85e5ke804386a834c49c8@mail.gmail.com> Message-ID: <3a142e750911010802l1a4183edh9d92eabdc21ab661@mail.gmail.com> On 10/31/09, Paul B Mahol wrote: > On 10/31/09, Ivan Voras wrote: >> I'm trying to setup an AP with a run0 interface on latest 8-STABLE but >> apparently 802.11 association fails: >> >> Oct 31 16:21:30 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE >> 802.11: associated >> Oct 31 16:21:33 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE >> 802.11: deauthenticated due to local deauth request >> Oct 31 16:21:33 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE >> 802.11: deassociated >> Oct 31 16:21:35 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE >> 802.11: associated >> Oct 31 16:21:38 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE >> 802.11: deauthenticated due to local deauth request >> Oct 31 16:21:38 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE >> 802.11: deassociated >> >> etc. Apparently the client never comes to the phase to receive DHCP >> address. >> >> The client in this case is WinXP and the setup did work with 7-STABLE, >> though with a bug in the rum driver which caused regular kernel panics >> on the AP. >> > > I tried same one with rum(4) as AP and ndis(4) as client on same > machine(some version of 8.0 - CURRENT). ndis client (configured via > wpa_supplicant) > would keep auth and deauth all the time. > I came to conclusion that rum is broken. But I think I remmember that > bwi(4) (as a client) > did not have such problem ... (I will test again to see) Well, I tried again and I got similar output like yours if I use wrong password. And with correct password client reauth all the time, maybe I need to setup ndis_events(8) .... From cowens at greatbaysoftware.com Thu Nov 5 15:35:40 2009 From: cowens at greatbaysoftware.com (Charles Owens) Date: Thu Nov 5 15:35:47 2009 Subject: kern/139654: CD-boot failure on newer IBM server Message-ID: <4AF2E837.2080705@greatbaysoftware.com> Hello, As detailed in the PR, we are unable to get FreeBSD (7.1) to boot with an IBM System x3250 M2 server. I'm not sure what steps to take next, and would greatly appreciate assistance. We've also submitted kern/139653 which deal with different hardware (HP) and is not quite as critical (very poor performance, as opposed to complete failure)... any suggestions with this also welcome. PR links: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/139654 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/139653 Thanks very much, Charles -- **Charles Owens** *Great Bay Software**|** *www.GreatBaySoftware.com**** From simon at optinet.com Sat Nov 7 08:47:02 2009 From: simon at optinet.com (Simon) Date: Sat Nov 7 08:47:09 2009 Subject: [Fwd: Re: amr driver issues in 7.1-RELEASE] In-Reply-To: <49D5FFA7.3090408@collaborativefusion.com> Message-ID: <20091107084702.7CC08106566B@hub.freebsd.org> On Fri, 03 Apr 2009 08:23:03 -0400, Steve Polyack wrote: >> It appears this has not been fixed in 7.1-p4 I've been waiting to upgrade due >> to this but was forced after latest root exploit was found recently. Upon MySQL >> upgrade, running mysql_upgrade which upgrades and checks all the tables, >> I got 2 of these messages while a large ,1.4G, mysql table was being dumped >> to array so it could be repaired. I don't know what to make of this error and >> are not sure if it could be safely ignored. >> >> amr0: Too many retries on command 0xc71ceaa8. Controller is likely dead >> amr0: Too many retries on command 0xc71cdce8. Controller is likely dead >> >> Thank you in advance! >> >> -Simon >> >> >We still see these as well. I've also been ensured that these are >harmless messages. As far as I can tell from my own investigation, the >behavior has not changed other than the addition of tracking of how many >retries there have been when submitting commands to the controller. >When the controller mailbox is "busy", the driver must wait before >submitting a command. If the driver has to retry 1000 times twice >within one second, it logs the messages you are seeing. This logging >was simply not present before 7.1. >As I've said and been told, the message is harmless if your machine is >still responding. I just wanted to follow up and let the list know my instance of this error was being caused by faulty drives. If you get this message, I would be concerned. Backup your data and run every single drive connected to this controller via manufacturer's diagnostic full test. A single faulty drive in RAID setup can cause mediocre performance and this error to show up. -Simon From deep.alexander at gmail.com Sun Nov 8 02:33:27 2009 From: deep.alexander at gmail.com (Alex Nordlund) Date: Sun Nov 8 02:33:35 2009 Subject: No drivers for INITIO INI1622? Linux drivers exists (with source too) Message-ID: Are there really no drivers for the INITIO INI1622? I only seem to find the Linux drivers (which are open source and GPL'd) http://www.sunix.com.tw/it/en/down/driver/SATA/SATA2100/linux0919.zip showed: linux.zip/initio162x_release0919/FC6/driver/sata_initio162x.c --- //Alex From korvus at comcast.net Mon Nov 9 15:48:55 2009 From: korvus at comcast.net (Steve Polyack) Date: Mon Nov 9 15:49:01 2009 Subject: mfi(4) lockups and the adapter event log Message-ID: <4AF839E5.10303@comcast.net> Hello, We saw an odd crash (more of a lockup) on one of our Dell's with a PERC5/i RAID controller (running 6.3-RELEASE-p10): mfi0: COMMAND 0xffffffff89dab0e8 TIMEOUT AFTER 31 SECONDS (repeated many times with different commands) mfi0: 3325 (310696326s/0x0020/4) - Type 18: Fatal firmware error: Line 1091 in ../../raid/verdeMain.c After some troubleshooting with Dell, they determined that there was no problem. An OpenManage live CD was used to run their diagnostic utilities, which turned up nothing. However, after rebooting the system and checking dmesg(8), it could be seen that the adapter was doing some weird things during initialization. It seemed to be going through the whole initialization cycle (Firmware initialization started....) up to five times. This does not jive with our other mfi/PERC5 systems. In addition to the multiple init cycles it was also printing weeks worth of messages from the adapter's event log (mostly battery relearns). Checking the event log with linux-megacli showed TONS of messages. Trying to clear them using linux-megacli seemed to cause a similar lockup, filled with command timeouts, but no fatal firmware error. We ended up clearing the event log using a linux live CD and the linux native MegaCLI binaries. The system hasn't locked up again since, but we're not sure what caused it in the first place. Has anyone else seen any kind of oddities with the PERC series of controllers and the adapter's event log? Does it just fill up after a while and start to cause trouble? I seem to remember a similar post recommending a cleaning of the event logs every so often. Thanks, Steve From lavalamp at spiritual-machines.org Mon Nov 9 19:18:57 2009 From: lavalamp at spiritual-machines.org (Brian A. Seklecki) Date: Mon Nov 9 19:19:38 2009 Subject: mfi(4) lockups and the adapter event log In-Reply-To: <4AF839E5.10303@comcast.net> References: <4AF839E5.10303@comcast.net> Message-ID: <1257792652.20787.372.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> > with linux-megacli showed TONS of messages. Trying to clear them using > linux-megacli seemed to cause a similar lockup, filled with command > timeouts, but no fatal firmware error. Also, does anyone know if the mfiutil(8) util in RELENG_8 has the ability to purge the event log? Man page 'clear' command nukes the volume configuration >:} We don't have RELENG_8 on a PowerEdge system yet. ~BAS From krassi at bulinfo.net Wed Nov 11 15:54:57 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Wed Nov 11 15:55:03 2009 Subject: USB SD, MMC, MS, CF card reader? Message-ID: <4AFADA49.5070401@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, I have an old USB card reader which is not recognized by 8.0. The reader is based on a C-Media CM320L chip. Does this reader need special handling or umass driver can be used? # usbconfig -u 7 -a 2 dump_info ugen7.2: at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON # usbconfig -u 7 -a 2 dump_device_quirks Dumping current device quirks: VID=0x0b05 PID=0x1726 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_HID_IGNORE VID=0x1608 PID=0x0001 REVLO=0x0094 REVHI=0x0094 QUIRK=UQ_SWAP_UNICODE VID=0x04fa PID=0x4201 REVLO=0x00a2 REVHI=0x00a2 QUIRK=UQ_BAD_ADC VID=0x04fa PID=0x4201 REVLO=0x00a2 REVHI=0x00a2 QUIRK=UQ_AU_NO_XU VID=0x04d2 PID=0x0070 REVLO=0x0103 REVHI=0x0103 QUIRK=UQ_BAD_ADC VID=0x04d2 PID=0xff05 REVLO=0x0000 REVHI=0x0000 QUIRK=UQ_BAD_AUDIO VID=0x05c7 PID=0x2011 REVLO=0x0110 REVHI=0x0110 QUIRK=UQ_SPUR_BUT_UP VID=0x0566 PID=0x2802 REVLO=0x0001 REVHI=0x0001 QUIRK=UQ_SPUR_BUT_UP VID=0x0711 PID=0x0100 REVLO=0x0102 REVHI=0x0102 QUIRK=UQ_BUS_POWERED VID=0x0711 PID=0x0210 REVLO=0x0102 REVHI=0x0102 QUIRK=UQ_BUS_POWERED VID=0x0451 PID=0x1446 REVLO=0x0110 REVHI=0x0110 QUIRK=UQ_POWER_CLAIM VID=0x0562 PID=0x0001 REVLO=0x0009 REVHI=0x0009 QUIRK=UQ_AU_NO_FRAC VID=0x1527 PID=0x0201 REVLO=0x0100 REVHI=0x0100 QUIRK=UQ_AU_INP_ASYNC VID=0x046d PID=0xc032 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_NO_STRINGS VID=0x05cc PID=0x2265 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_CFG_INDEX_1 VID=0x03f0 PID=0x0004 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_BROKEN_BIDIR VID=0x03f0 PID=0x0104 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_BROKEN_BIDIR VID=0x03f0 PID=0x0204 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_BROKEN_BIDIR VID=0x03f0 PID=0x0304 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_BROKEN_BIDIR VID=0x03f0 PID=0x0404 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_BROKEN_BIDIR VID=0x03f0 PID=0x0212 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_BROKEN_BIDIR VID=0x0924 PID=0xffef REVLO=0x0000 REVHI=0xffff QUIRK=UQ_BROKEN_BIDIR VID=0x051d PID=0x0002 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_HID_IGNORE VID=0x050d PID=0x0551 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_HID_IGNORE VID=0x0764 PID=0x0501 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_HID_IGNORE VID=0x1163 PID=0x0100 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_HID_IGNORE VID=0x04d8 PID=0x0002 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_HID_IGNORE VID=0x04d8 PID=0xc001 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_HID_IGNORE VID=0x0463 PID=0x0001 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_HID_IGNORE VID=0x0463 PID=0xffff REVLO=0x0000 REVHI=0xffff QUIRK=UQ_HID_IGNORE VID=0x05ac PID=0x1290 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_HID_IGNORE VID=0x05ac PID=0x1292 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_HID_IGNORE VID=0x04b4 PID=0x0bad REVLO=0x0000 REVHI=0xffff QUIRK=UQ_KBD_IGNORE VID=0x04b4 PID=0x0bad REVLO=0x0000 REVHI=0xffff QUIRK=UQ_HID_IGNORE VID=0x1781 PID=0x083e REVLO=0x0000 REVHI=0xffff QUIRK=UQ_KBD_IGNORE VID=0x1781 PID=0x083e REVLO=0x0000 REVHI=0xffff QUIRK=UQ_HID_IGNORE VID=0x1130 PID=0xf211 REVLO=0x0101 REVHI=0x0101 QUIRK=UQ_AUDIO_SWAP_LR VID=0x045e PID=0x008c REVLO=0x0000 REVHI=0xffff QUIRK=UQ_MS_LEADING_BYTE VID=0x1781 PID=0x083f REVLO=0x0000 REVHI=0xffff QUIRK=UQ_KBD_IGNORE VID=0x1781 PID=0x083f REVLO=0x0000 REVHI=0xffff QUIRK=UQ_HID_IGNORE -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr62kkACgkQxJBWvpalMpk/OACdE8++xMFCcX51jTrwtw0edFuX NQAAn2/UUI3OJdOeFClJRwXeqsHNLlbq =Umxy -----END PGP SIGNATURE----- From hselasky at c2i.net Wed Nov 11 17:02:59 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Nov 11 17:03:06 2009 Subject: USB SD, MMC, MS, CF card reader? In-Reply-To: <4AFADA49.5070401@bulinfo.net> References: <4AFADA49.5070401@bulinfo.net> Message-ID: <200911111704.20112.hselasky@c2i.net> On Wednesday 11 November 2009 16:37:45 Krassimir Slavchev wrote: > Hi All, > > I have an old USB card reader which is not recognized by 8.0. > The reader is based on a C-Media CM320L chip. > > Does this reader need special handling or umass driver can be used? > > # usbconfig -u 7 -a 2 dump_info > ugen7.2: at usbus7, cfg=0 md=HOST > spd=HIGH (480Mbps) pwr=ON > > # usbconfig -u 7 -a 2 dump_device_quirks > Hi, The umass quirks are currently not available through the USB quirks API. Can you do: dump_device_desc and dump_curr_config_desc ? You probably need to edit sys/dev/usb/storage/umass.c and add a device entry there. --HPS From krassi at bulinfo.net Wed Nov 11 18:01:48 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Wed Nov 11 18:01:55 2009 Subject: USB SD, MMC, MS, CF card reader? In-Reply-To: <200911111704.20112.hselasky@c2i.net> References: <4AFADA49.5070401@bulinfo.net> <200911111704.20112.hselasky@c2i.net> Message-ID: <4AFAFC06.70800@bulinfo.net> Hans Petter Selasky wrote: > On Wednesday 11 November 2009 16:37:45 Krassimir Slavchev wrote: >> Hi All, >> >> I have an old USB card reader which is not recognized by 8.0. >> The reader is based on a C-Media CM320L chip. >> >> Does this reader need special handling or umass driver can be used? >> >> # usbconfig -u 7 -a 2 dump_info >> ugen7.2: at usbus7, cfg=0 md=HOST >> spd=HIGH (480Mbps) pwr=ON >> >> # usbconfig -u 7 -a 2 dump_device_quirks >> > > Hi, > > The umass quirks are currently not available through the USB quirks API. > Can you do: dump_device_desc and dump_curr_config_desc ? > You probably need to edit sys/dev/usb/storage/umass.c and add a device entry > there. > > --HPS > > Yes, I will try but I am not sure whether this will be enough # usbconfig -u 7 -a 2 dump_device_desc ugen7.2: at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x0000 bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0040 idVendor = 0x0d8c idProduct = 0x5200 bcdDevice = 0x0100 iManufacturer = 0x0000 iProduct = 0x0000 iSerialNumber = 0x0000 bNumConfigurations = 0x0001 # usbconfig -u 7 -a 2 dump_curr_config_desc ugen7.2: at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0027 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x0000 bmAttributes = 0x0080 bMaxPower = 0x00fa Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0000 bNumEndpoints = 0x0003 bInterfaceClass = 0x00ff bInterfaceSubClass = 0x00ff bInterfaceProtocol = 0x00ff iInterface = 0x0000 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0082 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 2 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0084 bmAttributes = 0x0003 wMaxPacketSize = 0x0004 bInterval = 0x0009 bRefresh = 0x0000 bSynchAddress = 0x0000 From david at catwhisker.org Wed Nov 11 18:05:06 2009 From: david at catwhisker.org (David Wolfskill) Date: Wed Nov 11 18:05:13 2009 Subject: 7.2-STABLE i386 box crashing -- clues? Message-ID: <20091111173747.GA1150@albert.catwhisker.org> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hardware/attachments/20091111/00554705/attachment.pgp From peter at vk2pj.dyndns.org Thu Nov 12 07:39:00 2009 From: peter at vk2pj.dyndns.org (Peter Jeremy) Date: Thu Nov 12 07:39:07 2009 Subject: 7.2-STABLE i386 box crashing -- clues? In-Reply-To: <20091111173747.GA1150@albert.catwhisker.org> References: <20091111173747.GA1150@albert.catwhisker.org> Message-ID: <20091112062708.GA16648@server.vk2pj.dyndns.org> I can't offer any solutions but I have some more questions... On 2009-Nov-11 09:37:47 -0800, David Wolfskill wrote: >Every once in a while, it just crashes -- hard. It loses video output >at that point; Ctl+Alt+Esc doesn't appear to change anything; entering >(say) "reset" blindly at that point has no apparent effect. Roughly how often? Has anything unusual happened lately? Brownout, blackout, power surge, lightning, heatwave, ... >accordingly, had attached a SCSI host adaptor via PCI riser card. Since >I had nothing actually connected to the card, I pulled it out of the >machine before bringing it back up. Did you also pull the riser card? Riser cards don't have a spectacularly high reputation. > (I also fleft around for >excessively warm spots; nothing. All fans spin up, as well.) I don't suppose you also studied the capacitors on the motherboard. Are any showing any signs of bulges? Have you tried reseating everything? >Flaky CPU? Flaky power supply? How might I tell? CPU shouldn't go flaky unless it's been overheated. In my experience, PSUs are the least reliable part of consumer-grade hardware but about the only way to check is to swap it. If you've got a DMM, you could check all the rails but there are lots of failure modes that won't show up that way. Have you checked the voltage/temperature screen in the BIOS? Does anything look abnormal? Are you using a PS/2 or USB keyboard? Are you running X? At this stage, my suggestion would be to try swapping the PSU. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hardware/attachments/20091112/ce20f1d1/attachment.pgp From david at catwhisker.org Thu Nov 12 12:59:05 2009 From: david at catwhisker.org (David Wolfskill) Date: Thu Nov 12 12:59:11 2009 Subject: 7.2-STABLE i386 box crashing -- clues? In-Reply-To: <20091112062708.GA16648@server.vk2pj.dyndns.org> References: <20091111173747.GA1150@albert.catwhisker.org> <20091112062708.GA16648@server.vk2pj.dyndns.org> Message-ID: <20091112125903.GA1631@albert.catwhisker.org> On Thu, Nov 12, 2009 at 05:27:09PM +1100, Peter Jeremy wrote: > I can't offer any solutions but I have some more questions... I appreciate the help! > ... > >Every once in a while, it just crashes -- hard. It loses video output > >at that point; Ctl+Alt+Esc doesn't appear to change anything; entering > >(say) "reset" blindly at that point has no apparent effect. > > Roughly how often? For the current month: albert(7.2-S)[8] last reboot shutdown reboot ~ Thu Nov 12 03:04 reboot ~ Wed Nov 11 20:06 reboot ~ Wed Nov 11 14:42 shutdown ~ Wed Nov 11 14:40 reboot ~ Wed Nov 11 14:35 reboot ~ Wed Nov 11 10:05 reboot ~ Wed Nov 11 09:09 reboot ~ Wed Nov 11 04:25 reboot ~ Tue Nov 10 12:49 reboot ~ Mon Nov 9 14:52 reboot ~ Sun Nov 8 17:42 reboot ~ Sat Nov 7 04:22 reboot ~ Fri Nov 6 21:43 reboot ~ Fri Nov 6 19:00 reboot ~ Fri Nov 6 16:20 shutdown ~ Fri Nov 6 16:17 reboot ~ Fri Nov 6 16:03 reboot ~ Fri Nov 6 13:07 reboot ~ Fri Nov 6 09:46 reboot ~ Thu Nov 5 16:41 reboot ~ Thu Nov 5 13:32 reboot ~ Thu Nov 5 12:59 reboot ~ Thu Nov 5 10:17 reboot ~ Thu Nov 5 04:26 reboot ~ Wed Nov 4 20:32 reboot ~ Wed Nov 4 15:48 reboot ~ Wed Nov 4 10:37 reboot ~ Tue Nov 3 13:15 reboot ~ Tue Nov 3 10:55 reboot ~ Tue Nov 3 04:16 reboot ~ Mon Nov 2 18:13 reboot ~ Sun Nov 1 20:03 shutdown ~ Sun Nov 1 20:01 reboot ~ Sun Nov 1 17:10 reboot ~ Sun Nov 1 13:51 shutdown ~ Sun Nov 1 13:48 wtmp begins Sun Nov 1 05:08:18 PST 2009 albert(7.2-S)[9] The "solo reboots" are crashes; those paired with "shutdown" entries are controlled. > Has anything unusual happened lately? Brownout, blackout, power surge, > lightning, heatwave, ... Nothing linked to the crashes. I pulled the UPS out of service some weeks ago because it needs new batteries; I need to get those ordered. But the crashes were happening before that, in any case. > >accordingly, had attached a SCSI host adaptor via PCI riser card. Since > >I had nothing actually connected to the card, I pulled it out of the > >machine before bringing it back up. > > Did you also pull the riser card? Riser cards don't have a spectacularly > high reputation. That's actually what I pulled. The SCSI card itself is still physically in the chassis, merely with an air gap between itself at the system board (because the riser card is now in a closet). > > (I also fleft around for > >excessively warm spots; nothing. All fans spin up, as well.) > > I don't suppose you also studied the capacitors on the motherboard. > Are any showing any signs of bulges? I'll take another look for those; I recall that electrolytics exhibit that as a sign of failure -- thanks for the reminder. > Have you tried reseating everything? The memory, yeah (even before replacing it); also swapped the DIMMs. Only other thing that can be re-seated (desktop system board, so most everything is built-in) would be the CPU, and I'm not quite sure how that heat sink works. I did re-seat some power connectors. > >Flaky CPU? Flaky power supply? How might I tell? > > CPU shouldn't go flaky unless it's been overheated. In my experience, > PSUs are the least reliable part of consumer-grade hardware but about > the only way to check is to swap it. :-} > If you've got a DMM, you could check all the rails but there are > lots of failure modes that won't show up that way. Yeah, I kinda figured that. I do have a DMM (used to have a VTVM), but figured the meter wouldn't show transient dips or whatever too well. > Have you checked the voltage/temperature screen in the BIOS? Does > anything look abnormal? Did a couple of reality checks in that way as detours during some of the reboots. Nothing interesting there at all. (And I have seen a case in the past -- though with a 1U box) where that test definitely showed something wrong (CPU temp climbing about 1C every 30 seconds, IIRC). > Are you using a PS/2 or USB keyboard? PS/2 via KVM. I don't have any USB keyboarda. :-} > Are you running X? Yes; the machine is configured to start xdm on transition to multi--user, as my spouse used to use it as a desktop. (She's gone back to using its predecessor, a 4.11-STABLE machine, in frustration.) > At this stage, my suggestion would be to try swapping the PSU. Thanks. I'll discuss it with the "family CFO." Peace, david -- David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hardware/attachments/20091112/d2c3984f/attachment.pgp From krassi at bulinfo.net Fri Nov 13 07:19:20 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Fri Nov 13 07:19:26 2009 Subject: USB SD, MMC, MS, CF card reader? In-Reply-To: <200911111704.20112.hselasky@c2i.net> References: <4AFADA49.5070401@bulinfo.net> <200911111704.20112.hselasky@c2i.net> Message-ID: <4AFD086F.4090009@bulinfo.net> Hans Petter Selasky wrote: > On Wednesday 11 November 2009 16:37:45 Krassimir Slavchev wrote: >> Hi All, >> >> I have an old USB card reader which is not recognized by 8.0. >> The reader is based on a C-Media CM320L chip. >> >> Does this reader need special handling or umass driver can be used? >> >> # usbconfig -u 7 -a 2 dump_info >> ugen7.2: at usbus7, cfg=0 md=HOST >> spd=HIGH (480Mbps) pwr=ON >> >> # usbconfig -u 7 -a 2 dump_device_quirks >> > > Hi, > > The umass quirks are currently not available through the USB quirks API. > Can you do: dump_device_desc and dump_curr_config_desc ? > You probably need to edit sys/dev/usb/storage/umass.c and add a device entry > there. I have tried almost all possible protocol combinations but no luck. With UMASS_PROTO_SCSI | UMASS_PROTO_BBB: umass0: on usbus7 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0: Get Max Lun not supported (USB_ERR_TIMEOUT) umass0:0:0:-1: Attached to scbus0 Adding NO_GETMAXLUN quirk: umass0: on usbus7 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:0:0:-1: Attached to scbus0 The same reader works on windows with 'Generic USB Mass Storage' driver and in the chip documentation I found that it is 'Compliant with USB Mass Storage Device Class specifications'. May be something is handled differently? Best Regards From hselasky at c2i.net Fri Nov 13 09:09:06 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Fri Nov 13 09:09:13 2009 Subject: USB SD, MMC, MS, CF card reader? In-Reply-To: <4AFD086F.4090009@bulinfo.net> References: <4AFADA49.5070401@bulinfo.net> <200911111704.20112.hselasky@c2i.net> <4AFD086F.4090009@bulinfo.net> Message-ID: <200911130908.06079.hselasky@c2i.net> On Friday 13 November 2009 08:19:11 Krassimir Slavchev wrote: > Hans Petter Selasky wrote: > > On Wednesday 11 November 2009 16:37:45 Krassimir Slavchev wrote: > >> Hi All, > >> > >> I have an old USB card reader which is not recognized by 8.0. > >> The reader is based on a C-Media CM320L chip. > >> > >> Does this reader need special handling or umass driver can be used? > >> > >> # usbconfig -u 7 -a 2 dump_info > >> ugen7.2: at usbus7, cfg=0 md=HOST > >> spd=HIGH (480Mbps) pwr=ON > >> > >> # usbconfig -u 7 -a 2 dump_device_quirks > > > > Hi, > > > > The umass quirks are currently not available through the USB quirks API. > > Can you do: dump_device_desc and dump_curr_config_desc ? > > You probably need to edit sys/dev/usb/storage/umass.c and add a device > > entry there. > > I have tried almost all possible protocol combinations but no luck. > With UMASS_PROTO_SCSI | UMASS_PROTO_BBB: > > umass0: > on usbus7 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > umass0: Get Max Lun not supported (USB_ERR_TIMEOUT) > umass0:0:0:-1: Attached to scbus0 > > Adding NO_GETMAXLUN quirk: > umass0: > on usbus7 > umass0: SCSI over Bulk-Only; quirks = 0x0100 > umass0:0:0:-1: Attached to scbus0 > > The same reader works on windows with 'Generic USB Mass Storage' driver > and in the chip documentation I found that it is 'Compliant with USB > Mass Storage Device Class specifications'. > > May be something is handled differently? I don't know. Maybe your device needs some special command before it responds. --HPS From zoleg at vusovich.ru Fri Nov 13 10:57:04 2009 From: zoleg at vusovich.ru (Oleg Zharkoy) Date: Fri Nov 13 10:57:13 2009 Subject: amr driver issues in FreeBSD 7.2-amd64 and 8.0RC2-amd64: data coruption on RAID volume connected to Intel SRCS16 controller with more 2G RAM Message-ID: The amr driver contains a bug which can lead to data corruption on x64 with >2GB RAM in case of high I/O load with the Intel SRCS16 RAID controller. On system console and in /var/log/messages i see: Oct 31 19:01:54 ns kernel: g_vfs_done():amrd0s1d[READ(offset=1410197177638684672, length=8192)]error = 5 Oct 31 19:01:54 ns kernel: g_vfs_done():amrd0s1d[READ(offset=-6789833140853884928, length=8192)]error = 5 Oct 31 19:01:54 ns kernel: g_vfs_done():amrd0s1d[READ(offset=-6340316514251257856, length=8192)]error = 5 Oct 31 19:01:54 ns kernel: g_vfs_done():amrd0s1d[READ(offset=-1604222101744628736, length=8192)]error = 5 Oct 31 19:01:54 ns kernel: g_vfs_done():amrd0s1d[READ(offset=1512330144284542976, length=8192)]error = 5 Oct 31 19:01:54 ns kernel: g_vfs_done():amrd0s1d[READ(offset=6938750517802503168, length=8192)]error = 5 Oct 31 19:01:54 ns kernel: g_vfs_done():amrd0s1d[READ(offset=1355641023730907136, length=8192)]error = 5 Oct 31 19:01:54 ns kernel: g_vfs_done():amrd0s1d[READ(offset=1410197177638684672, length=8192)]error = 5 Oct 31 19:01:54 ns kernel: g_vfs_done():amrd0s1d[READ(offset=-6789833140853884928, length=8192)]error = 5 Oct 31 19:01:54 ns kernel: g_vfs_done():amrd0s1d[READ(offset=-6340316514251257856, length=8192)]error = 5 Oct 31 19:01:54 ns kernel: g_vfs_done():amrd0s1d[READ(offset=-1604222101744628736, length=8192)]error = 5 Oct 31 19:01:54 ns kernel: g_vfs_done():amrd0s1d[READ(offset=1512330144284542976, length=8192)]error = 5 Oct 31 19:01:54 ns kernel: g_vfs_done():amrd0s1d[READ(offset=6938750517802503168, length=8192)]error = 5 Oct 31 19:01:54 ns kernel: g_vfs_done():amrd0s1d[READ(offset=1355641023730907136, length=8192)]error = 5 Oct 31 19:01:54 ns kernel: g_vfs_done():amrd0s1d[READ(offset=-4443450940333174784, length=8192)]error = 5 With 2G RAM or on x86 version no data corruption and no error occured. Kernel config: cpu HAMMER ident MK_MAIN options SCHED_ULE #options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking #options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD # Network Lock Manager #options NFS_ROOT # NFS usable as /, requires NFSCLIENT #options MSDOSFS # MSDOS Filesystem #options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI #options KTRACE # ktrace(1) support #options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev #options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options MAC # TrustedBSD MAC Framework options FLOWTABLE # per-cpu routing cache # Enable 32-bit Linux ABI emulation (requires COMPAT_43 and COMPAT_IA32) options COMPAT_LINUX32 # Enable the linux-like proc filesystem support (requires COMPAT_LINUX32 # and PSEUDOFS) options LINPROCFS #Enable the linux-like sys filesystem support (requires COMPAT_LINUX32 # and PSEUDOFS) options LINSYSFS # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel # CPU frequency control #device cpufreq # Bus support. device acpi device pci # Floppy drives #device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem device amr # AMI MegaRAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver #device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Serial (COM) ports device uart # Generic UART driver # PCI Ethernet NICs. device em # Intel PRO/1000 adapter Gigabit Ethernet Card # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse # USB Ethernet, requires miibus device cdce # Generic USB over Ethernet # # SMB bus # # System Management Bus support is provided by the 'smbus' device. # Access to the SMBus device is via the 'smb' device (/dev/smb*), # which is a child of the 'smbus' device. # # Supported devices: # smb standard I/O through /dev/smb* # # Supported SMB interfaces: # iicsmb I2C to SMB bridge with any iicbus interface # bktr brooktree848 I2C hardware interface # intpm Intel PIIX4 (82371AB, 82443MX) Power Management Unit # alpm Acer Aladdin-IV/V/Pro2 Power Management Unit # ichsmb Intel ICH SMBus controller chips (82801AA, 82801AB, 82801BA) # viapm VIA VT82C586B/596B/686A and VT8233 Power Management Unit # amdpm AMD 756 Power Management Unit # amdsmb AMD 8111 SMBus 2.0 Controller # nfpm NVIDIA nForce Power Management Unit # nfsmb NVIDIA nForce2/3/4 MCP SMBus 2.0 Controller # device smb device smbus # Bus support, required for smb below. device ipmi device ichsmb # # I2C Bus # # Philips i2c bus support is provided by the `iicbus' device. # # Supported devices: # ic i2c network interface # iic i2c standard io # iicsmb i2c to smb bridge. Allow i2c i/o with smb commands. # # Supported interfaces: # bktr brooktree848 I2C software interface # # Other: # iicbb generic I2C bit-banging code (needed by lpbb, bktr) # device iicbus # Bus support, required for ic/iic/iicsmb below. device iicbb device ic device iic device iicsmb # smb over i2c bridge # # Temperature sensors: # # coretemp: on-die sensor on Intel Core and newer CPUs # k8temp: on-die sensor on AMD K8 CPUs # device coretemp # mchain library. It can be either loaded as KLD or compiled into kernel options LIBMCHAIN # libalias library, performing NAT options LIBALIAS # # Internet family options: # # MROUTING enables the kernel multicast packet forwarder, which works # with mrouted and XORP. # # IPFIREWALL enables support for IP firewall construction, in # conjunction with the `ipfw' program. IPFIREWALL_VERBOSE sends # logged packets to the system logger. IPFIREWALL_VERBOSE_LIMIT # limits the number of times a matching entry can be logged. # # WARNING: IPFIREWALL defaults to a policy of "deny ip from any to any" # and if you do not add other rules during startup to allow access, # YOU WILL LOCK YOURSELF OUT. It is suggested that you set firewall_type=open # in /etc/rc.conf when first enabling this feature, then refining the # firewall rules in /etc/rc.firewall after you've tested that the new kernel # feature works properly. # # IPFIREWALL_DEFAULT_TO_ACCEPT causes the default rule (at boot) to # allow everything. Use with care, if a cracker can crash your # firewall machine, they can get to your protected machines. However, # if you are using it as an as-needed filter for specific problems as # they arise, then this may be for you. Changing the default to 'allow' # means that you won't get stuck if the kernel and /sbin/ipfw binary get # out of sync. # # IPDIVERT enables the divert IP sockets, used by ``ipfw divert''. It # depends on IPFIREWALL if compiled into the kernel. # # IPFIREWALL_FORWARD enables changing of the packet destination either # to do some sort of policy routing or transparent proxying. Used by # ``ipfw forward''. All redirections apply to locally generated # packets too. Because of this great care is required when # crafting the ruleset. # # IPFIREWALL_NAT adds support for in kernel nat in ipfw, and it requires # LIBALIAS. To build an ipfw kld with nat support enabled, add # "CFLAGS+= -DIPFIREWALL_NAT" to your make.conf. # # IPSTEALTH enables code to support stealth forwarding (i.e., forwarding # packets without touching the TTL). This can be useful to hide firewalls # from traceroute and similar tools. # # TCPDEBUG enables code which keeps traces of the TCP state machine # for sockets with the SO_DEBUG option set, which can then be examined # using the trpt(8) utility. # #options MROUTING # Multicast routing options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options IPFIREWALL_FORWARD #packet destination changes options IPFIREWALL_NAT #ipfw kernel nat support options IPDIVERT #divert sockets options IPFILTER #ipfilter support options IPFILTER_LOG #ipfilter logging options IPFILTER_LOOKUP #ipfilter pools #options IPFILTER_DEFAULT_BLOCK #block all packets by default options IPSTEALTH #support for stealth forwarding # The MBUF_STRESS_TEST option enables options which create # various random failures / extreme cases related to mbuf # functions. See mbuf(9) for a list of available test cases. #options MBUF_STRESS_TEST # Statically Link in accept filters options ACCEPT_FILTER_DATA options ACCEPT_FILTER_HTTP # TCP_SIGNATURE adds support for RFC 2385 (TCP-MD5) digests. These are # carried in TCP option 19. This option is commonly used to protect # TCP sessions (e.g. BGP) where IPSEC is not available nor desirable. # This is enabled on a per-socket basis using the TCP_MD5SIG socket option. # This requires the use of 'device crypto', 'options IPSEC' # or 'device cryptodev'. #options TCP_SIGNATURE #include support for RFC 2385 # DUMMYNET enables the "dummynet" bandwidth limiter. You need IPFIREWALL # as well. See dummynet(4) and ipfw(8) for more info. When you run # DUMMYNET it is advisable to also have "options HZ=1000" to achieve a # smoother scheduling of the traffic. options DUMMYNET options HZ=1000 # Zero copy sockets support. This enables "zero copy" for sending and # receiving data via a socket. The send side works for any type of NIC, # the receive side only works for NICs that support MTUs greater than the # page size of your architecture and that support header splitting. See # zero_copy(9) for more details. #options ZERO_COPY_SOCKETS # netgraph(4). Enable the base netgraph code with the NETGRAPH option. # Individual node types can be enabled with the corresponding option # listed below; however, this is not strictly necessary as netgraph # will automatically load the corresponding KLD module if the node type # is not already compiled into the kernel. Each type below has a # corresponding man page, e.g., ng_async(8). options NETGRAPH # netgraph(4) system # In order to enable IPSEC you MUST also add device crypto to # your kernel configuration options IPSEC #IP security (requires device crypto) device crypto dmesg.boot: 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-RC2 #0: Sat Oct 31 20:01:37 IRKT 2009 root at ns.mk.local:/usr/obj/usr/src/sys/mk64-8 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU E5345 @ 2.33GHz (2339.14-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f7 Stepping = 7 Features=0xbfebfbff Features2=0x4e3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2055802880 (1960 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed 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 ipmi0: port 0xca2,0xca3 on acpi0 ipmi0: KCS mode found at io 0xca2 on acpi acpi_button0: on acpi0 pcib0: port 0xca2,0xca3,0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: irq 17 at device 1.0 on pci2 pci4: on pcib4 pcib5: irq 18 at device 2.0 on pci2 pci5: on pcib5 em0: port 0x2020-0x203f mem 0xb8820000-0xb883ffff,0xb8400000-0xb87fffff irq 18 at device 0.0 on pci5 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:53:6c:a8 em1: port 0x2000-0x201f mem 0xb8800000-0xb881ffff,0xb8000000-0xb83fffff irq 19 at device 0.1 on pci5 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:15:17:53:6c:a9 pcib6: at device 0.3 on pci1 pci6: on pcib6 amr0: mem 0xb8a00000-0xb8a0ffff irq 24 at device 1.0 on pci6 amr0: Using 64-bit DMA amr0: [ITHREAD] amr0: Firmware 713S, BIOS G401, 64MB RAM pcib7: at device 3.0 on pci0 pci7: on pcib7 pci0: at device 8.0 (no driver attached) pcib8: irq 16 at device 28.0 on pci0 pci8: on pcib8 uhci0: port 0x30a0-0x30bf irq 23 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: on uhci0 uhci1: port 0x3080-0x309f irq 22 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: on uhci1 uhci2: port 0x3060-0x307f irq 23 at device 29.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2: on uhci2 uhci3: port 0x3040-0x305f irq 22 at device 29.3 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x2f00 usbus3: on uhci3 ehci0: mem 0xb8c00400-0xb8c007ff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib9: at device 30.0 on pci0 pci9: on pcib9 vgapci0: port 0x1000-0x10ff mem 0xb0000000-0xb7ffffff,0xb8b00000-0xb8b0ffff irq 17 at device 12.0 on pci9 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30c0-0x30cf irq 20 at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] atapci1: port 0x30d8-0x30df,0x30f4-0x30f7,0x30d0-0x30d7,0x30f0-0x30f3,0x3020-0x303f mem 0xb8c00000-0xb8c003ff irq 20 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI called from vendor specific driver atapci1: AHCI v1.10 controller with 6 3Gbps ports, PM supported ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] ata6: on atapci1 ata6: [ITHREAD] ata7: on atapci1 ata7: [ITHREAD] ichsmb0: port 0x3000-0x301f irq 20 at device 31.3 on pci0 ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 atrtc0: port 0x70-0x71,0x74-0x77 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] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 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 device_attach: acpi_perf0 attach returned 6 acpi_throttle0: on cpu0 device_attach: acpi_perf0 attach returned 6 coretemp0: on cpu0 cpu1: on acpi0 device_attach: acpi_perf1 attach returned 6 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 device_attach: acpi_perf1 attach returned 6 coretemp1: on cpu1 cpu2: on acpi0 device_attach: acpi_perf2 attach returned 6 acpi_throttle2: on cpu2 acpi_throttle2: failed to attach P_CNT device_attach: acpi_throttle2 attach returned 6 device_attach: acpi_perf2 attach returned 6 coretemp2: on cpu2 cpu3: on acpi0 device_attach: acpi_perf3 attach returned 6 acpi_throttle3: on cpu3 acpi_throttle3: failed to attach P_CNT device_attach: acpi_throttle3 attach returned 6 device_attach: acpi_perf3 attach returned 6 coretemp3: on cpu3 ipmi1: on isa0 device_attach: ipmi1 attach returned 16 ipmi1: on isa0 device_attach: ipmi1 attach returned 16 orm0: at iomem 0xc0000-0xc8fff 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 Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. IP Filter: v4.1.28 initialized. Default = pass all, Logging = enabled ipfw2 initialized, divert enabled, nat enabled, rule-based forwarding enabled, default to accept, logging disabled usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ad4: 305245MB at ata2-master SATA300 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 ipmi0: IPMI device rev. 1, firmware rev. 0.2, version 2.0 ipmi0: Number of channels 5 ipmi0: Attached watchdog amrd0: on amr0 amrd0: 953674MB (1953124352 sectors) RAID 1 (optimal) lapic1: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! lapic2: Forcing LINT1 to edge trigger SMP: AP CPU #2 Launched! lapic3: Forcing LINT1 to edge trigger SMP: AP CPU #3 Launched! Root mount waiting for: usbus4 usbus3 usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 uhub4: 8 ports with 8 removable, self powered Trying to mount root from ufs:/dev/ad4s1a Please help resolve this trouble. Thanks! From patpro at patpro.net Fri Nov 13 14:36:36 2009 From: patpro at patpro.net (Patrick Proniewski) Date: Fri Nov 13 14:36:44 2009 Subject: Adaptec 1405 on FreeBSD Message-ID: Hello, I'm looking for a cheap non-RAID SATA II PCIe card, with 4 SATA ports, to plug into a FreeBSD 6.4 box. The Adaptec 1405 (ASC-1405) seems perfect to me, but it also seems unsupported by FreeBSD. The Adaptec web site is not sure about the support either: FreeBSD supported according to the en-GB description: FreeBSD unsupported according to en-US description: Any idea about the FreeBSD support for Adaptec 1405 (ASC-1405)? Any PCIe card suggestion is appreciated. regards, pat From mav at FreeBSD.org Fri Nov 13 20:00:49 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Fri Nov 13 20:00:55 2009 Subject: Adaptec 1405 on FreeBSD In-Reply-To: <1258136580.00183277.1258123203@10.7.7.3> References: <1258136580.00183277.1258123203@10.7.7.3> Message-ID: <4AFDBAEB.2020903@FreeBSD.org> Patrick Proniewski wrote: > Any idea about the FreeBSD support for Adaptec 1405 (ASC-1405)? I doubt. It is more SAS then SATA card. > Any PCIe card suggestion is appreciated. FreeBSD 6.x is already legacy. If you are building something new, you should look forward. What I have tested: - SiI3124-based - fast and functional. It is actually PCI-X one, but there are many boards with built-in PCIe bridges. - two SiI3132-based (Adaptec 1420SA and many others) - as cheap PCIe x1 alternative (max 150MB/s per card). These two better supported with new siis(4) driver on 8.0, but should work on 7.x with ata(4), haven't looked lower. - First generation of SiI chips (SiI3114). They are quite old - SATA1 and PCI, but they are long-time supported and they take all possible from PCI bus, and in 66MHz PCI-X slot can give even more. But I have heard some negative comments about them. - Supermicro SAT2-MV8 on Marvell - recently tested it on 8.0, supported in 7.x and probably before. Adaptec 1420SA is from the same series. But they are PCI-X (tested it in PCI). - Adaptec 1430SA - PCIe, based on newer Marvell chip. Added basic support recently to 8-STABLE. Not supported before. - most of chipset-integrated controllers (Intel, NVidia) are really not bad when working in AHCI mode (they are not limited by bus speed). - JMicron-based PCIe x1 adapters. They are cheap, AHCI-compatible and not so bad, but limited by bus speed at about 180MB/s per card. -- Alexander Motin From mav at FreeBSD.org Fri Nov 13 20:03:57 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Fri Nov 13 20:04:03 2009 Subject: Adaptec 1405 on FreeBSD In-Reply-To: <4AFDBAEB.2020903@FreeBSD.org> References: <1258136580.00183277.1258123203@10.7.7.3> <4AFDBAEB.2020903@FreeBSD.org> Message-ID: <4AFDBBA7.8010505@FreeBSD.org> Alexander Motin wrote: > Patrick Proniewski wrote: >> Any idea about the FreeBSD support for Adaptec 1405 (ASC-1405)? > > I doubt. It is more SAS then SATA card. > >> Any PCIe card suggestion is appreciated. > > FreeBSD 6.x is already legacy. If you are building something new, you > should look forward. What I have tested: > - SiI3124-based - fast and functional. It is actually PCI-X one, but > there are many boards with built-in PCIe bridges. > - two SiI3132-based (Adaptec 1420SA and many others) - as cheap PCIe x1 Oops, I meant Adaptec 1220SA here ^^^. > alternative (max 150MB/s per card). These two better supported with new > siis(4) driver on 8.0, but should work on 7.x with ata(4), haven't > looked lower. > - First generation of SiI chips (SiI3114). They are quite old - SATA1 > and PCI, but they are long-time supported and they take all possible > from PCI bus, and in 66MHz PCI-X slot can give even more. But I have > heard some negative comments about them. > - Supermicro SAT2-MV8 on Marvell - recently tested it on 8.0, supported > in 7.x and probably before. Adaptec 1420SA is from the same series. But > they are PCI-X (tested it in PCI). > - Adaptec 1430SA - PCIe, based on newer Marvell chip. Added basic > support recently to 8-STABLE. Not supported before. > - most of chipset-integrated controllers (Intel, NVidia) are really not > bad when working in AHCI mode (they are not limited by bus speed). > - JMicron-based PCIe x1 adapters. They are cheap, AHCI-compatible and > not so bad, but limited by bus speed at about 180MB/s per card. -- Alexander Motin From patpro at patpro.net Fri Nov 13 22:02:23 2009 From: patpro at patpro.net (Patrick Proniewski) Date: Fri Nov 13 22:02:29 2009 Subject: Adaptec 1405 on FreeBSD In-Reply-To: <4AFDBAEB.2020903@FreeBSD.org> References: <1258136580.00183277.1258123203@10.7.7.3> <4AFDBAEB.2020903@FreeBSD.org> Message-ID: <076E30DA-0FFC-4FA7-B14E-16918563BEE1@patpro.net> On 13 nov. 2009, at 21:00, Alexander Motin wrote: > Patrick Proniewski wrote: >> Any idea about the FreeBSD support for Adaptec 1405 (ASC-1405)? > > I doubt. It is more SAS then SATA card. As far as I can say, SAS controler are SATA compliant. In this particular case, the description from Adaptec reads "Cost- effective I/O supporting SATA and SAS". That's fine, if I can upgrade to SAS HDs later, it's a cool feature. >> Any PCIe card suggestion is appreciated. > > FreeBSD 6.x is already legacy. If you are building something new, you > should look forward. I know, but 8 is not ready, and I don't see the point in upgrading to 7. And more importantly, I own a second server, hosted in a datacenter: I try to keep OS version synchronised, so that I can test buildkernel/buildworld/install on my local computer before trying the update on the (very) distant server. > What I have tested: > - SiI3124-based - fast and functional. It is actually PCI-X one, but > there are many boards with built-in PCIe bridges. > - two SiI3132-based (Adaptec 1420SA and many others) - as cheap PCIe > x1 > alternative (max 150MB/s per card). These two better supported with > new > siis(4) driver on 8.0, but should work on 7.x with ata(4), haven't > looked lower. > - First generation of SiI chips (SiI3114). They are quite old - SATA1 > and PCI, but they are long-time supported and they take all possible > from PCI bus, and in 66MHz PCI-X slot can give even more. But I have > heard some negative comments about them. > - Supermicro SAT2-MV8 on Marvell - recently tested it on 8.0, > supported > in 7.x and probably before. Adaptec 1420SA is from the same series. > But > they are PCI-X (tested it in PCI). > - Adaptec 1430SA - PCIe, based on newer Marvell chip. Added basic > support recently to 8-STABLE. Not supported before. > - most of chipset-integrated controllers (Intel, NVidia) are really > not > bad when working in AHCI mode (they are not limited by bus speed). > - JMicron-based PCIe x1 adapters. They are cheap, AHCI-compatible and > not so bad, but limited by bus speed at about 180MB/s per card. PCI-x and PCI are not an option for me. In fact, everything comes from the fact my system behaves strangely from time to time. Long explanation here: http://lists.freebsd.org/pipermail/freebsd-hardware/2007-June/004541.html This problem disappeared for a long time, but came back just today. My wifi card is PCI, and according to the motherboard setup, PCI bus is on the same controller as on board SATA (with PCI-X too). The only slots that sit on a different chip are the two PCIe. I think that if I could move my HDs on the PCIe buses, it might resolve my problem. Even if it does solve this issue, it'll give me SATA II, in replacement of SATA I motherboard connectors. Either way, I win :) pat From mav at FreeBSD.org Fri Nov 13 22:28:04 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Fri Nov 13 22:28:10 2009 Subject: Adaptec 1405 on FreeBSD In-Reply-To: <076E30DA-0FFC-4FA7-B14E-16918563BEE1@patpro.net> References: <1258136580.00183277.1258123203@10.7.7.3> <4AFDBAEB.2020903@FreeBSD.org> <076E30DA-0FFC-4FA7-B14E-16918563BEE1@patpro.net> Message-ID: <4AFDDD6F.9000607@FreeBSD.org> Patrick Proniewski wrote: > PCI-x and PCI are not an option for me. > In fact, everything comes from the fact my system behaves strangely from > time to time. > Long explanation here: > http://lists.freebsd.org/pipermail/freebsd-hardware/2007-June/004541.html > > This problem disappeared for a long time, but came back just today. My > wifi card is PCI, and according to the motherboard setup, PCI bus is on > the same controller as on board SATA (with PCI-X too). The only slots > that sit on a different chip are the two PCIe. I think that if I could > move my HDs on the PCIe buses, it might resolve my problem. Even if it > does solve this issue, it'll give me SATA II, in replacement of SATA I > motherboard connectors. Either way, I win :) I am not sure it is productive way. There is too many assumptions. Even if it fix problems with disk, I am not sure your WiFi will work after that. Even if assume that problem is localized inside south bridge (you can't know that), there could be problems with other devices (LAN, for example). What's about changing SATA1 with SATA2 - I think you won't notice any difference. Most of disks are not so fast to congest SATA1, while other bonuses like NCQ are not supported by 6.4 any way. -- Alexander Motin From patpro at patpro.net Fri Nov 13 23:03:55 2009 From: patpro at patpro.net (Patrick Proniewski) Date: Fri Nov 13 23:04:01 2009 Subject: Adaptec 1405 on FreeBSD In-Reply-To: <4AFDDD6F.9000607@FreeBSD.org> References: <1258136580.00183277.1258123203@10.7.7.3> <4AFDBAEB.2020903@FreeBSD.org> <076E30DA-0FFC-4FA7-B14E-16918563BEE1@patpro.net> <4AFDDD6F.9000607@FreeBSD.org> Message-ID: <65126F85-DCCF-4B65-B415-8B2CFF100090@patpro.net> On 13 nov. 2009, at 23:27, Alexander Motin wrote: > I am not sure it is productive way. There is too many assumptions. > Even > if it fix problems with disk, I am not sure your WiFi will work after > that. Even if assume that problem is localized inside south bridge > (you > can't know that), there could be problems with other devices (LAN, for > example). Yep, I know that, but I've ask for help many times, and nobody was able to help me. May be this problem is too complex, or may be next time I should buy less exotic hardware (TYAN Tiger i7520SD is not what I would call a mainstream motherboard). > What's about changing SATA1 with SATA2 - I think you won't notice any > difference. Most of disks are not so fast to congest SATA1, while > other > bonuses like NCQ are not supported by 6.4 any way. oh crap. No NCQ ? But well, I'm planning a migration to 8.x during next year, for both local and remote servers (and new hardware for the remote server). pat From david at catwhisker.org Sat Nov 14 05:39:29 2009 From: david at catwhisker.org (David Wolfskill) Date: Sat Nov 14 05:39:45 2009 Subject: Msg: no prefetched decode (going from stable/6 -> stable/7) Message-ID: <20091114052429.GF1649@albert.catwhisker.org> I admit that I don't know what "no prefetched decode" means in this context, or what I can or should do about it. But the same hardware running stable/6 does not issue that whine, and the laptop in question does see the additional PCI devices on the docking station when running stable/6, but issues the above whine, and fails to "see" the additional PCI devices in the docking station running any of stable/7, stable/8, or head (9.0-CURRENT). And while there are certainly advances in many respects in going to newer versions of FreeBSD, I'm a little hard-pressed to understand how this qualifies. :-} A bit of background: My laptop is parts from 3 Dell laptops -- 2 Inspiron 8200s and 1 Latitude C840. I use the FreeBSD bootloader, and have 4 distinct bootable slices on the disk. At this time: * slice 1: / and /usr for stable/6 * slice 2: / and /usr for stable/7 * slice 4: / and /usr for stable/8 * slice 4: / and /usr for head (9.0-CURRENT); also swap, as well as a few other partitions (e.g., /var) that are mounted to the same place regardless of which slice is booted. For last night's BAFUG meeting, Julian had volunteered to demonstrate vimage. He needed access to a machine running stable/8 or head with multiple NICs. I volunteered the use of my laptop, as it has a couple of NICs in its chassis, and I recalled that when I had run stable/6, FreeBSD saw the wired NIC in the docking station. So I brought a couple of PCI NICs to stick in the dockinig station, figuring that would give us 5 NICs (not counting Firewire -- or anything I could shove in a PCCard slot), which should be adequate. But as I was building stable/8 (running stable/7 at teh time), I noticed that "ifconfig" output didn't show the additional 3 NICs. So this evening, I booted each of the slices in turn to single user mode, then (in each case) entered: * fsck -p && mount -a * csh * uname -a >/var/tmp/pciconf.N * pciconf -lv >>!$ * dmesg >/vat/tmp/dmesg.N (where "N" was one of "6", "7", "8", or "9", according to the version of FreeBSD being run at the time). I've attached the resulting files. Here's the tail end of diff -u pciconf.{6,7}: ... -iwi0@pci2:3:0: class=0x028000 card=0x27218086 chip=0x42208086 rev=0x05 hdr=0x00 +iwi0@pci0:2:3:0: class=0x028000 card=0x27218086 chip=0x42208086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' - device = 'MPCI3B driverIntel PRO/Wireless 2200BG' + device = 'driverIntel PRO/Wireless 2200BG (MPCI3B)' class = network -pcib3@pci2:12:0: class=0x060400 card=0x00000000 chip=0x00221011 rev=0x04 hdr=0x01 +pcib3@pci0:2:12:0: class=0x060400 card=0x00000000 chip=0x00221011 rev=0x04 hdr=0x01 vendor = 'Digital Equipment Corporation' - device = '21150-AA PCI to PCI Bridge' + device = 'PCI-PCI Bridge (DC21150-AA)' class = bridge subclass = PCI-PCI -xl1@pci3:1:0: class=0x020000 card=0x905510b7 chip=0x905510b7 rev=0x30 hdr=0x00 - vendor = '3COM Corp, Networking Division' - device = '3C905-TX Fast Etherlink 10/100 PCI TX NIC' - class = network - subclass = ethernet -dc0@pci3:2:0: class=0x020000 card=0xf0041385 chip=0x000211ad rev=0x20 hdr=0x00 - vendor = 'Lite-On Communications Inc' - device = 'KNE110TX Kingston EtheRx KNE110TX PCI Fast Ethernet Adapter' - class = network - subclass = ethernet -atapci0@pci3:5:0: class=0x01018f card=0x06461095 chip=0x06461095 rev=0x07 hdr=0x00 - vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' - device = 'PCI-0646 EIDE Adapter (Single FIFO)' - class = mass storage - subclass = ATA -ahc0@pci3:7:0: class=0x010000 card=0x78809004 chip=0x80789004 rev=0x01 hdr=0x00 - vendor = 'Adaptec Inc' - device = 'AIC-7880P Ultra/Ultra Wide SCSI Chipset' - class = mass storage - subclass = SCSI -xl2@pci3:8:0: class=0x020000 card=0x00a81028 chip=0x920010b7 rev=0x6c hdr=0x00 - vendor = '3COM Corp, Networking Division' - device = '3C905 CX-TX-M Fast EtherLink for PC Management NIC' - class = network - subclass = ethernet And here's the part of the output from "diff -u dmesg.{6,7}" that inspired the Subject: ... @@ -381,172 +412,34 @@ iwi0: bpf attached iwi0: bpf attached iwi0: [MPSAFE] +iwi0: [ITHREAD] iwi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps pcib3: at device 12.0 on pci2 +pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xf000-0xffff pcib3: memory decode 0xfa000000-0xfbffffff -pcib3: prefetched decode 0xfff00000-0xfffff -ACPI: Found matching pin for 3.5.INTA at func 0: 11 -ACPI: Found matching pin for 3.1.INTA at func 0: 11 -ACPI: Found matching pin for 3.2.INTA at func 0: 11 -ACPI: Found matching pin for 3.7.INTA at func 0: 11 -ACPI: Found matching pin for 3.8.INTA at func 0: 11 +pcib3: no prefetched decode pci3: on pcib3 -pci3: physical bus=3 -found-> vendor=0x10b7, dev=0x9055, revid=0x30 - bus=3, slot=1, func=0 - class=02-00-00, hdrtype=0x00, mfdev=0 - cmdreg=0x0117, statreg=0x0210, cachelnsz=8 (dwords) - lattimer=0x20 (960 ns), mingnt=0x0a (2500 ns), maxlat=0x0a (2500 ns) - intpin=a, irq=11 - powerspec 1 supports D0 D1 D2 D3 current D0 - map[10]: type 4, range 32, base 0000fc80, size 7, enabled -pcib3: requested I/O range 0xfc80-0xfcff: in range -pcib2: requested I/O range 0xfc80-0xfcff: in range - map[14]: type 1, range 32, base fafffc00, size 7, enabled -pcib3: requested memory range 0xfafffc00-0xfafffc7f: good -pcib2: requested memory range 0xfafffc00-0xfafffc7f: good -pcib3: matched entry for 3.1.INTA (src \\_SB_.PCI0.LNKC:0) -pcib3: slot 1 INTA routed to irq 11 via \\_SB_.PCI0.LNKC -found-> vendor=0x11ad, dev=0x0002, revid=0x20 - bus=3, slot=2, func=0 - class=02-00-00, hdrtype=0x00, mfdev=0 - cmdreg=0x0107, statreg=0x0280, cachelnsz=0 (dwords) - lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) - intpin=a, irq=11 - map[10]: type 4, range 32, base 0000f800, size 8, enabled -pcib3: requested I/O range 0xf800-0xf8ff: in range -pcib2: requested I/O range 0xf800-0xf8ff: in range - map[14]: type 1, range 32, base fafff800, size 8, enabled -pcib3: requested memory range 0xfafff800-0xfafff8ff: good -pcib2: requested memory range 0xfafff800-0xfafff8ff: good -pcib3: matched entry for 3.2.INTA (src \\_SB_.PCI0.LNKC:0) -pcib3: slot 2 INTA routed to irq 11 via \\_SB_.PCI0.LNKC -found-> vendor=0x1095, dev=0x0646, revid=0x07 - bus=3, slot=5, func=0 - class=01-01-8f, hdrtype=0x00, mfdev=0 - cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) - lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) - intpin=a, irq=11 - powerspec 1 supports D0 D1 D2 D3 current D0 - map[10]: type 4, range 32, base 0000fc78, size 3, enabled -pcib3: requested I/O range 0xfc78-0xfc7f: in range -pcib2: requested I/O range 0xfc78-0xfc7f: in range - map[14]: type 4, range 32, base 0000fc70, size 2, enabled -pcib3: requested I/O range 0xfc70-0xfc73: in range -pcib2: requested I/O range 0xfc70-0xfc73: in range - map[18]: type 4, range 32, base 0000fc60, size 3, enabled -pcib3: requested I/O range 0xfc60-0xfc67: in range -pcib2: requested I/O range 0xfc60-0xfc67: in range - map[1c]: type 4, range 32, base 0000fc58, size 2, enabled -pcib3: requested I/O range 0xfc58-0xfc5b: in range -pcib2: requested I/O range 0xfc58-0xfc5b: in range - map[20]: type 4, range 32, base 0000fc40, size 4, enabled -pcib3: requested I/O range 0xfc40-0xfc4f: in range -pcib2: requested I/O range 0xfc40-0xfc4f: in range -pcib3: matched entry for 3.5.INTA (src \\_SB_.PCI0.LNKC:0) -pcib3: slot 5 INTA routed to irq 11 via \\_SB_.PCI0.LNKC -found-> vendor=0x9004, dev=0x8078, revid=0x01 - bus=3, slot=7, func=0 - class=01-00-00, hdrtype=0x00, mfdev=0 - cmdreg=0x0117, statreg=0x0290, cachelnsz=8 (dwords) - lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x08 (2000 ns) - intpin=a, irq=11 - powerspec 1 supports D0 D3 current D0 - map[10]: type 4, range 32, base 0000f000, size 8, enabled -pcib3: requested I/O range 0xf000-0xf0ff: in range -pcib2: requested I/O range 0xf000-0xf0ff: in range - map[14]: type 1, range 32, base faffe000, size 12, enabled -pcib3: requested memory range 0xfaffe000-0xfaffefff: good -pcib2: requested memory range 0xfaffe000-0xfaffefff: good -pcib3: matched entry for 3.7.INTA (src \\_SB_.PCI0.LNKC:0) -pcib3: slot 7 INTA routed to irq 11 via \\_SB_.PCI0.LNKC -found-> vendor=0x10b7, dev=0x9200, revid=0x6c - bus=3, slot=8, func=0 - class=02-00-00, hdrtype=0x00, mfdev=0 - cmdreg=0x0117, statreg=0x0210, cachelnsz=8 (dwords) - lattimer=0x20 (960 ns), mingnt=0x0a (2500 ns), maxlat=0x0a (2500 ns) - intpin=a, irq=11 - powerspec 2 supports D0 D1 D2 D3 current D0 - map[10]: type 4, range 32, base 0000f400, size 7, enabled -pcib3: requested I/O range 0xf400-0xf47f: in range -pcib2: requested I/O range 0xf400-0xf47f: in range - map[14]: type 1, range 32, base fafff400, size 7, enabled -pcib3: requested memory range 0xfafff400-0xfafff47f: good -pcib2: requested memory range 0xfafff400-0xfafff47f: good -pcib3: matched entry for 3.8.INTA (src \\_SB_.PCI0.LNKC:0) -pcib3: slot 8 INTA routed to irq 11 via \\_SB_.PCI0.LNKC -xl1: <3Com 3c905B-TX Fast Etherlink XL> port 0xfc80-0xfcff mem 0xfafffc00-0xfafffc7f irq 11 at device 1.0 on pci3 -xl1: Reserved 0x80 bytes for rid 0x14 type 3 at 0xfafffc00 -xl1: using memory mapped I/O -xl1: media options word: a -xl1: found MII/AUTO -miibus1: on xl1 -xlphy0: <3Com internal media interface> on miibus1 -xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto -xl1: bpf attached -xl1: Ethernet address: 00:50:da:23:e6:d2 -xl1: [MPSAFE] .... I realize this isn't The End Of The World As We Know It -- and Julian was able to demo vimage with only 2 NICs showing up -- but I would rather prefer to be able to make use of the docking station without running FreEBSD 6.x to do so. [I set Reply-To because I'm (still) not subscribe to -hardware@.] Clues? Thanks! Peace, david -- David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hardware/attachments/20091114/b6e1dda1/attachment-0001.pgp From david at catwhisker.org Sat Nov 14 05:39:33 2009 From: david at catwhisker.org (David Wolfskill) Date: Sat Nov 14 05:39:46 2009 Subject: Msg: no prefetched decode (going from stable/6 -> stable/7) In-Reply-To: <20091114052429.GF1649@albert.catwhisker.org> References: <20091114052429.GF1649@albert.catwhisker.org> Message-ID: <20091114053103.GG1649@albert.catwhisker.org> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hardware/attachments/20091114/a538ecfe/attachment-0001.pgp From 000.fbsd at quip.cz Sat Nov 14 21:09:00 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Sat Nov 14 21:09:06 2009 Subject: Curiously unable to access network - bce, 7.2-RELEASE on a HP blade server In-Reply-To: References: Message-ID: <4AFF17FF.9020802@quip.cz> Ivan Voras wrote: > I forgot to attach hardware details: > > bce0: HP NC373i Multifunction Gigabit Server Adapter (B2) ASIC > 0x57081021 Rev B2 B/C 0x04040105 Flags 2.5G > > Additional data point: I cannot reconfigure the card to 100 Mbit > operation (currently in 1000baseSX autoselect, full-duplex). > > Ivan Voras wrote: >> The symptoms are: >> >> * The device (bce0, bce1) comes up, is visible in ifconfig, can be >> configured, is UP and RUNNING, everything looks fine >> * Apparently, it simply doesn't work - no ping responses, TCP, nothing >> * But tcpdump shows that the NIC apparently does receive multicast >> router announcements, and some broadcast ARP traffic; only unicast >> seems to be affected. >> * Running "netstat 1" shows that apparently there are some packets >> received - once a second or so, and the "err" counters are 0. >> * Digging further, the dev.bce.0.stat_IfinFramesL2FilterDiscards >> contains an increasing number, currently arround 57000 and the >> dev.bce.0.stat_IfHCInBadOctets also contains an increasing number, >> currently around 450,000, while ...InOctets is around 30,000 and >> ...OutBadOctets is 0. >> >> From the sysctls it looks like maybe it's discarding valid input >> packets. I've tried disabling rxcsum, txcsum and TSO without effect. >> >> I cannot upgrade or install 8.0 because newusb has some problems with >> the hardware. >> >> Any ideas? Can it be related to this PR 134788? http://www.freebsd.org/cgi/query-pr.cgi?pr=134788 (your problem sounds different, but anyway you can try 7-STABLE bce driver) Recent changes in bce driver fixed it for me. Miroslav Lachman From ivoras at freebsd.org Sat Nov 14 21:26:31 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Sat Nov 14 21:26:38 2009 Subject: Curiously unable to access network - bce, 7.2-RELEASE on a HP blade server In-Reply-To: <4AFF17FF.9020802@quip.cz> References: <4AFF17FF.9020802@quip.cz> Message-ID: <9bbcef730911141257w4d7b7f1tc3fb18c5bdcfe57a@mail.gmail.com> 2009/11/14 Miroslav Lachman <000.fbsd@quip.cz>: > Ivan Voras wrote: >> >> I forgot to attach hardware details: >> >> bce0: HP NC373i Multifunction Gigabit Server Adapter (B2) ASIC >> 0x57081021 Rev B2 B/C 0x04040105 Flags 2.5G >> >> Additional data point: I cannot reconfigure the card to 100 Mbit >> operation (currently in 1000baseSX autoselect, full-duplex). >> >> Ivan Voras wrote: >>> >>> The symptoms are: >>> >>> * The device (bce0, bce1) comes up, is visible in ifconfig, can be >>> configured, is UP and RUNNING, everything looks fine >>> * Apparently, it simply doesn't work - no ping responses, TCP, nothing >>> * But tcpdump shows that the NIC apparently does receive multicast >>> router announcements, and some broadcast ARP traffic; only unicast >>> seems to be affected. >>> * Running "netstat 1" shows that apparently there are some packets >>> received - once a second or so, and the "err" counters are 0. >>> * Digging further, the dev.bce.0.stat_IfinFramesL2FilterDiscards >>> contains an increasing number, currently arround 57000 and the >>> dev.bce.0.stat_IfHCInBadOctets also contains an increasing number, >>> currently around 450,000, while ...InOctets is around 30,000 and >>> ...OutBadOctets is 0. >>> >>> From the sysctls it looks like maybe it's discarding valid input >>> packets. I've tried disabling rxcsum, txcsum and TSO without effect. >>> >>> I cannot upgrade or install 8.0 because newusb has some problems with >>> the hardware. >>> >>> Any ideas? > > Can it be related to this PR 134788? > http://www.freebsd.org/cgi/query-pr.cgi?pr=134788 > (your problem sounds different, but anyway you can try 7-STABLE bce driver) > > Recent changes in bce driver fixed it for me. I did try booting 8.0 and found the same problem (though I cannot install 8.0 because of an unrelated problem with newusb). Judging by the dates in the PR, the fix should also be present in 8. From patpro at patpro.net Sun Nov 15 12:22:33 2009 From: patpro at patpro.net (Patrick Proniewski) Date: Sun Nov 15 12:22:40 2009 Subject: Adaptec 1405 on FreeBSD In-Reply-To: <4AFDBBA7.8010505@FreeBSD.org> References: <1258136580.00183277.1258123203@10.7.7.3> <4AFDBAEB.2020903@FreeBSD.org> <4AFDBBA7.8010505@FreeBSD.org> Message-ID: <511CEEC9-7721-4E51-AD7C-A98E59299F07@patpro.net> On 13 nov. 2009, at 21:03, Alexander Motin wrote: > Alexander Motin wrote: >> Patrick Proniewski wrote: >>> Any PCIe card suggestion is appreciated. >> >> FreeBSD 6.x is already legacy. If you are building something new, you >> should look forward. What I have tested: >> - SiI3124-based - fast and functional. It is actually PCI-X one, but >> there are many boards with built-in PCIe bridges. >> - two SiI3132-based (Adaptec 1420SA and many others) - as cheap >> PCIe x1 > > Oops, I meant Adaptec 1220SA here ^^^. > >> alternative (max 150MB/s per card). These two better supported with >> new >> siis(4) driver on 8.0, but should work on 7.x with ata(4), haven't >> looked lower. >> - First generation of SiI chips (SiI3114). They are quite old - SATA1 >> and PCI, but they are long-time supported and they take all possible >> from PCI bus, and in 66MHz PCI-X slot can give even more. But I have >> heard some negative comments about them. >> - Supermicro SAT2-MV8 on Marvell - recently tested it on 8.0, >> supported >> in 7.x and probably before. Adaptec 1420SA is from the same series. >> But >> they are PCI-X (tested it in PCI). >> - Adaptec 1430SA - PCIe, based on newer Marvell chip. Added basic >> support recently to 8-STABLE. Not supported before. >> - most of chipset-integrated controllers (Intel, NVidia) are really >> not >> bad when working in AHCI mode (they are not limited by bus speed). >> - JMicron-based PCIe x1 adapters. They are cheap, AHCI-compatible and >> not so bad, but limited by bus speed at about 180MB/s per card. I've just found this: Does anybody has given this card a try? Unfortunately I can't find the brand of the chip they are using? pat From mav at FreeBSD.org Sun Nov 15 15:39:03 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sun Nov 15 15:39:09 2009 Subject: Adaptec 1405 on FreeBSD In-Reply-To: <1258298591.00183715.1258288202@10.7.7.3> References: <1258136580.00183277.1258123203@10.7.7.3> <1258154582.00183317.1258143002@10.7.7.3> <1258154581.00183318.1258143002@10.7.7.3> <1258298591.00183715.1258288202@10.7.7.3> Message-ID: <4B002091.4010609@FreeBSD.org> Patrick Proniewski wrote: > On 13 nov. 2009, at 21:03, Alexander Motin wrote: > >> Alexander Motin wrote: >>> Patrick Proniewski wrote: >>>> Any PCIe card suggestion is appreciated. >>> >>> FreeBSD 6.x is already legacy. If you are building something new, you >>> should look forward. What I have tested: >>> - SiI3124-based - fast and functional. It is actually PCI-X one, but >>> there are many boards with built-in PCIe bridges. >>> - two SiI3132-based (Adaptec 1420SA and many others) - as cheap PCIe x1 >> >> Oops, I meant Adaptec 1220SA here ^^^. >> >>> alternative (max 150MB/s per card). These two better supported with new >>> siis(4) driver on 8.0, but should work on 7.x with ata(4), haven't >>> looked lower. >>> - First generation of SiI chips (SiI3114). They are quite old - SATA1 >>> and PCI, but they are long-time supported and they take all possible >>> from PCI bus, and in 66MHz PCI-X slot can give even more. But I have >>> heard some negative comments about them. >>> - Supermicro SAT2-MV8 on Marvell - recently tested it on 8.0, supported >>> in 7.x and probably before. Adaptec 1420SA is from the same series. But >>> they are PCI-X (tested it in PCI). >>> - Adaptec 1430SA - PCIe, based on newer Marvell chip. Added basic >>> support recently to 8-STABLE. Not supported before. >>> - most of chipset-integrated controllers (Intel, NVidia) are really not >>> bad when working in AHCI mode (they are not limited by bus speed). >>> - JMicron-based PCIe x1 adapters. They are cheap, AHCI-compatible and >>> not so bad, but limited by bus speed at about 180MB/s per card. > > I've just found this: > > > Does anybody has given this card a try? > Unfortunately I can't find the brand of the chip they are using? Looking on picture, I would surmise it can be SiI3132, but price is twice bigger then I would expect from that chip. SiI3132-based ST-Lab A-410 controller in my city costs $29. -- Alexander Motin From patpro at patpro.net Sun Nov 15 21:55:07 2009 From: patpro at patpro.net (Patrick Proniewski) Date: Sun Nov 15 21:55:13 2009 Subject: Adaptec 1405 on FreeBSD In-Reply-To: <4B002091.4010609@FreeBSD.org> References: <1258136580.00183277.1258123203@10.7.7.3> <1258154582.00183317.1258143002@10.7.7.3> <1258154581.00183318.1258143002@10.7.7.3> <1258298591.00183715.1258288202@10.7.7.3> <4B002091.4010609@FreeBSD.org> Message-ID: <68FCEA9F-3785-4C90-91A2-7B5BAD811EB2@patpro.net> On 15 nov. 2009, at 16:38, Alexander Motin wrote: >> I've just found this: >> > > >> >> Does anybody has given this card a try? >> Unfortunately I can't find the brand of the chip they are using? > > Looking on picture, I would surmise it can be SiI3132, but price is > twice bigger then I would expect from that chip. SiI3132-based ST-Lab > A-410 controller in my city costs $29. Thank you Alexander! By the way, I'm not sure I can trust Belkin here. The "Overview" part is about 120 words longer than the "Specs" part. I'm expecting more specs and less nonsense. pat From freebsd at sopwith.solgatos.com Mon Nov 16 05:58:42 2009 From: freebsd at sopwith.solgatos.com (Dieter) Date: Mon Nov 16 05:58:48 2009 Subject: Adaptec 1405 on FreeBSD In-Reply-To: Your message of "Fri, 13 Nov 2009 22:00:43 +0200." <4AFDBAEB.2020903@FreeBSD.org> Message-ID: <200911160542.FAA00360@sopwith.solgatos.com> >> - SiI3124-based - fast and functional. It is actually PCI-X one, but >> there are many boards with built-in PCIe bridges. Do any of these fit in a x1 slot? >> - two SiI3132-based (Adaptec 1420SA and many others) - as cheap PCIe x1 >> alternative (max 150MB/s per card). These two better supported with new >> siis(4) driver on 8.0, but should work on 7.x with ata(4), haven't >> looked lower. I have the Masscool XWT-PCIE10 (USD20.99 plus shipping from newegg) 3132 card. Works fine on FreeBSD/amd64 7.1. Has both internal and external connectors with jumpers to select which are active. Only 2 drives per card though. :-( >> - First generation of SiI chips (SiI3114). They are quite old - SATA1 >> and PCI, but they are long-time supported and they take all possible >> from PCI bus, and in 66MHz PCI-X slot can give even more. But I have >> heard some negative comments about them. I have a 3512 card in a NetBSD box and it is slow but otherwise works fine. I have read various complaints about 1st gen SiL chips with FreeBSD, so do your homework before getting one for a FreeBSD box. Perhaps the new drivers in 8.0 will fix these problems? >> - JMicron-based PCIe x1 adapters. They are cheap, AHCI-compatible and >> not so bad, but limited by bus speed at about 180MB/s per card. I have a couple of Syba JMB363 cards and they have been trouble from day 1. If I plug them into the 2 PCIe x1 slots the box hangs in firmware. Moving 1 to the x16 slot allows the machine to boot. After a few months both cards have lost a SATA port. The JMB363 provide a PATA channel in addition to the 2 SATA ports. The PATA will connect at UDMA100, and reads fine at that speed, but writes fail unless downgraded to UDMA66. (Yes with the correct length 80 wire ribbon cable.) When rebooting, sometimes one of the cards doesn't show up. Is there some way for FreeBSD to force a proper full init of expansion cards when rebooting? I've also seen a PCI firewire card not get completely reinited when rebooting. Has anyone had good luck with a JMB363 card? I might consider a JMB363 on a different brand card. Last time I searched, I couldn't find any PCIe x1 cards that supported 4 (or more) SATA drives. The closest thing I could find was the JMB363 with 2 SATA plus 2 PATA. (and of course PATA has various fundamental problems) Has anyone found such a card? Yes I know that an x1 slot doesn't have enough bandwidth to run 4 drives at full speed, but x1 is what I have. They make PCI cards with at least 4 SATA ports and PCI slots have even less bandwidth. Port multipliers have the same problem. >> What's about changing SATA1 with SATA2 - I think you won't notice any >> difference. Most of disks are not so fast to congest SATA1, while Conventional rotating disks are approaching 150. Supposedly the SSDs are already saturating 300. 600 is out, but not common yet. The higher speeds would be very useful with port multipliers. I haven't heard of any PMs with 600 yet though. >> other bonuses like NCQ are not supported by 6.4 any way. > oh crap. No NCQ ? 7.x doesn't support NCQ either. :-( I'm waiting impatiently for 8.0 to come out. as I need NCQ. Speaking of which, I've read that some controller/disk combinations have problems with NCQ? Is there a way to turn NCQ on/off on a per-disk basis? From patpro at patpro.net Mon Nov 16 07:17:05 2009 From: patpro at patpro.net (Patrick Proniewski) Date: Mon Nov 16 07:17:11 2009 Subject: Adaptec 1405 on FreeBSD In-Reply-To: <200911160542.FAA00360@sopwith.solgatos.com> References: <200911160542.FAA00360@sopwith.solgatos.com> Message-ID: <7322FA5F-ABC2-4402-9B25-9BFD20B9C2FD@patpro.net> On 15 nov. 2009, at 22:42, Dieter wrote: > 7.x doesn't support NCQ either. :-( I'm waiting impatiently for > 8.0 to come out. as I need NCQ. Speaking of which, I've read that > some controller/disk combinations have problems with NCQ? Is there > a way to turn NCQ on/off on a per-disk basis? Are you sure 8.0 will support NCQ? I've searched for "NCQ" on the freebsd web site (using google), and found nothing about it's implementation in the system. Wikipedia states that "FreeBSD fully supports AHCI and NCQ since version 8.0" but gives no reference. pat From avg at icyb.net.ua Mon Nov 16 13:29:06 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Nov 16 13:29:13 2009 Subject: Adaptec 1405 on FreeBSD In-Reply-To: <7322FA5F-ABC2-4402-9B25-9BFD20B9C2FD@patpro.net> References: <200911160542.FAA00360@sopwith.solgatos.com> <7322FA5F-ABC2-4402-9B25-9BFD20B9C2FD@patpro.net> Message-ID: <4B015086.4050403@icyb.net.ua> on 16/11/2009 09:16 Patrick Proniewski said the following: > On 15 nov. 2009, at 22:42, Dieter wrote: > >> 7.x doesn't support NCQ either. :-( I'm waiting impatiently for >> 8.0 to come out. as I need NCQ. Speaking of which, I've read that >> some controller/disk combinations have problems with NCQ? Is there >> a way to turn NCQ on/off on a per-disk basis? > > Are you sure 8.0 will support NCQ? I've searched for "NCQ" on the > freebsd web site (using google), and found nothing about it's > implementation in the system. > Wikipedia states that "FreeBSD fully supports AHCI and NCQ since version > 8.0" but gives no > reference. See ahci(4) on relevant system. -- Andriy Gapon From mav at FreeBSD.org Mon Nov 16 15:59:42 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon Nov 16 15:59:49 2009 Subject: Adaptec 1405 on FreeBSD In-Reply-To: <1258363380.00183909.1258351203@10.7.7.3> References: <1258363380.00183909.1258351203@10.7.7.3> Message-ID: <4B0176E7.7080204@FreeBSD.org> Dieter wrote: >>> - SiI3124-based - fast and functional. It is actually PCI-X one, but >>> there are many boards with built-in PCIe bridges. > > Do any of these fit in a x1 slot? I was surprised, but yes. And as expected, bus limits it performance badly. But it is still works much faster then 3132 at the same bus. >>> - First generation of SiI chips (SiI3114). They are quite old - SATA1 >>> and PCI, but they are long-time supported and they take all possible >>> from PCI bus, and in 66MHz PCI-X slot can give even more. But I have >>> heard some negative comments about them. > > I have a 3512 card in a NetBSD box and it is slow but otherwise works fine. > I have read various complaints about 1st gen SiL chips with FreeBSD, > so do your homework before getting one for a FreeBSD box. Perhaps the > new drivers in 8.0 will fix these problems? I haven't seen original chip errata to be sure, but ata(4) driver now includes some workarounds for this chip. Same time, there is no such quirks for 3114. > 7.x doesn't support NCQ either. :-( I'm waiting impatiently for > 8.0 to come out. as I need NCQ. Speaking of which, I've read that > some controller/disk combinations have problems with NCQ? Is there > a way to turn NCQ on/off on a per-disk basis? It is already possible in HEAD to write quirks for specific device models and firmware revisions. Also to control NCQ usage. -- Alexander Motin From peterjeremy at acm.org Mon Nov 16 18:29:32 2009 From: peterjeremy at acm.org (Peter Jeremy) Date: Mon Nov 16 18:29:39 2009 Subject: 7.2-STABLE i386 box crashing -- clues? In-Reply-To: <20091112125903.GA1631@albert.catwhisker.org> References: <20091111173747.GA1150@albert.catwhisker.org> <20091112062708.GA16648@server.vk2pj.dyndns.org> <20091112125903.GA1631@albert.catwhisker.org> Message-ID: <20091116182924.GA30969@server.vk2pj.dyndns.org> On 2009-Nov-12 04:59:03 -0800, David Wolfskill wrote: >Yes; the machine is configured to start xdm on transition to >multi--user, as my spouse used to use it as a desktop. Does the problem still appear if you don't start X? Is it running anything unusual when it crashes? >> At this stage, my suggestion would be to try swapping the PSU. > >Thanks. I'll discuss it with the "family CFO." You can't swap it with another of your systems? Even if it doesn't fit neatly into the case, a temporary swap would give you some confidence as to whether it was really faulty or not (especially if the random reboots move to the other system). -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hardware/attachments/20091116/f0a68cff/attachment.pgp From david at catwhisker.org Mon Nov 16 19:04:14 2009 From: david at catwhisker.org (David Wolfskill) Date: Mon Nov 16 19:04:21 2009 Subject: 7.2-STABLE i386 box crashing -- clues? In-Reply-To: <20091116182924.GA30969@server.vk2pj.dyndns.org> References: <20091111173747.GA1150@albert.catwhisker.org> <20091112062708.GA16648@server.vk2pj.dyndns.org> <20091112125903.GA1631@albert.catwhisker.org> <20091116182924.GA30969@server.vk2pj.dyndns.org> Message-ID: <20091116190410.GA1589@albert.catwhisker.org> On Tue, Nov 17, 2009 at 05:29:24AM +1100, Peter Jeremy wrote: > ... > >Yes; the machine is configured to start xdm on transition to > >multi--user, as my spouse used to use it as a desktop. > > Does the problem still appear if you don't start X? I haven't tried that yet.... > Is it running anything unusual when it crashes? Not that I can tell, no. Though I did just notice that the whines about icmp unreach responses is actually coming from the machine that's crashing ("albert") vs. the firewall box (which is configured to log everything to albert). > >> At this stage, my suggestion would be to try swapping the PSU. > > > >Thanks. I'll discuss it with the "family CFO." > > You can't swap it with another of your systems? Even if it doesn't > fit neatly into the case, a temporary swap would give you some > confidence as to whether it was really faulty or not (especially if > the random reboots move to the other system). I think it's more a matter of "at all" rather than "neatly." :-} I tend to have a variety of hardware, but each machine tends to be from a different era or have other differences that cause each to be a one-off. But I'll see what I can find. In the mean time. tyhe machine crashed this morning after I got in to work -- but wonder of wonders, it came back up again this time. And the typescript file that's capturing the serial console activity showed: fxp0: link state changed to UP Limiting icmp unreach response from 234 to 200 packets/sec FreeBSD/i386 (albert.catwhisker.org) (ttyd0) login: drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xf0000000 128MB info: [drm] Initialized i915 1.6.0 20080730 drm0: [ITHREAD] Limiting icmp unreach response from 201 to 200 packets/sec Limiting icmp unreach response from 201 to 200 packets/sec Limiting icmp unreach response from 201 to 200 packets/sec Limiting icmp unreach response from 201 to 200 packets/sec Limiting icmp unreach response from 201 to 200 packets/sec Limiting icmp unreach response from 201 to 200 packets/sec Limiting icmp unreach response from 201 to 200 packets/sec Limiting icmp unreach response from 201 to 200 packets/sec Limiting icmp unreach response from 201 to 200 packets/sec Limiting icmp unreach response from 201 to 200 packets/sec panic: vm_fault: fault on nofault entry, addr: c3983000 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c0bf0330,e7d168f8,c082cae9,c0c1237c,0,...) at 0xc049e9a6 = db_trace_self_wrapper+0x26 kdb_backtrace(c0c1237c,0,c0c07dfe,e7d16904,0,...) at 0xc085a239 = kdb_backtrace+0x29 panic(c0c07dfe,c3983000,2,e7d169fc,e7d169ec,...) at 0xc082cae9 = panic+0x119 vm_fault(c1471000,c3983000,2,0,e7d16a7c,...) at 0xc0a6ec88 = vm_fault+0x178 trap_pfault(c0d4de20,e7d16ac4,c0b2b675,0,c660cb00,...) at 0xc0b3f60e = trap_pfault+0x20e trap(e7d16b3c) at 0xc0b400b5 = trap+0x445 calltrap() at 0xc0b22dbb = calltrap+0x6 --- trap 0xc, eip = 0xc0b37648, esp = 0xe7d16b7c, ebp = 0xe7d16b88 --- pmap_try_insert_pv_entry(c08b14c4,c63c0cf0,c63c0cf0,e7d16bbc,c08b4b17,...) at 0xc0b37648 = pmap_try_insert_pv_entry+0x48 pmap_copy(c6cd2d74,c69dd350,33f7d000,f4000,33f7d000,...) at 0xc0b3c1e8 = pmap_copy+0x2e8 vmspace_fork(c69dd2c4,0,2,e7d16c5c,bfbfc824,...) at 0xc0a7698b = vmspace_fork+0x42b fork1(c63c3b40,14,0,e7d16c78,0,...) at 0xc08051ee = fork1+0x30e fork(c63c3b40,e7d16cfc,c,8001550d,369e99,...) at 0xc0806b79 = fork+0x29 syscall(e7d16d38) at 0xc0b3f9c5 = syscall+0x335 Xint0x80_syscall() at 0xc0b22e20 = Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip = 0x340cde4b, esp = 0xbfbfc7cc, ebp = 0xbfbfc858 --- Uptime: 3d4h1m43s Physical memory: 2033 MB Dumping 179 MB: 164 148 132 116 100 84 68 52 36 20 4 Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Taking a quick look at vmcore.1, I see: albert(7.2-S)[5] kgdb /boot/kernel/kernel vmcore.1 GNU gdb 6.1.1 [FreeBSD] ... [above stuff...] ... #0 doadump () at pcpu.h:196 196 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc082c817 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc082cb22 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0a6ec88 in vm_fault (map=0xc1471000, vaddr=3281530880, fault_type=2 '\002', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:277 #4 0xc0b3f60e in trap_pfault (frame=0xe7d16b3c, usermode=0, eva=3281531764) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc0b400b5 in trap (frame=0xe7d16b3c) at /usr/src/sys/i386/i386/trap.c:541 #6 0xc0b22dbb in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0xc0b37648 in pmap_try_insert_pv_entry (pmap=0xc6cd2d74, va=872140800, m=0xc2be5110) at /usr/src/sys/i386/i386/pmap.c:2229 #8 0xc0b3c1e8 in pmap_copy (dst_pmap=0xc6cd2d74, src_pmap=0xc69dd350, dst_addr=871878656, len=999424, src_addr=871878656) at /usr/src/sys/i386/i386/pmap.c:3677 #9 0xc0a7698b in vmspace_fork (vm1=0xc69dd2c4) at /usr/src/sys/vm/vm_map.c:2552 #10 0xc08051ee in fork1 (td=0xc63c3b40, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/kern_fork.c:288 #11 0xc0806b79 in fork (td=0xc63c3b40, uap=0xe7d16cfc) at /usr/src/sys/kern/kern_fork.c:107 #12 0xc0b3f9c5 in syscall (frame=0xe7d16d38) at /usr/src/sys/i386/i386/trap.c:1101 #13 0xc0b22e20 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:262 #14 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) If there is an issue with the PSU, I'm not sure there's much to be gained by spending much time on that dump -- I understand that there's not much information to trust if the PSU is flaky. Thanks for your help! Peace, david -- David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hardware/attachments/20091116/1a6de612/attachment.pgp From jhb at freebsd.org Mon Nov 16 21:31:10 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Nov 16 21:31:31 2009 Subject: Msg: no prefetched decode (going from stable/6 -> stable/7) In-Reply-To: <20091114052429.GF1649@albert.catwhisker.org> References: <20091114052429.GF1649@albert.catwhisker.org> Message-ID: <200911161538.26899.jhb@freebsd.org> On Saturday 14 November 2009 12:24:29 am David Wolfskill wrote: > I admit that I don't know what "no prefetched decode" means in this > context, or what I can or should do about it. > > But the same hardware running stable/6 does not issue that whine, and > the laptop in question does see the additional PCI devices on the > docking station when running stable/6, but issues the above whine, and > fails to "see" the additional PCI devices in the docking station running > any of stable/7, stable/8, or head (9.0-CURRENT). > > And while there are certainly advances in many respects in going to > newer versions of FreeBSD, I'm a little hard-pressed to understand how > this qualifies. :-} > > A bit of background: > > My laptop is parts from 3 Dell laptops -- 2 Inspiron 8200s and 1 > Latitude C840. I use the FreeBSD bootloader, and have 4 distinct > bootable slices on the disk. At this time: > > * slice 1: / and /usr for stable/6 > * slice 2: / and /usr for stable/7 > * slice 4: / and /usr for stable/8 > * slice 4: / and /usr for head (9.0-CURRENT); also swap, as well as a > few other partitions (e.g., /var) that are mounted to the > same place regardless of which slice is booted. > > For last night's BAFUG meeting, Julian had volunteered to demonstrate > vimage. He needed access to a machine running stable/8 or head with > multiple NICs. > > I volunteered the use of my laptop, as it has a couple of NICs in its > chassis, and I recalled that when I had run stable/6, FreeBSD saw the > wired NIC in the docking station. > > So I brought a couple of PCI NICs to stick in the dockinig station, > figuring that would give us 5 NICs (not counting Firewire -- or > anything I could shove in a PCCard slot), which should be adequate. > > But as I was building stable/8 (running stable/7 at teh time), I noticed > that "ifconfig" output didn't show the additional 3 NICs. > > So this evening, I booted each of the slices in turn to single user > mode, then (in each case) entered: > > * fsck -p && mount -a > * csh > * uname -a >/var/tmp/pciconf.N > * pciconf -lv >>!$ > * dmesg >/vat/tmp/dmesg.N > > (where "N" was one of "6", "7", "8", or "9", according to the version of > FreeBSD being run at the time). > > I've attached the resulting files. > > Here's the tail end of diff -u pciconf.{6,7}: > > ... > -iwi0@pci2:3:0: class=0x028000 card=0x27218086 chip=0x42208086 rev=0x05 hdr=0x00 > +iwi0@pci0:2:3:0: class=0x028000 card=0x27218086 chip=0x42208086 rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > - device = 'MPCI3B driverIntel PRO/Wireless 2200BG' > + device = 'driverIntel PRO/Wireless 2200BG (MPCI3B)' > class = network > -pcib3@pci2:12:0: class=0x060400 card=0x00000000 chip=0x00221011 rev=0x04 hdr=0x01 > +pcib3@pci0:2:12:0: class=0x060400 card=0x00000000 chip=0x00221011 rev=0x04 hdr=0x01 > vendor = 'Digital Equipment Corporation' > - device = '21150-AA PCI to PCI Bridge' > + device = 'PCI-PCI Bridge (DC21150-AA)' > class = bridge > subclass = PCI-PCI > -xl1@pci3:1:0: class=0x020000 card=0x905510b7 chip=0x905510b7 rev=0x30 hdr=0x00 > - vendor = '3COM Corp, Networking Division' > - device = '3C905-TX Fast Etherlink 10/100 PCI TX NIC' > - class = network > - subclass = ethernet > -dc0@pci3:2:0: class=0x020000 card=0xf0041385 chip=0x000211ad rev=0x20 hdr=0x00 > - vendor = 'Lite-On Communications Inc' > - device = 'KNE110TX Kingston EtheRx KNE110TX PCI Fast Ethernet Adapter' > - class = network > - subclass = ethernet > -atapci0@pci3:5:0: class=0x01018f card=0x06461095 chip=0x06461095 rev=0x07 hdr=0x00 > - vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' > - device = 'PCI-0646 EIDE Adapter (Single FIFO)' > - class = mass storage > - subclass = ATA > -ahc0@pci3:7:0: class=0x010000 card=0x78809004 chip=0x80789004 rev=0x01 hdr=0x00 > - vendor = 'Adaptec Inc' > - device = 'AIC-7880P Ultra/Ultra Wide SCSI Chipset' > - class = mass storage > - subclass = SCSI > -xl2@pci3:8:0: class=0x020000 card=0x00a81028 chip=0x920010b7 rev=0x6c hdr=0x00 > - vendor = '3COM Corp, Networking Division' > - device = '3C905 CX-TX-M Fast EtherLink for PC Management NIC' > - class = network > - subclass = ethernet > > And here's the part of the output from "diff -u dmesg.{6,7}" that > inspired the Subject: > > ... > @@ -381,172 +412,34 @@ > iwi0: bpf attached > iwi0: bpf attached > iwi0: [MPSAFE] > +iwi0: [ITHREAD] > iwi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > iwi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > pcib3: at device 12.0 on pci2 > +pcib3: domain 0 > pcib3: secondary bus 3 > pcib3: subordinate bus 3 > pcib3: I/O decode 0xf000-0xffff > pcib3: memory decode 0xfa000000-0xfbffffff > -pcib3: prefetched decode 0xfff00000-0xfffff > -ACPI: Found matching pin for 3.5.INTA at func 0: 11 > -ACPI: Found matching pin for 3.1.INTA at func 0: 11 > -ACPI: Found matching pin for 3.2.INTA at func 0: 11 > -ACPI: Found matching pin for 3.7.INTA at func 0: 11 > -ACPI: Found matching pin for 3.8.INTA at func 0: 11 > +pcib3: no prefetched decode In this case, newer message is just more correct. Notice that in the old printf the ending address is less than the starting address for the prefetch range. 7 is just smart enough to print this out more correctly. I do wonder if 7 does better if you disable ACPI? I'm curious if ACPI somehow thinks that the PCI device is not enabled. Presumably it would not have made it this far though if that were the case. Can you do something like 'pciconf -r pci0:3:1:0 0x0:0x40' under a working (6) and broken (7+) kernel with the docking station attached? -- John Baldwin From david at catwhisker.org Tue Nov 17 04:06:08 2009 From: david at catwhisker.org (David Wolfskill) Date: Tue Nov 17 04:06:15 2009 Subject: Msg: no prefetched decode (going from stable/6 -> stable/7) In-Reply-To: <200911161538.26899.jhb@freebsd.org> References: <20091114052429.GF1649@albert.catwhisker.org> <200911161538.26899.jhb@freebsd.org> Message-ID: <20091117040607.GG1589@albert.catwhisker.org> On Mon, Nov 16, 2009 at 03:38:26PM -0500, John Baldwin wrote: > ... > > Here's the tail end of diff -u pciconf.{6,7}: > > > > ... > > -iwi0@pci2:3:0: class=0x028000 card=0x27218086 chip=0x42208086 rev=0x05 > hdr=0x00 > > +iwi0@pci0:2:3:0: class=0x028000 card=0x27218086 chip=0x42208086 > rev=0x05 hdr=0x00 > > vendor = 'Intel Corporation' > > - device = 'MPCI3B driverIntel PRO/Wireless 2200BG' > > + device = 'driverIntel PRO/Wireless 2200BG (MPCI3B)' > > class = network > > -pcib3@pci2:12:0: class=0x060400 card=0x00000000 chip=0x00221011 > rev=0x04 hdr=0x01 > > +pcib3@pci0:2:12:0: class=0x060400 card=0x00000000 chip=0x00221011 > rev=0x04 hdr=0x01 > > vendor = 'Digital Equipment Corporation' > > - device = '21150-AA PCI to PCI Bridge' > > + device = 'PCI-PCI Bridge (DC21150-AA)' > > class = bridge > > subclass = PCI-PCI > > -xl1@pci3:1:0: class=0x020000 card=0x905510b7 chip=0x905510b7 rev=0x30 > hdr=0x00 > > - vendor = '3COM Corp, Networking Division' > > - device = '3C905-TX Fast Etherlink 10/100 PCI TX NIC' > > - class = network > > - subclass = ethernet > > ... > > pcib3: memory decode 0xfa000000-0xfbffffff > > -pcib3: prefetched decode 0xfff00000-0xfffff > > -ACPI: Found matching pin for 3.5.INTA at func 0: 11 > > -ACPI: Found matching pin for 3.1.INTA at func 0: 11 > > -ACPI: Found matching pin for 3.2.INTA at func 0: 11 > > -ACPI: Found matching pin for 3.7.INTA at func 0: 11 > > -ACPI: Found matching pin for 3.8.INTA at func 0: 11 > > +pcib3: no prefetched decode > > In this case, newer message is just more correct. Notice that in the old > printf the ending address is less than the starting address for the prefetch > range. 7 is just smart enough to print this out more correctly. I do wonder > if 7 does better if you disable ACPI? I'm curious if ACPI somehow thinks > that the PCI device is not enabled. Presumably it would not have made it > this far though if that were the case. OK; I haven't yet tried disabling ACPI. > Can you do something like 'pciconf -r > pci0:3:1:0 0x0:0x40' under a working (6) and broken (7+) kernel with the > docking station attached? Can do, thanks! So, first, running: FreeBSD g1-108.catwhisker.org 6.4-STABLE FreeBSD 6.4-STABLE #700 r199014: Sat Nov 7 04:28:00 PST 2009 root@g1-101.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY i386 I issued: sudo pciconf -r pci2:12:0 0x0:0x40 sudo pciconf -r pci3:1:0 0x0:0x40 (The first was the address of the PCI-PCI bridge; the second, that of the xl1 NIC.) Result: 00221011 02900107 06040004 00012008 00000000 00000000 20030302 2280f1f1 fbf0fa00 0001fff1 00000000 00000000 00000000 000000dc 00000000 02060000 02000000 905510b7 02100117 02000030 00002008 0000fc81 fafffc00 00000000 00000000 00000000 00000000 00000000 905510b7 fb000000 000000dc 00000000 0a0a010b 00000000 Then, running: FreeBSD g1-110.catwhisker.org 7.2-STABLE FreeBSD 7.2-STABLE #9 r199319: Mon Nov 16 06:04:38 PST 2009 root@g1-108.catwhisker.org:/common/S2/obj/usr/src/sys/CANARY i386 I first tried the same commands as above, and got: 00221011 82900107 06040004 00012008 00000000 00000000 20030302 2280f1f1 fbf0fa00 0001fff1 00000000 00000000 00000000 000000dc 00000000 06060000 02000000 pciconf: ioctl(PCIOCREAD): Operation not supported by device Then I realized that the designation of the PCI-PCI bridge was different under stable/7 than it was under stable/6, so I tried: sudo pciconf -r pci0:2:12:0 0x0:0x40 sudo pciconf -r pci0:3:1:0 0x0:0x40 and got: 00221011 82900107 06040004 00012008 00000000 00000000 20030302 2280f1f1 fbf0fa00 0001fff1 00000000 00000000 00000000 000000dc 00000000 06060000 02000000 pciconf: ioctl(PCIOCREAD): Operation not supported by device Was that useful? It appears that "pci2:12:0 0x0:0x40" looks quite a bit like "pci0:2:12:0 0x0:0x40". Coincidence? Aliases? Peace, david -- David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hardware/attachments/20091117/2c7ad477/attachment.pgp From freebsd at sopwith.solgatos.com Tue Nov 17 05:20:56 2009 From: freebsd at sopwith.solgatos.com (Dieter) Date: Tue Nov 17 05:21:07 2009 Subject: Adaptec 1405 on FreeBSD In-Reply-To: Your message of "Mon, 16 Nov 2009 17:59:35 +0200." <4B0176E7.7080204@FreeBSD.org> Message-ID: <200911162046.UAA02994@sopwith.solgatos.com> In message <4B0176E7.7080204@FreeBSD.org>, Alexander Motin writes: > >>> - SiI3124-based - fast and functional. It is actually PCI-X one, but > >>> there are many boards with built-in PCIe bridges. > > > > Do any of these fit in a x1 slot? > > I was surprised, but yes. My google-fu fails me. Any make/model, URLs, or keywords? > And as expected, bus limits it performance > badly. But it is still works much faster then 3132 at the same bus. Hmmm, I must not have tested both disks at once before on the 3132: One at a time: dd if=/dev/ad18 bs=1m count=1000 of=/dev/null 1048576000 bytes transferred in 8.807009 secs (119061534 bytes/sec) dd if=/dev/ad20 bs=1m count=1000 of=/dev/null 1048576000 bytes transferred in 8.800526 secs (119149243 bytes/sec) Two at once: dd if=/dev/ad18 bs=1m count=1000 of=/dev/null & dd if=/dev/ad20 bs=1m count=1000 of=/dev/null 1048576000 bytes transferred in 13.766050 secs (76171160 bytes/sec) 1048576000 bytes transferred in 13.799268 secs (75987799 bytes/sec) so 152 MB/s total rather than the expected ~238. PCIe x1 slot is supposed to be good for 250 MB/s, so it ought to be able to max out both disks at once, or at least get close. From freebsd at sopwith.solgatos.com Tue Nov 17 05:20:56 2009 From: freebsd at sopwith.solgatos.com (Dieter) Date: Tue Nov 17 05:21:08 2009 Subject: Adaptec 1405 on FreeBSD In-Reply-To: Your message of "Sun, 15 Nov 2009 13:22:24 +0100." <511CEEC9-7721-4E51-AD7C-A98E59299F07@patpro.net> Message-ID: <200911162114.VAA03618@sopwith.solgatos.com> In message <511CEEC9-7721-4E51-AD7C-A98E59299F07@patpro.net>, Patrick Proniewski writes: > I've just found this: > > > Does anybody has given this card a try? > Unfortunately I can't find the brand of the chip they are using=85 All I get is: "The system is encountering an unusual condition. Please try later." It was doing this yesterday also. Wonder what they mean by later. I guess I should not buy any web servers from Belkin. :-) From mav at FreeBSD.org Tue Nov 17 10:34:44 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Nov 17 10:34:51 2009 Subject: Adaptec 1405 on FreeBSD In-Reply-To: <1258446183.00184282.1258435802@10.7.7.3> References: <1258446183.00184282.1258435802@10.7.7.3> Message-ID: <4B027C3E.7020700@FreeBSD.org> Dieter wrote: > In message <4B0176E7.7080204@FreeBSD.org>, Alexander Motin writes: >>>>> - SiI3124-based - fast and functional. It is actually PCI-X one, but >>>>> there are many boards with built-in PCIe bridges. >>> Do any of these fit in a x1 slot? >> I was surprised, but yes. > > My google-fu fails me. Any make/model, URLs, or keywords? Syba PCI Express SATA II 4 x Ports RAID Controller Card SY-PEX40008 http://www.amazon.com/Syba-Express-Ports-Controller-SY-PEX40008/dp/B002R0DZWQ/ref=sr_1_22?ie=UTF8&s=electronics&qid=1258452902&sr=1-22 >> And as expected, bus limits it performance >> badly. But it is still works much faster then 3132 at the same bus. > > Hmmm, I must not have tested both disks at once before on the 3132: > > One at a time: > > dd if=/dev/ad18 bs=1m count=1000 of=/dev/null > 1048576000 bytes transferred in 8.807009 secs (119061534 bytes/sec) > > dd if=/dev/ad20 bs=1m count=1000 of=/dev/null > 1048576000 bytes transferred in 8.800526 secs (119149243 bytes/sec) > > Two at once: > > dd if=/dev/ad18 bs=1m count=1000 of=/dev/null & dd if=/dev/ad20 bs=1m count=1000 of=/dev/null > 1048576000 bytes transferred in 13.766050 secs (76171160 bytes/sec) > 1048576000 bytes transferred in 13.799268 secs (75987799 bytes/sec) > > so 152 MB/s total rather than the expected ~238. PCIe x1 slot is supposed to > be good for 250 MB/s, so it ought to be able to max out both disks at once, > or at least get close. I have close numbers. 250MB/s is actually performance of the physical level. Logical level also creates overhead of somewhere about 30-40 bytes per transfer. As soon as most of desktop chipsets limited with 128bytes transfers, it also shouldn't be forgotten. The interesting fact I have seen yesterday, SiI3132 is able to read 150MB/s, but write 170MB/s. I am not PCIe expert, but looks like transfer capabilities could be asymmetric. Also, and as soon as PCIe is duplex, I've also seen 110MB/s read from one drive, plus 100MB/s write to another, running at the same time. -- Alexander Motin From mkhitrov at gmail.com Wed Nov 18 01:32:27 2009 From: mkhitrov at gmail.com (Maxim Khitrov) Date: Wed Nov 18 01:32:33 2009 Subject: Looking for a tiny embedded system that supports *BSD Message-ID: <26ddd1750911171732p356f2af5rcb6321397aa9e70d@mail.gmail.com> Hello all, A project I'm working on requires a really small box (at most 15x9x3cm in size, but ideally smaller) that's capable of running one of the four BSDs. The catch is that it must have its own battery supply capable of powering the system for at least 5 hours. The other major requirements are one RS-232 and at least one USB ports. The battery should be recharged through the USB port. If there is a separate power cord, I will have to somehow join it and the usb cable into a single non-usb connector (which I'd like to avoid if at all possible). Finally, it must support some kind of removable storage (e.g. CF card). This system will essentially be a portable translator of one type of communication protocol to another with data flowing between the RS-232 and USB ports. Obviously, I don't need any video output or any kind of input. Just need a tiny box with two cables coming out of it. Do you know of anything that might work? - Max From Jiri.Smejkal at cnw.cz Wed Nov 18 09:37:07 2009 From: Jiri.Smejkal at cnw.cz (=?iso-8859-2?Q?Ji=F8=ED_Smejkal?=) Date: Wed Nov 18 09:37:19 2009 Subject: Looking for a tiny embedded system that supports *BSD In-Reply-To: <26ddd1750911171732p356f2af5rcb6321397aa9e70d@mail.gmail.com> References: <26ddd1750911171732p356f2af5rcb6321397aa9e70d@mail.gmail.com> Message-ID: <0FFC914A57259D4EBB4C448E8A8ECF15201B47DE46@SRVEX.cnw.local> Hi Maxim, What about ALIX 3D board www.pcengines.ch - 160x100x25mm, 500MHz AMD Geode LX2. I'm using it with FBSD 6,7,8. Single power supply 7-20V - ideal for Pb accu. Jiri Smejkal -----Original Message----- From: owner-freebsd-hardware@freebsd.org [mailto:owner-freebsd-hardware@freebsd.org] On Behalf Of Maxim Khitrov Sent: Wednesday, November 18, 2009 2:32 AM To: freebsd-hardware@freebsd.org Subject: Looking for a tiny embedded system that supports *BSD Hello all, A project I'm working on requires a really small box (at most 15x9x3cm in size, but ideally smaller) that's capable of running one of the four BSDs. The catch is that it must have its own battery supply capable of powering the system for at least 5 hours. The other major requirements are one RS-232 and at least one USB ports. The battery should be recharged through the USB port. If there is a separate power cord, I will have to somehow join it and the usb cable into a single non-usb connector (which I'd like to avoid if at all possible). Finally, it must support some kind of removable storage (e.g. CF card). This system will essentially be a portable translator of one type of communication protocol to another with data flowing between the RS-232 and USB ports. Obviously, I don't need any video output or any kind of input. Just need a tiny box with two cables coming out of it. Do you know of anything that might work? - Max _______________________________________________ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" From mkhitrov at gmail.com Wed Nov 18 11:20:41 2009 From: mkhitrov at gmail.com (Maxim Khitrov) Date: Wed Nov 18 11:20:46 2009 Subject: Looking for a tiny embedded system that supports *BSD In-Reply-To: <0FFC914A57259D4EBB4C448E8A8ECF15201B47DE46@SRVEX.cnw.local> References: <26ddd1750911171732p356f2af5rcb6321397aa9e70d@mail.gmail.com> <0FFC914A57259D4EBB4C448E8A8ECF15201B47DE46@SRVEX.cnw.local> Message-ID: <26ddd1750911180320l574714fdv54f4dda76703ad1a@mail.gmail.com> 2009/11/18 Ji?? Smejkal : > -----Original Message----- > From: owner-freebsd-hardware@freebsd.org [mailto:owner-freebsd-hardware@freebsd.org] On Behalf Of Maxim Khitrov > Sent: Wednesday, November 18, 2009 2:32 AM > To: freebsd-hardware@freebsd.org > Subject: Looking for a tiny embedded system that supports *BSD > > Hello all, > > A project I'm working on requires a really small box (at most 15x9x3cm > in size, but ideally smaller) that's capable of running one of the > four BSDs. > > The catch is that it must have its own battery supply capable of > powering the system for at least 5 hours. The other major requirements > are one RS-232 and at least one USB ports. The battery should be > recharged through the USB port. If there is a separate power cord, I > will have to somehow join it and the usb cable into a single non-usb > connector (which I'd like to avoid if at all possible). Finally, it > must support some kind of removable storage (e.g. CF card). > > This system will essentially be a portable translator of one type of > communication protocol to another with data flowing between the RS-232 > and USB ports. Obviously, I don't need any video output or any kind of > input. Just need a tiny box with two cables coming out of it. Do you > know of anything that might work? > > - Max > > Hi Maxim, > > What about ALIX 3D board www.pcengines.ch - 160x100x25mm, 500MHz AMD Geode LX2. I'm using it with FBSD 6,7,8. Single power supply 7-20V - ideal for Pb accu. > > Jiri Smejkal These weren't designed for use with a battery. That's the most difficult part of finding what I need. There are plenty boards out there that have all the right features, but so far I couldn't find anything that can work for a few hours without an AC power source. - Max From beckman at angryox.com Wed Nov 18 17:53:30 2009 From: beckman at angryox.com (Peter Beckman) Date: Wed Nov 18 17:53:38 2009 Subject: Looking for a tiny embedded system that supports *BSD In-Reply-To: <26ddd1750911180320l574714fdv54f4dda76703ad1a@mail.gmail.com> References: <26ddd1750911171732p356f2af5rcb6321397aa9e70d@mail.gmail.com> <0FFC914A57259D4EBB4C448E8A8ECF15201B47DE46@SRVEX.cnw.local> <26ddd1750911180320l574714fdv54f4dda76703ad1a@mail.gmail.com> Message-ID: On Wed, 18 Nov 2009, Maxim Khitrov wrote: > These weren't designed for use with a battery. That's the most > difficult part of finding what I need. There are plenty boards out > there that have all the right features, but so far I couldn't find > anything that can work for a few hours without an AC power source. Don't look for a whole computer that meets your needs, start looking for computers that meet your needs and then look for a PSU that can accept a battery input. http://www.epn-online.com/page/35052/130w-battery-backup-psu.html Not sure if Google uses a PSU from a commercial manufacturer or rolls their own, but their PSU's have a built in battery for each racked computer. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From phk at phk.freebsd.dk Wed Nov 18 18:51:55 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed Nov 18 18:52:02 2009 Subject: Looking for a tiny embedded system that supports *BSD In-Reply-To: Your message of "Wed, 18 Nov 2009 12:35:08 EST." Message-ID: <20677.1258569152@critter.freebsd.dk> In message , Peter Beckman writes: >On Wed, 18 Nov 2009, Maxim Khitrov wrote: > http://www.epn-online.com/page/35052/130w-battery-backup-psu.html For the effects we are talking about, this is much more relevant: http://www.mini-box.com/DC-DC -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From patpro at patpro.net Thu Nov 19 13:46:19 2009 From: patpro at patpro.net (Patrick Proniewski) Date: Thu Nov 19 13:46:27 2009 Subject: what is the good geometry for disk WD10EADS Message-ID: <8DEEC192-6A98-4487-A6D2-5367649F4C2D@patpro.net> Hello, I've just added a WD10EADS disk in my FreeBSD box () My mother board is few years old and supports only SATA I, so the drive is recognized as SATA150 (which is fine): ad6: 953869MB at ata3-master SATA150 Unfortunately, I'm unable to find the right geometry in order to format/label the disk. Using sysintall interface to handle the new disk yields to this kind of alerts: (1st alert) WARNING: A geometry of 1938021/16/63 for ad6 is incorrect ... (2nd alert) WARNING: A geometry of 121601/255/63 for ad6 is incorrect ... (3rd alert) WARNING: A geometry of 121601/255/63 for ad6 is incorrect ... (ad lib) So, the software tries to guess the right geometry, but fails and stick with wrong numbers (121601/255/63) I have this: # diskinfo -v ad6 ad6 512 # sectorsize 1000204886016 # mediasize in bytes (932G) 1953525168 # mediasize in sectors 1938021 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. But fdisk thinks it's not good. And mounting the formated disk fails (121601/255/63): # mount /dev/ad6s1c /backup mount: /dev/ad6s1c on /backup: incorrect super block I don't know where to look, the BIOS says nothing about the geometry (unless I've missed something). It's on LBA mode. patpro From patpro at patpro.net Thu Nov 19 14:10:48 2009 From: patpro at patpro.net (Patrick Proniewski) Date: Thu Nov 19 14:11:29 2009 Subject: what is the good geometry for disk WD10EADS In-Reply-To: <8DEEC192-6A98-4487-A6D2-5367649F4C2D@patpro.net> References: <8DEEC192-6A98-4487-A6D2-5367649F4C2D@patpro.net> Message-ID: few more info: On 19 nov. 2009, at 14:46, Patrick Proniewski wrote: > And mounting the formated disk fails (121601/255/63): > > # mount /dev/ad6s1c /backup > mount: /dev/ad6s1c on /backup: incorrect super block This is obviously wrong, 'c' partition represents the slice, and should not be available for mounting. I've messed up with fdisk/ disklabel (forgot to quit sysinstall between the two steps). I've found a japanese site that states that the correct geometry for WD10EADS could be 16383/16/63 (if the google translation is ok). I've tried, and so far the disk properly mounts. I'm still interested in a way to get the right geometry on FreeBSD, for this drive. patpro From peterjeremy at acm.org Fri Nov 20 07:59:43 2009 From: peterjeremy at acm.org (Peter Jeremy) Date: Fri Nov 20 07:59:50 2009 Subject: Looking for a tiny embedded system that supports *BSD In-Reply-To: <26ddd1750911171732p356f2af5rcb6321397aa9e70d@mail.gmail.com> References: <26ddd1750911171732p356f2af5rcb6321397aa9e70d@mail.gmail.com> Message-ID: <20091120065154.GB49534@server.vk2pj.dyndns.org> On 2009-Nov-17 20:32:06 -0500, Maxim Khitrov wrote: >A project I'm working on requires a really small box (at most 15x9x3cm >in size, but ideally smaller) that's capable of running one of the >four BSDs. > >The catch is that it must have its own battery supply capable of >powering the system for at least 5 hours. The other major requirements >are one RS-232 and at least one USB ports. If (as I read it), the battery needs to be inside the 15x9x3cm box, the 5hr battery requirement is going to make this very difficult using x86 hardware. You probably need to look at something ARM based or maybe something like gumstix.com (though I don't know if the latter is supported by any *BSD). > The battery should be >recharged through the USB port. This implies quite a low power consumption since USB 2 is restricted to 500mA per port - or 2.5W to charge the battery and presumably power the device. Is there a specific requirement for BSD? Based on what you've said, it would be far easier to meet the physical dimension and power requirements using something like a PIC or Atmel microcontroller. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hardware/attachments/20091120/9397894d/attachment.pgp From cowens at greatbaysoftware.com Fri Nov 20 21:46:30 2009 From: cowens at greatbaysoftware.com (Charles Owens) Date: Fri Nov 20 21:46:37 2009 Subject: USB keyboard flaky with PAE kernel, 7.1 Message-ID: <4B070F07.8010600@greatbaysoftware.com> Howdy, I'm still digging into it, put preliminary testing is showing that with a PAE-enabled 7.1-RELEASE-p8 kernel a USB keyboard functions only occasionally, if you're lucky. This flakiness is being seen with several different server models that we support (HP and IBM, all Xeon based). If we boot a non-PAE kernel then the USB keyboard is rock solid. For what it's worth (probably little) I can run the same PAE kernel on an old Pentium II system and a USB keyboard works fine. What is the best way to dig into this? Any and all assistance greatly appreciated. I can provide remote access to a testbed of these systems if useful. Charles (And, yes, I do know that amd64 is better than PAE for various obvious reasons. ;-) ) -- **Charles Owens** *Great Bay Software**|** ***www.GreatBaySoftware.com**** From exemys at exemys.com Sun Nov 22 02:44:06 2009 From: exemys at exemys.com (Exemys) Date: Sun Nov 22 02:44:14 2009 Subject: Pulse Meter with Cellular communication Message-ID: <35b847f35e5c94844d073655cec88ea7@www.hostmailing.com> This is a message in multipart MIME format. Your mail client should not be displaying this. Consider upgrading your mail client to view this message correctly. From cowens at greatbaysoftware.com Mon Nov 23 16:46:12 2009 From: cowens at greatbaysoftware.com (Charles Owens) Date: Mon Nov 23 16:46:18 2009 Subject: No "boot0" menu on Soekris, net5501 vs net4521 Message-ID: <4B0ABD27.2080501@greatbaysoftware.com> Hello, We're working with two different Soekris models (net5501 and net4521), working withFreeBSD 7.1 (nanobsd). We've found that the two models exhibit different boot behavior. Summary: the 4521 works fine, and the 5501 doesn't seem right. Here's what we see when we boot either: net4521 (BIOS ver 1.33) -- * "boot0" menu appears (letting you pick either of two FreeBSD slices) * OS loads properly from chosen or default slice net5501 (BIOS ver 1.33c) -- * "boot0" menu does _not_ appear. * system boots directly to slice 1 or 2, as chosen via BIOS option BootPartition Have others seen this behavior? For our application, we really need the 5501 to boot just like the 4521. Is this a bug (in BIOS, I'm guessing), or am I doing something wrong? It seems like there should be a way to clear the BootPartition setting, or set it to "MBR" or somesuch. Thanks very much, Charles -- **Charles Owens** *Great Bay Software******* From freebsd at sopwith.solgatos.com Tue Nov 24 05:14:34 2009 From: freebsd at sopwith.solgatos.com (Dieter) Date: Tue Nov 24 05:14:41 2009 Subject: PCIe-x1 SATA controllers (was: Re: Adaptec 1405 on FreeBSD ) In-Reply-To: Your message of "Tue, 17 Nov 2009 12:34:38 +0200." <4B027C3E.7020700@FreeBSD.org> Message-ID: <200911240257.CAA21330@sopwith.solgatos.com> In message <4B027C3E.7020700@FreeBSD.org>, Alexander Motin writes: > >>>>> - SiI3124-based - fast and functional. It is actually PCI-X one, but > >>>>> there are many boards with built-in PCIe bridges. > >>> Do any of these fit in a x1 slot? > >> I was surprised, but yes. > > > > My google-fu fails me. Any make/model, URLs, or keywords? > > Syba PCI Express SATA II 4 x Ports RAID Controller Card SY-PEX40008 Does anyone other than Syba make these? I'm a bit leery of Syba after my experience with some of their other fine products. Reviews on newegg say it "Gets a bit hot" and "gets quite hot under load", despite that big heatsink. http://www.newegg.com/Product/ProductReview.aspx?Item=N82E16816124027 ---------- > The interesting fact I have seen yesterday, SiI3132 is able to read > 150MB/s, but write 170MB/s. I am not PCIe expert, but looks like > transfer capabilities could be asymmetric. Also, and as soon as PCIe is > duplex, I've also seen 110MB/s read from one drive, plus 100MB/s write > to another, running at the same time. Seems odd. ---------- >From what I can see, FreeBSD does not support the Marvell 88SE61xx SATA controllers? For example, the SATA2-PCIE1x12 has 4 SATA ports + 1 PATA channel, for US$30.13 http://www.span.com/product_info.php?cPath=24_714_2502&products_id=16957 There is a similar SATA2-PCIE1X11 board with all ports internal. http://en.wikipedia.org/wiki/List_of_Marvell_Technology_Group_chipsets points to a patch for OpenBSD: http://www.webservertalk.com/message2133676.html and apparently penguinix supports them. ---------- Then we have this oddball, 2 SATA-300 ports + 2 SATA-150 ports: SYBA SY-PEX40013 http://www.newegg.com/Product/Product.aspx?Item=N82E16816124029 From mav at FreeBSD.org Tue Nov 24 09:00:15 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Nov 24 09:00:21 2009 Subject: PCIe-x1 SATA controllers (was: Re: Adaptec 1405 on FreeBSD ) In-Reply-To: <1259050982.00186650.1259040002@10.7.7.3> References: <1259050982.00186650.1259040002@10.7.7.3> Message-ID: <4B0BA09A.2070301@FreeBSD.org> Dieter wrote: >>From what I can see, FreeBSD does not support the Marvell 88SE61xx > SATA controllers? > > For example, the SATA2-PCIE1x12 has 4 SATA ports + 1 PATA channel, > for US$30.13 > http://www.span.com/product_info.php?cPath=24_714_2502&products_id=16957 > There is a similar SATA2-PCIE1X11 board with all ports internal. > > http://en.wikipedia.org/wiki/List_of_Marvell_Technology_Group_chipsets > points to a patch for OpenBSD: > http://www.webservertalk.com/message2133676.html > and apparently penguinix supports them. I have merged support for 88SE61xx SATA to 8-STABLE last days. I have no plans to merge it lower. -- Alexander Motin From korvus at comcast.net Tue Nov 24 17:53:31 2009 From: korvus at comcast.net (Steve Polyack) Date: Tue Nov 24 17:53:46 2009 Subject: Panic possibly related to glabel/geom and siis(4) Message-ID: <4B0C1A72.3000301@comcast.net> I have a system running 8.0-PRERELEASE with multiple drives and SATA port multipliers (siis controllers and PMPs). All of the attached drives are labeled via glabel(8) and then included into a ZFS pool. During some testing to determine how the system would react to a dead drive (simulated by physically removing a drive during operation), I was able to produce a panic. Now, I know that the SATA PMP and siis(4) code to handle and recover from device errors is incomplete, but I believe the crash may be particular to using glabel'd drives. Basically, after removing a drive while the zpool is in use and issues 'camcontrol reset' and 'rescan' on the appropriate bus, the physical device associated with the drive disappears. In this case: (pass5:siisch7:0:15:0): lost device (pass5:siisch7:0:15:0): removing device entry (ada2:siisch7:0:0:0): lost device and /dev/ada2 disappears. However, the associated glabel /dev/label/bigdisk07 remains. Since my ZFS pool is created based on the drive glabels, I believe this is why ZFS never notices the drives disappear either. Do glabels typically go away after a physical device is lost? Should this not be the case? After some runtime with the physical device missing, a kernel panic is produced: ada2:siisch7:0:0:0): Synchronize cache failed (ada2:siisch7:0:0:0): removing device entry Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 14 fault virtual address = 0x48 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff8035f375 stack pointer = 0x28:0xffffff800006db60 frame pointer = 0x28:0xffffff800006db70 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2 (g_event) [thread pid 2 tid 100014 ] Stopped at _mtx_lock_flags+0x15: lock cmpxchgq %rsi,0x18(%rdi) db> bt Tracing pid 2 tid 100014 td 0xffffff00014d4ab0 _mtx_lock_flags() at _mtx_lock_flags+0x15 vdev_geom_release() at vdev_geom_release+0x33 vdev_geom_orphan() at vdev_geom_orphan+0x15c g_run_events() at g_run_events+0x104 g_event_procbody() at g_event_procbody+0x55 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800006dd30, rbp = 0 --- I'm open to try patches and other suggestions. Thanks. From cowens at greatbaysoftware.com Wed Nov 25 11:24:42 2009 From: cowens at greatbaysoftware.com (Charles Owens) Date: Wed Nov 25 11:24:49 2009 Subject: USB keyboard flaky with PAE kernel, 7.1 In-Reply-To: <4B070F07.8010600@greatbaysoftware.com> References: <4B070F07.8010600@greatbaysoftware.com> Message-ID: <4B0D14CB.1010000@greatbaysoftware.com> Charles Owens wrote: > Howdy, > > I'm still digging into it, put preliminary testing is showing that with > a PAE-enabled 7.1-RELEASE-p8 kernel a USB keyboard functions only > occasionally, if you're lucky. This flakiness is being seen with > several different server models that we support (HP and IBM, all Xeon > based). If we boot a non-PAE kernel then the USB keyboard is rock solid. > > For what it's worth (probably little) I can run the same PAE kernel on > an old Pentium II system and a USB keyboard works fine. > > What is the best way to dig into this? Any and all assistance greatly > appreciated. I can provide remote access to a testbed of these systems > if useful. > Following is some detail for one of the systems, an IBM System x3550 M2. >From dmidecode: System Information Manufacturer: IBM Product Name: IBM System x -[7946AC1]- Version: 00 [root@dmz55 ~]# usbdevs -v Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 powered port 2 addr 2: low speed, power 100 mA, config 1, Comfort Curve Keyboard 2000(0x00dd), Microsoft(0x045e), rev 1.73 Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb2: addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered port 5 powered port 6 powered usbdevs: /dev/usb3: Input/output error usbdevs: /dev/usb4: Input/output error usbdevs: /dev/usb5: Input/output error Controller /dev/usb6: addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 addr 2: high speed, power 2 mA, config 2, IBM Composite Device-0(0x4012), IBM(0x04b3), rev 0.00 port 2 powered port 3 powered port 4 powered port 5 powered port 6 addr 3: high speed, power 450 mA, config 1, product 0x1a00(0x1a00), vendor 0x2001(0x2001), rev 10.01 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-p8 #3: Thu Nov 19 15:24:03 EST 2009 muck@dmz55.greatbaysoftware.com:/usr/obj/usr/src/sys/DMZ55 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU E5504 @ 2.00GHz (2000.08-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 = 6442450944 (6144 MB) avail memory = 4150349824 (3958 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 kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x588-0x58b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 28 at device 1.0 on pci0 pci11: on pcib1 pci11: at device 0.0 (no driver attached) pci11: at device 0.1 (no driver attached) pcib2: irq 29 at device 2.0 on pci0 pci16: on pcib2 pci16: at device 0.0 (no driver attached) pci16: at device 0.1 (no driver attached) pcib3: irq 24 at device 3.0 on pci0 pci21: on pcib3 pcib4: irq 30 at device 7.0 on pci0 pci26: on pcib4 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 0x20a0-0x20bf irq 17 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 0x2080-0x209f irq 18 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 ehci0: mem 0x9ba21400-0x9ba217ff irq 19 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: wrong number of companions (3 != 2) usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 6 ports with 6 removable, self powered pcib5: irq 16 at device 28.0 on pci0 pci1: on pcib5 mpt0: port 0x1000-0x10ff mem 0x9b910000-0x9b913fff,0x9b900000-0x9b90ffff irq 16 at device 0.0 on pci1 mpt0: [ITHREAD] mpt0: MPI Version=1.5.20.0 mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt0: 0 Active Volumes (2 Max) mpt0: 0 Hidden Drive Members (14 Max) pcib6: irq 16 at device 28.4 on pci0 pci6: on pcib6 pcib7: irq 16 at device 0.0 on pci6 pci7: on pcib7 vgapci0: mem 0x9a000000-0x9affffff,0x9b800000-0x9b803fff,0x9b000000-0x9b7fffff irq 16 at device 0.0 on pci7 uhci2: port 0x2060-0x207f irq 17 at device 29.0 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb3: on uhci2 usb3: USB revision 1.0 usb3: root hub problem, error=4 uhci3: port 0x2040-0x205f irq 18 at device 29.1 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 usb4: root hub problem, error=4 uhci4: port 0x2020-0x203f irq 19 at device 29.2 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 usb5: root hub problem, error=4 ehci1: mem 0x9ba21000-0x9ba213ff irq 17 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub3: on usb6 uhub3: 6 ports with 6 removable, self powered ukbd0: on uhub3 kbd2 at ukbd0 uhid0: on uhub3 uhid1: on uhub3 umass0: on uhub3 umass1: on uhub3 axe0: on uhub3 axe0: AX88172, bufsz 1536, boundary 64 miibus0: on axe0 rlphy0: PHY 3 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto axe0: WARNING: using obsoleted if_watchdog interface axe0: WARNING: using obsoleted IFF_NEEDSGIANT flag axe0: Ethernet address: 00:80:c8:38:15:ff pcib8: at device 30.0 on pci0 pci31: on pcib8 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x20f0-0x20ff,0x20e0-0x20ef irq 16 at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci1: port 0x2108-0x210f,0x2124-0x2127,0x2100-0x2107,0x2120-0x2123,0x20d0-0x20df,0x20c0-0x20cf irq 21 at device 31.5 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 p4tcc3: on cpu3 cpu3: on acpi0 est3: on cpu3 p4tcc3: on cpu3 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ukbd1: on uhub0 kbd3 at ukbd1 uhid2: on uhub0 Timecounters tick every 1.000 msec da0 at mpt0 bus 0 target 1 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 300.000MB/s transfers da0: Command Queueing Enabled da0: 286102MB (585937500 512 byte sectors: 255H 63S/T 36472C) cd0 at umass-sim0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 40.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present da1 at mpt0 bus 0 target 2 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 300.000MB/s transfers da1: Command Queueing Enabled da1: 286102MB (585937500 512 byte sectors: 255H 63S/T 36472C) SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! da2 at umass-sim1 bus 1 target 0 lun 0 da2: Removable Direct Access SCSI-0 device da2: 40.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da3 at umass-sim1 bus 1 target 0 lun 1 da3: Removable Direct Access SCSI-0 device da3: 40.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/da0s1a Charles Owens Great Bay Software From patpro at patpro.net Thu Nov 26 18:52:38 2009 From: patpro at patpro.net (Patrick Proniewski) Date: Thu Nov 26 18:52:45 2009 Subject: ATA check power status? Message-ID: <97F2DB2A-6515-4B0F-9146-A2059748A8B3@patpro.net> Hi all, I'm still playing with my WD Hard Drive WD10EADS (Caviar Green 1TB): > === START OF INFORMATION SECTION === > Device Model: WDC WD10EADS-00M2B0 > Serial Number: WD-WCAV51538624 > Firmware Version: 01.00A01 > User Capacity: 1,000,204,886,016 bytes > Device is: Not in smartctl database [for details use: -P > showall] > ATA Version is: 8 > ATA Standard is: Exact ATA specification draft version not indicated > Local Time is: Thu Nov 26 18:50:44 2009 CET > SMART support is: Available - device has SMART capability. > SMART support is: Enabled I'm trying to configure smartctl so that it won't wake the HD up for testing, using "-n standby": > /dev/ad6 -H -m root -a -n standby -o on -S on -s (S/../.././02| > L/../../6/03) But smartd won't accept: > smartd[94230]: Device: /dev/ad6, no ATA CHECK POWER STATUS support, > ignoring -n Directive I just don't know why. Is it: - the HD that doesn't support ata check power status? - the FreeBSD ata driver? - smartd that is too old for this new HD? regards, patpro From jguojun at sbcglobal.net Fri Nov 27 01:08:55 2009 From: jguojun at sbcglobal.net (Jin Guojun) Date: Fri Nov 27 01:09:08 2009 Subject: Panic possibly related to glabel/geom and siis(4) In-Reply-To: <4B0C1A72.3000301@comcast.net> Message-ID: <390534.50689.qm@web82207.mail.mud.yahoo.com> This is similar to what I have fight on last two weeks (was 8.0-RC USB/FS). My back trace from the panic is some different from yours, but the behave is the same. When access USB drives from 8.0-RC and 8.0-R will cause drives dead, vanish or reset, thus causing panic. >From both cases, it looks like a hotplug/automount related problem. --- On Tue, 11/24/09, Steve Polyack wrote: > From: Steve Polyack > Subject: Panic possibly related to glabel/geom and siis(4) > To: freebsd-hardware@freebsd.org, "freebsd-stable" , freebsd-geom@FreeBSD.org > Date: Tuesday, November 24, 2009, 5:40 PM > I have a system running > 8.0-PRERELEASE with multiple drives and SATA port > multipliers (siis controllers and PMPs). All of the > attached drives are labeled via glabel(8) and then included > into a ZFS pool. During some testing to determine how > the system would react to a dead drive (simulated by > physically removing a drive during operation), I was > able to produce a panic. > > Now, I know that the SATA PMP and siis(4) code to handle > and recover from device errors is incomplete, but I believe > the crash may be particular to using glabel'd drives. > Basically, after removing a drive while the zpool is in use > and issues 'camcontrol reset' and 'rescan' on the > appropriate bus, the physical device associated with the > drive disappears. In this case: > (pass5:siisch7:0:15:0): lost device > (pass5:siisch7:0:15:0): removing device entry > (ada2:siisch7:0:0:0): lost device > > and /dev/ada2 disappears. However, the associated > glabel /dev/label/bigdisk07 remains. Since my ZFS pool > is created based on the drive glabels, I believe this is why > ZFS never notices the drives disappear either. > > Do glabels typically go away after a physical device is > lost? Should this not be the case? > > > After some runtime with the physical device missing, a > kernel panic is produced: > > ada2:siisch7:0:0:0): Synchronize cache failed > (ada2:siisch7:0:0:0): removing device entry > > > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 14 > fault virtual address = 0x48 > fault code > = supervisor write data, page not present > instruction pointer = > 0x20:0xffffffff8035f375 > stack pointer > = 0x28:0xffffff800006db60 > frame pointer > = 0x28:0xffffff800006db70 > code segment = > base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, > def32 0, gran 1 > processor eflags = interrupt > enabled, resume, IOPL = 0 > current process = 2 > (g_event) > [thread pid 2 tid 100014 ] > Stopped at > _mtx_lock_flags+0x15: lock > cmpxchgq %rsi,0x18(%rdi) > db> bt > Tracing pid 2 tid 100014 td 0xffffff00014d4ab0 > _mtx_lock_flags() at _mtx_lock_flags+0x15 > vdev_geom_release() at vdev_geom_release+0x33 > vdev_geom_orphan() at vdev_geom_orphan+0x15c > g_run_events() at g_run_events+0x104 > g_event_procbody() at g_event_procbody+0x55 > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff800006dd30, rbp = 0 --- > > > I'm open to try patches and other suggestions. > Thanks. > _______________________________________________ > freebsd-hardware@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hardware > To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" >