pavelmachek

Kohjinsha wifi driver

Wed, 07 May 2008 20:52:54 GMT

Kohjinsha wifi driver is now updated to 2.6.26-rc1, and should be available in my work git-tree. I won't have Kohjinsha with me for next week, so don't expect any development. But if you want to clean up some really challenging code, feel free to help. Longer term, some testers would be very welcome.

Slowest machine

Thu, 01 May 2008 18:09:09 GMT

...to run "quick benchmark" was Wouter Verhelst's Mac IIci (running linux on 68030) -- thanks!

time factor $[65863223*65863159]
4337959928701457: 65863159 65863223

real 6m16.660s
user 6m9.920s
sys 0m4.530s

...that's 376 seconds, and almost exactly 1000 times slower than my home desktop.

Fastest machine seems to be djwong's Xeon E5450 (3GHz): 0.116s, 3000 faster than Mac II.

Do you have faster or slower machine?

Single AA phone charger

Sun, 27 Apr 2008 19:32:30 GMT

I have 10+ NiMH accumulators nearby, still my cellphones sometimes run out of power.

My first solution was to create pack for 4 of these, with USB connector, and charge from that. That did not work too well.

Now I got this toy... and it seems to work quite well. It also may be solution to my "1W headlamp from single battery" -- it provides ~500mA@3.6V with full accumulator. Is there some simple current limiting circuit I could use? (Regulator seems to have 5.5V max, I need 300mA for a 1W led, and it would be very nice if it was possible to limit current down to 10mA or so.)

Manufacturer says cellphone gets charged for ~1day standby from single AA, and that seems to be about right. (Actually n6230 seemed to last 1.5 days, but the test left something to be desired). I wonder how big conversion losses are: 1.5 days is definitely not full capacity of lion in n6230; and it has 700mAh li-ion ~= 2520mWh. Single NiMH should be ~2100mAh ~= 2520mWh, too...

pavel's quick benchmark

Sun, 27 Apr 2008 18:47:24 GMT

This one actually has a huge advantage: factor seems to be part of default installation, so it is easy to run on all machines down to sharp zaurus.

It also shows just how slow those embedded cpus are. I always assumed that arm@400MHz was approximately as fast as pentiumMMX@200MHz. ... that's quite far away from truth.

root@amd:~# time factor $[65863223*65863159]
4337959928701457: 65863159 65863223

amd: 0.591 s
eee @ 630: 1.673 s
eee @ 900: 1.858 s ?!
arima: 0.536 s
hobit: 0.376 s
zaurus: 21.99 s
kohjinsha: 4.062 s

Surprising notes here: Asus eee is much faster than kohjinsha. (In fact, eee has pretty cool CPU, it can compile kernel in like 15 minutes, unlike kohjinshas 90 minutes). And even kohjinsha's geode@500MHz is 5 times faster than zaurus... So zaurus is more like pentium@100MHz.

And now... What's the best and the worst result you can get in pavel's benchmark? Does someone has 386sx still running? Or will some ARMs be even slower? And is there anyone with those pentium extreme's at 3GHz?

Asus EEE to play with

Sun, 27 Apr 2008 18:25:40 GMT

Asus EEE is a pretty cool machine. It actually has an usable keyboard, and its linux distribution is very nicely done, and well integrated with the hardware.

Unfortunately, its ACPI BIOS is crap: no thermal zones, and battery values completely off. (It seems to only report values in percent, but it does so by claiming battery is 100mAh and counting from that. Oops).

It took me a while to figure out touchpad really has two buttons... it is one big button, and depending on you pressing left or right side it means left or right click. Unfortunately that means you can't even use X's 3 button emulation, and I have not figured out how to copy & paste between xterm (well hidden behind ctrl-alt-t) and browser.

