Re: Renaming a User
>>> I was wondering if it's possible to quickly and easily switch a >>> username on a samba controlled domain. >> sure but you'd have to change... >> >> /etc/passwd (or wherever user accounts are stored) >> /etc/shadow (or wherever user passwords are stored) >> the users $HOME directory >> smbpasswd (or tdbpassdb or wherever samba user accounts/passwords are >> stored) Also, if you are using locally stored email, check for files under /var/spool/mail, and rename them to match the new username where needed. Do the same thing for crontab files too. Look under /var/spool/cron -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Periodic Fedora 9 system hangs with jumpy mouse
I have reinstalled Fedora 9 (not an upgrade) onto a system that used to run F7 fine (except for a new video card, see below). Now I am seeing intermittent system hangs or lockups; probably about 2 or 3 per day. This happens most often if I'm scrolling a page in Firefox with the mouse wheel, but it has happened a few other times too. Usually when this happens I'm doing very little other than viewing a webpage or typing at the terminal shell. No music or video is playing; screen saver is not running. Usually the only major apps in use when this happens are Firefox, Thunderbird, terminals, and emacs. I have not enabled any of the Gnome desktop effects. When the system hangs, the mouse cursor will continue to move, but it is very jumpy and sluggish. But otherwise the system is completely unresponsive (not just slow). Nothing visible on the screen updates at all, mouse clicks are not registered, keyboard input does nothing. I can not even switch out to a console window, or any of the ctrl+alt sequences. The only thing I can do is to do a hard power-off and reboot. When the system comes back up I can not find any information about what may have happened. Log files just go silent at the instant the hang occurs. All F9 updates are applied. Running kernel 2.6.25.6-55.fc9.i686. No custom drivers or packages, and very little customization...mainly out-of-the-box Fedora. This system is a Dell Optiplex GX270 (4-5 yrs old) with a Pentium 4 3GHz cpu with hyperthreading enabled, 1 MB ram. I am using LVM and LUKS encryption on the swap and /home. The only hardware change in the system was replacing my old PCI graphics card (Matrox Millenium II) with a brand new ATI Stealth X1050 AGP. This was necessary because the F9 graphical install was unusable; as the old card only had VGA output and the installer's X11 could not properly auto-detect the LCD widescreen monitor and was trying to drive it at too high a frequency. I needed to have DVI output for the F9 graphical install to work; so I had to get a new video card. Does anybody have any ideas what might be happening; and is there anything I can do to help diagnose this problem or obtain more information that may be useful? -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: Periodic Fedora 9 system hangs with jumpy mouse
On Tue, Jun 24, 2008 at 1:11 PM, Alan Cox <[EMAIL PROTECTED]> wrote: >> When the system hangs, the mouse cursor will continue to move, but >> it is very jumpy and sluggish. But otherwise the system is completely >> unresponsive (not just slow). > > That sounds like it suddenly ran out of memory. > > Try > >echo "2" >/proc/sys/vm/overcommit_memory >echo "80" >/proc/sys/vm/overcommit_ration > > and see if instead you suddenly see lots of out of memory errors and > applications going away BTW, that's _ratio, not _ration. Prior to this, those parameters were 0 and 50 respectively. Ah, yes, as soon as I ran the first command, my X11 session immediately aborted and I got sent back to the gdm login. Although my memory use should have been pretty small at the time (I had just rebooted so only a terminal window and a single Firefox tab were running). > Does anything make /var/log/messages ? Prior to changing the kernel flags above, no, nothing ever showed up in syslog. But after this I saw something like this right at the point of running the first command above: Jun 24 14:03:44 deron kernel: [drm] Num pipes: 1 Jun 24 14:03:44 deron udevd[545]: udev_event_run: fork of child failed: Cannot allocate memory Jun 24 14:03:44 deron udevd[545]: udev_event_run: fork of child failed: Cannot allocate memory Jun 24 14:03:45 deron restorecond: Will not restore a file with more than one hard link (/etc/resolv.conf) Cannot allocate memory Jun 24 14:03:45 deron kernel: tomboy[2973]: segfault at 8968548 ip 08968548 sp bfaeab7c error 4 Jun 24 14:03:45 deron acpid: client connected from 4262[0:0] Jun 24 14:03:45 deron bonobo-activation-server (dem-4259): could not associate with desktop session: Failed to connect to socket /t mp/dbus-vx4vmi4BAf: Connection refused Jun 24 14:03:46 deron kernel: agpgart: Found an AGP 3.0 compliant device at :00:00.0. Jun 24 14:03:46 deron kernel: agpgart: Putting AGP V3 device at :00:00.0 into 8x mode Jun 24 14:03:46 deron kernel: agpgart: Putting AGP V3 device at :01:00.0 into 8x mode Jun 24 14:03:47 deron kernel: [drm] Setting GART location based on new memory map Jun 24 14:03:47 deron kernel: [drm] Loading R300 Microcode Jun 24 14:03:47 deron kernel: [drm] Num pipes: 1 Jun 24 14:03:47 deron kernel: [drm] writeback test succeeded in 1 usecs Other than the udev errors, I don't know what to make of the others. >> This system is a Dell Optiplex GX270 (4-5 yrs old) with a Pentium 4 3GHz cpu >> with hyperthreading enabled, 1 MB ram. I am using LVM and LUKS encryption >> on the swap and /home. > > 1MB or 1GB. 1MB might be a bit slow so I suspect the latter ;) Yes, a typo, 1 GiB physical memory. > I wonder if LUKS + swap might be the first suspect Well, I looked a little closer and it may be my fault. The LVM I have swap in was only 32 MB in size, not the 32 GB I had intended! So my swap is way smaller than my physical memory. Would that excessively small swap space size had resulted in the abrupt hanging behavior I had witnessed? I'm going to try to resize things and get my swap back up to 32 GB. A little tricky due to LUKS being in the mix, but I should be able to do it. >> The only hardware change in the system was replacing my old PCI graphics >> card (Matrox Millenium II) with a brand new ATI Stealth X1050 AGP. This was >> necessary because the F9 graphical install was unusable; as the old card only >> had VGA output and the installer's X11 could not properly auto-detect the LCD >> widescreen monitor and was trying to drive it at too high a frequency. I >> needed >> to have DVI output for the F9 graphical install to work; so I had to get a >> new >> video card. > > Which video driver are you using ? The Fedora supplied driver, not the ATI add-on. I'm can't remember how to figure out which X driver is being used anymore. Thanks Alan -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: Periodic Fedora 9 system hangs with jumpy mouse
On Tue, Jun 24, 2008 at 3:49 PM, Alan Cox <[EMAIL PROTECTED]> wrote: > O> > I wonder if LUKS + swap might be the first suspect >> I'm going to try to resize things and get my swap back up >> to 32 GB. A little tricky due to LUKS being in the mix, but >> I should be able to do it. > > Once you've done that run it for a bit and see if it seems to be > gradually eating through swap. The overcommit test will probably work > sanely as well with 1GB+ of swap 8) I'm running with almost 14GB of swap space now instead of 32MB. (Resizing things went smooth but was quite a lengthy manual process. When you've got LUKS and LVM and ext3 all in the mix you also have to do a lot of units conversions: 512 B/sector, 1024 B/kB, 4096 B/block, 32MB/LE ...) I'll run it for a few days and report back if this worked or not. -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: LVM question
On Wed, Jun 25, 2008 at 6:55 AM, Luc MAIGNAN <[EMAIL PROTECTED]> wrote: > I 've extended a volume group by addind a new disk (pvcreate, vgextend and > lvextend). > All seems to be ok, while lvdisplay gives me the new modified size . > But a 'df' continues to give me the old size. > > What's wrong ? You also need to resize the filesystem that is contained within the logical volume so that it expands to fill the new space. Use the resize2fs command. -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Removing LUKS encrypted swap from initrd nash script
Using Fedora 9, I had initially installed with my swap in an LVM logical volume using LUKS encryption. I've since changed that so it just uses dmcrypt directly without LUKS (using /dev/random as the key in the /etc/crypttab; and this is a desktop so I'm not worried about the hibernate issues) But still at boot time, it is prompting for the LUKS passphrase, which will obviously fail because the logical volume is no longer managed with LUKS. I've even completely overwritten the entire logical volume thinking that the "cryptsetup isLuks" might still be confused when it probes the logical volume. The /etc/rc.sysinit script handles this fine though. It re-creates and maps the swap using plain dmcrypt with a random key, without me ever seeing a prompt. I also checked the /etc/blkid/blkid.tab to make sure it wasn't cached there. I've finally traced this back to being an embedded cryptsetup command in the initrd's nash script "init" (which runs before rc.sysinit)... echo Setting up disk encryption: /dev/mapper/vg0-lv01 cryptsetup luksOpen /dev/mapper/vg0-lv01 luks-vg0-lv01 resume /dev/mapper/luks-vg0-lv01 What is the recommended way to rebuild the initrd to remove this now-unnecessary luksOpen from the initrd? I'm also not sure what the "resume" command is supposed to be doing, but it obviously can't stay either. Also, more for curiosity, why was that even in the initrd to begin with? I didn't think swap was ever used or enabled until after the rc.sysinit got control. So why would initrd need that logical volume luksOpen'ed? Thanks -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: Periodic Fedora 9 system hangs with jumpy mouse
On Wed, Jun 25, 2008 at 9:16 AM, Aaron Konstam <[EMAIL PROTECTED]> wrote: >> I'm running with almost 14GB of swap space... >> > Runnin with 14GB of swap semms an obscene waste of space. When you run > free how much of it is actually used? Yes, for this machine its overkill, but I don't mind. But I also run lots of heavy-duty servers where its not (granted they are 64-bit with lots of physical memory though). -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: Periodic Fedora 9 system hangs with jumpy mouse
On Tue, Jun 24, 2008 at 3:49 PM, Alan Cox <[EMAIL PROTECTED]> wrote: > Once you've done that run it for a bit and see if it seems to be > gradually eating through swap. The overcommit test will probably work > sanely as well with 1GB+ of swap 8) Bad news. The system is still periodically "hanging". This time I have more information, and I don't believe it to be memory/swap related at all. It actually is looking more like a kernel issue (?) I was able to use another computer and keep an ssh/shell session open onto the system. Then starting from a freshly booted system and logging in, I only ran firefox. Just reading /. for a while and scrolling a lot and eventually the system exhibited the same hanging behavoir. The mouse would move jumpily, but no other interaction or screen output/updates would occur. However the remote ssh session was still alive and interactive, so the system itself was not dead. Note that nothing showed up in the syslog, even with the vm overcommit kernel parameters set as Alan suggested. Furthermore, the system still had plenty of free memory left and the swap was 0% used. vmstat showed no paging at all. From the shell, the system still appeared to operate normally, except that the Xorg process was pegging one of the CPU cores at 100%. I tried to capture stuff from the /proc entry for that process (some of it included below). I was unable to gdb attach to the Xorg process (gdb would hang). And also the Xorg process was not killable. Finally I tried kill -KILL on it, and it sort of got half-killed. The exe symlink in proc was blanked out, and the process showed up as the name "[Xorg]" (my understanding is that the bracket syntax indicates a process that is dying/zombied). However the process ID remained, and it still showed as consuming 100% cpu in a running (R) state; which an actual zombie would never do. Here's the output of /proc/2682/status, before I attempted to kill it: Name: Xorg State: R (running) Tgid: 2682 Pid:2682 PPid: 2681 TracerPid: 0 Uid:0 0 0 0 Gid:0 0 0 0 FDSize: 256 Groups: VmPeak: 611884 kB VmSize:34632 kB VmLck: 0 kB VmHWM: 60628 kB VmRSS: 25496 kB VmData:18560 kB VmStk:84 kB VmExe: 1724 kB VmLib: 9180 kB VmPTE: 592 kB Threads:1 SigQ: 1/16375 SigPnd: ShdPnd: 2000 SigBlk: SigIgn: 00301000 SigCgt: 0001d1806ecb CapInh: CapPrm: CapEff: Cpus_allowed: 0003 Mems_allowed: 1 voluntary_ctxt_switches:334819 nonvoluntary_ctxt_switches: 34772 Note that the context switches would always increase every time I checked; even after it was in the half-killed state. All of the other processes for my user, except for Xorg, could be killed off cleanly. Only the Xorg process remained. Also during this time, I could see no significant system I/O occuring (where is the iostat command btw?). Also vmstat showed a very calm system. Again, this is running kernel 2.6.25.6-55.fc9.i686, with a 2-cpu smp (1 cpu with hyperthreading). Is there anything I can do to capture more useful information the next time this happens? -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: Periodic Fedora 9 system hangs with jumpy mouse
On Wed, Jun 25, 2008 at 2:55 PM, g <[EMAIL PROTECTED]> wrote: > Deron Meranda wrote: > >> >> the Xorg process (gdb would hang). And also the Xorg process >> was not killable. Finally I tried kill -KILL on it, and it sort >> of got half-killed. > > use 'ps -el|grep X' to find 'X', Xorg process, then > > "kill -15 'pid#'" to kill it. if '-15' fails, use '-7'. I did the ps thing. Only one Xorg process was running. I also tried kills in the following order: kill -TERM (-15) kill -SEGV (-11) kill -KILL (-9) The first two did nothing. The last kill (which is not blockable) changed the process name from "Xorg" to "[Xorg]" and blanked the /proc/xxx/exe symlink; but otherwise the Xorg process remained in a run state consuming 100% cpu. BTW, I've now looked through the Xorg.0.log file, and nothing interesting shows up in it when this "hang" occurs. Also the video card driver being loaded is the "radeon_drv.so" that comes with F9. -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: Periodic Fedora 9 system hangs with jumpy mouse
On Wed, Jun 25, 2008 at 3:44 PM, g <[EMAIL PROTECTED]> wrote: >> I also tried kills in the following order: >> >> kill -TERM (-15) >> kill -SEGV (-11) >> kill -KILL (-9) > > this is not same as what i was showing you above. use numbers, not words. > type it as "kill -15 'pid#'" and use '-7' if '-15' does not work. > there is a difference in what i am showing you and what you are using. No, there's no difference. These are all equivalent (on Linux): kill -15 pid kill -TERM pid kill -s 15 pid kill -s TERM pid I got in the habit of using symbolic names because I work on a lot of different kinds of Unix systems (not just Linux), and signal numbers are not always the same across OS's, but signal names are. * * * Anyway, I had another runaway Xorg. This time I was using the scrollbar on a simple gnome-terminal window; not firefox. It seems that this problem almost always occurs while I'm using a scrollbar of some sort. That may or may not be coincidence, but I'm leaning toward not at this point. Regarding signals This time when I had the Xorg process running at 100% cpu, I monitored the /proc/2384/status and /proc/2384/task/2384/status files. Before I even tried to do any kill, I noticed that the ShdPnd (shared pending signals) would toggle randomly between all zeros and 00..002000, sometimes for the process and sometimes for the task/thread. The wait channels (whan) were always 0 every time I looked. I went ahead and stopped (SIGSTOP) the Xorg parent process (gdm-simple-slave) just to make sure it wasn't sending signals. It wasn't. Other than the Xorg process, top showed an otherwise practically idle system. When I sent signals via kill to the process, I could occasionally see those signal bits show up in the ShdPnd bitmask for a second, and then it would go all zeros again. Yes, I tried all sorts of signals, including 7 (SIGBUS) too. Nothing had any noticeable affect on the Xorg process. I then did a SIGSTOP on the Xorg process. It remained in a running state consuming 100% cpu (odd); but the signal mask was changed and any subsequent signals I sent you could see accumulate in the pending signal mask field (as I would expect). But then doing a continue (SIGCONT) later, the pending signals would go back to 0 (and occasionally 0x2000 temporarily). Only when I sent a SIGKILL did anything change. The process was effectively killed; the exe symlink was gone, all the file descriptors were closed, etc. But the process entry still remained in the running state and was consuming 100% cpu. This wasn't just a status bug, you could noticeably tell the cpu was really pegged by the sluggishness of typing. After the SIGKILL, the signal pending masks would always stay at 0, regardless of any additional kills sent to it. I still have not seen any messages show up in syslog, dmesg, Xorg.0.log, or anyplace else I can think to look. And the rest of the system appears to be totally operational (but cpu starved). No weird I/O. All the filesystems are still quite usable. But the only way to get Xorg out of its mess is to reboot. So this looks like some strange kernel interaction with Xorg. Any ideas? Is there any other information I can get when the Xorg process does this again that might help figure this out? Thanks -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: Periodic Fedora 9 system hangs with jumpy mouse
Okay, so Xorg ran away last night while the system was totally idle and not being used at all. So I guess the scrollbar theory could be suspect. There was a screensaver running (just the "cosmos" image slideshow, no moving graphics); and I left firefox up, which had a gmail window running so it would I supposed occasionally refresh itself. But otherwise it should have been a completely idle unused system. My big question at this point is how is this locking up so hard? When you can't even kill -9 the process, what is going on. This has to be more than just Xorg (a user-space program), the kernel has to be involved here too. Is it a spinlock deadlock, or something like that? So how can you figure out what all those cpu cycles are being used for? Isn't there a way to probe into the kernel to see what it's doing? Unfortunately the wchan is 0, which is how I thought you could tell this sort of thing. Is there some place under /proc or some other method to peek around? Anyway, concerning the Xorg driver module, this is a brand new install of F9 (not an upgrade). All the software is part of the base F9 repo; nothing 3rd party was added. Everything was auto-detected. The video card shows up in a system scan as: ATI Technologies Inc RV350 AS [Radeon 9550] Chipset: "ATI Radeon 9600 AS (AGP)" (ChipID = 0x4153) The vendor's name on the box was: Diamond ATI Stealth X1050 (AGP 256MB) The Xorg driver chosen for this was: /usr/lib/xorg/modules/drivers//radeon_drv.so My screen is 1440 x 900 x 24, monitor is DELL E198WFP > just for fun and practice of card swapping, do you have a different > graphics card to try with different drivers? The only other card I had was a PCI card that only had VGA output, no DVI. And F9 didn't seem to know how to detect the monitor correctly and was overdriving the frequency (although it worked under F7). > do you boot level 3 or level 5. boot level 3, if cpu usage is low, then > 'startx' to see what happens. mono verses color. Yes, I can try that. So far it's just been boot to runlevel 5. > from level 3 boot, remove driver, then use 'yum install' to bring your > driver back in and reboot to load it. driver may be fried. The driver is coming from the package xorg-x11-drv-ati-6.8.0-14.fc9.i386 I did an rpm verify on it, rpm -V -v xorg-x11-drv-ati-6.8.0-14.fc9.i386 and that said all the files were intact and correct. > kde, gnome? have you tried any minimal desktops? something may, tho i > would doubt, be different in how you bring up x. Haven't tried other desktops other than Gnome, but I have disabled all the fancy effects, etc. The system runs perfectly fine; until that magic moment when the Xorg process runs away. Or is that the kernel that is running away? I wish I knew how to debug the kernel better; because it just doesn't appear to be a user-space problem. -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: Periodic Fedora 9 system hangs with jumpy mouse
Steve, your observed Xorg behavior certainly sounds very much like mine. It is quite frustrating. I've been trying to minimize my use of Firefox (painful) and shutting the app down when I'm not using it; and so far that seems to have greatly reduced (but not eliminated) the frequency of my hanging. But still, this almost has to be an interaction between the kernel and Xorg. I really wish I knew how to go about debugging the kernel when it gets in this modeeven if it's just to identify "what" it is doing. First, to compare systems.. It looks like you're running with a 64-bit kernel; I'm using a 32-bit 2-core processor. Are you also running with SMP (multiple CPU cores?). Do a: cat /proc/cpuinfo My card is a Diamond Stealth ATI X1050; which is really a vendor repackaging of an ATI RV350 AS [Radeon 9550], an AGP version. It also supposedly has this as its chipset: "ATI Radeon 9600 AS (AGP)" (ChipID = 0x4153) My card also has dual-head output capability (one DVI and one VGA); but I'm only using the DVI output only. I'm also not using any of the 3-D stuff. What does your card identify itself as? Try doing: lspci Also look in the Xorg.0.log file: grep -i chipset /var/log/Xorg.0.log On Tue, Jul 1, 2008 at 9:26 AM, Steve Dowe <[EMAIL PROTECTED]> wrote: >> The cause of this problem on my system seems to be when dragging >> (resizing) a window. X then seems to hang, the pointer gets jumpy Although mine happens (usually) when I'm doing vertical scrolling, they may be related. In both cases there is usually a lot of bitmap moving occurring, which may be a bitblit operation of some sort, possibly involving 2D acceleration. > I should also have added that the mouse cursor image "sticks" to the > diagonal arrow - it doesn't become the normal arrow/pointer again. This is probably to be expected. I believe that the cursor/pointer movement is "hardware" assisted; which means that it runs within interrupt code and not in the main Xorg event loop. Changing the pointer graphic though must be done outside interrupts; and the Xorg process appears to be stuck. See if you see what I do: $ grep -i cursor /var/log/Xorg.0.log (II) RADEON(0): Using hardware cursor 0 (scanline 1202) (II) RADEON(0): Using hardware cursor 1 (scanline 1204) > I have just booted up in the debug kernel and managed to re-hang X in no > time at all, using the method described above... :-/ Hmmm. I should try that too. > The only error message I can find, both in dmesg and messages, is this: > > kernel: ACPI Error (tbfadt-0453): 32/64X address mismatch in > "Pm2ControlBlock": [8800] [8100], using 64X [20070126] I don't know for sure, but this seems like a problem that would only occur on a 64-bit system. I only have a 32-bit system. I don't know if this would be related to your Xorg hanging, but I would have to guess that such an error would cause a process (or the kernel) to be completely aborted/panic'dnot get stuck in a 100% cpu loop. One thing we could try, is to pass options to the ATI driver to disable certain features (perhaps like certain forms of acceleration??). You can do a "man radeon" to see the options available. Those would supposedly go into your /etc/X11/xorg.conf file. I don't have any good suggestions on what to try though; and it's tedious to do the trial and error thing. Any kernel-savy people have any ideas of how to collect more information about this? -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: Periodic Fedora 9 system hangs with jumpy mouse
On Tue, Jul 1, 2008 at 3:59 PM, Steve Dowe <[EMAIL PROTECTED]> wrote: > I became aware of the firefox buffer memory flushing issue when running FF > 3.0b5. However, it seems to behave itself very well now on my box, using > FF3.0. Here is a link which I found useful in understanding that issue > further: http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/ Good link, but I think it is entirely unrelated to this. I'm running FF 3.0 final. Besides I never see any I/O contention; and many times when it hangs there is not disk I/O at all. And the hang never clears up, even after sitting for hours, as an fsync delay would cause. And the wchan for FF (or Xorg) never indicates that its blocking on an fsync. Also I can and have done filesystem writes *after* such an Xorg hang with no problems. > I suspected something was wrong by seeing a high CPU count for kcryptd, > which is used to encrypt a hard disk if configured that way (incidentally, > high kcryptd CPU was, in that case, a red herring). I'm also using an encrypted logical volume (dmcrypt/LUKS) for my home directory; but I've not seen anything suspicious about it. Only Xorg hangs, anything else I try to do (from a command line) works fine. > I'm running on an AMD Turion TL-60. Sounds like you have an intel? So you have a SMP 64-bit, and I have an SMP 32-bit. Yes, I'm have an Intel Pentium 4 (300MHz) with hyperthreading (pseudo 2-core). I wonder if disabling SMP at boot has any affect? Use the "nosmp" boot-time kernel option. Note though that if you're running with only one cpu and Xorg goes wild, you may not be able to ssh or do anything else, depending where at in the kernel this problem is occurring. >> My card is a Diamond Stealth ATI X1050; which is really a >> vendor repackaging of an ATI RV350 AS [Radeon 9550], >> an AGP version. It also supposedly has this as its chipset: >> "ATI Radeon 9600 AS (AGP)" (ChipID = 0x4153) and yours is a: > 01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 > Series] > (--) RADEON(0): Chipset: "ATI Radeon X1200" (ChipID = 0x791f) It looks like we have quite different ATI cards; but I don't know my Radeon product line very well. > # grep -i cursor /var/log/Xorg.0.log > (II) RADEON(0): Using hardware cursor 0 (scanline 1602) > (II) RADEON(0): Using hardware cursor 1 (scanline 1604) > > Presumably this is influenced by the display dimensions and refresh rate? You're using hardware-assisted cursor/pointer; which is the default. I think the scanline numbers indicate at which point in the screen refresh cycle that the interrupt will be generated (but I'm kind of guessing here). It's not too important. If you disable hardware cursors in your xorg.conf, those lines should not appear in the log file. > man radeon - excellent intro doc to the driver. The first two options are > of primary interest to me: > > Option "SWcursor" "boolean" > Selects software cursor. The default is off. > > Option "NoAccel" "boolean" > Enables or disables all hardware acceleration. > The default is to enable hardware acceleration. > > I'm going to try with both of these options enabled in xorg.conf and see if > I can hang the machine again. If so, perhaps we should look at the kernel. It will be interesting if NoAccel works. Of course that's quite a drastic workaround and may make your system seem very sluggish. But it could give a clue if the system behaves differently. Unfortunately the system hanging on me is one of my primary workstations and I don't have the luxury of being able to tweak and play with different options as much; especially since having to do a hard reboot is so disruptive. (I will say that I haven't had a lockup in about 3 days now; previously I'd see lockups 3 or 4 times a day. I do stay up to date on patches, but the only things recently which seem even remotely plausible are a HAL and libsysfs update and some SELinux policies. I may just be lucky, we'll see how long my system stays up). -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: Periodic Fedora 9 system hangs with jumpy mouse
On Tue, Jul 8, 2008 at 7:15 AM, Thomas Kappelmueller <[EMAIL PROTECTED]> wrote: > I completely solved this problem by doing this: > "yum install xorg-x11-drv-radeonhd" I can't use the radeonhd driver because it doesn't support or detect my card. The radeonhd only detects R5xx/R6xx based cards, so radeonhd is not an alternative for the radeon driver unless you happen to have a card which is in the overlap of the supported list. Reading the man page for radeonhd(4), it says that the driver doesn't yet support 2-D acceleration! So I suspect that may have more to do with its apparent stability for you than it being a different driver. As so far it seems that all the hanging problems we've seen appear to have something to do with 2-D acceleration. Strangely, I had been using the original radeon driver (without disabling any features) for about 2 weeks and it has not hung on me like it used to do frequently. I had started X via startx command, and not run level 5. (Incidentally, startx seems to work fine except it doesn't pick up any customized key mappings. I for instance set my caps lock to be ctrl. Starting via gdm uses my settings, but via startx does not... any ideas?) However I finally rebooted today (into run level 5) and then Xorg hung within 5 minutes...I wasn't even using the mouse, I just had a single terminal window open that was tail'ing a log file (and hence was scrolling text on its own). There were a lot of X and Gnome related RPM updates pushed today for Fedora 9; so I installed them all and will see if that makes any difference. -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: Periodic Fedora 9 system hangs with jumpy mouse
An update on this problem: First, I'm up to date on the latest kernel and X window packages. Again, I'm using the standard Fedora Radeon driver with all the default options. I'm also using the standard Gnome interface. Here's the strange thing I'm seeing. I don't know if this is just coincidence or not, but it is what I've experienced. If I boot the machine all the way to run level 5, then either X will experience the "hanging jumpy mouse" issue fairly quickly after use (usually when scrolling); or the X server doesn't even start correctly (I just get garbage pixels on the screen and the machine hangs). This later "garbage pixel" outcome only started occurring after the last kernel/X11 updates. However if I boot to run level 3 and then type "startx" at a console; then the session is extremely stable. In fact I've never had it hang at all if started via startx despite how heavily I use it. The only down side is that for some reason the startx method does not initialize any customized keyboard key mappings (such as setting caps-lock to be ctrl). But if I go to the System->Preferences->Hardware->Keyboard properties dialog and close it all is good again. This doesn't make a lot of sense to me; but perhaps it will to somebody. -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: encrypted swap question
On Tue, Aug 5, 2008 at 12:21 PM, Mike C <[EMAIL PROTECTED]> wrote: > I have a machine with f9 clean installed and encrypted /, encrypted swap > and encrypted /opt partitions. > > Of course during boot you are asked for the luks passphrase for all three > partitions. > > ... > > I would like to to the same with the swap partition - but if I make a > second keyfile in /root and refer to it on the swap partition line in > /etc/crypttab in the same way as for /opt then it ignores this during boot and > asks the user for the luks passphrase for the swap partition after asking for > the passphrase for the root partition. The / and primary swap partitions (or logical volumes) are handled a bit differently than say /opt. They are mounted very early in the boot process, and in fact are handled by the initrd's nash scripts. If you change the LUKS options for these, you'll need to rebuild the initrd (see mkinitrd) as well. Or, you could just wait until the next kernel update and it will correct things for you. I'd use /dev/urandom for swap; unless it's a laptop and you'll be doing suspend-to-ram (which I've heard could have LUKS issues). -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Can't upgrade f10 to f11: X startup failed, detected GPU lockup
I'm trying to install/upgrade a system currently running F10 to F11 (64-bit AMD, 4MB ram). The anaconda graphical install fails, and it always falls back to the text mode install. I have to use the graphical mode, because I need partitioning/LVM/LUKS options that the text mode does not support. This system worked fine with both F9 and F10. I'm using the on-board graphics chip on the motherboard (ASUS M2NBP-VM CSM) which is supposedly an nVidia GeForce 6150LE. Anyway during the early F11 anaconda install it always outputs: WARNING : X startup failed, falling back to text mode Looking at the X.log file, I have these excerpts: X.log Kernel command line: initrd=initrd.img BOOT_IMAGE=vmlinuz Build Date: 18 May 2009 02:47:15PM Build ID: xorg-x11-server 1.6.1.901-1.fc11 (--) PCI:*(0...@0:5:0) nVidia Corporation C51 [Quadro NVS 210S/GeForce 6150LE] rev 162, Mem @ 0xfc00/16777216, 0xd000/268435456, 0xfb00/16777216, BIOS @ 0x/131072 (II) NOUVEAU driver (II) NOUVEAU driver for NVIDIA chipset families : GeForce 6 (NV4x) (--) NOUVEAU(0): Chipset: "NVIDIA NV4E" (II) NOUVEAU(0): Setting dpms mode 3 on vga encoder (output 0) (II) NOUVEAU(0): Setting dpms mode 3 on tmds encoder (output 1) (II) NOUVEAU(0): Setting dpms mode 3 on CRTC 0 (II) NOUVEAU(0): Setting dpms mode 3 on CRTC 1 (II) NOUVEAU(0): Setting dpms mode 3 on CRTC 0 Fatal server error: Detected GPU lockup End X.log Does anybody have any idea what may have changed in F11, and how I can get the graphical installer to run like it did in previous releases? -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Can't upgrade f10 to f11: X startup failed, detected GPU lockup
> You might try "nomodeset" on the boot command line and see if the X server > starts ok. I tried that, with the same results. Actually in the X.log, there is a line that says that the chipset doesn't support modeset anyway, so the nomodeset option probably doesn't do anything. > If that fails, and you have another linux box to use, you can add "vnc" to > the command line and do a graphical install remotely. Hmm. I may have to try this one if I can't get anything else to work. Unfortunately, at this location, all my other linux boxes are quite old; running FC 3 and such. But I'll try to see if this will work. I hope I don't have to continue doing this for the upcoming F12. Thanks -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Can't upgrade f10 to f11: X startup failed, detected GPU lockup
On Mon, Sep 14, 2009 at 1:39 AM, n2xssvv.g02gfr12930 wrote: >> This system worked fine with both F9 and F10. I'm using the >> on-board graphics chip on the motherboard (ASUS M2NBP-VM CSM) >> which is supposedly an nVidia GeForce 6150LE. >> >> Anyway during the early F11 anaconda install it always outputs: >> WARNING : X startup failed, falling back to text mode > I managed to upgrade using Yumex and the nvidia drivers found in the RPM > Fusion repositories. Naturally I updated the GUI stuff first, in my case the > KDE and Gnome window managers, and the X-Video drivers. I've never used that before. Do you know of any recommended documentation any place? To be honest, this is really a headless server; I only ever use the video output to do these installs/upgrades. I'd be happy with text mode; except it is exceptionally crippled now as to be worthless. > Perhaps you should try setting the video driver to use to the standard vga > during the upgrade. The nouveau nvidia drivers are new to F11. I'm installing from the standard DVD image. How do you go about telling it to use a different driver? If you're referring to the initial menu, I tried the second option, something about using a "basic" video driver. It too fails, and reverts to text mode. Though rather than a GPU lockup, it complains about not having any compatible modes. Whatever drivers were standard in F9 or F10 worked just fine. Are they on the F11 install image and how can I tell it to use those instead of the new broken one? > After upgrading you may well still have your system using the ext3 > filesystem. I also managed to upgrade my Fedora 11 from ext3 to ext4 > successfully, but I still made backups beforehand, not to mention good > preparations. NOTE, do not upgrade your boot partition to ext4 as grub does > not support ext4 as far as I know. I'm on top of the ext3/4 thing. Thanks though! -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Can't upgrade f10 to f11: X startup failed, detected GPU lockup
On Mon, Sep 14, 2009 at 12:31 PM, n2xssvv.g02gfr12930 wrote: > yumex is a gui application that uses yum unfortunately. But yum itself is > not a gui application and can install and update from remote repositories. Thanks. I use rpm and yum (command line) frequently. But I don't use the graphical tools very often, so yumex was new to me. Is it just a front-end to yum, and is there anything that yumex does that yum can't? > These repositories locations are defined in *.repo files that can be found > in the /etc/yum.repos.d directory, and they are plain text files. Normally, adding yum repositories is not too hard; but I'm not very familiar with which repositories exist and which ones I should try using. You mentioned the RPM Fusion repositories; where do I find out more about that? However, that's fine for an already-running system. But I'm not aware of how to configure any of this when booting from the F11 DVD. How in the install/upgrade process can you tell it to do something different? > http://www.ghacks.net/2009/01/14/fedora-10-and-the-evolution-of-xorg/ Thanks for the link. I was vaguely aware of some of that, but it is interesting nonetheless. > As far as I can tell you probably need to configure for the old nv video > drivers rather than the nouveau ones it's trying to use. Agreed, either that or somehow get it to use a newer/fixed version somehow (which I hope is fixed by F12). > Hope these pointers help you resolve your problems. Thanks again -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Can't upgrade f10 to f11: X startup failed, detected GPU lockup
On Mon, Sep 14, 2009 at 4:32 PM, Kam Leo wrote: > Have you tried installing with vga=vesa? If I recall correctly you > need to press TAB and append that to grub. Nope, booting with vga=vesa does not work either. It still reverts to text mode after X fails to start. I am using the VNC boot option that G.Wolfe recommended, and that does appear to work so far (I'm in the middle of the upgrade now). It's documented in section 9.2 of the Fedora 11 Installation guide <http://docs.fedoraproject.org/install-guide/f11/en-US/html/sn-remoteaccess-installation.html> I'd still be interested to know how one could go about installing if I didn't happen to have another computer nearby to use. And if what I encountered is a known issue, that perhaps will be solved for F12. (Or if I can help collect information for the developers responsible for this area). Thanks to everybody -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Can't upgrade f10 to f11: X startup failed, detected GPU lockup
Just an update.. I finally got updated from F10 to F11 by using the remote VNC boot option. Interestingly though, immediately after the update I was able to boot the system all the way up to run level 5, and X works great. This is before any yum updates ... just using what was on the F11 DVD, apparently. So, is it the case that the X11 drivers on the F11 DVD are capable of working; but yet the anaconda installer can't? -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
F9 X11 mouse pointer grows hair and invisible screen boundaries
I have a peculiar problem that just started on my Fedora 9 system where my mouse pointer will suddenly "grow hair"; it will get a lot of random black pixels surrounding the pointer graphic (probably contained within a 20x20 pixel area). Whenever the pointer graphic is changed by an application (like crossing over a scrollbar) the random pattern of attached hair will also change. More annoyingly, when this happens, the pointer appears to have lost track of the screen boundaries. You can move it in one direction and it will hit some invisible random wall, as if it was at the edge of the screen even though its not. Sometimes it will jump/warp to a different part of the screen and the location of these invisible walls will randomly change. This makes using applications or even accessing menus or close buttons very challenging. When I can manage to close down a lot of applications, the problem will often clear up; which makes me think it may be more likely during a low memory condition. Although I never do actually run out of free memory, and I have plenty of swap. This is a 32-bit kernel, version 2.6.26.5-45.fc9.i686 The video card shows up in a system scan as: ATI Technologies Inc RV350 AS [Radeon 9550] Chipset: "ATI Radeon 9600 AS (AGP)" (ChipID = 0x4153) The vendor's name on the box was: Diamond ATI Stealth X1050 (AGP 256MB) The Xorg driver chosen for this was: /usr/lib/xorg/modules/drivers/radeon_drv.so which is from package xorg-x11-drv-ati-6.8.0-19.fc9.i386 I've been running for a long time with an xorg.conf which turns off the DRI option to work around lockup problems with this particular card. But this pointer hair is a new problem. Option "DRI" "off" My screen is 1440 x 900 x 24, monitor is DELL E198WFP Any ideas? -- Deron Meranda -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
