PROBLEM: tickless scheduling
in [Kernel]
|
Prev: staging: hv: Optimize adj_guesttime function and add more detailed comments
Next: s3c-fb: added patch series for s5pv210 and some features.
From: Donald Allen on 10 May 2010 20:20 1. Network file transfers and fscks stop on Toshiba netbook unless system receives external events 2. I have a new Toshiba NB305 on which I installed the beta release of Slackware 13.1, which provides a 2.6.33.3 kernel with the tickless option enabled. With this machine on my ethernet, I attempted to rsync my home directory to it, about 9 Gb, from a workstation that is my primary system (running Slackware 13). The transfer proceeded normally for awhile and then stopped, which I could see in the xterm on the workstation. I went to the netbook to see what was going on there and when I began typing, the transfer resumed. I ran 'top' on the netbook and it would freeze after a few updates, coinciding with the file transfer pausing again. Typing would get things moving. At another point, I tested pm-suspend on the netbook. Suspending worked, but awakening did not, so I had to power-cycle the machine. I use ext2 for reasons which I won't attempt to justify here, so when the machine came back up, it fsck'ed the root filesystem. Here again I saw things grind to a halt -- the progress meter stopped and the there was no disk activity. But if I moved my finger on the touchpad, things would get moving again. The only way to get the fsck to complete was to constantly be tickling the touchpad. I corresponded with Patrick Volkerding, telling him I suspected a scheduling problem and he informed me that the 13.1 kernel had tickless enabled, unlike 13. So I built a 2.6.33.3 kernel (from the Slackware-supplied kernel sources) with tickless disabled. With that kernel running, I power-cycled the machine to force a fsck of the root filesystem. This one proceeded to completion normally -- no external stimuli needed. 3. Tickless, scheduler 4. 2.6.33.3 7.1 ver_linux output attached 7.2 /proc/cpuinfo attached 7.3 /proc/modules attached 7.4 /proc/ioports, /proc/iomem attached 7.5 lspci attached 7.6 /proc/scsi/scsi attached
From: Robert Hancock on 10 May 2010 20:30 On 05/10/2010 06:18 PM, Donald Allen wrote: > 1. Network file transfers and fscks stop on Toshiba netbook unless > system receives external events > 2. I have a new Toshiba NB305 on which I installed the beta release of > Slackware 13.1, which provides a 2.6.33.3 kernel with the tickless > option enabled. With this machine on my ethernet, I attempted to rsync > my home directory to it, about 9 Gb, from a workstation that is my > primary system (running Slackware 13). The transfer proceeded normally > for awhile and then stopped, which I could see in the xterm on the > workstation. I went to the netbook to see what was going on there and > when I began typing, the transfer resumed. I ran 'top' on the netbook > and it would freeze after a few updates, coinciding with the file > transfer pausing again. Typing would get things moving. At another > point, I tested pm-suspend on the netbook. Suspending worked, but > awakening did not, so I had to power-cycle the machine. I use ext2 for > reasons which I won't attempt to justify here, so when the machine > came back up, it fsck'ed the root filesystem. Here again I saw things > grind to a halt -- the progress meter stopped and the there was no > disk activity. But if I moved my finger on the touchpad, things would > get moving again. The only way to get the fsck to complete was to > constantly be tickling the touchpad. I corresponded with Patrick > Volkerding, telling him I suspected a scheduling problem and he > informed me that the 13.1 kernel had tickless enabled, unlike 13. So I > built a 2.6.33.3 kernel (from the Slackware-supplied kernel sources) > with tickless disabled. With that kernel running, I power-cycled the > machine to force a fsck of the root filesystem. This one proceeded to > completion normally -- no external stimuli needed. > 3. Tickless, scheduler > 4. 2.6.33.3 > 7.1 ver_linux output attached > 7.2 /proc/cpuinfo attached > 7.3 /proc/modules attached > 7.4 /proc/ioports, /proc/iomem attached > 7.5 lspci attached > 7.6 /proc/scsi/scsi attached Can you post dmesg output from bootup? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Robert Hancock on 10 May 2010 20:40 On 05/10/2010 06:34 PM, Donald Allen wrote: > On Mon, May 10, 2010 at 8:27 PM, Robert Hancock<hancockrwd(a)gmail.com> wrote: >> On 05/10/2010 06:18 PM, Donald Allen wrote: >>> > >> >> Can you post dmesg output from bootup? > > See attached. > > /Don Allen >> I don't see anything too abnormal, except this: ACPI: NR_CPUS/possible_cpus limit of 1 reached. Processor 1/0x1 ignored. I assume your kernel is compiled without SMP support, but you have an Atom CPU that supports hyperthreading. I don't know if it's related but you could try fixing that and see if it changes anything. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Donald Allen on 10 May 2010 20:40 On Mon, May 10, 2010 at 8:27 PM, Robert Hancock <hancockrwd(a)gmail.com> wrote: > On 05/10/2010 06:18 PM, Donald Allen wrote: >> > > Can you post dmesg output from bootup? See attached. /Don Allen >
From: Donald Allen on 10 May 2010 21:00
On Mon, May 10, 2010 at 8:38 PM, Robert Hancock <hancockrwd(a)gmail.com> wrote: > On 05/10/2010 06:34 PM, Donald Allen wrote: >> >> On Mon, May 10, 2010 at 8:27 PM, Robert Hancock<hancockrwd(a)gmail.com> >> �wrote: >>> >>> On 05/10/2010 06:18 PM, Donald Allen wrote: >>>> >> >>> >>> Can you post dmesg output from bootup? >> >> See attached. >> >> /Don Allen >>> > > I don't see anything too abnormal, except this: > > ACPI: NR_CPUS/possible_cpus limit of 1 reached. �Processor 1/0x1 ignored. > > I assume your kernel is compiled without SMP support, but you have an Atom > CPU that supports hyperthreading. I don't know if it's related but you could > try fixing that and see if it changes anything. The dmesg (and all other data I supplied) is from the system running with the custom kernel I built, which has tickless disabled and does not fail in the way described in the report. So, to be clear, the dmesg is not from the failing kernel. Unfortunately, it was only after I'd installed the non-tickless kernel that I was pretty certain of what was happening and therefore in a position to file a bug report. Thanks for pointing out the non-smp bug. I'll fix and rebuild my kernel, but that is not relevant to the tickless issue. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |