Problem with FreeBSD 6.1 install

[n0cmonkey]

Originally posted by: Chaotic42
Sorry, the chipset heatsink fell off of my main system, and I've been trying to get it fixed. 🙂

I haven't really messed with the BSD system for a few days. It seems stable, the error only happens when I'm getting the "base" package. Everything else seems to work fine. I haven't had time to mess with the kernel much though.

As far as linux goes, I'm trying to diversify.

I should mention that I need SMP support. IIRC, OpenBSD didn't have SMP support last time I checked.

You haven't checked in a while. It has rudimentary SMP support for i386 and amd64. It's had it for a couple years now, I think. 😉

 

[Nothinman]

You haven't checked in a while. It has rudimentary SMP support for i386 and amd64. It's had it for a couple years now, I think.

But it depends on just how rudimentary the support is, if there's one big kernel lock all kernel resources will be contended via that lock slowing down anything except for purely CPU bound processes.

 

[n0cmonkey]

Originally posted by: Nothinman

You haven't checked in a while. It has rudimentary SMP support for i386 and amd64. It's had it for a couple years now, I think.

But it depends on just how rudimentary the support is, if there's one big kernel lock all kernel resources will be contended via that lock slowing down anything except for purely CPU bound processes.

It's so basic OpenBSD hasn't even finished their kernel threading project. 😛

 

[SleepWalkerX]

