I intended to write up some sort of HOWTO for using the Toshiba Satellite A80-117 with Debian GNU/Linux for quite some time now, but I don't seem to get around to really finish it. So for now, I'll just release some quick hints about how to get everything working — I'll cover more details and stuff as soon as time permits.
Please consider this a draft and let me know if you have any comments.
Sometimes funny things happen. I spent several hours yesterday, trying to figure out why my laptop is responding so darned slow. I suspected it had something to do with the hard drive and I found out quite quickly that (U)DMA was disabled, hence the CPU had to do all the work. OK, no problem, I'll just do a
hdparm -c1 -d1 /dev/hda and everything will be fine. Or so I thought.
What I got was this:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Operation not permitted
using_dma = 0 (off)
Which means DMA could not be enabled. I noticed an error message in the output of
dmesg which seemed related:
ide0: Speed warnings UDMA 3/4/5 is not functional. Some people had the same problems because they were missing the correct option in the kernel (mine is
CONFIG_BLK_DEV_PIIX), but that was not my problem. After a few hours of googling and 6 or 7 kernel recompiles, I gave up and went to bed.
Now to the funny part: Today, John Choffee posted a comment about bashpodder in my blog. Curious as I am, I also visited his blog and in his "LinkFeed" box a tiny entry caught my attention: [PATCH] ich6m-pciid-piix.patch. Now guess what this patch (for Linux 2.6) does. It adds support for my specific type of IDE/(S)ATA controller, the "
Intel Corporation 82801FBM (ICH6M)". Patch, recompile kernel, reboot,
hdparm -c1 -d1 /dev/hda, bingo!
Here's the output of
hdparm -tT /dev/hda:
Before the patch:
Timing cached reads: 2468 MB in 2.00 seconds = 1232.95 MB/sec
Timing buffered disk reads: 8 MB in 3.84 seconds = 2.08 MB/sec
After the patch:
Timing cached reads: 2624 MB in 2.00 seconds = 1312.20 MB/sec
Timing buffered disk reads: 88 MB in 3.00 seconds = 29.33 MB/sec
Thanks John, you're my personal hero today.
Update 2006-03-01: The URL for the patch is broken. This one works.
I have updated my iptables scripts again.
This time fw_laptop got support for limiting logging in case of flooding, blocking of known-bad IP addresses (e.g. from DShield.org), optional blocking of certain outbound ports (e.g. X11 server, VNC, NFS etc.), and a few minor tweaks...
Thanks to Ryan Giobbi for several hints and comments. Further comments and suggestions are welcome!
To be able to do this, they need a new server (free rack space and bandwidth are provided by OSL) for which they are seeking donations now.
It's also planned to create a non-profit organization which will hold the funds, so the donations will be tax-deductible...
More than two weeks ago I blogged about my server being down. After multiple emails, phone calls, and even a fax trying to reach the support team, the server is still dead. But at least I know (a little bit) more now.
I managed to get someone from support on the phone and he fixed the system at least so far that I could ssh to it again. I was able to pull a complete backup of the system, including a database dump.
That means that Unmaintained Free Software and all other sites hosted on the server will eventually return, no data will be lost.
After I created the backup, I wanted to reinstall the whole system and then install the backup to restore all services. As it turned out, the (automatic) reboot- and reinstall-script they use is obviously broken, I cannot reach the server anymore after I initated the reinstall. This is probably something more serious, as other people seem to be affected, too.
I have not the slightest idea what the hell happened on the server. There was something really, really strange going on. An example:
# ls -l /usr/bin/traceroute
-rw-rw---- 1 mysql mysql 310872 Jun 21 03:21 traceroute
Why the hell is
traceroute not executable and belongs to user/group
mysql? There are several other anomalies there:
/usr/share/doc/apt is not a directory as it is supposed to be, but a Perl script.
/usr/bin/id is a directory. Multiple system tools (awk, sed, ...) are not executable and partly directories with strange stuff in them. What gives?
One possible explanation is that the server was hacked and some rootkit wrecked havoc on the server. After a quick glance at the logs, I couldn't find any hints for a successful breakin, though. Another possibility is that the hard drive simply died and/or the filesystem was (heavily) corrupted. I don't know...
Has anybody ever seen something like this? Please enlighten me what could have happened...