Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Parag Warudkar]

> If you grab Linus' current tree it should apply.
> 
> Sorry about the confusion.
> -john

I ignored the reject since it was from an #include section - the build went fine. I am even able to use it successfully. Couple things -

Very happy to report that I no longer get those annoying - "losing some ticks ..." "your time source is unreliable or some driver is hogging interrupts" messages - Not sure what change in TOD subsystem cured it - or was it just the removal of the printk? ;) 

Sadly, it somehow feels noticeably slower than vanilla 2.6.12-rc5. Especially using X/KDE - It is surely usable but not snappy. I will do more research to find out exactly why - but before that is such as loss of snappiness possible due to the TOD changes?

Thanks
Parag

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Nishanth Aravamudan]

On 02.06.2005 [18:27:51 +0000], Parag Warudkar wrote:
> > If you grab Linus' current tree it should apply.
> > 
> > Sorry about the confusion.
> > -john
> 
> I ignored the reject since it was from an #include section - the build
> went fine. I am even able to use it successfully. Couple things -
> 
> Very happy to report that I no longer get those annoying - "losing
> some ticks ..." "your time source is unreliable or some driver is
> hogging interrupts" messages - Not sure what change in TOD subsystem
> cured it - or was it just the removal of the printk? ;) 
> 
> Sadly, it somehow feels noticeably slower than vanilla 2.6.12-rc5.
> Especially using X/KDE - It is surely usable but not snappy. I will do
> more research to find out exactly why - but before that is such as
> loss of snappiness possible due to the TOD changes?

Which timesource is being used?

cat /sys/devices/system/timesource/timesource0/timesource

Thanks,
Nish

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[john stultz]

On Thu, 2005-06-02 at 18:27 +0000, Parag Warudkar wrote:
> > If you grab Linus' current tree it should apply.
> > 
> > Sorry about the confusion.
> > -john
> 
> I ignored the reject since it was from an #include section - the build
> went fine. I am even able to use it successfully. Couple things -

Good to hear.


> Very happy to report that I no longer get those annoying - "losing
> some ticks ..." "your time source is unreliable or some driver is
> hogging interrupts" messages - Not sure what change in TOD subsystem
> cured it - or was it just the removal of the printk? ;) 

Since we do not interpolate, lost ticks no longer cause time problems
(well, unless you're using the jiffies timesource). 

> Sadly, it somehow feels noticeably slower than vanilla 2.6.12-rc5.
> Especially using X/KDE - It is surely usable but not snappy. I will do
> more research to find out exactly why - but before that is such as
> loss of snappiness possible due to the TOD changes?

Could you send me your dmesg output with and without using my patch? It
could be you're using a different timesource.

thanks
-john

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Parag Warudkar]

On Thursday 02 June 2005 14:39, Nishanth Aravamudan wrote:
> Which timesource is being used?
>
> cat /sys/devices/system/timesource/timesource0/timesource

tux-gentoo parag # cat /sys/devices/system/timesource/timesource0/timesource
jiffies tsc tsc-interp *acpi_pm

I am not attaching the dmesg output as it is fairly big and the only relevant 
line seems to be

Jun  1 20:56:18 tux-gentoo [   20.302560] Time: acpi_pm timesource has been 
installed.

Parag

-- 
Q: Would you like to see the WINE list?
A: What's on it, anything expensive?
Q: No, just Solitaire and MineSweeper for now, but the WINE is free.
	-- Kevin M. Bealer, about the WINdows Emulator

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[john stultz]

On Thu, 2005-06-02 at 19:05 -0400, Parag Warudkar wrote:
> On Thursday 02 June 2005 14:39, Nishanth Aravamudan wrote:
> > Which timesource is being used?
> >
> > cat /sys/devices/system/timesource/timesource0/timesource
> 
> tux-gentoo parag # cat /sys/devices/system/timesource/timesource0/timesource
> jiffies tsc tsc-interp *acpi_pm

You can change the timesource at runtime by doing something like:

echo "tsc" > /sys/devices/system/timesource/timesource0/timesource

The "*" denotes the current timesource, so you'll see it move the next
time you cat the timesource sysfs file.

Could you see if the slowness you're feeling is correlated to the
acpi_pm timesource? It is quite a bit slower to access then the TSC, but
I'd be surprised if you can actually feel the difference.

This is on an x86-64 system, correct?

thanks
-john

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Parag Warudkar]

On Thursday 02 June 2005 19:20, john stultz wrote:
> Could you see if the slowness you're feeling is correlated to the
> acpi_pm timesource? It is quite a bit slower to access then the TSC, but
> I'd be surprised if you can actually feel the difference.

Will try that.

>
> This is on an x86-64 system, correct?

Yes, correct.

Parag
-- 
It is exactly because a man cannot do a thing that he is a proper judge of it.
		-- Oscar Wilde

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Parag Warudkar]

On Thursday 02 June 2005 19:20, john stultz wrote:
> Could you see if the slowness you're feeling is correlated to the
> acpi_pm timesource?

Speaking of which, the below code from arch/i386/timer_pm.c looks particularly 
more taxing to me - 3 times read from ioport in a loop - not sure how many 
time that executes. 

static inline u32 read_pmtmr(void)
{
        u32 v1=0,v2=0,v3=0;
        /* It has been reported that because of various broken
         * chipsets (ICH4, PIIX4 and PIIX4E) where the ACPI PM time
         * source is not latched, so you must read it multiple
         * times to insure a safe value is read.
         */
        do {
                v1 = inl(pmtmr_ioport);
                v2 = inl(pmtmr_ioport);
                v3 = inl(pmtmr_ioport);
        } while ((v1 > v2 && v1 < v3) || (v2 > v3 && v2 < v1)
                        || (v3 > v1 && v3 < v2));

Shouldn't that loop be limited to the broken chipsets - why would correct 
people with correctly working chipsets carry this extra burden? (Or is it 
insignificant?)

-- 
Because we don't think about future generations, they will never forget us.
		-- Henrik Tikkanen

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Ulrich Windl]

Possibly the code could auto-detect the brokenness during initialization by 
executing inl(pmtmr_ioport) a few hundred times and watch for monotony.

Regards,
Ulrich


On 2 Jun 2005 at 19:50, Parag Warudkar wrote:

> On Thursday 02 June 2005 19:20, john stultz wrote:
> > Could you see if the slowness you're feeling is correlated to the
> > acpi_pm timesource?
> 
> Speaking of which, the below code from arch/i386/timer_pm.c looks particularly 
> more taxing to me - 3 times read from ioport in a loop - not sure how many 
> time that executes. 
> 
> static inline u32 read_pmtmr(void)
> {
>         u32 v1=0,v2=0,v3=0;
>         /* It has been reported that because of various broken
>          * chipsets (ICH4, PIIX4 and PIIX4E) where the ACPI PM time
>          * source is not latched, so you must read it multiple
>          * times to insure a safe value is read.
>          */
>         do {
>                 v1 = inl(pmtmr_ioport);
>                 v2 = inl(pmtmr_ioport);
>                 v3 = inl(pmtmr_ioport);
>         } while ((v1 > v2 && v1 < v3) || (v2 > v3 && v2 < v1)
>                         || (v3 > v1 && v3 < v2));
> 
> Shouldn't that loop be limited to the broken chipsets - why would correct 
> people with correctly working chipsets carry this extra burden? (Or is it 
> insignificant?)
> 
> -- 
> Because we don't think about future generations, they will never forget us.
> 		-- Henrik Tikkanen

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Parag Warudkar]

On Thursday 02 June 2005 19:20, john stultz wrote:
> Could you see if the slowness you're feeling is correlated to the
> acpi_pm timesource?

OK. I've to admit - I am not able to quantify the differences in snappiness 
after  trying hard to switch between vanilla rc5 and rc5-TOD with acpi_pm and 
tsc.  Ignore that for a while. (Although I still feel something is less 
snappy with TOD patches applied -tsc and acpi_pm both) If you have any means 
of measuring  the performance difference - let me know.

At the risk of sounding insane - 
Can any one try listen to music with the TOD patches applied?
I did it with XMMS, amaroK and Juk - All *seem* to play my music slightly 
faster than vanilla. Voices sound as if they were fast forwarded 
(fractionally).

Parag

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[john stultz]

On Thu, 2005-06-02 at 19:50 -0400, Parag Warudkar wrote:
> On Thursday 02 June 2005 19:20, john stultz wrote:
> > Could you see if the slowness you're feeling is correlated to the
> > acpi_pm timesource?
> 
> Speaking of which, the below code from arch/i386/timer_pm.c looks particularly 
> more taxing to me - 3 times read from ioport in a loop - not sure how many 
> time that executes. 
> 
> static inline u32 read_pmtmr(void)
> {
>         u32 v1=0,v2=0,v3=0;
>         /* It has been reported that because of various broken
>          * chipsets (ICH4, PIIX4 and PIIX4E) where the ACPI PM time
>          * source is not latched, so you must read it multiple
>          * times to insure a safe value is read.
>          */
>         do {
>                 v1 = inl(pmtmr_ioport);
>                 v2 = inl(pmtmr_ioport);
>                 v3 = inl(pmtmr_ioport);
>         } while ((v1 > v2 && v1 < v3) || (v2 > v3 && v2 < v1)
>                         || (v3 > v1 && v3 < v2));
> 
> Shouldn't that loop be limited to the broken chipsets - why would correct 
> people with correctly working chipsets carry this extra burden? (Or is it 
> insignificant?)

Yea, that would be nice to only do the triple read on the affected
systems. Although outside of the comment I don't have any real data as
to which system suffer from the issue. I'd have to defer to Dominik on
this one. 

thanks
-john

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Andi Kleen]

On Thu, Jun 02, 2005 at 07:50:33PM -0400, Parag Warudkar wrote:
> On Thursday 02 June 2005 19:20, john stultz wrote:
> > Could you see if the slowness you're feeling is correlated to the
> > acpi_pm timesource?
> 
> Speaking of which, the below code from arch/i386/timer_pm.c looks particularly 
> more taxing to me - 3 times read from ioport in a loop - not sure how many 
> time that executes. 
> 
> static inline u32 read_pmtmr(void)
> {
>         u32 v1=0,v2=0,v3=0;
>         /* It has been reported that because of various broken
>          * chipsets (ICH4, PIIX4 and PIIX4E) where the ACPI PM time
>          * source is not latched, so you must read it multiple
>          * times to insure a safe value is read.
>          */
>         do {
>                 v1 = inl(pmtmr_ioport);
>                 v2 = inl(pmtmr_ioport);
>                 v3 = inl(pmtmr_ioport);
>         } while ((v1 > v2 && v1 < v3) || (v2 > v3 && v2 < v1)
>                         || (v3 > v1 && v3 < v2));
> 
> Shouldn't that loop be limited to the broken chipsets - why would correct 
> people with correctly working chipsets carry this extra burden? (Or is it 
> insignificant?)

It is not insignificant and makes a lot of difference. On the x86-64
version of pmtimer I dropped it completely and so far nobody 
complained.

However I wonder why this new time system is using pmtimer by default
at all. That is very broken because pmtimer is one of the slowest.
I would suggest to duplicate the time source selection I have
in the latest x86-64 (-rc5) time.c, that is optimal for all machines
I know about (except that you might need to add cyclone and a non TSC
fallback for i386)

-Andi

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[john stultz]

On Fri, 2005-06-03 at 18:30 +0200, Andi Kleen wrote:
> On Thu, Jun 02, 2005 at 07:50:33PM -0400, Parag Warudkar wrote:
> > On Thursday 02 June 2005 19:20, john stultz wrote:
> > > Could you see if the slowness you're feeling is correlated to the
> > > acpi_pm timesource?
> > 
> > Speaking of which, the below code from arch/i386/timer_pm.c looks particularly 
> > more taxing to me - 3 times read from ioport in a loop - not sure how many 
> > time that executes. 
> > 
> > static inline u32 read_pmtmr(void)
> > {
> >         u32 v1=0,v2=0,v3=0;
> >         /* It has been reported that because of various broken
> >          * chipsets (ICH4, PIIX4 and PIIX4E) where the ACPI PM time
> >          * source is not latched, so you must read it multiple
> >          * times to insure a safe value is read.
> >          */
> >         do {
> >                 v1 = inl(pmtmr_ioport);
> >                 v2 = inl(pmtmr_ioport);
> >                 v3 = inl(pmtmr_ioport);
> >         } while ((v1 > v2 && v1 < v3) || (v2 > v3 && v2 < v1)
> >                         || (v3 > v1 && v3 < v2));
> > 
> > Shouldn't that loop be limited to the broken chipsets - why would correct 
> > people with correctly working chipsets carry this extra burden? (Or is it 
> > insignificant?)
> 
> It is not insignificant and makes a lot of difference. On the x86-64
> version of pmtimer I dropped it completely and so far nobody 
> complained.

Alright, I'll add a single read function and keep the triple read
function around just in case. Maybe we can use some sort of dmi
blacklist to auto-detect known trouble cases.

> However I wonder why this new time system is using pmtimer by default
> at all. That is very broken because pmtimer is one of the slowest.
> I would suggest to duplicate the time source selection I have
> in the latest x86-64 (-rc5) time.c, that is optimal for all machines
> I know about (except that you might need to add cyclone and a non TSC
> fallback for i386)

The priority values may need some tweaking. The acpi-pm timesource is
really useful on laptops that have cpufreq issues, so it has been a
higher priority then the TSC in i386 for awhile. 

How about something like this?

300 TSC 
200 HPET
200 CYCLONE
100 ACPI
050 PIT
010 JIFFIES

Then if the system has TSC issues (unsynced, cpufreq problems, etc), we
can demote the TSC's priority to 50 and it will fall back nicely without
manual intervention.

thanks
-john

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Christoph Lameter]

On Fri, 3 Jun 2005, john stultz wrote:

> How about something like this?
> 
> 300 TSC 
> 200 HPET
> 200 CYCLONE
> 100 ACPI
> 050 PIT
> 010 JIFFIES
> 
> Then if the system has TSC issues (unsynced, cpufreq problems, etc), we
> can demote the TSC's priority to 50 and it will fall back nicely without
> manual intervention.

Oh, we are going to have flags for timesources? Then please also do the 
jitter thing.

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[john stultz]

On Fri, 2005-06-03 at 12:02 -0700, Christoph Lameter wrote:
> On Fri, 3 Jun 2005, john stultz wrote:
> 
> > How about something like this?
> > 
> > 300 TSC 
> > 200 HPET
> > 200 CYCLONE
> > 100 ACPI
> > 050 PIT
> > 010 JIFFIES
> > 
> > Then if the system has TSC issues (unsynced, cpufreq problems, etc), we
> > can demote the TSC's priority to 50 and it will fall back nicely without
> > manual intervention.
> 
> Oh, we are going to have flags for timesources? Then please also do the 
> jitter thing.

Huh? There are no flags here, just the priority values that are already
in the structure.  When TSC timesource driver itself notes a problem
with the system, it can lower its own priority value.

thanks
-john

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Parag Warudkar]

[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]

Sorry for the resend - I had zipped up the .config and the mail didn't make it 
to everyone.

On Friday 03 June 2005 12:30, Andi Kleen wrote:
>  On the x86-64
> version of pmtimer I dropped it completely and so far nobody 
> complained.