Originally posted by: n0cmonkey
I said Linux's wireless support is craptastic, SleepWalkerX posted an OLD link (OpenBSD 3.7, OVER A YEAR OLD AT THIS POINT) displaying OpenBSD's (then) current wireless support. He said that Linux supports all of those and more (I'm guessing he means now as opposed to then, and despite the fact that several people seem to think Linux is falling behind).

Couldn't find an hcl for any of the bsds. Do they support the broadcom driver?

And I don't like just referring to getting support from just the kernel. Take a look at the acx100/111 project. I'm not sure why they're not included in the kernel. They have stable drivers that have been out for a while and they're gpl'd. The only reason I can think of is because they resorted to reverse-engineering to create their drivers.. Either this or I just can't find them in there.

 

[drag]

Originally posted by: SleepWalkerX

Originally posted by: n0cmonkey
I said Linux's wireless support is craptastic, SleepWalkerX posted an OLD link (OpenBSD 3.7, OVER A YEAR OLD AT THIS POINT) displaying OpenBSD's (then) current wireless support. He said that Linux supports all of those and more (I'm guessing he means now as opposed to then, and despite the fact that several people seem to think Linux is falling behind).

Couldn't find an hcl for any of the bsds. Do they support the broadcom driver?

And I don't like just referring to getting support from just the kernel. Take a look at the acx100/111 project. I'm not sure why they're not included in the kernel. They have stable drivers that have been out for a while and they're gpl'd. The only reason I can think of is because they resorted to reverse-engineering to create their drivers.. Either this or I just can't find them in there.

half of the drivers in the kernel right now are reverse engineered.

In fact lots computer companies got their start from reverse engineering other company's stuff. Adobe, for instance.

Or Compaq (now part of HP) made PC-compatable computers possible by reverse engineering the BIOS on a IBM PC.

Some people were kinda pissy 'about the acx100/111. I don't remember about it. Probably reverse engineered some drivers that EULA said you weren't allowed to reverse engineer them. Which, IMO, is not something that is legally enforcable. But I am just guessing.

 

[n0cmonkey]

Originally posted by: SleepWalkerX
Couldn't find an hcl for any of the bsds. Do they support the broadcom driver?

OpenBSD isn't. I'm guessing the others are.
OpenBSD platforms page. Click a platform and get an HCL.
NetBSD ports page. Click on an architecture (port in NetBSDese) and then on the supported hardware link.
FreeBSD 6.1's hardware list. Click on a platform to see a list.

And I don't like just referring to getting support from just the kernel. Take a look at the acx100/111 project. I'm not sure why they're not included in the kernel. They have stable drivers that have been out for a while and they're gpl'd. The only reason I can think of is because they resorted to reverse-engineering to create their drivers.. Either this or I just can't find them in there.

Anything not in the kernel proper is experimental at best. If it was quality it would be in the kernel.

 

[n0cmonkey]

I gave a live Linux cd a chance yesterday. It's one of the many specific purpose oriented live cds, and probably not increadibly up to date.

I was using an RALink based PCI card, with WEP encryption on the AP.

The ifconfig utility isn't wireless aware. That's a major shortcoming IMO, requiring yet another tool to become familiar with...

The iwconfig utility doesn't handle hex keys very well. It seems to expect dashes in the key, and doesn't like the 0x prefix to the hex key. The 0x thing isn't mentioned in the man page (under key/enc or BUGS), and was a major hold up for me. I think just about every other system I have uses it.

ifconfig also didn't tell me which interface was which either. I had eth0 and eth1. One of them was an onboard adapter, and the other was the wireless card. Which one was which? I didn't see any identifying information in the ifconfig output, which is quite disappointing.

Over all it made me glad I use OpenBSD. 😉

 

[Nothinman]

OpenBSD isn't. I'm guessing the others are.

That's stupid, the Broadcom chips are probably the first or second most popular embedded wifi chipset in notebooks. I know, buy a card and use that instead, but that's a crappy solution since working docs are now available even though they're not from Broadcom.

Anything not in the kernel proper is experimental at best. If it was quality it would be in the kernel.

Hardly, that's like saying that anything not in OpenBSD's base is experimental at best. I doubt you would recommend everyone stay away from packages not maintained by OpenBSD.

ifconfig also didn't tell me which interface was which either. I had eth0 and eth1. One of them was an onboard adapter, and the other was the wireless card. Which one was which? I didn't see any identifying information in the ifconfig output, which is quite disappointing.

That's one reason why iwconfig is useful, it'll easily idenfity which cards are wireless.

 

[n0cmonkey]

Originally posted by: Nothinman
That's stupid, the Broadcom chips are probably the first or second most popular embedded wifi chipset in notebooks. I know, buy a card and use that instead, but that's a crappy solution since working docs are now available even though they're not from Broadcom.

It's entirely possible someone is working on it. I don't know. It doesn't appear to be a priority though.

Hardly, that's like saying that anything not in OpenBSD's base is experimental at best. I doubt you would recommend everyone stay away from packages not maintained by OpenBSD.

Patches to OpenBSD's kernel that aren't in the main kernel are experimental.

That's one reason why iwconfig is useful, it'll easily idenfity which cards are wireless.

It took me a while to figure that out. 😛 Wireless cards are quite recognizable in OpenBSD through ifconfig, and they would be even if they all used the same identifying name (ie. eth?).

 

[Nothinman]

It's entirely possible someone is working on it. I don't know. It doesn't appear to be a priority though.

Besides the fact that Broadcom doesn't provide the firmware in a downloadable fashion I don't a reason why they wouldn't.

Patches to OpenBSD's kernel that aren't in the main kernel are experimental.

I didn't mean the kernel, I meant userland.

Wireless cards are quite recognizable in OpenBSD through ifconfig, and they would be even if they all used the same identifying name (ie. eth?).

So? Different isn't automatically bad. I don't mind using iwconfig because it presents a decent amount of information and would rather not have ifconfig output effectively doubled for wifi cards. Things like essid, AP MAC, link strength, etc don't fit into ifconfig IMO.

 

[n0cmonkey]

Originally posted by: Nothinman

It's entirely possible someone is working on it. I don't know. It doesn't appear to be a priority though.

Besides the fact that Broadcom doesn't provide the firmware in a downloadable fashion I don't a reason why they wouldn't.

Lack of time. Lack of developer interest. Lack of hardware. Who knows. 😛

Patches to OpenBSD's kernel that aren't in the main kernel are experimental.

I didn't mean the kernel, I meant userland.

My comments had nothing to do with userland, so talking about it is pretty worthle.

Wireless cards are quite recognizable in OpenBSD through ifconfig, and they would be even if they all used the same identifying name (ie. eth?).

So? Different isn't automatically bad. I don't mind using iwconfig because it presents a decent amount of information and would rather not have ifconfig output effectively doubled for wifi cards. Things like essid, AP MAC, link strength, etc don't fit into ifconfig IMO.

I think they fit just fine. ifconfig configures a network interface. Those settings are part of that configuration. If I'm bored when I get home I'll post the output, it isn't an insane amount of data.

Different isn't bad objectively, just subjectively. And my posts WRT this are subjective. 🙂

 

[Nothinman]

Lack of time. Lack of developer interest. Lack of hardware. Who knows.

Maybe they just all got lucky and got Centrino notebooks. =)

My comments had nothing to do with userland, so talking about it is pretty worthle.

Not at all. You deemed external drivers experimental just because they're not in the main kernel and that's a baseless label. The same label can easily be applied to software not included in any distribution's base install by your reasoning.

I think they fit just fine. ifconfig configures a network interface. Those settings are part of that configuration. If I'm bored when I get home I'll post the output, it isn't an insane amount of data.

Please do, I'd be surprised if they were able to make everything fit into a reasonable amount of space.

 

[n0cmonkey]

Originally posted by: Nothinman

Lack of time. Lack of developer interest. Lack of hardware. Who knows.

Maybe they just all got lucky and got Centrino notebooks. =)

