The 'fubarage' of this package is such that it should require an affirmative effort to inflict it on users. Please consider removing it from all install lists except "Everything" and manual selection.
I concur. All you have to do to break it is to swap CDs without closing all gmc windows, on a SCSI CD-ROM. Just try swapping in Fisher SRPM cd after Fisher i386 CD #1 (with making sure that gmc initially opens a directory on the CD #1).
Can you give more details about what goes wrong with gmc and SCSI CD-ROMS? (I've seen a mention of dialog windows with "garbage" in them in another bug report.) [ We probably could swap things around, but I don't have any workstations with SCSI CD-ROMS immediately to hand. ] As for removing it from the "everything install", I think this would remove useful functionality from most desktop users for the sake of avoiding problems that 1% of the users (at most) hit. The problems I'm aware of are: - The kernel spews unnecessary stuff to the syslog at level debug. (#6006) The default Red Hat syslog configuration doesn't log these messages, but some users change their config and sees them. - A while ago, there were some reports of corruption when magicdev opened a cd-rw device while a disk was being written. I haven't seen any reports of this recently, so it's possible its been fixed in the kernel. - Some reports of magicdev keeping APM from powering down completely. - Some mentions of bad interactions with gmc and SCSI with magicdev installed. (I think this has nothing to do with magicdev, other than magicdev is telling MC that a CD has been inserted and it should open a new window.) I don't have enough information currently on this to know what is going on exactly. That's a fairly long list, but none of them will be seen by a large proportion of users, and except for the CD-RW one, they are more annoyances than fatal flaws.
Here is one thing that will be seen by everybody: Magicdev spews 1 Hertz junk into "dmesg" ... rendering any content of dmesg totally useless. This will make it difficult if not impossible to support users out there, because critically useful information is rapidly discarded. I consider this specific issue to be a "fatal flaw."
On my system magicdev never unmounts a CD it mounted, even if it is not in use and a manual umount works. So unless I manually umount each CD before I eject it, I get VFS errors, because a mounted volume was changed. I have an ATAPI CDROM, but I don't think it's relevant.
From testers list Chris Runge > SCSI appears to be fine. However, I noticed that I get a ton of messages in > /var/log/messages and to the root console when I go into GNOME and the SCSI > CD-ROM doesn't have a disc in it. These end when I exit GNOME. Any ideas?
- The 1hz (or, actually, 2hz) junk to dmesg (#6006) is very much fixable by commenting out the message in the kernel, and we'll put that or some other fix in. - The problem with being able to eject mounted volumes has been fixed. (#13628) - The problem with (some?) SCSI devices generating excess spew (#26055) needs further investigation, and seems to have to do with devices not correctly reporting whether they have a disk in the drive.
On 8 Feb 2001, Owen Taylor wrote: > Not at all to blame you for this - magicdev probably _isn't_ > something you need. > <snip> > [For the newbie] first > confronted with Linux, the functions provided by magicdev - > automounting, opening a file manager window, prompting for the autorun > script, etc, really do make things significantly simpler. And so, Owen, you concur in my case ... that the RFE is correct; to remove it from the default Workstation install state; and place it only in the "Everything" install (again a 'Newbie' mistake which "really does make things significantly simpler" -- at the expense of security, conformance to the principle of Least Surprise, system log chatter, and the rest.) Packagers: Bugzilla assigned it to Owen, for he is the lead package maintainer ... and if and when it is 'ready for prime time,' it may return to being part of a Workstation default install -- but for RH 7.1, just as the newbie friendly 'joe' editor requires express selection in (since at least RH 5.0), so also should magicdev.
The other issue is that most folks who want to use CD burners, switching to the next disk becomes a pain -- if you can even get magicdev to let go of the drive. Sun had a volume manager that you could at least manually tell "go check the drive & mount it if possible", though they didn't really have a good solution to the CD burner crowd (i.e., leave yer grubby paws off that device, dammit).
From terstes list Subject: Re: scp slows to a crawl if magicdev is running Sam Varshavchik <mrsam> writes: > On Sat, 24 Feb 2001, Marty Shannon, RHCE wrote: > > > open("/dev/cdrom", O_RDONLY|O_NONBLOCK) = 9 > > ioctl(9, CDROM_DRIVE_STATUS, 0x7fffffff) = 2 > > close(9) = 0 > > Oh, so THAT'S why this bleeping thing keeps filling my syslog with this: > > Feb 24 17:31:08 localhost kernel: Device not ready. Make sure there is a > disc in the drive. > Feb 24 17:31:40 localhost last message repeated 16 times > Feb 24 17:32:41 localhost last message repeated 30 times > Feb 24 17:33:43 localhost last message repeated 31 times
Date: Sun, 04 Mar 2001 14:26:47 -0500 From: Chris Runge <crunge> Reply-To: testers-list To: testers-list Subject: Re: RC2: mouse slow when CD playing R P Herrold wrote: > On Sun, 4 Mar 2001, Chris Runge wrote: > >> Anyone notice this problem: On RC2 if I play a CD under X the mouse >> jitters a lot (this is using the built-in GNOME CD player). If I play >> the CD under cdp in a console session on another vt, however, I have no >> such problems with the mouse under X. > > > What does dmesg say? > I realize this isn't very scientific, but after doing the following the problem doesn't occur: (1) rpm -e magicdev (2) recompile kernel, changing taq command queuing depth (i think that is what it is) to 32 (from 253) for the new aic7xxx driver (and changing /etc/modules.conf appropriately) (3) reboot using new kernel dmesg says this: Attached scsi CD-ROM sr0 at scsi1, channel 0, id 3, lun 0 (scsi1:A:3): 40.000MB/s transfers (20.000MHz, offset 15, 16bit) sr0: scsi-1 drive Uniform CD-ROM driver Revision: 3.12 sr0: CDROM (ioctl) reports ILLEGAL REQUEST. sr0: CDROM (ioctl) reports ILLEGAL REQUEST. This is with it working, but I saw similar output before when the problem was occurring.
Magicdev impairs cdrecord bug added: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=34433
Events have overtaken this bug -- closing