Andi,
There I complain :):) - There is something wrong with this timer stuff in rc5. 
I earlier stated that running with rc5 + John's TOD patches makes the music 
players play music fast. It actually happens with plain vanilla rc5 too. (I 
was having 3-4  trees and some confusion when I earlier tested rc5 with 
John's patches.)

> I would suggest to duplicate the time source selection I have
> in the latest x86-64 (-rc5) time.c, that is optimal for all machines
> I know about (except that you might need to add cyclone and a non TSC
> fallback for i386)
>
> -Andi

I don't know if John's patches replace your timer code in rc5 totally but both 
rc5 and rc5+John's TOD patches make music play fast. Going back to 2.6.11 
brings the music speed back to normal.

My config for plain vanilla rc5 attached.

Parag

[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 37338 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.12-rc5
# Sat Jun  4 12:39:36 2005
#
CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_CMPXCHG=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_MK8=y
# CONFIG_MPSC is not set
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_MTRR=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
# CONFIG_NUMA is not set
CONFIG_HPET_TIMER=y
CONFIG_X86_PM_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_GART_IOMMU=y
CONFIG_SWIOTLB=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
# CONFIG_SECCOMP is not set
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_ISA_DMA_API=y

#
# Power management options
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_SOFTWARE_SUSPEND is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_ACPI_CONTAINER is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=y
# CONFIG_CPU_FREQ_STAT_DETAILS is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=m
CONFIG_CPU_FREQ_GOV_ONDEMAND=y

#
# CPUFreq processor drivers
#
CONFIG_X86_POWERNOW_K8=y
CONFIG_X86_POWERNOW_K8_ACPI=y
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
CONFIG_X86_ACPI_CPUFREQ=y

#
# shared options
#
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
# CONFIG_X86_SPEEDSTEP_LIB is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_UNORDERED_IO is not set
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_MSI is not set
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
# CONFIG_PCI_DEBUG is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not set
CONFIG_HOTPLUG_PCI_ACPI=y
# CONFIG_HOTPLUG_PCI_ACPI_IBM is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_IA32_EMULATION=y
CONFIG_IA32_AOUT=y
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_UID16=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
# CONFIG_DEBUG_DRIVER is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
# CONFIG_PARPORT_SERIAL is not set
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_PC_SUPERIO=y
# CONFIG_PARPORT_GSC is not set
CONFIG_PARPORT_1284=y

#
# Plug and Play support
#
# CONFIG_PNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# CONFIG_PARIDE is not set
CONFIG_BLK_CPQ_DA=m
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=8192
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_LBD=y
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_BLK_DEV_IDEFLOPPY=m
CONFIG_BLK_DEV_IDESCSI=m
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_IDEDMA_FORCED=y
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
CONFIG_BLK_DEV_ALI15X3=m
# CONFIG_WDC_ALI15X3 is not set
CONFIG_BLK_DEV_AMD74XX=y
# CONFIG_BLK_DEV_ATIIXP is not set
CONFIG_BLK_DEV_CMD64X=m
CONFIG_BLK_DEV_TRIFLEX=m
CONFIG_BLK_DEV_CY82C693=m
CONFIG_BLK_DEV_CS5520=m
CONFIG_BLK_DEV_CS5530=m
CONFIG_BLK_DEV_HPT34X=m
# CONFIG_HPT34X_AUTODMA is not set
CONFIG_BLK_DEV_HPT366=m
CONFIG_BLK_DEV_SC1200=m
CONFIG_BLK_DEV_PIIX=y
CONFIG_BLK_DEV_NS87415=m
CONFIG_BLK_DEV_PDC202XX_OLD=m
CONFIG_PDC202XX_BURST=y
CONFIG_BLK_DEV_PDC202XX_NEW=m
# CONFIG_PDC202XX_FORCE is not set
CONFIG_BLK_DEV_SVWKS=m
# CONFIG_BLK_DEV_SIIMAGE is not set
CONFIG_BLK_DEV_SIS5513=m
CONFIG_BLK_DEV_SLC90E66=m
CONFIG_BLK_DEV_TRM290=m
CONFIG_BLK_DEV_VIA82CXXX=m
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=y
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=y

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set

#
# SCSI Transport Attributes
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
# CONFIG_SCSI_ISCSI_ATTRS is not set

#
# SCSI low-level drivers
#
CONFIG_BLK_DEV_3W_XXXX_RAID=m
CONFIG_SCSI_3W_9XXX=m
CONFIG_SCSI_ACARD=m
CONFIG_SCSI_AACRAID=m
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=253
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
CONFIG_SCSI_AIC79XX=m
CONFIG_AIC79XX_CMDS_PER_DEVICE=32
CONFIG_AIC79XX_RESET_DELAY_MS=15000
# CONFIG_AIC79XX_ENABLE_RD_STRM is not set
# CONFIG_AIC79XX_DEBUG_ENABLE is not set
CONFIG_AIC79XX_DEBUG_MASK=0
# CONFIG_AIC79XX_REG_PRETTY_PRINT is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
CONFIG_SCSI_SATA=y
# CONFIG_SCSI_SATA_AHCI is not set
CONFIG_SCSI_SATA_SVW=m
CONFIG_SCSI_ATA_PIIX=m
CONFIG_SCSI_SATA_NV=m
CONFIG_SCSI_SATA_PROMISE=m
# CONFIG_SCSI_SATA_QSTOR is not set
CONFIG_SCSI_SATA_SX4=m
CONFIG_SCSI_SATA_SIL=m
CONFIG_SCSI_SATA_SIS=m
# CONFIG_SCSI_SATA_ULI is not set
CONFIG_SCSI_SATA_VIA=m
CONFIG_SCSI_SATA_VITESSE=m
CONFIG_SCSI_BUSLOGIC=m
# CONFIG_SCSI_OMIT_FLASHPOINT is not set
CONFIG_SCSI_DMX3191D=m
CONFIG_SCSI_EATA=m
# CONFIG_SCSI_EATA_TAGGED_QUEUE is not set
# CONFIG_SCSI_EATA_LINKED_COMMANDS is not set
CONFIG_SCSI_EATA_MAX_TAGS=16
CONFIG_SCSI_FUTURE_DOMAIN=m
CONFIG_SCSI_GDTH=m
CONFIG_SCSI_IPS=m
# CONFIG_SCSI_INITIO is not set
CONFIG_SCSI_INIA100=m
CONFIG_SCSI_PPA=m
CONFIG_SCSI_IMM=m
CONFIG_SCSI_IZIP_EPP16=y
# CONFIG_SCSI_IZIP_SLOW_CTR is not set
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
# CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set
CONFIG_SCSI_IPR=m
# CONFIG_SCSI_IPR_TRACE is not set
# CONFIG_SCSI_IPR_DUMP is not set
CONFIG_SCSI_QLOGIC_FC=m
CONFIG_SCSI_QLOGIC_FC_FIRMWARE=y
CONFIG_SCSI_QLOGIC_1280=m
# CONFIG_SCSI_QLOGIC_1280_1040 is not set
CONFIG_SCSI_QLA2XXX=y
CONFIG_SCSI_QLA21XX=m
CONFIG_SCSI_QLA22XX=m
CONFIG_SCSI_QLA2300=m
CONFIG_SCSI_QLA2322=m
CONFIG_SCSI_QLA6312=m
# CONFIG_SCSI_LPFC is not set
CONFIG_SCSI_DC395x=m
CONFIG_SCSI_DC390T=m
# CONFIG_SCSI_DEBUG is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
CONFIG_IEEE1394=m

#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
# CONFIG_IEEE1394_OUI_DB is not set
CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y
CONFIG_IEEE1394_CONFIG_ROM_IP1394=y

#
# Device Drivers
#
# CONFIG_IEEE1394_PCILYNX is not set
CONFIG_IEEE1394_OHCI1394=m

#
# Protocol Drivers
#
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
CONFIG_IEEE1394_ETH1394=m
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
CONFIG_IEEE1394_CMP=m
CONFIG_IEEE1394_AMDTP=m

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_NET_KEY=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_TUNNEL=m
CONFIG_IP_TCPDIAG=y
CONFIG_IP_TCPDIAG_IPV6=y

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
CONFIG_IPV6=y
CONFIG_IPV6_PRIVACY=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
CONFIG_INET6_TUNNEL=m
CONFIG_IPV6_TUNNEL=m
CONFIG_NETFILTER=y
CONFIG_NETFILTER_DEBUG=y

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT is not set
# CONFIG_IP_NF_CONNTRACK_MARK is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_REALM=m
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_COMMENT is not set
# CONFIG_IP_NF_MATCH_HASHLIMIT is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_NAT_TFTP=m
CONFIG_IP_NF_NAT_AMANDA=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_CLASSIFY=m
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_TARGET_NOTRACK=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m

#
# IPv6: Netfilter Configuration (EXPERIMENTAL)
#
# CONFIG_IP6_NF_QUEUE is not set
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_LIMIT=m
CONFIG_IP6_NF_MATCH_MAC=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_MULTIPORT=m
CONFIG_IP6_NF_MATCH_OWNER=m
CONFIG_IP6_NF_MATCH_MARK=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_AHESP=m
CONFIG_IP6_NF_MATCH_LENGTH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_MARK=m
CONFIG_IP6_NF_RAW=m
CONFIG_XFRM=y
CONFIG_XFRM_USER=m

#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IP_SCTP=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
CONFIG_VLAN_8021Q=m
# CONFIG_DECNET is not set
CONFIG_LLC=y
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_BASIC is not set
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
# CONFIG_CLS_U32_PERF is not set
CONFIG_NET_CLS_IND=y
# CONFIG_CLS_U32_MARK is not set
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_EMATCH is not set
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=m
# CONFIG_NET_ACT_GACT is not set
# CONFIG_NET_ACT_MIRRED is not set
# CONFIG_NET_ACT_IPT is not set
# CONFIG_NET_ACT_PEDIT is not set
# CONFIG_NET_ACT_SIMP is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
# CONFIG_BT_RFCOMM is not set
# CONFIG_BT_BNEP is not set
# CONFIG_BT_CMTP is not set
CONFIG_BT_HIDP=m

#
# Bluetooth device drivers
#
CONFIG_BT_HCIUSB=m
# CONFIG_BT_HCIUSB_SCO is not set
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIUART_BCSP_TXCRC=y
# CONFIG_BT_HCIBCM203X is not set
# CONFIG_BT_HCIBPA10X is not set
# CONFIG_BT_HCIBFUSB is not set
# CONFIG_BT_HCIVHCI is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_EQUALIZER=m
# CONFIG_TUN is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=m
# CONFIG_TYPHOON is not set

#
# Tulip family network device support
#
CONFIG_NET_TULIP=y
CONFIG_DE2104X=m
CONFIG_TULIP=m
# CONFIG_TULIP_MWI is not set
# CONFIG_TULIP_MMIO is not set
# CONFIG_TULIP_NAPI is not set
CONFIG_DE4X5=m
CONFIG_WINBOND_840=m
CONFIG_DM9102=m
CONFIG_HP100=m
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
CONFIG_AMD8111_ETH=m
# CONFIG_AMD8111E_NAPI is not set
CONFIG_ADAPTEC_STARFIRE=m
# CONFIG_ADAPTEC_STARFIRE_NAPI is not set
CONFIG_B44=m
CONFIG_FORCEDETH=m
CONFIG_DGRS=m
# CONFIG_EEPRO100 is not set
CONFIG_E100=m
CONFIG_FEALNX=m
CONFIG_NATSEMI=m
CONFIG_NE2K_PCI=m
CONFIG_8139CP=m
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
CONFIG_8139TOO_8129=y
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_SIS900=m
CONFIG_EPIC100=m
CONFIG_SUNDANCE=m
# CONFIG_SUNDANCE_MMIO is not set
CONFIG_VIA_RHINE=m
# CONFIG_VIA_RHINE_MMIO is not set

#
# Ethernet (1000 Mbit)
#
CONFIG_ACENIC=m
# CONFIG_ACENIC_OMIT_TIGON_I is not set
CONFIG_DL2K=m
CONFIG_E1000=m
# CONFIG_E1000_NAPI is not set
CONFIG_NS83820=m
CONFIG_HAMACHI=m
CONFIG_YELLOWFIN=m
CONFIG_R8169=m
# CONFIG_R8169_NAPI is not set
# CONFIG_R8169_VLAN is not set
CONFIG_SK98LIN=m
# CONFIG_VIA_VELOCITY is not set
CONFIG_TIGON3=m

#
# Ethernet (10000 Mbit)
#
CONFIG_IXGB=m
# CONFIG_IXGB_NAPI is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
CONFIG_TR=y
# CONFIG_IBMOL is not set
CONFIG_3C359=m
# CONFIG_TMS380TR is not set

#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y

#
# Obsolete Wireless cards support (pre-802.11)
#
# CONFIG_STRIP is not set

#
# Wireless 802.11b ISA/PCI cards support
#
CONFIG_HERMES=m
CONFIG_PLX_HERMES=m
CONFIG_TMD_HERMES=m
# CONFIG_PCI_HERMES is not set
# CONFIG_ATMEL is not set

#
# Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support
#
CONFIG_PRISM54=m
CONFIG_NET_WIRELESS=y

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PLIP=m
CONFIG_PPP=m
# CONFIG_PPP_MULTILINK is not set
# CONFIG_PPP_FILTER is not set
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
# CONFIG_SLIP_SMART is not set
# CONFIG_SLIP_MODE_SLIP6 is not set
CONFIG_NET_FC=y
# CONFIG_SHAPER is not set
CONFIG_NETCONSOLE=m

#
# ISDN subsystem
#
CONFIG_ISDN=m

#
# Old ISDN4Linux
#
# CONFIG_ISDN_I4L is not set

#
# CAPI subsystem
#
CONFIG_ISDN_CAPI=m
# CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON is not set
# CONFIG_ISDN_CAPI_MIDDLEWARE is not set
CONFIG_ISDN_CAPI_CAPI20=m

#
# CAPI hardware drivers
#

#
# Active AVM cards
#
# CONFIG_CAPI_AVM is not set

#
# Active Eicon DIVA Server cards
#
# CONFIG_CAPI_EICON is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1280
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=800
CONFIG_INPUT_JOYDEV=y
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=m
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
CONFIG_GAMEPORT=m
# CONFIG_GAMEPORT_NS558 is not set
# CONFIG_GAMEPORT_L4 is not set
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_VORTEX is not set
# CONFIG_GAMEPORT_FM801 is not set
# CONFIG_GAMEPORT_CS461X is not set
CONFIG_SOUND_GAMEPORT=m

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
CONFIG_ROCKETPORT=m
# CONFIG_CYCLADES is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_ISI is not set
CONFIG_SYNCLINK=m
CONFIG_SYNCLINKMP=m
CONFIG_N_HDLC=m
# CONFIG_RISCOM8 is not set
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_RIO is not set
# CONFIG_STALDRV is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_ACPI=y
CONFIG_SERIAL_8250_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_PRINTER is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_ALIM1535_WDT is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_SC520_WDT is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
# CONFIG_WAFER_WDT is not set
# CONFIG_I8XX_TCO is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_60XX_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_W83627HF_WDT is not set
# CONFIG_W83877F_WDT is not set
# CONFIG_MACHZ_WDT is not set

#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_HW_RANDOM=y
CONFIG_NVRAM=y
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
# CONFIG_AGP_INTEL is not set
CONFIG_DRM=y
CONFIG_DRM_TDFX=m
CONFIG_DRM_R128=m
CONFIG_DRM_RADEON=m
# CONFIG_DRM_MGA is not set
CONFIG_DRM_SIS=m
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
# CONFIG_HPET_RTC_IRQ is not set
CONFIG_HPET_MMAP=y
# CONFIG_HANGCHECK_TIMER is not set

#
# TPM devices
#
# CONFIG_TCG_TPM is not set

#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
CONFIG_I2C_AMD8111=m
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
CONFIG_I2C_ISA=m
CONFIG_I2C_NFORCE2=m
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
CONFIG_I2C_VIAPRO=m
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set

#
# Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
# CONFIG_SENSORS_ADM1026 is not set
CONFIG_SENSORS_ADM1031=m
# CONFIG_SENSORS_ASB100 is not set
CONFIG_SENSORS_DS1621=m
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
CONFIG_SENSORS_IT87=m
# CONFIG_SENSORS_LM63 is not set
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
CONFIG_SENSORS_MAX1619=m
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_W83781D=m
# CONFIG_SENSORS_W83L785TS is not set
CONFIG_SENSORS_W83627HF=m

#
# Other I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
CONFIG_SENSORS_EEPROM=m
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m

#
# Video For Linux
#

#
# Video Adapters
#
CONFIG_VIDEO_BT848=m
CONFIG_VIDEO_BWQCAM=m
CONFIG_VIDEO_CQCAM=m
CONFIG_VIDEO_W9966=m
CONFIG_VIDEO_CPIA=m
CONFIG_VIDEO_CPIA_PP=m
CONFIG_VIDEO_CPIA_USB=m
CONFIG_VIDEO_SAA5246A=m
CONFIG_VIDEO_SAA5249=m
CONFIG_TUNER_3036=m
CONFIG_VIDEO_STRADIS=m
CONFIG_VIDEO_ZORAN=m
CONFIG_VIDEO_ZORAN_BUZ=m
CONFIG_VIDEO_ZORAN_DC10=m
CONFIG_VIDEO_ZORAN_DC30=m
CONFIG_VIDEO_ZORAN_LML33=m
CONFIG_VIDEO_ZORAN_LML33R10=m
CONFIG_VIDEO_SAA7134=m
CONFIG_VIDEO_MXB=m
CONFIG_VIDEO_DPC=m
CONFIG_VIDEO_HEXIUM_ORION=m
CONFIG_VIDEO_HEXIUM_GEMINI=m
CONFIG_VIDEO_CX88=m
CONFIG_VIDEO_OVCAMCHIP=m

#
# Radio Adapters
#
CONFIG_RADIO_GEMTEK_PCI=m
CONFIG_RADIO_MAXIRADIO=m
CONFIG_RADIO_MAESTRO=m

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
CONFIG_VIDEO_SAA7146=m
CONFIG_VIDEO_SAA7146_VV=m
CONFIG_VIDEO_VIDEOBUF=m
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEO_BUF=m
CONFIG_VIDEO_BTCX=m
CONFIG_VIDEO_IR=m
CONFIG_VIDEO_TVEEPROM=m

#
# Graphics support
#
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_SOFT_CURSOR=y
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_MODE_HELPERS is not set
# CONFIG_FB_TILEBLITTING is not set
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
# CONFIG_FB_HGA is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON_OLD is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_FONT_6x11 is not set
CONFIG_FONT_PEARL_8x8=y
CONFIG_FONT_ACORN_8x8=y
CONFIG_FONT_MINI_4x6=y
CONFIG_FONT_SUN8x16=y
# CONFIG_FONT_SUN12x22 is not set

#
# Logo configuration
#
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Sound
#
CONFIG_SOUND=y

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=y
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_OPL3_LIB=m
CONFIG_SND_VX_LIB=m
# CONFIG_SND_DUMMY is not set
CONFIG_SND_VIRMIDI=m
# CONFIG_SND_MTPAV is not set
CONFIG_SND_SERIAL_U16550=m
CONFIG_SND_MPU401=m

#
# PCI devices
#
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_ALI5451=m
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
CONFIG_SND_AZT3328=m
CONFIG_SND_BT87X=m
# CONFIG_SND_BT87X_OVERCLOCK is not set
CONFIG_SND_CS46XX=m
# CONFIG_SND_CS46XX_NEW_DSP is not set
CONFIG_SND_CS4281=m
CONFIG_SND_EMU10K1=m
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_CA0106 is not set
CONFIG_SND_KORG1212=m
CONFIG_SND_MIXART=m
CONFIG_SND_NM256=m
CONFIG_SND_RME32=m
CONFIG_SND_RME96=m
CONFIG_SND_RME9652=m
CONFIG_SND_HDSP=m
CONFIG_SND_TRIDENT=m
CONFIG_SND_YMFPCI=m
CONFIG_SND_ALS4000=m
CONFIG_SND_CMIPCI=m
CONFIG_SND_ENS1370=m
CONFIG_SND_ENS1371=m
CONFIG_SND_ES1938=m
CONFIG_SND_ES1968=m
CONFIG_SND_MAESTRO3=m
CONFIG_SND_FM801=m
# CONFIG_SND_FM801_TEA575X is not set
CONFIG_SND_ICE1712=m
CONFIG_SND_ICE1724=m
CONFIG_SND_INTEL8X0=m
CONFIG_SND_INTEL8X0M=m
CONFIG_SND_SONICVIBES=m
CONFIG_SND_VIA82XX=m
# CONFIG_SND_VIA82XX_MODEM is not set
CONFIG_SND_VX222=m
# CONFIG_SND_HDA_INTEL is not set

#
# USB devices
#
CONFIG_SND_USB_AUDIO=m
# CONFIG_SND_USB_USX2Y is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_OHCI_HCD=m
# CONFIG_USB_OHCI_BIG_ENDIAN is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_AUDIO is not set

#
# USB Bluetooth TTY can only be used with disabled Bluetooth subsystem
#
# CONFIG_USB_MIDI is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set

#
# USB Input Devices
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_EGALAX is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set
# CONFIG_USB_VICAM is not set
# CONFIG_USB_DSBR is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_KONICAWC is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_SE401 is not set
# CONFIG_USB_SN9C102 is not set
# CONFIG_USB_STV680 is not set
# CONFIG_USB_W9968CF is not set
# CONFIG_USB_PWC is not set

#
# USB Network Adapters
#
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_USBNET=m

#
# USB Host-to-Host Cables
#
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_GENESYS=y
CONFIG_USB_NET1080=y
CONFIG_USB_PL2301=y
CONFIG_USB_KC2190=y

#
# Intelligent USB Devices/Gadgets
#
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_ZAURUS=y
CONFIG_USB_CDCETHER=y

#
# USB Network Adapters
#
CONFIG_USB_AX8817X=y
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_MON is not set

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETKIT is not set
# CONFIG_USB_PHIDGETSERVO is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_TEST is not set

#
# USB ATM/DSL drivers
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# Firmware Drivers
#
CONFIG_EDD=y

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
# CONFIG_EXT2_FS_SECURITY is not set
CONFIG_EXT3_FS=m
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
# CONFIG_REISERFS_FS_SECURITY is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y

#
# XFS support
#
CONFIG_XFS_FS=y
# CONFIG_XFS_RT is not set
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_SECURITY is not set
CONFIG_XFS_POSIX_ACL=y
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=y

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
CONFIG_LDM_PARTITION=y
# CONFIG_LDM_DEBUG is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
# CONFIG_EFI_PARTITION is not set

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m

#
# Profiling support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=m

#
# Kernel hacking
#
CONFIG_PRINTK_TIME=y
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_DEBUG_PREEMPT=y
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_CHECKING is not set
# CONFIG_INIT_DEBUG is not set
# CONFIG_IOMMU_DEBUG is not set
CONFIG_KPROBES=y

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=m
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=y
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_DEFLATE=m
# CONFIG_CRYPTO_MICHAEL_MIC is not set
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_TEST is not set

#
# Hardware crypto devices
#

#
# Library routines
#
CONFIG_CRC_CCITT=y
CONFIG_CRC32=y
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Andi Kleen]

> How about something like this?
> 
> 300 TSC 
> 200 HPET
> 200 CYCLONE
> 100 ACPI
> 050 PIT
> 010 JIFFIES
> 
> Then if the system has TSC issues (unsynced, cpufreq problems, etc), we

The priority is fine, the problem is getting the decisions for when
to fallback right.

It is quite complicated to decide this, see the x86-64 time.c code 
for this.

> can demote the TSC's priority to 50 and it will fall back nicely without
> manual intervention.

-Andi

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Andi Kleen]

