IRC Logs for #crux-devel Sunday, 2014-08-24

*** mavrick61 has quit IRC02:48
*** mavrick61 has joined #crux-devel02:49
*** Necrosporus has quit IRC04:12
*** jue has quit IRC08:48
*** Necrosporus has joined #crux-devel08:58
*** sepen has joined #crux-devel09:39
teK_I am verrry busy and the upgrade reequires physical interaction with (USB) media09:39
*** sepen has quit IRC09:43
NecrosporusteK_, you could try upgrading via ssh09:47
teK_I wanted to allude to the fact that real-worl interaction is exhausting ;)09:56
teK_the two machines are *in* my appartment09:56
frinnstI have even upgraded my backup server! lazy bastard :)10:08
teK_boot: fb128011:42
teK_Undefined video mode number: 30711:42
teK_our 3.1 ISO11:42
teK_I think this machine uses 1280 as a default resolution, will check that later, once X is up again11:43
teK_oh boy. xfce-terminal (my terminal) seems to be incompatible with libpng-1.613:19
teK_ /o\13:19
teK_or revdep is not yet done ;)13:26
frinnstprobably vte that is still linked against 1.4 or something13:46
teK_still looking for it13:46
teK_I hate xterm ;)13:46
frinnsturxvt ftw13:46
teK_our vte port is outdated like shit13:49
frinnst0.3x probably depends on gnome3 and a lot of other crap13:51
frinnst- Drop GTK 2 support13:51
teK_oh boy13:57
teK_I can see my statically linked xfce-terminal already13:57
teK_200MB binary size13:58
teK_0.37.90 tries to link against png1513:58
teK_and just because I updated to 3.1 :PP13:58
teK_hm, updateing gtk3 first13:59
*** jue has joined #crux-devel16:22
teK_+ rm /home/tmp/vte3-work/pkg/usr/lib/vte/gnome-pty-helper17:07
teK_rm: cannot remove '/home/tmp/vte3-work/pkg/usr/lib/vte/gnome-pty-helper': No such file or directory17:07
teK_oh and there's version=0.37.9017:08
teK_of it17:09
*** deus_ex has joined #crux-devel19:06
*** Necrosporus has quit IRC20:34
teK_frinnst: 5 hours of compilation and xfce-fuckup-age later I am finally on 3.1 on 1 of 2 machines20:58
teK_hope you're happier now!20:58
teK_on the other hand, firmware loading for my wifi is seriously broken21:57
jaegercurse you, wifi!21:57
teK_it takes ages to load after claiming it cannot (directly) load my firmware file21:57
teK_which is present in /lib/firmware21:57
nrxtxtek intel chip?22:01
nrxtxbuild the firmware file into kernel22:01
teK_will try that. Still: this sucks22:02
nrxtxthe kernel tries to load it before rootfs is mounted, which fails and he does not try it again22:03
teK_this lazy fuck22:03
jaegerIt would only do that if it's builtin, right?22:03
jaegerAs module it should be fine and load after boot22:03
nrxtxjaeger: it should but it does not22:05
jaegerwhich driver is that? I don't have that behavior with iwlwifi22:05
teK_it's iwlwifi22:05
jaegerboth my laptop and a desktop with a centrino 6205, both built as modules22:05
teK_02:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)22:06
frinnstIt may simply be a race condition somehow22:07
teK_it worked until I switched to eudev22:08
teK_do NOT let poettering read that!1122:08
jaegerMy laptop has 3.12.25 on it, desktop has 3.14.something22:08
jaegerboth on 3.1 and using eudev22:08
teK_I had 3.16.1 on it for 3.0 too22:08
teK_so you have some /lib/firmware/iwlwifi-6000-4.ucode file, too?22:08
teK_it specifically prints the file name during boot and the file *is* there22:09
jaegeryes, 6000g2a-5 in this case22:09
teK_I have zero inclination to include that file in each kernel image I am going to build22:10
teK_oh this should work via oldconfig, I guess.22:11
teK_oh and jaeger IWLWIFI is set to yes, not module22:13
jaegerthat's probably why it doesn't work22:13
jaegerwhither the money, lebowski?!22:17
teK_how can this be any more fucked up?22:22
teK_it still whines about not being able to load that crap22:22
teK_hello mcfly? somebody home?22:22
jaegerdid you switch it to module instead? what are the firmware permissions? does the md5sum match the original?22:23
teK_exactly 120 seconds after boot (timeout for loading things is 60) wifi starts working22:23
teK_doing that switch right now22:23
teK_it worked for ages so I bet the md5sum is ok. Permissions were 600, are 644 now22:23
jaegerMaybe I'm wrong here but it seems to me that if you build it as builtin and don't include the firmware in the kernel, it SHOULD be expected to fail22:23
jaegerthe first time, at least22:24
teK_ok wtf :D22:24
teK_what's the logic behind that22:24
teK_rebooting, (brb in 120s ...)22:24
jaegerok, look at it this way: if it's builtin, the wifi driver gets loaded before the filesystem containing its firmware is mounted22:25
jaegertherefore, failure22:25
jaegerIf it's a module instead, the module gets loaded later by eudev instead and the firmware is available22:25
teK_oooh it's getting better every time I do a reboot22:30
teK_yes I get that22:30
teK_I get that it *could* fix things. Yet it doesn't22:30
teK_I made my kernel ooops22:30
jaegerhow odd22:30
jaegerI'd suggest trying an older kernel, too, I guess22:30
teK_and th 120 seconds = 60 seconds default + $TIMEOUT value in /sys/class/firmware22:31
teK_I tried 3.15.7, same shit22:31
teK_I have to try to connec tto my wifi abort that and retry to make it work, btw22:31
jaegerthat's bizarre22:32
teK_but that's been the case for quite some kernel versions (a year at least?)22:32
jaegerweird. sorry, I'll butt out, then, clearly not helping :P22:34
teK_I bet frinnst has some useful ideas left22:36
teK_but thanks ;)22:36
jaeger <-- the kernel config from my laptop if you're interested22:39
nrxtxteK_: did it work as module?22:39
teK_thx jaeger. nrxtx: no22:39
jaegerdoes it do the same thing if you rmmod the module and then load it manually?22:44
teK_I changed the timeout to 10 seconds22:47
teK_I enabled debugging and experimental ucdoez22:47
nrxtxlooks the same like i had before including it in the kernel22:47
nrxtxhave the same card as 632522:47
jaegerthe firmware loaded properly in that paste22:47
jaeger[ 1069.554910] iwlwifi 0000:02:00.0: loaded firmware version build 25532 op_mode iwldvm22:48
jaegeroh, never mind, I see the errors above that22:48
nrxtxthe failed with "-2" is ENOENT22:49
jaegerI don't have the fallback user helper enabled even22:49
teK_it doesnt work at all if I disable the help22:50
jaegerwhat does the "Device Drivers -> Generic Driver Options" section of your kernel config look like?22:51
nrxtxteK_: have the *.ucode in /lib/firmware/... ?22:51
teK_[tek@pita][~]% ll /lib/firmware/*ucode22:52
teK_-rw-r--r-- 1 tek users 454608 [2010/06/02] /lib/firmware/iwlwifi-6000-4.ucode22:52
nrxtxaccording to the config you built that into the kernel and it still has error -2?22:53
teK_3 times22:54
jaegerloading the wrong kernel?22:54
teK_than (timeout set to 1 sec):22:54
teK_[   64.846646] iwlwifi 0000:02:00.0: loaded firmware version build 25532 op_mode iwldvm22:54
teK_Linux pita 3.16.1 #7 SMP PREEMPT Mon Aug 25 00:38:40 CEST 2014 x86_64 Intel(R) Core(TM) i7 CPU L 640 @ 2.13GHz GenuineIntel GNU/Linux22:54
nrxtxcan you post the output of lspci?22:54
teK_md5sum is identical to the file from
nrxtxwhat is the vendor & device id of this card?22:58
teK_other than the one from lspci?22:59
nrxtxthe one shown by lscpi -n22:59
teK_02:00.0 0280: 8086:4238 (rev 35)23:00
teK_the two-times authentication problem could be seen with my son's android smart phone during vacation with the hotel's wifi, too23:08
teK_which makes it even more weird but no less annoying23:08
nrxtxdo you have tracers enabled?23:15
teK_but I switched to wext in wicd and no wpa-auth works on the first try23:16
teK_a Gentoo user posted:23:18
teK_[    2.613858] iwlwifi 0000:02:00.0: Direct firmware load failed with error -223:18
teK_[    2.613899] iwlwifi 0000:02:00.0: Falling back to user helper23:18
teK_[    4.354019] iwlwifi 0000:02:00.0: loaded firmware version op_mode iwlmvm23:18
teK_please note the timestamps..23:18
jaegeralso a completely different version, what's up with that?23:18
teK_it's different hardware23:19
teK_but the same mechansims wrt firmware loading should apply23:19
jaegerah, I missed that, sorry23:19
nrxtx-2 should be "no such file or directory"23:19
jaegergentoo user23:19
nrxtxyou might need to add some printk to the firmware loader of the kernel to debug that23:20
jaegermaybe try the latest firmware from ?23:20
teK_which is funky because the code is embedded in the kernel23:20
teK_jaeger: I already have that (it's four years old)23:21
jaegerah. ok23:21
nrxtxaccording to the device id and iwlwifi driver source the filename is also correct23:23
teK_ENOENT is default return value23:25
nrxtxDo you have "CONFIG_IWLWIFI_DEBUG" and/or "CONFIG_IWLWIFI_DEVICE_TRACING" enabled?23:26
teK_DEBUG yes, TRACING no23:26
teK_but my guess is that the actual loading is never done23:26
teK_ /tried23:26
teK_because in that case the loader-function would emit additional information23:27
nrxtxif you have debug enabled you should see what he tries to load and or if the file is suitable23:27
teK_nope :)23:28
nrxtxwhat is the value of /sys/module/iwlwifi/parameters/debug ?23:28
nrxtxcan you load the module and immediately change it to 1?23:30
teK_sure, wait 60 seconds :P23:30
nrxtxah you should be able to change it as modprobe parameter "debug_level"23:31
nrxtxmodprobe iwlwifi debug_level=123:32
teK_this is funny :D23:32
teK_[ 1130.275129] iwlwifi 0000:02:00.0: U iwl_request_firmware attempting to load firmware 'iwlwifi-6000-5.ucode'23:32
nrxtxyeah he tries a range of files23:33
nrxtxseems like they set a new upper limit23:33
teK_ALL pages I checked list -423:33
jaegernever trust pages, trust dmesg23:33
jaegerit comes straight from the kernel driver, after all23:33
nrxtxand debug information :D23:33
teK_I was about to patch that into the firmware loader :P23:33
teK_so the question is.. will renaming /baking in the file suffice23:34
teK_brb ;)23:34
jaegerI never build it in, for what that's worth23:34
jaegerthough it should work either way if you use the right file :)23:34
nrxtxyes :D23:35
nrxtxteK_: the first try will be for .*-6.ucode23:37
nrxtxat least what the header file of the driver says23:37
teK_-5 does not get loaded either23:42
teK_not builtin and not with iwlwifi as module and the firmware just being in /lib/firmware23:42
jaegerif you remove them and 'dmesg | grep fw' it will tell you exactly which file it wants. Though that seems to be -523:43
nrxtxhave to go, you can get more information here:
jaegerwell, I didn't look at the header but anyway23:43
nrxtxif you need some more you can add some printks:
jaegeryou should probably do either 1) builtin AND firmware in kernel or 2) module and firmware NOT in kernel23:44
jaegernot a mix of both23:44
teK_ta nrxtx :)23:44
teK_yes jaeger, that were the two scenarios I tested23:44
teK_at least NOW I found a debian bug report that seems to be related23:45
jaegerok. from your comments I could not figure out which you were doing23:45
teK_both, sequentialy23:45
jaeger"not builtin and not with iwlwifi as module" seemed contradictory23:45
teK_my bad23:46
nrxtxhehe gn8 and have fun :D23:46
teK_in 15 minutes, my AP will disable WiFi anyway23:47
teK_problem solved23:47
teK_it's a safety measure23:48
teK_it's almost 2 a.m.  here23:48
jaegerAt this point I'm completely confused. :P23:48
teK_dont worry :>23:53

Generated by 2.11.0 by Marius Gedminas - find it at!