I recently put together a new system with a MSI P35 PLATINUM and although
reading from data CDs, DVDs, and watching DVD movies is working fine, DVD
burning isn't. MSI's manual says "1 IDE port by Marvell 88SE6111", but
lspci says it's a 88SE6121. I have two DVD burners, a SONY DRU-510A and
a DRU-820A. They were both working fine with TDK DVD+R media on my ASUS
K8V SE DELUXE (VIA IDE controller) prior to the upgrade.
Here's what I see with dvd+rw-tools version 7.0-9:
sh# growisofs -dvd-compat -speed=2.4 -Z /dev/dvd -rJ -joliet-long -quiet "burn"
Executing 'genisoimage -rJ -joliet-long -quiet burn | builtin_dd of=/dev/dvd obs=32k seek=0'
/dev/dvd: flushing cache
And from cdrecord version 1.1.6-1:
sh# mkisofs -rJ -joliet-long -quiet "burn" | cdrecord -v dev=/dev/dvd -
wodim: No write mode specified.
wodim: Asuming -tao mode.
wodim: Future versions of wodim may have different drive dependent defaults.
TOC Type: 1 = CD-ROM
scsibus: -2 target: -2 lun: -2
Linux sg driver version: 3.5.27
Wodim version: 1.1.6
SCSI buffer size: 64512
Device type : Removable CD-ROM
Version : 5
Response Format: 2
Vendor_info : 'SONY '
Identification : 'DVD RW DRU-820A '
Revision : '1.0c'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Current: 0x0009 (CD-R)
Profile: 0x002B (DVD+R/DL)
Profile: 0x001B (DVD+R)
Profile: 0x001A (DVD+RW)
Profile: 0x0016 (DVD-R/DL layer jump recording)
Profile: 0x0015 (DVD-R/DL sequential recording)
Profile: 0x0014 (DVD-RW sequential recording)
Profile: 0x0013 (DVD-RW restricted overwrite)
Profile: 0x0012 (DVD-RAM)
Profile: 0x0011 (DVD-R sequential recording)
Profile: 0x0010 (DVD-ROM)
Profile: 0x000A (CD-RW)
Profile: 0x0009 (CD-R) (current)
Profile: 0x0008 (CD-ROM)
Profile: 0x0002 (Removable disk)
Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
Driver flags : MMC-3 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
On Sat, 2 Feb 2008 16:30:04 -0600
(this is 2.6.24)
If nothing happens with this report in the next few days, please create an
entry at bugzilla.kernel.org so we can keep an eye on it, thanks.
Trying older kernels might be interesting, find out if it's a regression or
126.96.36.199 shows the same problems and 2.6.22 doesn't see the controller.
It looks like most of the changes happened betwen it's introduction in
2.6.20 (v0.1.1) and 2.6.22 (v0.1.4), with some minor updates for internal
changes after that...