[Cooker] X-application works in RedHat but not Mandrake
One of the applications I use is Allegro Common Lisp (www.franz.com). For Linux/Unix it is run in conjunction with Emacs and appears as an Emacs buffer in which you can eval Lisp expressions, etc. (ACL runs as a separate process but communicates with the Emacs process via sockets). Anyway, one of the components of ACL that is not run inside of Emacs is the object inspector. When started, a separate window is opened. As your cursor moves over objects in the window they are highlighted/boxed, and you are supposed to be able to click on them in various ways to have these objects inspected. The problem is, the inspector does not work in Mandrake 9.0. The objects are highlighted, but clicking on them merely causes the highlight to disappear (until the mouse is moved)--the appropriate action is not executed. I have not been using this application recently but want to again. While I have support, and the company is interested in helping, they only guarantee that it will work under RedHat, and this appears to be the only Linux they run. Interestingly enough, it does work just fine under RedHat 8.0 using either KDE or Gnome. Not only does it not work under Mandrake 9.0, it does not work under Mandrake 8.1 or 8.2 (don't know about 8.0). This occurs with both KDE and Gnome and one other WM I tried. However, the inspector runs just fine on an old Mandrake 7.2 partition! Wondered if anyone on this list my have any clues or suggestions. Every one of the installations I have tested has been using XFree 4, and the MDK failures are on 3 different machines with different graphics cards. What could be different about MDK 9.0 and RedHat 8.0 (both running XFree 4) that might cause such a problem? Thanks for any suggestions, Norm
Re: [Cooker] MDK 8.2, 1024 MB RAM
I have a number of machines with 1.5-2GB of ram on them, and have been running the Enterprise (himem) kernels on them (starting with MDK 8.0). We have had no problems that I would blame on the Enterprise kernels. In fact, the only problems we have had were memory corruption problems with MDK 8.2, which were (apparently) related to msec. Fixed these problems by disabling msec checks. Same problem happened on a machine using the stock 8.2 kernel as well. I cannot quite recall what messages we would find in the logs with the error, but it was a kernel attempt to address memory that failed. We think it was related to the zip drives as well (and supermount). Currently am running 8.2 and 9.0 Enterprise kernels without problems. Norm On Friday 01 November 2002 11:27 am, you wrote: Peter Magnusson wrote: On Wed, 23 Oct 2002, Bryan Whitehead wrote: Actaully it's more than that. A machine with 2GB of ram only sees this without highmem: total used free sharedbuffers cached Mem:904940 185524 719416 0 84 107520 -/+ buffers/cache: 77920 827020 Swap: 3084400 03084400 We can't run any HIGHMEM kernels cause they hard lock on every machine after minimal use. :( So how do you do to use more memory? Or dont you use it at all? I just don't use all my memory big waste, but constant crashing is just too much to put up with on the enterprise kernel :'( So far no word/help from Mandrake :( :(
[Cooker] RpmDrake fails to unmount cdrom
I have disabled supermount because--basically--it does not work. When using RpmDrake to install new software, it is smart enough to mount the cdrom, however, it fails to unmount the device when you Quit (using the button). Furthermore, the cdrom is mounted by root so user cannot umount it, and it fails to show as mounted on the KDE desktop (device icon). Wondered at first why cdrom wouldn't eject my disk. Clearly, when quitting, RpmDrake ought to umount any devices it mounted. Norm
[Cooker] 9.0 ghostscript bug
I transferred a bunch of Poscript figures from my older machines to a new 9.0 installation yesterday and found that all of the figures I have created with GNU plotutils over the last couple of years produce errors from the Ghostscript that is provided with MDK9.0 (and they cannot be displayed, of course). Here is what I have done to confirm this is a problem with the Ghostscript provided with MDK9.0: (1) Verified these files display fine under the Ghostscripts provided with MDK 8.1 and 8.2. (2) Confirmed this problem on a 2nd fresh 9.0 installation. (3) Files print properly when sent directly to 2 Postscript printers. (4) Downloaded and compiled the latest stable AFPL ghostscript (7.04). It has no trouble with any of these files. Thus, it seems almost certain that the ghostscript provided with MDK9.0 is buggy. I am somewhat unsure what ghostscript MDK is shipping. The ghostscript sites (http://www.cs.wisc.edu/~ghost/ and http://sourceforge.net/projects/ghostscript/) have two branches: AFPL and GNU. The MDK9.0 version identifies itself as ESP Ghostscript 7.05 when it runs. Since this is the version number of the GNU version, I assume that is what it is. Don't know why it is identified as ESP Ghostscript, though. I have not tried to download the GNU Ghostscript 7.05 and test it. This is a rather serious problem given the importance of ghostscript. It means that I cannot migrate my 8.x machines to 9.0 without a fix. I am open to any suggestions on the best way to replace the MDK9.0 version with the AFPL version. If you want an example file to test, email me at [EMAIL PROTECTED] Norm
[Cooker] RC3: Supermount better but still problems
The good news: in RC3 vs. RC2, using supermount with Zip drive and floppy no longer causes inability to access Zip or hard hang when writing to floppy The bad news: I continue to have one serious problem: deleting files from either Zip or floppy corrupts the FAT filesystems on these disks, because the freed-up clusters are not being properly reclaimed. You can see this by checking available space or by running dosfsck (which will fix the filesystem problems). I cannot believe that others are not complaining about this since we have seen this problem on multiple machines starting with MDK8.2. Perhaps most people haven't noticed that the space is vanishing on their zips? Try it: fill up a zip/floppy, delete the files, and your zip/floppy will still be full. Since this problem does not occur if you disable supermount, it is clearly a supermount problem. Speaking of checking free space on your zip/floppy, RC3 introduces a new problem for supermount: if you try to use Konqueror to check properties of /mnt/zip or /mnt/floppy, the Free space on /mnt/zip line is now BLANK. This was one of the few supermount-related things that worked on RC2. Also, supermounted devices don't show up using df, so frankly, I am not sure how someone is supposed to check free space on their zips/floppies. I tested the filesystem corruption mentioned above by looking at the disks on another machine running MDK8.1 (no supermount, of course)! Note: if you check the properties of the Zip entry you get when using the Removable media icon, the free space on / is what is listed. Additional usability problems for supermount under KDE: (1) Most important: after CDROM has been accessed via Konqueror, when you eject the CDROM, tray opens and then immdiately closes again. This happens as long as any Konqueror windows are open--even those that have never accessed /mnt/cdrom. So, you have to close ALL Konqueror windows to get your CD back--unless you want to forcibly restrain the tray. (This does not happen if you simply cd into /mnt/cdrom--you can eject the CDROM even while shell windows are still open to /mnt/cdrom.) (2) With Konqueror, navigating to /mnt, it can take as long as 10s for a directory listing to appear. Similar time to refresh the directory listing. (3) If you viewing /mnt/zip in Konqueror, then navigate up to /mnt, and eject the zip disk, almost immediately the zip subdirectory icon disappears (it does not simply switch to showing locked). The only way to get it back is to refresh the directory (which can take many seconds as noted). (4) Similarly, if you are viewing /mnt/zip in Konqueror, eject the disk, insert another, refresh to see new disk listing, and then navigate up to /mnt, the zip icon is missing--even though there is a disk in the drive.
Re: [Cooker] VFS Inodes Busy / 9.0 BETA - Bug report / Installation
I am also seeing these messages upon shutdown of RC3. They did not occur in RC2. Norm On Friday 20 September 2002 05:26 pm, you wrote: mandrakeexpert incident 32411 forwarded to cooker. when replying, please cc this email address: [EMAIL PROTECTED] quoted text below pakkie : 20/09 03:08 : Incident created Hi, I've installed MDK9rc3 (on a XFS filesystem). When I halt my system I always get the following message, which doesn't really sound healthy: VFS Inodes Busy: Self destruct in five seconds, Have a nice day -end quoted text-
[Cooker] RC2: Zip drive w/supermount problems
Am having trouble accessing internal (ATAPI) 250MB Zip drive under 9.0 RC2. Upon first booting, can insert a zip disk and access drive (either from command line or using KDE URL icon I created). However, if this is ejected and then re-inserted, problems occur. Now, clicking on icon results in KDE/Konqueror error message: Unable to enter file: /mnt/zip. You do not have access rights Attempts to access the drive from command line (even as root) produce I/O error messages. In addition to the error message from Konqueror, clicking on the icon causes a harddrive icon named dynamic_mnt_zip to appear on the desktop. Once this problem occurs, I have found no way to get zip drive to function again except for rebooting! Have noted these odd factors during this problem: /etc/fstab has had the zip line removed, while /etc/mtab has two zip entries (the one that is there when system boots, and another one at the end of the file after USB, which is missing the sync option). Am also encountering problems with FAT filesystem corruption when deleting files from Zip disks. This was also a problem under MDK 8.2. Clusters are not properly freed, so that the free space on a Zip disk constantly decreases, even if files are deleted. Disks can be repaired using dosfsck (which confirms the corruption). Hard for me to understand how supermount could cause this, but simply editing fstab to remove supermount from the zip drive eliminates the corruption. Also, the same corruption occurred under 8.2 with FAT floppies (I have not verified this on RC2). Norm Carver ([EMAIL PROTECTED])
[Cooker] VIA 8233a patch and 8.2 kernel compile problems
I sent a message about this to the expert list yesterday, but got no response and also decided perhaps this was relevant to cooker, so am sending a revised version here as well. My apologies if you see it twice. I have new machine with a motherboard with the new VIA VT8233A chip (which supports UDMA133). This chip is not recognized by the the Mandrake 8.2 kernel code, so I have only very slow disk access. I have gotten ahold of the 2.4.18 kernel patch that should allow this chip to be recognized (patch is from Vojtech Pavlik). It looks like a fairly straightforward patch. However, I cannot get the Mandrake 8.2 (2.4.18) kernel to compile--with or without the patch. I was hoping someone might be able to tell me what I am doing wrong so I can test the patch. When I applied the patch to the 2.4.18-mdk6 source and tried the kernel compile, I got apparent compiler errors (internal error: segmentation fault). To see if it was the patch, I then reverted all code and tried to simply recompile the MDK kernel. Same problem (though in a different file). In other words, I can't get Mandrake 8.2's supplied kernel source to compile. Why? (I notice other people on the expert list also mentioning kernel compile problems with 8.2.) Here are the details on what I did in trying to simply recompile MDK kernel: (1) made sure gcc was installed: gcc-2.96-0.76mdk (2) made sure kernel source files were installed: kernel-headers-2.4.18-25mdk and kernel-source-2.4.18-6mdk (3) copied /usr/src/linux/arch/i386/defconfig to /usr/source/linux/.config (4) make oldconfig (5) make dep make clean (6) make bzImage Runs for a while and then ends in some file with an error like: tty_io.c: In function `release_dev': tty_io.c:1277: Internal error: Segmentation fault. Please submit a full bug report. If I make changes to the .config or try using defconfig-enterprise, I can change the file in which the seg fault occurs, but it always occurs. This is how I understand to do the kernel compile--and I have rechecked Mandrake's documentation (from 8.1). What am I doing wrong? Or is there something wrong with MDK8.2 files? If so, is there a work around? Thanks for your help. I would really like to get the disk running at full speed on this machine, and I am sure other people will start having issues with this chip so it seems useful to find out about this patch. Norm
Re: [Cooker] VIA 8233a patch and 8.2 kernel compile problems
Tried your suggestion. It changes what happens, but I am still having compilation problems. End up getting internal compiler error: while compiling floppy.c. Any other suggestions? Thanks! On Thursday 28 March 2002 02:00 pm, you wrote: On Thursday 28 March 2002 11:21 am, you wrote: Here are the details on what I did in trying to simply recompile MDK kernel: (1) made sure gcc was installed: gcc-2.96-0.76mdk (2) made sure kernel source files were installed: kernel-headers-2.4.18-25mdk and kernel-source-2.4.18-6mdk (2.5) make mrproper. This sounds quite similar to a problem that I was having, this was the solution I found in the archives, and it worked for me. (3) copied /usr/src/linux/arch/i386/defconfig to /usr/source/linux/.config (4) make oldconfig (5) make dep make clean (6) make bzImage Runs for a while and then ends in some file with an error like: tty_io.c: In function `release_dev': tty_io.c:1277: Internal error: Segmentation fault. Please submit a full bug report. Norm Barry
Re: [Cooker] VIA 8233a patch and 8.2 kernel compile problems
On Thursday 28 March 2002 06:20 pm, you wrote: On Thursday 28 March 2002 03:40 pm, you wrote: Tried your suggestion. It changes what happens, but I am still having compilation problems. End up getting internal compiler error: while compiling floppy.c. Any other suggestions? Thanks! From what I dimly recall from lkml, bad memory can cause this. You might want to throw memtest86 at it overnight and see what comes up. Post your .config and I'll see if I can reproduce it on my box. Basically: Is it a new computer/memory/mobo? Have you been able to compile kernels before on it? You're not doing anything by way of overclocking, right? The fan(s) still work(s)? Barry Got me thinking. It is in fact a brand new machine. I will try some memory tests tomorrow (when back at work), but I decided to install 8.2 on my home machine and try the compile. Guess what? It works just fine! I guess that pretty much proves it is a machine-related problem. I wonder though why there seem to be quite a few other people having similar problems. Thanks for your help! Norm
