FreeBSD 8.1 may have broken my Eee's ethernet

G

GullibleJones

I decided to test out 8.1 today on my EeePC 1005HAB. According to some Eee wiki stuff I read, the 1005HA and HAB are supported as of 8.1, though the ethernet is still a little dodgy.

Exactly how dodgy, I clearly did not anticipate.

I installed. I tried to set up the network... And failed (no carrier). I rebooted and tried to set it up again (still no carrier). Reconnected the cable, checked to make sure everything was plugged in, still no carrier. Rebooted into Linux, still no carrier.

Edit: wherever the CMOS battery is, I can't find it - it looks like I'd have to disassemble the netbook, in which case I might as well just scrap it. Bah.
This was when it hit me: I'd seen this before. In Linux kernels prior to 2.6.31, loading the atl1c driver used for the 1005HAB's ethernet controller triggers a firmware crash. To fix this, you have to shut down the netbook, unplug the battery and power, wait thirty seconds, then plug everything back in and boot up again, and it will work like new (provided you don't load the old driver, which will start the whole thing over again).

So I shut down, unplugged the battery and power, waited thirty seconds, made sure everything was plugged in right, and booted into Linux again...

Still no carrier. x(

Guess I'll try clearing CMOS next, assuming I can reach the CMOS battery. Meanwhile, I figure you people ought to know that there may still be some really serious issues with Attansic ethernet controllers.

Edit: tried clearing CMOS, didn't work. Looks like this computer is scrap.
 
Not true. There was a bug in a development version of the Linux kernel, not long ago, which could corrupt the firmware of certain Intel ethernet controllers and render them unusable.

However, that's not the case here... It turns out that I was leaving out one factor - my ethernet switch. :r

I was able to get ethernet working again by moving to a different port on the switch... And then, by booting into FreeBSD again, I was able to remove the connectivity. Furthermore, once a port had been exposed to a DHCP request from the FreeBSD install, other computers couldn't connect to that port either. Resetting the switch fixed this. So, I'm not sure what exactly is going on, but it looks as though something about the way dhclient was configured, or maybe something about the alc driver, was causing ports on the switch to stop working.

(The switch is a cheap Linksys model, FWIW.)

If anyone knows what might cause something like this, I'd sure love to know...:\
 
SirDice said:
Until you replaced the firmware. Software can never destroy hardware.

http://blog.vodkamelone.de/archives/146-Unbricking-an-Intel-Pro1000-e1000-network-interface.html
Click to expand...

Software can overclock your hardware and grill it, software can destroy your monitor, software can use false (undocumented) commands and destroy the firmware of your dvd-drive etc. pp. Almost anything is possible, especially if you try to write something without proper specifications aka reverse engineering. Yes software doesn't act due its own intention, but because of some developer writing such faulty software. Sometimes you need user intervention to make it happen, but it can happen in some rare situations just because of just using it. So, software _can_ destory hardware. Let's stick to the reality and let philosophy aside.
 
oliverh said:
Software can overclock your hardware and grill it,
Click to expand...
That's hardware. The software doesn't supply the clock signal.

software can destroy your monitor,
Click to expand...
A modern monitor will switch off.

software can use false (undocumented) commands and destroy the firmware of your dvd-drive etc. pp.
Click to expand...
Firmware can be replaced.
 
>That's hardware. The software doesn't supply the clock signal.

That's software, if you 'overclock' your hardware by intention, you do it with software. You're maybe thinking of something like the Core i7, but that's a different story. I can even change the voltage by software. This is no magic, it's usual practice among some people.

>A modern monitor will switch off.

In theory, in practice it's not quiet uncommon.


>Firmware can be replaced.

The example wasn't about the firmware replaced by a user, but the use of a undocumented command, which under some circumstances without any user intervention does quiet the opposite. Seen some years ago, I think it was Mandriva.
 
oliverh said:
>That's hardware. The software doesn't supply the clock signal.

That's software, if you 'overclock' your hardware by intention, you do it with software. You're maybe thinking of something like the Core i7, but that's a different story. I can even change the voltage by software.
Click to expand...
No, you are changing hardware settings with a bit of software. It's still hardware that supplies the voltages/frequencies.

>A modern monitor will switch off.

In theory, in practice it's not quiet uncommon.
Click to expand...
This has been the case for about 10 years or so.


>Firmware can be replaced.

The example wasn't about the firmware replaced by a user, but the use of a undocumented command, which under some circumstances without any user intervention does quiet the opposite. Seen some years ago, I think it was Mandriva.
Click to expand...
Sigh, yes, the firmware would be corrupted. But it can also be replaced by a working, non-corrupt, version in the same way. After the firwmare has been restored the hardware will work fine. Hence, it's not destroyed or otherwise damaged.
 
SirDice said:
Software can never break or destroy hardware.
Click to expand...

A very complicated philosofical statement...

I'd say: a program can be made to detonate a bomb so a program can cause damage.
You can say that it is the bomb's ignition mechanism (hardware) that detonates it, but the explosion will be initiated when a piece of code changes te state of the "detonate button", in this case a logical switch, somewhere on a chip.
If this is not true, software would not be able to interact with the physical world at all and cannot be useful for anything.

This might sound strange but it is also possible to state that nothing can cause anything. Every event in the universe is caused by the big bang a long time ago. The only event that initiated itself without the need of any conditions.
 
GullibleJones said:
I decided to test out 8.1 today on my EeePC 1005HAB. According to some Eee wiki stuff I read, the 1005HA and HAB are supported as of 8.1, though the ethernet is still a little dodgy.

Exactly how dodgy, I clearly did not anticipate.
...
So I shut down, unplugged the battery and power, waited thirty seconds, made sure everything was plugged in right, and booted into Linux again...

Still no carrier. x(

Guess I'll try clearing CMOS next, assuming I can reach the CMOS battery. Meanwhile, I figure you people ought to know that there may still be some really serious issues with Attansic ethernet controllers.

Edit: tried clearing CMOS, didn't work. Looks like this computer is scrap.
Click to expand...

Try replacing the Ethernet cable first.

I've seen some weirdness with network devices where the manufacturer can't be bothered to provide programming information (looking at you, Broadcom and Marvell!) Even seen a burnt-out PHY on a 3Com card, which insisted it was still okay. But bad cables or bent-down pins in Ethernet connectors are much more common. And sometimes a switch gets annoyed and disables a port. It's a rich tapestry of pissed-off network devices.

If the firmware is corrupted, installing Windows drivers for the card might reprogram it. The manufacturer may have separate utilities or firmware updates that could also revive it.

Should all else fail, there's wireless or USB Ethernet.

It's worth entering a PR if you are reasonably certain that the FreeBSD driver was responsible. The driver maintainer may have other suggestions.
 
Another idea is to shutdown the laptop completely before booting FreeBSD.

I had some issues with a realtek card in one of my machines. It would work fine in Windows but when I rebooted to start FreeBSD the card just wouldn't work. Only after turning off the machine completely would it work in FreeBSD. Rebooting from FreeBSD to FreeBSD, no problem. FreeBSD to Windows, no problem either. Only a reboot from Windows to FreeBSD didn't work. It seemed like Windows left the card in some weird state after a shutdown.
 
You must log in or register to reply here.
Back
Top