...speaking of which, this is actually my first machine where flash works including audio, and I did not even have to agree to stupid EULA. Skype also works, which is a plus (had to deal with ugly EULA there :-().

Horse will not step on human

Fri, 18 Apr 2008 22:25:37 GMT

...at least according to old czech saying.

And it is mostly true, too. First horse will not step on you, because he can see you clearly and insticts tell him not to do that. Unfortunately, second horse has his view blocked by the first horse...

...and so he stepped on my hand. I guess I just won $1000000 in lottery, because my bones survived that unbroken.

800kg of fun

Sat, 12 Apr 2008 22:22:52 GMT

...one more question related to big mare... She's quickly becoming leading horse in group of 20 horses. Basically all the geldings fell in love with her. And we'd rather have some other leading horse. Is there any way to interfere with their hierarchy?

Fun with kohjinsha, and how to control 800kg mare

Sat, 12 Apr 2008 21:46:08 GMT

I had some fun with kohjinsha wifi driver... the winbondport driver (also known as w35und) contains its own 802.11 stack... which is no-go if it should be ever merged to mainline. So I played a bit, and managed to add softmac interface to it. It is quite a hack, as I kept the 802.11 parts intact, so single card now announces itself as two interfaces. To my amazement, receive now works -- if I iwlist wlan0 scan on hardmac interface, I see the results on softmac interface, too. Unfortunately, transmit looks more tricky.

Theres beatiful, but very big mare in Kostelec stables... she is 15 (or so), but I'm not sure how much training she had. Anyway she is pretty easy to ride (and very afraid to ride alone), but leading her just does not work. If she wants to go to the destination, its okay, and if you lead her in a group, that's okay, too, but leading her away from other horses is pretty much no-no.

I guess Parelli/Roberts tricks could help here, but round fence is not available nearby. Leading on headstall will probably do... or is there any other trick available? Rope halter?

Sesja Linuksowa

Fri, 04 Apr 2008 11:29:13 GMT

I am going to Sesja Linuksowa in Poland... but slowly. For some reason, bus driver decided to avoid highways.... so if you are there, be sure to say "hello".

Daylight saving time is stupid idea

Tue, 01 Apr 2008 23:34:53 GMT

...and handling of time zones in vCalendar does not help. When you add an appointment to calendar in nokia 6230 (and similar, probably everything vCalendar based), the phone converts meetings to GMT, and stores them.

Unfortunately, with begining of daylight saving time, you move from GMT+1 to GMT+2... but your appointments stay there, and are now one hour off.

"Correct" solution would be to always enter timezone when entering appointment.

Workaround would be not to change timezone when dst begins, but lie to telephone, and set the time instead. Unfortunately, that would wreak havoc with synchronization, such as mobical.

"Reasonable" solution would be to assume appointments to be in "local" time zone, whatever that is. Just do not store that in GMT... but that's not how vCalendar works.

Is there chance of getting this mess cleared?

And before I loose them, here are some measurements from headlight I modded. Originally, it had 3 white leds, with optics making pretty narrow beam. I added 100mA, 90degrees red and green led.

On "almost empty" NiMHs (3x AAA), directly connected for white & green, current was: 18mA for white, 15mA for green and 26mA for red.

On freshly charged 900mAh NiMHs, current was 65mA for white, 54mA for green, 95mA for red. 82mA when running white+green.

I added switch selecting direct connection, 20 ohm resistor, and unknown blue resistor. With 20 ohms and fresh batteries, values are 28mA for white, 24mA for green and 50mA for red. Difference in light output is pretty minimal, and this setting is what I use when "very low" setting is not enough -- like going trot/gallop. White+green in this mode is very nice.

Unknown blue resistor and empty batteries gives about 3mA white (assuming 3mA on green?) and 6mA on red. Red is pretty unusable in this setting, you'll see objects above ground and branches trying to hit you, but not the ground itself. Green in this mode is OTOH very usable, providing nice light all around you, with visibility of few meters, and you can walk horse on this setting... not bad for 3mA (~10mW). This is actually too much light for eyes to go into highest-gain mode.

MAINTAINERS file sucks

Sat, 29 Mar 2008 20:37:57 GMT

So I want to submit a patch to ALSA... and I'd like to know who the maintainer is, and what list should be CCed... So I open MAINTAINERS file in less, and search for ALSA...

...and nothing relevant comes up. Hmm, perhaps someone was clever and title says "ADVANCED LINUX SOUND ARCHITECTURE"?

...nope. Did I get the acronym wrong? No.

...relevant maintainter is listed under "SOUND". (And the list is subscribers-only). There were about 10 proposals to split MAINTAINERS file and put it close to relevant sources, or at least add "Files: " field to MAINTAINERS file. Perhaps it is time to do something like that?

Oh and BTW ALSA sucks. It invents compeletely new abstractions where none are neccessary:

snd_assert(subs->dataurb[i].urb, return -EINVAL);
if (subs->ops.prepare(subs, runtime, subs->dataurb[i].urb) < 0) {
	snd_printk(KERN_ERR "cannot prepare datapipe for urb %d\n", i);
	goto __error;
}
...
snd_printdd(KERN_INFO "setting usb interface %d:%d\n", fmt->iface, fmt->altsetting);

snd_assert? WTF is that? (and notice the ugly "return -EINVAL" parameter). Rest of kernel uses WARN_ON()...

snd_printk()... what is it? Will it print? [answer is yes, and depending on config option, it will print filename and linenumber, too]

snd_printdd()... what is it? Why is it ALSA-specific? Will I see the printout? [answer is no, unless I tweak the config]

If you are a kernel janitor, and want to clean something up, please take a look at ALSA.

iommu and lots of fun

Thu, 27 Mar 2008 09:28:27 GMT

This is what I got after my iommu experiments:

Welcome to openSUSE 10.3 (i586) - Kernel 2.6.22.5-31-bigsmp (tty2).


leet login: root
Password:
Last login: Sun Feb  1 09:41:07 CET 1987 from he cron daemon
#
#
auth     sufficient     pam_rootok.so
auth     include        common-auth
account  include        common-account
password include        common-password
session  required       pam_loginuid.so
session  include        common-session
 on The PAM configuration file for t
Have a lot of fun...
leet:~ #

...seems like there will be a lot of fun. Anyway, if you want to avoid this "fun", use iommu=soft on >3GB machines where you are running hibernation. Be sure to use iommu=soft on both boot and resume kernels.

thanks Theodore ext3 is so robust

Thu, 27 Mar 2008 09:07:25 GMT

In theory, running journalled filesystem without barriers in write-back mode is very bad idea... Unfortunately, it is what I have been doing for years now: x60's disk does not seem to support barriers. ext3 survived.

Today I was trying to debug iommu problems after resume, apparently overwriting beggining of partition with some random data. ext3 fsck just used backup superblock...

Thanks!

click on link provided by FBI, go to jail?

Fri, 21 Mar 2008 10:39:19 GMT

...for 3 or so years...? US finally went crazy.

vger.kernel.org is down

Wed, 19 Mar 2008 09:11:20 GMT

...and yes, David Miller already knows about it. So no, problem is not in your incoming mail setup, and no, being unable to post to linux-kernel@vger.kernel.org is not fault on your system.

Wikipedia, evil autorepeat, strange usb and good wireless news

Thu, 13 Mar 2008 08:29:23 GMT

There has been recent talk about "wikipedia should accept advertising to keep itself from bankrupting". Well... there's easy way to "fix" this: set up wikipedia mirror, add advertising, and send the generated money to wikipedia foundation. I may even use that mirror...

X windows seem to be doing software autorepeat, even on plain PS/2 keyboards that are perfectly capable of autorepeating themselves. That's wrong and stupid: as soon as you get non-trivial interrupt/scheduling latencies, your keyboard becomes unusable. Console gets this right: if your interrupt latency is too high it will loose keystrokes due to limited buffer, but at least it will not insert new ones so you can actually make progress on typing.

Played with USB soundcard a lot... and found a magic way to make it play at least mono... Seems like playing 8-bit sound is required in order to kick it to work?!

mplayer -ao alsa:device=hw=1 -af format=u8  KDE_Startup.wav
mplayer -ao alsa:device=hw=1 -af format=s16le -af resample=48000
        -af channels=1 KDE_Logout_1.ogg

And after about 2 years, good news in iwl3945 land: it still crashes (under evil kind of load) but at least you can now compile it into kernel (not a module). That means that Thinkpad x60 finally got to state of Thinkpad x32, functionality-wise.

Kohjinsha updates

Mon, 10 Mar 2008 13:33:41 GMT

Kohjinsha sound seems to work for me now. If it is broken for you, try updating to 2.6.25-rc4 or something.

Petr Susil created a page about Kohji, including recent hacks on the USB wifi. It seems that driver is actually stable once you enable 8KB stack.

How to boot into distribution living in chroot...

Mon, 03 Mar 2008 20:29:17 GMT

Guillaume Chazarain describes this "interesting" trick: init=/working_distro/lib/ld-linux.so.2 --library-path
/working_distro/lib /working_distro/usr/sbin/chroot /working_distro/
/sbin/init

...okay, it probably also qualifies as "most interesting kernel cmdline hack", ever.

bioheadlight & warm-loving computer

Mon, 03 Mar 2008 18:56:16 GMT

Ok, so how does ideal headlight look like?

Produces as much light as possible? ...no, that's an atomic bomb, not headlight.

Produces as much light as possible, and lasts as long as possible? ...that's better, but it still is not what is needed. Powerful headlights blind people, and that's not good use of energy... it is also annoying.

I guess feedback based on light sensor would work. Have few separate beams, and have light sensors. If too much light would reach user's eyes, turn down that particular beam. No more blinding, and it should be pretty energy-efficient, too.

(Actually, this is inspired by riding on white horses in the dark. As soon as you lie down because of low branches, you blind yourself.... bad.)

Now... does anyone actually make a headlight like that? Is there schematics available somewhere?

As far as computers go... it seems I have one CPU that hates cooling. It gets more stable when it warms up, and after I displaced the CPU fan so that only 30% of air hits the cooler, machine seems to last longer between crashes now...

suspend to RAM in Fedora

Mon, 03 Mar 2008 18:34:36 GMT

...does not work too well. One of reasons is that, well, Fedora does not ship s2ram.

Fedora relies on pm-utils restoring video state by hand. That unfortunately means you need to be running HAL to test suspend (no easy testing from init=/bin/bash). It also relies on external utilities, so if your disk fails to wake up, you'll not read anything on screen.

s2ram has integral whitelist... which means easier testing. (It also appears to be what Fedora people dislike -- they fell in love with HAL, apparently). Anyway, you don't have to use internal whitelist. Just pass the whitelist parameters on command line to s2ram.

Pretty please, package s2ram for Fedora. It is not easy to compile s2ram, because its dependencies are lacking, and s2ram is realy vital for suspend debugging. (You can get s2ram sources at suspend.sf.net, it is GPLed).

Evil hack to get gps to work on openmoko with 2.6.24 kernel

Wed, 20 Feb 2008 23:38:14 GMT

gllin expects paths in /sys... unfortunately they changed with 2.6.24 update. Fortunately, sed works on binary files :-)

