Re: Calibration issues with USB disc present.

[Greg KH]

On Mon, Nov 14, 2005 at 10:56:05AM -0800, George Anzinger wrote:
> Greg KH wrote:
> >On Sat, Nov 12, 2005 at 08:06:37AM -0800, George Anzinger wrote:
> >
> >>Greg KH wrote:
> >>
> >>>On Fri, Nov 11, 2005 at 01:57:07PM -0800, john stultz wrote:
> >>>
> >>>
> >>>>On Fri, 2005-11-11 at 13:37 -0800, George Anzinger wrote:
> >>>>
> >>>>
> >>>>>John,
> >>>>>
> >>>>>Have you run into this.  One of the USB disc controllers has the 
> >>>>>ability to boot the system, however, it needs SMM code to do this.  
> >>>>>This SMM code, somehow, causes SMI interrupts (which are higher 
> >>>>>priority than NMI interrutps and not maskable) which it needs to do 
> >>>>>its thing.
> >>>>>
> >>>>>Problem is that if one of these occurs while calibrating the TSC or 
> >>>>>the delay code, it can cause a wrong result.  We have seen both a too 
> >>>>>long and a too short result (depending on where the interrut happens).
> >>>>>
> >>>>>They have found the root cause of TSC calibration problem.
> >>>>>Now they ask for the fix or workaround.
> >>>>>
> >>>>>That is the BIOS is periodically interrupted by USB controller and the 
> >>>>>CPU
> >>>>>waits during the processing of these interrupts.
> >>>>>Their experiments say the interrupt interval is 260mSec and the BIOS 
> >>>>>needs
> >>>>>150uSec - 200uSec for processing.
> >>>>>It is proved that the problem doesn't reproduce by masking such SMI in 
> >>>>>BIOS.
> >>>>>They say SMI is for BIOS emulation for connecting legacy devices to 
> >>>>>USB.
> >>>>>Without such an emulation it's impossible to boot from USB-FD for 
> >>>>>instance,
> >>>>>they say too.
> >>>>
> >>>>Hmmm. I haven't heard of this issue specifically, but yes, I'm quite
> >>>>familiar with the pain BIOS SMIs can cause and I'm not surprised that it
> >>>>would affect the TSC/delay calibration code.
> >>>>
> >>>>Is this still an issue w/ 2.6.14? I know the new TSC based delay
> >>>>calibration code is supposed to be SMI resilient, but I haven't really
> >>>>played with it closely.
> >>>>
> >>>>Not sure what the best method to move forward would be. I suspect
> >>>>disabling the SMI code early in boot (I thought the usb legacy handoff
> >>>>stuff already did this?) would help. Then the actual Linux USB drivers
> >>>>can take over before we switch from the initrd to the root filesystem.
> >>>>
> >>>>Greg, do you have a suggestion?
> >>>
> >>>
> >>>I only ever saw this when people forgot to load the USB drivers.  Once
> >>>the kernel took over USB support, there was no problem (if there was,
> >>>that's a BIOS bug.)  The handoff code in 2.6.14 should help a lot with
> >>>this too.
> >>>
> >>
> >>Ah... are you saying that the USB support code stops the SMM/SMI prior to 
> >>the TSC & delay calibration?  Also, this problem was noted in a 2.4.20 
> >>kernel.  Any help there?
> >
> >
> >I do not know where in the boot process the TSC and delay calibration is
> >done.  If it happens before the PCI bus is probed, then no, it does not
> >happen before this.
> 
> My guess is that the PCI bus code would like to use delay() so I rather 
> think it is calibrated prior to this :(
> >
> >On these boxes, I'd just recommend disabling USB legacy support
> >completly, if possible.  And then complain loudly to the vendor to fix
> >their BIOS.
> 
> But if one is booting from that device...

Booting from a USB device?  I can see this happening when installing a
distro, and you boot from the USB cdrom, but not for "normal"
operations.

Oh well, publicly mock the manufacturer for doing horrible things in
their BIOS and then no one will buy the boxes, and we will not have
problems :)

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/