They are big fans of thinkpads... 😛

Not at all. You deemed external drivers experimental just because they're not in the main kernel and that's a baseless label. The same label can easily be applied to software not included in any distribution's base install by your reasoning.

There are plenty of reasons not to install some 3rd party stuff in the base install, other than the software being experimental. I can't think of a good reason not to include drivers in the kernel if they're good enough.

Please do, I'd be surprised if they were able to make everything fit into a reasonable amount of space.

$ ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224
groups: lo
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7
ral0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:0e:2e:4f:f6:0f
groups: egress
media: IEEE802.11 autoselect (OFDM54 mode 11g)
status: active
ieee80211: nwid N0CNET chan 9 bssid 00:14:bf:31:4c:8d 70dB nwkey <not displayed> 100dBm
inet 192.168.1.233 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::20e:2eff:fe4f:f60f%ral0 prefixlen 64 scopeid 0x1
sk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:12:17:55:96:c6
media: Ethernet autoselect (100baseTX full-duplex,flag0,flag1)
status: active
inet 10.10.10.101 netmask 0xffffff00 broadcast 10.10.10.255
inet6 fe80::212:17ff:fe55:96c6%sk0 prefixlen 64 scopeid 0x2
fxp0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:20:ed:5e:60:af
media: Ethernet autoselect (none)
status: no carrier
pflog0: flags=0<> mtu 33224
pfsync0: flags=0<> mtu 1460
groups: carp
enc0: flags=0<> mtu 1536

I like their ifconfig output a lot better than Linux's anyhow. I can't remember what it is offhand, but I'm generally looking for some information in the linux output that I'm used to getting in the OpenBSD output and being frustrated I can't find it. 😛

 

[Nothinman]

I can't think of a good reason not to include drivers in the kernel if they're good enough.

There are plenty. Two that come to mind right now are that they could depend on other patches not submitted yet or they might not fit the kernel coding style yet. There is plenty of code that works just fine but isn't ready for inclusion yet and since they only settled on which 80211 layer would be included a few months ago they could be in the progress of converting to it.

I like their ifconfig output a lot better than Linux's anyhow. I can't remember what it is offhand, but I'm generally looking for some information in the linux output that I'm used to getting in the OpenBSD output and being frustrated I can't find it.

The fact that none of the BSD ifconfig's show rx/tx stats and interface errors has always bugged me. And the only thing I've thought could be in Linux ifconfig that isn't is forced media selection.