I recently almost died from a heart attack because after a really horrible crash (don't ask), Debian unstable on my laptop wouldn't boot anymore. The system hung at "Waiting for root filesystem...", and I was in panic mode as I feared I lost all my data (and as usual my backups were waaay too old).
At first I was suspecting that something actually got erased or mangled due to the crash, either at the dm-crypt layer, or the LVM layer, or the ext3 filesystem on top of those. After various hours of messing with live CDs, cryptsetup, lvm commands (such as pvscan, pvs, vgchange, vgs, vgck) and finally fsck I still had not managed to successfully boot my laptop.
I finally was able to boot by changing the initrd from initrd.img-2.6.30-2-686 to initrd.img-2.6.30-2-686.bak in the GRUB2 menu (at boot-time), at which point it was clear that something was wrong with my current initrd. A bit of debugging and some initrd comparisons revealed the cause:
Both, the cryptsetup and lvm2 packages were no longer installed on my laptop, which made all update-initramfs invokations (e.g. upon kernel package updates) create initrds which did not contain the proper dm-crypt and lvm functionality support. Hence, no booting for me. I only noticed because of the crash, as I usually do not reboot the laptop very often (two or three times per year maybe).
Now, as to why those packages were removed I have absolutely no idea. I did not remove them knowingly, so I suspect some dist-upgrade did it and I didn't notice (but I do carefully check which packages dist-upgrade tries to remove, usually)...
Good news for kernel hackers, and especially coreboot developers like me: AMD has released the chipset documentation for the RS780 chipset, including the BIOS Developer's Guide. And these documents are being released freely and openly to the public, no NDAs required, which is great!
The coreboot community, which includes government organizations, corporations, research labs and individuals from around the world, is very excited to expand on our existing and decade-long collaboration with AMD. This collaboration has, over the years, resulted in the inclusion of coreboot into everything from some of the largest AMD-based supercomputers in the world to some of the smallest embedded systems.
Together with the recent SB700/SB710/SB750 documentation release, the Developer Guide release for the RS780 family of Integrated Chipset/Graphics Processors enables the coreboot community to support any board with AMD chipsets out there, from embedded to enthusiast desktop and high-end server boards.
This new release once again demonstrates AMD's commitment to open standards and software that provides an improved user experience and Total Cost of Ownership for users in every walk of life. One cornerstone of this openness is the availability of documentation without NDA, enabling everyone to contribute.
Coreboot is open source, so every interested developer or user can modify, tweak and extend it to their heart's content.
An additional benefit of this documentation release is flashrom support for all AMD chipsets which enables users to reflash their BIOS/firmware/coreboot from within Linux and *BSD without rebooting.
Coreboot code for the SB700 and 780 chipset family is already being worked on by Zheng Bao at AMD in his spare time and the coreboot community is happy to work with him on finishing and integrating the code into the official coreboot codebase.
We'd like to thank Sharon Troia at AMD for making these documentation releases possible.
The exact download URLs are listed at http://www.coreboot.org/Datasheets.
I recently got a new (well, refurbished) laptop as a replacement for my old Toshiba A80-117 laptop which has more or less died. It's an IBM/Lenovo T40p laptop (model 2373-CG6), with an Intel Pentim M at 1.5 GHz. I chose this laptop for multiple reasons:
Downsides and missing hardware features (nothing too important, though):
Pretty much all of the hardware works flawlessly out of the box with a recent distro/kernel, see below for details.
Not needed, I simply popped out the 40 GB drive from the T40p and inserted my 160 GB (PATA) drive from my old laptop and that was it. Pretty much everything worked out of the box (see below), even though this is a totally different manufacturer, model, chipset, graphics card, wireless card, and so on. The only exception being (of course) my small Windows partition on that disk, which is now unusable as the drive is on different hardware and Microsoft doesn't like me to do that. Free Software: 1, Microsoft: 0.
Works out of the box using the snd_intel8x0 driver. The hardware is onboard audio in the southbridge (82801DB / ICH4) and uses the Analog Devices AD1981B codec.
Works out of the box using the bluetooth and hci_usb driver. The laptop's Bluetooth device is USB-attached internally and shows up in lsusb as:
$ lsusb Bus 003 Device 004: ID 1668:0441 Actiontec Electronics, Inc. [hex] IBM Integrated Bluetooth II
The device is not enabled per default though (which is a good thing), you can enable it like this:
$ echo enable > /proc/acpi/ibm/bluetooth
Disabling is equally simple:
$ echo disable > /proc/acpi/ibm/bluetooth
After that, you can use hcitool / hciconfig etc. as usual, and/or enable more related stuff with /etc/init.d/bluetooth restart.
Untested, I don't need it.
Untested so far.
Works out of the box.
$ sensors acpitz-virtual-0 Adapter: Virtual device temp1: +51.0°C (crit = +93.0°C) thinkpad-isa-0000 Adapter: ISA adapter fan1: 3698 RPM temp1: +51.0°C temp2: +42.0°C temp3: +32.0°C temp4: +49.0°C temp5: +33.0°C ERROR: Can't get value of subfeature temp6_input: Can't read temp6: +0.0°C temp7: +28.0°C ERROR: Can't get value of subfeature temp8_input: Can't read temp8: +0.0°C
$ dmesg | grep -i hpet pci 0000:00:1f.0: Force enabled HPET at 0xfed00000 hpet clockevent registered HPET: 3 timers in total, 0 timers will be used for per-cpu timer hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 hpet0: 3 comparators, 64-bit 14.318180 MHz counter
You can check with powertop that the number of wakeups-from-idle is drastically reduced (from 70 to less than 10) when adding hpet=force to the kernel command line.
Works out of the box using the e1000 driver.
$ modprobe e1000 Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI Copyright (c) 1999-2006 Intel Corporation. ACPI: PCI Interrupt 0000:02:01.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11 e1000: 0000:02:01.0: e1000_probe: (PCI:33MHz:32-bit) 00:11:22:33:44:55 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
Works out of the box, both in X as well as in the console using gpm.
Works out of the box, both in X as well as in the console using gpm.
Both work out of the box (on 2.6.26 or 2.6.29 kernels), or at least it used to; I think I'm seeing some hangs upon resume nowadays (Capslock LED is blinking, schreen is blank. I'll investigate.). I'm using the hibernate Debian package. You can explicitly force the usage of either method in /etc/hibernate/hibernate.conf by uncommenting the respective lines.
# TryMethod suspend2.conf TryMethod disk.conf # TryMethod ram.conf
Works out of the box using the ath5k driver. I tested WEP as well as WPA.
Works out of the box using the acpi_cpufreq driver.
$ cpufreq-info analyzing CPU 0: driver: acpi-cpufreq CPUs which need to switch frequency at the same time: 0 hardware limits: 600 MHz - 1.50 GHz available frequency steps: 1.50 GHz, 1.40 GHz, 1.20 GHz, 1000 MHz, 800 MHz, 600 MHz available cpufreq governors: userspace, powersave, ondemand, conservative, performance current policy: frequency should be within 800 MHz and 1.50 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency is 800 MHz (asserted by call to hardware). cpufreq stats: 1.50 GHz:69.76%, 1.40 GHz:0.11%, 1.20 GHz:0.13%, 1000 MHz:0.16%, 800 MHz:29.83%, 600 MHz:0.00% (4010)
Use cpufreq-set -g performance if you need full CPU power, cpufreq-set -g powersave otherwise.
Works fine out of the box, tested with beep.
Works out of the box. You can play DVDs or CD-ROMs, and burn CDs (but not DVDs):
$ wodim foo.iso [...] Device type : Removable CD-ROM Version : 0 Response Format: 2 Capabilities : Vendor_info : 'MATSHITA' Identification : 'UJDA745 DVD/CDRW' Revision : '1.02' Device seems to be: Generic mmc2 DVD-ROM. Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R96R
Ejecting a CD-ROM/DVD using the eject command line tool also works fine.
Works out of the box using the radeon driver.
$ xrandr Screen 0: minimum 320 x 200, current 1400 x 1050, maximum 1400 x 2048 VGA-0 disconnected (normal left inverted right x axis y axis) DVI-0 disconnected (normal left inverted right x axis y axis) LVDS connected 1400x1050+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1400x1050 50.0*+ 1280x800 60.0 1280x768 60.0 1024x768 60.0 800x600 60.3 640x480 59.9 S-video disconnected (normal left inverted right x axis y axis)
DRI works out of the box with the (mainline, open-source) driver:
$ glxinfo | grep direct direct rendering: Yes
If you attach an external monitor or projector, you can enable it using xrandr as usual:
$ xrandr --output VGA-0 --auto
You can also use a dual-head setup by adding this to your "Screen" section in /etc/X11/xorg.conf:
SubSection "Display" # Virtual 2048 2048 Virtual 1400 2048 EndSubSection
After restarting the X server, you can play with xrandr and move the external screen (VGA-0) "below" the laptop's LCD screen (LVDS) for a simple dual-head setup. The GUI tools arandr or grandr are probably a bit simpler to use than plain command line xrandr.
The maximum size for the "Virtual" line is 2048x2048 if you want to keep DRI enabled (you can use higher values if you don't care about DRI).
Untested so far.
Yes, this model still has an actual parallel port, which is nice as I can use it for random JTAG stuff (e.g. OpenOCD) with several cheapo parallel port JTAG adapters I own.
This laptop has a type II/III PCMCIA slot which works out of the box using the pcmcia and yenta_socket drivers. You can probe/handle PCMCIA cards using the pccardctl tool:
$ pccardctl status Socket 0: no card Socket 1: no card
Works fine, of course. Luckily it's USB 2.0 (not USB 1.1) so I can successfully do high-speed stuff, e.g. watching DVB-T using kaffeine. The only small problem is that there are only two USB ports, more would have been better.
Works fine, of course, it's just a normal PATA drive. You can check if DMA gets properly enabled with hdparm /dev/hda | grep dma.
Works out of the box (Fn + PgUp). This is a tiny, but useful light embedded in the screen, which is helpful if you're working in dark rooms or in trains during the night etc.
What works out of the box: brightness control buttons, audio volume control + mute buttons, thinklight button.
TODO: Access IBM, F3, F4, F5, F7, F12, left/right special keys, Fn+Space.
All of them seem to work fine, including the Bluetooth on/off and Wireless on/off LEDs, as well as the suspend LED.
-[0000:00]-+-00.0 Intel Corporation 82855PM Processor to I/O Controller [8086:3340] +-01.0-[0000:01]----00.0 ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] [1002:4c66] +-1d.0 Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [8086:24c2] +-1d.1 Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [8086:24c4] +-1d.2 Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [8086:24c7] +-1d.7 Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller [8086:24cd] +-1e.0-[0000:02-08]--+-00.0 Texas Instruments PCI1520 PC card Cardbus Controller [104c:ac55] | +-00.1 Texas Instruments PCI1520 PC card Cardbus Controller [104c:ac55] | +-01.0 Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile) [8086:101e] | \-02.0 Atheros Communications Inc. AR5212 802.11abg NIC [168c:1014] +-1f.0 Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge [8086:24cc] +-1f.1 Intel Corporation 82801DBM (ICH4-M) IDE Controller [8086:24ca] +-1f.3 Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller [8086:24c3] +-1f.5 Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller [8086:24c5] \-1f.6 Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller [8086:24c6]
processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 9 model name : Intel(R) Pentium(R) M processor 1500MHz stepping : 5 cpu MHz : 1500.000 cache size : 1024 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 tm pbe up bts est tm2 bogomips : 2997.72 clflush size : 64 power management:
All in all it's a really nice piece of hardware, and it works without much hassle with recent distros/kernels.
I have no idea how such a great open-source game as Teeworlds has been able to exist without me hearing about it until recently.
Teeworlds is a fast-paced realtime multiplayer shooter. You control a small "Tee" which can hold various weapons (hammer, gun, shotgun, laser-rifle, rocket launcher, ninja-sword) while running and jumping around frantically on the map, trying to frag as many other Tees as you can before you're killed by some other guy. Easy, eh?
There's are many game servers to choose from, as well as various game modes (death match, team death match, capfure the flag and some unofficial "mods"). You can join servers on the Internet, or create your own server, be it a public one or a LAN server.
Usually I would suggest apt-get install teeworlds, but for now the packages in unstable are an older 0.4.x version, whereas upstream released a much-improved 0.5.1 version. I have already filed a bug and I'm optimistic there'll be a new version in unstable soon.
In the mean-time however, you can manually build the game from source via:
$ apt-get install zlib-dev libsdl1.2-dev (maybe also libgl, libglu, and python, if not already installed) $ wget 'http://teeworlds.com/trac/bam/browser/releases/bam-0.2.0.zip?format=raw' -O bam-0.2.0.zip $ wget http://teeworlds.com/files/teeworlds-0.5.1-src.zip $ unzip bam-0.2.0.zip $ unzip teeworlds-0.5.1-src.zip $ cd bam-0.2.0 $ ./make_unix.sh $ cd ../teeworlds-0.5.1-src $ ../bam-0.2.0/src/bam release
You'll obviously need a working OpenGL/DRI setup (check if "glxinfo | grep direct" says "Yes"), otherwise the game will be way too slow. In case you experience graphics glitches and distortions, first exit the game, then:
$ vi ~/.teeworlds/settings.cfg
Change the "gfx_noclip 0" option there to "gfx_noclip 1" and restart the game.
If you use a local firewall as I do, you need to open at least ports 8300-8303 (UDP), even better 8300-8310 for more choice in game servers:
$ iptables -A OUTPUT -m state --state NEW -p udp --dport 8300:8310 -j ACCEPT
Let me join the crowd by saying a great "thank you!" to all the people who made this release possible, especially so the release team who organized everything, as well as the thousands of contributors (in one form or another) who helped shape the new release!
Personally, I'm eager to try out the new Linux 2.6.28 kernel package in unstable now (which have been uploaded today or so, but haven't yet reached my mirror), since they contain mainline wireless drivers for my One A110 netbook, among many other things.
Also, in the next few days I'll probably re-install my NSLU2 ARM box using the latest Lenny installer, following the HOWTOs by Martin Michlmayr (I'll probably write about the experience later). This re-install is long overdue, as I'm currently running the box from an 1GB thumb drive, which works ok, but I'm slowly running out of space. So I'll re-install on a 4 GB (or bigger) thumb drive.