> There I complain :):) - There is something wrong with this timer stuff in rc5. 
> I earlier stated that running with rc5 + John's TOD patches makes the music 
> players play music fast. It actually happens with plain vanilla rc5 too. (I 
> was having 3-4 ?trees and some confusion when I earlier tested rc5 with 
> John's patches.)

Do you actually use pmtimer? Please send a dmesg log.

Also note that pmtimer does not even drive the timer interrupt,
just gettimeofday.

-Andi

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Parag Warudkar]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

On Sunday 05 June 2005 07:28, Andi Kleen wrote:
> Do you actually use pmtimer? Please send a dmesg log.
>
Full dmesg attached - 2.6.12-rc5 seems to use pmtimer.

From 2.6.12-rc5 -
---------------------------------------
Jun  5 10:04:04 tux-gentoo [    0.000000] time.c: Using 3.579545 MHz PM timer.
Jun  5 10:04:04 tux-gentoo [    0.000000] time.c: Detected 797.956 MHz 
processor.
Jun  5 10:04:04 tux-gentoo [   14.020805] time.c: Using PIT/TSC based 
timekeeping.

And from 2.6.11-gentoo 
---------------------------------------
May  3 22:31:03 tux-gentoo time.c: Using 1.193182 MHz PIT timer.
May  3 22:31:03 tux-gentoo time.c: Detected 1994.883 MHz processor.

The differences in PM Timer MHz - is something wrong there? They seem to be 
dependent on processor MHz which is 797 MHz (lowest cpufreq) in 2.6.12-rc5 
and 1994 MHz (Highest cpufreq) on 2.6.11.

> Also note that pmtimer does not even drive the timer interrupt,
> just gettimeofday.

Could it be that the music players use gettimeofday() for time keeping? Sure 
enough they are broken with -rc5.

Parag

