Fernando Pablo Lopez-Lezcano wrote: Hmm, it's actually pre10-ac2, there hasn't been an -ac3 yet :-) But to answer your question: yes, I've tried various other 2.4.20 prepatches, but I don't know exactly which ones. All of them had the lockup problem however. regards, Stefan

Fernando Pablo Lopez-Lezcano wrote: I've tried every kernel from 2.4.20-pre5 up to 2.4.20-pre10, and again 2.4.20-pre10-ac3, which caused a lockup on my system in the past, this afternoon. And I couldn't reproduce even _one_ lockup. I use another IDE interface though: a cmd649 add-on controller. The lockups happened with the onboard IDE interface (VIA KT333 chipset, vt8235 southbridge). For now I'm too lazy to open the computer case and try with the VIA interface to be sure, but... I can't think of another change to my system, so maybe that's the reason for the lockups. What IDE interface do you have? regards, Stefan -- ----> http://www.shockfrosted.org

To add one more datapoint to the thread and (apparently good news): I'm testing 2.4.20 (final) + lowlat + preempt + acpi + alsa + jack and the computer seems to be chugging along nicely. This is with today's alsa. A slighly older alsa did lock the computer after 5 or so minutes of jack activity but I managed to reboot it with the sysrq magic key. With the newest alsa I got jack + freqtweak + ams (with the demo patch) running for 50 minutes until for some reason jack died due to a watchdog interrupt. Not bad. -- Fernando

Not on the net at this point. I have been hand tweaking the originals to patch cleanly (trying to fix the failing chunks). I can email them to you, use at your own risk :-) BTW, results in my current tests are inconclusive, a couple of times I managed to freeze the machine soon after I started just jackd and qjackconnect. I'm currently trying to see if I can stat the stuff from the text console so that I can try to catch some register dumps through the sysrq magic key... -- Fernando

I don't have the time now to analyze the results but it would seem the problem is freqtweak in combination with jackd. When the system freezes after starting stuff from a text console, <alt>sysrq-p prints information about the current registers and the printout of repeated dumps only shows the jackd and freqtweak processes over and over again. Somehow they must be deadlocking. I'm hoping that typing all those numbers and parsing through ksymoops will show us exactly where things are hanging. So much fun. -- Fernando

It eventually did after I sent the message :-( Well, the machine keeps locking even with those patches. A sure way for me to kill it is to run jack, ardour, freqtweak, qjackconnect and a process doing "tar cvf usr.tar /usr" (in the home partition). Sometimes I cannot even start all the stuff and I don't get to the tar process, sometimes it takes a while to die. Adding some heavy disk activity to the mix seems to help kill it faster. But I've seen it die with just jack and ardour running. This is what I'm currently testing: 2.4.20 + capabilities + preempt + lowlat + [from Con Koliva's page] Read latency2 disk hack (Andrew Morton) + ACPI + variable HZ (1000) + [from an older jl patch] drm low latency + [from ext3 page] ext3 patches for 2.4.20 Same results on a quick test with 2.4.21-pre2. I built the icebox kernel debugger to try to get some info on where the program is hanging and this is what I get in terms of what's happening (four instances of breaking into the debugger with the Sysrq-d key), this is the list of tasks: 1) __switch_to +3e schedule +269 sleep_on +45 __mark_inode_dirty +d9 pipe_write +1b9 sys_write +9f system_call +33 2) sleep_on +6f bread +20 __mark_inode_dirty +d9 pipe_write +1b9 poll_freewait +44 sys_write +9f system_call +33 3) __wake_up +55 bread +20 __mark_inode_dirty +d9 pipe_write +1b9 poll_freewait +44 sys_write +9f system_call +33 4) schedule +1ab sleep_on +45 bread +20 __mark_inode_dirty +d9 pipe_write +1b9 poll_freewait +44 sys_write +9f system_call +33 So the system seems to be stuck in __mark_inode_dirty, whatever that is. Each time I break into the debugger I see one of the jack related processes as the current process. No other processes, so I assume the SCHED_FIFO ring is still running but everything else is being blocked by the mark_inode_dirty call. Any interested kernel hackers out there to help with this? Awaiting instructions... :-) -- Fernando

seems *damn* likely ... sorry to just be chiming in with a useless comment!

On Sat, 2003-01-04 at 01:49, Andrew Morton wrote: Last time I tried, this did not happen in 2.4.19 so I assumed it was a problem in 2.4.20 (boot into 2.4.19, no problems, boot into 2.4.20, lockups, same everything else). Other users have reported this as well (in 2.4.20 only AFAIK). Other users are using the exact same versions of jack and associated software under a 2.4.19 kernel intensively (through Planet CCRMA) and have not reported lockups. It could also be that 2.4.20 makes a race condition inside jack more likely, and exposes a bug in jack. I'll test again in 2.4.19 just to make sure I'm still seeing the same thing. Thanks for the help, I'll try out your suggestions and report back. -- Fernando

On Saturday 07 December 2002 03.58, Fernando Pablo Lopez-Lezcano wrote: I would be interested in trying your version of the patches. Please mail! :-) BTW, I applied the 2.4.19 LL patch to 2.4.20, and got a few rejects in the file system area, which I have not investigated further. (Seems to be a lot of changes around there...) Performance is "ok" under X and proc stress, but I get countless latencies in the whole range up to some 6-8 ms as soon as I start stressing the disk. (This is *with* DMA enabled, of course.) Haven't tried preempt yet. As to freezing, I've only managed to do that once - and IIRC, that was when trying to instantiate a synth in MusE while Ardour was running in the background. No useful info about what actually happened, and I haven't tested that combination any further. Are you certain your freeze is actually happening in kernel space? Tried using watchdog with "ping-pong" between highest and lowest priority SCHED_FIFO threads? (BTW, we should have a watchdog anyway, probably integrated with givertcap or something.) //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---