Jeremy Morse wrote: > Jared made some changes to video.c on the 14th Dec, but they don't > appear to contain anything dangerous; you could try without those > modifications though.
No, Jared's modification are indeed harmless. What I did in the last 24 hours was to compile kernels with the NetBSD source for each day from the 14th until the 20th of December. An hour ago I found out that the deadly modification occured between the 16th and the 17th. Some manually applied patches further I had it identified as Matt's usb_mem.c patch: http://mail-index.netbsd.org/source-changes/2010/12/15/msg015963.html I guess the problem is that he switched from malloc()/free() to kmem_zalloc()/kmem_free(). Maybe his changes are even correct and disclose a problem which we ever had but didn't notice? I don't know. Nevertheless, I removed his patch and was finally able to test your last patches. The result: video alloc 2 bufs enqueue 0xd57dee30 enqueue 0xd57dee48 video buf complete; frameno 1 EOF 1 egress 0xd57dee30 enqueue 0xd57dee30 video buf complete; frameno 0 EOF 1 egress 0xd57dee48 enqueue 0xd57dee48 video buf complete; frameno 1 EOF 1 egress 0xd57dee30 enqueue 0xd57dee30 video buf complete; frameno 0 EOF 1 egress 0xd57dee48 enqueue 0xd57dee48 video buf complete; frameno 1 EOF 1 egress 0xd57dee30 enqueue 0xd57dee30 video buf complete; frameno 0 EOF 1 egress 0xd57dee48 enqueue 0xd57dee48 video buf complete; frameno 1 EOF 1 egress 0xd57dee30 enqueue 0xd57dee30 video buf complete; frameno 0 EOF 1 egress 0xd57dee48 enqueue 0xd57dee48 video buf complete; frameno 1 EOF 1 [...] The mplayer-output looks exactly the same as before! Just a bit more flickering, because of the debugging output. So it is not ehci? > Do you know the PowerPC memory managment facilities at all? No, unfortunately not. I need to have a look into that some day, because of several problems I have to solve (currently in my amigappc port). But I try to avoid it as long as possible. ;) -- Frank Wille