<pre>
cat gllin.real | sed 's-/sys/-/s/s/-g' > gllin.real2
mkdir -p /s/s/bus/platform/devices/
ln -s /sys/bus/platform/devices/neo1973-pm-gps.0/ /s/s/bus/platform/devices/gta01-pm-gps.0
</pre>

Evil lights

Tue, 12 Feb 2008 23:56:30 GMT

I played with headlights in last month or two, because horses need
to be ridden in the winter, too... and that often means going after sunset. Few observations:

powering red LEDs from 3x NiMH AAA is a bad idea. Resistor eats half of the energy. What is worse, LED will drive batteries into pretty low voltage without reducing brightness. That's bad for them, and means you'll get very little light when you attempt to switch back to green/white LED.
due to human vision system, red light is pretty much wasted. Yes, it allows you to keep night vision; OTOH 50mA green LED allows you to see much better than 100mA red LED.
using hot glue to glue 100mA+ LEDs is not a cool idea.
incandescent lights are evil. They can go from pretty much full
power to no light at all in about a minute. Guess what happened to me
in the middle of dark wood... (fortunately horses do not rely on
vision as much as humans do).
you can't power 1W white LED from 3x NiMH battery. Not even AAs will work.
width of beam matters. Narrow beam is useful for "this is how far
away I can shine" and for blinding people. That's about it.
DC-to-DC converters are nice -- they keep the light steady, and
are probably the only way how to do 1W led reasonably, but can be
evil... if they fail down to no light when battery goes low. I
actually seen that in one commercial headlight (Petzl something?), and
I'd consider that fatal flaw.

joule thief is a cool toy, it works and produces light even from single dead AA battery. But it remains a toy, maybe useful in emergency. 20mA is not enough for serious light.

testing@home

Tue, 12 Feb 2008 14:36:38 GMT

I guess I have a project idea.

You know, there are about 1000 distributed projects: seti@home, tiles@home, folding@home, and who knows what else. They produce lot of heat, but they have a side effect -- they test stability of your machine.

At the same time, those distributed projects have problems with unreliable machines, cheating, etc. But there seems to be easy solution: Just run everything twice, on machines far away from one another... which means distributed projects get even better for testing: now you can recognize not only crashes/hard locks, but also incorrect results.

Now... it would be nice to create distributed network with main goal of testing machine stability. Yes, it can produce tiles for openstreetmap as a sideeffect, or search for UFO or whatever... Do everything few times, tell owners which hosts last responded when using nice UI, and you can get lots of spare cycles, while clients get a lot of nice testing...

for the record

Wed, 06 Feb 2008 00:54:51 GMT

...I'll be happy when freezer is gone, and am now looking forward to Matthew Garrett's patches to fix all the drivers in tree, which is the thing that keeps freezer there for s2ram path.

Plus, I'd really like kexec/kjump patches to go in. I believe one extra kernel boot during suspend is going to slow stuff down, but lets see... and kjump really looks interesting for different kinds of hacks, like live crashdumps....

thanks for port 0x80 debugging cards

Sat, 02 Feb 2008 00:07:07 GMT

s2ram wakeup with new real mode running .c code now works, both 32-bit and 64-bit... and big thanks go for port 0x80 debugging cards... without them debugging would be impossible.

I just wonder if hardware debugers will ever enter mainstream. It is simple piece of hardware (low-speed i2c connection to cpu debug port), but it is sometimes very very useful.