Kernel failure while writing DVD-RAM

[Dave Higton]

On Sat 2009-11-14, Gilboa Davara wrote:

> On Thu, 2009-11-12 at 16:10 +0000, Dave Higton wrote:
> > I'm testing DVD-RAM writing and reading for reliability 
> under Fedoras 10
> > and 5.  While writing some files under F10 this afternoon, 
> there was a
> > kernel failure.  Details below:
> > 
> > WARNING: at fs/buffer.c:1186 mark_buffer_dirty+0x27/0x79() 
> (Not tainted)
> > Hardware name: OptiPlex 755                 
> > Modules linked in: udf crc_itu_t fuse i915 drm bridge stp 
> bnep sco l2cap
> > bluetooth sunrpc nf_conntrack_netbios_ns nf_conntrack_ftp 
> ip6t_REJECT
> > nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand
> > acpi_cpufreq dm_multipath uinput snd_hda_intel 
> snd_seq_dummy snd_seq_oss
> > snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss
> > snd_pcm snd_timer snd_page_alloc snd_hwdep ata_generic i2c_i801 snd
> > ppdev i2c_core iTCO_wdt iTCO_vendor_support parport_pc pata_acpi
> > serio_raw dcdbas soundcore pcspkr parport e1000e e1000 joydev [last
> > unloaded: microcode]
> > Pid: 12876, comm: fillDVD2 Not tainted 
> 2.6.27.37-170.2.104.fc10.i686 #1
> >  [<c042ddfb>] warn_on_slowpath+0x65/0x8b
> >  [<c04228dc>] ? __enqueue_entity+0xe3/0xeb
> >  [<c0424346>] ? enqueue_entity+0x203/0x20b
> >  [<c06abe09>] ? _spin_lock+0x8/0xb
> >  [<c0495510>] ? inode_sub_bytes+0x69/0x71
> >  [<c04afeef>] mark_buffer_dirty+0x27/0x79
> >  [<f8ea4cb3>] udf_bitmap_free_blocks+0xf8/0x12e [udf]
> >  [<f8ea51ba>] udf_free_blocks+0x62/0x8c [udf]
> >  [<f8eae3f1>] extent_trunc+0xe5/0xf0 [udf]
> >  [<f8eae88a>] udf_discard_prealloc+0xce/0x17b [udf]
> >  [<f8ea5844>] udf_release_file+0x18/0x22 [udf]
> >  [<c04939ad>] __fput+0xad/0x13d
> >  [<c0493a54>] fput+0x17/0x19
> >  [<c04912e7>] filp_close+0x50/0x5a
> >  [<c0491363>] sys_close+0x72/0xb1
> >  [<c0404c8a>] syscall_call+0x7/0xb
> >  =======================
> > ---[ end trace d4c5a1d53380a8a7 ]---
> > 
> > This is a standard installation from a Fedora 10 DVD, whose 
> image was
> > taken from the web.
> > 
> > Other than "yup, it's broken", does the above trace mean anything to
> > anyone, and is there anything I can do to make it work 
> reliably or even
> > to diagnose it further?
> > 
> > fillDVD2 is my app, written in C, which simply writes 
> sequential files
> > of 1 MB each to the DVD on /dev/sr0.  I can post the source 
> if anyone
> > wants to see it.
> > 
> > Looking further ahead, the aim was to try to fix writing 
> DVD-RAM under
> > Fedora 5.  We know this is broken, and I was hoping to 
> back-port the F10
> > code to F5.  Up to now, we had only observed failures under 
> F5, never
> > F10 - this is the first.  The failures were entirely 
> different: F5 would
> > occasionally fail to write beyond 4 GB, and would consistently write
> > DVD-RAMs that showed allocation errors when examined by the Philips
> > udf_test application.  F10 has never exhibited either of 
> those failures.
> > F5 has never shown an oops.  Now it seems I can no longer 
> rely on the
> > F10 UDF code either.
> > 
> > Dave
> > 
> 
> Dave,
> 
> This doesn't look like an oops. This is a simple WARN_ON (or actually,
> in this case, warn_slowpath).

OK.  I've just been Googling for warn_slowpath, but although I've
found lots of examples, I don't know what it means.  My guess is
that it's used as a diagnostic by some code, probably kernel code,
so the next challenge is to find where it was called from.  Yes?

> Are you getting a real crash or some kind of failure.

More information since my original posting: fillDVD2 is a test app
that I wrote as part of an effort to test the ability of Fedora to
write DVD-RAM discs.  We have experienced numerous failures, but
we don't yet understand why.

fillDVD2 wasn't testing for errors.  An error occurred somewhere,
but fillDVD2 carried on trying to write to the DVD-RAM disc.  This
doesn't work; once DVD-RAM writing has failed, no subsequent
attempts will succeed.  The disc has to be ejected.

I revised fillDVD2 to stop on an error.  A subsequent test showed
that the first error, at a similar point (when the disc was within
a few hundred MB of getting full), was "I/O error".  Not very
meaningful to me.

> Can you please post:
> A. Kernel version.

uname -a says:
2.6.27.38-170.2.113.fc10.i686 #1 SMP Wed Nov 4 17:55:39 EST 2009
i686 i686 i386 GNULinux

> B. Serial port output. (Should capture the actual OOPs)

I don't have anything connected to the serial port - it never
occurred to me to do so.  I'll see what I can do.

> Beyond that, F10 is nearing EOL. I'd suggest you hurry up and 
> file a bug
> report before it dies. Maybe the Fedora kernel guys will fix 
> in the last
> F10 update. (I'd also include the fillDVD code in the bug report.)

OK.

> As for back-porting fixes from F10 to F5, I'd consider switching to
> CentOS/RHEL 5.4 instead, and back porting only the important stuff you
> really (really) need from F10.

We originally wanted to use CentOS but were never able to solve
a real-time problem it gave us: we need to service interrupts from
our cards every 32 ms.  Normally the IRQ is active for no more than
8 us before it's serviced; under CentOS this would often exceed 20 ms
and we would lose data.

> P.S. Are you by any chance related to Nice U.K?

Yes!  You were; I take it you've now left?

> If so, please say "Hello" to Russ.

Russ says "Hello" to you!  Russ and I are working on the same project.

Dave


NICE CTI Systems UK Limited ("NICE") is registered in England under company number, 3403044. The registered office of NICE is at Tollbar Way, Hedge End, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.