Exactly what CD burner do you have?  What's in /proc/scsi/scsi?

Contents of /proc/scsi/scsi:

Attached devices:
Host:  scsi0   Channel:  00  Id:  06 Lun: 00
      Vendor: HP        Model:  C1750A                   Rev: 3125
       Type: Processor                                             ANSI SCSI
revision: 01
Host: scsi1     Channel: 00 Id: 00   Lun: 00            
       Vendor RICOH   Model: CD-R/RW  MP7083A   Rev: 1.10
        Type:   CD-ROM                                           ANSI SCSI
revision: 02

Note: That the burner and software worked great under RH 7.0 and under the
original ISO download of Wolverine. It's only after the updates to the beta that
the problem has been occuring.

Kernel problem.

If you put 'options scsi_mod max_scsi_luns=1' in /etc/modules.conf and reboot, 
does the problem persist?

Yes, the problem persists -- no difference

Okay, and if you downgrade to the Wolverine kernel it works?

I haven't downgraded the kernel yet. But before I upgraded from 2.4.1.-- to
2.4.2.-- it worked fine. I can try downgrading later today to confirm but it
will be 5 or 6 hours before I can do that.

I downgraded the kernel from 2.4.2-0.1.28 to 2.4.2 rebooted and the burner
worked fine.  I don't have 2.4.2-0.1.25 on my system anymore to test that kernel
but:

the proc/scsi/scsi file changed between the 2 kernels (no other changes were
made to the system other than loading in the different kernel).

proc/scsi/scsi contents under error conditions of 2.4.2-0.1.28
Host: scsi0 Channel: 00 Id: 06 Lun: 00
		Vender HP  Model: C1750A
        Type: Processor       ANSI SCSI revision: 01
Host: scsi1 Channel: 00 ID: 00 Lun: 00
      Vendor: RICOH Model: CD-R/RW MP7083A Rev: 1.10
        Type CD-ROM                  ANSI SCSI revision: 02

proce/scsi/scsi under kernel 2.4.2 which works correctly
Host: scsi0 Channel: 00 ID: 00 Lun:00
        Vendor RICOH Model: CD-R/RW MP7083A revision 1.10
        Type CD-ROm                  ANSI SCSI revision: 02
Host: scsi1 Channel: 00 ID: 06 Lun:00
        Vendor HP       Model: c1750A    Rev: 3125
         Type Processor                  ANSI SCSI revision: 01

So in summary under 2.4.2-0.1.28 the cd-writer is on [1,0] and under 2.4.2 is
under [0,0] and the scanner is on [0,6] under 2.4.2-0.1.28 and on [1,6] under 2.4.2

Could you please show us the output of /sbin/lsmod?

OK, the contents are below but please be advised that with the download and
install of the latest beta updates (April 6, 2001) that the problem reported in
this bugzilla has disappeared.

Here's the output you requested.

Module                  Size  Used by
ide-cd                 26848   0  (autoclean)
cdrom                  27232   0  (autoclean) [ide-cd]
ipt_MASQUERADE          1712   1  (autoclean)
iptable_nat            16160   0  [ipt_MASQUERADE]
ip_conntrack           15824   1  [ipt_MASQUERADE iptable_nat]
ip_tables              11072   4  [ipt_MASQUERADE iptable_nat]
autofs                 11264   1  (autoclean)
de4x5                  41840   1  (autoclean)
via-rhine              10912   1  (autoclean)
usb-uhci               20624   0  (unused)
usbcore                49664   1  [usb-uhci]
aic7xxx               136080   0  (unused)
sd_mod                 11680   0  (unused)
scsi_mod               95008   2  [aic7xxx sd_mod]

Well..... you make it very hard to close this as fixed ;)

Well it was resovled until updating my system to the latest updates of wolverine
prior to seawolfs release.

Now the same identical problems are back -- machine totally hangs and have to do
a cold restart. Detected when trying to burn iso images for seawolf.

