Re: FreeBSD 9.0 and Intel MatrixRAID RAID5
I had something similar on a software based RAID controller on my Intel S5000PSL motherboard when I just went from 8.2-RELEASE to 9.0-RELEASE. After adding geom_raid_load=YES to my /boot/loader.conf, it still didn't create the device on bootup. I had to manually create the label with graid. After that it created /dev/raid/ar0 for me and I could mount the volume. Only thing which I've trying to understand is the last message below about the integrity check failed. I've found other posts on this but when I dig into my setup, I don't see the same problems that are illustrated in the post and am at a loss for why that is being stated. Also, on other posts I think it was (raid/r0, MBR) that people were getting and trying to fix. Mine is (raid/r0, BSD) which I cannot find reference to. I have a feeling it has to do with the geometry of the disk or something. Everything else seems fine... I admittedly only use this volume for scratch space and didn't have anything important stored on it so I wasn't worried about experimenting or losing data. ada0 at ahcich0 bus 0 scbus2 target 0 lun 0 ada0: WDC WD4000YR-01PLB0 01.06A01 ATA-7 SATA 1.x device ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 381554MB (781422768 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus3 target 0 lun 0 ada1: WDC WD4000YR-01PLB0 01.06A01 ATA-7 SATA 1.x device ada1: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 381554MB (781422768 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 GEOM_RAID: Intel-8c840681: Array Intel-8c840681 created. GEOM_RAID: Intel-8c840681: Disk ada0s1 state changed from NONE to ACTIVE. GEOM_RAID: Intel-8c840681: Subdisk ar0:0-ada0s1 state changed from NONE to ACTIVE. GEOM_RAID: Intel-8c840681: Disk ada1s1 state changed from NONE to ACTIVE. GEOM_RAID: Intel-8c840681: Subdisk ar0:1-ada1s1 state changed from NONE to ACTIVE. GEOM_RAID: Intel-8c840681: Array started. GEOM_RAID: Intel-8c840681: Volume ar0 state changed from STARTING to OPTIMAL. GEOM_RAID: Intel-8c840681: Provider raid/r0 for volume ar0 created. GEOM_PART: integrity check failed (raid/r0, BSD) Any ideas on the integrity check anyone? Thanks! -Vinny On 1/17/2012 6:57 AM, Matthias Gamsjager wrote: Not sure if geom_raid is implemented with cam. I remember a post a while back about this issue to happen with defaulting cam in 9. Did not follow it so not sure if something has been done about it. On Tue, Jan 17, 2012 at 11:53 AM, Alexander Pyhalov a...@rsu.ru wrote: Hello. On my desktop I use Intel MatrixRAID RAID5 soft raid controller. RAID5 is configured over 3 disks. FreeBSD 8.2 sees this as: ar0: 953874MB Intel MatrixRAID RAID5 (stripe 64 KB) status: READY ar0: disk0 READY using ad4 at ata2-master ar0: disk1 READY using ad6 at ata3-master ar0: disk2 READY using ad12 at ata6-master Root filesystem is on /dev/ar0s1. Today I've tried to upgrade to 9.0. It doesn't see this disk array. Here is dmesg. When I load geom_raid, it finds something, but doesn't want to work with RAID: GEOM_RAID: Intel-e922b201: Array Intel-e922b201 created. GEOM_RAID: Intel-e922b201: No transformation module found for Volume0. GEOM_RAID: Intel-e922b201: Volume Volume0 state changed from STARTING to UNSUPPORTED. GEOM_RAID: Intel-e922b201: Disk ada2 state changed from NONE to ACTIVE. GEOM_RAID: Intel-e922b201: Subdisk Volume0:2-ada2 state changed from NONE to ACTIVE. GEOM_RAID: Intel-e922b201: Disk ada1 state changed from NONE to ACTIVE. GEOM_RAID: Intel-e922b201: Subdisk Volume0:1-ada1 state changed from NONE to ACTIVE. GEOM_RAID: Intel-e922b201: Disk ada0 state changed from NONE to ACTIVE. GEOM_RAID: Intel-e922b201: Subdisk Volume0:0-ada0 state changed from NONE to ACTIVE. GEOM_RAID: Intel-e922b201: Array started. No new devices appear in /dev. How could I solve this issue? -- ___ 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: FreeBSD 9.0 and Intel MatrixRAID RAID5
On 1/17/2012 4:04 PM, Alexander Motin wrote: On 17.01.2012 19:03, Vinny Abello wrote: I had something similar on a software based RAID controller on my Intel S5000PSL motherboard when I just went from 8.2-RELEASE to 9.0-RELEASE. After adding geom_raid_load=YES to my /boot/loader.conf, it still didn't create the device on bootup. I had to manually create the label with graid. After that it created /dev/raid/ar0 for me and I could mount the volume. Only thing which I've trying to understand is the last message below about the integrity check failed. I've found other posts on this but when I dig into my setup, I don't see the same problems that are illustrated in the post and am at a loss for why that is being stated. Also, on other posts I think it was (raid/r0, MBR) that people were getting and trying to fix. Mine is (raid/r0, BSD) which I cannot find reference to. I have a feeling it has to do with the geometry of the disk or something. Everything else seems fine... I admittedly only use this volume for scratch space and didn't have anything important st or ed on it so I wasn't worried about experimenting or losing data. ada0 at ahcich0 bus 0 scbus2 target 0 lun 0 ada0:WDC WD4000YR-01PLB0 01.06A01 ATA-7 SATA 1.x device ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 381554MB (781422768 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus3 target 0 lun 0 ada1:WDC WD4000YR-01PLB0 01.06A01 ATA-7 SATA 1.x device ada1: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 381554MB (781422768 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 GEOM_RAID: Intel-8c840681: Array Intel-8c840681 created. GEOM_RAID: Intel-8c840681: Disk ada0s1 state changed from NONE to ACTIVE. GEOM_RAID: Intel-8c840681: Subdisk ar0:0-ada0s1 state changed from NONE to ACTIVE. GEOM_RAID: Intel-8c840681: Disk ada1s1 state changed from NONE to ACTIVE. GEOM_RAID: Intel-8c840681: Subdisk ar0:1-ada1s1 state changed from NONE to ACTIVE. GEOM_RAID: Intel-8c840681: Array started. GEOM_RAID: Intel-8c840681: Volume ar0 state changed from STARTING to OPTIMAL. GEOM_RAID: Intel-8c840681: Provider raid/r0 for volume ar0 created. GEOM_PART: integrity check failed (raid/r0, BSD) Any ideas on the integrity check anyone? It is not related to geom_raid, but to geom_part. There is something wrong with your label. You may set kern.geom.part.check_integrity sysctl to zero do disable these checks. AFAIR it was mentioned in 9.0 release notes. Thanks for responding, Alexander. I also found that information about that sysctl variable, however I was trying to determine if something is actually wrong, how to determine what it is and ultimately how to fix it so it passes the check. I'd rather not ignore errors/warnings unless it's a bug. Again, I have no data of value on this partition, so I can do anything to fix it. Just not sure what to do or look at specifically. Thanks! -Vinny ___ 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 9.0 and Intel MatrixRAID RAID5
On 1/17/2012 4:38 PM, Alexander Motin wrote: On 17.01.2012 23:35, Vinny Abello wrote: On 1/17/2012 4:04 PM, Alexander Motin wrote: On 17.01.2012 19:03, Vinny Abello wrote: I had something similar on a software based RAID controller on my Intel S5000PSL motherboard when I just went from 8.2-RELEASE to 9.0-RELEASE. After adding geom_raid_load=YES to my /boot/loader.conf, it still didn't create the device on bootup. I had to manually create the label with graid. After that it created /dev/raid/ar0 for me and I could mount the volume. Only thing which I've trying to understand is the last message below about the integrity check failed. I've found other posts on this but when I dig into my setup, I don't see the same problems that are illustrated in the post and am at a loss for why that is being stated. Also, on other posts I think it was (raid/r0, MBR) that people were getting and trying to fix. Mine is (raid/r0, BSD) which I cannot find reference to. I have a feeling it has to do with the geometry of the disk or something. Everything else seems fine... I admittedly only use this volume for scratch space and didn't have anything important st or ed on it so I wasn't worried about experimenting or losing data. ada0 at ahcich0 bus 0 scbus2 target 0 lun 0 ada0:WDC WD4000YR-01PLB0 01.06A01 ATA-7 SATA 1.x device ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 381554MB (781422768 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus3 target 0 lun 0 ada1:WDC WD4000YR-01PLB0 01.06A01 ATA-7 SATA 1.x device ada1: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 381554MB (781422768 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 GEOM_RAID: Intel-8c840681: Array Intel-8c840681 created. GEOM_RAID: Intel-8c840681: Disk ada0s1 state changed from NONE to ACTIVE. GEOM_RAID: Intel-8c840681: Subdisk ar0:0-ada0s1 state changed from NONE to ACTIVE. GEOM_RAID: Intel-8c840681: Disk ada1s1 state changed from NONE to ACTIVE. GEOM_RAID: Intel-8c840681: Subdisk ar0:1-ada1s1 state changed from NONE to ACTIVE. GEOM_RAID: Intel-8c840681: Array started. GEOM_RAID: Intel-8c840681: Volume ar0 state changed from STARTING to OPTIMAL. GEOM_RAID: Intel-8c840681: Provider raid/r0 for volume ar0 created. GEOM_PART: integrity check failed (raid/r0, BSD) Any ideas on the integrity check anyone? It is not related to geom_raid, but to geom_part. There is something wrong with your label. You may set kern.geom.part.check_integrity sysctl to zero do disable these checks. AFAIR it was mentioned in 9.0 release notes. Thanks for responding, Alexander. I also found that information about that sysctl variable, however I was trying to determine if something is actually wrong, how to determine what it is and ultimately how to fix it so it passes the check. I'd rather not ignore errors/warnings unless it's a bug. Again, I have no data of value on this partition, so I can do anything to fix it. Just not sure what to do or look at specifically. First thing I would check is that partition is not bigger then the RAID volume size. If label was created before the RAID volume, that could be the reason, because RAID cuts several sectors off the end of disk to store metadata. OK, thanks for the suggestion. I will investigate. -Vinny ___ 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: Packet Loss w/bge BCM5703 on Dell PE2650
Sten Daniel Soersdal wrote: Vinny Abello wrote: Oliver Fromme wrote: Vinny Abello wrote: I've isolated a problem which appears to be a bug causing packet loss with FreeBSD 6.0 and later on the Dell PowerEdge 2650 servers and the integrated Broadcom BCM5703 NICs. Have you enabled polling on the interface? I experienced a similar problem on a HP Proliant DL360 running 6.2-stable (RELENG_6 of a few weeks ago). The problem disappeared upon ifconfig bge0 polling. Best regards Oliver It appears I do not have the DEVICE_POLLING option set when I compiled my kernel on my one machine and on the second I am just using the GENERIC kernel. I'll recompile with this option set and try again and post my results to the list. Thanks! Try disabling hardware assisted checksumming. ( ifconfig bge0 -txcsum -rxcsum ). Thanks for the suggestion, but... That's actually one of the first things I tried before writing to the list. No difference. I'm going to put an Intel Pro/100 card in shortly to see if the problem goes away to be certain the issue is definitely with the integrated Broadcom NICs. -- Vinny Abello Network Engineer [EMAIL PROTECTED] (973)940-6100 PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Packet Loss w/bge BCM5703 on Dell PE2650
Vinny Abello wrote: Sten Daniel Soersdal wrote: Vinny Abello wrote: Oliver Fromme wrote: Vinny Abello wrote: I've isolated a problem which appears to be a bug causing packet loss with FreeBSD 6.0 and later on the Dell PowerEdge 2650 servers and the integrated Broadcom BCM5703 NICs. Have you enabled polling on the interface? I experienced a similar problem on a HP Proliant DL360 running 6.2-stable (RELENG_6 of a few weeks ago). The problem disappeared upon ifconfig bge0 polling. Best regards Oliver It appears I do not have the DEVICE_POLLING option set when I compiled my kernel on my one machine and on the second I am just using the GENERIC kernel. I'll recompile with this option set and try again and post my results to the list. Thanks! Try disabling hardware assisted checksumming. ( ifconfig bge0 -txcsum -rxcsum ). Thanks for the suggestion, but... That's actually one of the first things I tried before writing to the list. No difference. I'm going to put an Intel Pro/100 card in shortly to see if the problem goes away to be certain the issue is definitely with the integrated Broadcom NICs. I've installed an Intel Pro/100 adapter in the Dell PowerEdge 2650. This is an Intel 82550 chipset. The packet loss problem is completely gone when using this NIC in the server, so it is definitely related to the bge driver and this chipset BCM5703 or something else in the server. I'm going to try and isolate which major release this problem appeared. Maybe this will help isolate the change that is causing this issue for me. -- Vinny Abello Network Engineer [EMAIL PROTECTED] (973)940-6100 PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Packet Loss w/bge BCM5703 on Dell PE2650
Abdullah Ibn Hamad Al-Marri wrote: On 5/31/07, Vinny Abello [EMAIL PROTECTED] wrote: Vinny Abello wrote: Sten Daniel Soersdal wrote: Vinny Abello wrote: Oliver Fromme wrote: Vinny Abello wrote: I've isolated a problem which appears to be a bug causing packet loss with FreeBSD 6.0 and later on the Dell PowerEdge 2650 servers and the integrated Broadcom BCM5703 NICs. Have you enabled polling on the interface? I experienced a similar problem on a HP Proliant DL360 running 6.2-stable (RELENG_6 of a few weeks ago). The problem disappeared upon ifconfig bge0 polling. Best regards Oliver It appears I do not have the DEVICE_POLLING option set when I compiled my kernel on my one machine and on the second I am just using the GENERIC kernel. I'll recompile with this option set and try again and post my results to the list. Thanks! Try disabling hardware assisted checksumming. ( ifconfig bge0 -txcsum -rxcsum ). Thanks for the suggestion, but... That's actually one of the first things I tried before writing to the list. No difference. I'm going to put an Intel Pro/100 card in shortly to see if the problem goes away to be certain the issue is definitely with the integrated Broadcom NICs. I've installed an Intel Pro/100 adapter in the Dell PowerEdge 2650. This is an Intel 82550 chipset. The packet loss problem is completely gone when using this NIC in the server, so it is definitely related to the bge driver and this chipset BCM5703 or something else in the server. I'm going to try and isolate which major release this problem appeared. Maybe this will help isolate the change that is causing this issue for me. -- Vinny Abello Network Engineer [EMAIL PROTECTED] (973)940-6100 PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain I still suggest you csup to stable, there are changes made to the driver :) OK, I'll try that next instead. :) Thanks! -- Vinny Abello Network Engineer [EMAIL PROTECTED] (973)940-6100 PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Packet Loss w/bge BCM5703 on Dell PE2650
Abdullah Ibn Hamad Al-Marri wrote: I've installed an Intel Pro/100 adapter in the Dell PowerEdge 2650. This is an Intel 82550 chipset. The packet loss problem is completely gone when using this NIC in the server, so it is definitely related to the bge driver and this chipset BCM5703 or something else in the server. I'm going to try and isolate which major release this problem appeared. Maybe this will help isolate the change that is causing this issue for me. I still suggest you csup to stable, there are changes made to the driver :) OK, just did a cvsup to the latest RELENG_6 from today, recompiled and still have the same problem with the newer bge code, so that didn't help. :( Again, the fxp card works ok. It seems there is no easy fix for this at the moment so I may end up just sticking fxp cards in these model servers and disabling the integrated bge cards. :-/ -- Vinny Abello Network Engineer [EMAIL PROTECTED] (973)940-6100 PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Packet Loss w/bge BCM5703 on Dell PE2650
Oliver Fromme wrote: Vinny Abello wrote: I've isolated a problem which appears to be a bug causing packet loss with FreeBSD 6.0 and later on the Dell PowerEdge 2650 servers and the integrated Broadcom BCM5703 NICs. Have you enabled polling on the interface? I experienced a similar problem on a HP Proliant DL360 running 6.2-stable (RELENG_6 of a few weeks ago). The problem disappeared upon ifconfig bge0 polling. Best regards Oliver Thanks for the suggestion. Either I am doing something wrong or ifconfig doesn't understand the polling argument. I'm wondering if it is supported by the driver on this chipset. [EMAIL PROTECTED] ~# ifconfig bge0 polling ifconfig: polling: Invalid argument [EMAIL PROTECTED] ~# ifconfig bge0 bge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=1bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING inet 216.182.1.13 netmask 0xff00 broadcast 216.182.1.255 ether 00:0d:56:ba:73:bf media: Ethernet autoselect (1000baseTX full-duplex) status: active -- Vinny Abello Network Engineer [EMAIL PROTECTED] (973)940-6100 PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Packet Loss w/bge BCM5703 on Dell PE2650
Oliver Fromme wrote: Vinny Abello wrote: I've isolated a problem which appears to be a bug causing packet loss with FreeBSD 6.0 and later on the Dell PowerEdge 2650 servers and the integrated Broadcom BCM5703 NICs. Have you enabled polling on the interface? I experienced a similar problem on a HP Proliant DL360 running 6.2-stable (RELENG_6 of a few weeks ago). The problem disappeared upon ifconfig bge0 polling. Best regards Oliver It appears I do not have the DEVICE_POLLING option set when I compiled my kernel on my one machine and on the second I am just using the GENERIC kernel. I'll recompile with this option set and try again and post my results to the list. Thanks! -- Vinny Abello Network Engineer [EMAIL PROTECTED] (973)940-6100 PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Packet Loss w/bge BCM5703 on Dell PE2650
Abdullah Ibn Hamad Al-Marri wrote: On 5/30/07, Jeremy Chadwick [EMAIL PROTECTED] wrote: On Wed, May 30, 2007 at 01:34:42PM -0400, Vinny Abello wrote: Thanks for the suggestion. Either I am doing something wrong or ifconfig doesn't understand the polling argument. I'm wondering if it is supported by the driver on this chipset. You need to enable options DEVICE_POLLING in your kernel. See polling(4). -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | I have it in my kernel, do I need to add polling in rc.conf too? OK, I've enabled polling in my kernel and did ifconfig bge0 polling and it accepted it and shows that polling is enabled on bge0 when checking with ifconfig. Unfortunately, this did not resolve the packet loss issue I wrote about originally. I still have the same loss. :( Any other ideas? Does anyone run a PowerEdge 2650 with FreeBSD 6.0 or later that's on this list? Thanks! -- Vinny Abello Network Engineer [EMAIL PROTECTED] (973)940-6100 PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Packet Loss w/bge BCM5703 on Dell PE2650
security wrote: Vinny Abello wrote: OK, I've enabled polling in my kernel and did ifconfig bge0 polling and it accepted it and shows that polling is enabled on bge0 when checking with ifconfig. Unfortunately, this did not resolve the packet loss issue I wrote about originally. I still have the same loss. :( Any other ideas? Does anyone run a PowerEdge 2650 with FreeBSD 6.0 or later that's on this list? Thanks! Have you checked your buffer usage with netstat -m? My apologies if this was already suggested All suggestions welcomed: 258/267/525 mbufs in use (current/cache/total) 256/134/390/25600 mbuf clusters in use (current/cache/total/max) 256/128 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 576K/334K/911K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/4/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines I'm not sure how to interpret the information or if any of it is indicating a problem where buffers need adjustment. -- Vinny Abello Network Engineer [EMAIL PROTECTED] (973)940-6100 PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Packet Loss w/bge BCM5703 on Dell PE2650
Jeremy Chadwick wrote: On Wed, May 30, 2007 at 02:49:42PM -0400, Vinny Abello wrote: All suggestions welcomed: Your mbuf counts look OK. I don't see anything there which looks like a problem. If you had packet loss caused by mbuf exhaustion, your FreeBSD console log would show something. I've some couple questions: 1) Checked console logs (dmesg -a) to see if there's anything there which might give you hints to the problem? I'm on the console. Nothing comes up when there is packet loss. Nothing in the dmesg -a output either likewise... Interestingly, I sometimes forget to adjust the icmplim which will artificially limit the pings in my test. On 4.11, this would show the kernel is doing rate limiting. On 6.2 it does not give any indication. I do confirm that it is not being rate limited though by setting net.inet.icmp.icmplim to some high value or -1 also seems to work. 2) Any IPMI modules installed in that Dell box? As far as I recall, IPMI support was not added to the PowerEdge servers until the 2850 which supported IPMI 1.5. This is a 2650. There are no addin IPMI cards. There is the built in DRAC controller but that does not share the NIC like happens on the 2850 and 2950 servers. It has it's own dedicated port. Interestingly it uses 3 IRQ's! I tried even switching IRQ's in the BIOS around to make sure the NIC had it's own unshared IRQ but that made no difference either. 3) vmstat -i output? test# vmstat -i interrupt total rate irq1: atkbd04557 0 irq6: fdc010 0 irq14: ata0 47 0 irq28: bge0 304 0 irq30: aac0 2784 0 cpu0: timer 24371045 1999 Total 24378747 2000 4) Is there a switch between the Cisco router and the FreeBSD box? Yes, both my production setup and my test setup where I reproduced the problem. 5) If there is a switch between the router and the FreeBSD box, have you tried the pings from a box (not the Cisco) on the same switch segment as the FreeBSD box? Yes, same loss. I tried from several devices on the segment and see the loss, only to the FreeBSD systems running on that specific hardware. 6) Have you tried pings the other way (FreeBSD box - box#2, and box#2 - FreeBSD box) to see if its reproducable that way? Yes, in fact that is the reason this is such a big problem. I use the production system to measure latency and packet loss, and since going to FreeBSD 6.x, it has been showing random packet loss in my data that isn't there at all. 7) Does it only happen with ICMP traffic, or can you reproduce the loss using something like FTP (slow transfer rates/stalls)? It's hard to say. It's definitely with ICMP. I've not noticed it with other data. I'll have to do more testing. 8) Tried downthrottling to 100mbit (ifconfig_bge0=... media 100baseTX) on both sides, to see if it's a gigabit-specific problem? My test system is running at 100Mb, same hardware, same problem. 9) Tried different cabling? I see the network is gigabit. You might try replacing the cables, preferably with CAT6. Tried changing cables, ports, port speed, switches, tried the second NIC in the system (same model as the first). The only thing I haven't done is put a third party NIC like an Intel Pro/100 in the system and try it. I'm sure it will work ok but I don't know for a fact. I can try that as a test. I have boxes of them sitting next to my desk here. Thanks for your time! :) -- Vinny Abello Network Engineer [EMAIL PROTECTED] (973)940-6100 PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Packet Loss w/bge BCM5703 on Dell PE2650
: type 16550A sio1: 16550A-compatible COM port port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A pmtimer0 on isa0 orm0: ISA Option ROMs at iomem 0xc-0xc7fff,0xc8000-0xcbfff,0xec000-0xe on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 1.000 msec acd0: CDROM TEAC CD-ROM CD-224E/K.9A at ata0-master UDMA33 aacd0: RAID 1 (Mirror) on aac0 aacd0: 34712MB (71091456 sectors) SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/aacd0s1a bge0: link state changed to UP Router#ping 216.182.1.13 repeat 1000 Type escape sequence to abort. Sending 1000, 100-byte ICMP Echos to 216.182.1.13, timeout is 2 seconds: !! !! !! !! !! !! !! !! !!.!!!.!!!.!!! !! !! !! !! !! Success rate is 99 percent (997/1000), round-trip min/avg/max = 1/1/8 ms -- Vinny Abello Network Engineer [EMAIL PROTECTED] (973)940-6100 PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intermittent network issues with Freebsd 6.2
Greg Barniskis wrote: Vivek Khera wrote: On our PE800, I had to disable the bge on BIOS and plug in an em-based NIC card. Made a world of difference in system stability and performance -- it is actually usable now :-) On our Dell PE2950 units, we had to do the same thing (disable and replace the Broadcom interfaces), and that was running Windows Server 2k3. The problem really seems to be flakiness of the chips or firmware, not necessarily flakiness in the drivers for FreeBSD. Maybe it's both, I don't know. My point is that Broadcom cards have had some serious problems on other platforms too, and not just recently. Other NIC brands have never given us nearly as much trouble. Interestingly, there was a recent Broadcom driver update from Dell within the past couple of months that is marked critical. It claims the previous version can result in system instability and corrupt data. This package is an update to a newer driver that fixes some issues that could result in system halts or posible corrupt data. It is strongly suggested that you update to this new driver if you are using the Broadcom NetXtreme II network interfaces and the 2.6 family of drivers (2.6.14 would be the driver version shown by Windows.) Of course this is for Windows, but... I wonder if perhaps the bge driver suffers from the same problem and if this driver update is just a workaround for a hardware bug. Oddly enough, we have probably somewhere around 100+ PE 2950 servers and have never had a problem with the Broadcom NICs in them. Same with the other PE models using Broadcom NICs, although we primarily run Windows Server 2003 on them. I do have a couple of 2650's with FreeBSD and the bge driver which both seem ok so maybe it is a combination of the bge driver and specific chipset. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow network performance
This sounds like your switch and host settings are correct so I wouldn't spend too much more time looking at that at this point. I just wanted to mention it to be sure. Good luck! Dimuthu Parussalla BWEADM non-std-pwd wrote: This is exactly what I did. Managed Switch A (2950G) 1) both switch and bge/em card set for auto negeotiation 2) Both switch and bge/em set for 1000mb full-duplex. Managed Switch B (Netgeat GSM7224) 1) both switch and bge/em card set for auto negeotiation 2) Both switch and bge/em set for 1000mb full-duplex. I am seriously running out of options. Thanks Vinny Abello writes: Although I don't think this is necessarily the cause of your dropouts as you put it, one must understand the way autonegotiation and manual speed and duplex work between network gear. For autonegotiation to work, BOTH devices must support autonegotiation, OR both devices must be set to the same speed and duplex setting. If one only supports auto and the other does not, you must NOT set the device that you can manually configure to full duplex. The auto device will never negotiate at full duplex and fall back to half when autonegotiation fails, causing a duplex mismatch and horrible network performance and loss. A very rough set of rules of thumb (YMMV): When connecting to an unmanaged switch, use auto. If your host doesn't support auto, set it to half-duplex. When connecting to a managed switch, make sure the port is set to auto and set your system to auto, otherwise force both the switch port and your host to the same settings. This is required especially if the host doesn't support auto negotiation and you want to run at full duplex. When connecting to a managed switch, enable portfast or the equivalent spanning-tree command on the switch port your host is connected to so it forwards traffic immediately when getting link. So to sum it up, auto only works if both sides speak auto. Auto negotiation failure falls back to half-duplex! Of course there are all the horror stories where auto negotiation is evil and that different vendor's implementations don't play nice or are just completely broken, so always set things to manual or you and your family will suffer an untimely death... There are so many of these stories that one would think there has to be some truth to it. In my own experience, I have never had an issue with auto negotiation in some ten years of working with a dozen different vendors' networking gear so I guess I'm lucky... or I just understand how it interacts with other devices and their capabilities. I still don't know which exactly. Hope this helps! :) Dimuthu Parussalla wrote: Hi All, Apart from random dropout from the network. Our IBM X236 server suffers slow network performance. I've changed the server from CISCO switch to a netgear switch on a test platform. Also tried 1000m full-duplex setup with no auto negotionation on both ends. Still after few days (3-4) server drops the connection. And while its working I get 90KBps upload/download with ftp transfers. I have treid changing BGE network cards to EM (intel 100/1000) still the same result. Any idea's to nail this problem? /etc/sysctl.conf kern.ipc.maxsockbuf=8388608 kern.ipc.somaxconn=2048 net.inet.tcp.sendspace=3217968 net.inet.tcp.recvspace=3217968 net.inet.tcp.rfc1323=1 #net.inet.tcp.rfc3042=0 net.inet.ip.portrange.hilast=65535 net.inet.ip.portrange.hifirst=49152 net.inet.ip.portrange.last=65535 net.inet.ip.portrange.first=1024 net.inet.tcp.inflight.enable=0 /boot/loader.conf kern.ipc.nmbclusters=32768 Interfaces: em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 192.168.1.12 netmask 0xff00 broadcast 192.168.1.255 ether 00:0e:0c:d0:73:3c media: Ethernet 1000baseTX full-duplex status: active em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 6x.xx.xx.xx netmask 0xffc0 broadcast xxx.xxx.xxx.255 ether 00:0e:0c:9f:f4:5e media: Ethernet 100baseTX full-duplex status: active Regards Dimuthu Parussalla ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow network performance
Although I don't think this is necessarily the cause of your dropouts as you put it, one must understand the way autonegotiation and manual speed and duplex work between network gear. For autonegotiation to work, BOTH devices must support autonegotiation, OR both devices must be set to the same speed and duplex setting. If one only supports auto and the other does not, you must NOT set the device that you can manually configure to full duplex. The auto device will never negotiate at full duplex and fall back to half when autonegotiation fails, causing a duplex mismatch and horrible network performance and loss. A very rough set of rules of thumb (YMMV): When connecting to an unmanaged switch, use auto. If your host doesn't support auto, set it to half-duplex. When connecting to a managed switch, make sure the port is set to auto and set your system to auto, otherwise force both the switch port and your host to the same settings. This is required especially if the host doesn't support auto negotiation and you want to run at full duplex. When connecting to a managed switch, enable portfast or the equivalent spanning-tree command on the switch port your host is connected to so it forwards traffic immediately when getting link. So to sum it up, auto only works if both sides speak auto. Auto negotiation failure falls back to half-duplex! Of course there are all the horror stories where auto negotiation is evil and that different vendor's implementations don't play nice or are just completely broken, so always set things to manual or you and your family will suffer an untimely death... There are so many of these stories that one would think there has to be some truth to it. In my own experience, I have never had an issue with auto negotiation in some ten years of working with a dozen different vendors' networking gear so I guess I'm lucky... or I just understand how it interacts with other devices and their capabilities. I still don't know which exactly. Hope this helps! :) Dimuthu Parussalla wrote: Hi All, Apart from random dropout from the network. Our IBM X236 server suffers slow network performance. I've changed the server from CISCO switch to a netgear switch on a test platform. Also tried 1000m full-duplex setup with no auto negotionation on both ends. Still after few days (3-4) server drops the connection. And while its working I get 90KBps upload/download with ftp transfers. I have treid changing BGE network cards to EM (intel 100/1000) still the same result. Any idea's to nail this problem? /etc/sysctl.conf kern.ipc.maxsockbuf=8388608 kern.ipc.somaxconn=2048 net.inet.tcp.sendspace=3217968 net.inet.tcp.recvspace=3217968 net.inet.tcp.rfc1323=1 #net.inet.tcp.rfc3042=0 net.inet.ip.portrange.hilast=65535 net.inet.ip.portrange.hifirst=49152 net.inet.ip.portrange.last=65535 net.inet.ip.portrange.first=1024 net.inet.tcp.inflight.enable=0 /boot/loader.conf kern.ipc.nmbclusters=32768 Interfaces: em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 192.168.1.12 netmask 0xff00 broadcast 192.168.1.255 ether 00:0e:0c:d0:73:3c media: Ethernet 1000baseTX full-duplex status: active em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 6x.xx.xx.xx netmask 0xffc0 broadcast xxx.xxx.xxx.255 ether 00:0e:0c:9f:f4:5e media: Ethernet 100baseTX full-duplex status: active Regards Dimuthu Parussalla ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
How to start rc script after sshd starts?
Hello, I think this is a relatively easy question to answer but couldn't find anything after some searching. I'm running: FreeBSD engbox.tellurian.net 6.2-STABLE FreeBSD 6.2-STABLE #0: Sat Jan 27 00:37:31 EST 2007 (yeah, pretty recent as of this email) :) I have a daemon that apparently does a check using ssh-keyscan against the loopback address when it starts up. The problem I have is that sshd is not started when the script runs to start this daemon, so it fails and I end up having to start it manually. What is the recommended way to get this script to start after sshd has started up? I was hoping to not have to hack any rc scripts up from their defaults for starting up the system if possible. It's a standard rc script in /usr/local/etc/rc.d. If it matters, the daemon is smokeping. I can stop it from using ssh-keyscan completely as I really don't use the probe at all in smokeping but I'm curious as to the proper way of making this work. Any pointers are appreciated. Thanks! -- Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVIDIA 6600GT Freeze
At 08:24 AM 7/21/2006, Nealie wrote: On Thu, 2006-07-20 at 13:51 +0200, Nealie wrote: I have a problem with my system freezing when using an NVIDIA video card using the nvidia-driver port. All seems to work fine for a while but then the system freezes and won't even reply to a ping. This can happen regardless of whether I use openGL or not. Everything works fine using the nv driver, so it doesn't seem to be a hardware problem. My setup is as follows: uname: FreeBSD server.home 6.1-STABLE FreeBSD 6.1-STABLE #0: Wed Jul 19 11:19:16 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVER i386 AGP NVIDIA 6600GT installed on an MSI K8T Neo-F V2.09 motherboard (VIA K8T800 Pro chipset) with an AMD Athlon 64 3500+ CPU. The NVIDIA driver is installed as per the instructions, with agp and dri removed from the kernel in order to use the NVIDIA agp interface, even though the sysctl settings suggest otherwise. If anyone has any ideas about this problem I'd be very grateful. Just a quick reply to myself: The problem seems to be that the the IRQs of the motherboards on board network interface and the AGP card are the same. This works for a while but then something goes horribly wrong and all comes to a halt. Why the IRQ is shared I have no idea as there are nine free IRQs. On most machines I have seen, IRQ's are shared between certain slots. You can change the IRQ that is being used but not the devices sharing it. I believe this is inherent to the current PC architecture and motherboard design. Being that the NIC is integrated and you have so many other IRQ's free, I'm not sure why they chose that route for your board. Perhaps NICs can generally share with video cards without problems. In general (not guaranteed), devices *should* be able to share IRQ's if the drivers are written properly and if the hardware isn't designed horribly. This is just a generalization of my own experiences. I in no way write drivers for hardware for any operating system. YMMV. :) Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Please confirm: top(1) cpu time broken on FreeBSD 6.1 (RELEASE/STABLE) SMP ?
Disable hyperthreading in your BIOS. At 10:20 AM 7/18/2006, Martin Blapp wrote: Hi, Ok, seems to be a HTT issue on a untuned system. On two boxes I get with 'sysctl -a | grep smp | grep kern.smp.cpus' kern.smp.cpus: 4 Here I see CPU-IDs 0 and 2 in top. No other CPUs seem to be used. Here I get the broken CPU usage. And yes, seeting hyperthreading_allowed=1 corrects the top usage. On two other boxes where it works I get 'sysctl -a | grep smp | grep kern.smp.cpus' kern.smp.cpus: 2 Here I see CPU-ID's 0 and 1 in top. Here everything works as it should. Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.x on Dual PIII server only seeing one CPU ...
3579545 Hz quality 1000 acpi_timer0: 32-bit timer at 3.579545MHz port 0x508-0x50b on acpi0 cpu0: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: mass storage, RAID at device 2.0 (no driver attached) fxp0: Intel 82550 Pro/100 Ethernet port 0x1480-0x14bf mem 0xfe79-0xfe790fff,0xfe76-0xfe77 irq 21 at device 3.0 on pci0 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:03:47:bd:67:66 fxp1: Intel 82550 Pro/100 Ethernet port 0x14c0-0x14ff mem 0xfeac-0xfeac0fff,0xfeaa-0xfeab irq 20 at device 4.0 on pci0 miibus1: MII bus on fxp1 inphy1: i82555 10/100 media interface on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Ethernet address: 00:03:47:bd:67:67 pci0: display, VGA at device 12.0 (no driver attached) isab0: PCI-ISA bridge at device 15.0 on pci0 isa0: ISA bus on isab0 pci0: mass storage, ATA at device 15.1 (no driver attached) pci0: serial bus, USB at device 15.2 (no driver attached) pcib1: ACPI Host-PCI bridge on acpi0 pci1: ACPI PCI bus on pcib1 iir0: Intel Integrated RAID Controller mem 0xfc8f-0xfc8f3fff irq 30 at device 9.0 on pci1 iir0: [GIANT-LOCKED] pcib2: ACPI Host-PCI bridge on acpi0 pci2: ACPI PCI bus on pcib2 orm0: ISA Option ROMs at iomem 0xc-0xc7fff,0xc8000-0xd0fff,0xd1000-0xd27ff,0xd2800-0xd3fff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] Timecounter TSC frequency 1263452709 Hz quality 800 Timecounters tick every 1.000 msec Waiting 5 seconds for SCSI devices to settle ses0 at iir0 bus 1 target 6 lun 0 ses0: ESG-SHV SCA HSBP M16 0.05 Fixed Processor SCSI-2 device ses0: SAF-TE Compliant Device da0 at iir0 bus 2 target 0 lun 0 da0: Intel Host Drive #00 Fixed Direct Access SCSI-2 device da0: Tagged Queueing Enabled da0: 174848MB (358088850 512 byte sectors: 255H 63S/T 22290C) Trying to mount root from ufs:/dev/da0s1a Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hyperthreading in 6.x ... still frowned upon?
At 11:36 AM 5/3/2006, Chuck Swiger wrote: Marc G. Fournier wrote: In 4.x, it was a 'shut it off' sort of deal .. my new amd64 don't appear to have it enabled, but my older i386 server that I just upgraded to 6.x does: user pid %cpu %mem vsz rss tt state starttime command root 14 104.0 0.0 0 8 ?? RL11:38AM 0:55.02 [idle: cpu0] root 11 99.1 0.0 0 8 ?? RL11:38AM 0:00.00 [idle: cpu3] root 13 99.1 0.0 0 8 ?? RL11:38AM 0:00.00 [idle: cpu1] root 12 98.0 0.0 0 8 ?? RL11:38AM 0:54.54 [idle: cpu2] Is it still something that I should disable, and, if so, how in 6.x? You should test it for the workloads you have, but most of the time, HT isn't especially helpful. AMD64 CPUs come in dual-core format rather than HT-enabled. If you've seen HT or HTT applied to an AMD system, it's likely an abbreviation for HyperTransport or HyperTransport Technology. An Intel technical rep that gave a presentation on upcoming Intel VT technology in processors (Virtualization Technology) that I attended indicated that Hyperthreading was really designed to start getting programmers to program threading into their applications in preparation of dual core processors that we now have. Hyperthreading will likely be removed in future processors now that dual core technology is standard. In some instances it created a slight performance boost. Hyperthreading is known to hurt performance under high loads because it diminishes the amount of cache available for each thread. Many times, having no Hyperthreading but more CPU cache available increases performance under high loads. I typically disable Hyperthreading on all my servers as they are dual processor or dual core/dual processor or better anyway. I tend to get better results (with my applications) without Hyperthreading. I've been experimenting with leaving it on with my workstation as it's not a dual core or dual processor. The reason hyperthreading frowned upon in multiuser scenarios of FreeBSD is due to a vulnerability found in Hyperthreading: http://lists.freebsd.org/pipermail/freebsd-security/2005-May/002903.html Hyperthreading needs to be disabled in the BIOS. Often is referred to as a Virtual Processor in the BIOS. Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Default ICMP rate limiting changes from 5.4 to 6.x?
Hello all, I'm trying to figure out why my smokeping installation using fping probes now seems to get periodic loss. It's very minor and only affects the fping probe type. Without centering too much on smokeping details, was there any sort of default rate limiting changed in the ICMP settings going from FreeBSD 5.4 to 6.0? The problem happens across every monitor and started exactly after the upgrade. I tried removing and reinstalling the fping port as well as all of smokeping via the port as well but it had no effect. Does anyone have any other ideas as to what might cause this to happen? I asked on the smokeping list but nobody had any input. The system in question is running: FreeBSD engbox.tellurian.net 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #3: Wed Mar 8 16:37:25 EST 2006 I can post dmesg output too, but I don't think that is necessarily relevant as everything else is working perfectly fine and I have no stability or performance problems. Thanks in advance for any helpful ideas or hints! Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Which PCI SATA controller?
3Ware cards will work in a 32 bit PCI slot. They typically support both 32 bit and 64 bit slots. I researched this before I bought one. Actually, there are benchmark results out there comparing the difference of a 32 bit vs 64 bit PCI slot. Just be sure you have a motherboard that is known to play nice with them. I had one once with a motherboard and it ran 1/10th the speed of my onboard Si3112A in any operating system (FreeBSD, Linux, Windows XP). 3Ware had little explanation after I contacted them other than a board incompatibility (this was an Asus A7N8X-E Deluxe). I sold the card to someone whom it worked much better for. Still can't run FreeBSD on my home system as a result as I'm doing RAID 0 on some Raptor drives and want to dual boot with Windows... Next time I replace my hardware I'll look into something a little more FreeBSD friendly. At 03:58 PM 2/20/2006, [EMAIL PROTECTED] wrote: Sorry ... just to clarify, this would be running 6.0 and it needs to be a 32bit card ... so as awesome as 3ware cards might be, it does me little good ... On Mon, Feb 20, 2006 at 12:05:12PM -0600, Hank Marquardt wrote: So I'm having similar issues to others with gmirror and SATA throwing DMA WRITE failures under load ... In my searching Ive found a few references to the Sil3112 chipset being an issue and it's what's in my cheapy Adaptec card ... So if I want to proceed, what is a good PCI SATA controller? -- Hank Marquardt [EMAIL PROTECTED] GPG Id: 2BB5E60C Fingerprint: D807 61BC FD18 370A AC1D 3EDF 2BF9 8A2D 2BB5 E60C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Hank Marquardt [EMAIL PROTECTED] http://web.yerpso.net GPG Id: 2BB5E60C Fingerprint: D807 61BC FD18 370A AC1D 3EDF 2BF9 8A2D 2BB5 E60C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clock reverts to epoch on boot?
At 04:45 AM 2/14/2006, Oliver Fromme wrote: Vinny Abello [EMAIL PROTECTED] wrote: CPUTYPE=pentium4 Better use ?=. Yes, I saw that error and corrected it. Thanks. That wasn't the source of my problems actually, but I at least have it specified properly now. CFLAGS= -O2 -pipe COPTFLAGS= -O -pipe I recommend not to overide those two at all. Especially your CFLAGS setting might generate broken code because there are sources which are not aliasing-clean, which can break with any optimizations beyond -O, unless you also specify -fno-strict-aliasing. Really? Are there any current examples of such? I've never run into this myself, but I'm sure you wouldn't be recommending it if it wasn't true. What about -funroll-loops and -ffast-math? I see a lot of people using those options in general as well. I actually found one reference from someone claiming -O3 is good in CFLAGS and -O2 for COPTFLAGS although I have read a lot of things about why not to use -O3 in CFLAGS and that it's not supported at all with buildworld, so I'm not really interested in using that at all, even with ports. The defaults are -O2 -fno-strict-aliasing -pipe for CFLAGS, and for COPTFLAGS it's -O -pipe if DEBUG is defined (the default in GENERIC), otherwise -O2 -pipe -fno-strict-aliasing. Is -O2 safe on COPTFLAGS if you have debugging disabled in the KERNCONF? I usually disable it as I have no interest in debugging the kernel (nor have I had problems where I've needed to... yet). I've found references in the archives that it is desirable to get (keep?) the kernel working with -O2 optimizations. Any pointers appreciated. TIA! Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clock reverts to epoch on boot?
At 12:29 PM 2/14/2006, Oliver Fromme wrote: Vinny Abello [EMAIL PROTECTED] wrote: Oliver Fromme wrote: Vinny Abello [EMAIL PROTECTED] wrote: CFLAGS= -O2 -pipe COPTFLAGS= -O -pipe I recommend not to overide those two at all. Especially your CFLAGS setting might generate broken code because there are sources which are not aliasing-clean, which can break with any optimizations beyond -O, unless you also specify -fno-strict-aliasing. Really? Are there any current examples of such? I've never run into this myself, but I'm sure you wouldn't be recommending it if it wasn't true. XEmacs, PostgreSQL, freetype2 and others. Whether you get problems or not depends on a lot of things. If you're lucky, it works. On platforms with only few registers (like i386) it's more likely to work, because gcc has less possibilities to exploit aliasing optimizations. What about -funroll-loops and -ffast-math? I see a lot of people using those options in general as well. You can use them. They shouldn't cause harm, but in many cases -funroll-loops makes the code slower, because it increases the size of the code so it decreases the efficiency of the processor caches. I actually found one reference from someone claiming -O3 is good in CFLAGS and -O2 for COPTFLAGS although I have read a lot of things about why not to use -O3 in CFLAGS and that it's not supported at all with buildworld, so I'm not really interested in using that at all, even with ports. I probably didn't explain it clearly enough. You can use -O2 (and probably also -O3, but I haven't tried that). In former times, the gcc optimizer was known to have bugs that could cause bad code to be generated. As far as I know, those bugs have been fixed in current versions of gcc. However, -O2 also includes -fstrict-aliasing. Strict ali- asing enables a special optimization which lets the compiler assume that pointers with incompatible types never point to the same target. For example, in the function void func (int *foo, short *bar) it is legal for the compiler (according to ANSI C) to assume that the two pointers may not alias. But a lot of programs don't fulfill that assumption. It's a problem with those sources, not with gcc. Therefore the default CFLAGS include -fno-strict-aliasing, which disables that kind of optimizations in gcc. With that option, gcc always assumes that pointers may alias. If you override CFLAGS in your /etc/make.conf by specifying -O2 (or -O3 or -Os) but not also specifying -fno-strict-ali- asing, you run the risk of enabling bugs in programs. The defaults are -O2 -fno-strict-aliasing -pipe for CFLAGS, and for COPTFLAGS it's -O -pipe if DEBUG is defined (the default in GENERIC), otherwise -O2 -pipe -fno-strict-aliasing. Is -O2 safe on COPTFLAGS if you have debugging disabled in the KERNCONF? Yes, I think so. But when you disable DEBUG, then -O2 is the default anyway (-O2 -pipe -fno-strict-aliasing, to be exact), so there's no point in overriding it in make.conf. That's the reason why I recommend not to mess with CFLAGS and COPTFLAGS in /etc/make.conf. The defaults provided by the FreeBSD developers are usually the best optimization possible without creating potentially broken binaries. Best regards Oliver Thanks for all of your excellent explanations, Oliver. Highly appreciated. :) Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
clock reverts to epoch on boot?
: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: 16550A-compatible COM port port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A orm0: ISA Option ROMs at iomem 0xc-0xc7fff,0xc8000-0xcbfff,0xec000-0xe on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 1.000 msec acd0: CDROM TEAC CD-ROM CD-224E/K.9A at ata0-master UDMA33 aacd0: RAID 1 (Mirror) on aac0 aacd0: 34712MB (71091456 sectors) SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/aacd0s1a bge0: link state changed to UP I may try doing a cvsup of source and rebuilding again. My make.conf settings are pretty tame: CPUTYPE=pentium4 CFLAGS= -O2 -pipe COPTFLAGS= -O -pipe NO_GAMES=true PERL_VER=5.8.7 PERL_VERSION=5.8.7 I can't see anything out of the ordinary combing through the syslog output. Any ideas? Any takers? :) Thanks in advance! Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clock reverts to epoch on boot?
At 09:49 PM 2/13/2006, Chuck Swiger wrote: Vinny Abello wrote: [ ... ] I may try doing a cvsup of source and rebuilding again. My make.conf settings are pretty tame: CPUTYPE=pentium4 CFLAGS= -O2 -pipe COPTFLAGS= -O -pipe Remove the CPUTYPE declaration, or at least decrease it to just pentium. OK, I can try that. Come to think of it, I did have it set to p4 previously and I believe it was working. Why would this make a difference? Also, I just booted in single user mode and the clock is correct. Does this likely confirm it is a problem when I did a buildworld with that CPUTYPE set? Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clock reverts to epoch on boot?
At 10:04 PM 2/13/2006, Vinny Abello wrote: At 09:49 PM 2/13/2006, Chuck Swiger wrote: Vinny Abello wrote: [ ... ] I may try doing a cvsup of source and rebuilding again. My make.conf settings are pretty tame: CPUTYPE=pentium4 CFLAGS= -O2 -pipe COPTFLAGS= -O -pipe Remove the CPUTYPE declaration, or at least decrease it to just pentium. OK, I can try that. Come to think of it, I did have it set to p4 previously and I believe it was working. Why would this make a difference? Also, I just booted in single user mode and the clock is correct. Does this likely confirm it is a problem when I did a buildworld with that CPUTYPE set? Nevermind. I just answered my own question. I should have RTFM more carefully. :) If CPUTYPE is defined in your /etc/make.conf, make sure to use the ?= instead of the = assignment operator, so that buildworld can override the CPUTYPE if it needs to. I am thinking if I change to CPUTYPE?=pentium4 I will be ok. Does that sound correct or am I still barking up the wrong tree? Thanks!! Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clock reverts to epoch on boot?
At 10:25 PM 2/13/2006, Chuck Swiger wrote: Vinny Abello wrote: [ ... ] Nevermind. I just answered my own question. I should have RTFM more carefully. :) :-) If CPUTYPE is defined in your /etc/make.conf, make sure to use the ?= instead of the = assignment operator, so that buildworld can override the CPUTYPE if it needs to. I am thinking if I change to CPUTYPE?=pentium4 I will be ok. Does that sound correct or am I still barking up the wrong tree? If you weren't having any problems, feel free to experiment. Since you don't gain much by using the machine-specific compiler optimizations for the kernel, it is worth turning them off to see whether the resulting kernel still has the same problem... Will give it a shot and see what happens. So far buildworld isn't using CPU specific optimizations with the CPUTYPE?=pentium4 as documented so I have a feeling that will fix my problem. I actually started having problems after rebuilding world from this source a second time with (what I thought) were more optimized compiler settings. Obviously not if they cause it to break. :) My kernel is the same from when it was working from the original CVSUP and original buildworld so I think I'll be ok with that. I'll rebuild it to be safe anyway though. Thanks again for your help! :) Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clock reverts to epoch on boot?
At 10:28 PM 2/13/2006, Vinny Abello wrote: At 10:25 PM 2/13/2006, Chuck Swiger wrote: Vinny Abello wrote: [ ... ] Nevermind. I just answered my own question. I should have RTFM more carefully. :) :-) If CPUTYPE is defined in your /etc/make.conf, make sure to use the ?= instead of the = assignment operator, so that buildworld can override the CPUTYPE if it needs to. I am thinking if I change to CPUTYPE?=pentium4 I will be ok. Does that sound correct or am I still barking up the wrong tree? If you weren't having any problems, feel free to experiment. Since you don't gain much by using the machine-specific compiler optimizations for the kernel, it is worth turning them off to see whether the resulting kernel still has the same problem... Will give it a shot and see what happens. So far buildworld isn't using CPU specific optimizations with the CPUTYPE?=pentium4 as documented so I have a feeling that will fix my problem. I actually started having problems after rebuilding world from this source a second time with (what I thought) were more optimized compiler settings. Obviously not if they cause it to break. :) My kernel is the same from when it was working from the original CVSUP and original buildworld so I think I'll be ok with that. I'll rebuild it to be safe anyway though. Thanks again for your help! :) Just following up on this further. It seems the problem was a little more complex (or simple) than this... I had the same problem despite what settings I used for CPUTYPE in my make.conf file. As I stated earlier, booting into single user mode works fine and I have the correct date. I started looking at what was loading on startup when going multiuser. I basically commented out my whole rc.conf.local file except for SSH and then time was correct upon bootup! I put everything back except for time related programs, but the problem came back. I uncommented all my time stuff and on a hunch, I commented out only the line to enable a Backup Exec port from starting. Having this disabled made it so on every startup my system time is now correct. I had noticed an error when that agent was starting since upgrading which I was going to look into. I know it is actually a Linux binary and relies on Linux compatibility in FreeBSD. I'm not sure if the binary was just damaged or if my Linux binary compatibility or some libraries are out of sync. Regardless, I seem to have found the problem... I need to update to the newest agent from Veritas/Symantec anyway instead of this port, although I don't know if that works well either. I'll look into that tomorrow and look into possibly rebuilding my Linux binary port containing the libraries as well, although that was really the only reason I had it installed and my not need it. What is odd is my kernsecurelevel is set to 2 and the time still gets massively adjusted, incorrectly somehow to boot. I think that binary was run in the startup rc scripts prior to kernsecurelevel being raised from -1 to 2 though. Actually, I'm sure of that now, so nevermind. Thanks again for the help. I just wanted to post back what I found to share with others in case someone ever runs into the same oddity. P.S. I CVSUP'ed STABLE, built the kernel and did buildworld with CPUTYPE?=prescott which more accurately matches my actual CPU type. No problems at all to report. :) Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems Booting 6.0 RC1 on ia64
At 01:07 AM 10/23/2005, Joe Kelsey wrote: I am trying to boot up 6.0 RC1 on a brand new ia64 box. I have an ASUS A8V motherboard with an AMD64 3800. I have a DVD writer attached to the ATA bus and two SATA disk drives. On my x86 box (5.4), I download the 6.0 RC1 ia64 disc ISO images and burn them onto CD-ROM. I then take the new CD-ROM and put it in the ia64 drive. The system starts the boot process (with boot drive set to the DVD writer), but errors out and asks me to insert a valid boot drive. What have I done wrong here? If what you've typed is correct, you've mistaken the Itanium build for the AMD64 build of FreeBSD 6.0 RC1. Try downloading the AMD64 version and see how that fairs. Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acc Monitor error message
At 11:25 PM 8/17/2005, Huang wen hui wrote: hi, I have DELL PE4600 server with acc driver , running 5.4 Release. when system boot, got this message: Mounting root from ufs:/dev/aacd0s1a aac0: **Monitor** ID(0:02:0); Error Event [command:0x2a] aac0: **Monitor** ID(0:02:0); Hardware Error [k:0x4,c:0x19,q:0x0] aac0: **Monitor** ID(0:02:0); Defect List Error The system uptime is 87 days and I do not hit any problem. Is this message harmless? It looks like your PERC RAID controller might be telling you there is a detected problem with one of the drives (id 2), possibly. I'm not sure what a SMART error looks like coming from the aac driver in FreeBSD, but that could possibly be it. Usually, the drive in question will physically change the status light from solid green to a flashing amber or flashing amber and green... I think the later if it's a SMART failure. If everything looks ok on the server, someone more knowledgeable about the aac driver and PERC controllers would have to comment. Then again I could be misinterpreting it, but seeing as you got no other responses it's a place to start looking. Look at the drive in slot 2. Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make -j as a stress test (was: Re: Quality of FreeBSD) [WARNING - 6.0-BETA1 still hosed!]
3Ware cards will work with 32 bit PCI buses. At 10:20 AM 7/24/2005, Karl Denninger wrote: Those cards all have (and appear to require) PCI-64 (double-connector) bus plug-ins. For those of us with single PCI bus slots (e.g. those of us who don't have Opterons), that simply won't work unless I'm missing something. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://homecuda.com Emerald Coast: Buy / sell homes, cars, boats! http://genesis3.blogspot.comMusings Of A Sentient Mind On Sun, Jul 24, 2005 at 12:06:16PM +0100, Robert Watson wrote: On Sun, 24 Jul 2005, Mike Tancsa wrote: At 12:00 AM 24/07/2005, Karl Denninger wrote: Finally, any pointers on a 2 port PCI SATA board that (1) is KNOWN to work, (2) has EXTERNAL SATA connections, and (3) isn't one of those whiz-bang all-in-one-RAID thingies that costs $500? 3ware makes an excellent 2 port SATA card (8000 series) that works very well. Its about $110 USD from various online sources. You can use it as RAID1 or 2 independent disks. They work very well and are well tested in FreeBSD. One of the things that makes 3ware a particularly encouraging choice is that 3ware helps maintain their driver on FreeBSD, as well as putting it through their own test environment with their hardware. 3ware's driver developer also has a FreeBSD commit bit so that he can maintain it directly. The fact that vendors like 3ware and others (Intel, etc) get directly involved in testing and maintaining their drivers on FreeBSD is one of the things that gets them on my recommendation list for hardware purchases. Robert N M Watson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] %SPAMBLOCK-SYS: Matched [EMAIL PROTECTED], message ok ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP support maturity? AMD64x2 or FX-57?
At 04:27 PM 7/22/2005, Frank Mayhar wrote: Brandon Fosdick wrote: SMP support in FreeBSD seems to be a perpetually favorite feature to gripe about, but every release seems to say that its getting better. I'm about to build a new server and am trying to determine if I should go with dual procs or just a single. The AMD64x2 is slightly cheaper than the FX-57 so I'm leaning that way, but it would be a rather pointless savings if SMP isn't well supported. So, is SMP in -STABLE ready for primetime? Can it really make use of two processors? Sigh. You know, I've been running with two processors since 4.1 or thereabouts. Sure, the BGL scheme is inefficient as far as the kernel itself is concerned, but for compute-bound user processes it worked just fine. Naturally I avoided 5.0/1/2 for my production boxen, waiting for the complete overhaul of SMP to stabilize, but when I booted 5.3, everything was fine and I haven't looked back. Personally I don't have the first clue what people have found to gripe about. It has been good, it got a _lot_ better in 5.x, and it's continuing to improve. Ports to new processor families are an entirely different kettle of fish and have their own sets of problems, virtually all of which have to do with the new architecture and not with the general SMP support itself. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ I agree. I'm not a FreeBSD expert by any means, but I do enjoy using it very much. I've learned a lot about it over the past year or so that I've been running it. I have both a 4.11 and 5.4 box that have dual processors and are running like champs. The 5.4 box is doing a lot more work actually, and it never has a problem. It's been all good for me, but then again, I probably don't delve quite as deeply into some of the complex heavy loaded things other do. Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Another ata and dma problem - maybe because INTEL
At 09:49 PM 7/7/2005, you wrote: Hi, i`m using freebsd releng_5 and got weird problem with AtA_DMA... I bought mobo with i865PE chipset and when I allow DMA transfer in BIOS for my TEAC cd-540E drive, freebsd fails to boot with: ATA_INTERRUPT was seen but timeout fired out with LBA=0.. I also tried applying a ATA mkIII with no luck(it tells me that ata_if.h is missing). When I remove teac from my system, it boots correctly. I tried also in loader.conf typing hw.ata.atapi_dma=0, but still the same...fails to boot. I`ve before this mobo with VIA kt333 chipset, and it allows me to set PIO4 for drive (with no problemo at freebsd boot) Any ideas or patches? Just out of curiosity, check to make sure you have the latest firmware for the Teac drive. I recall encountering problems with a Teac CD-ROM drive on a new motherboard with a fairly new chipset on the market (this was a long time ago) until I updated the firmware in the drive. I couldn't boot any OS off the drive, yet it worked fine on other motherboards. It's worth a shot. You might have similar problems with any OS on that motherboard and CD-ROM drive. Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Old messages
At 12:09 PM 7/3/2005, Jaimie Garner wrote: I did not are signed up for daily digest of single messages? I am set up for single messages. Maybe that has something to do with it. On Sunday 03 July 2005 9:05 am, Kövesdán Gábor wrote: So did I. Andy Gilligan wrote: Ok, is it just me or did anyone else receive a bunch of mails to -stable from about 6-7 months ago? I got about three or so messages from way back... One was commenting on FreeBSD 5.3 being released soon! :-P I thought the date sorting in my email program got messed up, honestly. ;) Glad it wasn't just me. I receive separate single messages myself and still got them. Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: re0 no carrier problem - Patches found in archives didn't work.
At 07:09 AM 6/19/2005, Marcin Koziej wrote: [04:12 19-06-2005] Tom Pepper [EMAIL PROTECTED] this may seem obvious, but do you still have the same issue if you statically define the mediatype to a fixed link speed and duplex? lots of interfaces have problems negotiating autoselect with switches, as protocols vary widely. the blinking is indicative of autoselect setup woes... This wasn't obvious for me! Thanks for the answer! When I set the media by hand it showed 'active', but no data could be transmitted (yellow link diode on switch, not blinking). I then pulled the switch with my home lan from the wall and plugged my re0 instead - It worked! So this seems to be the %$R#(@%*$ switch issue. The funny thing is, that with media set manually (or sometimes with autoselect) everything works fine with this switch (i have used it all day yesterday till evening without problem). Now, when i wait some time with media manually set, it starts transmitting data and everything works fine. Why does it happen? Why is it so unpredictible? Can it be fixed in software, or should i throw the switch out the window and by a new one? I may be replying to the wrong thread, but if I remember a previous post, this is for a realtek gig-e card going to a gig-e switch... Just another obvious point but you are using either Cat-5e or Cat-6 cables, right? Just thought I'd offer another obvious suggestion. :) Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: DELL PowerEdge 2850 and FreeBSD 5.4
What BIOS revision are you running in your 2850? Make sure all your firmware is up to date. I had problems with an slightly older Dell 2650 trying to install FreeBSD until I flashed the latest RAID controller firmware. If this doesn't help, try running some diagnostics on the hardware. Dell has some pretty extensive utilities. I think you can boot a Dell diagnostic CD you download from their web site. It's possible you have bad RAM. At 11:50 AM 5/31/2005, Danny Cooper wrote: With the kernel I removed all non-required devices Firewire, usb all the NIC's except em and removed all RAID and SCSI controllers to make sure nothing would interfere. I tried to boot with the AMD64 CD but with no success, the machine just hangs when it tries to load the CD, still trying to work out a solution to the problem, but it just seems these DELL 2850 machines are for Windows or RedHat!!! DC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Claus Guttesen Sent: 31 May 2005 16:15 To: Danny Cooper Cc: freebsd-stable@freebsd.org Subject: Re: DELL PowerEdge 2850 and FreeBSD 5.4 I have installed FreeBSD 5.4 RELEASE and upgraded to -STABLE on a DELL PE2850. FreeBSD 5.4-STABLE #1: Wed May 25 23:43:12 BST 2005 CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3192.22-MHz 686-class CPU) real memory = 5100273664 (4864 MB) avail memory = 4189892608 (3995 MB) MPTable: DELL PE 016D FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 amr0: LSILogic PERC 4e/Di Firmware 516A, BIOS H418, 256MB RAM I have disabled ACPI HTT and enabled PAE to make the whole system memory available. However the problem I have is the system can crash at any moment, and is not load related. As the crash info below is when the machine was in an 100% idle state. I have the same hardware as well, running on the i386-port. I have disabled usb with usbd_enable=NO in /etc/rc.conf. I have no idea whether this helps but havent't had an issue with the 2850. Except with a qlogic-hba and the isp-driver (I suspect) *on* amd64, but *not* on i386. Claus ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Poor network performance: a lot of timeouts
At 04:56 PM 5/30/2005, Sebastian Ahndorf wrote: Kris Kennaway wrote: Both sides must have same config, autosense should work if there is no config possibility in other end. autosense may in fact not work, especially on low-quality NICs like rl. I don't agree to that. I had similar problems with my network using a cheap switch with some realtek nics. I had the nics running 100baseTX Full Duplex. Changing this to autosense made the problems gone. Reason (as some people of the german questions-list told me): Many cheap switches always send their autosensepakets, and have great problems if the nics connected to the switch do not response to the autosensepakets (cause they are configured to 10/100baseTX full/half duplex). Also realtek nics are far away from being good nics, they work without problems with the autosensemode and a cheap switch for me (and many other people I know). I would suggest the starter of this thread to use autosense with his nic (if not tested yet). The deal is simply this: Autosense must be enabled on both sides to autonegotiate speed/duplex. If you force one side to full duplex, the other side still autosenses (on most unmanaged switches), fail, and will fall back to half duplex causing a duplex mismatch. You have to force the other side to full duplex as well. If you cannot do this, leave it at auto, or set the side you can manage to half so they agree. I personally like to leave everything on auto except links between switches and between routers and switches which I force to full. It always works out well for me on practically any platform or OS. Maybe on one or two occasions I've experienced faulty drivers which cause the autosensing to not work on the NIC and just default to half duplex. Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can FreeBSD be installed on DellPowerEdge2800 ?
FYI, the architecture of the 2850 (assuming it is similar to your 2800) requires that you enable PAE support in your kernel of whatever OS you run to address the full 4GB of RAM. This is due in some part because of the memory mapping that was done for the PCI express bus and/or onboard Perc controller (per Dell tech support). We've run into this with all of our 2850's with various OS's and enabling PAE (per Dell's advice) fixes it. At 05:50 PM 3/1/2005, Art Mason wrote: Indeed, just installed on a customer's server last night, and I build SMP support into the GENERIC kernel this morning. Only issues I encountered has to do w/ recognizing the full 4GB of RAM, but this apparently has some compatibility issues w/ the amr driver. As per Holger's comments about disabling USB in BIOS, this is a good suggestion, since the DRAC apparently causes some IRQ issues w/ the PS/2 keyboard controller, or something along those lines. Regardless, these 2850 boxes are stupid fast, and I'm looking forward to benchmarking 5.3 on them. -- Art Mason Technical Support - Team F Rackspace Managed Hosting (800) 961-4454 ext. 4290 [EMAIL PROTECTED] Kipp Holger wrote: On Tue 01.03.2005 17:49, lhmwzy wrote: Please reply to hk at alogis dot com. This is not my native account. Subject: Can FreeBSD be installed on DellPowerEdge2800 ? Yes Anybody did this? Yes. Any help is appreciateed? Boot from FreeBSD 5.3-RELEASE-CD and install. No problems so far. You might want to disable USB within BIOS, though, because they seem to be shared with other critical devices (nics and raidcontroller). But I don't use USB anyway. Then you might want to upgrade to 5-STABLE. This is on Dell PowerEdge 2800 with 2GB ECC RAM, 4 x 36GB SCSI and amrd-Controller (PERC-4-something). Binary copy of SAP 4.6C and Oracle 8 (from a working installation on FreeBSD 4.x) works nearly without changes (using emulators/linux_base-suse-9.1 and one additional rpm (some compatibility-thing)). Regards, Holger Kipp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN Courage is resistance to fear, mastery of fear - not absence of fear -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