[-- Attachment #2: dm.out --]
[-- Type: text/plain, Size: 15901 bytes --]

id[0x00] lapic_id[0x00] enabled)
[    0.000000] Processor #0 15:4 APIC version 16
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: BIOS IRQ0 pin2 override ignored.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Setting APIC routing to flat
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] Allocating PCI resources starting at 30000000 (gap: 30000000:cff80000)
[    0.000000] Checking aperture...
[    0.000000] CPU 0: aperture @ e8000000 size 128 MB
[    0.000000] Built 1 zonelists
[    0.000000] Kernel command line: root=/dev/hda2 vga=0x317 video=vesafb:ywrap,mtrr
[    0.000000] Initializing CPU#0
[    0.000000] PID hash table entries: 4096 (order: 12, 131072 bytes)
[    0.000000] time.c: Using 3.579545 MHz PM timer.
[    0.000000] time.c: Detected 797.956 MHz processor.
[   14.020805] time.c: Using PIT/TSC based timekeeping.
[   14.020847] Console: colour dummy device 80x25
[   14.022212] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[   14.023558] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[   14.049027] Memory: 767948k/785856k available (2988k kernel code, 17204k reserved, 1244k data, 184k init)
[   14.049137] Calibrating delay loop... 1581.05 BogoMIPS (lpj=790528)
[   14.071862] Mount-cache hash table entries: 256
[   14.072002] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[   14.072014] CPU: L2 Cache: 1024K (64 bytes/line)
[   14.072026] CPU: AMD Athlon(tm) 64 Processor 3200+ stepping 08
[   14.123727] Using local APIC timer interrupts.
[   14.249130] Detected 12.468 MHz APIC timer.
[   14.249150] testing NMI watchdog ... OK.
[   14.259568] NET: Registered protocol family 16
[   14.259616] PCI: Using configuration type 1
[   14.259625] mtrr: v2.0 (20020519)
[   14.260253] ACPI: Subsystem revision 20050309
[   14.291197] ACPI: Interpreter enabled
[   14.291208] ACPI: Using IOAPIC for interrupt routing
[   14.291937] ACPI: PCI Root Bridge [PCI0] (0000:00)
[   14.291949] PCI: Probing PCI hardware (bus 00)
[   14.293033] Boot video device is 0000:01:00.0
[   14.294186] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[   14.296247] ACPI: Embedded Controller [EC0] (gpe 33)
[   14.342234] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P2P0._PRT]
[   14.342704] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP0._PRT]
[   14.343933] ACPI: PCI Interrupt Link [LNK1] (IRQs 16 18 19) *0
[   14.344618] ACPI: PCI Interrupt Link [LNK2] (IRQs 16 18 19) *0
[   14.345313] ACPI: PCI Interrupt Link [LNK3] (IRQs 17) *0
[   14.346004] ACPI: PCI Interrupt Link [LNK4] (IRQs 16 18 19) *0, disabled.
[   14.346689] ACPI: PCI Interrupt Link [LNK5] (IRQs 16 18 19) *0
[   14.347367] ACPI: PCI Interrupt Link [LSMB] (IRQs 20 21 22) *0
[   14.348038] ACPI: PCI Interrupt Link [LUS0] (IRQs 20 21 22) *0
[   14.348707] ACPI: PCI Interrupt Link [LUS1] (IRQs 20 21 22) *0
[   14.349381] ACPI: PCI Interrupt Link [LUS2] (IRQs 20 21 22) *0
[   14.350059] ACPI: PCI Interrupt Link [LMAC] (IRQs 20 21 22) *0, disabled.
[   14.350731] ACPI: PCI Interrupt Link [LACI] (IRQs 20 21 22) *0
[   14.351410] ACPI: PCI Interrupt Link [LMCI] (IRQs 20 21 22) *0
[   14.352093] ACPI: PCI Interrupt Link [LPID] (IRQs 20 21 22) *0, disabled.
[   14.352781] ACPI: PCI Interrupt Link [LTID] (IRQs 20 21 22) *0, disabled.
[   14.353227] SCSI subsystem initialized
[   14.353305] PCI: Using ACPI for IRQ routing
[   14.353315] PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
[   14.353403] TC classifier action (bugs to netdev@oss.sgi.com cc hadi@cyberus.ca)
[   14.353462] agpgart: Detected AGP bridge 0
[   14.353476] agpgart: Setting up Nforce3 AGP.
[   14.360612] agpgart: AGP aperture is 128M @ 0xe8000000
[   14.360650] PCI-DMA: Disabling IOMMU.
[   14.362164] Simple Boot Flag at 0x37 set to 0x1
[   14.362362] IA32 emulation $Id: sys_ia32.c,v 1.32 2002/03/24 13:02:28 ak Exp $
[   14.363662] SGI XFS with ACLs, large block/inode numbers, no debug enabled
[   14.363826] Initializing Cryptographic API
[   14.363988] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[   14.363997] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.4
[   14.364250] vesafb: framebuffer at 0xf0000000, mapped to 0xffffc20000100000, using 3072k, total 65536k
[   14.364268] vesafb: mode is 1024x768x16, linelength=2048, pages=1
[   14.364276] vesafb: scrolling: redraw
[   14.364285] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
[   14.379417] Console: switching to colour frame buffer device 128x48
[   14.379519] fb0: VESA VGA frame buffer device
[   14.380896] ACPI: AC Adapter [ACAD] (on-line)
[   14.490704] ACPI: Battery Slot [BAT1] (battery present)
[   14.490808] ACPI: Power Button (FF) [PWRF]
[   14.490882] ACPI: Lid Switch [LID]
[   14.491495] ACPI: Video Device [VGA] (multi-head: yes  rom: no  post: no)
[   14.492706] ACPI: CPU0 (power states: C1[C1] C2[C2])
[   14.503781] ACPI: Thermal Zone [THRM] (49 C)
[   14.527634] Real Time Clock Driver v1.12
[   14.527783] Non-volatile memory driver v1.2
[   14.527858] Linux agpgart interface v0.101 (c) Dave Jones
[   14.527955] [drm] Initialized drm 1.0.0 20040925
[   14.536630] i8042.c: Detected active multiplexing controller, rev 1.1.
[   14.541623] serio: i8042 AUX0 port at 0x60,0x64 irq 12
[   14.544230] serio: i8042 AUX1 port at 0x60,0x64 irq 12
[   14.544922] serio: i8042 AUX2 port at 0x60,0x64 irq 12
[   14.545923] serio: i8042 AUX3 port at 0x60,0x64 irq 12
[   14.546620] serio: i8042 KBD port at 0x60,0x64 irq 1
[   14.549091] Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
[   14.553242] ACPI: PCI Interrupt Link [LMCI] enabled at IRQ 22
[   14.555816] ACPI: PCI Interrupt 0000:00:06.1[B] -> Link [LMCI] -> GSI 22 (level, low) -> IRQ 22
[   14.558482] io scheduler noop registered
[   14.561096] io scheduler anticipatory registered
[   14.563659] io scheduler deadline registered
[   14.566185] io scheduler cfq registered
[   14.569255] RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
[   14.572139] loop: loaded (max 8 devices)
[   14.574807] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
[   14.577388] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
[   14.580068] NFORCE3-150: IDE controller at PCI slot 0000:00:08.0
[   14.582717] Losing some ticks... checking if CPU frequency changed.
[   14.582743] NFORCE3-150: chipset revision 165
[   14.585354] NFORCE3-150: not 100% native mode: will probe irqs later
[   14.587971] NFORCE3-150: BIOS didn't set cable bits correctly. Enabling workaround.
[   14.590598] NFORCE3-150: 0000:00:08.0 (rev a5) UDMA133 controller
[   14.593207]     ide0: BM-DMA at 0x2080-0x2087, BIOS settings: hda:DMA, hdb:pio
[   14.595940]     ide1: BM-DMA at 0x2088-0x208f, BIOS settings: hdc:DMA, hdd:pio
[   14.598624] Probing IDE interface ide0...
[   14.862207] hda: FUJITSU MHT2060AT PL, ATA DISK drive
[   15.480618] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[   15.483282] Probing IDE interface ide1...
[   16.154712] hdc: HL-DT-ST DVD+RW GCA-4040N, ATAPI CD/DVD-ROM drive
[   16.463014] ide1 at 0x170-0x177,0x376 on irq 15
[   16.465842] Probing IDE interface ide2...
[   16.978947] Probing IDE interface ide3...
[   17.491146] Probing IDE interface ide4...
[   18.003347] Probing IDE interface ide5...
[   18.515569] hda: max request size: 128KiB
[   18.589874] hda: 117210240 sectors (60011 MB) w/8192KiB Cache, CHS=65535/16/63, UDMA(100)
[   18.595599] hda: cache flushes supported
[   18.598307]  hda: hda1 hda2 hda3 hda4
[   18.639056] hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, DMA
[   18.641680] Uniform CD-ROM driver Revision: 3.20
[   18.646342] mice: PS/2 mouse device common for all mice
[   18.649010] Advanced Linux Sound Architecture Driver Version 1.0.9rc2  (Thu Mar 24 10:33:39 2005 UTC).
[   18.653060] ALSA device list:
[   18.655739]   No soundcards found.
[   18.658428] NET: Registered protocol family 2
[   18.670369] IP: routing cache hash table of 8192 buckets, 64Kbytes
[   18.673378] TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
[   18.677298] TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
[   18.680836] TCP: Hash tables configured (established 131072 bind 65536)
[   18.683748] NET: Registered protocol family 1
[   18.686579] NET: Registered protocol family 10
[   18.689535] Disabled Privacy Extensions on device ffffffff804d4f40(lo)
[   18.692547] IPv6 over IPv4 tunneling driver
[   18.695622] NET: Registered protocol family 17
[   18.698491] NET: Registered protocol family 15
[   18.702516] powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.00.09e)
[   18.707347] powernow-k8:    0 : fid 0xc (2000 MHz), vid 0x2 (1500 mV)
[   18.710312] powernow-k8:    1 : fid 0x8 (1600 MHz), vid 0xa (1300 mV)
[   18.713133] powernow-k8:    2 : fid 0x0 (800 MHz), vid 0x12 (1100 mV)
[   18.715959] cpu_init done, current fid 0x0, vid 0x12
[   18.723803] ACPI wakeup devices: 
[   18.730427] USB0 USB1 USB2 PS2K PS2M MAC0 
[   18.737028] ACPI: (supports S0 S3 S4 S5)
[   18.743579] BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
[   18.786926] input: AT Translated Set 2 keyboard on isa0060/serio0
[   18.824816] ReiserFS: hda2: found reiserfs format "3.6" with standard journal
[   23.626367] ReiserFS: hda2: using ordered data mode
[   23.670621] ReiserFS: hda2: journal params: device hda2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
[   23.689259] ReiserFS: hda2: checking transaction log (hda2)
[   23.886849] ReiserFS: hda2: Using r5 hash to sort names
[   23.893548] VFS: Mounted root (reiserfs filesystem) readonly.
[   23.900826] Freeing unused kernel memory: 184k freed
[   32.416092] Adding 2241056k swap on /dev/hda4.  Priority:-1 extents:1
[   50.875537] 8139too Fast Ethernet driver 0.9.27
[   50.890016] ACPI: PCI Interrupt Link [LNK2] enabled at IRQ 19
[   50.890040] ACPI: PCI Interrupt 0000:02:01.0[A] -> Link [LNK2] -> GSI 19 (level, low) -> IRQ 19
[   50.897072] eth0: RealTek RTL8139 at 0xffffc2000004e800, 00:0f:b0:01:01:65, IRQ 19
[   50.897082] eth0:  Identified 8139 chip type 'RTL-8101'
[   51.234948] input: PS/2 Generic Mouse on isa0060/serio4
[   59.845023] NTFS driver 2.1.22 [Flags: R/O MODULE].
[   60.530597] NTFS volume version 3.1.
[   60.601686] ReiserFS: hda3: found reiserfs format "3.6" with standard journal
[   60.603757] ReiserFS: hda3: using ordered data mode
[   60.604511] ReiserFS: hda3: journal params: device hda3, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
[   60.608739] ReiserFS: hda3: checking transaction log (hda3)
[   62.319226] ReiserFS: hda3: Using r5 hash to sort names
[   62.584642] usbcore: registered new driver usbfs
[   62.610782] usbcore: registered new driver hub
[   64.290816] eth0: link up, 10Mbps, half-duplex, lpa 0x0000
[   72.660618] ACPI: PCI Interrupt Link [LUS2] enabled at IRQ 21
[   72.661010] ACPI: PCI Interrupt 0000:00:02.2[C] -> Link [LUS2] -> GSI 21 (level, low) -> IRQ 21
[   72.661192] PCI: Setting latency timer of device 0000:00:02.2 to 64
[   72.661306] ehci_hcd 0000:00:02.2: nVidia Corporation nForce3 USB 2.0
[   72.689419] ehci_hcd 0000:00:02.2: new USB bus registered, assigned bus number 1
[   72.689791] ehci_hcd 0000:00:02.2: irq 21, io mem 0xe0004000
[   72.689969] PCI: cache line size of 64 is not supported by device 0000:00:02.2
[   72.690078] ehci_hcd 0000:00:02.2: park 0
[   72.690199] ehci_hcd 0000:00:02.2: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
[   72.704293] hub 1-0:1.0: USB hub found
[   72.704640] hub 1-0:1.0: 6 ports detected
[   74.918764] i2c_adapter i2c-0: nForce2 SMBus adapter at 0x2040
[   74.944919] i2c_adapter i2c-1: nForce2 SMBus adapter at 0x2000
[   75.219764] ohci_hcd: 2004 Nov 08 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
[   75.245808] PCI: Enabling device 0000:00:02.0 (0004 -> 0006)
[   75.247239] ACPI: PCI Interrupt Link [LUS0] enabled at IRQ 20
[   75.247379] ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LUS0] -> GSI 20 (level, low) -> IRQ 20
[   75.247553] PCI: Setting latency timer of device 0000:00:02.0 to 64
[   75.247662] ohci_hcd 0000:00:02.0: nVidia Corporation nForce3 USB 1.1
[   75.782732] ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2
[   75.783105] ohci_hcd 0000:00:02.0: irq 20, io mem 0xe0000000
[   75.927665] hub 2-0:1.0: USB hub found
[   75.928014] hub 2-0:1.0: 3 ports detected
[   75.934011] PCI: Enabling device 0000:00:02.1 (0004 -> 0006)
[   75.935138] ACPI: PCI Interrupt Link [LUS1] enabled at IRQ 22
[   75.935263] ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [LUS1] -> GSI 22 (level, low) -> IRQ 22
[   75.935431] PCI: Setting latency timer of device 0000:00:02.1 to 64
[   75.935538] ohci_hcd 0000:00:02.1: nVidia Corporation nForce3 USB 1.1 (#2)
[   76.527343] ohci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 3
[   76.527714] ohci_hcd 0000:00:02.1: irq 22, io mem 0xe0001000
[   77.073071] hub 3-0:1.0: USB hub found
[   77.073424] hub 3-0:1.0: 3 ports detected
[   78.087273] usb 3-1: new low speed USB device using ohci_hcd and address 2
[   78.854488] usbcore: registered new driver hiddev
[   78.936150] ACPI: PCI Interrupt Link [LACI] enabled at IRQ 21
[   78.936505] ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [LACI] -> GSI 21 (level, low) -> IRQ 21
[   78.936687] PCI: Setting latency timer of device 0000:00:06.0 to 64
[   79.035096] input: USB HID v1.11 Mouse [Microsoft Microsoft Wireless Optical Mouse® 1.0A] on usb-0000:00:02.1-1
[   79.035302] usbcore: registered new driver usbhid
[   79.035399] drivers/usb/input/hid-core.c: v2.01:USB HID core driver
[   80.740808] intel8x0_measure_ac97_clock: measured 49384 usecs
[   80.741165] intel8x0: clocking to 47409
[   81.464847] ACPI: PCI Interrupt 0000:00:06.1[B] -> Link [LMCI] -> GSI 22 (level, low) -> IRQ 22
[   81.465438] PCI: Setting latency timer of device 0000:00:06.1 to 64
[   81.939052] libata version 1.10 loaded.
[   84.554628] ieee1394: Initialized config rom entry `ip1394'
[   84.609398] ohci1394: $Rev: 1250 $ Ben Collins <bcollins@debian.org>
[   84.610734] ACPI: PCI Interrupt Link [LNK1] enabled at IRQ 18
[   84.610871] ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNK1] -> GSI 18 (level, low) -> IRQ 18
[   84.766166] ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[18]  MMIO=[e0108000-e01087ff]  Max Packet=[2048]
[   85.085423] 8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
[   86.750731] USB Universal Host Controller Interface driver v2.2
[   87.937108] ieee1394: Host added: ID:BUS[0-00:1023]  GUID[463f0200463f0200]
[   88.019837] eth1394: $Rev: 1247 $ Ben Collins <bcollins@debian.org>
[   88.026653] eth1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
[  104.291844] eth0: link up, 10Mbps, half-duplex, lpa 0x0000
[  108.976114] powernowd[10717]: segfault at 00002aaaaacbe7c3 rip 00002aaaaac03b2e rsp 00007fffff99deb0 error 7
[  130.985451] eth0: no IPv6 routers present
[  356.893427] codec_semaphore: semaphore is not ready [0x1][0x301300]
[  356.893844] codec_read 0: semaphore is not ready for register 0x76
[  356.896684] codec_semaphore: semaphore is not ready [0x1][0x301300]
[  356.896919] codec_read 1: semaphore is not ready for register 0x54

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Dominik Brodowski]

On Fri, Jun 03, 2005 at 08:24:35AM -0700, john stultz wrote:
> On Thu, 2005-06-02 at 19:50 -0400, Parag Warudkar wrote:
> > On Thursday 02 June 2005 19:20, john stultz wrote:
> > > Could you see if the slowness you're feeling is correlated to the
> > > acpi_pm timesource?
> > 
> > Speaking of which, the below code from arch/i386/timer_pm.c looks particularly 
> > more taxing to me - 3 times read from ioport in a loop - not sure how many 
> > time that executes. 
> > 
> > static inline u32 read_pmtmr(void)
> > {
> >         u32 v1=0,v2=0,v3=0;
> >         /* It has been reported that because of various broken
> >          * chipsets (ICH4, PIIX4 and PIIX4E) where the ACPI PM time
> >          * source is not latched, so you must read it multiple
> >          * times to insure a safe value is read.
> >          */
> >         do {
> >                 v1 = inl(pmtmr_ioport);
> >                 v2 = inl(pmtmr_ioport);
> >                 v3 = inl(pmtmr_ioport);
> >         } while ((v1 > v2 && v1 < v3) || (v2 > v3 && v2 < v1)
> >                         || (v3 > v1 && v3 < v2));
> > 
> > Shouldn't that loop be limited to the broken chipsets - why would correct 
> > people with correctly working chipsets carry this extra burden? (Or is it 
> > insignificant?)
> 
> Yea, that would be nice to only do the triple read on the affected
> systems. Although outside of the comment I don't have any real data as
> to which system suffer from the issue.

IIRC (from the comment above) several chipsets suffer from this
inconsistency, namely the widely used PIIX4(E) and ICH(4 only? or also other
ICH-ones?). Therefore, we'd need at least some sort of boot-time check to
decide which method to use... and based on the method, we can adjust the
priority maybe?

Thanks,
	Dominik

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Lee Revell]

On Sun, 2005-06-05 at 10:15 -0400, Parag Warudkar wrote:
> > Also note that pmtimer does not even drive the timer interrupt,
> > just gettimeofday.
> 
> Could it be that the music players use gettimeofday() for time keeping? Sure 
> enough they are broken with -rc5.

Well, that would be a broken design anyway.  That's what the ALSA timer
API is for.  But XMMS has a long history of buggy ALSA support anyway.

Do you get the same result with native OSS, ALSA OSS emulation, and
native ALSA?

Lee

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Parag Warudkar]

On Sunday 05 June 2005 16:51, Lee Revell wrote:
> Well, that would be a broken design anyway.  That's what the ALSA timer
> API is for.  But XMMS has a long history of buggy ALSA support anyway.
>

I am not sure they use gettimeofday(). Pardon my ignorance but why is it 
broken for them to use gettimeofday()?

> Do you get the same result with native OSS, ALSA OSS emulation, and
> native ALSA?

I am not sure about OSS and ALSA OSS emulation but I tried XMMS with ALSA 
output plugin and Juk and amaroK with GStreamer/alsasink. All of them have 
the same problem.

Parag

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Lee Revell]

On Sun, 2005-06-05 at 17:41 -0400, Parag Warudkar wrote:
> On Sunday 05 June 2005 16:51, Lee Revell wrote:
> > Well, that would be a broken design anyway.  That's what the ALSA timer
> > API is for.  But XMMS has a long history of buggy ALSA support anyway.
> >
> 
> I am not sure they use gettimeofday(). Pardon my ignorance but why is it 
> broken for them to use gettimeofday()?

If they're trying to synchronize other things to the sound,
gettimeofday() is a poor choice because it's driven by a different
crystal than the soundcard.  The correct solution is to use a PCM slave
timer.  See alsa-lib/examples/timer.c.

Lee

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Parag Warudkar]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

On Sunday 05 June 2005 13:05, Dominik Brodowski wrote:
> IIRC (from the comment above) several chipsets suffer from this
> inconsistency, namely the widely used PIIX4(E) and ICH(4 only? or also
> other ICH-ones?). Therefore, we'd need at least some sort of boot-time
> check to decide which method to use... and based on the method, we can
> adjust the priority maybe?

To begin with, will the simple proof-of-concept patch like below work? (It 
tests the chipset read in the same do{}while loop - if the loop executes only 
once, it considers the chipset good - in which case it executes the faster 
read_pmtmr_fast function.) Or does it need wider testing under different 
circumstances to conclude that chipset is good?

I tested the patch under Virtual PC which emulates a PIIX4 chipset. Test 
passes there, meaning the do {}while  loop executes only once.

Parag

[-- Attachment #2: timer_pm.c.patch --]
[-- Type: text/x-diff, Size: 3564 bytes --]

--- linux-2.6-orig/arch/i386/kernel/timers/timer_pm.c	2005-03-02 02:37:48.000000000 -0500
+++ linux-2.6.12-rc5/arch/i386/kernel/timers/timer_pm.c	2005-06-05 23:01:15.000000000 -0400
@@ -35,6 +35,10 @@
  * in arch/i386/acpi/boot.c */
 u32 pmtmr_ioport = 0;
 
+struct pmtmr_rd_func {
+	u32 (*read_pmtmr) (void);
+}pmtmr_rd_func;
+
 
 /* value of the Power timer at last timer interrupt */
 static u32 offset_tick;
@@ -45,6 +49,11 @@
 
 #define ACPI_PM_MASK 0xFFFFFF /* limit it to 24 bits */
 
+static inline u32 read_pmtmr_fast(void)
+{
+	return inl(pmtmr_ioport);
+}
+
 /*helper function to safely read acpi pm timesource*/
 static inline u32 read_pmtmr(void)
 {
@@ -76,14 +85,14 @@
 	unsigned long count, delta;
 
 	mach_prepare_counter();
-	value1 = read_pmtmr();
+	value1 = pmtmr_rd_func.read_pmtmr();
 	mach_countup(&count);
-	value2 = read_pmtmr();
+	value2 = pmtmr_rd_func.read_pmtmr();
 	delta = (value2 - value1) & ACPI_PM_MASK;
 
 	/* Check that the PMTMR delta is within 5% of what we expect */
-	if (delta < (PMTMR_EXPECTED_RATE * 19) / 20 ||
-	    delta > (PMTMR_EXPECTED_RATE * 21) / 20) {
+	if (delta < (PMTMR_EXPECTED_RATE * 18) / 20 ||
+	    delta > (PMTMR_EXPECTED_RATE * 22) / 20) {
 		printk(KERN_INFO "PM-Timer running at invalid rate: %lu%% of normal - aborting.\n", 100UL * delta / PMTMR_EXPECTED_RATE);
 		return -1;
 	}
@@ -95,9 +104,16 @@
 static int init_pmtmr(char* override)
 {
 	u32 value1, value2;
-	unsigned int i;
+	u32 v1=0,v2=0,v3=0;
+	unsigned int i, loop_cnt=0;
 
- 	if (override[0] && strncmp(override,"pmtmr",5))
+	/* Use slower but probably more correct read function by
+	 * default. This is overriden with a fast one if it is
+	 * suitable to do so below.
+	 */
+	pmtmr_rd_func.read_pmtmr = read_pmtmr;
+ 	
+	if (override[0] && strncmp(override,"pmtmr",5))
 		return -ENODEV;
 
 	if (!pmtmr_ioport)
@@ -106,9 +122,32 @@
 	/* we use the TSC for delay_pmtmr, so make sure it exists */
 	if (!cpu_has_tsc)
 		return -ENODEV;
+	/* It has been reported that because of various broken
+	 * chipsets (ICH4, PIIX4 and PIIX4E) where the ACPI PM time
+	 * source is not latched, so you must read it multiple
+	 * times to insure a safe value is read.
+	 */
+	do {
+		v1 = inl(pmtmr_ioport);
+		v2 = inl(pmtmr_ioport);
+		v3 = inl(pmtmr_ioport);
+		loop_cnt++;
+	} while ((v1 > v2 && v1 < v3) || (v2 > v3 && v2 < v1)
+			|| (v3 > v1 && v3 < v2));
+	
+	if(loop_cnt == 1) { 
+		/*We have a good chipset*/
+		printk(KERN_INFO "PM Timer: Chipset passes port read test\n");
+		pmtmr_rd_func.read_pmtmr = read_pmtmr_fast;
+	}
+	
+	else {
+		printk(KERN_INFO "PM Timer: Chipset fails port read test:");
+	 	printk(KERN_INFO "Working around it.");
+	}
 
 	/* "verify" this timing source */
-	value1 = read_pmtmr();
+	value1 = pmtmr_rd_func.read_pmtmr();
 	for (i = 0; i < 10000; i++) {
 		value2 = read_pmtmr();
 		if (value2 == value1)
@@ -156,7 +195,7 @@
 
 	write_seqlock(&monotonic_lock);
 
-	offset_tick = read_pmtmr();
+	offset_tick = pmtmr_rd_func.read_pmtmr();
 
 	/* calculate tick interval */
 	delta = (offset_tick - last_offset) & ACPI_PM_MASK;
@@ -202,7 +241,7 @@
 	} while (read_seqretry(&monotonic_lock, seq));
 
 	/* Read the pmtmr */
-	this_offset =  read_pmtmr();
+	this_offset =  pmtmr_rd_func.read_pmtmr();
 
 	/* convert to nanoseconds */
 	ret = (this_offset - last_offset) & ACPI_PM_MASK;
@@ -232,7 +271,7 @@
 	u32 now, offset, delta = 0;
 
 	offset = offset_tick;
-	now = read_pmtmr();
+	now = pmtmr_rd_func.read_pmtmr();
 	delta = (now - offset)&ACPI_PM_MASK;
 
 	return (unsigned long) offset_delay + cyc2us(delta);

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Dominik Brodowski]

Hi,

On Sun, Jun 05, 2005 at 11:04:34PM -0400, Parag Warudkar wrote:
> tests the chipset read in the same do{}while loop - if the loop executes only 
> once, it considers the chipset good - in which case it executes the faster 
> read_pmtmr_fast function.) Or does it need wider testing under different 
> circumstances to conclude that chipset is good?

I fear that we need to run the loop a couple of times at least -- IIRC many
accesses were correct, but some failed. Will investigate soon.

> I tested the patch under Virtual PC which emulates a PIIX4 chipset. Test 
> passes there, meaning the do {}while  loop executes only once.

Possibly this is a bug-free emulation?

	Dominik

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Andi Kleen]

> IIRC (from the comment above) several chipsets suffer from this
> inconsistency, namely the widely used PIIX4(E) and ICH(4 only? or also other
> ICH-ones?). Therefore, we'd need at least some sort of boot-time check to
> decide which method to use... and based on the method, we can adjust the
> priority maybe?

At least on x86-64 there are no ICH4s or PIIX4Es. Actually I think
there was one early prototype machine from Intel with ICH4, but I am willing
to ignore these.  So please dont do any such things on the x86-64 version.

Also didnt ICH4 already have HPET? it might not be enabled on many
boxes, but given the chip datasheet one can write enable code to 
fix that.

-Andi

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Dominik Brodowski]

On Mon, Jun 06, 2005 at 11:21:59AM +0200, Andi Kleen wrote:
> > IIRC (from the comment above) several chipsets suffer from this
> > inconsistency, namely the widely used PIIX4(E) and ICH(4 only? or also other
> > ICH-ones?). Therefore, we'd need at least some sort of boot-time check to
> > decide which method to use... and based on the method, we can adjust the
> > priority maybe?
> 
> At least on x86-64 there are no ICH4s or PIIX4Es. Actually I think
> there was one early prototype machine from Intel with ICH4, but I am willing
> to ignore these.  So please dont do any such things on the x86-64 version.
> 
> Also didnt ICH4 already have HPET? it might not be enabled on many
> boxes, but given the chip datasheet one can write enable code to 
> fix that.

At least on my notebook, which has an ICH4-M, there is no HPET. AFAIK it
resides on a separate chip which may or may not exist. I'd be glad if the
opposite were true, though :)

	Dominik

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Andi Kleen]

cc list trimmed. John please dont send out mails with such 
a horrible cc list anymore.

On Sun, Jun 05, 2005 at 10:15:33AM -0400, Parag Warudkar wrote:
> On Sunday 05 June 2005 07:28, Andi Kleen wrote:
> > Do you actually use pmtimer? Please send a dmesg log.
> >
> Full dmesg attached - 2.6.12-rc5 seems to use pmtimer.

And does it work with nopmtimer ? 

-Andi

> 
> From 2.6.12-rc5 -
> ---------------------------------------
> Jun  5 10:04:04 tux-gentoo [    0.000000] time.c: Using 3.579545 MHz PM timer.
> Jun  5 10:04:04 tux-gentoo [    0.000000] time.c: Detected 797.956 MHz 
> processor.
> Jun  5 10:04:04 tux-gentoo [   14.020805] time.c: Using PIT/TSC based 
> timekeeping.

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Andi Kleen]

> At least on my notebook, which has an ICH4-M, there is no HPET. AFAIK it
> resides on a separate chip which may or may not exist. I'd be glad if the
> opposite were true, though :)

No it is on the southbridge. But it is often not enabled in the BIOS
(so it is not reported in ACPI) but that can be fixed. 

-Andi

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Parag Warudkar]

On Monday 06 June 2005 05:29, Andi Kleen wrote:
> And does it work with nopmtimer ?
>
> -Andi

Thanks for trimming the CC list. 

No it doesn't work with nopmtimer - music still plays fast. I have to go back 
to 2.6.11 to get it to play at right speed. 

Relevant lines from rc5 with nopmtimer -

Jun  6 07:11:59 tux-gentoo [    0.000000] time.c: Using 1.193182 MHz PIT 
timer.
Jun  6 07:11:59 tux-gentoo [    0.000000] time.c: Detected 797.952 MHz 
processor.
Jun  6 07:11:59 tux-gentoo [   22.152032] time.c: Using PIT/TSC based 
timekeeping.


Parag

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Vojtech Pavlik]

On Mon, Jun 06, 2005 at 11:21:59AM +0200, Andi Kleen wrote:
> > IIRC (from the comment above) several chipsets suffer from this
> > inconsistency, namely the widely used PIIX4(E) and ICH(4 only? or also other
> > ICH-ones?). Therefore, we'd need at least some sort of boot-time check to
> > decide which method to use... and based on the method, we can adjust the
> > priority maybe?
> 
> At least on x86-64 there are no ICH4s or PIIX4Es. Actually I think
> there was one early prototype machine from Intel with ICH4, but I am willing
> to ignore these.  So please dont do any such things on the x86-64 version.
> 
> Also didnt ICH4 already have HPET? it might not be enabled on many
> boxes, but given the chip datasheet one can write enable code to 
> fix that.
 
I believe the HPET is implemented in the northbridge (MCH) in Intel
systems.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[john stultz]

On Sun, 2005-06-05 at 13:27 +0200, Andi Kleen wrote:
> > How about something like this?
> > 
> > 300 TSC 
> > 200 HPET
> > 200 CYCLONE
> > 100 ACPI
> > 050 PIT
> > 010 JIFFIES
> > 
> > Then if the system has TSC issues (unsynced, cpufreq problems, etc), we
> 
> The priority is fine, the problem is getting the decisions for when
> to fallback right.
> 
> It is quite complicated to decide this, see the x86-64 time.c code 
> for this.

Hmmm. I'm not sure I see the level of complication that you allude to.
Let me re-spin my patches again with the tsc timesource auto-demotion
and let me know if I'm missing anything.

thanks
-john

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[john stultz]

On Sun, 2005-06-05 at 19:05 +0200, Dominik Brodowski wrote:
> On Fri, Jun 03, 2005 at 08:24:35AM -0700, john stultz wrote:
> > On Thu, 2005-06-02 at 19:50 -0400, Parag Warudkar wrote:
> > > On Thursday 02 June 2005 19:20, john stultz wrote:
> > > > Could you see if the slowness you're feeling is correlated to the
> > > > acpi_pm timesource?
> > > 
> > > Speaking of which, the below code from arch/i386/timer_pm.c looks particularly 
> > > more taxing to me - 3 times read from ioport in a loop - not sure how many 
> > > time that executes. 
> > > 
> > > static inline u32 read_pmtmr(void)
> > > {
> > >         u32 v1=0,v2=0,v3=0;
> > >         /* It has been reported that because of various broken
> > >          * chipsets (ICH4, PIIX4 and PIIX4E) where the ACPI PM time
> > >          * source is not latched, so you must read it multiple
> > >          * times to insure a safe value is read.
> > >          */
> > >         do {
> > >                 v1 = inl(pmtmr_ioport);
> > >                 v2 = inl(pmtmr_ioport);
> > >                 v3 = inl(pmtmr_ioport);
> > >         } while ((v1 > v2 && v1 < v3) || (v2 > v3 && v2 < v1)
> > >                         || (v3 > v1 && v3 < v2));
> > > 
> > > Shouldn't that loop be limited to the broken chipsets - why would correct 
> > > people with correctly working chipsets carry this extra burden? (Or is it 
> > > insignificant?)
> > 
> > Yea, that would be nice to only do the triple read on the affected
> > systems. Although outside of the comment I don't have any real data as
> > to which system suffer from the issue.
> 
> IIRC (from the comment above) several chipsets suffer from this
> inconsistency, namely the widely used PIIX4(E) and ICH(4 only? or also other
> ICH-ones?). Therefore, we'd need at least some sort of boot-time check to
> decide which method to use... and based on the method, we can adjust the
> priority maybe?

Well, I'm not sure if this would be reasonably auto-detectable by just
reading the pmtmr in a loop. That could take awhile. But some form of
DMI blacklist should cover us.  Ok, I'll work on this for the next
release.

thanks
-john

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Andi Kleen]

On Mon, Jun 06, 2005 at 07:46:22AM -0400, Parag Warudkar wrote:
> On Monday 06 June 2005 05:29, Andi Kleen wrote:
> > And does it work with nopmtimer ?
> >
> > -Andi
> 
> Thanks for trimming the CC list. 
> 
> No it doesn't work with nopmtimer - music still plays fast. I have to go back 
> to 2.6.11 to get it to play at right speed. 

Then it is something else, not the pmtimer.

I dont know what it could be. Do a binary search? 

-Andi

> 
> Relevant lines from rc5 with nopmtimer -
> 
> Jun  6 07:11:59 tux-gentoo [    0.000000] time.c: Using 1.193182 MHz PIT 
> timer.
> Jun  6 07:11:59 tux-gentoo [    0.000000] time.c: Detected 797.952 MHz 
> processor.
> Jun  6 07:11:59 tux-gentoo [   22.152032] time.c: Using PIT/TSC based 
> timekeeping.
> 
> 
> Parag

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Lee Revell]

On Wed, 2005-06-08 at 15:51 +0200, Andi Kleen wrote:
> On Mon, Jun 06, 2005 at 07:46:22AM -0400, Parag Warudkar wrote:
> > On Monday 06 June 2005 05:29, Andi Kleen wrote:
> > > And does it work with nopmtimer ?
> > >
> > > -Andi
> > 
> > Thanks for trimming the CC list. 
> > 
> > No it doesn't work with nopmtimer - music still plays fast. I have to go back 
> > to 2.6.11 to get it to play at right speed. 
> 
> Then it is something else, not the pmtimer.
> 
> I dont know what it could be. Do a binary search? 

XMMS has a long history of buggy ALSA support, which has improved
lately.  Make sure you're using the latest version.

Also try 2.6.11 with ALSA 1.0.9, maybe it's an interaction between ALSA
and the new gettimeofday patches.

Lee

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[john stultz]

On Wed, 2005-06-08 at 21:47 -0400, Lee Revell wrote:
> On Wed, 2005-06-08 at 15:51 +0200, Andi Kleen wrote:
> > On Mon, Jun 06, 2005 at 07:46:22AM -0400, Parag Warudkar wrote:
> > > On Monday 06 June 2005 05:29, Andi Kleen wrote:
> > > > And does it work with nopmtimer ?
> > > >
> > > > -Andi
> > > 
> > > Thanks for trimming the CC list. 
> > > 
> > > No it doesn't work with nopmtimer - music still plays fast. I have to go back 
> > > to 2.6.11 to get it to play at right speed. 
> > 
> > Then it is something else, not the pmtimer.
> > 
> > I dont know what it could be. Do a binary search? 
> 
> XMMS has a long history of buggy ALSA support, which has improved
> lately.  Make sure you're using the latest version.
> 
> Also try 2.6.11 with ALSA 1.0.9, maybe it's an interaction between ALSA
> and the new gettimeofday patches.

Wahzuntme! :)  Well, I'd be very interested if my patches were to blame,
but I believe Parag said it happened with or without my patches.

Parag: If I'm incorrect and the issue goes away without my patches,
please let me know as I want to get to the bottom of it. 

thanks
-john

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Parag Warudkar]

>>On Wednesday 08 June 2005 21:47, Lee Revell wrote:
> > Also try 2.6.11 with ALSA 1.0.9, maybe it's an interaction between ALSA
> > and the new gettimeofday patches.

I am using 2.6.11 and ALSA 1.0.8 - no problem there. Will try with -rc5 and 
ALSA 1.0.9 to see if that makes any difference.

>On Wednesday 08 June 2005 22:12, john stultz wrote:
>
> Wahzuntme! :):)  Well, I'd be very interested if my patches were to blame,
> but I believe Parag said it happened with or without my patches.

You are right - it happens regardless of whether TOD patches are applied or 
not - So you are free to work upon a super fast TOD while we work upon the 
super fast music! :)

Parag

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Andi Kleen]

> Wahzuntme! :)  Well, I'd be very interested if my patches were to blame,
> but I believe Parag said it happened with or without my patches.

Yes, he said it happened with plain rc5.
-Andi

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[George Anzinger]

Parag Warudkar wrote:
> On Sunday 05 June 2005 13:05, Dominik Brodowski wrote:
> 
>>IIRC (from the comment above) several chipsets suffer from this
>>inconsistency, namely the widely used PIIX4(E) and ICH(4 only? or also
>>other ICH-ones?). Therefore, we'd need at least some sort of boot-time
>>check to decide which method to use... and based on the method, we can
>>adjust the priority maybe?
> 
> 
> To begin with, will the simple proof-of-concept patch like below work? (It 
> tests the chipset read in the same do{}while loop - if the loop executes only 
> once, it considers the chipset good - in which case it executes the faster 
> read_pmtmr_fast function.) Or does it need wider testing under different 
> circumstances to conclude that chipset is good?
> 
> I tested the patch under Virtual PC which emulates a PIIX4 chipset. Test 
> passes there, meaning the do {}while  loop executes only once.

As I understand the problem it is that the counter is, sometimes, read while it 
is is rippling the carry up to the higher bits.  This will only happen if the 
read is done just as the hardware is bumping the count and even then only if 
there is a carry.  Exactly where in the carry sequency this happens is likely 
just a guess.

In the HRT patch I take care of this by testing the read against a prior read 
(up to 1/HZ away).  If the number is bigger and to too much bigger, I just do 
one read.  Here is the full routine:

quick_get_cpuctr(void)
{
	static  unsigned long last_read = 0;
	static  int qgc_max = 0;
	int i;

	unsigned long rd_delta, rd_ans, rd = inl(acpi_pm_tmr_address);

	/*
	 * This will be REALLY big if ever we move backward in time...
	 */
	rd_delta = (rd - last_read) & SIZE_MASK;
	last_read = rd;

	rd_ans =  (rd - last_update) & SIZE_MASK;

	if (likely((rd_ans < (arch_cycles_per_jiffy << 1)) &&
		   (rd_delta < (arch_cycles_per_jiffy << 1))))
		return rd_ans;

	for (i = 0; i < 10; i++) {
		rd = inl(acpi_pm_tmr_address);
		rd_delta = (rd - last_read) & SIZE_MASK;
		last_read = rd;
		if (unlikely(i > qgc_max))
			qgc_max = i;
		/*
		 * On my test machine (800MHZ dual PIII) this is always
		 * seven.  Seems long, but we will give it some slack...
		 * We note that rd_delta (and all the vars) unsigned so
		 * a backward movement will show as a really big number.
		 */
		if (likely(rd_delta < 20))
			return (rd - last_update) & SIZE_MASK;
	}
	return (rd - last_update) & SIZE_MASK;
}
George
-- 
> 
> Parag
> 
> 
> ------------------------------------------------------------------------
> 
> --- linux-2.6-orig/arch/i386/kernel/timers/timer_pm.c	2005-03-02 02:37:48.000000000 -0500
> +++ linux-2.6.12-rc5/arch/i386/kernel/timers/timer_pm.c	2005-06-05 23:01:15.000000000 -0400
> @@ -35,6 +35,10 @@
>   * in arch/i386/acpi/boot.c */
>  u32 pmtmr_ioport = 0;
>  
> +struct pmtmr_rd_func {
> +	u32 (*read_pmtmr) (void);
> +}pmtmr_rd_func;
> +
>  
>  /* value of the Power timer at last timer interrupt */
>  static u32 offset_tick;
> @@ -45,6 +49,11 @@
>  
>  #define ACPI_PM_MASK 0xFFFFFF /* limit it to 24 bits */
>  
> +static inline u32 read_pmtmr_fast(void)
> +{
> +	return inl(pmtmr_ioport);
> +}
> +
>  /*helper function to safely read acpi pm timesource*/
>  static inline u32 read_pmtmr(void)
>  {
> @@ -76,14 +85,14 @@
>  	unsigned long count, delta;
>  
>  	mach_prepare_counter();
> -	value1 = read_pmtmr();
> +	value1 = pmtmr_rd_func.read_pmtmr();
>  	mach_countup(&count);
> -	value2 = read_pmtmr();
> +	value2 = pmtmr_rd_func.read_pmtmr();
>  	delta = (value2 - value1) & ACPI_PM_MASK;
>  
>  	/* Check that the PMTMR delta is within 5% of what we expect */
> -	if (delta < (PMTMR_EXPECTED_RATE * 19) / 20 ||
> -	    delta > (PMTMR_EXPECTED_RATE * 21) / 20) {
> +	if (delta < (PMTMR_EXPECTED_RATE * 18) / 20 ||
> +	    delta > (PMTMR_EXPECTED_RATE * 22) / 20) {
>  		printk(KERN_INFO "PM-Timer running at invalid rate: %lu%% of normal - aborting.\n", 100UL * delta / PMTMR_EXPECTED_RATE);
>  		return -1;
>  	}
> @@ -95,9 +104,16 @@
>  static int init_pmtmr(char* override)
>  {
>  	u32 value1, value2;
> -	unsigned int i;
> +	u32 v1=0,v2=0,v3=0;
> +	unsigned int i, loop_cnt=0;
>  
> - 	if (override[0] && strncmp(override,"pmtmr",5))
> +	/* Use slower but probably more correct read function by
> +	 * default. This is overriden with a fast one if it is
> +	 * suitable to do so below.
> +	 */
> +	pmtmr_rd_func.read_pmtmr = read_pmtmr;
> + 	
> +	if (override[0] && strncmp(override,"pmtmr",5))
>  		return -ENODEV;
>  
>  	if (!pmtmr_ioport)
> @@ -106,9 +122,32 @@
>  	/* we use the TSC for delay_pmtmr, so make sure it exists */
>  	if (!cpu_has_tsc)
>  		return -ENODEV;
> +	/* It has been reported that because of various broken
> +	 * chipsets (ICH4, PIIX4 and PIIX4E) where the ACPI PM time
> +	 * source is not latched, so you must read it multiple
> +	 * times to insure a safe value is read.
> +	 */
> +	do {
> +		v1 = inl(pmtmr_ioport);
> +		v2 = inl(pmtmr_ioport);
> +		v3 = inl(pmtmr_ioport);
> +		loop_cnt++;
> +	} while ((v1 > v2 && v1 < v3) || (v2 > v3 && v2 < v1)
> +			|| (v3 > v1 && v3 < v2));
> +	
> +	if(loop_cnt == 1) { 
> +		/*We have a good chipset*/
> +		printk(KERN_INFO "PM Timer: Chipset passes port read test\n");
> +		pmtmr_rd_func.read_pmtmr = read_pmtmr_fast;
> +	}
> +	
> +	else {
> +		printk(KERN_INFO "PM Timer: Chipset fails port read test:");
> +	 	printk(KERN_INFO "Working around it.");
> +	}
>  
>  	/* "verify" this timing source */
> -	value1 = read_pmtmr();
> +	value1 = pmtmr_rd_func.read_pmtmr();
>  	for (i = 0; i < 10000; i++) {
>  		value2 = read_pmtmr();
>  		if (value2 == value1)
> @@ -156,7 +195,7 @@
>  
>  	write_seqlock(&monotonic_lock);
>  
> -	offset_tick = read_pmtmr();
> +	offset_tick = pmtmr_rd_func.read_pmtmr();
>  
>  	/* calculate tick interval */
>  	delta = (offset_tick - last_offset) & ACPI_PM_MASK;
> @@ -202,7 +241,7 @@
>  	} while (read_seqretry(&monotonic_lock, seq));
>  
>  	/* Read the pmtmr */
> -	this_offset =  read_pmtmr();
> +	this_offset =  pmtmr_rd_func.read_pmtmr();
>  
>  	/* convert to nanoseconds */
>  	ret = (this_offset - last_offset) & ACPI_PM_MASK;
> @@ -232,7 +271,7 @@
>  	u32 now, offset, delta = 0;
>  
>  	offset = offset_tick;
> -	now = read_pmtmr();
> +	now = pmtmr_rd_func.read_pmtmr();
>  	delta = (now - offset)&ACPI_PM_MASK;
>  
>  	return (unsigned long) offset_delay + cyc2us(delta);

-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Parag Warudkar]

> Since we do not interpolate, lost ticks no longer cause time problems
> (well, unless you're using the jiffies timesource). 
> 

That's certainly cool - no longer lost ticks!

> > Sadly, it somehow feels noticeably slower than vanilla 2.6.12-rc5.
> > Especially using X/KDE - It is surely usable but not snappy. I will do
> > more research to find out exactly why - but before that is such as
> > loss of snappiness possible due to the TOD changes?
> 
> Could you send me your dmesg output with and without using my patch? It
> could be you're using a different timesource.
> 

I can send the dmesg output later on - but when I checked it last it printed - "using acpi_pm".  Machine is a laptop and has nvidia chipset if that matters.

Parag

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[john stultz]

On Wed, 2005-06-01 at 20:37 -0400, Parag Warudkar wrote:
> On Wednesday 01 June 2005 19:13, john stultz wrote:
> > This patch converts the x86-64 arch to use the new timeofday
> > infrastructure. It applies on top of my timeofday-core_B1 patch.
> 
> This one fails to apply - time.c HUNK #1 gets rejected. (Attached)

Yea, sorry. My naming scheme isn't quite granular enough. The patch is
against Linus' git tree as of yesterday, not -rc5 vanilla. 

If you grab Linus' current tree it should apply.

Sorry about the confusion.
-john

Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[Parag Warudkar]

[-- Attachment #1: Type: text/plain, Size: 257 bytes --]

On Wednesday 01 June 2005 19:13, john stultz wrote:
> This patch converts the x86-64 arch to use the new timeofday
> infrastructure. It applies on top of my timeofday-core_B1 patch.

This one fails to apply - time.c HUNK #1 gets rejected. (Attached)

Parag

[-- Attachment #2: time.c.rej --]
[-- Type: text/x-csrc, Size: 489 bytes --]

***************
*** 26,35 ****
  #include <linux/sysdev.h>
  #include <linux/bcd.h>
  #include <linux/kallsyms.h>
- #include <linux/acpi.h>
- #ifdef CONFIG_ACPI
- #include <acpi/achware.h>	/* for PM timer frequency */
- #endif
  #include <asm/8253pit.h>
  #include <asm/pgtable.h>
  #include <asm/vsyscall.h>
--- 26,31 ----
  #include <linux/sysdev.h>
  #include <linux/bcd.h>
  #include <linux/kallsyms.h>
  #include <asm/8253pit.h>
  #include <asm/pgtable.h>
  #include <asm/vsyscall.h>

[PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[john stultz]

Andi, All,
	I'm just re-spinning this to resolve a conflict w/ the CPUFREQ changes
Linus accepted last night.

This patch converts the x86-64 arch to use the new timeofday
infrastructure. It applies on top of my timeofday-core_B1 patch. This is
a full conversion, so most of this patch is subtractions removing the
existing arch specific time keeping code. This patch does not provide
any x86-64 timesources, so using this patch alone on top of the
timeofday-core patch will only give you the jiffies timesource. To get
full replacements for the code being removed here, the following
timeofday-timesources-i386 patch (x86-64 shares the same timesources as
i386) will need to be applied.

Andi: I'd like to submit this to Andrew for inclusion into his tree for
testing, however I'd like to get an ACK from you first. Please let me
know if you have any feedback or suggestions.

thanks
-john

Signed-off-by: John Stultz <johnstul@us.ibm.com>

linux-2.6.12-rc5_timeofday-arch-x86-64_B1.patch
===============================================

Index: arch/i386/kernel/acpi/boot.c
===================================================================
--- 15eb8deaa5b22a81f97a9af307d81b0567115674/arch/i386/kernel/acpi/boot.c  (mode:100644)
+++ 85c83ea7c8c2d1f7e94ba65fa8d2a77d1022c973/arch/i386/kernel/acpi/boot.c  (mode:100644)
@@ -547,7 +547,7 @@
 
 
 #ifdef CONFIG_HPET_TIMER
-
+#include <asm/hpet.h>
 static int __init acpi_parse_hpet(unsigned long phys, unsigned long size)
 {
 	struct acpi_table_hpet *hpet_tbl;
@@ -570,18 +570,12 @@
 #ifdef	CONFIG_X86_64
         vxtime.hpet_address = hpet_tbl->addr.addrl |
                 ((long) hpet_tbl->addr.addrh << 32);
-
-        printk(KERN_INFO PREFIX "HPET id: %#x base: %#lx\n",
-               hpet_tbl->id, vxtime.hpet_address);
+	hpet_address = vxtime.hpet_address;
 #else	/* X86 */
-	{
-		extern unsigned long hpet_address;
-
 		hpet_address = hpet_tbl->addr.addrl;
+#endif	/* X86 */
 		printk(KERN_INFO PREFIX "HPET id: %#x base: %#lx\n",
 			hpet_tbl->id, hpet_address);
-	}
-#endif	/* X86 */
 
 	return 0;
 }
Index: arch/x86_64/Kconfig
===================================================================
--- 15eb8deaa5b22a81f97a9af307d81b0567115674/arch/x86_64/Kconfig  (mode:100644)
+++ 85c83ea7c8c2d1f7e94ba65fa8d2a77d1022c973/arch/x86_64/Kconfig  (mode:100644)
@@ -24,6 +24,14 @@
 	bool
 	default y
 
+config NEWTOD
+       bool
+       default y
+
+config NEWTOD_VSYSCALL
+       bool
+       default y
+
 config MMU
 	bool
 	default y
Index: arch/x86_64/kernel/Makefile
===================================================================
--- 15eb8deaa5b22a81f97a9af307d81b0567115674/arch/x86_64/kernel/Makefile  (mode:100644)
+++ 85c83ea7c8c2d1f7e94ba65fa8d2a77d1022c973/arch/x86_64/kernel/Makefile  (mode:100644)
@@ -28,7 +28,6 @@
 obj-$(CONFIG_DUMMY_IOMMU)	+= pci-nommu.o pci-dma.o
 obj-$(CONFIG_SWIOTLB)		+= swiotlb.o
 obj-$(CONFIG_KPROBES)		+= kprobes.o
-obj-$(CONFIG_X86_PM_TIMER)	+= pmtimer.o
 
 obj-$(CONFIG_MODULES)		+= module.o
 
Index: arch/x86_64/kernel/pmtimer.c
===================================================================
--- 15eb8deaa5b22a81f97a9af307d81b0567115674/arch/x86_64/kernel/pmtimer.c  (mode:100644)
+++ /dev/null  (tree:85c83ea7c8c2d1f7e94ba65fa8d2a77d1022c973)
@@ -1,101 +0,0 @@
-/* Ported over from i386 by AK, original copyright was:
- *
- * (C) Dominik Brodowski <linux@brodo.de> 2003
- *
- * Driver to use the Power Management Timer (PMTMR) available in some
- * southbridges as primary timing source for the Linux kernel.
- *
- * Based on parts of linux/drivers/acpi/hardware/hwtimer.c, timer_pit.c,
- * timer_hpet.c, and on Arjan van de Ven's implementation for 2.4.
- *
- * This file is licensed under the GPL v2.
- *
- * Dropped all the hardware bug workarounds for now. Hopefully they
- * are not needed on 64bit chipsets.
- */
-
-#include <linux/jiffies.h>
-#include <linux/kernel.h>
-#include <linux/time.h>
-#include <linux/init.h>
-#include <linux/cpumask.h>
-#include <asm/io.h>
-#include <asm/proto.h>
-#include <asm/msr.h>
-#include <asm/vsyscall.h>
-
-/* The I/O port the PMTMR resides at.
- * The location is detected during setup_arch(),
- * in arch/i386/kernel/acpi/boot.c */
-u32 pmtmr_ioport;
-
-/* value of the Power timer at last timer interrupt */
-static u32 offset_delay;
-static u32 last_pmtmr_tick;
-
-#define ACPI_PM_MASK 0xFFFFFF /* limit it to 24 bits */
-
-static inline u32 cyc2us(u32 cycles)
-{
-	/* The Power Management Timer ticks at 3.579545 ticks per microsecond.
-	 * 1 / PM_TIMER_FREQUENCY == 0.27936511 =~ 286/1024 [error: 0.024%]
-	 *
-	 * Even with HZ = 100, delta is at maximum 35796 ticks, so it can
-	 * easily be multiplied with 286 (=0x11E) without having to fear
-	 * u32 overflows.
-	 */
-	cycles *= 286;
-	return (cycles >> 10);
-}
-
-int pmtimer_mark_offset(void)
-{
-	static int first_run = 1;
-	unsigned long tsc;
-	u32 lost;
-
-	u32 tick = inl(pmtmr_ioport);
-	u32 delta;
-
-	delta = cyc2us((tick - last_pmtmr_tick) & ACPI_PM_MASK);
-
-	last_pmtmr_tick = tick;
-	monotonic_base += delta * NSEC_PER_USEC;
-
-	delta += offset_delay;
-
-	lost = delta / (USEC_PER_SEC / HZ);
-	offset_delay = delta % (USEC_PER_SEC / HZ);
-
-	rdtscll(tsc);
-	vxtime.last_tsc = tsc - offset_delay * cpu_khz;
-
-	/* don't calculate delay for first run,
-	   or if we've got less then a tick */
-	if (first_run || (lost < 1)) {
-		first_run = 0;
-		offset_delay = 0;
-	}
-
-	return lost - 1;
-}
-
-unsigned int do_gettimeoffset_pm(void)
-{
-	u32 now, offset, delta = 0;
-
-	offset = last_pmtmr_tick;
-	now = inl(pmtmr_ioport);
-	delta = (now - offset) & ACPI_PM_MASK;
-
-	return offset_delay + cyc2us(delta);
-}
-
-
-static int __init nopmtimer_setup(char *s)
-{
-	pmtmr_ioport = 0;
-	return 0;
-}
-
-__setup("nopmtimer", nopmtimer_setup);
Index: arch/x86_64/kernel/time.c
===================================================================
--- 15eb8deaa5b22a81f97a9af307d81b0567115674/arch/x86_64/kernel/time.c  (mode:100644)
+++ 85c83ea7c8c2d1f7e94ba65fa8d2a77d1022c973/arch/x86_64/kernel/time.c  (mode:100644)
@@ -26,10 +26,6 @@
 #include <linux/sysdev.h>
 #include <linux/bcd.h>
 #include <linux/kallsyms.h>
-#include <linux/acpi.h>
-#ifdef CONFIG_ACPI
-#include <acpi/achware.h>	/* for PM timer frequency */
-#endif
 #include <asm/8253pit.h>
 #include <asm/pgtable.h>
 #include <asm/vsyscall.h>
@@ -39,6 +35,7 @@
 #include <asm/sections.h>
 #include <linux/cpufreq.h>
 #include <linux/hpet.h>
+#include <linux/timeofday.h>
 #ifdef CONFIG_X86_LOCAL_APIC
 #include <asm/apic.h>
 #endif
@@ -47,9 +44,6 @@
 
 EXPORT_SYMBOL(jiffies_64);
 
-#ifdef CONFIG_CPU_FREQ
-static void cpufreq_delayed_get(void);
-#endif
 extern void i8254_timer_resume(void);
 extern int using_apic_timer;
 
@@ -62,6 +56,7 @@
 #undef HPET_HACK_ENABLE_DANGEROUS
 
 unsigned int cpu_khz;					/* TSC clocks / usec, not used here */
+unsigned long hpet_address;
 static unsigned long hpet_period;			/* fsecs / HPET clock */
 unsigned long hpet_tick;				/* HPET clocks / interrupt */
 unsigned long vxtime_hz = PIT_TICK_RATE;
@@ -83,108 +78,6 @@
 	rdtscll(*tsc);
 }
 
-/*
- * do_gettimeoffset() returns microseconds since last timer interrupt was
- * triggered by hardware. A memory read of HPET is slower than a register read
- * of TSC, but much more reliable. It's also synchronized to the timer
- * interrupt. Note that do_gettimeoffset() may return more than hpet_tick, if a
- * timer interrupt has happened already, but vxtime.trigger wasn't updated yet.
- * This is not a problem, because jiffies hasn't updated either. They are bound
- * together by xtime_lock.
- */
-
-static inline unsigned int do_gettimeoffset_tsc(void)
-{
-	unsigned long t;
-	unsigned long x;
-	rdtscll_sync(&t);
-	if (t < vxtime.last_tsc) t = vxtime.last_tsc; /* hack */
-	x = ((t - vxtime.last_tsc) * vxtime.tsc_quot) >> 32;
-	return x;
-}
-
-static inline unsigned int do_gettimeoffset_hpet(void)
-{
-	return ((hpet_readl(HPET_COUNTER) - vxtime.last) * vxtime.quot) >> 32;
-}
-
-unsigned int (*do_gettimeoffset)(void) = do_gettimeoffset_tsc;
-
-/*
- * This version of gettimeofday() has microsecond resolution and better than
- * microsecond precision, as we're using at least a 10 MHz (usually 14.31818
- * MHz) HPET timer.
- */
-
-void do_gettimeofday(struct timeval *tv)
-{
-	unsigned long seq, t;
- 	unsigned int sec, usec;
-
-	do {
-		seq = read_seqbegin(&xtime_lock);
-
-		sec = xtime.tv_sec;
-		usec = xtime.tv_nsec / 1000;
-
-		/* i386 does some correction here to keep the clock 
-		   monotonous even when ntpd is fixing drift.
-		   But they didn't work for me, there is a non monotonic
-		   clock anyways with ntp.
-		   I dropped all corrections now until a real solution can
-		   be found. Note when you fix it here you need to do the same
-		   in arch/x86_64/kernel/vsyscall.c and export all needed
-		   variables in vmlinux.lds. -AK */ 
-
-		t = (jiffies - wall_jiffies) * (1000000L / HZ) +
-			do_gettimeoffset();
-		usec += t;
-
-	} while (read_seqretry(&xtime_lock, seq));
-
-	tv->tv_sec = sec + usec / 1000000;
-	tv->tv_usec = usec % 1000000;
-}
-
-EXPORT_SYMBOL(do_gettimeofday);
-
-/*
- * settimeofday() first undoes the correction that gettimeofday would do
- * on the time, and then saves it. This is ugly, but has been like this for
- * ages already.
- */
-
-int do_settimeofday(struct timespec *tv)
-{
-	time_t wtm_sec, sec = tv->tv_sec;
-	long wtm_nsec, nsec = tv->tv_nsec;
-
-	if ((unsigned long)tv->tv_nsec >= NSEC_PER_SEC)
-		return -EINVAL;
-
-	write_seqlock_irq(&xtime_lock);
-
-	nsec -= do_gettimeoffset() * 1000 +
-		(jiffies - wall_jiffies) * (NSEC_PER_SEC/HZ);
-
-	wtm_sec  = wall_to_monotonic.tv_sec + (xtime.tv_sec - sec);
-	wtm_nsec = wall_to_monotonic.tv_nsec + (xtime.tv_nsec - nsec);
-
-	set_normalized_timespec(&xtime, sec, nsec);
-	set_normalized_timespec(&wall_to_monotonic, wtm_sec, wtm_nsec);
-
-	time_adjust = 0;		/* stop active adjtime() */
-	time_status |= STA_UNSYNC;
-	time_maxerror = NTP_PHASE_LIMIT;
-	time_esterror = NTP_PHASE_LIMIT;
-
-	write_sequnlock_irq(&xtime_lock);
-	clock_was_set();
-	return 0;
-}
-
-EXPORT_SYMBOL(do_settimeofday);
-
 unsigned long profile_pc(struct pt_regs *regs)
 {
 	unsigned long pc = instruction_pointer(regs);
@@ -284,90 +177,8 @@
 	spin_unlock(&rtc_lock);
 }
 
-
-/* monotonic_clock(): returns # of nanoseconds passed since time_init()
- *		Note: This function is required to return accurate
- *		time even in the absence of multiple timer ticks.
- */
-unsigned long long monotonic_clock(void)
-{
-	unsigned long seq;
- 	u32 last_offset, this_offset, offset;
-	unsigned long long base;
-
-	if (vxtime.mode == VXTIME_HPET) {
-		do {
-			seq = read_seqbegin(&xtime_lock);
-
-			last_offset = vxtime.last;
-			base = monotonic_base;
-			this_offset = hpet_readl(HPET_T0_CMP) - hpet_tick;
-
-		} while (read_seqretry(&xtime_lock, seq));
-		offset = (this_offset - last_offset);
-		offset *=(NSEC_PER_SEC/HZ)/hpet_tick;
-		return base + offset;
-	}else{
-		do {
-			seq = read_seqbegin(&xtime_lock);
-
-			last_offset = vxtime.last_tsc;
-			base = monotonic_base;
-		} while (read_seqretry(&xtime_lock, seq));
-		sync_core();
-		rdtscll(this_offset);
-		offset = (this_offset - last_offset)*1000/cpu_khz; 
-		return base + offset;
-	}
-
-
-}
-EXPORT_SYMBOL(monotonic_clock);
-
-static noinline void handle_lost_ticks(int lost, struct pt_regs *regs)
-{
-    static long lost_count;
-    static int warned;
-
-    if (report_lost_ticks) {
-	    printk(KERN_WARNING "time.c: Lost %d timer "
-		   "tick(s)! ", lost);
-	    print_symbol("rip %s)\n", regs->rip);
-    }
-
-    if (lost_count == 1000 && !warned) {
-	    printk(KERN_WARNING
-		   "warning: many lost ticks.\n"
-		   KERN_WARNING "Your time source seems to be instable or "
-		   		"some driver is hogging interupts\n");
-	    print_symbol("rip %s\n", regs->rip);
-	    if (vxtime.mode == VXTIME_TSC && vxtime.hpet_address) {
-		    printk(KERN_WARNING "Falling back to HPET\n");
-		    vxtime.last = hpet_readl(HPET_T0_CMP) - hpet_tick;
-		    vxtime.mode = VXTIME_HPET;
-		    do_gettimeoffset = do_gettimeoffset_hpet;
-	    }
-	    /* else should fall back to PIT, but code missing. */
-	    warned = 1;
-    } else
-	    lost_count++;
-
-#ifdef CONFIG_CPU_FREQ
-    /* In some cases the CPU can change frequency without us noticing
-       (like going into thermal throttle)
-       Give cpufreq a change to catch up. */
-    if ((lost_count+1) % 25 == 0) {
-	    cpufreq_delayed_get();
-    }
-#endif
-}
-
 static irqreturn_t timer_interrupt(int irq, void *dev_id, struct pt_regs *regs)
 {
-	static unsigned long rtc_update = 0;
-	unsigned long tsc;
-	int delay, offset = 0, lost = 0;
-
 /*
  * Here we are in the timer irq handler. We have irqs locally disabled (so we
  * don't need spin_lock_irqsave()) but we don't know if the timer_bh is running
@@ -377,60 +188,6 @@
 
 	write_seqlock(&xtime_lock);
 
-	if (vxtime.hpet_address) {
-		offset = hpet_readl(HPET_T0_CMP) - hpet_tick;
-		delay = hpet_readl(HPET_COUNTER) - offset;
-	} else {
-		spin_lock(&i8253_lock);
-		outb_p(0x00, 0x43);
-		delay = inb_p(0x40);
-		delay |= inb(0x40) << 8;
-		spin_unlock(&i8253_lock);
-		delay = LATCH - 1 - delay;
-	}
-
-	rdtscll_sync(&tsc);
-
-	if (vxtime.mode == VXTIME_HPET) {
-		if (offset - vxtime.last > hpet_tick) {
-			lost = (offset - vxtime.last) / hpet_tick - 1;
-		}
-
-		monotonic_base += 
-			(offset - vxtime.last)*(NSEC_PER_SEC/HZ) / hpet_tick;
-
-		vxtime.last = offset;
-#ifdef CONFIG_X86_PM_TIMER
-	} else if (vxtime.mode == VXTIME_PMTMR) {
-		lost = pmtimer_mark_offset();
-#endif
-	} else {
-		offset = (((tsc - vxtime.last_tsc) *
-			   vxtime.tsc_quot) >> 32) - (USEC_PER_SEC / HZ);
-
-		if (offset < 0)
-			offset = 0;
-
-		if (offset > (USEC_PER_SEC / HZ)) {
-			lost = offset / (USEC_PER_SEC / HZ);
-			offset %= (USEC_PER_SEC / HZ);
-		}
-
-		monotonic_base += (tsc - vxtime.last_tsc)*1000000/cpu_khz ;
-
-		vxtime.last_tsc = tsc - vxtime.quot * delay / vxtime.tsc_quot;
-
-		if ((((tsc - vxtime.last_tsc) *
-		      vxtime.tsc_quot) >> 32) < offset)
-			vxtime.last_tsc = tsc -
-				(((long) offset << 32) / vxtime.tsc_quot) - 1;
-	}
-
-	if (lost > 0) {
-		handle_lost_ticks(lost, regs);
-		jiffies += lost;
-	}
-
 /*
  * Do the timer stuff.
  */
@@ -453,20 +210,6 @@
 		smp_local_timer_interrupt(regs);
 #endif
 
-/*
- * If we have an externally synchronized Linux clock, then update CMOS clock
- * accordingly every ~11 minutes. set_rtc_mmss() will be called in the jiffy
- * closest to exactly 500 ms before the next second. If the update fails, we
- * don't care, as it'll be updated on the next turn, and the problem (time way
- * off) isn't likely to go away much sooner anyway.
- */
-
-	if ((~time_status & STA_UNSYNC) && xtime.tv_sec > rtc_update &&
-		abs(xtime.tv_nsec - 500000000) <= tick_nsec / 2) {
-		set_rtc_mmss(xtime.tv_sec);
-		rtc_update = xtime.tv_sec + 660;
-	}
- 
 	write_sequnlock(&xtime_lock);
 
 	return IRQ_HANDLED;
@@ -567,6 +310,30 @@
 	return mktime(year, mon, day, hour, min, sec);
 }
 
+/* arch specific timeofday hooks */
+nsec_t read_persistent_clock(void)
+{
+	return (nsec_t)get_cmos_time() * NSEC_PER_SEC;
+}
+
+void sync_persistent_clock(struct timespec ts)
+{
+	static unsigned long rtc_update = 0;
+	/*
+	 * If we have an externally synchronized Linux clock, then update
+	 * CMOS clock accordingly every ~11 minutes. set_rtc_mmss() will
+	 * be called in the jiffy closest to exactly 500 ms before the
+	 * next second. If the update fails, we don't care, as it'll be
+	 * updated on the next turn, and the problem (time way off) isn't
+	 * likely to go away much sooner anyway.
+	 */
+	if (ts.tv_sec > rtc_update &&
+		abs(ts.tv_nsec - 500000000) <= tick_nsec / 2) {
+		set_rtc_mmss(xtime.tv_sec);
+		rtc_update = xtime.tv_sec + 660;
+	}
+}
+
 #ifdef CONFIG_CPU_FREQ
 
 /* Frequency scaling support. Adjust the TSC based timer when the cpu frequency
@@ -594,23 +361,6 @@
 	cpufreq_delayed_issched = 0;
 }
 
-/* if we notice lost ticks, schedule a call to cpufreq_get() as it tries
- * to verify the CPU frequency the timing core thinks the CPU is running
- * at is still correct.
- */
-static void cpufreq_delayed_get(void)
-{
-	static int warned;
-	if (cpufreq_init && !cpufreq_delayed_issched) {
-		cpufreq_delayed_issched = 1;
-		if (!warned) {
-			warned = 1;
-			printk(KERN_DEBUG "Losing some ticks... checking if CPU frequency changed.\n");
-		}
-		schedule_work(&cpufreq_delayed_get_work);
-	}
-}
-
 static unsigned int  ref_freq = 0;
 static unsigned long loops_per_jiffy_ref = 0;
 
@@ -906,13 +656,6 @@
 			hpet_period;
 		cpu_khz = hpet_calibrate_tsc();
 		timename = "HPET";
-#ifdef CONFIG_X86_PM_TIMER
-	} else if (pmtmr_ioport) {
-		vxtime_hz = PM_TIMER_FREQUENCY;
-		timename = "PM";
-		pit_init();
-		cpu_khz = pit_calibrate_tsc();
-#endif
 	} else {
 		pit_init();
 		cpu_khz = pit_calibrate_tsc();
@@ -963,31 +706,8 @@
  */
 void __init time_init_gtod(void)
 {
-	char *timetype;
-
 	if (unsynchronized_tsc())
 		notsc = 1;
-	if (vxtime.hpet_address && notsc) {
-		timetype = "HPET";
-		vxtime.last = hpet_readl(HPET_T0_CMP) - hpet_tick;
-		vxtime.mode = VXTIME_HPET;
-		do_gettimeoffset = do_gettimeoffset_hpet;
-#ifdef CONFIG_X86_PM_TIMER
-	/* Using PM for gettimeofday is quite slow, but we have no other
-	   choice because the TSC is too unreliable on some systems. */
-	} else if (pmtmr_ioport && !vxtime.hpet_address && notsc) {
-		timetype = "PM";
-		do_gettimeoffset = do_gettimeoffset_pm;
-		vxtime.mode = VXTIME_PMTMR;
-		sysctl_vsyscall = 0;
-		printk(KERN_INFO "Disabling vsyscall due to use of PM timer\n");
-#endif
-	} else {
-		timetype = vxtime.hpet_address ? "HPET/TSC" : "PIT/TSC";
-		vxtime.mode = VXTIME_TSC;
-	}
-
-	printk(KERN_INFO "time.c: Using %s based timekeeping.\n", timetype);
 }
 
 __setup("report_lost_ticks", time_setup);
@@ -1010,7 +730,6 @@
 
 static int timer_resume(struct sys_device *dev)
 {
-	unsigned long flags;
 	unsigned long sec;
 	unsigned long ctime = get_cmos_time();
 	unsigned long sleep_length = (ctime - sleep_start) * HZ;
@@ -1021,10 +740,6 @@
 		i8254_timer_resume();
 
 	sec = ctime + clock_cmos_diff;
-	write_seqlock_irqsave(&xtime_lock,flags);
-	xtime.tv_sec = sec;
-	xtime.tv_nsec = 0;
-	write_sequnlock_irqrestore(&xtime_lock,flags);
 	jiffies += sleep_length;
 	wall_jiffies += sleep_length;
 	return 0;
Index: arch/x86_64/kernel/vmlinux.lds.S
===================================================================
--- 15eb8deaa5b22a81f97a9af307d81b0567115674/arch/x86_64/kernel/vmlinux.lds.S  (mode:100644)
+++ 85c83ea7c8c2d1f7e94ba65fa8d2a77d1022c973/arch/x86_64/kernel/vmlinux.lds.S  (mode:100644)
@@ -71,6 +71,13 @@
   . = ALIGN(CONFIG_X86_L1_CACHE_BYTES);
   .jiffies : AT CACHE_ALIGN(AFTER(.xtime)) { *(.jiffies) }
   jiffies = LOADADDR(.jiffies);
+
+  .vsyscall_gtod_data : AT AFTER(.jiffies) { *(.vsyscall_gtod_data) }
+  vsyscall_gtod_data = LOADADDR(.vsyscall_gtod_data);
+  .vsyscall_gtod_lock : AT AFTER(.vsyscall_gtod_data) { *(.vsyscall_gtod_lock) }
+  vsyscall_gtod_lock = LOADADDR(.vsyscall_gtod_lock);
+
+
   .vsyscall_1 ADDR(.vsyscall_0) + 1024: AT (LOADADDR(.vsyscall_0) + 1024) { *(.vsyscall_1) }
   . = LOADADDR(.vsyscall_0) + 4096;
 
Index: arch/x86_64/kernel/vsyscall.c
===================================================================
--- 15eb8deaa5b22a81f97a9af307d81b0567115674/arch/x86_64/kernel/vsyscall.c  (mode:100644)
+++ 85c83ea7c8c2d1f7e94ba65fa8d2a77d1022c973/arch/x86_64/kernel/vsyscall.c  (mode:100644)
@@ -19,6 +19,8 @@
  *  want per guest time just set the kernel.vsyscall64 sysctl to 0.
  */
 
+#include <linux/timeofday.h>
+#include <linux/timesource.h>
 #include <linux/time.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
@@ -40,6 +42,21 @@
 int __sysctl_vsyscall __section_sysctl_vsyscall = 1;
 seqlock_t __xtime_lock __section_xtime_lock = SEQLOCK_UNLOCKED;
 
+
+struct vsyscall_gtod_data_t {
+	struct timeval wall_time_tv;
+	struct timezone sys_tz;
+	cycle_t offset_base;
+	struct timesource_t timesource;
+};
+
+extern struct vsyscall_gtod_data_t vsyscall_gtod_data;
+struct vsyscall_gtod_data_t __vsyscall_gtod_data __section_vsyscall_gtod_data;
+
+extern seqlock_t vsyscall_gtod_lock;
+seqlock_t __vsyscall_gtod_lock __section_vsyscall_gtod_lock = SEQLOCK_UNLOCKED;
+
+
 #include <asm/unistd.h>
 
 static force_inline void timeval_normalize(struct timeval * tv)
@@ -53,40 +70,54 @@
 	}
 }
 
-static force_inline void do_vgettimeofday(struct timeval * tv)
+/* XXX - this is ugly. gettimeofday() has a label in it so we can't
+	call it twice.
+ */
+static force_inline int syscall_gtod(struct timeval *tv, struct timezone *tz)
 {
-	long sequence, t;
-	unsigned long sec, usec;
-
+	int ret;
+	asm volatile("syscall"
+		: "=a" (ret)
+		: "0" (__NR_gettimeofday),"D" (tv),"S" (tz) : __syscall_clobber );
+	return ret;
+}
+static force_inline void do_vgettimeofday(struct timeval* tv)
+{
+	cycle_t now, cycle_delta;
+	nsec_t nsec_delta;
+	unsigned long seq;
 	do {
-		sequence = read_seqbegin(&__xtime_lock);
-		
-		sec = __xtime.tv_sec;
-		usec = (__xtime.tv_nsec / 1000) +
-			(__jiffies - __wall_jiffies) * (1000000 / HZ);
-
-		if (__vxtime.mode != VXTIME_HPET) {
-			sync_core();
-			rdtscll(t);
-			if (t < __vxtime.last_tsc)
-				t = __vxtime.last_tsc;
-			usec += ((t - __vxtime.last_tsc) *
-				 __vxtime.tsc_quot) >> 32;
-			/* See comment in x86_64 do_gettimeofday. */
-		} else {
-			usec += ((readl((void *)fix_to_virt(VSYSCALL_HPET) + 0xf0) -
-				  __vxtime.last) * __vxtime.quot) >> 32;
+		seq = read_seqbegin(&__vsyscall_gtod_lock);
+
+		if (__vsyscall_gtod_data.timesource.type == TIMESOURCE_FUNCTION) {
+			syscall_gtod(tv, NULL);
+			return;
 		}
-	} while (read_seqretry(&__xtime_lock, sequence));
 
-	tv->tv_sec = sec + usec / 1000000;
-	tv->tv_usec = usec % 1000000;
+		/* read the timeosurce and calc cycle_delta */
+		now = read_timesource(&__vsyscall_gtod_data.timesource);
+		cycle_delta = (now - __vsyscall_gtod_data.offset_base)
+					& __vsyscall_gtod_data.timesource.mask;
+
+		/* convert cycles to nsecs */
+		nsec_delta = cycle_delta * __vsyscall_gtod_data.timesource.mult;
+		nsec_delta = nsec_delta >> __vsyscall_gtod_data.timesource.shift;
+
+		/* add nsec offset to wall_time_tv */
+		*tv = __vsyscall_gtod_data.wall_time_tv;
+		do_div(nsec_delta, NSEC_PER_USEC);
+		tv->tv_usec += (unsigned long) nsec_delta;
+		while (tv->tv_usec > USEC_PER_SEC) {
+			tv->tv_sec += 1;
+			tv->tv_usec -= USEC_PER_SEC;
+		}
+	} while (read_seqretry(&__vsyscall_gtod_lock, seq));
 }
 
 /* RED-PEN may want to readd seq locking, but then the variable should be write-once. */
 static force_inline void do_get_tz(struct timezone * tz)
 {
-	*tz = __sys_tz;
+	*tz = __vsyscall_gtod_data.sys_tz;
 }
 
 static force_inline int gettimeofday(struct timeval *tv, struct timezone *tz)
@@ -118,15 +149,15 @@
 	return 0;
 }
 
-/* This will break when the xtime seconds get inaccurate, but that is
- * unlikely */
 static time_t __vsyscall(1) vtime(time_t *t)
 {
+	struct timeval tv;
 	if (unlikely(!__sysctl_vsyscall))
 		return time_syscall(t);
-	else if (t)
-		*t = __xtime.tv_sec;		
-	return __xtime.tv_sec;
+	vgettimeofday(&tv, 0);
+	if (t)
+		*t = tv.tv_sec;
+	return tv.tv_sec;
 }
 
 static long __vsyscall(2) venosys_0(void)
@@ -139,6 +170,48 @@
 	return -ENOSYS;
 }
 
+struct timesource_t* curr_timesource;
+
+void arch_update_vsyscall_gtod(nsec_t wall_time, cycle_t offset_base,
+				struct timesource_t* timesource, int ntp_adj)
+{
+	unsigned long flags;
+
+	write_seqlock_irqsave(&vsyscall_gtod_lock, flags);
+
+	/* XXX - hackitty hack hack. this is terrible! */
+	if (curr_timesource != timesource) {
+		if ((timesource->type == TIMESOURCE_MMIO_32)
+				|| (timesource->type == TIMESOURCE_MMIO_64)) {
+			unsigned long vaddr = (unsigned long)timesource->mmio_ptr;
+			pgd_t *pgd = pgd_offset_k(vaddr);
+			pud_t *pud = pud_offset(pgd, vaddr);
+			pmd_t *pmd = pmd_offset(pud,vaddr);
+			pte_t *pte = pte_offset_kernel(pmd, vaddr);
+			*pte = pte_mkread(*pte);
+		}
+		curr_timesource = timesource;
+	}
+
+	/* save off wall time as timeval */
+	vsyscall_gtod_data.wall_time_tv = ns_to_timeval(wall_time);
+
+	/* save offset_base */
+	vsyscall_gtod_data.offset_base = offset_base;
+
+	/* copy current timesource */
+	vsyscall_gtod_data.timesource = *timesource;
+
+	/* apply ntp adjustment to timesource mult */
+	vsyscall_gtod_data.timesource.mult += ntp_adj;
+
+	/* save off current timezone */
+	vsyscall_gtod_data.sys_tz = sys_tz;
+
+	write_sequnlock_irqrestore(&vsyscall_gtod_lock, flags);
+
+}
+
 #ifdef CONFIG_SYSCTL
 
 #define SYSCALL 0x050f
@@ -217,6 +290,7 @@
 	BUG_ON((unsigned long) &vtime != VSYSCALL_ADDR(__NR_vtime));
 	BUG_ON((VSYSCALL_ADDR(0) != __fix_to_virt(VSYSCALL_FIRST_PAGE)));
 	map_vsyscall();
+	sysctl_vsyscall = 1;
 #ifdef CONFIG_SYSCTL
 	register_sysctl_table(kernel_root_table2, 0);
 #endif
Index: include/asm-generic/div64.h
===================================================================
--- 15eb8deaa5b22a81f97a9af307d81b0567115674/include/asm-generic/div64.h  (mode:100644)
+++ 85c83ea7c8c2d1f7e94ba65fa8d2a77d1022c973/include/asm-generic/div64.h  (mode:100644)
@@ -55,4 +55,13 @@
 
 #endif /* BITS_PER_LONG */
 
+#ifndef div_long_long_rem
+#define div_long_long_rem(dividend,divisor,remainder) \
+({							\
+	u64 result = dividend;				\
+	*remainder = do_div(result,divisor);		\
+	result;						\
+})
+#endif
+
 #endif /* _ASM_GENERIC_DIV64_H */
Index: include/asm-x86_64/hpet.h
===================================================================
--- 15eb8deaa5b22a81f97a9af307d81b0567115674/include/asm-x86_64/hpet.h  (mode:100644)
+++ 85c83ea7c8c2d1f7e94ba65fa8d2a77d1022c973/include/asm-x86_64/hpet.h  (mode:100644)
@@ -1,6 +1,6 @@
 #ifndef _ASM_X8664_HPET_H
 #define _ASM_X8664_HPET_H 1
-
+#include <asm/fixmap.h>
 /*
  * Documentation on HPET can be found at:
  *      http://www.intel.com/ial/home/sp/pcmmspec.htm
@@ -44,6 +44,7 @@
 #define HPET_TN_SETVAL		0x040
 #define HPET_TN_32BIT		0x100
 
+extern unsigned long hpet_address;	/* hpet memory map physical address */
 extern int is_hpet_enabled(void);
 extern int hpet_rtc_timer_init(void);
 extern int oem_force_hpet_timer(void);
Index: include/asm-x86_64/timeofday.h
===================================================================
--- /dev/null  (tree:15eb8deaa5b22a81f97a9af307d81b0567115674)
+++ 85c83ea7c8c2d1f7e94ba65fa8d2a77d1022c973/include/asm-x86_64/timeofday.h  (mode:100644)
@@ -0,0 +1,4 @@
+#ifndef _ASM_X86_64_TIMEOFDAY_H
+#define _ASM_X86_64_TIMEOFDAY_H
+#include <asm-generic/timeofday.h>
+#endif
Index: include/asm-x86_64/vsyscall.h
===================================================================
--- 15eb8deaa5b22a81f97a9af307d81b0567115674/include/asm-x86_64/vsyscall.h  (mode:100644)
+++ 85c83ea7c8c2d1f7e94ba65fa8d2a77d1022c973/include/asm-x86_64/vsyscall.h  (mode:100644)
@@ -22,6 +22,8 @@
 #define __section_sysctl_vsyscall __attribute__ ((unused, __section__ (".sysctl_vsyscall"), aligned(16)))
 #define __section_xtime __attribute__ ((unused, __section__ (".xtime"), aligned(16)))
 #define __section_xtime_lock __attribute__ ((unused, __section__ (".xtime_lock"), aligned(16)))
+#define __section_vsyscall_gtod_data __attribute__ ((unused, __section__ (".vsyscall_gtod_data"),aligned(16)))
+#define __section_vsyscall_gtod_lock __attribute__ ((unused, __section__ (".vsyscall_gtod_lock"),aligned(16)))
 
 #define VXTIME_TSC	1
 #define VXTIME_HPET	2