FreeBSD 5.3-BETA2 is now available directly or via ISO images. Release notes have changed little since BETA1 but several showstopping bugs have now been swatted. Much of the recent work has centered around the network and filesystem layers, ACPI and testing of the ULE scheduler which will become the default in 5.3. Elsewhere, Open For Business, Ed Hurst has another in a series of articles introductory articles describes describing FreeBSD; for email (part 5) purposes.
FreeBSD 5.3-BETA2 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
look at the release schedule you could have seen 5.3 Beta2 would be released by now
beta 3 will come around 3 sep and beta4 will be around sep 10
then the RC will arive 17 sep RC 1 and 24 sep RC 2 if all goes acording to plan
Heh. Just like Beta 1, this one does not recognize my NIC (a formerly well supported card under FreeBSD since at least version 4.7, as well as every other BSD and Linux distribution I’ve ever tried), and nothing I do will make it work (betas are fun aren’t they?
I sent a pr during the first beta, and again just now. I sure hope that someone over there wakes up and fixes it before the next beta, as I’ve been waiting to try a version of FreeBSD with KSE, ULE and X.org for such a long time now.
Well, what kind of NIC is it?
In all likely hood, it’s an ACPI problem not assigning the NIC an interrupt. Try booting with ACPI disabled.
Heh. Just like Beta 1, this one does not recognize my NIC (a formerly well supported card under FreeBSD since at least version 4.7, as well as every other BSD and Linux distribution I’ve ever tried), and nothing I do will make it work (betas are fun aren’t they?
Not sure if you’re just trolling or what. Someone who isn’t trolling would have at least mentioned what NIC it was that wasn’t detected. I’ll give you the benefit of the doubt and assume that you’re not trolling. Perhaps that NIC was taken out of GENERIC for some reason. Why don’t you tell us what that NIC is?
I sent a pr during the first beta, and again just now. I sure hope that someone over there wakes up and fixes it before the next beta, as I’ve been waiting to try a version of FreeBSD with KSE, ULE and X.org for such a long time now.
Sending a pr (problem report) is a good thing. I commend you on that. Most people are too lazy to do it. They just bitch that it doesn’t work and don’t even let anyone know exactly wha the problem was. Developers can’t fix it if they don’t know about it.
I am not trolling, and I am taking offense here, but I’ll forgive you as I did not mention the card. The FreeBSD driver for my card has always been rl, the card, a D-Link DFE-538TX.
You know you can buy one for like $20?
If one long supported card loses a driver, what’s to stop that happening to any other? Should we just plan to buy new NICs every time an OS comes out with a new version?
Use your head.
well dispite what most people think (well the attitude often shown here at this site) I think there is room for both linux and freebsd to exist. Now i just installed this latest beta and I’ve got to say i’m pretty impressed ( minux the known issues i’m giving them the benefit of the doubt that they will be fixed) sure freebsd isn’t as polished as a desktop than linux is but it has never been its intention to.
I think DLink NIC uses the VIA? Rhine? chipset (could be wrong) just a cheapie, no worse/better that the realtek, just not as common.
It’s probably more likely that the driver hasn’t been updated to handle the changes made to networking code, or isn’t MPSafe or something.
One can probably assume it’s on someone’s TODO list, along with all the other NIC drivers.
The last release didn’t have any real show-stoppers for me, so I’m really looking forward to this release
many companies started to support FreeBSD.
if concentration of FreeBSD Kernel increases , then sure it will be No.1 without any rumours…
Come on guys, Yesterday we had enough flame on the FreeBSD poll.
Why is there so much hate against FreeBSD?
It’s a clean a robust OS, it works just seemless most of the time, and like Windows or Linux, sometimes one has to search for help to solve software or hardware problems, but hey, I think it’s worth the hassle once fixed. It works great, and let’s stop saying it’s less popular than Linux or harder to use than Windows. One should choose the OS we’re more comfortable with, and stop criticizing the other guys just because they don’t use the OS we think is right.
I second that
On FreeBSD there is also APIC to worry about… which AFAIK, needs to be compiled into the kernel since it is not in the defualt. Not taken time to mess with it yet, but I am guessing this could also be a problem. Not sure if it will lead to something not being detected, but there have been reports of it leading to IRQ problems in some situations. There where discussions on this revolving around a vr ethernet card recently going on either current or questions mailing lists recently, iirc. There where a few suggestions on how to solve it. On mine I just took the simple path, disabled APIC and it worked fine.
It’s very hard for us geeks not to criticise. But if you hold back on the criticism you might become more popular and increase the number of friends you have. Also you feel better.
Recently when I upgraded from RELENG_4 to RELENG_5_2 (5.2.1) I had similar problems. I bet your NIC IRQ is being routed to a virtual IRQ. Here’s what I did to spot the issue:
`systat -vmstat 1`
Take a look under the “Interrupts” column and pay attention to your NIC. With light network load, you shouldn’t see too many interrupts per sec (since the ‘1’ in the command line is a one-second resolution). With the problem, I was averaging about, oh 5000 – 15000 a _second_. Needless to say, my NIC wasn’t too responsive. I ran `ps ax | grep -i irq` to see what the IRQ was assigned to the NIC. It was something above 15. I then ran `less /var/run/dmesg.boot` to see what the IRQ assignments were. Here’s it on the good system:
**SNIP**
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib0: slot 1 INTA is routed to irq 15
agp0: <NVIDIA nForce2 AGP Controller> mem 0xd0000000-0xd3ffffff at device 0.0 on
pci0
pci0: <memory, RAM> at device 0.1 (no driver attached)
pci0: <memory, RAM> at device 0.2 (no driver attached)
pci0: <memory, RAM> at device 0.3 (no driver attached)
pci0: <memory, RAM> at device 0.4 (no driver attached)
pci0: <memory, RAM> at device 0.5 (no driver attached)
isab0: <PCI-ISA bridge> at device 1.0 on pci0
isa0: <ISA bus> on isab0
pci0: <serial bus, SMBus> at device 1.1 (no driver attached)
pcib1: <ACPI PCI-PCI bridge> at device 8.0 on pci0
pci1: <ACPI PCI bus> on pcib1
pcib1: slot 8 INTA is routed to irq 10
xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xd000-0xd07f mem 0xdf000000-0xdf00
007f irq 10 at device 8.0 on pci1
**/SNIP**
For the NIC (xl0), see the last part (linefeed) reading “device 8.0 on pci1”. Now, look above and see the line “pcib1: slot 8 INTA is routed to irq 10”. While I can’t remember what they were, I could tell the interrupt was being routed to a higher IRQ value. To resolve this, I had to fiddle with the BIOS and turn off a lot of devices within it. I have an NVIDIA board, which I’ll never get again, that enables a bunch of IRQ-grabbing stuff that _cannot_ be disabled. It took a bit of patience twiddling w/ this and that value before I got it to the point where the NIC IRQ wasn’t routed.
HTH and good luck!
Jon
Why does uname -a on FreeBSD 5.3 beta show FreeBSD 6.0???
best regards
Dev
Because you synced with CURRENT not RELENG_5
*default tag=RELENG_5
ports-all TAG=.
should work I think, giving you current ports and RELENG_5 branch sources.
CURRENT is now FreeBSD 6.x
Duh! If you were running 5.3-BETA, it would show as 5.3-BETA. Hence, you aren’t running 5.3-BETA.
tag=. will always get you -CURRENT. With the branching of 5.3 as the new -STABLE branch, -CURRENT has been bumped to 6.0.
You want tag=RELENG_5 to get the BETA.
should i also use releng_5 for the ports tag?
grtz
Ports *always* use tag=.
There is only 1 ports tree.