Re: [Fdutils] DMA cache consistency bug introduced in 2.6.28 (Was: Re: Cannot format floppies under kernel 2.6.*?)

[Linus Torvalds <torvalds@linux-foundation.org>]

On Wed, 23 Dec 2009, Mark Hounschell wrote:
> > 
> > Hmm. Looks like hpet2 is still getting used instead of local APIC 
> > timer in .28 case.
> > 
> > I was expecting some low number in hpet2 and local timer on all CPU to 
> > be around the same value. Above shows CPU 0 is depending on hpet2 for 
> > some reason even with idle=halt. Can you send the output of below two 
> > in case of .28 /proc/timer_list
> 
> Attached.

Oh wow.

That's crazy:

	Tick Device: mode:     1
	Per CPU device: 0
	Clock Event Device: hpet2
	 max_delta_ns:   2147483647
	 min_delta_ns:   5000
	 mult:           61510047
	 shift:          32
	 mode:           3
	 next_event:     123991000000 nsecs
	 set_next_event: hpet_msi_next_event
	 set_mode:       hpet_msi_set_mode
	 event_handler:  hrtimer_interrupt
	
	Tick Device: mode:     1
	Per CPU device: 1
	Clock Event Device: lapic
	 max_delta_ns:   670831998
	 min_delta_ns:   1199
	 mult:           53707624
	 shift:          32
	 mode:           3
	 next_event:     123991125000 nsecs
	 set_next_event: lapic_next_event
	 set_mode:       lapic_timer_setup
	 event_handler:  hrtimer_interrupt

	...

It's not using the lapic for CPU0. 

Using the HPET as a per-cpu timer is some crazy sh*t, since it's pretty 
expensive to reprogram (compared to the local apic). And having different 
timers for different CPU's is just odd.

The fact that the timer subsystem can do this and it all (mostly) works at 
all is nice and impressive, but doesn't make it any less crazy ;)

That said, none of this seems to explain why DMA/fdformat doesn't work.

			Linus