realtime-preempt patch-2.6.15-rt18 issues

["Rui Nuno Capela" <rncbc@rncbc.org>]

Hi, Ingo,

I think I would let you know that I'm still on 2.6.15-rt16, which works
great for the most purposes, on all of my boxes.

My problem is that the current/latest of the realtime-preempt patch,
2.6.15-rt18, has some showstoppers, at least for my day-to-day usage.

First one, and I think this is a return of an old buglet. Its the one that
occurs every time an usb-storage device is unplugged (e.g. a usb flash
stick). Once that happens, the usb subsystem gets seriously crippled.

Here goes a sample dmesg output of this occurrence (the complete listing
is attached, as is the corresponding kernel .config).

...
usb 2-1: new full speed USB device using ohci_hcd and address 2
Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
  Vendor: USB 2.0   Model: Flash Disk        Rev: 2.00
  Type:   Direct-Access                      ANSI SCSI revision: 02
SCSI device sda: 2031616 512-byte hdwr sectors (1040 MB)
sda: Write Protect is off
sda: Mode Sense: 0b 00 00 08
sda: assuming drive cache: write through
SCSI device sda: 2031616 512-byte hdwr sectors (1040 MB)
sda: Write Protect is off
sda: Mode Sense: 0b 00 00 08
sda: assuming drive cache: write through
 sda: sda1
sd 0:0:0:0: Attached scsi removable disk sda
usb-storage: device scan complete
usb 2-1: USB disconnect, address 2
slab error in kmem_cache_destroy(): cache `scsi_cmd_cache': Can't free all
objects
 [<c0144603>] kmem_cache_destroy+0x83/0xf8 (8)
 [<c020b1d6>] scsi_destroy_command_freelist+0x4e/0x5a (12)
 [<c020be67>] scsi_host_dev_release+0x4e/0x71 (12)
 [<c01f0fef>] device_release+0x14/0x39 (12)
 [<c01a2c9b>] kobject_cleanup+0x3e/0x5e (4)
 [<c01a2cbb>] kobject_release+0x0/0x8 (8)
 [<e05327ac>] usb_stor_control_thread+0x0/0x183 [usb_storage] (8)
 [<c01a3432>] kref_put+0x3a/0x44 (4)
 [<e053290e>] usb_stor_control_thread+0x162/0x183 [usb_storage] (12)
 [<c027a8a1>] schedule+0xd4/0xf5 (32)
 [<c01230df>] kthread+0x63/0x8f (20)
 [<c012307c>] kthread+0x0/0x8f (12)
 [<c0100d59>] kernel_thread_helper+0x5/0xb (16)


The second issue seems to be related to the RTC and is not strictly
specific to -rt18. AFAICT, my experience goes far as the ALSA MIDI
sequencer is concerned (snd-seq-midi) and it badly shows whenever the RTC
timer is used (snd-rtctimer), moreover if its used by default (i.e.
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y).

As it seems specific to -rt18, the ALSA sequencer event queueing is
perfectly non-functional if the RTC timer is used. On -rt16, and probably
before, the use of snd-rtctimer is suspiciously related to some complete
and instantaneous system lockups that I was experiencing more than many
times, while doing some MIDI sequencing; it always occurred almost exactly
on queue timer stop/start instants. Once I got rid of the rtctimer,
everything seems to get back to normal, that is, no hard-freezes to date.

My current configurations tries to avoid the RTC use in any circunstance.

So I think RTC is still an open issue, and it has indeed surfaced here and
there, specially regarding the RT patch usage in the Linux Audio/MIDI
niche.

Hope I can help in anyway.

Cheers,
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org

Attachment: dmesg-2.6.15.4-rt18.1.gz
Description: application/gzip-compressed

Attachment: config-2.6.15.4-rt18.1.gz
Description: application/gzip-compressed