Re: 5.2-RELEASE TODO
On Wed, 3 Dec 2003, Tom wrote: On Tue, 2 Dec 2003, Eric Anderson wrote: Tom wrote: Just to be complete, there are already a whole bunch of machines that will not boot 5.x, irregardless of the ACPI issues. I've never been able to boot 5.x with ACPI on or off, on any of the 5 Dell PowerEdge 6350 servers I have here, even though they run 4.9 perfectly. I have a PR open on it. So even without the ACPI issues on some hardware, there are still other reasons why 5.x is going to fail to boot. Are you using a PERC in those boxes? I've seen issues with PERC controllers on 5.1, but 4.8 worked fine. I received a patch, which fixed it, but it's a bit hard to install the os, and then rebuild world without rebooting the machine. :) Well, there are so many kinds of PERC cards. Some are just Mylex cards. Others are MegaRAID. I think they use some Adaptec now. 1550 = lsi megaraid 1650 = adaptec 1750 = lsi megaraid 2550 = adaptec ( don't know the 2650 card just know ). perc stands for poweredge raid controller, so perc just means dell raid card nothing more nothing less. And with the dell habit of switching vendors every model that ain't very informative. -- Sten Spans There is a crack in everything that's how the light gets in. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Corrected gettimeofday() test code
On Sat, 29 Nov 2003, Kris Kennaway wrote: I forwarded the reports of timecounter problems to phk, and he asked that people who are seeing timecounter problems provide FULL details of their system configuration, including: snip Please note that there are quite a few broken timecounters out there, a lot of them break when HZ != 100. I encountered this with a newer revision of the dell 1550, the old revision was fine in this respect oddly enough. These problems do however show up quickly when running ntpd which will complain about a borked system clock every 10 minutes or so. Make sure that your hardware is good before blaming software :). HTH, HAND. -- Sten Spans There is a crack in everything that's how the light gets in. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em0 on install
On Sun, 23 Nov 2003, Randy Bush wrote: trying to install using the 5.1-release mini cd and em0. it seems not to dhcp (looked with tcpdump) despite my saying Yes (and no to ipv6). am i missing a clue? I can easily cause my em0 to stop working with a 5.1 kernel, by running find on a large filesystem across ssh. This seems to be fixed in current, I could not reproduce it with a 5.2-BETA kernel ( no changes in world ). The mtu size of 9014 may have something to do with the breakage :). -- Sten Spans There is a crack in everything that's how the light gets in. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: howto debug acpi_thermal on Dell 2500 servers
On Fri, 10 Oct 2003, Ken Menzel wrote: Hi, I am trying to figure out how to use ACPI to get thermal info on Dell 2500 servers. I have compiled acpi into the kernel (see below for problems with acpi as module with ACPI_DEBUG in make.conf). I can't seem to get any addtional info from acpi. Do I need a debug kernel? Do I have to have more options in my kernel config? Is someone already doing (done?) this and I shouldn't bother to try and debug it? I do know that on the dell 1550, temperature monitoring is done with an lm80, which didn't seem to want to play with smbus. (x)mbmon which opens /dev/io directly is able to get temperature readings. Might be worth a try. -- Sten Spans There is a crack in everything that's how the light gets in. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 3Com 3c905C-TX
On Wed, 1 May 2002, Guido Kollerie wrote: snip Unfortunately the switch is unmanaged hence I am not able to explicitely set the switch to 100 Mbits full-duplex. Using ifconfig to set the nic to 10baseT/UTP and then back to 100baseTX full-duplex doesn't help. Only a reboot will bring the NIC back to 100 Mbits full duplex mode. Please note that due to vagaries in the auto-negotiation spec 3com and cisco dont work well together. And 3coms ( on linux atleast ) have the added bonus of sometimes deciding to change speed/duplex just for the heck of it. The only way to use them reliably is to force both the card and the switch. We came to the conclusion that fxp's are a nicer option. IMHO just creating a reliable and clearly defined auto-negotiation protocol will do more for ethernet speed than gigabit ethernet :). -- Sten Spans What does one do with ones money, when there is no more empty rackspace ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 3Com 3c905C-TX
On Wed, 1 May 2002, Glendon Gross wrote: Out of curiosity, do only 3c509's exibit this behavior, or is this the core problem with 3c59x's as well? My experiences have not been consistent with these cards, and I had assumed it was due to buggy code in the 3-Com chipset. I've noticed flaky behavior from the Vortex [3c59x] card as well. I would assume is the chipset, because just out of the blue redoing negotiation doesnt seem like something that a sane driver would do. The most probable thing is that the card interprets normal traffic erronously as negotiation signals. Just now I have been wrestling with an ISA 3c509 which has a Lucent 40-01304 chip on it. At first the card was detected, and later not detected [on a different OS.]I vote for the fxp's as well, I've had hardly any problems with them. Is there a way to lock down the card by hacking the driver, so it won't try to auto-negotiate the connection? Like I said forcing it ( with the dos config tool ) helps, and solves the problems in most cases. But it's pretty workable when you force both sides. -- Sten Spans What does one do with ones money, when there is no more empty rackspace ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
