that separate firmware package sounds nice.
jmkasunich: is your computer finally working?
it's getting worse my the minute
remember at the workshop when my mouse was flakey and I got a new one
the new one is showing the same symptoms, which is too weird to be a coincidence
the scroll wheel seems to be issuing the wrong events
but it worked all this time?
I'm looking at events with xev, and also catting /dev/input/mouse0 thru hd
it worked until I rebooted
when I scroll down, apps seem to behave more-or-less normally
and xev says I'm getting button 5 press and release events (which seems weird, but who knows)
when I scroll up, the cursor jumps to the right about 10-20 pixels at a time
call me crazy, but I'd just try another mouse
and I get button2 events
I've been considering that
but the only other mice I have are ancient
no scroll wheels at all - so not a suitable test really
oh, I have a wireless USB mouse for the laptop
can two mice co-exist, or should I unplug the PS2 mouse?
apparently they can
and the USB one scrolls just fine
I find it extremely astonishing that two mice would have such similar failures
this one isn't some $3.95 cheapo - it is a logitech
I wonder if mice suffer from memory leaks like windows does, and need to be rebooted every so often
the mouse is plugged into the KVM, which is UPS powered - so the mouse has been up for at least 132 days
I unplugged it from the kvm, plugged it into the PC, worked
back into the kvm, still worked
moral of the story, reboot your mouse once in a while
I have to reboot my toaster sometimes
it won't let go of the toast, it locks up and keeps toasting forever
I put a "Designed for Windows 2000" sticker on it (pried off my laptop)
well, now I can pop one issue off my stack
only about 998 left
got my compressor wired to power!
looks like the barn will be done tomorrow!
what are you doing to/with/in the barn?
seems like we're always racing the cold weather this time of year
it's for the critters - they didn't have much shelter for winter.
oh, you're building another barn?
you had one, but it is all full of crap, right?
oh we still have it :-)
it's fully enclosed - we've never had animals in it
you have two now, you had one before
is studying Xorg.log the only way to figure out what is actually going on driver-wise?
I think I'm using nv
depends. if you're concerned about GL stuff, check the output of glxinfo
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI Radeon 20050528 AGP 1x TCL
right now I don't have any GL
name of display: :0.0
Xlib: extension "GLX" missing on display ":0.0".
Xlib: extension "GLX" missing on display ":0.0".
Xlib: extension "GLX" missing on display ":0.0".
Error: couldn't find RGB GLX visual
but that is a few levels up the stack
I have weirdness in plain old X
how did you break it so badly just adding ram?
oh, new kernel
no new kernel?
I was running -51 desktop, an update to -52 desktop was pending (had been installed but not rebooted)
I've also installed -52 server, trying to access all 4g
all three kernels have X issues tho
do you have linux-restricted-modules-`uname -r` installed?
the issues are hard to explain, and not terribly consistent
yes, for 51 and 52
the blinking text cursor in some (but not all) text boxes/windows is deformed
huh. this stuff just always works for me now...
arrow keys work strangely in some but not all text windows
backspacing leaves vertical lines between chars in some windows
I probably have some unholy mixture of nv and nvidia drivers running (drivers or pieces of drivers)
or it is a driver version thing
nvidia libraries + non-nvidia driver
EMC: 03tissf 07TRUNK * 10emc2/src/po/fr_rs274_err.po: *** empty log message ***
hence my question about how to identify what is going on
EMC: 03tissf 07TRUNK * 10emc2/docs/src/motion/pid_theory_fr.lyx: *** empty log message ***
or, how to get a clean slate
if you don't have this, try adding it
Identifier"NVIDIA Corporation NVIDIA Default Card"
that is what I've had since the update
I _want_ to be running nv, at least for now
what happens when you put it back?
uh what is your goal again?
I changed from nvidia to nv when X refused to start after the reboot
probably because the binary nvidia doesn't match the new kernel
oh so nvidia won't load
you should have the matching one if you have the matching linux-restricted-modules
did you do some terrible thing like run the crappy nvidia installer sometime in the past?
I dunno, that was in the past
last time I did anything with X on here was probably two years ago
I _did_ have nvidia working
jmkasunich@mahan:~$ dpkg -l | grep restricted
rc linux-restricted-modules-2.6.15-26-386 22.214.171.124-4 Non-free Linux 2.6.15 modules on 386
rc linux-restricted-modules-2.6.15-28-386 126.96.36.199-28.1 Non-free Linux 2.6.15 modules on 386
rc linux-restricted-modules-2.6.15-28-686 188.8.131.52-28.2 Non-free Linux 2.6.15 modules on PPro/Celero
rc linux-restricted-modules-2.6.15-29-686 184.108.40.206-29.1 Non-free Linux 2.6.15 modules on PPro/Celero
ii linux-restricted-modules-2.6.15-51-686 220.127.116.11-51.2 Non-free Linux 2.6.15 modules on PPro/Celero
ii linux-restricted-modules-2.6.15-52-686 18.104.22.168-52.3 Non-free Linux 2.6.15 modules on PPro/Celero
ii linux-restricted-modules-686 22.214.171.124 Restricted Linux modules on PPro/Celeron/PII
ii linux-restricted-modules-common aj1 Non-free Linux 2.6.15 modules helper script
what's uname -r say?
so you do have the matching one
getting nvidia working is step 2 I think - shouldn't it be easier to get nv working?
btw, it _is_ distinctly possible that I ran some nvidia installer, I just don't remember
sounds like nv just has crap support for your particular card and it gives bogus little display problems
I'd say don't waste time on that
$ cat /etc/default/linux-restricted-modules-common
I guess I was thinking of nv as "slow, but solid" and nvidia as "hw acceleration, but binary and hoops to jump thru"
does it have DISABLED_MODULES including nv?
# DISABLED_MODULES="ath_hal fc fglrx ltm nv"
ok, that's not it
* jmkasunich digs thru old boxes to find out what graphics card I have
seems I have a GeForce 7100S
$ cd /lib/modules/`uname -r`/volatile; ls -l nv*
synaptic says re: nvidia-glx "If you have a TNT, TNT2, or older GeForce, you may need the nvidia-glx-legacy
package instead of this one."
jmkasunich@mahan:~$ cd /lib/modules/`uname -r`/volatile; ls -l nv*
-rw-r--r-- 1 root root 5176514 2008-11-01 21:15 nvidia.ko
-rw-r--r-- 1 root root 4410619 2008-11-01 21:15 nvidia_legacy.ko
the nvidia-glx-legacy package is NOT installed
jmkasunich@mahan:/lib/modules/2.6.15-52-686/volatile$ dpkg -l | grep " nv"
ii nvidia-glx 1.0.8776+126.96.36.199-52.3 NVIDIA binary XFree86 4.x/X.Org driver
rc nvidia-glx-dev 1.0.8776+188.8.131.52-52.3 NVIDIA binary XFree86 4.x/X.Org driver devel
ii nvidia-kernel-common 20051028+1 NVIDIA binary kernel module common files
modinfo /lib/modules/`uname -r`/volatile/nvidia.ko|grep vermagic
if you didn't need -legacy before a minor update, I doubt you need it now
vermagic: 2.6.15-52-686 SMP preempt 686 gcc-4.0
it might have been installed earlier
does that vermagic match uname -a?
I think both were, and I uninstalled them while trying to get back to just the nv driver
Linux mahan 2.6.15-52-686 #1 SMP PREEMPT Wed Oct 22 19:11:33 UTC 2008 i686 GNU/Linux
maybe you are right then.
no mention of gcc version in uname -a, and the case of PREEMPT doesn't match
so the modules are getting built and they match
I think that's normal
lemme comment out nv and uncommend nvidia in xorg.conf, install the legacy package, and restart x
change your Driver back to "nvidia", and try to run X, and save the log
driver changed, I'll try it first without installing -legacy
woot, it works
I have glx too
* jmkasunich is sad
any idea what you did to fix it?
used the binary driver instead of nv
thats why I'm sad
so, a couple more things popped off the stack
at the moment I'm running ubuntu's latest desktop kernel and the nvidia binary driver, everything seems to work
however, I only have 3.1G of RAM
I know (tried it) that the -server kernel will recognize and use all the ram
but I don't think there is a restricted-modules package for it
surely there is
... or not
they probaby figure servers don't need accelerated graphics and the other stuff that restricted gives you
one solution would be to compile my own kernel using the settings from -52-desktop, but change only the -PAE and -64G settings
but I guess that still means I don't have a nvidia driver
unless the binary by some miracle would work with the kernel I make
have you tried leaving these l-r-m and booting -server?
I can't divine from the dependencies whether that's supposed to work
what do you mean by "leaving"?
don't worry about l-r-m, just install and boot -server and see what happens
I can try
I never did worry about l-r-m, there are a bunch installed and it apparently can figure out which to use
probably won't find the one it wants, but I'll try
yeah it does magic at boot time
[02:23:26] <jmkasunich> http://ubuntuforums.org/showpost.php?p=4296321&postcount=6
this guy is trying to do the same thing
rebooting to server kernel
* jmkasunich crosses fingers
I saved the dmesg and xorg logs, booted back into the desktop kernel
I wish I had a clue how to build l-r-m-...-server but I don't
(EE) NVIDIA(0): Failed to load the NVIDIA kernel module!
I wish there was a free (even if a bit slow) driver for my card
* jmkasunich makes a note - never buy nvidia again
does that have any support (even SW) for glx?
a billion emc users can't be wrong
so what is the downside of using vesa instead of nv?
oh, nv? I thought nv had rendering artifacts
nv has artifacts
(nv should have glx too unless someting is screwy)
then something is screwy
dunno if the artifacts and the lack of glx are related or not
we decided not to mess with nv, remember?
try uninstlaling nvidia-glx
then run vesa
in your place I'd get on ebay and order a video card, and use 3.1G until it shows up
try uninstalling nvidia-glx, then run vesa? or were those two different thoughts
those are the same thought
without nvidia-glx, vesa/nv will give you software gl
vesa _and_ nv?
now I'm lost
I thought my three driver choices were nvidia, nv, or vesa
yes either one should do software gl, if you remove the nvidia libraries
not "nv _and_ vesa"
both nv and vesa, of which you only use one or the other, will do software gl
I misread "vesa/nv will give you software gl"
"but only if the binary nvidia-glx is removed to it doesn't interfere"
that is probably the issue I've been having all along
[02:36:31] <cradek> http://shop.ebay.com/items/_W0QQ_nkwZmatroxQ20g450QQ_armrsZ1QQ_fromZR40QQ_mdoZ
I have these on everything - they work great even with relatime
I need pci-express, are all 450's AGP?
I don't know anything about PCIe, I've never had one
lemme check mobo manual, I'm pretty sure it has only pci-E and pci
there are some pci ones for $20...
yep, two PCI, one PCI-E x16, one x8, one x4
I have regular pci in some of my machines
yeah but you probably don't want that.
for a machine controller, sure
but not for my primary desktop system
[02:40:15] <cradek> http://cgi.ebay.com/Matrox-Millennium-G550-PCIe-32Mb-Dual-Head-G55-MDDE32_W0QQitemZ120315419879QQcmdZViewItem?_trksid=p3286.m20.l1116
no idea if this would work as well
(what a funky slot)
I thought PCIe was a normal looking slot
that is an x1 PCIe
the rest of these are $x00.00
PCI express is a serial bus, and they run varying numbers of channels depending on the bandwidth needed
"normal" video cards are one of the highest bandwidth things in the computer and go in x16 slots
I have no more advice for you, you might be relieved to hear
I still have a couple things to try
it must be possible for you to build lrm-...-server somehow
one really, nv is out, the artifacts suck
I thought the whole point of lrm is that they are binaries - how can I build them?
I'm gonna try uninstalling nvidia-glx, and setting xorg.conf to vesa
then see how slow glxgears is
that doesn't require a reboot, right? just an x restart?
oh, non-reboot would give me desktop kernel, vesa, software glx
good enough to test speed
then reboot to get server kernel, vesa, adn software glx
I think it might be a good idea to shut down X, then remove nvidia-glx
I can do alt-F1 to get a text terminal, how to I stop X?
gdm-stop I think
Provides: nvidia-kernel-169.12, nvidia-kernel-71.86.04, nvidia-kernel-96.43.05
I notice hardy has what you want
I was thinking about biting that bullet
I'm sure hardy has a lot of other things I want too
I don't really notice any difference day-to-day
better support for my mobo's sensors, maybe a newer gimp that can handle my camera's raw files, etc
I hear ff3 is nice
are you running hardy?
only on the lathe
can you do that grep for the MEM*G config flags?
I wonder if they are setting the 64G flag in the newer kernels?
or isn't the lathe powered right now?
all I have installed is -rtai
oh wait I can get to another hardy
I did a man gdm, and it says there should be something called "gdm-stop"
but that doesn't seem to exist
I'll use the init.d method, but I wonder why the other is missing
oh well, here goes
that didn't work
"GDM already running. Aborting!"
vesa gave me 1024x768 instead of 1600x1200, I assume that can be fixed
glxgears works, at a few frames per second
something is whacked - it is reporting over 1000 fps, but the image is clearly jerky
real apps will probably be fine
wow, you're right - the HBM vismach model (rather complex) pans, rotates and zooms with only minor jerkiness, as does the axis preview
the vismach model has a bad case of the jaggies that I don't recall from before, I wonder if the HW acceleration was doing anti-aliasing
is your lcd still at a non-native resolution?
that will make everything look like hell
I have the LCD configured for non-scaling
so I have a small image in the middle of the screen
I prefer that too
vesa doesn't have the text window artifacts that nv had
I wonder why I'm not getting my 1600x1200? nothing in xorg.conf changed
gonna go back to nvidia for a sec, I want to check that jaggies thing
vesa has 4 modes, all with 16 in the 'dp/th' field
glx has about 40 modes
I mean nvidia
[03:25:37] <jmkasunich> https://www.linuxquestions.org/questions/linux-hardware-18/cannot-get-nv-driver-to-work-and-the-vesa-driver-is-limited-598696/
I just love helpfull replies like the one in that thread
so polite: "Thanks for responding, but apparently you didn't read any of my post."
trying to figure out what incantations are needed to make vesa use 1600x1200
I can't type today.
I need to restart back into vesa again
[03:31:17] <jmkasunich> http://www.pastebin.ca/1242865
(II) VESA(0): Not using mode "1600x1200" (no mode of this name)
there are two "standard" vesa modes that are 1600x1200, one is 8 bits/pixel, one is 16
(II) VESA(0): VESA VBE DDC read failed
I believe my xorg.conf has a default depth of 24
that's where it reads the monitor specs, right?
it might always fail, because of my KVM switch (not sure)
oh, bet so
those always screw it up
find your monitor specs and hardcode them
(II) VESA(0): Generic Monitor: Using hsync range of 28.00-80.00 kHz
I explicitly define horiz and vert freq ranges in my xorg.conf, it shouldn't need the DDC data
I think this is what's killing that mode
oh - ok
lemme pastebin my xorg.conf
[03:37:17] <jmkasunich> http://www.pastebin.ca/1242872
monitor info line 99
ok, you're hardcoding a modeline that gives 75kHz
I'd think there is a vesa mode that matches that, but maybe not
I didn't think that modeline was 75Hz
the xorg log has a big list of "standard vesa modes"
that is, within your specified rates
only two are 1600x1200, and they don't have the right memory depth
I don't think the modes care about refresh rate, just memory layout
worth a shot
what is? commenting out my modeline?
and changing the depth to 16
I'll change one thing at a time ;-)
DCC has a tendancy to screw up more than it does good usually.
commenting the modeline didn't help
changing depth to 16 did
restoring the modeline it still works
so, I'm running a 3.8megabyte mode on my 128 megabyte video card
which vga mode are you using?
I think 146
the vesa driver only supports pre-defined vesa modes, and there simply aren't any large deep ones
1600x1200x24 = 799
eww - icky moire (sp?) patterns on the ways of the HBM vismach model, it must be trying to dither to make up for the lack of color depth
[03:49:43] <Jymmmm> http://en.wikipedia.org/wiki/VESA_BIOS_Extensions
Jymmmm: your math is funky
oh, I see, that is a mode number
interesting that my mode 146 doesn't appear in any of those tables
so it looks like my choices for now are:
1) use the generic kernel, get 3.2G of my 4G total ram, use the nvidia driver and have fast high-quality graphics
2) use the server kernel, get all 4G of ram, use the vesa driver, and have slower low-quality graphics
other options that may or may not work include:
3) somehow come up with a binary nvidia driver that plays nice with the server kernel
4) build a kernel that is like the generic one, but has the 64G and PAE config switches set, and plays nice with the existing nvidia binary driver
oh, forgot 5) update to 8.04, which has a restricted-modules package that goes with the server kernel
that will be rather painfull but is probably the best long term solution - dapper is getting a bit crusty around the edges
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-11-02.txt
jmkasunich: I typically use vga=791 (or 794) during startup of Ubuntu in grub, then just add to the bootloader line: nosplash verbose vga=791
jmkasunich: You cna do this temporarily at bootup I think by hitting F6
jmkasunich: as far as mode 146 goes, I've never heard of it, might be an nvidia specific thing, but I wasn't really paying attention to the whole conversation either.
huh, that's interesting -- my program shows in top as a zombie, but it's still consuming about 200% CPU
(it's a pthread program in which the original thread has called pthread_exit, but there are still two threads working)
jepler_: Wouldn't that sorta-kinda be a zombie?
kinda alive, but kinda not
Jymmmm: there's a specific definition of a "zombie process" (one that has exited, but its exit value hasn't been read by the parent process through wait() or waitpid()) and I think this doesn't quite qualify (since only one thread has exited, not the whole process)