/bin/sh core dumps on FreeBSD 7.2
Hi! Suddenly /bin/sh started to crash all the time with core dumps. I'm running FreeBSD 7.2-RELEASE-p4 (i386) and I have not updated anything lately. The /bin/sh binary seems to be untouched. It might be some hardware trouble, but the machine seems to run OK now. (I had to replace /bin/sh with a symlink to /rescue/sh.) I would like to track down the problem, but running sh I only get Segmentation fault: 11 (core dumped). I would be happy to run gdb and give you a backtrace. Any clues? Hans PS! I tried to run freebsd-update IDS to see if any files are broken, but it stops at Inspecting system... sha256: ///boot/kernel/utopia.ko.symbols: Input/output error ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /bin/sh core dumps on FreeBSD 7.2
Hans F. Nordhaug wrote: Hi! Suddenly /bin/sh started to crash all the time with core dumps. I'm running FreeBSD 7.2-RELEASE-p4 (i386) and I have not updated anything lately. The /bin/sh binary seems to be untouched. It might be some hardware trouble, but the machine seems to run OK now. (I had to replace /bin/sh with a symlink to /rescue/sh.) I would like to track down the problem, but running sh I only get Segmentation fault: 11 (core dumped). I would be happy to run gdb and give you a backtrace. Any clues? Hans PS! I tried to run freebsd-update IDS to see if any files are broken, but it stops at Inspecting system... sha256: ///boot/kernel/utopia.ko.symbols: Input/output error All of this points to a hardware problem. I think the best thing you can try is to manually get a hash fingerprint of your sh and compare it with another, known good copy. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /bin/sh core dumps on FreeBSD 7.2
Ivan Voras wrote: Hans F. Nordhaug wrote: Hi! Suddenly /bin/sh started to crash all the time with core dumps. I'm running FreeBSD 7.2-RELEASE-p4 (i386) and I have not updated anything lately. The /bin/sh binary seems to be untouched. It might be some hardware trouble, but the machine seems to run OK now. (I had to replace /bin/sh with a symlink to /rescue/sh.) I would like to track down the problem, but running sh I only get Segmentation fault: 11 (core dumped). I would be happy to run gdb and give you a backtrace. Any clues? Hans PS! I tried to run freebsd-update IDS to see if any files are broken, but it stops at Inspecting system... sha256: ///boot/kernel/utopia.ko.symbols: Input/output error All of this points to a hardware problem. Last time I saw things like this it was either a hard drive on the way out, or a PSU dying. Run some pre-OS tests (Ultimate boot cd or something) to try and get some results outside of the OS I think the best thing you can try is to manually get a hash fingerprint of your sh and compare it with another, known good copy. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /bin/sh core dumps on FreeBSD 7.2
On Thu, Nov 12, 2009 at 11:33:08AM +0100, Hans F. Nordhaug wrote:
Suddenly /bin/sh started to crash all the time with core dumps. I'm
running FreeBSD 7.2-RELEASE-p4 (i386) and I have not updated anything
lately. The /bin/sh binary seems to be untouched. It might be some
hardware trouble, but the machine seems to run OK now. (I had to
replace /bin/sh with a symlink to /rescue/sh.)
I would like to track down the problem, but running sh I only get
Segmentation fault: 11 (core dumped). I would be happy to run
gdb and give you a backtrace. Any clues?
PS! I tried to run freebsd-update IDS to see if any files are
broken, but it stops at
Inspecting system... sha256: ///boot/kernel/utopia.ko.symbols: Input/output
error
Hardware problem. Take your pick: bad RAM, bad hard disk, bad
motherboard, bad PSU, bad cabling.
You can rule out hard disk problems by installing smartmontools from
ports (sysutils/smartmontools). Please provide output from the
following command:
smartctl -a /dev/{disk}
Where {disk} is ad4, da0, or similar -- and NOT something like
ad8s1 or da0s1d.
If multiple disks are in your machine -- the one you want is the
disk you boot from (where /boot exists, and/or root filesystem).
I can teach you how to decode/read SMART statistics correctly.
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
SMART
Jeremy Chadwick wrote: I can teach you how to decode/read SMART statistics correctly. Actually, it would be good if you taught more than him :) I've always wondered how important are each of the dozen or so statistics and what indicates what... Here is for example my desktop drive: SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 087 083 006Pre-fail Always - 45398197 3 Spin_Up_Time0x0003 096 093 000Pre-fail Always - 0 4 Start_Stop_Count0x0032 100 100 020Old_age Always - 64 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 084 060 030Pre-fail Always - 247407473 9 Power_On_Hours 0x0032 089 089 000Old_age Always - 10155 10 Spin_Retry_Count0x0013 100 100 097Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020Old_age Always - 64 187 Reported_Uncorrect 0x0032 100 100 000Old_age Always - 0 189 High_Fly_Writes 0x003a 100 100 000Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 058 055 045Old_age Always - 42 (Lifetime Min/Max 37/44) 194 Temperature_Celsius 0x0022 042 045 000Old_age Always - 42 (0 20 0 0) 195 Hardware_ECC_Recovered 0x001a 062 059 000Old_age Always - 45398197 197 Current_Pending_Sector 0x0012 100 100 000Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000Old_age Offline - 0 199 UDMA_CRC_Error_Count0x003e 200 200 000Old_age Always - 0 200 Multi_Zone_Error_Rate 0x 100 253 000Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000Old_age Always - 0 I see many values exceeding threshold but since I see it so often on other drives I don't know what the threshold is for. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: SMART
On Nov 12, 2009, at 1:25 PM, Ivan Voras wrote: Actually, it would be good if you taught more than him :) I've always wondered how important are each of the dozen or so statistics and what indicates what... Here is for example my desktop drive: SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 087 083 006Pre-fail Always - 45398197 3 Spin_Up_Time0x0003 096 093 000Pre-fail Always - 0 4 Start_Stop_Count0x0032 100 100 020Old_age Always - 64 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 084 060 030Pre-fail Always - 247407473 9 Power_On_Hours 0x0032 089 089 000Old_age Always - 10155 10 Spin_Retry_Count0x0013 100 100 097Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020Old_age Always - 64 187 Reported_Uncorrect 0x0032 100 100 000Old_age Always - 0 189 High_Fly_Writes 0x003a 100 100 000Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 058 055 045Old_age Always - 42 (Lifetime Min/Max 37/44) 194 Temperature_Celsius 0x0022 042 045 000Old_age Always - 42 (0 20 0 0) 195 Hardware_ECC_Recovered 0x001a 062 059 000Old_age Always - 45398197 197 Current_Pending_Sector 0x0012 100 100 000Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000Old_age Offline - 0 199 UDMA_CRC_Error_Count0x003e 200 200 000Old_age Always - 0 200 Multi_Zone_Error_Rate 0x 100 253 000Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000Old_age Always - 0 I see many values exceeding threshold but since I see it so often on other drives I don't know what the threshold is for. None of the your values are exceeding the threshold - it works backwards. If the value is LOWER than the threshold, you might be in trouble. Also, judging by the raw read error rate, seek error rate and hardward ECC recovered, allow me to guess that this is a Seagate drive. :-) (Seagate drives, perhaps among others, use these raw values way differently than others. My Hitachi 7K1000.B has 0 on those.) Regards, Thomas___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: SMART
Thomas Backman wrote: On Nov 12, 2009, at 1:25 PM, Ivan Voras wrote: Actually, it would be good if you taught more than him :) I've always wondered how important are each of the dozen or so statistics and what indicates what... Here is for example my desktop drive: SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 087 083 006Pre-fail Always - 45398197 3 Spin_Up_Time0x0003 096 093 000Pre-fail Always - 0 4 Start_Stop_Count0x0032 100 100 020Old_age Always - 64 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 084 060 030Pre-fail Always - 247407473 9 Power_On_Hours 0x0032 089 089 000Old_age Always - 10155 10 Spin_Retry_Count0x0013 100 100 097Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020Old_age Always - 64 187 Reported_Uncorrect 0x0032 100 100 000Old_age Always - 0 189 High_Fly_Writes 0x003a 100 100 000Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 058 055 045Old_age Always - 42 (Lifetime Min/Max 37/44) 194 Temperature_Celsius 0x0022 042 045 000Old_age Always - 42 (0 20 0 0) 195 Hardware_ECC_Recovered 0x001a 062 059 000Old_age Always - 45398197 197 Current_Pending_Sector 0x0012 100 100 000Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000Old_age Offline - 0 199 UDMA_CRC_Error_Count0x003e 200 200 000Old_age Always - 0 200 Multi_Zone_Error_Rate 0x 100 253 000Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000Old_age Always - 0 I see many values exceeding threshold but since I see it so often on other drives I don't know what the threshold is for. None of the your values are exceeding the threshold - it works backwards. If the value is LOWER than the threshold, you might be in trouble. Good to know. Also, judging by the raw read error rate, seek error rate and hardward ECC recovered, allow me to guess that this is a Seagate drive. :-) (Seagate drives, perhaps among others, use these raw values way differently than others. My Hitachi 7K1000.B has 0 on those.) Yes, it's Seagate. Statistically I have the least problems with their drives. But I imagine that lack of standardization about these statistics very much limits the usability of SMART, right? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Problems moving hostapd AP config from 6.4 to 8.0RC2
Hi Sam, On Thu, 12 Nov 2009 03:53:17 pm Sam Leffler wrote: Setting HOSTAPD_CFLAGS directly is the intended mechanism. EAP_SERVER is the important one to define; past that you're just adding in some of the more esoteric mechanisms. I should probably enable it by default (it comes setup out of the box to do only WPA-PSK). Making a tunable that defaults to enabled sounds logical as the example files have references to it. However I can understand the concern in doing something different to the shrink wrapped edition :) It would possibly make a sensible companion setting for WPA_SUPPLICANT_EAPOL - HOSTAPD_EAP? Kind regards, Geoff -- ___ From the desk of Geoff Roberts Implementation Partner AUSTRALIAN PROJECTS PTY LIMITED S A F E K N O W L E D G E IT Security - Data Protection Email: supp...@apro.com.au NATIONAL HELP DESK SUPPORT Sydney 02 4231 4222 Melbourne 03 9017 8222 Adelaide 08 6461 6222 Perth 08 8463 1222 Brisbane 07 3137 1555 Hobart 03 6281 2555 Canberra 02 6112 8855 ___ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: SMART
On Thu, 12 Nov 2009 13:56:16 +0100 Ivan Voras ivo...@freebsd.org wrote: Yes, it's Seagate. Statistically I have the least problems with their drives. But I imagine that lack of standardization about these statistics very much limits the usability of SMART, right? The main problem with SMART appears to be that it's not an accurate predictor of drive failure, according to a study done at Google - see http://labs.google.com/papers/disk_failures.pdf -- Bruce Cran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: SMART
Bruce Cran wrote: On Thu, 12 Nov 2009 13:56:16 +0100 Ivan Voras ivo...@freebsd.org wrote: Yes, it's Seagate. Statistically I have the least problems with their drives. But I imagine that lack of standardization about these statistics very much limits the usability of SMART, right? The main problem with SMART appears to be that it's not an accurate predictor of drive failure, according to a study done at Google - see http://labs.google.com/papers/disk_failures.pdf I've seen it. But I don't remember if they addressed the problem of nonstandard interpretations of statistics? I do remember they said they buy from multiple drive vendors. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
can't boot table-8 on HP Proliant DL580 G5
Hi, the boot stops somewhare after probing ata0, so far playing with the BIOS (disabling stuff) does not help. BTW, linux boots ok (except it has problems with IPMI) So, any success stories there? danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: SMART
On 2009-11-12 14:35, Ivan Voras wrote: I've seen it. But I don't remember if they addressed the problem of nonstandard interpretations of statistics? Note the statistics you quoted are Vendor Specific SMART Attributes, so it is quite logical for different vendors to have different statistics. :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: SMART
Dimitry Andric wrote: On 2009-11-12 14:35, Ivan Voras wrote: I've seen it. But I don't remember if they addressed the problem of nonstandard interpretations of statistics? Note the statistics you quoted are Vendor Specific SMART Attributes, so it is quite logical for different vendors to have different statistics. :) I see your point :) Though I would hope that a statistics like: 1 Raw_Read_Error_Rate 0x000f 087 083 006Pre-fail Always - 45398197 would have an equivalent across vendors :) I know, it's too much to ask :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
8.0-rc2 meshmode breaks hostap mode on ath0
hi 8.0-rc2 802.11s breaks ap mode: - on the same interface - when mesh is on diffent channel how-to reproduce: ifconfig wlan0 create wlandev ath0 wlanmode hostap ifconfig wlan0 ssid bert channel 3 up ifconfig wlan1 create wlandev ath0 wlanmode mesh ifconfig wlan1 channel 3 meshid ernie up ifconfig == wlan0 = status: running ifconfig wlan1 channel 7 ifconfig == wlan0 = status: no carrier details below, kind regards, Marten dmesg: # dmesg 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: Tue Nov 10 20:24:18 CET 2009 r...@master:/usr/obj/nanobsd.full/usr/src/sys/KERNEL i386 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Enhanced Am486DX4/Am5x86 Write-Back (486-class CPU) Origin = AuthenticAMD Id = 0x494 Stepping = 4 Features=0x1FPU real memory = 67108864 (64 MB) avail memory = 55230464 (52 MB) wlan: mac acl policy registered kbd1 at kbdmux0 ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309 ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. *** WARNING: missing CPU_ELAN -- timekeeping may be wrong pcib0: AMD Elan SC520 host to PCI bridge pcibus 0 on motherboard pci0: PCI bus on pcib0 ath0: Atheros 5212 mem 0xa000-0xa000 irq 10 at device 16.0 on pci0 ath0: [ITHREAD] ath0: AR5212 mac 5.9 RF5112 phy 4.3 sis0: NatSemi DP8381[56] 10/100BaseTX port 0xe000-0xe0ff mem 0xa001-0xa0010fff irq 11 at device 18.0 on pci0 sis0: Silicon Revision: DP83816A miibus0: MII bus on sis0 nsphyter0: DP83815 10/100 media interface PHY 0 on miibus0 nsphyter0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:00:24:c5:59:8c sis0: [ITHREAD] sis1: NatSemi DP8381[56] 10/100BaseTX port 0xe100-0xe1ff mem 0xa0011000-0xa0011fff irq 5 at device 19.0 on pci0 sis1: Silicon Revision: DP83816A miibus1: MII bus on sis1 nsphyter1: DP83815 10/100 media interface PHY 0 on miibus1 nsphyter1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis1: Ethernet address: 00:00:24:c5:59:8d sis1: [ITHREAD] sis2: NatSemi DP8381[56] 10/100BaseTX port 0xe200-0xe2ff mem 0xa0012000-0xa0012fff irq 9 at device 20.0 on pci0 sis2: Silicon Revision: DP83816A miibus2: MII bus on sis2 nsphyter2: DP83815 10/100 media interface PHY 0 on miibus2 nsphyter2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis2: Ethernet address: 00:00:24:c5:59:8e sis2: [ITHREAD] cpu0 on motherboard isa0: ISA bus on motherboard pmtimer0 on isa0 orm0: ISA Option ROM at iomem 0xc8000-0xd0fff pnpid ORM on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to get the current command byte value. atrtc0: AT Real Time Clock at port 0x70 irq 8 on isa0 uart0: 16550 or compatible at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: [FILTER] uart0: console (9600,n,8,1) uart1: 16550 or compatible at port 0x2f8-0x2ff irq 3 on isa0 uart1: [FILTER] Timecounters tick every 1.000 msec ad0: 1923MB CF CARD 2GB Ver2.19K at ata0-master PIO4 Trying to mount root from ufs:/dev/ad0s1a Invalid time in real time clock. Check and reset the date immediately! wlan0: Ethernet address: 00:0b:6b:34:58:99 wlan1: Ethernet address: 00:0b:6b:34:58:99 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 done All buffers synced. Uptime: 9m38s Rebooting... 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: Tue Nov 10 20:24:18 CET 2009 r...@master:/usr/obj/nanobsd.full/usr/src/sys/KERNEL i386 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Am5x86 Write-Back (486-class CPU) Origin = AuthenticAMD Id = 0x4f4 Stepping = 4 Features=0x1FPU real memory = 67108864 (64 MB) avail memory = 55230464 (52 MB) wlan: mac acl policy registered kbd1 at kbdmux0 ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309 ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. *** WARNING: missing CPU_ELAN -- timekeeping may be wrong pcib0: AMD Elan SC520 host to PCI bridge pcibus 0 on motherboard pci0: PCI bus on pcib0 ath0: Atheros 5212 mem 0xa000-0xa000 irq 10 at device 16.0 on pci0 ath0: [ITHREAD] ath0: AR5212 mac 5.9 RF5112 phy 4.3 sis0: NatSemi DP8381[56] 10/100BaseTX port
8.0-rc2 dropped hardsupport
Support for the following devices seems not to be continued in 8.0 (and 7.2 and higher): - WRAP 1C - WRAP 2E (EOL) - ALIX 1C Both devices stopped booting as described in several postings and pr's. My question/suggestion to announce this in the 7.2 and 8.0 release notes. (or better to fix the issues) kind regards, Marten -- http://www.voedselbankleiden.nl Needs your help! http://martenvijn.nl http://bsd.wifisoft.org/nek/ The Network Event Kit http://opencommunitycamp.org OCC 2010 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: SMART
On Thu, 12 Nov 2009, Ivan Voras wrote: Dimitry Andric wrote: On 2009-11-12 14:35, Ivan Voras wrote: I've seen it. But I don't remember if they addressed the problem of nonstandard interpretations of statistics? Note the statistics you quoted are Vendor Specific SMART Attributes, so it is quite logical for different vendors to have different statistics. :) I see your point :) Though I would hope that a statistics like: 1 Raw_Read_Error_Rate 0x000f 087 083 006Pre-fail Always - 45398197 would have an equivalent across vendors :) I know, it's too much to ask :) True .. but all you really need to know is that as far as your disk vendor is concerned, your error rate is 87 (somethings), the worst it's ever been is 83 and if it were nearer 6 somethings, you should worry :) 9 Power_On_Hours 0x0032 089 089 000Old_age Always - 10155 Seagate says you're only 11% on the way to (mean) oblivion .. if you believe it should run 11.4 years. We had one 4GB IBM drive that did! cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
8.0-RC3 Available
The third and hopefully last of the Release Candidates for the FreeBSD 8.0 release cycle is now available. Unless something catastrophic comes up within the next couple of days we will begin the final builds for 8.0-RELEASE. There is one known issue with the igb(4) driver we are still deciding whether or not to fix as part of 8.0-RELEASE versus doing an Errata Notice for it some time after the release is out. It has been patched in head, and the SVN commit for it is r199192. If any of you are able to give that patch a try on a machine with the igb(4) NIC it would be appreciated. If you notice problems you can report them through the normal Gnats PR system or on the freebsd-current mailing list. I do cross-post announcements to freebsd-stable because this particular release is about to become a stable branch but when it comes to watching for issues related to the release most of the developers pay more attention to the freebsd-current list. ISO images for all supported architectures are available on the FTP sites, and a memory stick image is available for amd64/i386 architectures. For amd64/i386 architectures the cdrom and memstick images include the documentation packages but no other packages. The DVD image includes the packages that will probably be available on the official release media but is subject to change between now and release. For sparc64 there is now a livefs cdrom, disc1 includes the documentation packages, and the DVD image has the set of packages that currently build for sparc64 (which is a sub-set of the set provided for amd64/i386). If you are using csup/cvsup methods to update an older system the branch tag to use is RELENG_8_0. The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, 7.1-RELEASE, 7.2-RELEASE, 8.0-BETA1, 8.0-BETA2, 8.0-BETA3, 8.0-BETA4, 8.0-RC1 or 8.0-RC2 can upgrade as follows: # freebsd-update upgrade -r 8.0-RC3 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. Systems running 8.0-BETA3 may print the warning INDEX-OLD.all: Invalid arguments when downloading updates; this warning is a harmless bug (fixed in 8.0-BETA4) and can be safely ignored. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install At this point, users of systems being upgraded from FreeBSD 8.0-BETA2 or earlier will be prompted by freebsd-update to rebuild all third-party applications (e.g., ports installed from the ports tree) due to updates in system libraries. See: http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html for mode details. After updating installed third-party applications (and again, only if freebsd-update printed a message indicating that this was necessary), run freebsd-update again so that it can delete the old (no longer used) system libraries: # freebsd-update install Finally, reboot into 8.0-RC3: # shutdown -r now MD5/SHA256 checksums for the image files: MD5 (8.0-RC3-amd64-bootonly.iso) = 641881caa82ea85c118bc15fff12fce6 MD5 (8.0-RC3-amd64-disc1.iso) = 854c273b89792cd0366d5399df1034eb MD5 (8.0-RC3-amd64-dvd1.iso) = 9bd1bb2507bc2a3037bc321bb2724bd6 MD5 (8.0-RC3-amd64-livefs.iso) = c5f427c8bf823e10a5348935cec2d7ee MD5 (8.0-RC3-amd64-memstick.img) = 6af9e213914a58a5779715ae5882bd25 MD5 (8.0-RC3-i386-bootonly.iso) = dfaec92ae358ab780d317aa66482ca9e MD5 (8.0-RC3-i386-disc1.iso) = 460f6cfddaebee6ae59a7d5f73695246 MD5 (8.0-RC3-i386-dvd1.iso) = 98d3f65f2444a8745f787df5ce9e1f0c MD5 (8.0-RC3-i386-livefs.iso) = 5184b7f6403d1d24991533bde0e580ff MD5 (8.0-RC3-i386-memstick.img) = 8774ef1d6bdf541e440f2f8ed22a2493 MD5 (8.0-RC3-ia64-bootonly.iso) = fd0af8f34937cf7fc78ea0063252afb7 MD5 (8.0-RC3-ia64-disc1.iso) = 96313c25e53fc333c258ed675007f3d7 MD5 (8.0-RC3-ia64-disc2.iso) = 235714607a2805c396ece829839405be MD5 (8.0-RC3-ia64-disc3.iso) = 53fca9243ccc788190ca58d24f363cbe MD5 (8.0-RC3-ia64-dvd1.iso) = 4e24736ab50bc2227c72dbeab6869266 MD5 (8.0-RC3-ia64-livefs.iso) = b6d76cf77ed714631bf714ff78b8e950 MD5 (8.0-RC3-pc98-bootonly.iso) = 137d17ec3830b6ae831b6fb48adf86e0 MD5 (8.0-RC3-pc98-disc1.iso) = 3624b1f7b3a659a7454718e38b9a1ee0 MD5 (8.0-RC3-pc98-livefs.iso) = 29ed3786b2df1c2e72e45d1187f3e788 MD5 (8.0-RC3-powerpc-bootonly.iso) = e7d8508639dee4aed5e52a24d6e27b69 MD5 (8.0-RC3-powerpc-disc1.iso) = 1016ae7753db153b7be0f5d167f595b9 MD5 (8.0-RC3-powerpc-disc2.iso) = aec2400454631cc2eaecb6f618bfecc8 MD5 (8.0-RC3-powerpc-disc3.iso) = fe36d621ad4b6347f8ade9800ccfab7b MD5 (8.0-RC3-sparc64-bootonly.iso) = c35ddcb4dd050c793d89973eba02df72 MD5 (8.0-RC3-sparc64-disc1.iso) = 0d3855603ac868609fb882c32108 MD5 (8.0-RC3-sparc64-dvd1.iso) =
Re: 8.0-rc2 dropped hardsupport
In article 1091012.9283.79...@localhost you wrote: Support for the following devices seems not to be continued in 8.0 (and 7.2 and higher): - WRAP 1C - WRAP 2E (EOL) - ALIX 1C Both devices stopped booting as described in several postings and pr's. I have FreeBSD 8 running on WRAP and ALIX boards. LBA support for ALIX is broken in older versions of the BIOS. For LBA to work you need BIOS v0.99h. What problems are you seeing? Larry -- Larry Baird| http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: l...@gta.com | TEL 407-380-0220, FAX 407-380-6080 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-rc2 dropped hardsupport
On Thursday 12 November 2009 9:26:38 am Marten Vijn wrote: Support for the following devices seems not to be continued in 8.0 (and 7.2 and higher): - WRAP 1C - WRAP 2E (EOL) - ALIX 1C Both devices stopped booting as described in several postings and pr's. What are these devices? Random model numbers generally aren't enough context for most people to figure out what you are asking. Are these embedded ARM boards, storage controllers, wireless NICs, etc.? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-rc2 dropped hardsupport
John Baldwin wrote: On Thursday 12 November 2009 9:26:38 am Marten Vijn wrote: Support for the following devices seems not to be continued in 8.0 (and 7.2 and higher): - WRAP 1C - WRAP 2E (EOL) - ALIX 1C Both devices stopped booting as described in several postings and pr's. What are these devices? Random model numbers generally aren't enough context for most people to figure out what you are asking. Are these embedded ARM boards, storage controllers, wireless NICs, etc.? Small (embedded) x86 boards: http://www.pcengines.ch/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-rc2 dropped hardsupport
On Thu, Nov 12, 2009 at 10:35:17AM -0500, John Baldwin wrote: On Thursday 12 November 2009 9:26:38 am Marten Vijn wrote: Support for the following devices seems not to be continued in 8.0 (and 7.2 and higher): - WRAP 1C - WRAP 2E (EOL) - ALIX 1C Both devices stopped booting as described in several postings and pr's. What are these devices? Random model numbers generally aren't enough context for most people to figure out what you are asking. Are these embedded ARM boards, storage controllers, wireless NICs, etc.? The above are all PC Engines products. WRAP series: http://www.pcengines.ch/wrap.htm ALIX series: http://www.pcengines.ch/alix.htm -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-rc2 dropped hardsupport
Marten Vijn wrote: Support for the following devices seems not to be continued in 8.0 (and 7.2 and higher): - ALIX 1C For what it's worth, I've run the entire 7-STABLE and 8-CURRENT/STABLE development cycle kernels on a similarily equipped fit-pc with AMD Geode (I think it is LX800) without any issue at all. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-rc2 dropped hardsupport
At 11:01 AM 11/12/2009, Jeremy Chadwick wrote:
On Thu, Nov 12, 2009 at 10:35:17AM -0500, John Baldwin wrote:
On Thursday 12 November 2009 9:26:38 am Marten Vijn wrote:
Support for the following devices seems not to be continued in 8.0 (and
7.2 and higher):
- WRAP 1C
- WRAP 2E (EOL)
- ALIX 1C
Both devices stopped booting as described in several postings and pr's.
WRAP series: http://www.pcengines.ch/wrap.htm
ALIX series: http://www.pcengines.ch/alix.htm
Not sure about the older WRAP boards, but the current Alix boxes work
very well with RELENG_7 and RELENG_8.
There is a patch however for RELENG_7 that never got MFC'd for some
reason that I use as well. Phk ?
---Mike
--- sys/i386/i386/geode.c 2007-09-18 05:19:44.0 -0400
+++ sys/i386/i386/geode.c.good 2008-09-12 17:13:18.0 -0400
@@ -25,7 +25,7 @@
*/
#include sys/cdefs.h
-__FBSDID($FreeBSD: src/sys/i386/i386/geode.c,v 1.10 2007/09/18
09:19:44 phk Exp $);
+__FBSDID($FreeBSD: src/sys/i386/i386/geode.c,v 1.11 2008/02/10
19:14:42 phk Exp $);
#include sys/param.h
#include sys/systm.h
@@ -40,41 +40,50 @@
#include machine/pc/bios.h
static struct bios_oem bios_soekris = {
- { 0xf, 0xf1000 },
- {
- { Soekris, 0, 8 },/* Soekris Engineering. */
- { net4, 0, 8 }, /* net45xx */
- { comBIOS, 0, 54 }, /* comBIOS ver. 1.26a 20040819 ... */
- { NULL, 0, 0 },
- }
+{ 0xf, 0xf1000 },
+{
+ { Soekris, 0, 8 },/* Soekris Engineering. */
+ { net4, 0, 8 }, /* net45xx */
+ { comBIOS, 0, 54 }, /* comBIOS ver. 1.26a 20040819 ... */
+ { NULL, 0, 0 },
+}
};
static struct bios_oem bios_soekris_55 = {
- { 0xf, 0xf1000 },
- {
- { Soekris, 0, 8 },/* Soekris Engineering. */
- { net5, 0, 8 }, /* net5xxx */
- { comBIOS, 0, 54 }, /* comBIOS ver. 1.26a 20040819 ... */
- { NULL, 0, 0 },
- }
+{ 0xf, 0xf1000 },
+{
+ { Soekris, 0, 8 },/* Soekris Engineering. */
+ { net5, 0, 8 }, /* net5xxx */
+ { comBIOS, 0, 54 }, /* comBIOS ver. 1.26a 20040819 ... */
+ { NULL, 0, 0 },
+}
};
static struct bios_oem bios_pcengines = {
- { 0xf9000, 0xfa000 },
- {
- { PC Engines WRAP, 0, 28 }, /* PC Engines WRAP.1C v1.03 */
- { tinyBIOS, 0, 28 }, /* tinyBIOS V1.4a
(C)1997-2003 */
- { NULL, 0, 0 },
- }
+{ 0xf9000, 0xfa000 },
+{
+ { PC Engines WRAP, 0, 28 }, /* PC Engines WRAP.1C v1.03 */
+ { tinyBIOS, 0, 28 }, /* tinyBIOS V1.4a (C)1997-2003 */
+ { NULL, 0, 0 },
+}
+};
+
+static struct bios_oem bios_pcengines_55 = {
+{ 0xf9000, 0xfa000 },
+{
+ { PC Engines ALIX, 0, 28 }, /* PC Engines ALIX */
+ { tinyBIOS, 0, 28 }, /* tinyBIOS V1.4a (C)1997-2005 */
+ { NULL, 0, 0 },
+}
};
static struct bios_oem bios_advantech = {
- { 0xfe000, 0xff000 },
- {
- { PCM-582, 5, 33 }, /* PCM-5823 BIOS V1.12 ... */
- { GXm-Cx5530, -11, 35 }, /* 06/07/2002-GXm-Cx5530... */
- { NULL, 0, 0 },
- }
+{ 0xfe000, 0xff000 },
+{
+ { PCM-582, 5, 33 }, /* PCM-5823 BIOS V1.12 ... */
+ { GXm-Cx5530, -11, 35 }, /* 06/07/2002-GXm-Cx5530... */
+ { NULL, 0, 0 },
+}
};
static unsignedcba;
@@ -117,6 +126,11 @@
}
a = rdmsr(0x514c);
+ if (bit = 16) {
+ a += 0x80;
+ bit -= 16;
+ }
+
if (onoff)
outl(a, 1 bit);
else
@@ -256,11 +270,13 @@
* by the bios, see p161 in data sheet.
*/
cba = pci_read_config(self, 0x64, 4);
- printf(Geode CBA@ 0x%x\n, cba);
+ if (bootverbose)
+ printf(Geode CBA@ 0x%x\n, cba);
geode_counter = cba + 0x08;
outl(cba + 0x0d, 2);
- printf(Geode rev: %02x %02x\n,
- inb(cba + 0x3c), inb(cba + 0x3d));
+ if (bootverbose)
+ printf(Geode rev: %02x %02x\n,
+ inb(cba + 0x3c), inb(cba + 0x3d));
tc_init(geode_timecounter);
EVENTHANDLER_REGISTER(watchdog_list, geode_watchdog,
NULL, 0);
@@ -270,13 +286,14 @@
case 0x0510100b:
gpio = pci_read_config(self, PCIR_BAR(0), 4);
gpio = ~0x1f;
- printf(Geode GPIO@ = %x\n, gpio);
- if ( bios_oem_strings(bios_soekris,
- bios_oem,
ciss(4) not seeing multiple LUNs
Hello, I'm having a strange problem with HP hardware and the ciss(4) driver. I have an HP DL160 G6 server with FreeBSD 8 (cvsupped from RELENG_8 yesterday) with a Smart Array P212 SAS controller. There is an HP Storageworks 1/8 G2 autoloader (dmesg from the machine attached). The problem is I only get the sa0 device from the tape drive on LUN 0 of the device, the ch0 device which should be at LUN 1 is not detected. Camcontrol gives this output: # camcontrol devlist -v scbus0 on ciss0 bus 0: scbus1 on ciss0 bus 32: HP Ultrium 4-SCSI U51W at scbus1 target 4 lun 0 (sa0,pass0) scbus-1 on xpt0 bus 0: at scbus-1 target -1 lun -1 (xpt0) # camcontrol reportluns 1:4 2 LUNs found 0 1 If I try to force a rescan of device 4:1:1 (or any 4:1:x for that matter) it will happily report a device, but it will be the same device it sees on LUN 0. I tried the syscontrols reported in ciss(4) without any change. I could not find much ducumentation about this on HP site. The controller's documentation says it supports the autoloader, so it should be able to see it. Maybe I need to enable something in the contorller but I got no documetnation about that. Does someone has got an idea? Is this a problem with the ciss driver? Thanks in advance for any help! -- Guido Falsi m...@madpilot.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: 8.0RC2 top statistics seem broken
[snip] Load average and %CPU user are right, as are other global statistics. The load is produced by the 7z process (archivers/p7zip) which compresses some data in two threads but is credited with 0% CPU, though its runtime is correct (increments every second as it should in a CPU-bound process). It doesn't help if I expand / show individual threads. I believe this is related to multithreaded processes only. I saw this for intr kernel process. Singlethread processes eat CPU slightly less than on 7.2, however, I can not say is it statistic errors or real speedup. I saw the issue on SMP/ULE only and can not say anything about UP and 4BSD scheduler. Check out r197652 on stable/7. I had a similar problem where top was showing 0% for a CPU hog, but since I was unable to replicate it on CURRENT (and the ULE accounting code is different between releases) I only submitted for stable/7. I think the patch will be easy to apply by hand, though, to test it. Thanks, matthew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ciss(4) not seeing multiple LUNs
On Thu, Nov 12, 2009 at 05:33:15PM +0100, Guido Falsi wrote: Hello, I have an HP DL160 G6 server with FreeBSD 8 (cvsupped from RELENG_8 yesterday) with a Smart Array P212 SAS controller. There is an HP Storageworks 1/8 G2 autoloader (dmesg from the machine attached). Forgot the attachment, sorry. Here it comes. -- Guido Falsi m...@madpilot.net 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 #6: Thu Nov 12 11:57:04 CET 2009 r...@xxx.xxx.it:/usr/obj/usr/src/sys/UXIFI04 amd64 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU E5504 @ 2.00GHz (2000.08-MHz K8-class CPU) Origin = GenuineIntel Id = 0x106a5 Stepping = 5 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x9ce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4095668224 (3905 MB) ACPI APIC Table: HP ProLiant FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 18 cpu2 (AP): APIC ID: 20 cpu3 (AP): APIC ID: 22 ioapic0: Changing APIC ID to 1 ioapic1: Changing APIC ID to 3 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard kbd1 at kbdmux0 acpi0: HP ProLiant on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, bff0 (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci8: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 3.0 on pci0 pci7: ACPI PCI bus on pcib2 ciss0: HP Smart Array P212 port 0xe800-0xe8ff mem 0xfb80-0xfbbf,0xfbeff000-0xfbef irq 24 at device 0.0 on pci7 ciss0: PERFORMANT Transport ciss0: [ITHREAD] pcib3: ACPI PCI-PCI bridge at device 7.0 on pci0 pci6: ACPI PCI bus on pcib3 pcib4: ACPI PCI-PCI bridge at device 9.0 on pci0 pci5: ACPI PCI bus on pcib4 igb0: Intel(R) PRO/1000 Network Connection version - 1.7.3 port 0xd880-0xd89f mem 0xfb76-0xfb77,0xfb74-0xfb75,0xfb7b8000-0xfb7bbfff irq 32 at device 0.0 on pci5 igb0: Using MSIX interrupts with 3 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 00:26:55:80:53:fe igb1: Intel(R) PRO/1000 Network Connection version - 1.7.3 port 0xdc00-0xdc1f mem 0xfb7e-0xfb7f,0xfb7c-0xfb7d,0xfb7bc000-0xfb7b irq 42 at device 0.1 on pci5 igb1: Using MSIX interrupts with 3 vectors igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: Ethernet address: 00:26:55:80:53:ff pcib5: ACPI PCI-PCI bridge at device 10.0 on pci0 pci4: ACPI PCI bus on pcib5 pci0: base peripheral, interrupt controller at device 20.0 (no driver attached) pci0: base peripheral, interrupt controller at device 20.1 (no driver attached) pci0: base peripheral, interrupt controller at device 20.2 (no driver attached) uhci0: UHCI (generic) USB controller port 0xb800-0xb81f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2400 usbus0: UHCI (generic) USB controller on uhci0 ehci0: EHCI (generic) USB 2.0 controller mem 0xfa7f8000-0xfa7f83ff irq 18 at device 26.7 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: EHCI (generic) USB 2.0 controller on ehci0 pcib6: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci3: ACPI PCI bus on pcib6 pcib7: ACPI PCI-PCI bridge irq 16 at device 28.4 on pci0 pci2: ACPI PCI bus on pcib7 vgapci0: VGA-compatible display mem 0xf800-0xf8ff,0xfb6fc000-0xfb6f,0xfa80-0xfaff irq 16 at device 0.0 on pci2 uhci1: UHCI (generic) USB controller port 0xb880-0xb89f irq 23 at device 29.0 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2400 usbus2: UHCI (generic) USB controller on uhci1 uhci2: UHCI (generic) USB controller port 0xbc00-0xbc1f irq 19 at device 29.1 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x2400 usbus3: UHCI (generic) USB controller on uhci2 uhci3: UHCI (generic) USB controller port 0xc000-0xc01f irq 18 at device 29.2 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x2400 usbus4: UHCI (generic) USB controller on uhci3 ehci1: EHCI (generic) USB 2.0 controller mem 0xfa7fa000-0xfa7fa3ff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus5: EHCI version 1.0 usbus5: EHCI (generic) USB 2.0 controller on
Re: 8.0-rc2 dropped hardwaresupport
On Thu, 2009-11-12 at 15:21 +, Larry Baird wrote: In article 1091012.9283.79...@localhost you wrote: Support for the following devices seems not to be continued in 8.0 (and 7.2 and higher): - WRAP 1C - WRAP 2E (EOL) - ALIX 1C Both devices stopped booting as described in several postings and pr's. I have FreeBSD 8 running on WRAP and ALIX boards. LBA support for ALIX is broken in older versions of the BIOS. For LBA to work you need BIOS v0.99h. What problems are you seeing? Larry I did some more testing, and I made an error on the ALIX 1C since it does boot but it hangs on devd but for WRAP 1C and 2E: PC Engines WRAP.2B/2C v1.11 640 KB Base Memory 130048 KB Extended Memory 01F0 Master 044A CF CARD 2GB Phys C/H/S 3909/16/63 Log C/H/S 977/64/63 1 FreeBSD 2 FreeBSD F6 PXE Boot: 1 Here it ends Would you recommend to downgrade the bios? I have version 1.11 on all boards. thanks Marten -- http://www.voedselbankleiden.nl needs your help! http://martenvijn.nl http://bsd.wifisoft.org/nek/ http://opencommunitycamp.org OCC 2010 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: SMART
On Thu, Nov 12, 2009 at 01:25:12PM +0100, Ivan Voras wrote: Jeremy Chadwick wrote: I can teach you how to decode/read SMART statistics correctly. Actually, it would be good if you taught more than him :) I've always wondered how important are each of the dozen or so statistics and what indicates what... I started a write-up but after writing about 300 lines realised that if I continued the details would eventually be lost in the Sea of Information Chaos that is a mailing list. :-) I've gone over how to read SMART data 3 separate times in the past 2 months (at work, on a public forum, and in private mail), so this would be the 4th... I'll work on writing an actual HTML document to put up on my web site and will respond with the URL once I finish it. Sorry for the yeah sure I can help you read this data response followed by what will probably be labelled as an excuse by some. Admittedly reading the output is pretty simple, but getting familiar with what the output looks like (on a per-vendor basis) takes exposure to all sorts of drives, ditto with F/W bugs and so on. In general though, don't let anyone tell you SMART is worthless. The overall health assessment status is generally worthless, but the per-attribute data is of great use. Don't let anyone tell you the weighted/adjusted values (VALUE/WORST/THRESH) are useless either; in some cases they're all you can safely rely on. Don't damn SMART when it's actually the manufacturers which need to be spanked for setting such unreasonable health failure thresholds. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-rc2 dropped hardwaresupport
Marten, I did some more testing, and I made an error on the ALIX 1C since it does boot but it hangs on devd but for WRAP 1C and 2E: PC Engines WRAP.2B/2C v1.11 640 KB Base Memory 130048 KB Extended Memory 01F0 Master 044A CF CARD 2GB Phys C/H/S 3909/16/63 Log C/H/S 977/64/63 1 FreeBSD 2 FreeBSD F6 PXE Boot: 1 Here it ends Would you recommend to downgrade the bios? I have version 1.11 on all boards. The 0.99h BIOS is for ALIX boards. I am running v1.11 on my WRAP boards. PC Engines WRAP.1C/1D/1E v1.11 640 KB Base Memory 130048 KB Extended Memory Looking at your geometry, I would recommend verifing that the BIOS is set for LBA mode (not CHS). If you change mode, you will probably need to reinstall FreeBSD. Larry -- Larry Baird| http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: l...@gta.com | TEL 407-380-0220, FAX 407-380-6080 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0RC2 top statistics seem broken
On Thu, Nov 12, 2009 at 08:42:28AM -0800, Matthew Fleming wrote:
[snip]
Load average and %CPU user are right, as are other global
statistics.
The load is produced by the 7z process (archivers/p7zip) which
compresses some data in two threads but is credited with 0% CPU,
though
its runtime is correct (increments every second as it should in a
CPU-bound process). It doesn't help if I expand / show individual
threads.
I believe this is related to multithreaded processes only. I saw this
for
intr kernel process. Singlethread processes eat CPU slightly less than
on 7.2, however, I can not say is it statistic errors or real speedup.
I saw the issue on SMP/ULE only and can not say anything about UP and
4BSD scheduler.
Check out r197652 on stable/7. I had a similar problem where top was
showing 0% for a CPU hog, but since I was unable to replicate it on
CURRENT (and the ULE accounting code is different between releases) I
only submitted for stable/7. I think the patch will be easy to apply by
hand, though, to test it.
Thank you very much. I have applied your patch and it fixes the bug:
CPU 0: 22.0% user, 0.0% nice, 4.9% system, 0.0% interrupt, 73.2% idle
CPU 1: 1.2% user, 0.0% nice, 1.2% system, 4.9% interrupt, 92.7% idle
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND
11 root 2 171 ki31 0K32K CPU00 12:11 165.77% idle
1338 nobody 1 44 -10 439M 433M kqread 0 0:24 14.45% nginx
1339 nobody 1 44 -10 439M 433M kqread 0 0:23 12.89% nginx
12 root 15 -60- 0K 240K WAIT0 0:09 4.39% intr
CPU 0: 16.2% user, 0.0% nice, 8.5% system, 0.8% interrupt, 74.5% idle
CPU 1: 1.2% user, 0.0% nice, 1.9% system, 4.2% interrupt, 92.7% idle
PID USERNAMEPRI NICE SIZERES STATE C TIME WCPU COMMAND
11 root171 ki31 0K32K RUN 1 6:39 88.96% {idle: cpu1}
11 root171 ki31 0K32K RUN 0 6:11 77.59% {idle: cpu0}
1338 nobody 44 -10 439M 433M CPU00 0:27 14.45% nginx
1339 nobody 44 -10 439M 433M RUN 1 0:26 14.26% nginx
12 root-68- 0K 240K WAIT1 0:09 4.69% {irq19: bge0}
The patch against 8.0-PREREALSE is attached.
--
Igor Sysoev
http://sysoev.ru/en/
--- sys/kern/sched_ule.c2009-11-02 09:25:28.0 +0300
+++ sys/kern/sched_ule.c2009-11-12 21:53:45.0 +0300
@@ -103,6 +103,7 @@
u_int ts_slptime; /* Number of ticks we vol. slept */
u_int ts_runtime; /* Number of ticks we were running */
int ts_ltick; /* Last tick that we were running on */
+ int ts_incrtick;/* Last tick that we incremented on */
int ts_ftick; /* First tick that we were running on */
int ts_ticks; /* Tick count */
#ifdef KTR
@@ -1991,6 +1992,7 @@
*/
ts2-ts_ticks = ts-ts_ticks;
ts2-ts_ltick = ts-ts_ltick;
+ ts2-ts_incrtick = ts-ts_incrtick;
ts2-ts_ftick = ts-ts_ftick;
child-td_user_pri = td-td_user_pri;
child-td_base_user_pri = td-td_base_user_pri;
@@ -2182,11 +2184,12 @@
* Ticks is updated asynchronously on a single cpu. Check here to
* avoid incrementing ts_ticks multiple times in a single tick.
*/
- if (ts-ts_ltick == ticks)
+ if (ts-ts_incrtick == ticks)
return;
/* Adjust ticks for pctcpu */
ts-ts_ticks += 1 SCHED_TICK_SHIFT;
ts-ts_ltick = ticks;
+ ts-ts_incrtick = ticks;
/*
* Update if we've exceeded our desired tick threshhold by over one
* second.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
82573 xfers pause, no watchdog timeouts, DCGDIS ineffective (7.2-R)
We have servers with dual 82573 NICs that work well during low-throughput activity, but during high-volume activity, they pause shortly after transfers start and do not recover. Other sessions to the system are not affected. These systems are being repurposed, jumping from 6.3 to 7.2. The same system and its kin do not exhibit the symptom under 6.3-RELEASE-p13. The symptoms appear under freebsd-updated 7.2-RELEASE GENERIC kernel with no tuning. Previously, we've been using DCGDIS.EXE (from Jack Vogel) for this symptom. The first system to be repurposed accepts DCGDIS with 'Updated' and subsequent 'update not needed', with no relief. Notably, there are no watchdog timeout errors - unlike our various Supermicro models still running FreeBSD 6.x. All of our other 7.x Supermicro flavors had already received the flash update and haven't show the symptom. Details follow. Kernel: rand# uname -a FreeBSD rand.acsalaska.net 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Fri Oct 2 12:21:39 UTC 2009 r...@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 sysctls: rand# sysctl dev.em dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.6 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 subdevice=0x108c class=0x02 dev.em.0.%parent: pci13 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 6.9.6 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=0 dev.em.1.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 subdevice=0x108c class=0x02 dev.em.1.%parent: pci14 dev.em.1.debug: -1 dev.em.1.stats: -1 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 kenv: rand# kenv | grep smbios | egrep -v 'socket|serial|uuid|tag|0123456789' smbios.bios.reldate=03/05/2008 smbios.bios.vendor=Phoenix Technologies LTD smbios.bios.version=6.00 smbios.chassis.maker=Supermicro smbios.planar.maker=Supermicro smbios.planar.product=PDSMi smbios.planar.version=PCB Version smbios.system.maker=Supermicro smbios.system.product=PDSMi The system is not yet production, so I can invasively abuse it if needed. The other systems are in production under 6.3-RELEASE-p13 and can also be inspected. Any pointers appreciated. Royce ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 82573 xfers pause, no watchdog timeouts, DCGDIS ineffective (7.2-R)
On Thu, Nov 12, 2009 at 10:36:16AM -0900, Royce Williams wrote: We have servers with dual 82573 NICs that work well during low-throughput activity, but during high-volume activity, they pause shortly after transfers start and do not recover. Other sessions to the system are not affected. Please define low-throughput and high-volume if you could; it might help folks determine where the threshold is for problems. These systems are being repurposed, jumping from 6.3 to 7.2. The same system and its kin do not exhibit the symptom under 6.3-RELEASE-p13. The symptoms appear under freebsd-updated 7.2-RELEASE GENERIC kernel with no tuning. Previously, we've been using DCGDIS.EXE (from Jack Vogel) for this symptom. The first system to be repurposed accepts DCGDIS with 'Updated' and subsequent 'update not needed', with no relief. Notably, there are no watchdog timeout errors - unlike our various Supermicro models still running FreeBSD 6.x. All of our other 7.x Supermicro flavors had already received the flash update and haven't show the symptom. Details follow. Kernel: rand# uname -a FreeBSD rand.acsalaska.net 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Fri Oct 2 12:21:39 UTC 2009 r...@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 sysctls: rand# sysctl dev.em dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.6 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 subdevice=0x108c class=0x02 dev.em.0.%parent: pci13 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 6.9.6 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=0 dev.em.1.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 subdevice=0x108c class=0x02 dev.em.1.%parent: pci14 dev.em.1.debug: -1 dev.em.1.stats: -1 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 kenv: rand# kenv | grep smbios | egrep -v 'socket|serial|uuid|tag|0123456789' smbios.bios.reldate=03/05/2008 smbios.bios.vendor=Phoenix Technologies LTD smbios.bios.version=6.00 smbios.chassis.maker=Supermicro smbios.planar.maker=Supermicro smbios.planar.product=PDSMi smbios.planar.version=PCB Version smbios.system.maker=Supermicro smbios.system.product=PDSMi The system is not yet production, so I can invasively abuse it if needed. The other systems are in production under 6.3-RELEASE-p13 and can also be inspected. Any pointers appreciated. Royce For what it's worth as a comparison base: We use the following Supermicro SuperServers, and can confirm that no such issues occur for us using RELENG_6 nor RELENG_7 on the following hardware: Supermicro SuperServer 5015B-MTB - amd64 - Intel 82573V + Intel 82573L Supermicro SuperServer 5015M-T+B - amd64 - Intel 82573V + Intel 82573L Supermicro SuperServer 5015M-T+B - amd64 - Intel 82573V + Intel 82573L Supermicro SuperServer 5015M-T+B - i386 - Intel 82573V + Intel 82573L Supermicro SuperServer 5015M-T+B - i386 - Intel 82573V + Intel 82573L The 5015B-MTB system presently runs RELENG_8 -- no issues there either. Relevant server configuration and network setup details: - All machines use pf(4). - All emX devices are configured for autoneg. - All emX devices use RXCSUM, TXCSUM, and TSO4. - We do not use polling. - All machines use both NICs simultaneously at all times. - All machines connected to an HP ProCurve 2626 switch (100mbit, full-duplex ports, all autoneg). - We do not use Jumbo frames. - No add-in cards (PCI, PCI-X, nor PCIe) are used in the systems. - All of the systems had DCGDIS.EXE run on them; no EEPROM settings were changed, indicating the from-the-Intel-factory MANC register in question was set properly. Relevant throughput details per box: - em0 pushes ~600-1000kbit/sec at all times. - em1 pushes ~100-200kbit/sec at all times. - During nightly maintenance (backups), em1 pushes ~2-3mbit/sec for a variable amount of time. - For a full level 0 backup (which I've done numerous times), em1 pushes 60-70mbit/sec without issues. I've compared your sysctl dev.em output to that of our 5015M-T+B systems (which use the PDSMi+, not the PDSMi, but whatever), and ours is 100% identical. All of our 5015M-T+B systems are using BIOS 1.3, and the 5015B-MTB system is using BIOS 1.30. If you'd like, I can provide the exact BIOS settings we use on the machines in question; they do deviate from the factory defaults a slight bit, but none of the adjustments are tweaks for performance or otherwise (just disabling things which we don't use, etc.). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking
Re: 82573 xfers pause, no watchdog timeouts, DCGDIS ineffective (7.2-R)
It is critically important on these systems that you get the latest BIOS on them, so maybe that's the difference between you two. I am going to be putting out a new em driver to CURRENT soon, it might be an option to try that as well, it sounds like a hang, management/os race in the driver is a possibility. Jack On Thu, Nov 12, 2009 at 12:47 PM, Jeremy Chadwick free...@jdc.parodius.comwrote: On Thu, Nov 12, 2009 at 10:36:16AM -0900, Royce Williams wrote: We have servers with dual 82573 NICs that work well during low-throughput activity, but during high-volume activity, they pause shortly after transfers start and do not recover. Other sessions to the system are not affected. Please define low-throughput and high-volume if you could; it might help folks determine where the threshold is for problems. These systems are being repurposed, jumping from 6.3 to 7.2. The same system and its kin do not exhibit the symptom under 6.3-RELEASE-p13. The symptoms appear under freebsd-updated 7.2-RELEASE GENERIC kernel with no tuning. Previously, we've been using DCGDIS.EXE (from Jack Vogel) for this symptom. The first system to be repurposed accepts DCGDIS with 'Updated' and subsequent 'update not needed', with no relief. Notably, there are no watchdog timeout errors - unlike our various Supermicro models still running FreeBSD 6.x. All of our other 7.x Supermicro flavors had already received the flash update and haven't show the symptom. Details follow. Kernel: rand# uname -a FreeBSD rand.acsalaska.net 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Fri Oct 2 12:21:39 UTC 2009 r...@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 sysctls: rand# sysctl dev.em dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.6 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 subdevice=0x108c class=0x02 dev.em.0.%parent: pci13 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 6.9.6 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=0 dev.em.1.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 subdevice=0x108c class=0x02 dev.em.1.%parent: pci14 dev.em.1.debug: -1 dev.em.1.stats: -1 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 kenv: rand# kenv | grep smbios | egrep -v 'socket|serial|uuid|tag|0123456789' smbios.bios.reldate=03/05/2008 smbios.bios.vendor=Phoenix Technologies LTD smbios.bios.version=6.00 smbios.chassis.maker=Supermicro smbios.planar.maker=Supermicro smbios.planar.product=PDSMi smbios.planar.version=PCB Version smbios.system.maker=Supermicro smbios.system.product=PDSMi The system is not yet production, so I can invasively abuse it if needed. The other systems are in production under 6.3-RELEASE-p13 and can also be inspected. Any pointers appreciated. Royce For what it's worth as a comparison base: We use the following Supermicro SuperServers, and can confirm that no such issues occur for us using RELENG_6 nor RELENG_7 on the following hardware: Supermicro SuperServer 5015B-MTB - amd64 - Intel 82573V + Intel 82573L Supermicro SuperServer 5015M-T+B - amd64 - Intel 82573V + Intel 82573L Supermicro SuperServer 5015M-T+B - amd64 - Intel 82573V + Intel 82573L Supermicro SuperServer 5015M-T+B - i386 - Intel 82573V + Intel 82573L Supermicro SuperServer 5015M-T+B - i386 - Intel 82573V + Intel 82573L The 5015B-MTB system presently runs RELENG_8 -- no issues there either. Relevant server configuration and network setup details: - All machines use pf(4). - All emX devices are configured for autoneg. - All emX devices use RXCSUM, TXCSUM, and TSO4. - We do not use polling. - All machines use both NICs simultaneously at all times. - All machines connected to an HP ProCurve 2626 switch (100mbit, full-duplex ports, all autoneg). - We do not use Jumbo frames. - No add-in cards (PCI, PCI-X, nor PCIe) are used in the systems. - All of the systems had DCGDIS.EXE run on them; no EEPROM settings were changed, indicating the from-the-Intel-factory MANC register in question was set properly. Relevant throughput details per box: - em0 pushes ~600-1000kbit/sec at all times. - em1 pushes ~100-200kbit/sec at all times. - During nightly maintenance (backups), em1 pushes ~2-3mbit/sec for a variable amount of time. - For a full level 0 backup (which I've done numerous times), em1 pushes 60-70mbit/sec without issues. I've compared your sysctl dev.em output to that of our 5015M-T+B systems (which use the PDSMi+, not the PDSMi, but whatever), and ours is 100%
FreeBSD 7.x hang-on-boot on Dell 1950
I have a dell 1950 here on the floor. Since 1950 seems to refer to a lot of things with a lot of configurations, I'm going to attempt to narrow that down a bit. It's got 2x 2.33Ghz dual core pentiums (stepping 06-0F-6 according to the bios) in it and it has an SAS RAID card that FreeBSD recognises. I've upgraded the BIOS to 2.6.1. It has two SAS 70G drives in a RAID 1 configuration and it has a DVD (although it will only boot from CDs). If it helps, it's between 2 and 3 years old, I think. If I allow the machine to boot normally, it stopps after checking the floppy (there is no floppy) with the following message: fdc0: floppy drive controller port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 If I boot the machine without ACPI, it seems to stop at the same place (stopping after having checked the ata controller, which checks right before the floppy) If I boot the machine verbose, I get no more information --- it stopps at the same place. I have tried this (so far) with 7.2-R and 7.1-R. Both do the same thing. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7.x hang-on-boot on Dell 1950
On Thu, Nov 12, 2009 at 2:46 PM, Zaphod Beeblebrox zbee...@gmail.comwrote: I have a dell 1950 here on the floor. Since 1950 seems to refer to a lot of things with a lot of configurations, I'm going to attempt to narrow that down a bit. It's got 2x 2.33Ghz dual core pentiums (stepping 06-0F-6 according to the bios) in it and it has an SAS RAID card that FreeBSD recognises. I've upgraded the BIOS to 2.6.1. It has two SAS 70G drives in a RAID 1 configuration and it has a DVD (although it will only boot from CDs). If it helps, it's between 2 and 3 years old, I think. If I allow the machine to boot normally, it stopps after checking the floppy (there is no floppy) with the following message: fdc0: floppy drive controller port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 If I boot the machine without ACPI, it seems to stop at the same place (stopping after having checked the ata controller, which checks right before the floppy) If I boot the machine verbose, I get no more information --- it stopps at the same place. I have tried this (so far) with 7.2-R and 7.1-R. Both do the same thing. Can you disable the floppy drive and controller? There are usually separate options on different screens. -- Adam Vande More ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: SMART
On Thu, Nov 12, 2009 at 09:44:28AM -0800, Jeremy Chadwick wrote: On Thu, Nov 12, 2009 at 01:25:12PM +0100, Ivan Voras wrote: Jeremy Chadwick wrote: I can teach you how to decode/read SMART statistics correctly. Actually, it would be good if you taught more than him :) I've always wondered how important are each of the dozen or so statistics and what indicates what... I'll work on writing an actual HTML document to put up on my web site and will respond with the URL once I finish it. Isn't this sufficient? http://en.wikipedia.org/wiki/S.M.A.R.T.#Known_ATA_S.M.A.R.T._attributes If not, could you make the changes on wikipedia? This isn't a FreeBSD-specific topic, and the larger community would benefit from such documentation. -- Rick C. Petty ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
KVM tips for bsd as guest?
Downloaded iso, but qemu barfs when trying to install --- loads kernel but panics during boot of 7.2 ( and 8.0-rc3) install ISOs. I am trying to set up a bsd guest ... Host OS is debian. Virtualbox installed no problem. I am looking for a general how-to if there is one out there( tried searching didn't find it). Rudy -- MonkeyBrains.net -- Rudy 415.425.9825 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: KVM tips for bsd as guest?
On Thu, Nov 12, 2009 at 22:42, Rudy cra...@monkeybrains.net wrote: Downloaded iso, but qemu barfs when trying to install --- loads kernel but panics during boot of 7.2 ( and 8.0-rc3) install ISOs. I am trying to set up a bsd guest ... Host OS is debian. Virtualbox installed no problem. I am looking for a general how-to if there is one out there( tried searching didn't find it). What about sending the kernel panic message (with backtrace)? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-RC3 Available
On 2009-11-12T10:38:37-0500, Ken Smith kensm...@buffalo.edu wrote: ISO images for all supported architectures are available on the FTP sites, and a memory stick image is available for amd64/i386 architectures. For amd64/i386 architectures the cdrom and memstick images include the documentation packages but no other packages. I just did a successful minimal install on a Dell laptop from the amd64 memstick RC3 media. I created the memstick like this on a GNU/Linux machine: dd if=8.0-RC3-amd64-memstick.img of=/dev/sda bs=10240 conv=sync -- Kenyon Ralph signature.asc Description: Digital signature
FreeBSD 7.x hang-on-boot on Dell 1950
On Thu, Nov 12, 2009 at 4:27 PM, Adam Vande More amvandem...@gmail.comwrote: On Thu, Nov 12, 2009 at 2:46 PM, Zaphod Beeblebrox zbee...@gmail.comwrote: fdc0: floppy drive controller port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 If I boot the machine without ACPI, it seems to stop at the same place (stopping after having checked the ata controller, which checks right before the floppy) If I boot the machine verbose, I get no more information --- it stopps at the same place. Can you disable the floppy drive and controller? There are usually separate options on different screens. I've now verified that 8.0-RC3 does the same thing, BTW. Anyways... no. There is no floppy option in the BIOS. It's not in any of the sub-menus (which is how Dell's BIOS is organized). I'm also not-so-sure that the floppy is where it's stopping because the non-ACPI boot doesn't mention the floppy at all ... leading me to believe it's whatever is checked after the floppy that is at fault... but even the verbose boot doesn't let me know what that might be. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
how to mirror cvs or svn with rsync
Hi everybody! How do I mirror FreeBSD sources (CVS or SVN) with rsync? This is the first time I have to use rsync, and its man page really makes me confused. I would really appreciate your help. Regards, Nik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /bin/sh core dumps on FreeBSD 7.2
* Jeremy Chadwick free...@jdc.parodius.com [2009-11-12]:
On Thu, Nov 12, 2009 at 11:33:08AM +0100, Hans F. Nordhaug wrote:
Suddenly /bin/sh started to crash all the time with core dumps. I'm
running FreeBSD 7.2-RELEASE-p4 (i386) and I have not updated anything
lately. The /bin/sh binary seems to be untouched. It might be some
hardware trouble, but the machine seems to run OK now. (I had to
replace /bin/sh with a symlink to /rescue/sh.)
I would like to track down the problem, but running sh I only get
Segmentation fault: 11 (core dumped). I would be happy to run
gdb and give you a backtrace. Any clues?
PS! I tried to run freebsd-update IDS to see if any files are
broken, but it stops at
Inspecting system... sha256: ///boot/kernel/utopia.ko.symbols: Input/output
error
Hardware problem. Take your pick: bad RAM, bad hard disk, bad
motherboard, bad PSU, bad cabling.
You can rule out hard disk problems by installing smartmontools from
ports (sysutils/smartmontools). Please provide output from the
following command:
smartctl -a /dev/{disk}
Thx for the infp about smartmontools. The only problem I found was:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPEUPDATED
WHEN_FAILED RAW_VALUE
190 Airflow_Temperature_Cel 0x0022 001 001 045Old_age Always
FAILING_NOW 253
Don't know if this is a serious problem.
Hans
PS! The disk is of type
Model Family: Western Digital Caviar Second Generation Serial ATA family
Device Model: WDC WD2500JS-55NCB1
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: KVM tips for bsd as guest?
On Thu, Nov 12, 2009 at 1:53 PM, Marius Nünnerich mar...@nuenneri.ch wrote: On Thu, Nov 12, 2009 at 22:42, Rudy cra...@monkeybrains.net wrote: Downloaded iso, but qemu barfs when trying to install --- loads kernel but panics during boot of 7.2 ( and 8.0-rc3) install ISOs. I am trying to set up a bsd guest ... Host OS is debian. i386 or amd64? What are your KVM settings? Number of CPUs, amount of RAM, type of virtual disk (IDE/SCSI), type of NIC (rtl3189/e1000)? Which CPU is in the host server (AMD/Intel)? And which versions of KVM and Linux kernel are you running? Last time I tested was with KVM-72 on 64-bit Debian using kernel 2.6.26, and installing/running FreeBSD 6.x and 7.x, 32-bit and 64-bit, ran without any issues. Used LVM-backed virtual IDE drives, and e1000 NICs. Granted, we use AMD Opteron CPUs, which seem to have fewer issues with KVM than Intel Xeon CPUs. I am looking for a general how-to if there is one out there( tried searching didn't find it). There's no real How-To needed. Just configure the VM, and boot. This is the first time I've heard of issues with installing FreeBSD into KVM-managed VMs. -- Freddie Cash fjwc...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 82573 xfers pause, no watchdog timeouts, DCGDIS ineffective (7.2-R)
On Thu, Nov 12, 2009 at 11:47 AM, Jeremy Chadwick free...@jdc.parodius.com wrote: Please define low-throughput and high-volume if you could; it might help folks determine where the threshold is for problems. My definitions are pretty subjective/operational, but for what it's worth: - low is interactive SSH, DNS lookups, and pings; - high is a single unthrottled rsync session. rand# sysctl dev.em dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.6 dev.em.0.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 subdevice=0x108c class=0x02 kenv: rand# kenv | grep smbios | egrep -v 'socket|serial|uuid|tag|0123456789' smbios.bios.reldate=03/05/2008 For what it's worth as a comparison base: We use the following Supermicro SuperServers, and can confirm that no such issues occur for us using RELENG_6 nor RELENG_7 on the following hardware: [good cross-check list snipped] The problem system is a 5015M-MF. We are running 5015M-MT+ and 5015T-PR on RELENG_6 and 7, both without the symptom. Relevant server configuration and network setup details: - All machines use pf(4). - All emX devices are configured for autoneg. - All emX devices use RXCSUM, TXCSUM, and TSO4. - We do not use polling. - All machines use both NICs simultaneously at all times. - All machines connected to an HP ProCurve 2626 switch (100mbit, full-duplex ports, all autoneg). - We do not use Jumbo frames. - No add-in cards (PCI, PCI-X, nor PCIe) are used in the systems. - All of the systems had DCGDIS.EXE run on them; no EEPROM settings were changed, indicating the from-the-Intel-factory MANC register in question was set properly. No firewall is active on the problem system, and none of this back have been DCGDIS-ified, but otherwise, our setup is identical. I've compared your sysctl dev.em output to that of our 5015M-T+B systems (which use the PDSMi+, not the PDSMi, but whatever), and ours is 100% identical. All of our 5015M-T+B systems are using BIOS 1.3, and the 5015B-MTB system is using BIOS 1.30. The repurposed system is at 1.3 (03/05/2008) - flashed prior to install. The production 6.3 systems are using 1.1 (or 1.1A, would have to reboot to check, but the date is 10/27/2005). If you'd like, I can provide the exact BIOS settings we use on the machines in question; they do deviate from the factory defaults a slight bit, but none of the adjustments are tweaks for performance or otherwise (just disabling things which we don't use, etc.). We're running similarly as well. I might be able to retire another system of this batch and install 7.2, but leave the BIOS update off, to see if it makes a difference. Royce ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
hald running 100%
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After upgrading to 8.0-PRERELEASE today, I'm seeing hald at 100% on both my laptop and my desktop: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 1500 haldaemon 1 1180 22944K 4904K CPU1 1 107:44 100.00% hald uptime was about 1:50 at this point. Seems to be relatively common from the posts I've seen. ThinkPad X61s. dmesg output attached. FWIW. - -- Dan Langille BSDCan - The Technical BSD Conference : http://www.bsdcan.org/ PGCon - The PostgreSQL Conference: http://www.pgcon.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkr8vZwACgkQCgsXFM/7nTzTmwCgwSlroEPuQ8cL3U8THAlFVp7v waIAmwRjRzNkjCUffuzhvKwj/wK5i5f6 =yVNP -END PGP SIGNATURE- 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-PRERELEASE #2: Thu Nov 12 10:44:46 EST 2009 d...@laptop.example.org:/usr/obj/usr/src/sys/LAPTOP amd64 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU L7500 @ 1.60GHz (1596.01-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6fb Stepping = 11 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4024070144 (3837 MB) ACPI APIC Table: LENOVO TP-7N FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Warning: 32/64X length mismatch in Gpe1Block: 0/32 20090521 tbfadt-625 ACPI Warning: Optional field Gpe1Block has zero address or length:0 102C/0 20090521 tbfadt-655 ioapic0: Changing APIC ID to 1 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: LENOVO TP-7N on motherboard acpi0: [ITHREAD] acpi_ec0: Embedded Controller: GPE 0x12, ECDT port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, bff0 (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 vgapci0: VGA-compatible display port 0x1800-0x1807 mem 0xf800-0xf80f,0xe000-0xefff irq 16 at device 2.0 on pci0 agp0: Intel GM965 SVGA controller on vgapci0 agp0: detected 7676k stolen memory agp0: aperture size is 256M vgapci1: VGA-compatible display mem 0xf810-0xf81f at device 2.1 on pci0 em0: Intel(R) PRO/1000 Network Connection 6.9.14 port 0x1840-0x185f mem 0xf820-0xf821,0xf8225000-0xf8225fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1d:72:86:96:3c uhci0: Intel 82801H (ICH8) USB controller USB-D port 0x1860-0x187f irq 20 at device 26.0 on pci0 uhci0: [ITHREAD] usbus0: Intel 82801H (ICH8) USB controller USB-D on uhci0 uhci1: Intel 82801H (ICH8) USB controller USB-E port 0x1880-0x189f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] usbus1: Intel 82801H (ICH8) USB controller USB-E on uhci1 ehci0: Intel 82801H (ICH8) USB 2.0 controller USB2-B mem 0xf8426c00-0xf8426fff irq 22 at device 26.7 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: Intel 82801H (ICH8) USB 2.0 controller USB2-B on ehci0 hdac0: Intel 82801H High Definition Audio Controller mem 0xf822-0xf8223fff irq 17 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090624_0136 hdac0: [ITHREAD] pcib1: ACPI PCI-PCI bridge irq 20 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge irq 21 at device 28.1 on pci0 pci3: ACPI PCI bus on pcib2 ath0: Atheros 5212 mem 0xf7f0-0xf7f0 irq 17 at device 0.0 on pci3 ath0: [ITHREAD] ath0: AR5413 mac 10.3 RF5424 phy 6.1 uhci2: Intel 82801H (ICH8) USB controller USB-A port 0x18a0-0x18bf irq 16 at device 29.0 on pci0 uhci2: [ITHREAD] usbus3: Intel 82801H (ICH8) USB controller USB-A on uhci2 uhci3: Intel 82801H (ICH8) USB controller USB-B port 0x18c0-0x18df irq 17 at device 29.1 on pci0 uhci3: [ITHREAD] usbus4: Intel 82801H (ICH8) USB controller USB-B on uhci3 ehci1: Intel 82801H (ICH8) USB 2.0 controller USB2-A mem 0xf8427000-0xf84273ff irq 19 at device 29.7 on pci0 ehci1: [ITHREAD] usbus5: EHCI version 1.0 usbus5: Intel 82801H (ICH8) USB 2.0 controller USB2-A on
Re: 82573 xfers pause, no watchdog timeouts, DCGDIS ineffective (7.2-R)
On Thu, Nov 12, 2009 at 2:18 PM, Royce Williams royce.willi...@gmail.com wrote: On Thu, Nov 12, 2009 at 11:47 AM, Jeremy Chadwick - All machines connected to an HP ProCurve 2626 switch (100mbit, full-duplex ports, all autoneg). No firewall is active on the problem system, and none of this back have been DCGDIS-ified, but otherwise, our setup is identical. Er, s/back/batch/g, and it's not a ProCurve. ;-) But we are also usually full-duplex and autoneg on both sides. Based on new (embarrassing) information, I'll leave it to Jack to decide whether or not he wants to pursue this further. The problem box is sitting in my grotty mini-lab, with a subnet partially serviced by a 10M hub. Guess which Ethernet cable I picked up. Guess what happens when I move the system to a 100M/full connection. As my cow-orker put it, You and the other four people on Earth using that NIC on 10M hubs can probably find workarounds. My apologies for the noise, though it's theoretically possible that the root cause might still need addressing. Jack, let me know if you want me to do any testing for you. Or I can always send you my hub. ;-) Royce ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: hald running 100%
On Thu, Nov 12, 2009 at 7:59 PM, Dan Langille d...@langille.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After upgrading to 8.0-PRERELEASE today, I'm seeing hald at 100% on both my laptop and my desktop: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 1500 haldaemon 1 1180 22944K 4904K CPU1 1 107:44 100.00% hald uptime was about 1:50 at this point. Seems to be relatively common from the posts I've seen. ThinkPad X61s. dmesg output attached. FWIW. it's not a common issue anymore. What version of hal are you running and did you recompile after the upgrade? -- Adam Vande More ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 82573 xfers pause, no watchdog timeouts, DCGDIS ineffective (7.2-R)
LOL, glad the problem has been resolved, and no thanks, I do not need to pursue this any further. I also want to thank Jeremy for his help and data!! Thanks guys and good evening, Jack On Thu, Nov 12, 2009 at 6:56 PM, Royce Williams royce.willi...@gmail.comwrote: On Thu, Nov 12, 2009 at 2:18 PM, Royce Williams royce.willi...@gmail.com wrote: On Thu, Nov 12, 2009 at 11:47 AM, Jeremy Chadwick - All machines connected to an HP ProCurve 2626 switch (100mbit, full-duplex ports, all autoneg). No firewall is active on the problem system, and none of this back have been DCGDIS-ified, but otherwise, our setup is identical. Er, s/back/batch/g, and it's not a ProCurve. ;-) But we are also usually full-duplex and autoneg on both sides. Based on new (embarrassing) information, I'll leave it to Jack to decide whether or not he wants to pursue this further. The problem box is sitting in my grotty mini-lab, with a subnet partially serviced by a 10M hub. Guess which Ethernet cable I picked up. Guess what happens when I move the system to a 100M/full connection. As my cow-orker put it, You and the other four people on Earth using that NIC on 10M hubs can probably find workarounds. My apologies for the noise, though it's theoretically possible that the root cause might still need addressing. Jack, let me know if you want me to do any testing for you. Or I can always send you my hub. ;-) Royce ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Welcome to LinkedIn!
Thank you for using LinkedIn! You have joined over 50 million professionals using LinkedIn to stay connected and reach new people through trusted referrals. Get Things Done... Better and Faster Use LinkedIn to get whatever job you do today done better -- it's the best way to connect with: * job candidates * industry experts * business partners * hiring managers Search your network now: http://www.linkedin.com/e/TGrSvDCw7IOFPvo9di0rrrCxHfruWXUdu2q0FyGg/sea/wel_search_02_A/ Find Contacts The average LinkedIn user knows 15 to 20 people who already have their professional network on LinkedIn. You probably do, too. Find out which of the people you know are already LinkedIn: http://www.linkedin.com/e/TGrSvDCw7IOFPvo9di0rrrCxHfruWXUdu2q0FyGg/fdc/wel_findcts_02_A/ How LinkedIn Works To learn more about LinkedIn, come and take our tour: http://www.linkedin.com/e/TGrSvDCw7IOFPvo9di0rrrCxHfruWXUdu2q0FyGg/tou/wel_tour_02_A/ Welcome! - Your LinkedIn Team http://www.linkedin.com/ Your email: freebsd-stable@FreeBSD.ORG Add additional emails: https://www.linkedin.com/e/TGrSvDCw7IOFPvo9di0rrrCxHfruWXUdu2q0FyGg/mep/wel_addemail_02_A/ Edit profile: http://www.linkedin.com/e/TGrSvDCw7IOFPvo9di0rrrCxHfruWXUdu2q0FyGg/mpe/wel_editpro_02_A/ Contact settings: https://www.linkedin.com/e/TGrSvDCw7IOFPvo9di0rrrCxHfruWXUdu2q0FyGg/csp/wel_cntset_02_A/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
