Well, this is what I've got on my laptop:
01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 140M (rev a1)
It runs nouveau.
I'll be out in the field for work today, but will have some time sitting and waiting for meetings. I'll see if I can sort out how to decompress and remaster modules, as I've never done that before
# lzm2dir /mnt/sdb1/temp/002/002-xorg.lzm /mnt/sdb1/temp/002
then:
# dir2lzm /mnt/sdb1/temp/002/002-xorg /mnt/sdb1/temp/002/002-xorg.lzm
correct?
Why do you recommend moving 004-kde to /porteus/optional, and should I move it back for testing the remastered modules?
Yes, I'm in over my head. No, I don't care that I am
Any helpful commands for debugging? I was planning copying the output of lspci, lsmod, dmesg, cat /etc/X11/xorg.conf, and cat /var/log/Xorg.0.log to a text file, before and after making the above modifcations, and checking where they are different.
Thanks, as always, for your help and guidance. For what I lack in experience, I make up with blind optimism and self-depricating humor.
Posted after 3 hours 46 minutes 17 seconds:
Lol. I did something wrong. Got 'boot error' on restart, and now I'm out of time. I'll sort it out
Posted after 1 day 37 minutes 13 seconds:
I was finally able to reproduce the error.
I've traced down some differences in dmesg:
In the workaround setting (nouveau in 003 lzm), the end of dmesg reads:
Code: Select all
[ 17.873712] [drm] Initialized nouveau 0.0.16 20090420 for 0000:01:00.0 on minor 0
[ 18.354187] [drm] nouveau 0000:01:00.0: Allocating FIFO number 2
[ 18.361137] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 2
[ 18.535264] [drm] nouveau 0000:01:00.0: Allocating FIFO number 3
[ 18.542272] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 3
[ 21.678283] iwl3945 0000:0c:00.0: Radio disabled by HW RF Kill switch
[ 26.680270] iwl3945 0000:0c:00.0: Radio disabled by HW RF Kill switch
[ 31.681488] iwl3945 0000:0c:00.0: Radio disabled by HW RF Kill switch
[ 36.680025] iwl3945 0000:0c:00.0: Radio disabled by HW RF Kill switch
With nouveau in 002 (buggy setting), the end of dmesg reads:
Code: Select all
[ 18.015307] [drm] Initialized nouveau 0.0.16 20090420 for 0000:01:00.0 on minor 0
[ 18.035921] [drm] nouveau 0000:01:00.0: Allocating FIFO number 2
[ 18.042888] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 2
[ 18.679936] [drm] nouveau 0000:01:00.0: pid 2662 doesn't own channel 4
[ 21.620997] iwl3945 0000:0c:00.0: Radio disabled by HW RF Kill switch
[ 26.538141] iwl3945 0000:0c:00.0: Radio disabled by HW RF Kill switch
[ 31.535314] iwl3945 0000:0c:00.0: Radio disabled by HW RF Kill switch
[ 36.540323] iwl3945 0000:0c:00.0: Radio disabled by HW RF Kill switch
So, it would appear that nouveau is trying to allocate FIFO channel 4 and cannot, rather than allocating FIFO channel 3. I have no idea why this is, but I'll continue googling to see if I can sort it out. If anyone is more familiar with this and has some insight, please let me know.
xorg.conf goes on to load "modesetting" driver rather than nouveau.
Posted after 1 day 20 hours 57 minutes 35 seconds:
An update on my progress:
I realized that the entry in xorg.conf may be the reason for the dmesg errors, rather than the other way around. To provide better information that my last post, here are the relevant xorg.conf entries:
When nouveau is placed in 003 module:
Code: Select all
Section "Device"
Identifier "Card0"
Driver "nouveau"
BusID "PCI:1:0:0"
EndSection
And, when nouveau is placed in 002 module:
Code: Select all
Section "Device"
Identifier "Card0"
Driver "modesetting"
BusID "PCI:1:0:0"
EndSection
I don't believe that modesetting is an actual driver (as we discussed in our PM's, fanthom), so it is curious how it ended up here.
So, I made a copy of the working xorg.conf file and put it into the 002-xorg.lzm module along with the nouveau driver, and booted up, disabling changes and xconf. This resolved the issue on my machine. With nouveau set as the driver in xorg.conf, this is the relevant output from dmesg, once again becomes:
Code: Select all
[ 17.708729] [drm] nouveau 0000:01:00.0: Allocating FIFO number 2
[ 17.715721] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 2
[ 17.889691] [drm] nouveau 0000:01:00.0: Allocating FIFO number 3
[ 17.896694] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 3
I have yet to determine why xconf is setting up "modesetting" as the driver instead of "nouveau" when nouveau is placed in the 002-xorg.lzm module. I've read through the xconf script, and don't see where this could have taken place, except perhaps when it calls on /usr/bin/X (which looks like a link to /usr/bin/Xorg).
fanthom, did you run a custom compile of Xorg, and if so, did this issue present after the last time you compiled it?
Next steps in my testing (likely on Tuesday) will be to see what happens when I run xconf without the nouveau driver in any modules, and perhaps to see what happens when I move nouveau around and/or remove it from my 32 bit install, to get an idea of how it should behave.
Thanks for your patience!
Posted after 2 days 47 minutes 19 seconds:
After some more testing, I was able to sort out that xconf is unable to see the nouveau drivers unless those files are added or touched after the 002-xorg.lzm module is loaded.
I was able to develop one workaround:
First, I placed the files nouveau_drv.la and nouveau_drv.so in /tmp, in the 002-xorg.lzm module. Then, in the 001-core.lzm module, I added the following to /etc/rc.d/rc.local:
Code: Select all
cp /tmp/nouveau_drv.la /usr/lib64/xorg/modules/drivers/
cp /tmp/nouveau_drv.so /usr/lib64/xorg/modules/drivers/
Thus, the files were packed with the rest of the 002 module, and moved into place before xconf was run.
Also, fanthom suggested another workaround, which I also tested:
I left the nouveau drivers in /usr/lib64/xorg/modules/drivers/, and added the following to /etc/rc.d/rc.local:
Code: Select all
touch /usr/lib64/xorg/modules/drivers/nouveau_drv.la
touch /usr/lib64/xorg/modules/drivers/nouveau_drv.so
I’m still unclear as to why xconf cannot detect these files out of the box…but hopefully it will resolve itself in V1.0.
Thanks, fanthom!