[Cooker] [Bug 3747] [bash] Broken lines on all terminal emulators
http://qa.mandrakesoft.com/show_bug.cgi?id=3747 --- Additional Comments From [EMAIL PROTECTED] 2003-24-06 19:48 --- so to fix this, shopt -s checkwinsize is needed by default under bash. What I do not understand is why I get this bug without running top or anything else. Resizing konsole always results in problems when using arrows to seek in the command. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: This happens on Mandrake (and maybe others) on any terminal emulator (konsole, aterm, xterm, rxvt, Eterm, etc) on Mdk9.1 and earlier versions. To reproduce it: 1. On X, open any terminal (eg. xterm). Don't maximize it. 2. Write 'top' and press ENTER. top uses all the window. 3. Maximize the window. 4. Press 'q' to quit top 5. Start writing anything until you reach the right-most part of the screen. Before reaching the right margin, the cursor will go the the beginning of the line (as if it were going to pass to the next line, but it doesn't). PS: I first thought it was due to KDE and filed a bug at http://bugs.kde.org/show_bug.cgi?id=53418See the screenshot there.
[Cooker] [Bug 1281] [Installation] user cannot read mounted winxp partitions
http://qa.mandrakesoft.com/show_bug.cgi?id=1281 --- Additional Comments From [EMAIL PROTECTED] 2003-03-31 18:51 --- if it happens on clean install, give fstab entries and dir listing again in that case. 16 drwxr--r--4 root root16384 Dec 31 1969 win-more the permissions here are an indication of the mount options used, so it does not help if you chmod a+x win-more here, you have to change fstab to do this. I therefore fail to understand how your fstab can report /dev/hda1 /mnt/winxp vfat iocharset=iso8859-1,codepage=850 0 0 and that the dir gets above permissions. Unless it was remounted with different options afterwards. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: __UNKNOWN__ status: RESOLVED creation_date: description: Here's a partial listing of my /mnt 16 drwxr--r--4 root root16384 Dec 31 1969 win-more 32 drwxr--r-- 19 root root32768 Dec 31 1969 winxp Here are the relevant lines from /etc/fstab /dev/hdb1 /mnt/win-more vfat user,uid=501,umask=0,codepage=850,iocharset=iso8859-1 0 0 /dev/hda1 /mnt/winxp vfat iocharset=iso8859-1,codepage=850 0 0 Here is what happens when I try to cd win-more or cd winxp win-more: Permission denied. winxp: Permission denied. Both mounted drives are accessible as root, but not as myself (user nate, uid 501). chmod: changing permissions of `win-more': Operation not permitted. I left the /mnt/winxp mount parameters just as the 9.1b3 upgrade chose to set them, and I've fiddled with the parameters for /mnt/win-more based on what I've read in other similar problem reports. I remembered to mount -a, and I've even rebooted a few times. Nothing fixes it.
[Cooker] [Bug 2255] [drakxtools] Bad frequency ranges in /etc/X11/XF86Config-4 in mdk-9.1rc2
http://qa.mandrakesoft.com/show_bug.cgi?id=2255 --- Additional Comments From [EMAIL PROTECTED] 2003-03-31 18:57 --- have a look at /usr/share/ldetect-lst/MonitorsDB and what kind of info you have to submit for your monitor. ddcxinfos |grep EISA should give you also the EDID --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: Using mandrake-9.1rc1. XFdrake generates these default ranges for 1024x768: HorizSync 31.5- 57 VertRefresh 50-70 Obviously, which these ranges it is impossible to get any refresh rate above 70Hz. Since XFdrake does not allow one to choose the refresh rate, the default ranges should be larger, something like: HorizSync 30- 70 VertRefresh 50-90 Even 5+ year old cards like riva128 can do 85Hz at [EMAIL PROTECTED]
[Cooker] [Bug 3574] [kernel] supermount prevents CD ejection in mdk-9.1 final
http://qa.mandrakesoft.com/show_bug.cgi?id=3574 --- Additional Comments From [EMAIL PROTECTED] 2003-03-31 19:00 --- Since you're interested:) Best for you would be to try andreys new supermount patch posted on cooker today. It fixes most known bugs and also allows and option no_tray_lock so you can always get the drive to open. d. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: I have all updates applied on stock mdk-9.1 install. I have supermount and scsi-emulation enabled. I have two IDE CD drives: hdc (scsi-emulated) hdd (no scsi-emulation). The CD ejection problem is reproducble for both drives. Steps to reproduce the problem - 1. Put a CD in the drive and close the tray by pressing the CD eject button (the hardware button present on the drive). Press the eject button again and verify that the CD is ejected as expected. Close the CD tray again. 2. Lets say that the CD drive device is /dev/cdrom (mounted on /mnt/cdrom2). Run the command: ls /mnt/cdrom2 Now, press the CD eject button, the CD is ejected fine. Close the CD tray. 3. Run a command to read /dev/cdrom as: cat /dev/cdrom 4. Wait for the cat command in previous step to end (or you may interrupt the cat command if it takes too long). 5. a) Now press the CD eject button. Nothing happens. b) If I use eject /dev/cdrom, the CD is ejected fine. 6. a) If I skip step 5b and run ls /mnt/cdrom2, then the CD files are listed just fine. b) After step 6a, if I press the CD eject button, it ejects normally. This strange behavior is 100% reproducible. It seems that every time the cat command is used after an ls command, it prevents a manual hardware ejection of the CD. After cat, using the ls command sets things right. Further investigation revealed that if I manually umount /mnt/cdrom2 then this problem disappears. If I manually re-mount /mnt/cdrom2, the problem reappears. Obviously, supermount is not handling things correctly since the problem is related to mounting. No error messages in dmesg or /var/log/* can be found that explains this odd behavior. I reported the same bug in bug 2103 but that bug has been marked resolved as fixed, even though the bug still exists in mandrake-9.1 final.
[Cooker] [Bug 2255] [drakxtools] Bad frequency ranges in /etc/X11/XF86Config-4 in mdk-9.1rc2/mdk-9.1 final
http://qa.mandrakesoft.com/show_bug.cgi?id=2255 --- Additional Comments From [EMAIL PROTECTED] 2003-03-31 19:27 --- good, but look in the manual to fill in the other values needed by /usr/share/ldetect-lst/MonitorsDB (most importantly max horizontal and vertical freq, [EMAIL PROTECTED]@85Hz is not enough info, check the monitor manual!). --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: Using mandrake-9.1rc1. XFdrake generates these default ranges for 1024x768: HorizSync 31.5- 57 VertRefresh 50-70 Obviously, which these ranges it is impossible to get any refresh rate above 70Hz. Since XFdrake does not allow one to choose the refresh rate, the default ranges should be larger, something like: HorizSync 30- 70 VertRefresh 50-90 Even 5+ year old cards like riva128 can do 85Hz at [EMAIL PROTECTED]
[Cooker] [Bug 2922] [kernel-2.4.21.0.13mdk] ALSA output broken on SB16 PCI in current kernel
http://qa.mandrakesoft.com/show_bug.cgi?id=2922 [EMAIL PROTECTED] changed: What|Removed |Added Product|kernel-2.4.21.0.12mdk |kernel-2.4.21.0.13mdk --- Additional Comments From [EMAIL PROTECTED] 2003-03-08 21:44 --- adam, can you try older alsa driver versions to see were it started misbehaving? also, you might want to post the problem at alsa-ml. d. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: As the summary states, ALSA output simply doesn't work on this card in current Cooker kernels. I expect the last ALSA update broke it (it used to work fine). The card uses the snd-ens1371 driver. Any program which attempts to output to ALSA natively freezes as soon as it attempts to play sound, and cannot be exited normally, even ctrl-c fails to work - has to be 'kill'ed. This has been verified with xmms in ALSA mode (using the xmms-alsa plugin), totem, xine with the ALSA plugin, and ogg123 (which attempts to output in ALSA mode by default). However, sound works with the ALSA driver if its OSS emulation is used - i.e., I can get sound perfectly well with any program set to output in OSS mode, using the ALSA driver. None of the programs I checked gave any error output, they just froze. This is quite a popular legacy card. Can't find anything in the ALSA mailing lists about this.
[Cooker] [Bug 2432] [kernel-2.4.21.0.12mdk] Audio modules problems : MPlayer makes a very choppy sound with oss and alsa9 drivers
http://qa.mandrakesoft.com/show_bug.cgi?id=2432 --- Additional Comments From [EMAIL PROTECTED] 2003-03-07 01:15 --- bug will be fixed in next kernel update --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: MPlayer makes a very choppy sound with oss and alsa9 drivers (using -ao oss and -ao alsa9) when reading : - unencrypted DVD - decrypted vobs - avi files with mp3 audio stream The sound is very choppy (even more with alsa driver) and slows down the video as well. This does not occur when using the SDL audio driver (-ao sdl). This happens with the packaged mplayer and also with a compilation of MPlayer from the sources. Using OGLE DVD player, there is a similar problem : when playing DVD, the sound is choppy, but the video plays too fast. Howover, this does not occur with Xine when playing the exact same files, either with oss and alsa9 drivers.
[Cooker] [Bug 2103] [kernel] supermount prevents CD ejection in mdk-9.0/mdk-9.1rc1
http://qa.mandrakesoft.com/show_bug.cgi?id=2103 --- Additional Comments From [EMAIL PROTECTED] 2003-02-28 10:09 --- you are right. noatime doesn't matter. Only the bug does not occur for me when only cat /dev/cdrom. It seems I first have to ls /mnt/cdrom and after that cat /dev/cdrom. d. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: Firstly, I am running kernel 2.4.19-24mdk (not 2.4.19-19mdk). I have all updates applied. I also have supermount and scsi-emulation enabled. I have two CD drives (hdc and hdd). The ejection problem is with /dev/cdrom1 (/dev/hdd). Here are the steps to reproduce the problem: 1. Put a CD in the drive and close the tray by pressing the CD eject button (the hardware button present on the drive). 2. Press the eject button and the CD is ejected normally 3. Close the CD tray again. 4. Run a command to read /dev/cdrom1 as: cat /dev/cdrom1 5. a) Now press the CD eject button. Nothing happens. b) If I use eject /dev/cdrom1, the CD is ejected fine. 6. a) If I skip step 5b and run ls /mnt/cdrom2 (/dev/cdrom1 is mounted on /mnt/cdrom2), then the CD files are listed just fine. b) After step 6a, if I press the CD eject button, it ejects normally. This strange behavior is 100% reproducible. It seems that every time the cat command is used, it prevents a manual hardware ejection of the CD. After cat, using another read command (like ls) that reads from the device, sets things right. Further investigation revealed that if I manually umount /mnt/cdrom2 then this problem disappears. If I manually re-mount /mnt/cdrom2, the problem reappears. Obviously, supermount is not handling it correctly since it is related to mounting. No error messages in dmesg or /var/log/* can be found that explains this odd behavior.
[Cooker] [Bug 2103] [kernel] supermount prevents CD ejection in mdk-9.0/mdk-9.1rc1
http://qa.mandrakesoft.com/show_bug.cgi?id=2103 --- Additional Comments From [EMAIL PROTECTED] 2003-02-27 09:41 --- hmm..strange. You did remount the drive I hope? Can you produce your /etc/fstab (with the noatime in there). d. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: Firstly, I am running kernel 2.4.19-24mdk (not 2.4.19-19mdk). I have all updates applied. I also have supermount and scsi-emulation enabled. I have two CD drives (hdc and hdd). The ejection problem is with /dev/cdrom1 (/dev/hdd). Here are the steps to reproduce the problem: 1. Put a CD in the drive and close the tray by pressing the CD eject button (the hardware button present on the drive). 2. Press the eject button and the CD is ejected normally 3. Close the CD tray again. 4. Run a command to read /dev/cdrom1 as: cat /dev/cdrom1 5. a) Now press the CD eject button. Nothing happens. b) If I use eject /dev/cdrom1, the CD is ejected fine. 6. a) If I skip step 5b and run ls /mnt/cdrom2 (/dev/cdrom1 is mounted on /mnt/cdrom2), then the CD files are listed just fine. b) After step 6a, if I press the CD eject button, it ejects normally. This strange behavior is 100% reproducible. It seems that every time the cat command is used, it prevents a manual hardware ejection of the CD. After cat, using another read command (like ls) that reads from the device, sets things right. Further investigation revealed that if I manually umount /mnt/cdrom2 then this problem disappears. If I manually re-mount /mnt/cdrom2, the problem reappears. Obviously, supermount is not handling it correctly since it is related to mounting. No error messages in dmesg or /var/log/* can be found that explains this odd behavior.
[Cooker] [Bug 2432] [mplayer] MPlayer makes a very choppy sound with oss and alsa9 drivers
http://qa.mandrakesoft.com/show_bug.cgi?id=2432 --- Additional Comments From [EMAIL PROTECTED] 2003-02-26 10:42 --- Perhaps you all are seeing different problems. I know there is a bug in the alsa version for the emu10k1 in one of the latest kernels, I send a fix to juan but I didn't check wether it is incorporated in revision 10. The bug caused the PCI bus being a bit overloaded when heavy video stuff was taking place. Resulting in a choppy sound. But it would only occur in snd-emu10k1. Try with an old kernel (before alsa rc7) to see if the problem goes away. d. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: MPlayer makes a very choppy sound with oss and alsa9 drivers (using -ao oss and -ao alsa9) when reading : - unencrypted DVD - decrypted vobs - avi files with mp3 audio stream The sound is very choppy (even more with alsa driver) and slows down the video as well. This does not occur when using the SDL audio driver (-ao sdl). This happens with the packaged mplayer and also with a compilation of MPlayer from the sources. Using OGLE DVD player, there is a similar problem : when playing DVD, the sound is choppy, but the video plays too fast. Howover, this does not occur with Xine when playing the exact same files, either with oss and alsa9 drivers.
[Cooker] [Bug 2103] [kernel] supermount prevents CD ejection in mdk-9.0/mdk-9.1rc1
http://qa.mandrakesoft.com/show_bug.cgi?id=2103 --- Additional Comments From [EMAIL PROTECTED] 2003-02-26 21:09 --- Ofcourse this is invalid, as you are not running cooker. However, I can reproduce it here. Can you try setting noatime in the mount options in /etc/fstab (after the --) and see if that helps? Danny --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: Firstly, I am running kernel 2.4.19-24mdk (not 2.4.19-19mdk). I have all updates applied. I also have supermount and scsi-emulation enabled. I have two CD drives (hdc and hdd). The ejection problem is with /dev/cdrom1 (/dev/hdd). Here are the steps to reproduce the problem: 1. Put a CD in the drive and close the tray by pressing the CD eject button (the hardware button present on the drive). 2. Press the eject button and the CD is ejected normally 3. Close the CD tray again. 4. Run a command to read /dev/cdrom1 as: cat /dev/cdrom1 5. a) Now press the CD eject button. Nothing happens. b) If I use eject /dev/cdrom1, the CD is ejected fine. 6. a) If I skip step 5b and run ls /mnt/cdrom2 (/dev/cdrom1 is mounted on /mnt/cdrom2), then the CD files are listed just fine. b) After step 6a, if I press the CD eject button, it ejects normally. This strange behavior is 100% reproducible. It seems that every time the cat command is used, it prevents a manual hardware ejection of the CD. After cat, using another read command (like ls) that reads from the device, sets things right. Further investigation revealed that if I manually umount /mnt/cdrom2 then this problem disappears. If I manually re-mount /mnt/cdrom2, the problem reappears. Obviously, supermount is not handling it correctly since it is related to mounting. No error messages in dmesg or /var/log/* can be found that explains this odd behavior.
[Cooker] [Bug 2044] [kdebase] fam prevent the CD drive from opening
http://qa.mandrakesoft.com/show_bug.cgi?id=2044 --- Additional Comments From [EMAIL PROTECTED] 2003-02-26 21:20 --- Hmm, Frederic, IIRC I talked about this before with Laurent. But isn't the easiest fix to change fam NOT to monitor certain dirs like /mnt/* (for floppies the problem is even worse, since the light stays on). Fam already contains the possibility to exclude nfs dirs, so adding this might be easier than wait for the KDE team to notice this. Also, it prevents any other app needing to be fixed because it uses fam. I'd say: fam is bugged. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: can't open the cd-rom drive [EMAIL PROTECTED] mnt]# lsof /mnt/cdrom COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME fam 2154a 139r DIR0,90 59392 /mnt/cdrom
