> > The strange thing is that Ingo's patch to make cpu_clock() a NOP until > > after sched_init() didn't fix things for me... > Very strange. I threw in an output line counter into the printk code() ... if I > disable the timestamps for the first 30 lines, then everything is good (so the > basic timestamping code does still work on ia64). But I would have thought > that Ingo's delay until sched_init() ought to be long enough too. Clearly I > need to figure out exactly what needs to be initialized to prevent the > hang/crash. I guess sched_init() is too early... it does seem really strange to me, but I just double checked with Ingo's patch and it does indeed hang. The slow way to make progress is just to go through start_kernel() line-by-line and enable cpu_clock() at each stage, and see where it stops hanging. I'll give that a shot as a background process (my ia64 box takes quite a while to boot, so each test takes a long time but requires very little of my attention). --
| Ingo Molnar | [bug] block subsystem related crash with latest -git |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Adrian Bunk | Re: net/ipv4/fib_trie.c - compile error (Re: 2.6.23-rc3-mm1) |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| Jarek Poplawski | [PATCH take 2] pkt_sched: Protect gen estimators under est_lock. |
| David Miller | [GIT]: Networking |
| Natalie Protasevich | [BUG] New Kernel Bugs |