May be able to install iso images from harddrive and then test but bug is back.

Please confirm if this still happening in seawolf

This problem still exists in seawolf --- exactly as described above.

I can burn the cd-s under 2.4.2 but not on wolverine or seawolf.

Perhaps this problem is directly related to bugzilla 29266.

The scsi setups in proc/scsi/scsi are different under 2.4.2 and the various
wolverine and seawolf versions as documented in the bugzillas.

I've also created a number of CD coasters using cdrecord directly under the
stock RedHat 7.1 2.4.2-2smp kernel. Exactly as above, cdrecord actually starts
burning tracks and, at apparently random points in the creation of the CD, the
whole system locks up _ no keyboard, mouse or network access, CTRL-ALT-DEL has
no effect, only a hard reset works.

I've even gone so far as to kill autorun under KDE, and the problem persists. It
appears under KDE, Gnome and even Failsafe (i.e., twm). Years ago, a similar
problem occurred when using an ATAPI Travan tape drive using the ide driver of
Gadi Oxman: There was a sinister interaction between it and the smp code in the
kernel, but Gadi fixed that trouble some years ago. Could a related problem have
crept back in? As I recall, it had something to do with spin locks, but, then
again, no one should trust my memory anymore; I know that I don't :)

With the latest kernel update from RedHat, the same problem arises as described
above.

However, at least an unsatisfying workaround exists: Rebooting the system using
the uni-processor kernel allowed me to burn a pair of good CDs. So, it seems to
be some interaction between the multi-processing code and the IDE-SCSI driver.
Again, as mentioned above, perhaps Gadi Oxman might be able to shed some light
on this problem.

I have the exact same problem.  I am using the 2.4.2-2 kernel, and with a 200Mhz
Compaq deskpro pentium.  Previously, using the 2.2 kernel and redhat 7.0 I was
able to burn CDs without any problem.
My /proc/scsi/scsi is a bit simpler:

Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: RICOH    Model: CD-R/RW MP7083A  Rev: 1.10
  Type:   CD-ROM                           ANSI SCSI revision: 02
~

In addition, I have found that the same hang occurs just trying to make an image
of an existing CD using the command:

dd if=/dev/scd0 of=cdimage

Hope that brings you a bit closer to the solution.

I have the same exact problem now as I did with SeaWolf -- I orginially reported
this bug.

Xcdroast and CDToaster both work fine on audio tracts -- doesn't hang the systems.

But when trying to burn an ISO image (such as Roswell) or data files or
directories, the programs will start to initialize to burn the disk and then
totally hang the entire machine.  Must press the harware reset button to restart.

This bug was first reported on March 28, close to six months ago, and there
seems to have been
no solution found. Is anyone working on this? I have just built the 2.4.9 kernel
in both SMP and
uniprocessor forms, and still I have the same problem with or without the
"-debug" command line
switch to cdrecord: The diagnostics show the tracks starting to be processed,
but after anywhere
from just two or three up to more than a hundred, the system hangs in a
progressively worse
manner, leaving nothing in the /var/log/messages file. First the CD burner laser
activity light goes
out, leaving only the disc activity light blinking. Second, no commands from the
keyboard have any
effect. (Before starting the cdrecord, I opened a second xterm and typed in
"reboot" without a
carriage return. When the CD burner seemed to hang along with the track updating
diagnostics of
cdrecord, I then pressed the return key, which was echoed in the xterm, but
nothing happened
except that the freeze continued.) Third, the mouse stays active, allowing me to
raise and lower
multiple windows for a short time (several seconds), although the keyboard is
dead. Fourth, the
mouse stops responding. At that point, I need to press the reset button and go
through the tedium
of watching an fsck occur after the reboot, since the system was not shut down
gracefully.

  As others have said before, I had no problem burning CDs under RedHat 7.0, but
I have had
nothing but heartache since installing SeaWolf.

  Is anyone listening?

Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/