Hi, Sure. I've been testing 2.6.9-rc1-mm1-S3 SMP on a P4 HT SUSE 9.1 Pro box. In fact I've been struggling with the VP's ever since O3, while on SMP/HT. It hasn't been a pleasent experience, to say the least. My latest findings, S3 inclusive, goes something like this: - can only have it stable or even bootable if CONFIG_SCHED_SMT is not set. - systematic hardlocks when jackd -R is started while on softirq-preempt=1 and/or hardirq-preempt=1. - can't get to burn CD/DVDs at all, even with that scsi_ioctl.c command verification bypass. - can only pray while having the boot/init process reach the xdm login prompt successfully. More times than I find fair and enough, it simply dies on the beach, so to speak. And to make things worst, right after when this happens, some hardware components start behaving erratically. Only a (very) cold boot (i.e. extreme power down) seems to be the solution to this strange side-effect(s). OTOH just by rebooting on a stable vanilla kernel ends all this crappy annoyances ;) This all gets me feeling about the edge being fed up with this VP thing, even more when, quite ironically, this machine works fine let alone with a 2.6 vanilla SMP/HT preemptible kernel. Yeah, no xruns while running jackd -R -p 128 -n 2 ... (jack-0.99.0) Just some late-night thoughts... and please forgive me for being on the negative side this time ;) Gotta get to sleep now... -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

* Rui Nuno Capela <rncbc(a)rncbc.org> wrote: i tried to reproduce your problems before with no luck. I tried your .config on my dual P4/HT box. I am also testing the VP patchset on a dual Celeron, an 8-way Xeon, an on an AMD64 box. So it is something special to your setup. the initial question is whether the VP patchset is stable if you apply -S3 but disable all the following options: CONFIG_PREEMPT_VOLUNTARY CONFIG_PREEMPT_SOFTIRQS CONFIG_PREEMPT_HARDIRQS CONFIG_PREEMPT_BKL CONFIG_PREEMPT_TIMING CONFIG_LATENCY_TRACE this should give you a close to vanilla kernel. Then once you have established a 'known point of stability', could you enable the above options one by one (and keeping the previous options enabled) and see which one introduces the instability? My guess would be PREEMPT_HARDIRQS. to debug the hard-lockups, the most reliable way is to use nmi_watchdog=1 and a serial console to another box. It's quite painful to debug lockups without a serial console. Ingo

* Rui Nuno Capela <rncbc(a)rncbc.org> wrote: to set up serial logging: ------------------------- install a null modem cable to one of the serial ports of the server, connect the cable to another box, run a terminal program on that other box (e.g. "minicom -m" - do Alt-L to switch on logging after starting it up) and set up the server's kernel to do serial logging: enable CONFIG_SERIAL_8250_CONSOLE and CONFIG_SERIAL_CORE_CONSOLE, recompile & reinstall the kernel, add "console=ttyS0,38400 console=tty0" to your /etc/grub.conf or /etc/lilo.conf kernel boot line, reboot the server with the new kernel command line - and configure minicom to run with that speed (Alt-S). e.g. my /etc/grub.conf has: title test-2.6 (test-2.6) root (hd0,0) kernel /boot/bzImage root=/dev/sda1 console=ttyS0,38400 console=tty0 nmi_watchdog=1 kernel_preempt=1 if everything is set up correctly then you should see kernel messages showing up in the minicom session when you boot up. When the messages do not show up then typical errors are mismatch between the serial port (or speed) and the device names used - if it's COM2 then use ttyS1, and dont forget to set up the serial speed option of minicom, etc. You can test the serial connection by doing: echo x > /dev/ttyS0 and that should show up in the minicom session on the other box. to set up the NMI watchdog: --------------------------- add nmi_watchdog=1 to your boot parameters and reboot - that should be all to get it active. If all CPU's NMI count increases in /proc/interrupts then it's working fine. If the counts do not increase (or only one CPU increases it) then try nmi_watchdog=2 - this is another type of NMI that might work better. (Very rarely there are boxes that dont have reliable NMI counts with 1 and 2 either - but i dont think your box is one of those.) once the NMI watchdog is up and running it should catch all hard lockups and print backtraces to the serial console - even if you are within X while the lockup happens. You can test hard lockups by running the attached 'lockupcli' userspace code as root - it turns off interrupts and goes into an infinite loop => instant lockup. The NMI watchdog should notice this condition after a couple of seconds and should abort the task, printing a kernel trace as well. Your box should be back in working order after that point. now for the real lockup your box wont be 'fixed' by the NMI watchdog, it will likely stay locked up, but you should get messages on the serial console, giving us an idea where the kernel locked up and why. (Very rarely it happens that not even the NMI watchdog prints anything for a hard lockup - this is often the sign of hardware problems.) Ingo

* Rui Nuno Capela <rncbc(a)rncbc.org> wrote: ok, some progress: managed to reproduce the jackd instant lockup on my P4 HT SMP box. (hacked my kernel to ignore the second CPU's ACPI entries so that i got a single-physical-CPU HT setup. The box has the same i8x0 sound stuff as your box.) not much debug info yet, but it's not a classic hard lockup. It rather seems to be jackd (or the kernel) looping indefinitely. Keyboard doesnt work because it's threaded by default ... more later. Ingo

* Ingo Molnar <mingo(a)elte.hu> wrote: yeah, this was it. I fixed this bug in my tree and i'll release -S5 in a couple of minutes. Ingo