darkness

Tried to rebuild the 0.9.2 release with the 0.9.1 RPM spec file. First problem: texi2pdf not found. There’s no such binary in FC4 at this time. Eventually I think it’s going to be in the texinfo package, but check Bugzilla since there are a couple bugs open on it as I recall. Anyway, it turns out texi2pdf is just texi2dvi --pdf, so just make a script to exec texi2dvi --pdf "$@", name it texi2pdf, put it in your path, and no more problems there.

Second problem: it keeps locking up on tests. I gave up at this point. Goes to 100%. I couldn’t even tell what test it was in. So I gave up, used the SBCL 0.9.1 RPM.

Then SBCL randomly started crashing with errors like:

internal error #29
    SC: 14, Offset: 4   lispobj 0x51082ff
fatal error encountered in SBCL pid 12264:
internal error too early in init, can't recover
The system is too badly corrupted or confused to continue at the Lisp
level. If the system had been compiled with the SB-LDB feature, we'd drop
into the LDB low-level debugger now. But there's no LDB in this build, so
we can't really do anything but just exit, sorry.

Turns out this is a result of kernel.randomize_va_space = 1 (that’s /proc/sys/net/kernel/randomize_va_space) which is the default in (at least) FC4’s kernel(s). You only get this error about 2/3 of the time; the rest of the time SBCL seems to work. The solution is to run SBCL like setarch i686 -R sbcl. I made a script in my path to do this when SBCL is built. Side note: I ran setarch i686 -R rpmbuild -ba sbcl.spec, but that didn’t make the build succeed. I didn’t try switching off the flag system-wide.

I tried to connect to the Internet with my phone during class, since there’s no wireless in the new building. Unfortunately I couldn’t get it to connect in class. I already had Bluetooth configured to connect to my v710 for DUN, but I’ve since had my phone flashed so it was no longer paired to my PC. When I did something like cat I’d first have my phone inform me of the pairing attempt and ask me for a PIN, then see things like hcid[4851]: pin_code_request in /var/log/messages. I couldn’t figure out how to tell the Bluetooth stack what PIN to use. gnome-bluetooth-manager was utterly useless: scan detected my phone, but it made like it was already detected. (Presumably some database somewhere indeed indicated the phone was already paired, but I needed a ‘re-pair’ option or something.)

Poking around revealed /etc/bluetooth/hcid.conf. There are two relevant parameters, pin_helper and dbus_pin_helper. In the default FC4 hcid.conf, pin_helper is commented out and dbus_pin_helper is set. At some point, I also noticed hcid would disappear after it spit out its pin_code_request. So I slapped strace on it, and behold (edited for brevity, wrapped for readability):

send(3, "<30>Jul  7 11:32:32 hcid[4851]: pin_code_request
(sba=XX:XX:XX:XX:XX:XX, dba=XX:XX:XX:XX:XX:XX)", 95, MSG_NOSIGNAL) =
95
write(2, "4851: arguments to dbus_type_is_basic() were incorrect,
assertion \"_dbus_type_is_valid (typecode) || typecode ==
DBUS_TYPE_INVALID\" failed in file dbus-signature.c line 259.\nThis is
normally a bug in some application using the D-BUS library.\n", 242) =
242
write(2, "type unknown isn\'t supported yet in
dbus_message_append_args_valist\n", 68) = 68
read(5,
"l\3\1\1G\0\0\0\3\0\0\0u\0\0\0\6\1s\0\4\0\0\0:1.1\0\0\0\0\4\1s\0)\0\0
\0org.freedesktop.DBus.Error.ServiceUnknown\0\0\0\0\0\0\0\5\1u\0\2\0\0
\0\10\1g\0\1s\0\0\7\1s\0\24\0\0\0org.freedesktop.DBus\0\0\0\0B\0\0\0The
name org.bluez.PinAgent was not provided by any .service files\0",
2048) = 207
writev(2, [{"*** buffer overflow detected ***: ", 34}, {"hcid:
processing events", 23}, {" terminated\n", 12}], 3) = 69

So that can’t be good. I commented out dbus_pin_helper, uncommented pin_helper "/usr/bin/bluepin";, restart of hcid (er, no restart, just start, since it had just crashed), and lo I was now presented with a window asking me for a pin. hcid even kept running. Got paired, but it seemed like communications with the phone would lock up after ATZ: about any other command just yielded silence and an inability to type more. At some point the right combination of suspending, resuming, and randomness allowed it to start working: I could bring up the PPP interface.

Then I got the fun unregister_netdevice: waiting for ppp0 to become free. Usage count = 1 message when I tried to ifdown the PPP device.

So a reboot and I come back to a new Fedora kernel (2.6.12-1.1387_FC4). Now everything works just fine, ifup and ifdown.

Update: turns out this has already been reported as bug 160676.

Of course, this new kernel brought still more fun. My ATrpms ipw2100 1.1.0 driver was not built for this new kernel. ATrpms hadn’t rebuilt it yet either. So I went to try and compile it myself. This managed to make GCC SIGSEGV.

Luckily this one had already been filed in Bugzilla. I also found an entry for the bug in the ipw2100 bug tracker with a patch. I applied that patch and I could compile the module. As an update to my comment in the RH bug, I’m using the resulting driver right now to make this web log entry, and I’ve been using it all day, so it can’t be that bad. Maybe this combination of kernel and wireless driver will also stop the strange “resource unavailable” messages I’ve been getting occasionally when I resume my laptop. (I have to rmmod ipw2100; rmmod ieee80211 and then everything is fine, but it’s still quite annoying.)