Hi all, Since changing to the 3.6.x series of RT_PREEMPT kernel (it was 2.6.33.x before) I have some strange issues with mounting/umounting/syncing of hard disk partitions. What I do is, I format a partition of the hard disk, I mount this partition, extract an tgz image (about 750 MB) into that freshly formatted partition and umount it again: mkfs.ext3 .... mount ... tar xf ... umount ... Doing the umount causes occasionally kernel panics (unable to handle kernel paging request... in ksoftirqd/0). When I add a "sync" before the umount, I never got the kernel panic. However, I can observe that the time needed for the "sync" varies dramatically. Very often it takes around 6-8 seconds, however sometimes it takes up to 53 seconds! Apart from the test script that performs this actions, the PC is idle. Kernel: 3.6.11.3-rt35, x86 (32 bit mode no PAE), 4 GB RAM, CPU core i7. Kernel boot parameters: root=/dev/sda6 vga=0x31a isolcpus=1-31 I have attached the kernel config and the result of the test output (script.log). Here is the script: --------------------------- BEGIN SCRIPT ----------------------- #!/bin/bash MNTDIR=/tmp/mnt.$$ mkdir -p $MNTDIR DEV=/dev/sda5 # This is a tgz file with 750MB FILE=/tmp/hugefile.tgz title() { echo "-----------------------" echo "$1" } mountCopy() { title "mount" time mount $DEV $MNTDIR title "sync 1" time sync ( cd $MNTDIR title "tar" time tar -xSzp --numeric-owner --atime-preserve -f $FILE ) title "sync 2" time sync title "umount" time umount $MNTDIR } main() { for (( i=0 ; i<20 ; i++ )) ; do echo "****** $i ******" title "mkfs" time mkfs.ext3 -q $DEV mountCopy done } main 2>&1 --------------------------- END SCRIPT ----------------------- The times needed for the sync before umount: grep -A 2 "sync 2" script.log| grep real real 0m6.672s real 0m52.831s real 0m7.522s real 0m8.543s real 0m8.394s real 0m6.160s real 0m11.234s real 0m51.943s real 0m6.527s real 0m53.752s real 0m7.045s real 0m9.985s real 0m7.907s real 0m47.593s real 0m8.086s real 0m6.806s real 0m8.433s real 0m8.490s real 0m8.424s real 0m47.382s Is there any possibility to avoid this long durations of the "sync"? Is there any kernel option that could somehow fix this? Any help is highly welcome! Thanks a lot. Best Regards Mathias
Attachment:
config.gz
Description: config.gz
Attachment:
script.log.gz
Description: script.log.gz