Re: hard lock-up with 4.14 git

[Prakash Punnoor]

On 13.10.2017 13:56, Markus Trippelsdorf wrote:
> On 2017.10.13 at 13:39 +0200, Prakash Punnoor wrote:
>> after some use (eg. compiling packages) the machine locks up hard. Magic
>> SysRq doesn't work.
>>
>> I had trouble bisecting the offending commit. This is my third try. And
>> it points to 94b1b03b519b81c494900cb112aa00ed205cc2d9 "x86/mm: Rework
>> lazy TLB mode and TLB freshness tracking".
>>
>> Does it make sense? It still locks up with master. Please let me know if
>> you need more infos. Please CC, as I am not subscribed.
> This is a known issue. The fix is here:
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1508009.html
>
Thanks for the pointer. The fix seems to work for me, too.

Regards,

Prakash

Re: hard lock-up with 4.14 git

[Prakash Punnoor]

On 13.10.2017 13:56, Markus Trippelsdorf wrote:
> On 2017.10.13 at 13:39 +0200, Prakash Punnoor wrote:
>> after some use (eg. compiling packages) the machine locks up hard. Magic
>> SysRq doesn't work.
>>
>> I had trouble bisecting the offending commit. This is my third try. And
>> it points to 94b1b03b519b81c494900cb112aa00ed205cc2d9 "x86/mm: Rework
>> lazy TLB mode and TLB freshness tracking".
>>
>> Does it make sense? It still locks up with master. Please let me know if
>> you need more infos. Please CC, as I am not subscribed.
> This is a known issue. The fix is here:
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1508009.html
>
Thanks for the pointer. The fix seems to work for me, too.

Regards,

Prakash

Re: hard lock-up with 4.14 git

[Prakash Punnoor]

On 13.10.2017 13:39, Prakash Punnoor wrote:
> Hi,
>
> after some use (eg. compiling packages) the machine locks up hard. Magic
> SysRq doesn't work.
>
> I had trouble bisecting the offending commit. This is my third try. And
> it points to 94b1b03b519b81c494900cb112aa00ed205cc2d9 "x86/mm: Rework
> lazy TLB mode and TLB freshness tracking".
>
> Does it make sense? It still locks up with master. Please let me know if
> you need more infos. Please CC, as I am not subscribed.
>
> Regards,
>
> Prakash
>

Hi again, I forgot the kernel config. It is attached now.

Regards,

Prakash

> PS: The log:
>
> git bisect start
> # good: [569dbb88e80deb68974ef6fdd6a13edb9d686261] Linux 4.13
> git bisect good 569dbb88e80deb68974ef6fdd6a13edb9d686261
> # bad: [2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e] Linux 4.14-rc1
> git bisect bad 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e
> # bad: [aae3dbb4776e7916b6cd442d00159bea27a695c1] Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
> git bisect bad aae3dbb4776e7916b6cd442d00159bea27a695c1
> # bad: [bf1d6b2c76eda86159519bf5c427b1fa8f51f733] Merge tag
> 'staging-4.14-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
> git bisect bad bf1d6b2c76eda86159519bf5c427b1fa8f51f733
> # good: [edc2988c548db05e33b921fed15821010bc74895] Merge branch 'linus'
> into locking/core, to fix up conflicts
> git bisect good edc2988c548db05e33b921fed15821010bc74895
> # bad: [04759194dc447ff0b9ef35bc641ce3bb076c2930] Merge tag
> 'arm64-upstream' of
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
> git bisect bad 04759194dc447ff0b9ef35bc641ce3bb076c2930
> # good: [5f82e71a001d14824a7728ad9e49f6aea420f161] Merge branch
> 'locking-core-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> git bisect good 5f82e71a001d14824a7728ad9e49f6aea420f161
> # bad: [f57091767add2b79d76aac41b83b192d8ba1dce7] Merge branch
> 'x86-cache-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> git bisect bad f57091767add2b79d76aac41b83b192d8ba1dce7
> # bad: [dd90cccffc20a15d8e4c3ac8813f4b6a6cd4766f] Merge branch
> 'timers-core-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> git bisect bad dd90cccffc20a15d8e4c3ac8813f4b6a6cd4766f
> # bad: [e505371dd83963caae1a37ead9524e8d997341be] x86/boot: Add early
> cmdline parsing for options with arguments
> git bisect bad e505371dd83963caae1a37ead9524e8d997341be
> # bad: [b9d05200bc12444c7778a49c9694d8382ed06aa8] x86/mm: Insure that
> boot memory areas are mapped properly
> git bisect bad b9d05200bc12444c7778a49c9694d8382ed06aa8
> # bad: [f7750a79568788473c5e8092ee58a52248f34329] x86, mpparse,
> x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap() for RAM mappings
> git bisect bad f7750a79568788473c5e8092ee58a52248f34329
> # bad: [cba4671af7550e008f7a7835f06df0763825bf3e] x86/mm: Disable PCID
> on 32-bit kernels
> git bisect bad cba4671af7550e008f7a7835f06df0763825bf3e
> # good: [b0579ade7cd82391360e959cc844e50a160e8a96] x86/mm: Track the
> TLB's tlb_gen and update the flushing algorithm
> git bisect good b0579ade7cd82391360e959cc844e50a160e8a96
> # bad: [43858b4f25cf0adc5c2ca9cf5ce5fdf2532941e5] x86/mm: Stop calling
> leave_mm() in idle code
> git bisect bad 43858b4f25cf0adc5c2ca9cf5ce5fdf2532941e5
> # bad: [94b1b03b519b81c494900cb112aa00ed205cc2d9] x86/mm: Rework lazy
> TLB mode and TLB freshness tracking
> git bisect bad 94b1b03b519b81c494900cb112aa00ed205cc2d9
> # first bad commit: [94b1b03b519b81c494900cb112aa00ed205cc2d9] x86/mm:
> Rework lazy TLB mode and TLB freshness tracking
>

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.13.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X8

Re: hard lock-up with 4.14 git

[Prakash Punnoor]

On 13.10.2017 13:39, Prakash Punnoor wrote:
> Hi,
>
> after some use (eg. compiling packages) the machine locks up hard. Magic
> SysRq doesn't work.
>
> I had trouble bisecting the offending commit. This is my third try. And
> it points to 94b1b03b519b81c494900cb112aa00ed205cc2d9 "x86/mm: Rework
> lazy TLB mode and TLB freshness tracking".
>
> Does it make sense? It still locks up with master. Please let me know if
> you need more infos. Please CC, as I am not subscribed.
>
> Regards,
>
> Prakash
>

Hi again, I forgot the kernel config. It is attached now.

Regards,

Prakash

> PS: The log:
>
> git bisect start
> # good: [569dbb88e80deb68974ef6fdd6a13edb9d686261] Linux 4.13
> git bisect good 569dbb88e80deb68974ef6fdd6a13edb9d686261
> # bad: [2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e] Linux 4.14-rc1
> git bisect bad 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e
> # bad: [aae3dbb4776e7916b6cd442d00159bea27a695c1] Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
> git bisect bad aae3dbb4776e7916b6cd442d00159bea27a695c1
> # bad: [bf1d6b2c76eda86159519bf5c427b1fa8f51f733] Merge tag
> 'staging-4.14-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
> git bisect bad bf1d6b2c76eda86159519bf5c427b1fa8f51f733
> # good: [edc2988c548db05e33b921fed15821010bc74895] Merge branch 'linus'
> into locking/core, to fix up conflicts
> git bisect good edc2988c548db05e33b921fed15821010bc74895
> # bad: [04759194dc447ff0b9ef35bc641ce3bb076c2930] Merge tag
> 'arm64-upstream' of
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
> git bisect bad 04759194dc447ff0b9ef35bc641ce3bb076c2930
> # good: [5f82e71a001d14824a7728ad9e49f6aea420f161] Merge branch
> 'locking-core-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> git bisect good 5f82e71a001d14824a7728ad9e49f6aea420f161
> # bad: [f57091767add2b79d76aac41b83b192d8ba1dce7] Merge branch
> 'x86-cache-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> git bisect bad f57091767add2b79d76aac41b83b192d8ba1dce7
> # bad: [dd90cccffc20a15d8e4c3ac8813f4b6a6cd4766f] Merge branch
> 'timers-core-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> git bisect bad dd90cccffc20a15d8e4c3ac8813f4b6a6cd4766f
> # bad: [e505371dd83963caae1a37ead9524e8d997341be] x86/boot: Add early
> cmdline parsing for options with arguments
> git bisect bad e505371dd83963caae1a37ead9524e8d997341be
> # bad: [b9d05200bc12444c7778a49c9694d8382ed06aa8] x86/mm: Insure that
> boot memory areas are mapped properly
> git bisect bad b9d05200bc12444c7778a49c9694d8382ed06aa8
> # bad: [f7750a79568788473c5e8092ee58a52248f34329] x86, mpparse,
> x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap() for RAM mappings
> git bisect bad f7750a79568788473c5e8092ee58a52248f34329
> # bad: [cba4671af7550e008f7a7835f06df0763825bf3e] x86/mm: Disable PCID
> on 32-bit kernels
> git bisect bad cba4671af7550e008f7a7835f06df0763825bf3e
> # good: [b0579ade7cd82391360e959cc844e50a160e8a96] x86/mm: Track the
> TLB's tlb_gen and update the flushing algorithm
> git bisect good b0579ade7cd82391360e959cc844e50a160e8a96
> # bad: [43858b4f25cf0adc5c2ca9cf5ce5fdf2532941e5] x86/mm: Stop calling
> leave_mm() in idle code
> git bisect bad 43858b4f25cf0adc5c2ca9cf5ce5fdf2532941e5
> # bad: [94b1b03b519b81c494900cb112aa00ed205cc2d9] x86/mm: Rework lazy
> TLB mode and TLB freshness tracking
> git bisect bad 94b1b03b519b81c494900cb112aa00ed205cc2d9
> # first bad commit: [94b1b03b519b81c494900cb112aa00ed205cc2d9] x86/mm:
> Rework lazy TLB mode and TLB freshness tracking
>

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.13.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X8

hard lock-up with 4.14 git

[Prakash Punnoor]

Hi,

after some use (eg. compiling packages) the machine locks up hard. Magic
SysRq doesn't work.

I had trouble bisecting the offending commit. This is my third try. And
it points to 94b1b03b519b81c494900cb112aa00ed205cc2d9 "x86/mm: Rework
lazy TLB mode and TLB freshness tracking".

Does it make sense? It still locks up with master. Please let me know if
you need more infos. Please CC, as I am not subscribed.

Regards,

Prakash


PS: The log:

git bisect start
# good: [569dbb88e80deb68974ef6fdd6a13edb9d686261] Linux 4.13
git bisect good 569dbb88e80deb68974ef6fdd6a13edb9d686261
# bad: [2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e] Linux 4.14-rc1
git bisect bad 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e
# bad: [aae3dbb4776e7916b6cd442d00159bea27a695c1] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect bad aae3dbb4776e7916b6cd442d00159bea27a695c1
# bad: [bf1d6b2c76eda86159519bf5c427b1fa8f51f733] Merge tag
'staging-4.14-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
git bisect bad bf1d6b2c76eda86159519bf5c427b1fa8f51f733
# good: [edc2988c548db05e33b921fed15821010bc74895] Merge branch 'linus'
into locking/core, to fix up conflicts
git bisect good edc2988c548db05e33b921fed15821010bc74895
# bad: [04759194dc447ff0b9ef35bc641ce3bb076c2930] Merge tag
'arm64-upstream' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
git bisect bad 04759194dc447ff0b9ef35bc641ce3bb076c2930
# good: [5f82e71a001d14824a7728ad9e49f6aea420f161] Merge branch
'locking-core-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 5f82e71a001d14824a7728ad9e49f6aea420f161
# bad: [f57091767add2b79d76aac41b83b192d8ba1dce7] Merge branch
'x86-cache-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad f57091767add2b79d76aac41b83b192d8ba1dce7
# bad: [dd90cccffc20a15d8e4c3ac8813f4b6a6cd4766f] Merge branch
'timers-core-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad dd90cccffc20a15d8e4c3ac8813f4b6a6cd4766f
# bad: [e505371dd83963caae1a37ead9524e8d997341be] x86/boot: Add early
cmdline parsing for options with arguments
git bisect bad e505371dd83963caae1a37ead9524e8d997341be
# bad: [b9d05200bc12444c7778a49c9694d8382ed06aa8] x86/mm: Insure that
boot memory areas are mapped properly
git bisect bad b9d05200bc12444c7778a49c9694d8382ed06aa8
# bad: [f7750a79568788473c5e8092ee58a52248f34329] x86, mpparse,
x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap() for RAM mappings
git bisect bad f7750a79568788473c5e8092ee58a52248f34329
# bad: [cba4671af7550e008f7a7835f06df0763825bf3e] x86/mm: Disable PCID
on 32-bit kernels
git bisect bad cba4671af7550e008f7a7835f06df0763825bf3e
# good: [b0579ade7cd82391360e959cc844e50a160e8a96] x86/mm: Track the
TLB's tlb_gen and update the flushing algorithm
git bisect good b0579ade7cd82391360e959cc844e50a160e8a96
# bad: [43858b4f25cf0adc5c2ca9cf5ce5fdf2532941e5] x86/mm: Stop calling
leave_mm() in idle code
git bisect bad 43858b4f25cf0adc5c2ca9cf5ce5fdf2532941e5
# bad: [94b1b03b519b81c494900cb112aa00ed205cc2d9] x86/mm: Rework lazy
TLB mode and TLB freshness tracking
git bisect bad 94b1b03b519b81c494900cb112aa00ed205cc2d9
# first bad commit: [94b1b03b519b81c494900cb112aa00ed205cc2d9] x86/mm:
Rework lazy TLB mode and TLB freshness tracking

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 16
model   : 5
model name  : AMD Phenom(tm) II X4 840 Processor
stepping: 3
microcode   : 0x1c8
cpu MHz : 3201.034
cache size  : 512 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid 
extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy 
abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall npt 
lbrv svm_lock nrip_save
bugs: tlb_mmatch fxsave_leak sysret_ss_attrs null_seg amd_e400
bogomips: 6400.76
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor   : 1
vendor_id   : AuthenticAMD
cpu family  : 16
model   : 5
model name  : AMD Phenom(tm) II X4 840 Processor
stepping: 3
microcode   : 0x1c8
cpu MHz : 3201.034
cache size  : 512 KB
physical id : 0
siblings: 4
core id : 1
cpu cores   : 4
apicid  : 1
initial apicid  : 1
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 

hard lock-up with 4.14 git

[Prakash Punnoor]

Hi,

after some use (eg. compiling packages) the machine locks up hard. Magic
SysRq doesn't work.

I had trouble bisecting the offending commit. This is my third try. And
it points to 94b1b03b519b81c494900cb112aa00ed205cc2d9 "x86/mm: Rework
lazy TLB mode and TLB freshness tracking".

Does it make sense? It still locks up with master. Please let me know if
you need more infos. Please CC, as I am not subscribed.

Regards,

Prakash


PS: The log:

git bisect start
# good: [569dbb88e80deb68974ef6fdd6a13edb9d686261] Linux 4.13
git bisect good 569dbb88e80deb68974ef6fdd6a13edb9d686261
# bad: [2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e] Linux 4.14-rc1
git bisect bad 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e
# bad: [aae3dbb4776e7916b6cd442d00159bea27a695c1] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect bad aae3dbb4776e7916b6cd442d00159bea27a695c1
# bad: [bf1d6b2c76eda86159519bf5c427b1fa8f51f733] Merge tag
'staging-4.14-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
git bisect bad bf1d6b2c76eda86159519bf5c427b1fa8f51f733
# good: [edc2988c548db05e33b921fed15821010bc74895] Merge branch 'linus'
into locking/core, to fix up conflicts
git bisect good edc2988c548db05e33b921fed15821010bc74895
# bad: [04759194dc447ff0b9ef35bc641ce3bb076c2930] Merge tag
'arm64-upstream' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
git bisect bad 04759194dc447ff0b9ef35bc641ce3bb076c2930
# good: [5f82e71a001d14824a7728ad9e49f6aea420f161] Merge branch
'locking-core-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 5f82e71a001d14824a7728ad9e49f6aea420f161
# bad: [f57091767add2b79d76aac41b83b192d8ba1dce7] Merge branch
'x86-cache-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad f57091767add2b79d76aac41b83b192d8ba1dce7
# bad: [dd90cccffc20a15d8e4c3ac8813f4b6a6cd4766f] Merge branch
'timers-core-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad dd90cccffc20a15d8e4c3ac8813f4b6a6cd4766f
# bad: [e505371dd83963caae1a37ead9524e8d997341be] x86/boot: Add early
cmdline parsing for options with arguments
git bisect bad e505371dd83963caae1a37ead9524e8d997341be
# bad: [b9d05200bc12444c7778a49c9694d8382ed06aa8] x86/mm: Insure that
boot memory areas are mapped properly
git bisect bad b9d05200bc12444c7778a49c9694d8382ed06aa8
# bad: [f7750a79568788473c5e8092ee58a52248f34329] x86, mpparse,
x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap() for RAM mappings
git bisect bad f7750a79568788473c5e8092ee58a52248f34329
# bad: [cba4671af7550e008f7a7835f06df0763825bf3e] x86/mm: Disable PCID
on 32-bit kernels
git bisect bad cba4671af7550e008f7a7835f06df0763825bf3e
# good: [b0579ade7cd82391360e959cc844e50a160e8a96] x86/mm: Track the
TLB's tlb_gen and update the flushing algorithm
git bisect good b0579ade7cd82391360e959cc844e50a160e8a96
# bad: [43858b4f25cf0adc5c2ca9cf5ce5fdf2532941e5] x86/mm: Stop calling
leave_mm() in idle code
git bisect bad 43858b4f25cf0adc5c2ca9cf5ce5fdf2532941e5
# bad: [94b1b03b519b81c494900cb112aa00ed205cc2d9] x86/mm: Rework lazy
TLB mode and TLB freshness tracking
git bisect bad 94b1b03b519b81c494900cb112aa00ed205cc2d9
# first bad commit: [94b1b03b519b81c494900cb112aa00ed205cc2d9] x86/mm:
Rework lazy TLB mode and TLB freshness tracking

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 16
model   : 5
model name  : AMD Phenom(tm) II X4 840 Processor
stepping: 3
microcode   : 0x1c8
cpu MHz : 3201.034
cache size  : 512 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid 
extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy 
abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall npt 
lbrv svm_lock nrip_save
bugs: tlb_mmatch fxsave_leak sysret_ss_attrs null_seg amd_e400
bogomips: 6400.76
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor   : 1
vendor_id   : AuthenticAMD
cpu family  : 16
model   : 5
model name  : AMD Phenom(tm) II X4 840 Processor
stepping: 3
microcode   : 0x1c8
cpu MHz : 3201.034
cache size  : 512 KB
physical id : 0
siblings: 4
core id : 1
cpu cores   : 4
apicid  : 1
initial apicid  : 1
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 

Re: udiskd high CPU usage with 4.0 git

[Prakash Punnoor]

On 09.03.2015 00:30, NeilBrown wrote:
> On Sun, 08 Mar 2015 18:14:39 +0100 Prakash Punnoor  wrote:
> 
>> Hi,
>>
>> I noticed the udisks daemon (version 2.1.4) suddenly started using high
>> cpu (one core at 100%) with linux 4.0 git kernel. I bisected it to:
>>
>> 750f199ee8b578062341e6ddfe36c59ac8ff2dcb
>>
>> And reverting it from current master (at
>> 2cf3afcd4cbe0e32b8722fc291e9255de1b4d6c6) fixes my problem indeed.
>>
>> I attached dmesg and config from
>> 2cf3afcd4cbe0e32b8722fc291e9255de1b4d6c6 with
>> 750f199ee8b578062341e6ddfe36c59ac8ff2dcb reverted. Any more infos
>> needed? I am actually using a raid5 array, if that matters:
>>
>> Personalities : [raid6] [raid5] [raid4]
>> md127 : active raid5 sdd1[1] sdb1[3] sdc1[0]
>>   3907023872 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3]
>> [UUU]
>>
>> unused devices: 
>>
>>
>> The array uses systemd automount feature (x-systemd.automount).
>>
>> Please CC me, as I am not subscribed.
>>
>>
>> Regards,
>>
>> Prakash
> 
> Thanks for the report.
> I can't reproduce this, or see what would cause it.
> 
> Can you please reproduce the problem and then run
> 
>   strace -o /tmp/udisks.trace -f -p `pidof udisksd`
> 
> for a few seconds, then interrupt and post the resulting '/tmp/udisks.trace'.

Hi, attached the trace.

Regards,

Prakash




udisks.trace.xz
Description: application/xz

Re: udiskd high CPU usage with 4.0 git

[Prakash Punnoor]

On 09.03.2015 00:30, NeilBrown wrote:
 On Sun, 08 Mar 2015 18:14:39 +0100 Prakash Punnoor prak...@punnoor.de wrote:
 
 Hi,

 I noticed the udisks daemon (version 2.1.4) suddenly started using high
 cpu (one core at 100%) with linux 4.0 git kernel. I bisected it to:

 750f199ee8b578062341e6ddfe36c59ac8ff2dcb

 And reverting it from current master (at
 2cf3afcd4cbe0e32b8722fc291e9255de1b4d6c6) fixes my problem indeed.

 I attached dmesg and config from
 2cf3afcd4cbe0e32b8722fc291e9255de1b4d6c6 with
 750f199ee8b578062341e6ddfe36c59ac8ff2dcb reverted. Any more infos
 needed? I am actually using a raid5 array, if that matters:

 Personalities : [raid6] [raid5] [raid4]
 md127 : active raid5 sdd1[1] sdb1[3] sdc1[0]
   3907023872 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3]
 [UUU]

 unused devices: none


 The array uses systemd automount feature (x-systemd.automount).

 Please CC me, as I am not subscribed.


 Regards,

 Prakash
 
 Thanks for the report.
 I can't reproduce this, or see what would cause it.
 
 Can you please reproduce the problem and then run
 
   strace -o /tmp/udisks.trace -f -p `pidof udisksd`
 
 for a few seconds, then interrupt and post the resulting '/tmp/udisks.trace'.

Hi, attached the trace.

Regards,

Prakash




udisks.trace.xz
Description: application/xz

udiskd high CPU usage with 4.0 git

[Prakash Punnoor]

Hi,

I noticed the udisks daemon (version 2.1.4) suddenly started using high
cpu (one core at 100%) with linux 4.0 git kernel. I bisected it to:

750f199ee8b578062341e6ddfe36c59ac8ff2dcb

And reverting it from current master (at
2cf3afcd4cbe0e32b8722fc291e9255de1b4d6c6) fixes my problem indeed.

I attached dmesg and config from
2cf3afcd4cbe0e32b8722fc291e9255de1b4d6c6 with
750f199ee8b578062341e6ddfe36c59ac8ff2dcb reverted. Any more infos
needed? I am actually using a raid5 array, if that matters:

Personalities : [raid6] [raid5] [raid4]
md127 : active raid5 sdd1[1] sdb1[3] sdc1[0]
  3907023872 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3]
[UUU]

unused devices: 


The array uses systemd automount feature (x-systemd.automount).

Please CC me, as I am not subscribed.


Regards,

Prakash


config_2cf3afcd4cbe0e32b8722fc291e9255de1b4d6c6.xz
Description: application/xz


dmesg_2cf3afcd4cbe0e32b8722fc291e9255de1b4d6c6.xz
Description: application/xz

udiskd high CPU usage with 4.0 git

[Prakash Punnoor]

Hi,

I noticed the udisks daemon (version 2.1.4) suddenly started using high
cpu (one core at 100%) with linux 4.0 git kernel. I bisected it to:

750f199ee8b578062341e6ddfe36c59ac8ff2dcb

And reverting it from current master (at
2cf3afcd4cbe0e32b8722fc291e9255de1b4d6c6) fixes my problem indeed.

I attached dmesg and config from
2cf3afcd4cbe0e32b8722fc291e9255de1b4d6c6 with
750f199ee8b578062341e6ddfe36c59ac8ff2dcb reverted. Any more infos
needed? I am actually using a raid5 array, if that matters:

Personalities : [raid6] [raid5] [raid4]
md127 : active raid5 sdd1[1] sdb1[3] sdc1[0]
  3907023872 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3]
[UUU]

unused devices: none


The array uses systemd automount feature (x-systemd.automount).

Please CC me, as I am not subscribed.


Regards,

Prakash


config_2cf3afcd4cbe0e32b8722fc291e9255de1b4d6c6.xz
Description: application/xz


dmesg_2cf3afcd4cbe0e32b8722fc291e9255de1b4d6c6.xz
Description: application/xz

Re: [Debug 2/2] x86/PCI/ACPI: Relax ACPI resource descriptor checks to work around BIOS bugs

[Prakash Punnoor]

On 04.03.2015 03:29, Jiang Liu wrote:
> On 2015/3/3 23:18, Bjorn Helgaas wrote:
>> On Mon, Mar 2, 2015 at 10:25 PM, Jiang Liu  wrote:
>>> Some BIOSes report incorrect length for ACPI address space descriptors,
>>> so relax the checks to avoid regressions.
>>>
>>> Signed-off-by: Jiang Liu 
>>
>> It'd be nice to have a DSDT archived and referenced in this changelog
>> for future reference.  This sounds similar to previous issues:
> Hi all,
>   Could anybody help to dump an ACPI table from those failure
> systems so we could archive it?

Attached: DSDT from my Abit A-S78H.

Regards,

Prakash


DSDT-Abit-A-S78H.xz
Description: application/xz

Re: [Debug 2/2] x86/PCI/ACPI: Relax ACPI resource descriptor checks to work around BIOS bugs

[Prakash Punnoor]

On 04.03.2015 03:29, Jiang Liu wrote:
 On 2015/3/3 23:18, Bjorn Helgaas wrote:
 On Mon, Mar 2, 2015 at 10:25 PM, Jiang Liu jiang@linux.intel.com wrote:
 Some BIOSes report incorrect length for ACPI address space descriptors,
 so relax the checks to avoid regressions.

 Signed-off-by: Jiang Liu jiang@linux.intel.com

 It'd be nice to have a DSDT archived and referenced in this changelog
 for future reference.  This sounds similar to previous issues:
 Hi all,
   Could anybody help to dump an ACPI table from those failure
 systems so we could archive it?

Attached: DSDT from my Abit A-S78H.

Regards,

Prakash


DSDT-Abit-A-S78H.xz
Description: application/xz

Re: [Debug 0/2] Fix regressions caused by commit 593669c2ac0f

[Prakash Punnoor]

On 03.03.2015 05:34, Dave Airlie wrote:
> On 3 March 2015 at 14:25, Jiang Liu  wrote:
>> Commit 593669c2ac0f (x86/PCI/ACPI: Use common ACPI resource interfaces
>> to simplify implementation) causes regression to several platforms,
>> which is caused by stricter checks in new ACPI resource parsing code
>> and BIOSes report incorrect ACPI resource descriptors.  So try to relax
>> the check to avoid regressions.
>>
>> Jiang Liu (2):
>>   x86/PCI/ACPI: Ignore resources consumed by host bridge itself
>>   x86/PCI/ACPI: Relax ACPI resource descriptor checks to work around
>> BIOS bugs
> 
> I've booted my machine with that lost its r8169 and it appears to be
> working now.
> 
> So from the regression POV:
> Tested-by: Dave Airlie 

Works for me, as well. Thanks!

Tested-by: Prakash Punnoor 


Regards,

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

Re: [Debug 0/2] Fix regressions caused by commit 593669c2ac0f

[Prakash Punnoor]

On 03.03.2015 05:34, Dave Airlie wrote:
 On 3 March 2015 at 14:25, Jiang Liu jiang@linux.intel.com wrote:
 Commit 593669c2ac0f (x86/PCI/ACPI: Use common ACPI resource interfaces
 to simplify implementation) causes regression to several platforms,
 which is caused by stricter checks in new ACPI resource parsing code
 and BIOSes report incorrect ACPI resource descriptors.  So try to relax
 the check to avoid regressions.

 Jiang Liu (2):
   x86/PCI/ACPI: Ignore resources consumed by host bridge itself
   x86/PCI/ACPI: Relax ACPI resource descriptor checks to work around
 BIOS bugs
 
 I've booted my machine with that lost its r8169 and it appears to be
 working now.
 
 So from the regression POV:
 Tested-by: Dave Airlie airl...@redhat.com

Works for me, as well. Thanks!

Tested-by: Prakash Punnoor prak...@punnoor.de


Regards,

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

ACPI regression with 3.19+

[Prakash Punnoor]

Hallo,

my system won't boot with current GIT kernel (see attached screenshot).
The system seems somewhat frozen (cannot ssh into it), but magic sysrq
still works. I bisected the problem to commit
593669c2ac0fe18baee04a3cd5539a148aa48574. Attached are my config and
dmesg output from previous commit, which still booted.
I don't know if related, but the message "pnp 00:00: can't evaluate
_CRS: 1" is also new to me. I saw it with commit
8515f9368161730655b64ddaf8b11a3d20049610, but not with
c793504de3de484076e1eb96d5187af55f47945c. Didn't test commits in between.

I am not subscribed, so please CC if you need more info. Thanks.

Regards,

Prakash

PS: Sorry for posting twice, mistyped ACPI mailing list address.


config_812dbd9994f122629db73205a7f7f46b430a6360.xz
Description: application/xz


kernel_812dbd9994f122629db73205a7f7f46b430a6360.txt.xz
Description: application/xz

ACPI regression with 3.19+

[Prakash Punnoor]

Hallo,

my system won't boot with current GIT kernel (see attached screenshot).
The system seems somewhat frozen (cannot ssh into it), but magic sysrq
still works. I bisected the problem to commit
593669c2ac0fe18baee04a3cd5539a148aa48574. Attached are my config and
dmesg output from previous commit, which still booted.
I don't know if related, but the message "pnp 00:00: can't evaluate
_CRS: 1" is also new to me. I saw it with commit
8515f9368161730655b64ddaf8b11a3d20049610, but not with
c793504de3de484076e1eb96d5187af55f47945c. Didn't test commits in between.

I am not subscribed, so please CC if you need more info. Thanks.

Regards,

Prakash


config_812dbd9994f122629db73205a7f7f46b430a6360.xz
Description: application/xz


kernel_812dbd9994f122629db73205a7f7f46b430a6360.txt.xz
Description: application/xz

ACPI regression with 3.19+

[Prakash Punnoor]

Hallo,

my system won't boot with current GIT kernel (see attached screenshot).
The system seems somewhat frozen (cannot ssh into it), but magic sysrq
still works. I bisected the problem to commit
593669c2ac0fe18baee04a3cd5539a148aa48574. Attached are my config and
dmesg output from previous commit, which still booted.
I don't know if related, but the message pnp 00:00: can't evaluate
_CRS: 1 is also new to me. I saw it with commit
8515f9368161730655b64ddaf8b11a3d20049610, but not with
c793504de3de484076e1eb96d5187af55f47945c. Didn't test commits in between.

I am not subscribed, so please CC if you need more info. Thanks.

Regards,

Prakash


config_812dbd9994f122629db73205a7f7f46b430a6360.xz
Description: application/xz


kernel_812dbd9994f122629db73205a7f7f46b430a6360.txt.xz
Description: application/xz

ACPI regression with 3.19+

[Prakash Punnoor]

Hallo,

my system won't boot with current GIT kernel (see attached screenshot).
The system seems somewhat frozen (cannot ssh into it), but magic sysrq
still works. I bisected the problem to commit
593669c2ac0fe18baee04a3cd5539a148aa48574. Attached are my config and
dmesg output from previous commit, which still booted.
I don't know if related, but the message pnp 00:00: can't evaluate
_CRS: 1 is also new to me. I saw it with commit
8515f9368161730655b64ddaf8b11a3d20049610, but not with
c793504de3de484076e1eb96d5187af55f47945c. Didn't test commits in between.

I am not subscribed, so please CC if you need more info. Thanks.

Regards,

Prakash

PS: Sorry for posting twice, mistyped ACPI mailing list address.


config_812dbd9994f122629db73205a7f7f46b430a6360.xz
Description: application/xz


kernel_812dbd9994f122629db73205a7f7f46b430a6360.txt.xz
Description: application/xz

Re: Disk schedulers

[Prakash Punnoor]

On the day of Friday 15 February 2008 Jan Engelhardt hast written:
> On Feb 14 2008 17:21, Lukas Hejtmanek wrote:
> >Hello,
> >
> >whom should I blame about disk schedulers?
>
> Also consider
> - DMA (e.g. only UDMA2 selected)
> - aging disk

Nope, I also reported this problem _years_ ago, but till now much hasn't 
changed. Large writes lead to read starvation.

-- 
(°=     =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: Disk schedulers

[Prakash Punnoor]

On the day of Friday 15 February 2008 Jan Engelhardt hast written:
 On Feb 14 2008 17:21, Lukas Hejtmanek wrote:
 Hello,
 
 whom should I blame about disk schedulers?

 Also consider
 - DMA (e.g. only UDMA2 selected)
 - aging disk

Nope, I also reported this problem _years_ ago, but till now much hasn't 
changed. Large writes lead to read starvation.

-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: E1000 (PCI-E) doesn't work on nforce430, MSI issue.

[Prakash Punnoor]

On the day of Tuesday 12 February 2008 Krzysztof Halasa hast written:
> Hi,
>
> Is it a known problem?
> Linux 2.6.24.2, ASUS M2NPV-MX mobo, nforce 430 based, two PCI-E x1
> E1000 cards, 32-bit kernel, default e1000 driver (PCI IDs disabled in
> e1000e).
>
> Don't work by default. "pci=nomsi" fixes the problem.

Probably the patch to enable msi bit on the host bridge(?) is still missing in 
mainline. I needed that patch to make msi work on my MCP51 system.

-- 
(°=     =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: E1000 (PCI-E) doesn't work on nforce430, MSI issue.

[Prakash Punnoor]

On the day of Tuesday 12 February 2008 Krzysztof Halasa hast written:
 Hi,

 Is it a known problem?
 Linux 2.6.24.2, ASUS M2NPV-MX mobo, nforce 430 based, two PCI-E x1
 E1000 cards, 32-bit kernel, default e1000 driver (PCI IDs disabled in
 e1000e).

 Don't work by default. pci=nomsi fixes the problem.

Probably the patch to enable msi bit on the host bridge(?) is still missing in 
mainline. I needed that patch to make msi work on my MCP51 system.

-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Saturday 09 February 2008 Gene Heskett hast written:
> On Saturday 09 February 2008, Prakash Punnoor wrote:
> >On the day of Saturday 09 February 2008 Gene Heskett hast written:
> >> This has killed me both at boot time twice, once before NASH was
> >> running, and several times when uptimes were a day plus, but has never
> >> reappeared since the first time I used the acpi_user_timer_override
> >> argument, and this includes several boots without it including 2
> >> complete, 2 or 3 minute power downs.
> >
> >Are you saying that on your nforce2 you need the override
> >(acpi_use_timer_override) to have a stable system? Because that would be
> > in contrast to all previous findings regarding nforce2. Could you provide
> >
> >cat /proc/interrupts
> >lspci
> >lspci -n
>
> Currently booted with it, uptime 38 hours, only diff visible is in dmesg as
> has been posted here in another thread.
>
> [EMAIL PROTECTED] ~]# cat /proc/interrupts
>CPU0
>   0:869XT-PIC-XTtimer
>   1: 18   IO-APIC-edge  i8042

Thanks for providing the info. According to the IDs your and my board are 
quite alike. If you don't pass acpi_use_timer_override to vanilla kernel, 
does your timer get connected to IO-APIC? Ie:

   CPU0
  0:  47834   IO-APIC-edge  timer

In this mode, is your board stable? I never run my hw longer than 10h, so I 
cannot say anything about long-term stability, but lately my nforce2 didn't 
make any troubles and (when it did, it usally was related to PSU). I am 
skipping the override, ie. my timer is connected to IO-APIC.

If in the latter mode your hw is instable, we have a problem...
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Saturday 09 February 2008 Gene Heskett hast written:
> This has killed me both at boot time twice, once before NASH was running,
> and several times when uptimes were a day plus, but has never reappeared
> since the first time I used the acpi_user_timer_override argument, and this
> includes several boots without it including 2 complete, 2 or 3 minute power
> downs.

Are you saying that on your nforce2 you need the override 
(acpi_use_timer_override) to have a stable system? Because that would be in 
contrast to all previous findings regarding nforce2. Could you provide 

cat /proc/interrupts
lspci
lspci -n
-- 
(°=     =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

Am Samstag 09 Februar 2008 schrieben Sie:
> On Sat, Feb 09, 2008 at 04:51:05PM +0100, Prakash Punnoor wrote:
> > On the day of Saturday 09 February 2008 Andi Kleen hast written:
> > > We discussed this back then with Nvidia engineers and they stated
> > > that only NF5 would need timer overrides.
> >
> > Can I get a link which verifies your statement? I provided one which kind
> > of contradicts yours.
>
> Sorry cannot supply links to them, they were private mail. For some
> reason the Nvidia people seem to be shy to post to mailing lists.

Too bad that you cannot make them publish their infos.

>
> iirc the thread which inspired this patch (together with several
> bugs in both novell and kernel.org bugzilla) was
>
> http://marc.info/?t=11617522451=1=2

Interesting, this was where I posted, as well...

> So you have to trust me on that -- it's a bit similar to as to I have
> to trust your not yet produced boot log and test results.

And I won't, as I reverted to my stable kernel again and thus patching it 
again (yes it was 2.6.24 with early-quirks.c from git and your patch on top) 
doesn't give more info then I already provided. Furthermore I also told you 
that because of missing nforce2 ID the practical test wasn't really 
necessary.


Just add this line to your patch:

+   QBRIDGE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE2, 
nvidia_timer),


So that the quirk gets applied for nForce2, then your patch is - while still 
wrong in my eyes - not a regression anymore (for me) and thus I would take 
back my NAK(, but still not ACK it).

bye,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Saturday 09 February 2008 Andi Kleen hast written:
> We discussed this back then with Nvidia engineers and they stated
> that only NF5 would need timer overrides.

Can I get a link which verifies your statement? I provided one which kind of 
contradicts yours.
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Saturday 09 February 2008 Thomas Gleixner hast written:
> On Sat, 9 Feb 2008, Prakash Punnoor wrote:
> > On the day of Friday 08 February 2008 Andi Kleen hast written:
> > > On Fri, Feb 08, 2008 at 08:00:39PM +0100, Prakash Punnoor wrote:
> > > > On the day of Friday 08 February 2008 Andi Kleen hast written:
> > > > > On Fri, Feb 08, 2008 at 06:39:17PM +0100, Prakash Punnoor wrote:
> > > > > > Yes, confirmed. timer w/o the skipping stays XT-PIC on nforce2.
> > > > >
> > > > > Confirmed what? Did you test my patch on both machines?
> > > > > What was the result?
> > > >
> > > > I confirmed that it (nforce2) needed the acpi_skip_timer_override. If
> > > > you read my mail, you knew I didn't test your patch.
> > >
> > > Ok can you please do so then?  Or stop your obstructism?
> >
> > Grr, I don't know why I am discussing with stubborn and/or arrogant devs
> > like you seem to be. But I actually did what you wanted and as *expected*
> > - as I said I understand that trivial piece of code you posted - your
> > patch fails here for my nforce2:
>
> No worry, this patch wont go anywhere near mainline as long as it
> breaks stuff and obviously you are under no obligation to re-test
> patches that have not been changed just re-submitted.

The problem is current behaviour is already broken as it applies the quirk 
*unconditionally* for all Nvidia hardwarde where no hpet is detected. The 
latter is just heuristics. *If* correct Nforce2 ID gets added to the proposed 
patch, behaviour would be equivalent to current situation for me (nforce2, 
mcp51). Still I am saying mcp51 doesn't belong per-se to the list of chipsets 
which need to be quirked, as for me it shows adverse effect. Taking mcp51 out 
would be an advancement.


If there are situations where quirking is correct and other situation where it 
is incorrect for the same type of chipsets, I think then the quirk should not 
be applied automatically.



So I suggest something like this as a start. The quirk only gets applied for 
nforce2 unconditionally, as it was intended originally. For chipsets between 
nforce3 and before nforce5 the user gets a message and no quirk gets applied 
automatically. If there are known bug reports (Andi Kleen didn't supply any 
references) some more infos could be asked from the reportes. Then for known 
broken bios versions the quirk could be applied by DMI scan *selectively*. 
(This part of code is missing here.) I also don't know whether the list of 
IDs is complete.

Warning I hand edited the original proposed patch, so it won't apply and 
probably won't compile. But I hope one gets the idea.


Index: linux/arch/x86/kernel/early-quirks.c
===
--- linux.orig/arch/x86/kernel/early-quirks.c
+++ linux/arch/x86/kernel/early-quirks.c
@@ -60,38 +60,21 @@ static void __init via_bugs(int  num, in
 #endif
 }
 
-#ifdef CONFIG_ACPI
-#ifdef CONFIG_X86_IO_APIC
-
-static int __init nvidia_hpet_check(struct acpi_table_header *header)
-{
-   return 0;
-}
-#endif /* CONFIG_X86_IO_APIC */
-#endif /* CONFIG_ACPI */
-
-static void __init nvidia_bugs(int num, int slot, int func)
+static void __init nvidia_timer(int num, int slot, int func)
 {
 #ifdef CONFIG_ACPI
 #ifdef CONFIG_X86_IO_APIC
/*
-* All timer overrides on Nvidia are
-* wrong unless HPET is enabled.
-* Unfortunately that's not true on many Asus boards.
-* We don't know yet how to detect this automatically, but
-* at least allow a command line override.
+* Timer overrides on Nvidia NForce2 are
+* wrong.
 */
if (acpi_use_timer_override)
return;
 
-   if (acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check)) {
-   acpi_skip_timer_override = 1;
-   printk(KERN_INFO "Nvidia board "
-  "detected. Ignoring ACPI "
-  "timer override.\n");
-   printk(KERN_INFO "If you got timer trouble "
-   "try acpi_use_timer_override\n");
-   }
+   acpi_skip_timer_override = 1;
+   printk(KERN_INFO "NForce2 Nvidia board detected."
+"Ignoring ACPI timer override.\n");
+   printk(KERN_INFO "If you have trouble try acpi_use_timer_override\n");
 #endif
 #endif
/* RED-PEN skip them on mptables too? */
@@ -121,9 +104,19 @@ struct chipset {
void (*f)(int num, int slot, int func);
 };
 
+ static void __init nvidia_timer_hint(int num, int slot, int func)
+ {
+   if (!acpi_skip_timer_override)
+   printk(KERN_INFO "Pre NForce5 Nvidia board detected."
+   

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Saturday 09 February 2008 Andi Kleen hast written:
> > Grr, I don't know why I am discussing with stubborn and/or arrogant devs
> > like you seem to be. But I actually did what you wanted and as *expected*
> > - as I
>
> Thanks.
>
> > said I understand that trivial piece of code you posted - your patch
> > fails here for my nforce2:
>
> That is 2.6.24 + my patch?  And system didn't boot?
>
> > cat /proc/interrupts
> >CPU0
> >   0:832XT-PIC-XTtimer < seeing this?
>
> Well it looks like it is ticking. What are the symptoms?

You are seeing it. If you read my other mails you would comprehend it as well.

> Do you have a full boot log of the failure?

As I said inform yourself, what the intention of the quirk is about. I am 
tired of this.

>
> > And no, I won't test it on my MCP51 as I *know* what happens: As soon as
> > I disable hpet, the quirk gets triggered and will lock up my system.
>
> I readded the HPET check in v2 especially for you so if HPET is enabled
> no quirk is triggered.

Still you didn't give *any* proof that mcp51 needs quirk at all. I therefore 
want that line *removed*:

+   QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x02f0, nvidia_timer), /* mcp 51/nf4 ? 
*/

Furthermore my original bios didn't have option to enable hpet. What then? 
Kernel hangs unless I specify acpi_use_timer_override. Great.

Hint: The correct way of quirking would be *only having this one* line:

+   QBRIDGE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE2, 
nvidia_timer),

According to Len Brown's comment this would work for every nforce2. For every 
other nforceX use DMI Scan and only quirk known broken bioses instead of 
messing up working boxes.

bye,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Saturday 09 February 2008 Andi Kleen hast written:
  Grr, I don't know why I am discussing with stubborn and/or arrogant devs
  like you seem to be. But I actually did what you wanted and as *expected*
  - as I

 Thanks.

  said I understand that trivial piece of code you posted - your patch
  fails here for my nforce2:

 That is 2.6.24 + my patch?  And system didn't boot?

  cat /proc/interrupts
 CPU0
0:832XT-PIC-XTtimer  seeing this?

 Well it looks like it is ticking. What are the symptoms?

You are seeing it. If you read my other mails you would comprehend it as well.

 Do you have a full boot log of the failure?

As I said inform yourself, what the intention of the quirk is about. I am 
tired of this.


  And no, I won't test it on my MCP51 as I *know* what happens: As soon as
  I disable hpet, the quirk gets triggered and will lock up my system.

 I readded the HPET check in v2 especially for you so if HPET is enabled
 no quirk is triggered.

Still you didn't give *any* proof that mcp51 needs quirk at all. I therefore 
want that line *removed*:

+   QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x02f0, nvidia_timer), /* mcp 51/nf4 ? 
*/

Furthermore my original bios didn't have option to enable hpet. What then? 
Kernel hangs unless I specify acpi_use_timer_override. Great.

Hint: The correct way of quirking would be *only having this one* line:

+   QBRIDGE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE2, 
nvidia_timer),

According to Len Brown's comment this would work for every nforce2. For every 
other nforceX use DMI Scan and only quirk known broken bioses instead of 
messing up working boxes.

bye,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Saturday 09 February 2008 Thomas Gleixner hast written:
 On Sat, 9 Feb 2008, Prakash Punnoor wrote:
  On the day of Friday 08 February 2008 Andi Kleen hast written:
   On Fri, Feb 08, 2008 at 08:00:39PM +0100, Prakash Punnoor wrote:
On the day of Friday 08 February 2008 Andi Kleen hast written:
 On Fri, Feb 08, 2008 at 06:39:17PM +0100, Prakash Punnoor wrote:
  Yes, confirmed. timer w/o the skipping stays XT-PIC on nforce2.

 Confirmed what? Did you test my patch on both machines?
 What was the result?
   
I confirmed that it (nforce2) needed the acpi_skip_timer_override. If
you read my mail, you knew I didn't test your patch.
  
   Ok can you please do so then?  Or stop your obstructism?
 
  Grr, I don't know why I am discussing with stubborn and/or arrogant devs
  like you seem to be. But I actually did what you wanted and as *expected*
  - as I said I understand that trivial piece of code you posted - your
  patch fails here for my nforce2:

 No worry, this patch wont go anywhere near mainline as long as it
 breaks stuff and obviously you are under no obligation to re-test
 patches that have not been changed just re-submitted.

The problem is current behaviour is already broken as it applies the quirk 
*unconditionally* for all Nvidia hardwarde where no hpet is detected. The 
latter is just heuristics. *If* correct Nforce2 ID gets added to the proposed 
patch, behaviour would be equivalent to current situation for me (nforce2, 
mcp51). Still I am saying mcp51 doesn't belong per-se to the list of chipsets 
which need to be quirked, as for me it shows adverse effect. Taking mcp51 out 
would be an advancement.


If there are situations where quirking is correct and other situation where it 
is incorrect for the same type of chipsets, I think then the quirk should not 
be applied automatically.



So I suggest something like this as a start. The quirk only gets applied for 
nforce2 unconditionally, as it was intended originally. For chipsets between 
nforce3 and before nforce5 the user gets a message and no quirk gets applied 
automatically. If there are known bug reports (Andi Kleen didn't supply any 
references) some more infos could be asked from the reportes. Then for known 
broken bios versions the quirk could be applied by DMI scan *selectively*. 
(This part of code is missing here.) I also don't know whether the list of 
IDs is complete.

Warning I hand edited the original proposed patch, so it won't apply and 
probably won't compile. But I hope one gets the idea.


Index: linux/arch/x86/kernel/early-quirks.c
===
--- linux.orig/arch/x86/kernel/early-quirks.c
+++ linux/arch/x86/kernel/early-quirks.c
@@ -60,38 +60,21 @@ static void __init via_bugs(int  num, in
 #endif
 }
 
-#ifdef CONFIG_ACPI
-#ifdef CONFIG_X86_IO_APIC
-
-static int __init nvidia_hpet_check(struct acpi_table_header *header)
-{
-   return 0;
-}
-#endif /* CONFIG_X86_IO_APIC */
-#endif /* CONFIG_ACPI */
-
-static void __init nvidia_bugs(int num, int slot, int func)
+static void __init nvidia_timer(int num, int slot, int func)
 {
 #ifdef CONFIG_ACPI
 #ifdef CONFIG_X86_IO_APIC
/*
-* All timer overrides on Nvidia are
-* wrong unless HPET is enabled.
-* Unfortunately that's not true on many Asus boards.
-* We don't know yet how to detect this automatically, but
-* at least allow a command line override.
+* Timer overrides on Nvidia NForce2 are
+* wrong.
 */
if (acpi_use_timer_override)
return;
 
-   if (acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check)) {
-   acpi_skip_timer_override = 1;
-   printk(KERN_INFO Nvidia board 
-  detected. Ignoring ACPI 
-  timer override.\n);
-   printk(KERN_INFO If you got timer trouble 
-   try acpi_use_timer_override\n);
-   }
+   acpi_skip_timer_override = 1;
+   printk(KERN_INFO NForce2 Nvidia board detected.
+Ignoring ACPI timer override.\n);
+   printk(KERN_INFO If you have trouble try acpi_use_timer_override\n);
 #endif
 #endif
/* RED-PEN skip them on mptables too? */
@@ -121,9 +104,19 @@ struct chipset {
void (*f)(int num, int slot, int func);
 };
 
+ static void __init nvidia_timer_hint(int num, int slot, int func)
+ {
+   if (!acpi_skip_timer_override)
+   printk(KERN_INFO Pre NForce5 Nvidia board detected.
+If you have trouble, try booting with 
acpi_skip_timer_override\n
+If that works for you please report to the 
Linux kernel mailing 
list.);
+ }

+#define QBRIDGE(vendor, device, func) { \
+   vendor, device, PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, \
+   QFLAG_APPLY_ONCE, func }
+
 static struct chipset early_qrk[] __initdata

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Saturday 09 February 2008 Andi Kleen hast written:
 We discussed this back then with Nvidia engineers and they stated
 that only NF5 would need timer overrides.

Can I get a link which verifies your statement? I provided one which kind of 
contradicts yours.
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

Am Samstag 09 Februar 2008 schrieben Sie:
 On Sat, Feb 09, 2008 at 04:51:05PM +0100, Prakash Punnoor wrote:
  On the day of Saturday 09 February 2008 Andi Kleen hast written:
   We discussed this back then with Nvidia engineers and they stated
   that only NF5 would need timer overrides.
 
  Can I get a link which verifies your statement? I provided one which kind
  of contradicts yours.

 Sorry cannot supply links to them, they were private mail. For some
 reason the Nvidia people seem to be shy to post to mailing lists.

Too bad that you cannot make them publish their infos.


 iirc the thread which inspired this patch (together with several
 bugs in both novell and kernel.org bugzilla) was

 http://marc.info/?t=11617522451r=1w=2

Interesting, this was where I posted, as well...

 So you have to trust me on that -- it's a bit similar to as to I have
 to trust your not yet produced boot log and test results.

And I won't, as I reverted to my stable kernel again and thus patching it 
again (yes it was 2.6.24 with early-quirks.c from git and your patch on top) 
doesn't give more info then I already provided. Furthermore I also told you 
that because of missing nforce2 ID the practical test wasn't really 
necessary.


Just add this line to your patch:

+   QBRIDGE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE2, 
nvidia_timer),


So that the quirk gets applied for nForce2, then your patch is - while still 
wrong in my eyes - not a regression anymore (for me) and thus I would take 
back my NAK(, but still not ACK it).

bye,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Saturday 09 February 2008 Gene Heskett hast written:
 This has killed me both at boot time twice, once before NASH was running,
 and several times when uptimes were a day plus, but has never reappeared
 since the first time I used the acpi_user_timer_override argument, and this
 includes several boots without it including 2 complete, 2 or 3 minute power
 downs.

Are you saying that on your nforce2 you need the override 
(acpi_use_timer_override) to have a stable system? Because that would be in 
contrast to all previous findings regarding nforce2. Could you provide 

cat /proc/interrupts
lspci
lspci -n
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Saturday 09 February 2008 Gene Heskett hast written:
 On Saturday 09 February 2008, Prakash Punnoor wrote:
 On the day of Saturday 09 February 2008 Gene Heskett hast written:
  This has killed me both at boot time twice, once before NASH was
  running, and several times when uptimes were a day plus, but has never
  reappeared since the first time I used the acpi_user_timer_override
  argument, and this includes several boots without it including 2
  complete, 2 or 3 minute power downs.
 
 Are you saying that on your nforce2 you need the override
 (acpi_use_timer_override) to have a stable system? Because that would be
  in contrast to all previous findings regarding nforce2. Could you provide
 
 cat /proc/interrupts
 lspci
 lspci -n

 Currently booted with it, uptime 38 hours, only diff visible is in dmesg as
 has been posted here in another thread.

 [EMAIL PROTECTED] ~]# cat /proc/interrupts
CPU0
   0:869XT-PIC-XTtimer
   1: 18   IO-APIC-edge  i8042

Thanks for providing the info. According to the IDs your and my board are 
quite alike. If you don't pass acpi_use_timer_override to vanilla kernel, 
does your timer get connected to IO-APIC? Ie:

   CPU0
  0:  47834   IO-APIC-edge  timer

In this mode, is your board stable? I never run my hw longer than 10h, so I 
cannot say anything about long-term stability, but lately my nforce2 didn't 
make any troubles and (when it did, it usally was related to PSU). I am 
skipping the override, ie. my timer is connected to IO-APIC.

If in the latter mode your hw is instable, we have a problem...
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Friday 08 February 2008 Andi Kleen hast written:
> On Fri, Feb 08, 2008 at 08:00:39PM +0100, Prakash Punnoor wrote:
> > On the day of Friday 08 February 2008 Andi Kleen hast written:
> > > On Fri, Feb 08, 2008 at 06:39:17PM +0100, Prakash Punnoor wrote:
> > > >
> > > > Yes, confirmed. timer w/o the skipping stays XT-PIC on nforce2.
> > >
> > > Confirmed what? Did you test my patch on both machines?
> > > What was the result?
> >
> > I confirmed that it (nforce2) needed the acpi_skip_timer_override. If you
> > read my mail, you knew I didn't test your patch.
>
> Ok can you please do so then?  Or stop your obstructism?

Grr, I don't know why I am discussing with stubborn and/or arrogant devs like 
you seem to be. But I actually did what you wanted and as *expected* - as I 
said I understand that trivial piece of code you posted - your patch fails 
here for my nforce2:

cat /proc/interrupts
   CPU0
  0:832XT-PIC-XTtimer < seeing this?
  1: 10   IO-APIC-edge  i8042
  8:  2   IO-APIC-edge  rtc
  9:  0   IO-APIC-fasteoi   acpi
 12: 84   IO-APIC-edge  i8042
 14: 38   IO-APIC-edge  ide0
 16: 184026   IO-APIC-fasteoi   eth0
 17:  0   IO-APIC-fasteoi   Technisat/B2C2 FlexCop II/IIb/III Digital 
TV PCI Driver
 18:  0   IO-APIC-fasteoi   NVidia nForce2
 19:  12460   IO-APIC-fasteoi   nvidia
NMI:  0   Non-maskable interrupts
LOC:  74695   Local timer interrupts
TRM:  0   Thermal event interrupts
SPU:  0   Spurious interrupts
ERR:  0
MIS:  0


And no, I won't test it on my MCP51 as I *know* what happens: As soon as I 
disable hpet, the quirk gets triggered and will lock up my system.

Now stop wasting my time and do your homework!

> Your objections don't make sense, so you can NAK all day.  You're
> talking about timer overrides in PIC mode which is just pure non sense.

Then talk to Len Brown, maybe he is able to make you understand.

> Ok if you're unwilling to test I'm ignoring you in the future.
> Please stop sending me email.

Actually I don't care anymore. The last time you also didn't really cared for 
what I said about your way of quirking the nforce boards.

I know how to make the kernel behave in this matter, it is just a pity for 
other users, who don't know...

Good luck!
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Friday 08 February 2008 Andi Kleen hast written:
> On Fri, Feb 08, 2008 at 06:39:17PM +0100, Prakash Punnoor wrote:
> > On the day of Friday 08 February 2008 Andi Kleen hast written:
> > > On Fri, Feb 08, 2008 at 04:13:35PM +0100, Prakash Punnoor wrote:
> > > > Sorry, I meant the opposite. I needed the acpi_skip_timer_override
> > > > kernel parameter for nforce2, thus no override. So this chipset is
> > > > missing here. At least I remember that my nforce2 needed the
> > > > skipping,
> > >
> > > I hope you remember correctly and mean it this time. It would be better
> > > if you could double check.
> >
> > Yes, confirmed. timer w/o the skipping stays XT-PIC on nforce2.
>
> Confirmed what? Did you test my patch on both machines?
> What was the result?

I confirmed that it (nforce2) needed the acpi_skip_timer_override. If you read 
my mail, you knew I didn't test your patch.

> > lspci -n:
>
> Please always send lspci without -n too; I hate looking up hex codes
> by hand when a computer can do that for me.
>
> > 02:00.0 0300: 10de:0281 (rev a1)
> >
> > > I'm a little sceptical because we had this patch in OpenSUSE 10.3
> > > and I didn't think there were complaints from NF2 users.
> > > With the changes you're requesting it turns from something
> > > very well tested into something experimental.
> >
> > Well, even w/o the skipping my nforce2 system wasn't unstable, AFAIK. So
> > I don't think just because of the XT-PIC entry people would complain.
>
> Timer override only does something in APIC mode and when you see XT-PIC
> in /proc/interrupts then you're not in APIC mode. All these patches
> are a no-op in this state.

Perhaps I wasn't percise, Len Brown had it in his earlier patch descriptions:

"
workaround for nForce2 BIOS bug: XT-PIC timer in IOAPIC mode 
"acpi_skip_timer_override" boot parameter
"

or

"
Since the hardware is connected to APIC pin0, it is a BIOS bug 
 that an ACPI interrupt source override from pin2 to IRQ0 exists. 
 
With this simple 2.6.5 patch you can specify "acpi_skip_timer_override" 
 to ignore that bogus BIOS directive. The result is with your 
 ACPI-enabled APIC-enabled kernel, you'll get IRQ0 IO-APIC-edge timer. 
"

This is exactly what I observed on the nforce2.

My kernels are compiled and configured for APIC. With broken BIOSes the timer 
ends up as XT-PIC anyway. That is what I wanted to say and which you could 
see from my cat /proc/interrupts dumps.




Why can't the kernel check for this condition and only activate the quirk then 
instead of current and your proposed broken behaviour?




> > See why I don't want the quirk to be applied more than needed? *NOT*
> > applying the quirk on nforce2 didn't cause any obvious side effects.
> > APPLYING to mcp51 causes hard lock-ups.
>
> Can you please just test the patches instead of speculating what they
> might do or not do?

No, I do understand C code and I know the ID of my board. So I am not 
speculating, just saving myself time and hassle.

You are not even taking the time to really read what I say. I am not your   
guinea pig. Why should I simply waste my time? Esp. my nforce2 system is a 
productive system and I usually don't mess with it. So come up with a patch 
that makes sense (and triggers on my nforce2 and does not trigger on my 
mcp51) in my eyes, or I won't test anything and keep the NAK.

I don't think you did your research correctly coming up with the first version 
of the patch, as it ignored the nforce2 altogether. And the original version 
was made for nforce2 exclusively! So why should I trust that you know what 
you are doing? I don't get the impression. You also didn't gave references 
where you get your IDs in the patch. I at least tried to gave some references 
that putting in those IDs is *wrong*. If you can provide those references 
(and not some "search for it") you could strengthen your point. Provide some 
bug reports or lkml posts where users of nforce4, mcp51 needed the 
skip_override to get their system stable.




I don't care whether this patch has been in some kernel for some time. It is 
still wrong (worse for nforce2 users, though better for newer nvidia chipset 
users as at last the quirk doesn't get appield for them)!





BTW, nforce2 lspci:
00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?) (rev 
c1)
00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev c1)
00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1)
00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1)
00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1)
00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Friday 08 February 2008 Andi Kleen hast written:
> On Fri, Feb 08, 2008 at 04:13:35PM +0100, Prakash Punnoor wrote:

> > Sorry, I meant the opposite. I needed the acpi_skip_timer_override kernel
> > parameter for nforce2, thus no override. So this chipset is missing here.
> > At least I remember that my nforce2 needed the skipping,
>
> I hope you remember correctly and mean it this time. It would be better
> if you could double check.

Yes, confirmed. timer w/o the skipping stays XT-PIC on nforce2.

w/o skipping:

  0: 153413XT-PIC-XTtimer
  1: 10   IO-APIC-edge  i8042
  8:  2   IO-APIC-edge  rtc
  9:  0   IO-APIC-fasteoi   acpi
 12:112   IO-APIC-edge  i8042
 14: 37   IO-APIC-edge  ide0
 16: 165137   IO-APIC-fasteoi   eth0
 17:  0   IO-APIC-fasteoi   Technisat/B2C2 FlexCop II/IIb/III Digital 
TV PCI Driver
 18:  0   IO-APIC-fasteoi   NVidia nForce2
 19:   7922   IO-APIC-fasteoi   nvidia
NMI:  0
LOC: 153209
ERR:  0
MIS:  0

w/ skipping:
   CPU0
  0:  47834   IO-APIC-edge  timer
  1: 10   IO-APIC-edge  i8042
  8:  2   IO-APIC-edge  rtc
  9:  0   IO-APIC-fasteoi   acpi
 12:112   IO-APIC-edge  i8042
 14: 37   IO-APIC-edge  ide0
 16: 152413   IO-APIC-fasteoi   eth0
 17:  0   IO-APIC-fasteoi   Technisat/B2C2 FlexCop II/IIb/III Digital 
TV PCI Driver
 18:  0   IO-APIC-fasteoi   NVidia nForce2
 19:   1582   IO-APIC-fasteoi   nvidia
NMI:  0
LOC:  47736
ERR:  0
MIS:  0


lspci -n:
00:00.0 0600: 10de:01e0 (rev c1)
00:00.1 0500: 10de:01eb (rev c1)
00:00.2 0500: 10de:01ee (rev c1)
00:00.3 0500: 10de:01ed (rev c1)
00:00.4 0500: 10de:01ec (rev c1)
00:00.5 0500: 10de:01ef (rev c1)
00:01.0 0601: 10de:0060 (rev a3)
00:01.1 0c05: 10de:0064 (rev a2)
00:02.0 0c03: 10de:0067 (rev a3)
00:02.1 0c03: 10de:0067 (rev a3)
00:02.2 0c03: 10de:0068 (rev a3)
00:04.0 0200: 10de:0066 (rev a1)
00:05.0 0401: 10de:006b (rev a2)
00:06.0 0401: 10de:006a (rev a1)
00:08.0 0604: 10de:006c (rev a3)
00:09.0 0101: 10de:0065 (rev a2)
00:0d.0 0c00: 10de:006e (rev a3)
00:1e.0 0604: 10de:01e8 (rev c1)
01:08.0 0280: 13d0:2103 (rev 01)
02:00.0 0300: 10de:0281 (rev a1)

> I'm a little sceptical because we had this patch in OpenSUSE 10.3
> and I didn't think there were complaints from NF2 users.
> With the changes you're requesting it turns from something
> very well tested into something experimental.

Well, even w/o the skipping my nforce2 system wasn't unstable, AFAIK. So I 
don't think just because of the XT-PIC entry people would complain.

See why I don't want the quirk to be applied more than needed? *NOT* applying 
the quirk on nforce2 didn't cause any obvious side effects. APPLYING to mcp51 
causes hard lock-ups.

> But NF2 should not need a timer override anyways so probably
> ignoring it there is ok.
>
> Actually checking CK804 is already an Nforce2, but you might
> have NF2S which has a different ID. Do you have full lspci/lspci -n
> output?

My nforce2 board has different id then the listed ones, so that one needs to 
be included.

> Ok I'm appending another patch that adds the NF2S too, can
> you please test it on that machine?

No point if the quirk doesn't get triggered.

>
> > > I'm appending a revised patch. Does it work for you?
> >
> > I haven't tested it, but it would "work" as it would bail out in my case
>
> Can you please test it?

Will try the final version...

> > or not. Are you actually sure that so many nforceX boards have broken
> > bioses?
>
> Yes, it was a problem in the Nvidia reference BIOS that they sent to OEMs
> to base their own BIOS on, so pretty much everybody had this problem.
>
> We went over this with Nvidia engineers with a fine comb at this
> point. If you search the mailing list archives you might even
> find the discussions.

Yes, I actually linked to that discussion in the previous mail and there Allen 
Martin only stated that nforce2 and 3 may be affected. So I wonder why you 
(or Len) include nforce4 and mcp51 and so on?

Can't the quirk be made more intelligent? Ie. if we want APIC mode and timer 
stays as XT-PIC, then and only then rewire the timer and don't use the 
override, ie apply quirk? If rewiring isn't possible, then the kernel should 
als least print out a big fat warning that the user should probably skip the 
override. I don't know enough on the subject to explain it more precisely.

bye,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Friday 08 February 2008 Prakash Punnoor hast written:
> On the day of Friday 08 February 2008 Andi Kleen hast written:
> > On Thu, Feb 07, 2008 at 10:21:18PM +0100, Prakash Punnoor wrote:
> > > On the day of Thursday 07 February 2008 Andi Kleen hast written:
> > > > Replace the old "for all of nvidia" quirk with a quirk containing pci
> > > > device ID. I goobled this list together from pci.ids and googling and
> > > > it may be incomplete, but so far I haven't had complaints.
> > > >
> > > > +   QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x02f0, nvidia_timer), /* mcp 
> > > > 51/nf4
> > > > ? */
> > >
> > > If you want to skip timer override on this board, this is a *NAK* from
> > > me. I told you the last time, it only works reliably here on MCP51 with
> > > timer
> >
> > Hmm, if you told me it got lost somewhere, sorry.
>
> I at least found this post: http://lkml.org/lkml/2006/8/13/2 though I
> remeber we had some discussions. ;-)

http://lkml.org/lkml/2006/8/13/25

I killed one digit by mistake...
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Friday 08 February 2008 Andi Kleen hast written:
> On Thu, Feb 07, 2008 at 10:21:18PM +0100, Prakash Punnoor wrote:
> > On the day of Thursday 07 February 2008 Andi Kleen hast written:
> > > Replace the old "for all of nvidia" quirk with a quirk containing pci
> > > device ID. I goobled this list together from pci.ids and googling and
> > > it may be incomplete, but so far I haven't had complaints.
> > >
> > > + QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x02f0, nvidia_timer), /* mcp 51/nf4 ?
> > > */
> >
> > If you want to skip timer override on this board, this is a *NAK* from
> > me. I told you the last time, it only works reliably here on MCP51 with
> > timer
>
> Hmm, if you told me it got lost somewhere, sorry.

I at least found this post: http://lkml.org/lkml/2006/8/13/2 though I remeber 
we had some discussions. ;-)

>
> > override working. Even before Asus released a bios which had an option to
> > enable the hpet, I needed the override or I got irratic behaviour. Since
> > I got hpet enabled I gave up on arguing as the wrongly triggered quirk
> > didn't bug me anymore.
>
> Ok we can keep the HPET check if that makes you more happy.
>
> > IIRC my nforce2 needed the override. I didn't see that in the list.
>
> The list only contains IDs where the override should be ignored; so
> if it has a correct one and it's not there everything is fine.

Sorry, I meant the opposite. I needed the acpi_skip_timer_override kernel 
parameter for nforce2, thus no override. So this chipset is missing here. At 
least I remember that my nforce2 needed the skipping, 
otherwise the timer stayed in XT-PIC mode even when APIC was requested.

> I'm appending a revised patch. Does it work for you?

I haven't tested it, but it would "work" as it would bail out in my case 
because of the hpet check. The problem I see with this approach - as with the 
old one -  it simply wants to ignore the override for a whole bunch of 
chipsets. (The old one is catastrophic as it even doesn't care for chipset 
revision.)  And checking for hpet is just heuristics (or what is the 
rationale behind it?) not a real check whether the override should be ignored 
or not. Are you actually sure that so many nforceX boards have broken bioses? 
References? I would prefer a DMI check and only apply the quirk for *known* 
broken bioses instead fo "blindly" doing it as in my case my mcp51 system is 
unstable with the quirk applied - it *never* needed the quirk.

I found this:
http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.6.5/2004043905-nforce2_timer.patch

So it seems the original (proposed?) version did a DMI check for known broken 
bioses. Why was this approach abandoned?

According to
http://lkml.org/lkml/2006/10/19/427
it seems only nforce2 and perhaps some nforce3 are relevant.


To sum it up, I think it is a step into the right direction, but still not 
correct.
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Friday 08 February 2008 Andi Kleen hast written:
 On Thu, Feb 07, 2008 at 10:21:18PM +0100, Prakash Punnoor wrote:
  On the day of Thursday 07 February 2008 Andi Kleen hast written:
   Replace the old for all of nvidia quirk with a quirk containing pci
   device ID. I goobled this list together from pci.ids and googling and
   it may be incomplete, but so far I haven't had complaints.
  
   + QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x02f0, nvidia_timer), /* mcp 51/nf4 ?
   */
 
  If you want to skip timer override on this board, this is a *NAK* from
  me. I told you the last time, it only works reliably here on MCP51 with
  timer

 Hmm, if you told me it got lost somewhere, sorry.

I at least found this post: http://lkml.org/lkml/2006/8/13/2 though I remeber 
we had some discussions. ;-)


  override working. Even before Asus released a bios which had an option to
  enable the hpet, I needed the override or I got irratic behaviour. Since
  I got hpet enabled I gave up on arguing as the wrongly triggered quirk
  didn't bug me anymore.

 Ok we can keep the HPET check if that makes you more happy.

  IIRC my nforce2 needed the override. I didn't see that in the list.

 The list only contains IDs where the override should be ignored; so
 if it has a correct one and it's not there everything is fine.

Sorry, I meant the opposite. I needed the acpi_skip_timer_override kernel 
parameter for nforce2, thus no override. So this chipset is missing here. At 
least I remember that my nforce2 needed the skipping, 
otherwise the timer stayed in XT-PIC mode even when APIC was requested.

 I'm appending a revised patch. Does it work for you?

I haven't tested it, but it would work as it would bail out in my case 
because of the hpet check. The problem I see with this approach - as with the 
old one -  it simply wants to ignore the override for a whole bunch of 
chipsets. (The old one is catastrophic as it even doesn't care for chipset 
revision.)  And checking for hpet is just heuristics (or what is the 
rationale behind it?) not a real check whether the override should be ignored 
or not. Are you actually sure that so many nforceX boards have broken bioses? 
References? I would prefer a DMI check and only apply the quirk for *known* 
broken bioses instead fo blindly doing it as in my case my mcp51 system is 
unstable with the quirk applied - it *never* needed the quirk.

I found this:
http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.6.5/2004043905-nforce2_timer.patch

So it seems the original (proposed?) version did a DMI check for known broken 
bioses. Why was this approach abandoned?

According to
http://lkml.org/lkml/2006/10/19/427
it seems only nforce2 and perhaps some nforce3 are relevant.


To sum it up, I think it is a step into the right direction, but still not 
correct.
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Friday 08 February 2008 Andi Kleen hast written:
 On Fri, Feb 08, 2008 at 04:13:35PM +0100, Prakash Punnoor wrote:

  Sorry, I meant the opposite. I needed the acpi_skip_timer_override kernel
  parameter for nforce2, thus no override. So this chipset is missing here.
  At least I remember that my nforce2 needed the skipping,

 I hope you remember correctly and mean it this time. It would be better
 if you could double check.

Yes, confirmed. timer w/o the skipping stays XT-PIC on nforce2.

w/o skipping:

  0: 153413XT-PIC-XTtimer
  1: 10   IO-APIC-edge  i8042
  8:  2   IO-APIC-edge  rtc
  9:  0   IO-APIC-fasteoi   acpi
 12:112   IO-APIC-edge  i8042
 14: 37   IO-APIC-edge  ide0
 16: 165137   IO-APIC-fasteoi   eth0
 17:  0   IO-APIC-fasteoi   Technisat/B2C2 FlexCop II/IIb/III Digital 
TV PCI Driver
 18:  0   IO-APIC-fasteoi   NVidia nForce2
 19:   7922   IO-APIC-fasteoi   nvidia
NMI:  0
LOC: 153209
ERR:  0
MIS:  0

w/ skipping:
   CPU0
  0:  47834   IO-APIC-edge  timer
  1: 10   IO-APIC-edge  i8042
  8:  2   IO-APIC-edge  rtc
  9:  0   IO-APIC-fasteoi   acpi
 12:112   IO-APIC-edge  i8042
 14: 37   IO-APIC-edge  ide0
 16: 152413   IO-APIC-fasteoi   eth0
 17:  0   IO-APIC-fasteoi   Technisat/B2C2 FlexCop II/IIb/III Digital 
TV PCI Driver
 18:  0   IO-APIC-fasteoi   NVidia nForce2
 19:   1582   IO-APIC-fasteoi   nvidia
NMI:  0
LOC:  47736
ERR:  0
MIS:  0


lspci -n:
00:00.0 0600: 10de:01e0 (rev c1)
00:00.1 0500: 10de:01eb (rev c1)
00:00.2 0500: 10de:01ee (rev c1)
00:00.3 0500: 10de:01ed (rev c1)
00:00.4 0500: 10de:01ec (rev c1)
00:00.5 0500: 10de:01ef (rev c1)
00:01.0 0601: 10de:0060 (rev a3)
00:01.1 0c05: 10de:0064 (rev a2)
00:02.0 0c03: 10de:0067 (rev a3)
00:02.1 0c03: 10de:0067 (rev a3)
00:02.2 0c03: 10de:0068 (rev a3)
00:04.0 0200: 10de:0066 (rev a1)
00:05.0 0401: 10de:006b (rev a2)
00:06.0 0401: 10de:006a (rev a1)
00:08.0 0604: 10de:006c (rev a3)
00:09.0 0101: 10de:0065 (rev a2)
00:0d.0 0c00: 10de:006e (rev a3)
00:1e.0 0604: 10de:01e8 (rev c1)
01:08.0 0280: 13d0:2103 (rev 01)
02:00.0 0300: 10de:0281 (rev a1)

 I'm a little sceptical because we had this patch in OpenSUSE 10.3
 and I didn't think there were complaints from NF2 users.
 With the changes you're requesting it turns from something
 very well tested into something experimental.

Well, even w/o the skipping my nforce2 system wasn't unstable, AFAIK. So I 
don't think just because of the XT-PIC entry people would complain.

See why I don't want the quirk to be applied more than needed? *NOT* applying 
the quirk on nforce2 didn't cause any obvious side effects. APPLYING to mcp51 
causes hard lock-ups.

 But NF2 should not need a timer override anyways so probably
 ignoring it there is ok.

 Actually checking CK804 is already an Nforce2, but you might
 have NF2S which has a different ID. Do you have full lspci/lspci -n
 output?

My nforce2 board has different id then the listed ones, so that one needs to 
be included.

 Ok I'm appending another patch that adds the NF2S too, can
 you please test it on that machine?

No point if the quirk doesn't get triggered.


   I'm appending a revised patch. Does it work for you?
 
  I haven't tested it, but it would work as it would bail out in my case

 Can you please test it?

Will try the final version...

  or not. Are you actually sure that so many nforceX boards have broken
  bioses?

 Yes, it was a problem in the Nvidia reference BIOS that they sent to OEMs
 to base their own BIOS on, so pretty much everybody had this problem.

 We went over this with Nvidia engineers with a fine comb at this
 point. If you search the mailing list archives you might even
 find the discussions.

Yes, I actually linked to that discussion in the previous mail and there Allen 
Martin only stated that nforce2 and 3 may be affected. So I wonder why you 
(or Len) include nforce4 and mcp51 and so on?

Can't the quirk be made more intelligent? Ie. if we want APIC mode and timer 
stays as XT-PIC, then and only then rewire the timer and don't use the 
override, ie apply quirk? If rewiring isn't possible, then the kernel should 
als least print out a big fat warning that the user should probably skip the 
override. I don't know enough on the subject to explain it more precisely.

bye,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Friday 08 February 2008 Andi Kleen hast written:
 On Fri, Feb 08, 2008 at 06:39:17PM +0100, Prakash Punnoor wrote:
  On the day of Friday 08 February 2008 Andi Kleen hast written:
   On Fri, Feb 08, 2008 at 04:13:35PM +0100, Prakash Punnoor wrote:
Sorry, I meant the opposite. I needed the acpi_skip_timer_override
kernel parameter for nforce2, thus no override. So this chipset is
missing here. At least I remember that my nforce2 needed the
skipping,
  
   I hope you remember correctly and mean it this time. It would be better
   if you could double check.
 
  Yes, confirmed. timer w/o the skipping stays XT-PIC on nforce2.

 Confirmed what? Did you test my patch on both machines?
 What was the result?

I confirmed that it (nforce2) needed the acpi_skip_timer_override. If you read 
my mail, you knew I didn't test your patch.

  lspci -n:

 Please always send lspci without -n too; I hate looking up hex codes
 by hand when a computer can do that for me.

  02:00.0 0300: 10de:0281 (rev a1)
 
   I'm a little sceptical because we had this patch in OpenSUSE 10.3
   and I didn't think there were complaints from NF2 users.
   With the changes you're requesting it turns from something
   very well tested into something experimental.
 
  Well, even w/o the skipping my nforce2 system wasn't unstable, AFAIK. So
  I don't think just because of the XT-PIC entry people would complain.

 Timer override only does something in APIC mode and when you see XT-PIC
 in /proc/interrupts then you're not in APIC mode. All these patches
 are a no-op in this state.

Perhaps I wasn't percise, Len Brown had it in his earlier patch descriptions:


workaround for nForce2 BIOS bug: XT-PIC timer in IOAPIC mode 
acpi_skip_timer_override boot parameter


or


Since the hardware is connected to APIC pin0, it is a BIOS bug 
 that an ACPI interrupt source override from pin2 to IRQ0 exists. 
 
With this simple 2.6.5 patch you can specify acpi_skip_timer_override 
 to ignore that bogus BIOS directive. The result is with your 
 ACPI-enabled APIC-enabled kernel, you'll get IRQ0 IO-APIC-edge timer. 


This is exactly what I observed on the nforce2.

My kernels are compiled and configured for APIC. With broken BIOSes the timer 
ends up as XT-PIC anyway. That is what I wanted to say and which you could 
see from my cat /proc/interrupts dumps.




Why can't the kernel check for this condition and only activate the quirk then 
instead of current and your proposed broken behaviour?




  See why I don't want the quirk to be applied more than needed? *NOT*
  applying the quirk on nforce2 didn't cause any obvious side effects.
  APPLYING to mcp51 causes hard lock-ups.

 Can you please just test the patches instead of speculating what they
 might do or not do?

No, I do understand C code and I know the ID of my board. So I am not 
speculating, just saving myself time and hassle.

You are not even taking the time to really read what I say. I am not your   
guinea pig. Why should I simply waste my time? Esp. my nforce2 system is a 
productive system and I usually don't mess with it. So come up with a patch 
that makes sense (and triggers on my nforce2 and does not trigger on my 
mcp51) in my eyes, or I won't test anything and keep the NAK.

I don't think you did your research correctly coming up with the first version 
of the patch, as it ignored the nforce2 altogether. And the original version 
was made for nforce2 exclusively! So why should I trust that you know what 
you are doing? I don't get the impression. You also didn't gave references 
where you get your IDs in the patch. I at least tried to gave some references 
that putting in those IDs is *wrong*. If you can provide those references 
(and not some search for it) you could strengthen your point. Provide some 
bug reports or lkml posts where users of nforce4, mcp51 needed the 
skip_override to get their system stable.




I don't care whether this patch has been in some kernel for some time. It is 
still wrong (worse for nforce2 users, though better for newer nvidia chipset 
users as at last the quirk doesn't get appield for them)!





BTW, nforce2 lspci:
00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?) (rev 
c1)
00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev c1)
00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1)
00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1)
00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1)
00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev c1)
00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2)
00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev a3)
00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller (rev a3)
00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev a3)
00:04.0

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Friday 08 February 2008 Prakash Punnoor hast written:
 On the day of Friday 08 February 2008 Andi Kleen hast written:
  On Thu, Feb 07, 2008 at 10:21:18PM +0100, Prakash Punnoor wrote:
   On the day of Thursday 07 February 2008 Andi Kleen hast written:
Replace the old for all of nvidia quirk with a quirk containing pci
device ID. I goobled this list together from pci.ids and googling and
it may be incomplete, but so far I haven't had complaints.
   
+   QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x02f0, nvidia_timer), /* mcp 
51/nf4
? */
  
   If you want to skip timer override on this board, this is a *NAK* from
   me. I told you the last time, it only works reliably here on MCP51 with
   timer
 
  Hmm, if you told me it got lost somewhere, sorry.

 I at least found this post: http://lkml.org/lkml/2006/8/13/2 though I
 remeber we had some discussions. ;-)

http://lkml.org/lkml/2006/8/13/25

I killed one digit by mistake...
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Thursday 07 February 2008 Andi Kleen hast written:

> Replace the old "for all of nvidia" quirk with a quirk containing pci
> device ID. I goobled this list together from pci.ids and googling and it
> may be incomplete, but so far I haven't had complaints.

> + QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x02f0, nvidia_timer), /* mcp 51/nf4 ? */

If you want to skip timer override on this board, this is a *NAK* from me. I 
told you the last time, it only works reliably here on MCP51 with timer 
override working. Even before Asus released a bios which had an option to 
enable the hpet, I needed the override or I got irratic behaviour. Since I 
got hpet enabled I gave up on arguing as the wrongly triggered quirk didn't 
bug me anymore.

IIRC my nforce2 needed the override. I didn't see that in the list.

00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00: de 10 f0 02 06 00 b0 00 a2 00 00 05 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 c0 81
30: 00 00 00 00 44 00 00 00 00 00 00 00 ff 00 00 00

bye,
-- 
(°=         =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Replace nvidia timer override quirk with pci id list

[Prakash Punnoor]

On the day of Thursday 07 February 2008 Andi Kleen hast written:

 Replace the old for all of nvidia quirk with a quirk containing pci
 device ID. I goobled this list together from pci.ids and googling and it
 may be incomplete, but so far I haven't had complaints.

 + QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x02f0, nvidia_timer), /* mcp 51/nf4 ? */

If you want to skip timer override on this board, this is a *NAK* from me. I 
told you the last time, it only works reliably here on MCP51 with timer 
override working. Even before Asus released a bios which had an option to 
enable the hpet, I needed the override or I got irratic behaviour. Since I 
got hpet enabled I gave up on arguing as the wrongly triggered quirk didn't 
bug me anymore.

IIRC my nforce2 needed the override. I didn't see that in the list.

00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00: de 10 f0 02 06 00 b0 00 a2 00 00 05 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 c0 81
30: 00 00 00 00 44 00 00 00 00 00 00 00 ff 00 00 00

bye,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 1/2] msi: set 'En' bit of MSI Mapping Capability on HT platform

[Prakash Punnoor]

Hi,

> According to the HyperTransport spec, 'En' indicate if the MSI Mapping is
> active. So it should be set when enable the MSI.

Great! This is what I needed to get MSI going on my MCP51 board. I added some 
ids, but I think there were not necessary, as I only got

PCI: :00:00.0: enabled HT MSI mapping
PCI: :00:10.1: enabled HT MSI mapping

were those devices are:
00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
Flags: bus master, 66MHz, fast devsel, latency 0
Capabilities: [44] HyperTransport: Slave or Primary Interface
Capabilities: [e0] HyperTransport: MSI Mapping Enable+ Fixed-
00: de 10 f0 02 06 00 b0 00 a2 00 00 05 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 c0 81
30: 00 00 00 00 44 00 00 00 00 00 00 00 ff 00 00 00

According to your patch, you named this device
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_C51_MEMC0   0x02F0
So is the lspci database not correct or your naming? lspci lists some 
memcontrollers for me, but they don't seem to have MSI specific items.


00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2)
Subsystem: ASUSTeK Computer Inc. Unknown device 81cb
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 319
Memory at fe024000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 2
Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ 
Queue=0/0 Enable+
Capabilities: [6c] HyperTransport: MSI Mapping Enable+ Fixed+
00: de 10 6c 02 06 04 b0 00 a2 00 03 04 00 00 80 00
10: 00 40 02 fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 cb 81
30: 00 00 00 00 44 00 00 00 00 00 00 00 05 02 02 05

Yay:
cat /proc/interrupts
319: 26   9357   PCI-MSI-edge  HDA Intel


So, now sata_nv and nvidia binary graphics driver could activate MSI, as 
well. :-)

One thing I noticed in the patch:
+   if (((bridge_dev = pci_find_slot(0, 0)) != NULL) &&

You rather want to use pci_get_bus_and_slot instead, as pci_find_slot is 
deprecated.

Thanks!
-- 
(°=     =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 1/2] msi: set 'En' bit of MSI Mapping Capability on HT platform

[Prakash Punnoor]

Hi,

 According to the HyperTransport spec, 'En' indicate if the MSI Mapping is
 active. So it should be set when enable the MSI.

Great! This is what I needed to get MSI going on my MCP51 board. I added some 
ids, but I think there were not necessary, as I only got

PCI: :00:00.0: enabled HT MSI mapping
PCI: :00:10.1: enabled HT MSI mapping

were those devices are:
00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
Flags: bus master, 66MHz, fast devsel, latency 0
Capabilities: [44] HyperTransport: Slave or Primary Interface
Capabilities: [e0] HyperTransport: MSI Mapping Enable+ Fixed-
00: de 10 f0 02 06 00 b0 00 a2 00 00 05 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 c0 81
30: 00 00 00 00 44 00 00 00 00 00 00 00 ff 00 00 00

According to your patch, you named this device
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_C51_MEMC0   0x02F0
So is the lspci database not correct or your naming? lspci lists some 
memcontrollers for me, but they don't seem to have MSI specific items.


00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2)
Subsystem: ASUSTeK Computer Inc. Unknown device 81cb
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 319
Memory at fe024000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 2
Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ 
Queue=0/0 Enable+
Capabilities: [6c] HyperTransport: MSI Mapping Enable+ Fixed+
00: de 10 6c 02 06 04 b0 00 a2 00 03 04 00 00 80 00
10: 00 40 02 fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 cb 81
30: 00 00 00 00 44 00 00 00 00 00 00 00 05 02 02 05

Yay:
cat /proc/interrupts
319: 26   9357   PCI-MSI-edge  HDA Intel


So, now sata_nv and nvidia binary graphics driver could activate MSI, as 
well. :-)

One thing I noticed in the patch:
+   if (((bridge_dev = pci_find_slot(0, 0)) != NULL) 

You rather want to use pci_get_bus_and_slot instead, as pci_find_slot is 
deprecated.

Thanks!
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

2.6.24-rc1-gec3b67c1 broken reg. libata-sata_nv in non NCQ mode

[Prakash Punnoor]

Hi,

I cannot boot above kernel when I *disable* swncq support which got added in 
sata_nv. Problem seems that some component thinks driver is in ncq mode while 
it is not, as I see a queue depth of 31 instead of 0 on boot., ie I see 
something like this:

ata1.00: 625142448 sectors, multi 1: LBA48 NCQ (depth 31/32)

though I disabled ncq.And then boot "hangs" at

sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
 sda

while detecting partitions I guess. (Note, the boot messages are from ncq 
enabled kernel, but look alike, at least regarding queue depth...) The kernel 
doesn't really hang but tries detecting something while spitting out some 
errors. I simply wasn't patient enough.

Anyway, I tried 2.6.23 with swncq patch on top, and here I don't have any 
problems with swncq or w/o it. (NCQ depth also gets correctly reported). I 
diffed the 2.6.23 patched driver with git one and they are nearly identical 
excpet some ID changes, whcih don't affect me, es I have a MCP51 chipset. So 
something in libata changed and got broken or sata_nv wasn't adopted for that 
change.

HTH,
-- 
(°=     =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

2.6.24-rc1-gec3b67c1 broken reg. libata-sata_nv in non NCQ mode

[Prakash Punnoor]

Hi,

I cannot boot above kernel when I *disable* swncq support which got added in 
sata_nv. Problem seems that some component thinks driver is in ncq mode while 
it is not, as I see a queue depth of 31 instead of 0 on boot., ie I see 
something like this:

ata1.00: 625142448 sectors, multi 1: LBA48 NCQ (depth 31/32)

though I disabled ncq.And then boot hangs at

sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
 sda

while detecting partitions I guess. (Note, the boot messages are from ncq 
enabled kernel, but look alike, at least regarding queue depth...) The kernel 
doesn't really hang but tries detecting something while spitting out some 
errors. I simply wasn't patient enough.

Anyway, I tried 2.6.23 with swncq patch on top, and here I don't have any 
problems with swncq or w/o it. (NCQ depth also gets correctly reported). I 
diffed the 2.6.23 patched driver with git one and they are nearly identical 
excpet some ID changes, whcih don't affect me, es I have a MCP51 chipset. So 
something in libata changed and got broken or sata_nv wasn't adopted for that 
change.

HTH,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: sata_nv issues with MCP51 SATA controller

[Prakash Punnoor]

On the day of Saturday 15 September 2007 Jon Ivar Rykkelid hast written:
> Do you get the same error messages that I do if you're running without
> the "acpi_use_timer_override" (this is how it is spelled, isn't it) ?

I don't remeber which messages I get, but for me the kernel didn't boot with 
certain versions. Any yes, you spelled it correctly.
-- 
(°=     =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: sata_nv issues with MCP51 SATA controller

[Prakash Punnoor]

On the day of Friday 14 September 2007 Jon Ivar Rykkelid hast written:
> Hi, I'm getting inmore confident that the driver is the issue.
>
>
> (Or have anyone EVER been successful with the latest kernel/driver on
> this HW)?

I don't have exaclty the same hw, but the same chipset and I don't have any 
problems - even with the swncq patch applied. Do you have an hpet? If not, 
try booting with acpi_use_time_override. My system won't work with skipping 
the override.

-- 
(°=     =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: sata_nv issues with MCP51 SATA controller

[Prakash Punnoor]

On the day of Friday 14 September 2007 Jon Ivar Rykkelid hast written:
 Hi, I'm getting inmore confident that the driver is the issue.


 (Or have anyone EVER been successful with the latest kernel/driver on
 this HW)?

I don't have exaclty the same hw, but the same chipset and I don't have any 
problems - even with the swncq patch applied. Do you have an hpet? If not, 
try booting with acpi_use_time_override. My system won't work with skipping 
the override.

-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: sata_nv issues with MCP51 SATA controller

[Prakash Punnoor]

On the day of Saturday 15 September 2007 Jon Ivar Rykkelid hast written:
 Do you get the same error messages that I do if you're running without
 the acpi_use_timer_override (this is how it is spelled, isn't it) ?

I don't remeber which messages I get, but for me the kernel didn't boot with 
certain versions. Any yes, you spelled it correctly.
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: sata_nv issues with MCP51 SATA controller

[Prakash Punnoor]

On the day of Thursday 13 September 2007 Jon Ivar Rykkelid hast written:
> Resending, as my first attempts contained HTML and was blocked...
>
> Tejun Heo wrote:
> > Jon Ivar Rykkelid wrote:
> >> Thanks for the suggestion, but sata_nv is not built modular in my
> >> current kernel, so "no can do" at the moment
> >> (However, if some expert REALLY thinks this will fix things, I will
> >> CERTAINLY recompile and give it a go)
> >
> > Passing "sata_nv.adma=0" as kernel boot parameter will do the trick.
>
> Ahh, silly me... Of course!
> Ooops, I just got back, and verified: I actually have sata_nv running as
> a module after all on this server... My bad.
> I fixed /etc/modprobe.conf to include the following two lines:
> "
> alias scsi_hostadapter sata_nv
> options sata_nv adma=0
> ...
> "

I don't think it will matter, as adma doesn't affect MCP51, but only nforce4. 
So I'd look for other trouble makers.
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: sata_nv issues with MCP51 SATA controller

[Prakash Punnoor]

On the day of Thursday 13 September 2007 Jon Ivar Rykkelid hast written:
 Resending, as my first attempts contained HTML and was blocked...

 Tejun Heo wrote:
  Jon Ivar Rykkelid wrote:
  Thanks for the suggestion, but sata_nv is not built modular in my
  current kernel, so no can do at the moment
  (However, if some expert REALLY thinks this will fix things, I will
  CERTAINLY recompile and give it a go)
 
  Passing sata_nv.adma=0 as kernel boot parameter will do the trick.

 Ahh, silly me... Of course!
 Ooops, I just got back, and verified: I actually have sata_nv running as
 a module after all on this server... My bad.
 I fixed /etc/modprobe.conf to include the following two lines:
 
 alias scsi_hostadapter sata_nv
 options sata_nv adma=0
 ...
 

I don't think it will matter, as adma doesn't affect MCP51, but only nforce4. 
So I'd look for other trouble makers.
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: Why do so many machines need "noapic"?

[Prakash Punnoor]

On the day of Friday 07 September 2007 Chuck Ebbert hast written:
> On 09/06/2007 07:31 AM, Andi Kleen wrote:
> > Chuck Ebbert <[EMAIL PROTECTED]> writes:
> >> Some systems lock up without the noapic option.
> >
> > Please find patterns: cpu type, chipsets, mainboard vendors etc.
>
> This is the first one I've actually had in front of me:
>
>   HP TX1000 notebook
>   Nvidia C51/MCP51 mobile chipset

Do you have a hpet? If not, have you tried using acpi_use_timer_override with 
apic?

bye,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: Why do so many machines need noapic?

[Prakash Punnoor]

On the day of Friday 07 September 2007 Chuck Ebbert hast written:
 On 09/06/2007 07:31 AM, Andi Kleen wrote:
  Chuck Ebbert [EMAIL PROTECTED] writes:
  Some systems lock up without the noapic option.
 
  Please find patterns: cpu type, chipsets, mainboard vendors etc.

 This is the first one I've actually had in front of me:

   HP TX1000 notebook
   Nvidia C51/MCP51 mobile chipset

Do you have a hpet? If not, have you tried using acpi_use_timer_override with 
apic?

bye,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: Linux 2.6.23-rc5

[Prakash Punnoor]

On the day of Sunday 02 September 2007 Prakash Punnoor hast written:
> Hi,
>
> 2.6.23-rc5 locks up hard (Magic Syskeys won't even work) after a few
> minutes of work on x86_64. 2.6.23-rc4 was fine. I'll try git-bisect to find
> out what is causing trouble. Yes, I am using nvidia binary but it didn't
> make troubles since ages... When I found the bugger, I'll try whether it
> works w/o nvidia binary.

It seems my system is stable again with patch from

http://lkml.org/lkml/2007/9/2/219

Though I didn't get a light show on hang...

-- 
(°=     =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: Linux 2.6.23-rc5

[Prakash Punnoor]

On the day of Sunday 02 September 2007 Prakash Punnoor hast written:
 Hi,

 2.6.23-rc5 locks up hard (Magic Syskeys won't even work) after a few
 minutes of work on x86_64. 2.6.23-rc4 was fine. I'll try git-bisect to find
 out what is causing trouble. Yes, I am using nvidia binary but it didn't
 make troubles since ages... When I found the bugger, I'll try whether it
 works w/o nvidia binary.

It seems my system is stable again with patch from

http://lkml.org/lkml/2007/9/2/219

Though I didn't get a light show on hang...

-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

ipv4_get_l4proto: Frag of proto 17

[Prakash Punnoor]

Hi,

since 2.6.23-rc1 my log gets cluttered with

ipv4_get_l4proto: Frag of proto 17

What is the reason?

Cheers,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [2.6.20.17 review 35/58] forcedeth bug fix: realtek phy

[Prakash Punnoor]

On the day of Thursday 23 August 2007 Greg KH hast written:
> On Wed, Aug 22, 2007 at 10:42:25PM +0200, Willy Tarreau wrote:
> > On Wed, Aug 22, 2007 at 08:15:03PM +0200, Prakash Punnoor wrote:
> > > Hi,
> > >
> > > even if Greg is waiting for some special invitation
> > > (http://lkml.org/lkml/2007/8/14/229), I suggest putting this patch by
> > > Ayaz on top:
> > >
> > > http://lkml.org/lkml/2007/8/10/296
> >
> > That's what I prepare first, but then noticed it's not in mainline.
> >
> > > Perhaps Ayaz wants to give Greg the clarification he needs... :sigh:
> >
> > He should, as the fix is not in mainline either :-(
> > I don't think Greg asks for specific clarification, just a plain patch
> > with a short commit log on its own which does not include remains of
> > older mails.
>
> Exactly, that is what I am waiting for.
>
> And also I need the change to go into mainline first, as we can not
> diverge with the -stable releases.

Can we get that into mainline then? I haven't seen forcedeth in MAINTAINERS, 
so I added netdev to the cc list.

bye,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [2.6.20.17 review 35/58] forcedeth bug fix: realtek phy

[Prakash Punnoor]

On the day of Thursday 23 August 2007 Greg KH hast written:
 On Wed, Aug 22, 2007 at 10:42:25PM +0200, Willy Tarreau wrote:
  On Wed, Aug 22, 2007 at 08:15:03PM +0200, Prakash Punnoor wrote:
   Hi,
  
   even if Greg is waiting for some special invitation
   (http://lkml.org/lkml/2007/8/14/229), I suggest putting this patch by
   Ayaz on top:
  
   http://lkml.org/lkml/2007/8/10/296
 
  That's what I prepare first, but then noticed it's not in mainline.
 
   Perhaps Ayaz wants to give Greg the clarification he needs... :sigh:
 
  He should, as the fix is not in mainline either :-(
  I don't think Greg asks for specific clarification, just a plain patch
  with a short commit log on its own which does not include remains of
  older mails.

 Exactly, that is what I am waiting for.

 And also I need the change to go into mainline first, as we can not
 diverge with the -stable releases.

Can we get that into mainline then? I haven't seen forcedeth in MAINTAINERS, 
so I added netdev to the cc list.

bye,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [2.6.20.17 review 35/58] forcedeth bug fix: realtek phy

[Prakash Punnoor]

Hi,

even if Greg is waiting for some special invitation 
(http://lkml.org/lkml/2007/8/14/229), I suggest putting this patch by Ayaz on 
top:

http://lkml.org/lkml/2007/8/10/296

Perhaps Ayaz wants to give Greg the clarification he needs... :sigh:

bye,

Prakash


On the day of Wednesday 22 August 2007 Willy Tarreau hast written:
> This patch contains errata fixes for the realtek phy. It only renamed the
> defines to be phy specific.
>
> Signed-off-by: Ayaz Abdulla <[EMAIL PROTECTED]>
> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> Signed-off-by: Willy Tarreau <[EMAIL PROTECTED]>
> ---
>  drivers/net/forcedeth.c |   54
> +++ 1 files changed, 54
> insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
> index c383dc3..dbfdbed 100644
> --- a/drivers/net/forcedeth.c
> +++ b/drivers/net/forcedeth.c
> @@ -554,6 +554,7 @@ union ring_type {
>  #define PHY_OUI_MARVELL  0x5043
>  #define PHY_OUI_CICADA   0x03f1
>  #define PHY_OUI_VITESSE  0x01c1
> +#define PHY_OUI_REALTEK  0x01c1
>  #define PHYID1_OUI_MASK  0x03ff
>  #define PHYID1_OUI_SHFT  6
>  #define PHYID2_OUI_MASK  0xfc00
> @@ -583,6 +584,13 @@ union ring_type {
>  #define PHY_VITESSE_INIT80x0100
>  #define PHY_VITESSE_INIT90x8f82
>  #define PHY_VITESSE_INIT10   0x0
> +#define PHY_REALTEK_INIT_REG10x1f
> +#define PHY_REALTEK_INIT_REG20x19
> +#define PHY_REALTEK_INIT_REG30x13
> +#define PHY_REALTEK_INIT10x
> +#define PHY_REALTEK_INIT20x8e00
> +#define PHY_REALTEK_INIT30x0001
> +#define PHY_REALTEK_INIT40xad17
>
>  #define PHY_GIGABIT  0x0100
>
> @@ -1106,6 +1114,28 @@ static int phy_init(struct net_device *dev)
>   return PHY_ERROR;
>   }
>   }
> + if (np->phy_oui == PHY_OUI_REALTEK) {
> + if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, 
> PHY_REALTEK_INIT1))
> { +   printk(KERN_INFO "%s: phy init failed.
> ", pci_name(np->pci_dev));
> + return PHY_ERROR;
> + }
> + if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG2, 
> PHY_REALTEK_INIT2))
> { +   printk(KERN_INFO "%s: phy init failed.
> ", pci_name(np->pci_dev));
> + return PHY_ERROR;
> + }
> + if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, 
> PHY_REALTEK_INIT3))
> { +   printk(KERN_INFO "%s: phy init failed.
> ", pci_name(np->pci_dev));
> + return PHY_ERROR;
> + }
> + if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG3, 
> PHY_REALTEK_INIT4))
> { +   printk(KERN_INFO "%s: phy init failed.
> ", pci_name(np->pci_dev));
> + return PHY_ERROR;
> + }
> + if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, 
> PHY_REALTEK_INIT1))
> { +   printk(KERN_INFO "%s: phy init failed.
> ", pci_name(np->pci_dev));
> + return PHY_ERROR;
> + }
> + }
>
>   /* set advertise register */
>   reg = mii_rw(dev, np->phyaddr, MII_ADVERTISE, MII_READ);
> @@ -1242,6 +1272,30 @@ static int phy_init(struct net_device *dev)
>   return PHY_ERROR;
>   }
>   }
> + if (np->phy_oui == PHY_OUI_REALTEK) {
> + /* reset could have cleared these out, set them back */
> + if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, 
> PHY_REALTEK_INIT1))
> { +   printk(KERN_INFO "%s: phy init failed.
> ", pci_name(np->pci_dev));
> + return PHY_ERROR;
> + }
> + if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG2, 
> PHY_REALTEK_INIT2))
> { +   printk(KERN_INFO "%s: phy init failed.
> ", pci_name(np->pci_dev));
> + return PHY_ERROR;
> + }
> + if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, 
> PHY_REALTEK_INIT3))
> { +   printk(KERN_INFO "%s: phy init failed.
> ", pci_name(np->pci_dev));
> + return PHY_ERROR;
> + }
> + if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG3, 
> PHY_REALTEK_INIT4))
> { +   printk(KERN_INFO "%s: phy init failed.
> ", pci_name(np->pci_dev));
> +     return PHY_ERROR;
> + }
> + if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, 
> PHY_REALTEK_INIT1))
> { +   printk(KERN_INFO "%s: phy init failed.
> ", pci_name(np->pci_dev));
> + return PHY_ERROR;
> + }
> + }
> +
>   /* some phys clear out pause advertisment on reset, set it back */
>   mii_rw(dev, np->phyaddr, MII_ADVERTISE, reg);
>
> --
> 1.5.2.5



-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [2.6.20.17 review 35/58] forcedeth bug fix: realtek phy

[Prakash Punnoor]

Hi,

even if Greg is waiting for some special invitation 
(http://lkml.org/lkml/2007/8/14/229), I suggest putting this patch by Ayaz on 
top:

http://lkml.org/lkml/2007/8/10/296

Perhaps Ayaz wants to give Greg the clarification he needs... :sigh:

bye,

Prakash


On the day of Wednesday 22 August 2007 Willy Tarreau hast written:
 This patch contains errata fixes for the realtek phy. It only renamed the
 defines to be phy specific.

 Signed-off-by: Ayaz Abdulla [EMAIL PROTECTED]
 Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
 Signed-off-by: Willy Tarreau [EMAIL PROTECTED]
 ---
  drivers/net/forcedeth.c |   54
 +++ 1 files changed, 54
 insertions(+), 0 deletions(-)

 diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
 index c383dc3..dbfdbed 100644
 --- a/drivers/net/forcedeth.c
 +++ b/drivers/net/forcedeth.c
 @@ -554,6 +554,7 @@ union ring_type {
  #define PHY_OUI_MARVELL  0x5043
  #define PHY_OUI_CICADA   0x03f1
  #define PHY_OUI_VITESSE  0x01c1
 +#define PHY_OUI_REALTEK  0x01c1
  #define PHYID1_OUI_MASK  0x03ff
  #define PHYID1_OUI_SHFT  6
  #define PHYID2_OUI_MASK  0xfc00
 @@ -583,6 +584,13 @@ union ring_type {
  #define PHY_VITESSE_INIT80x0100
  #define PHY_VITESSE_INIT90x8f82
  #define PHY_VITESSE_INIT10   0x0
 +#define PHY_REALTEK_INIT_REG10x1f
 +#define PHY_REALTEK_INIT_REG20x19
 +#define PHY_REALTEK_INIT_REG30x13
 +#define PHY_REALTEK_INIT10x
 +#define PHY_REALTEK_INIT20x8e00
 +#define PHY_REALTEK_INIT30x0001
 +#define PHY_REALTEK_INIT40xad17

  #define PHY_GIGABIT  0x0100

 @@ -1106,6 +1114,28 @@ static int phy_init(struct net_device *dev)
   return PHY_ERROR;
   }
   }
 + if (np-phy_oui == PHY_OUI_REALTEK) {
 + if (mii_rw(dev, np-phyaddr, PHY_REALTEK_INIT_REG1, 
 PHY_REALTEK_INIT1))
 { +   printk(KERN_INFO %s: phy init failed.
 , pci_name(np-pci_dev));
 + return PHY_ERROR;
 + }
 + if (mii_rw(dev, np-phyaddr, PHY_REALTEK_INIT_REG2, 
 PHY_REALTEK_INIT2))
 { +   printk(KERN_INFO %s: phy init failed.
 , pci_name(np-pci_dev));
 + return PHY_ERROR;
 + }
 + if (mii_rw(dev, np-phyaddr, PHY_REALTEK_INIT_REG1, 
 PHY_REALTEK_INIT3))
 { +   printk(KERN_INFO %s: phy init failed.
 , pci_name(np-pci_dev));
 + return PHY_ERROR;
 + }
 + if (mii_rw(dev, np-phyaddr, PHY_REALTEK_INIT_REG3, 
 PHY_REALTEK_INIT4))
 { +   printk(KERN_INFO %s: phy init failed.
 , pci_name(np-pci_dev));
 + return PHY_ERROR;
 + }
 + if (mii_rw(dev, np-phyaddr, PHY_REALTEK_INIT_REG1, 
 PHY_REALTEK_INIT1))
 { +   printk(KERN_INFO %s: phy init failed.
 , pci_name(np-pci_dev));
 + return PHY_ERROR;
 + }
 + }

   /* set advertise register */
   reg = mii_rw(dev, np-phyaddr, MII_ADVERTISE, MII_READ);
 @@ -1242,6 +1272,30 @@ static int phy_init(struct net_device *dev)
   return PHY_ERROR;
   }
   }
 + if (np-phy_oui == PHY_OUI_REALTEK) {
 + /* reset could have cleared these out, set them back */
 + if (mii_rw(dev, np-phyaddr, PHY_REALTEK_INIT_REG1, 
 PHY_REALTEK_INIT1))
 { +   printk(KERN_INFO %s: phy init failed.
 , pci_name(np-pci_dev));
 + return PHY_ERROR;
 + }
 + if (mii_rw(dev, np-phyaddr, PHY_REALTEK_INIT_REG2, 
 PHY_REALTEK_INIT2))
 { +   printk(KERN_INFO %s: phy init failed.
 , pci_name(np-pci_dev));
 + return PHY_ERROR;
 + }
 + if (mii_rw(dev, np-phyaddr, PHY_REALTEK_INIT_REG1, 
 PHY_REALTEK_INIT3))
 { +   printk(KERN_INFO %s: phy init failed.
 , pci_name(np-pci_dev));
 + return PHY_ERROR;
 + }
 + if (mii_rw(dev, np-phyaddr, PHY_REALTEK_INIT_REG3, 
 PHY_REALTEK_INIT4))
 { +   printk(KERN_INFO %s: phy init failed.
 , pci_name(np-pci_dev));
 + return PHY_ERROR;
 + }
 + if (mii_rw(dev, np-phyaddr, PHY_REALTEK_INIT_REG1, 
 PHY_REALTEK_INIT1))
 { +   printk(KERN_INFO %s: phy init failed.
 , pci_name(np-pci_dev));
 + return PHY_ERROR;
 + }
 + }
 +
   /* some phys clear out pause advertisment on reset, set it back */
   mii_rw(dev, np-phyaddr, MII_ADVERTISE, reg);

 --
 1.5.2.5



-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [patch 00/12] 2.6.22-stable review

[Prakash Punnoor]

Am Dienstag 14 August 2007 schrieb Greg KH:
> On Tue, Aug 14, 2007 at 06:13:34PM +0200, Prakash Punnoor wrote:
> > Am Dienstag 14 August 2007 schrieb Greg KH:
> > > This is the start of the stable review cycle for the 2.6.22.3 release.
> >
> > You missed this one: http://lkml.org/lkml/2007/8/10/296
> >
> > The buggy patch was introduced in 2.6.22.2, so it wouldn't be bad to fix
> > in .3...
>
> I asked for clarification about that patch, if it is really needed and
> matters, yet did not recieve any response yet.

Well, I can't speak for the author, but I at least would find it disturbing if 
some random values would be written into random registers of my hardware, 
when they were meant for a different hardware...

-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [patch 00/12] 2.6.22-stable review

[Prakash Punnoor]

Am Dienstag 14 August 2007 schrieb Greg KH:
> This is the start of the stable review cycle for the 2.6.22.3 release.

You missed this one: http://lkml.org/lkml/2007/8/10/296

The buggy patch was introduced in 2.6.22.2, so it wouldn't be bad to fix 
in .3...

bye,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [patch 00/12] 2.6.22-stable review

[Prakash Punnoor]

Am Dienstag 14 August 2007 schrieb Greg KH:
 This is the start of the stable review cycle for the 2.6.22.3 release.

You missed this one: http://lkml.org/lkml/2007/8/10/296

The buggy patch was introduced in 2.6.22.2, so it wouldn't be bad to fix 
in .3...

bye,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [patch 00/12] 2.6.22-stable review

[Prakash Punnoor]

Am Dienstag 14 August 2007 schrieb Greg KH:
 On Tue, Aug 14, 2007 at 06:13:34PM +0200, Prakash Punnoor wrote:
  Am Dienstag 14 August 2007 schrieb Greg KH:
   This is the start of the stable review cycle for the 2.6.22.3 release.
 
  You missed this one: http://lkml.org/lkml/2007/8/10/296
 
  The buggy patch was introduced in 2.6.22.2, so it wouldn't be bad to fix
  in .3...

 I asked for clarification about that patch, if it is really needed and
 matters, yet did not recieve any response yet.

Well, I can't speak for the author, but I at least would find it disturbing if 
some random values would be written into random registers of my hardware, 
when they were meant for a different hardware...

-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: Linux 2.6.22.2

[Prakash Punnoor]

Hi,

I just noticed that PHY_OUI_VITESSE == PHY_OUI_REALTEK. Is that really 
intentional?

> diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
> index 42ba1c0..a361dba 100644
> --- a/drivers/net/forcedeth.c
> +++ b/drivers/net/forcedeth.c
> @@ -550,6 +550,8 @@ union ring_type {
>  /* PHY defines */
>  #define PHY_OUI_MARVELL  0x5043
>  #define PHY_OUI_CICADA   0x03f1
> +#define PHY_OUI_VITESSE  0x01c1
> +#define PHY_OUI_REALTEK  0x01c1
- 
(°=         =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: Linux 2.6.22.2

[Prakash Punnoor]

Hi,

I just noticed that PHY_OUI_VITESSE == PHY_OUI_REALTEK. Is that really 
intentional?

 diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
 index 42ba1c0..a361dba 100644
 --- a/drivers/net/forcedeth.c
 +++ b/drivers/net/forcedeth.c
 @@ -550,6 +550,8 @@ union ring_type {
  /* PHY defines */
  #define PHY_OUI_MARVELL  0x5043
  #define PHY_OUI_CICADA   0x03f1
 +#define PHY_OUI_VITESSE  0x01c1
 +#define PHY_OUI_REALTEK  0x01c1
- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: 2.6.23-rc1, KVM-AMD problem

[Prakash Punnoor]

Am Montag 30 Juli 2007 schrieb Avi Kivity:
> Alistair John Strachan wrote:
[...]
> > Basically, the installer seems to work fine, but Windows seemed to have
> > problems after installing post-SP2 updates. Maybe that's why not
> > everybody is seeing it yet.
>
> How about the attached patch? (I haven't yet tried to reproduce, but
> this can cause an AMD-only oops).

commit 80917728e43e248155c019f743655806b582b099
Author: Avi Kivity <[EMAIL PROTECTED]>
Date:   Mon Jul 30 15:56:36 2007 +0300

KVM: x86 emulator: disable writeback for debug register instructions

These are handled internally by the instruction.

Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>

diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index 1a90ba0..2136da5 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -1222,11 +1222,13 @@ twobyte_insn:
}
break;
case 0x21: /* mov from dr to reg */
+   no_wb = 1;
if (modrm_mod != 3)
goto cannot_emulate;
rc = emulator_get_dr(ctxt, modrm_reg, &_regs[modrm_rm]);
break;
case 0x23: /* mov from reg to dr */
+   no_wb = 1;
if (modrm_mod != 3)
goto cannot_emulate;
rc = emulator_set_dr(ctxt, modrm_reg, _regs[modrm_rm]);


Unfortunately this doesn't seem to have made it into 2.6.23-rc2. I need it as 
well, to make Windows XP boot up w/o hanging or reebooting my host machine.

Cheers,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: 2.6.23-rc1, KVM-AMD problem

[Prakash Punnoor]

Am Montag 30 Juli 2007 schrieb Avi Kivity:
 Alistair John Strachan wrote:
[...]
  Basically, the installer seems to work fine, but Windows seemed to have
  problems after installing post-SP2 updates. Maybe that's why not
  everybody is seeing it yet.

 How about the attached patch? (I haven't yet tried to reproduce, but
 this can cause an AMD-only oops).

commit 80917728e43e248155c019f743655806b582b099
Author: Avi Kivity [EMAIL PROTECTED]
Date:   Mon Jul 30 15:56:36 2007 +0300

KVM: x86 emulator: disable writeback for debug register instructions

These are handled internally by the instruction.

Signed-off-by: Avi Kivity [EMAIL PROTECTED]

diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index 1a90ba0..2136da5 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -1222,11 +1222,13 @@ twobyte_insn:
}
break;
case 0x21: /* mov from dr to reg */
+   no_wb = 1;
if (modrm_mod != 3)
goto cannot_emulate;
rc = emulator_get_dr(ctxt, modrm_reg, _regs[modrm_rm]);
break;
case 0x23: /* mov from reg to dr */
+   no_wb = 1;
if (modrm_mod != 3)
goto cannot_emulate;
rc = emulator_set_dr(ctxt, modrm_reg, _regs[modrm_rm]);


Unfortunately this doesn't seem to have made it into 2.6.23-rc2. I need it as 
well, to make Windows XP boot up w/o hanging or reebooting my host machine.

Cheers,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61

[Prakash Punnoor]

Am Montag 09 Juli 2007 schrieb Peer Chen:
> It's a rule for all our drivers not just for linux, also if we put the
> Maxtor drive to the blacklist so that its NCQ function won't be enable for
> all controllers of other vendors,but we don't have the strong evidence that
> those Maxtor HDDs are also broken for other controllers.

The Maxtor drive I mentioned earlier worked fine on a ULI AHCI controller with 
NCQ enabled for the few hours I used Linux on that machine for recovering 
purposes So I wouldn't want a global balcklist.

BTW, I now have 4 Seagate ST3320620AS on the MCP51, mostly in raid5 and they 
work fine with NCQ enabled and the second patch you/your co-worker posted.

Cheers,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61

[Prakash Punnoor]

Am Montag 09 Juli 2007 schrieb Peer Chen:
 It's a rule for all our drivers not just for linux, also if we put the
 Maxtor drive to the blacklist so that its NCQ function won't be enable for
 all controllers of other vendors,but we don't have the strong evidence that
 those Maxtor HDDs are also broken for other controllers.

The Maxtor drive I mentioned earlier worked fine on a ULI AHCI controller with 
NCQ enabled for the few hours I used Linux on that machine for recovering 
purposes So I wouldn't want a global balcklist.

BTW, I now have 4 Seagate ST3320620AS on the MCP51, mostly in raid5 and they 
work fine with NCQ enabled and the second patch you/your co-worker posted.

Cheers,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61

[Prakash Punnoor]

Am Mittwoch 27 Juni 2007 schrieb Peer Chen:
> We did the many test with the new version driver and didn't encounter
> that problem, but in certain cases, DMASETUP command packets from drive
> to the controller are corrupted, and the controller issues an R_ERR to
> the drive. Drives that comply with SATA spec will re-transmit the
> corrupted packet and normal operation continues. However, some Maxtor
> NCQ drives do not re-transmit the DMASETUP command packet, resulting in
> software timeout for this command. So if you are using the Maxtor HD and
> meet this problem,please don't enable the NCQ function.

Out of interest I tested the patch again with my Maxtor drive I mentioned in 
the other thread. Ths time it got worse. I couldn't boot anymore, ie init 
starts some services and then dies at random places as if corrupt data was 
transfered. With the previous patch the system worked, except the port 
resets.

Anyway, I'll ask Maxtor or rather Seagate to fix their firmware pointing at 
your diagnosis.

bye,
-- 
(°=         =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61

[Prakash Punnoor]

Am Mittwoch 27 Juni 2007 schrieb Peer Chen:
 We did the many test with the new version driver and didn't encounter
 that problem, but in certain cases, DMASETUP command packets from drive
 to the controller are corrupted, and the controller issues an R_ERR to
 the drive. Drives that comply with SATA spec will re-transmit the
 corrupted packet and normal operation continues. However, some Maxtor
 NCQ drives do not re-transmit the DMASETUP command packet, resulting in
 software timeout for this command. So if you are using the Maxtor HD and
 meet this problem,please don't enable the NCQ function.

Out of interest I tested the patch again with my Maxtor drive I mentioned in 
the other thread. Ths time it got worse. I couldn't boot anymore, ie init 
starts some services and then dies at random places as if corrupt data was 
transfered. With the previous patch the system worked, except the port 
resets.

Anyway, I'll ask Maxtor or rather Seagate to fix their firmware pointing at 
your diagnosis.

bye,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [Trivial Patch] Remove JFFS2 dependency on internal Zlib header

[Prakash Punnoor]

Daniel Hazelton wrote:


Signed-off-by: Daniel Hazelton <[EMAIL PROTECTED]>

DRH

diff --git a/fs/jffs2/compr_zlib.c b/fs/jffs2/compr_zlib.c
index 2b87fcc..9f1b935 100644
--- a/fs/jffs2/compr_zlib.c
+++ b/fs/jffs2/compr_zlib.c
@@ -16,7 +16,6 @@
 #include 
 #include 
 #include 
-#include 
 #include "nodelist.h"
 #include "compr.h"

@@ -154,7 +153,7 @@ static int jffs2_zlib_decompress(unsigned char *data_in,

/* If it's deflate, and it's got no preset dictionary, then
   we can tell zlib to skip the adler32 check. */
-   if (srclen > 2 && !(data_in[1] & PRESET_DICT) &&
+   if (srclen > 2 && !(data_in[1] & 0x20) &&
((data_in[0] & 0x0f) == Z_DEFLATED) &&
!(((data_in[0]<<8) + data_in[1]) % 31)) {




Why not

#define PRESET_DICT 0x20

instead of obfuscating the code with a magic number ? (Or name it 
differently if it clashes with something else...)



Cheers,

Prakash
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Trivial Patch] Remove JFFS2 dependency on internal Zlib header

[Prakash Punnoor]

Daniel Hazelton wrote:


Signed-off-by: Daniel Hazelton [EMAIL PROTECTED]

DRH

diff --git a/fs/jffs2/compr_zlib.c b/fs/jffs2/compr_zlib.c
index 2b87fcc..9f1b935 100644
--- a/fs/jffs2/compr_zlib.c
+++ b/fs/jffs2/compr_zlib.c
@@ -16,7 +16,6 @@
 #include linux/kernel.h
 #include linux/slab.h
 #include linux/zlib.h
-#include linux/zutil.h
 #include nodelist.h
 #include compr.h

@@ -154,7 +153,7 @@ static int jffs2_zlib_decompress(unsigned char *data_in,

/* If it's deflate, and it's got no preset dictionary, then
   we can tell zlib to skip the adler32 check. */
-   if (srclen  2  !(data_in[1]  PRESET_DICT) 
+   if (srclen  2  !(data_in[1]  0x20) 
((data_in[0]  0x0f) == Z_DEFLATED) 
!(((data_in[0]8) + data_in[1]) % 31)) {




Why not

#define PRESET_DICT 0x20

instead of obfuscating the code with a magic number ? (Or name it 
differently if it clashes with something else...)



Cheers,

Prakash
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Kconfig powernow-k8 driver should depend on ACPI P-States driver

[Prakash Punnoor]

Am Mittwoch 16 Mai 2007 schrieb Joshua Hoblitt:
> Hello,
>
> Below is a one line patch to possibly fix this bug:
>
> http://bugs.gentoo.org/show_bug.cgi?id=178585
> http://bugzilla.kernel.org/show_bug.cgi?id=8075
>
> If the kernel is configured with:
>
> CONFIG_X86_POWERNOW_K8=y
> CONFIG_X86_ACPI_CPUFREQ=m
>
> Which is currently an allowed configuration, the powernow-k8 driver on
> an SMP system will fail with a warning like:

NAK. I have an Athlon X2 and it works for me w/o the P states driver compiled 
in.

YOu probably should ask the vendor to fix the bios or simply compile in the p 
states driver additionally w/o forcing the user to do it.

Maybe you want to give a hint in the p states driver help text?
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Kconfig powernow-k8 driver should depend on ACPI P-States driver

[Prakash Punnoor]

Am Mittwoch 16 Mai 2007 schrieb Joshua Hoblitt:
 Hello,

 Below is a one line patch to possibly fix this bug:

 http://bugs.gentoo.org/show_bug.cgi?id=178585
 http://bugzilla.kernel.org/show_bug.cgi?id=8075

 If the kernel is configured with:

 CONFIG_X86_POWERNOW_K8=y
 CONFIG_X86_ACPI_CPUFREQ=m

 Which is currently an allowed configuration, the powernow-k8 driver on
 an SMP system will fail with a warning like:

NAK. I have an Athlon X2 and it works for me w/o the P states driver compiled 
in.

YOu probably should ask the vendor to fix the bios or simply compile in the p 
states driver additionally w/o forcing the user to do it.

Maybe you want to give a hint in the p states driver help text?
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [patch] CFS scheduler, -v7

[Prakash Punnoor]

Am Sonntag 29 April 2007 schrieb Prakash Punnoor:
> Am Samstag 28 April 2007 schrieb Ingo Molnar:
> > i'm pleased to announce release -v7 of the CFS scheduler patchset. (The
> > main goal of CFS is to implement "desktop scheduling" with as high
> > quality as technically possible.)
> >
> > The CFS patch against v2.6.21 (or against v2.6.20.8) can be downloaded
> > from the usual place:
>
> I made a quick test with the ac3 encoder aften, I tested against rsdl 0.36
> (I think it was). Time was slightly worse: >5.9 secs (with two threads on
> Athlon64 X2 x86_64). mainline gives me 5.4sec. rsdl took 5.8 sec.
>
> I haven't testes earlier cfs nor later sd. Seems scheduler gets optimized
> more for single core than smp?
>
> http://aften.sourceforge.net/

Just as an update: Ingo managed to fix this issue in v9. Nice work!

Cheers,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [patch] CFS scheduler, -v7

[Prakash Punnoor]

Am Sonntag 29 April 2007 schrieb Prakash Punnoor:
 Am Samstag 28 April 2007 schrieb Ingo Molnar:
  i'm pleased to announce release -v7 of the CFS scheduler patchset. (The
  main goal of CFS is to implement desktop scheduling with as high
  quality as technically possible.)
 
  The CFS patch against v2.6.21 (or against v2.6.20.8) can be downloaded
  from the usual place:

 I made a quick test with the ac3 encoder aften, I tested against rsdl 0.36
 (I think it was). Time was slightly worse: 5.9 secs (with two threads on
 Athlon64 X2 x86_64). mainline gives me 5.4sec. rsdl took 5.8 sec.

 I haven't testes earlier cfs nor later sd. Seems scheduler gets optimized
 more for single core than smp?

 http://aften.sourceforge.net/

Just as an update: Ingo managed to fix this issue in v9. Nice work!

Cheers,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [patch] CFS scheduler, -v7

[Prakash Punnoor]

Am Samstag 28 April 2007 schrieb Ingo Molnar:
> i'm pleased to announce release -v7 of the CFS scheduler patchset. (The
> main goal of CFS is to implement "desktop scheduling" with as high
> quality as technically possible.)
>
> The CFS patch against v2.6.21 (or against v2.6.20.8) can be downloaded
> from the usual place:

I made a quick test with the ac3 encoder aften, I tested against rsdl 0.36 (I 
think it was). Time was slightly worse: >5.9 secs (with two threads on 
Athlon64 X2 x86_64). mainline gives me 5.4sec. rsdl took 5.8 sec.

I haven't testes earlier cfs nor later sd. Seems scheduler gets optimized more 
for single core than smp?

http://aften.sourceforge.net/

Cheers,
-- 
(°=     =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [patch] CFS scheduler, -v7

[Prakash Punnoor]

Am Samstag 28 April 2007 schrieb Ingo Molnar:
 i'm pleased to announce release -v7 of the CFS scheduler patchset. (The
 main goal of CFS is to implement desktop scheduling with as high
 quality as technically possible.)

 The CFS patch against v2.6.21 (or against v2.6.20.8) can be downloaded
 from the usual place:

I made a quick test with the ac3 encoder aften, I tested against rsdl 0.36 (I 
think it was). Time was slightly worse: 5.9 secs (with two threads on 
Athlon64 X2 x86_64). mainline gives me 5.4sec. rsdl took 5.8 sec.

I haven't testes earlier cfs nor later sd. Seems scheduler gets optimized more 
for single core than smp?

http://aften.sourceforge.net/

Cheers,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

Re: [ck] [PATCH] sched: staircase deadline misc fixes

[Prakash Punnoor]

Am Sonntag 01 April 2007 schrieb michael chang:
> On 4/1/07, Prakash Punnoor <[EMAIL PROTECTED]> wrote:
> > Am Mittwoch 28 März 2007 schrieb Prakash Punnoor:

> > >
> > > Hi, I am using 2.6.21-rc5 with rsdl 0.37 and think I still see a
> > > regression with my Athlon X2. Namely using this ac3 encoder
> > > (http://aften.sourceforge.net/), which I parallelized in a simple way,
> > > with my test sample I remember having encoding times of ~5.4sec with
> > > vanilla and ~5.8 sec with rsdl - once the whole test wave is in cache.

> > BTW, I confirmed this regression. With vanilla 2.76.21-rc5 I get back my
> > 5.4 secs with the test sample and two threads. Furtmermore for me vanilla
>
> Which version of RSDL were you comparing to 2.6.21-rc5? Did you try
> the patch in the first message (http://lkml.org/lkml/2007/3/28/146)?
> The patch that _began_ this thread had SMP fixes in it... (Also, IIRC,
> the latest version of the scheduler no longer has the rotating
> component - so it's just SDl now.)

As I said, I tried 0.37. Didn't it have the fix inside? Actually I am 
reluctant to go back to (r)sdl, as it didn't show improvements for me, yet.

-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


pgplirkxW9eu6.pgp
Description: PGP signature

Re: [ck] [PATCH] sched: staircase deadline misc fixes

[Prakash Punnoor]

Am Sonntag 01 April 2007 schrieb michael chang:
 On 4/1/07, Prakash Punnoor [EMAIL PROTECTED] wrote:
  Am Mittwoch 28 März 2007 schrieb Prakash Punnoor:

  
   Hi, I am using 2.6.21-rc5 with rsdl 0.37 and think I still see a
   regression with my Athlon X2. Namely using this ac3 encoder
   (http://aften.sourceforge.net/), which I parallelized in a simple way,
   with my test sample I remember having encoding times of ~5.4sec with
   vanilla and ~5.8 sec with rsdl - once the whole test wave is in cache.

  BTW, I confirmed this regression. With vanilla 2.76.21-rc5 I get back my
  5.4 secs with the test sample and two threads. Furtmermore for me vanilla

 Which version of RSDL were you comparing to 2.6.21-rc5? Did you try
 the patch in the first message (http://lkml.org/lkml/2007/3/28/146)?
 The patch that _began_ this thread had SMP fixes in it... (Also, IIRC,
 the latest version of the scheduler no longer has the rotating
 component - so it's just SDl now.)

As I said, I tried 0.37. Didn't it have the fix inside? Actually I am 
reluctant to go back to (r)sdl, as it didn't show improvements for me, yet.

-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


pgplirkxW9eu6.pgp
Description: PGP signature

Re: [ck] [PATCH] sched: staircase deadline misc fixes

[Prakash Punnoor]

Am Mittwoch 28 März 2007 schrieb Prakash Punnoor:
> Am Mittwoch 28 März 2007 schrieb Con Kolivas:
> > I'm cautiously optimistic that we're at the thin edge of the bugfix wedge
> > now.
> >
> > ---
> > set_load_weight() should be performed after p->quota is set. This fixes a
> > large SMP performance regression.
>
> Hi, I am using 2.6.21-rc5 with rsdl 0.37 and think I still see a regression
> with my Athlon X2. Namely using this ac3 encoder
> (http://aften.sourceforge.net/), which I parallelized in a simple way, with
> my test sample I remember having encoding times of ~5.4sec with vanilla and
> ~5.8 sec with rsdl - once the whole test wave is in cache. Otherwise you
> can easily I/O limit the encoder. ;-) You need to get sources from svn
> though. The current 0.06 release doesn't have threads support.

BTW, I confirmed this regression. With vanilla 2.76.21-rc5 I get back my 5.4 
secs with the test sample and two threads. Furtmermore for me vanilla 
actually feels nicer on my dual core, even with load - just subjectively 
that's why I ditched rsdl...

Cheers,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


pgpRah6vrej2y.pgp
Description: PGP signature

Re: [ck] [PATCH] sched: staircase deadline misc fixes

[Prakash Punnoor]

Am Mittwoch 28 März 2007 schrieb Prakash Punnoor:
 Am Mittwoch 28 März 2007 schrieb Con Kolivas:
  I'm cautiously optimistic that we're at the thin edge of the bugfix wedge
  now.
 
  ---
  set_load_weight() should be performed after p-quota is set. This fixes a
  large SMP performance regression.

 Hi, I am using 2.6.21-rc5 with rsdl 0.37 and think I still see a regression
 with my Athlon X2. Namely using this ac3 encoder
 (http://aften.sourceforge.net/), which I parallelized in a simple way, with
 my test sample I remember having encoding times of ~5.4sec with vanilla and
 ~5.8 sec with rsdl - once the whole test wave is in cache. Otherwise you
 can easily I/O limit the encoder. ;-) You need to get sources from svn
 though. The current 0.06 release doesn't have threads support.

BTW, I confirmed this regression. With vanilla 2.76.21-rc5 I get back my 5.4 
secs with the test sample and two threads. Furtmermore for me vanilla 
actually feels nicer on my dual core, even with load - just subjectively 
that's why I ditched rsdl...

Cheers,
-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


pgpRah6vrej2y.pgp
Description: PGP signature

Re: [ck] [PATCH] sched: staircase deadline misc fixes

[Prakash Punnoor]

Am Mittwoch 28 März 2007 schrieb Con Kolivas:
> I'm cautiously optimistic that we're at the thin edge of the bugfix wedge
> now.
>
> ---
> set_load_weight() should be performed after p->quota is set. This fixes a
> large SMP performance regression.

Hi, I am using 2.6.21-rc5 with rsdl 0.37 and think I still see a regression 
with my Athlon X2. Namely using this ac3 encoder 
(http://aften.sourceforge.net/), which I parallelized in a simple way, with 
my test sample I remember having encoding times of ~5.4sec with vanilla and 
~5.8 sec with rsdl - once the whole test wave is in cache. Otherwise you can 
easily I/O limit the encoder. ;-) You need to get sources from svn though. 
The current 0.06 release doesn't have threads support.

Cheers,

-- 
(°=     =°)
//\ Prakash Punnoor /\\
V_/ \_V


pgpPd1wincXFE.pgp
Description: PGP signature

Re: [ck] [PATCH] sched: staircase deadline misc fixes

[Prakash Punnoor]

Am Mittwoch 28 März 2007 schrieb Con Kolivas:
 I'm cautiously optimistic that we're at the thin edge of the bugfix wedge
 now.

 ---
 set_load_weight() should be performed after p-quota is set. This fixes a
 large SMP performance regression.

Hi, I am using 2.6.21-rc5 with rsdl 0.37 and think I still see a regression 
with my Athlon X2. Namely using this ac3 encoder 
(http://aften.sourceforge.net/), which I parallelized in a simple way, with 
my test sample I remember having encoding times of ~5.4sec with vanilla and 
~5.8 sec with rsdl - once the whole test wave is in cache. Otherwise you can 
easily I/O limit the encoder. ;-) You need to get sources from svn though. 
The current 0.06 release doesn't have threads support.

Cheers,

-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


pgpPd1wincXFE.pgp
Description: PGP signature

Re: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen with pata_amd

[Prakash Punnoor]

Am Sonntag 18 Februar 2007 schrieb Prakash Punnoor:
> Am Samstag 17 Februar 2007 schrieb Prakash Punnoor:
> > Am Samstag 17 Februar 2007 schrieb Prakash Punnoor:
> > > Hi,
> > >
> > > I tried a cat /dev/sdb1 >/dev/null from a Sandisk Extreme III CF card
> > > connected via cf to IDE adapteer to onboard ide of nforce c51. I am
> > > usinf 2.6.20 on x86_64. For a few seconds it worked but then it dropped
> > > to pio4:
> > >
> > > ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> > > ata3.00: (BMDMA stat 0x65)
> > > ata3.00: cmd c8/00:80:1f:7d:01/00:00:00:00:00/e0 tag 0 cdb 0x0 data
> > > 65536 in res 58/00:00:9e:7d:01/00:00:00:00:00/e0 Emask 0x2 (HSM
> > > violation) ata3: soft resetting port
> > > ata3.00: simplex DMA is claimed by other device, disabling DMA
> > > ata3.00: configured for PIO4
> > > ata3: EH complete
> > > SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
> > > sdb: Write Protect is off
> > > sdb: Mode Sense: 00 3a 00 00
> > > SCSI device sdb: write cache: enabled, read cache: enabled, doesn't
> > > support DPO or FUA
>
> [...]
>
> > The ide driver worked better - for a short time and then this happens:
> >
> > hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
> > ide: failed opcode was: unknown
> > hda: DMA disabled
>
> I connected the cf to ide adapter to an ide to sata adapter and using this
> combination on sata_nv makes no troubkes whatsoever. So what goues wrong
> with pata_amd/amd ide driver? BTW, I found specs for the cf card on the
> sandisk website. Perhaps someone wants to check whether the amd drivers
> deal corretcly with the true ide mode implemented in the cf card?
>
> http://www.sandisk.com/Assets/File/OEM/Manuals/ProdManCFlashv11.0.pdf

For what it's worth: I tried the cd-ide adapter with the sandisk cf on another 
machine with ide uli/ali driver and here I don't have any problems as well. 
So everything points to amd driver...

-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


pgpb8koZZyXqc.pgp
Description: PGP signature

Re: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen with pata_amd

[Prakash Punnoor]

Am Sonntag 18 Februar 2007 schrieb Prakash Punnoor:
 Am Samstag 17 Februar 2007 schrieb Prakash Punnoor:
  Am Samstag 17 Februar 2007 schrieb Prakash Punnoor:
   Hi,
  
   I tried a cat /dev/sdb1 /dev/null from a Sandisk Extreme III CF card
   connected via cf to IDE adapteer to onboard ide of nforce c51. I am
   usinf 2.6.20 on x86_64. For a few seconds it worked but then it dropped
   to pio4:
  
   ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
   ata3.00: (BMDMA stat 0x65)
   ata3.00: cmd c8/00:80:1f:7d:01/00:00:00:00:00/e0 tag 0 cdb 0x0 data
   65536 in res 58/00:00:9e:7d:01/00:00:00:00:00/e0 Emask 0x2 (HSM
   violation) ata3: soft resetting port
   ata3.00: simplex DMA is claimed by other device, disabling DMA
   ata3.00: configured for PIO4
   ata3: EH complete
   SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
   sdb: Write Protect is off
   sdb: Mode Sense: 00 3a 00 00
   SCSI device sdb: write cache: enabled, read cache: enabled, doesn't
   support DPO or FUA

 [...]

  The ide driver worked better - for a short time and then this happens:
 
  hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
  ide: failed opcode was: unknown
  hda: DMA disabled

 I connected the cf to ide adapter to an ide to sata adapter and using this
 combination on sata_nv makes no troubkes whatsoever. So what goues wrong
 with pata_amd/amd ide driver? BTW, I found specs for the cf card on the
 sandisk website. Perhaps someone wants to check whether the amd drivers
 deal corretcly with the true ide mode implemented in the cf card?

 http://www.sandisk.com/Assets/File/OEM/Manuals/ProdManCFlashv11.0.pdf

For what it's worth: I tried the cd-ide adapter with the sandisk cf on another 
machine with ide uli/ali driver and here I don't have any problems as well. 
So everything points to amd driver...

-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


pgpb8koZZyXqc.pgp
Description: PGP signature

Re: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen with pata_amd

[Prakash Punnoor]

Am Samstag 17 Februar 2007 schrieb Prakash Punnoor:
> Am Samstag 17 Februar 2007 schrieb Prakash Punnoor:
> > Hi,
> >
> > I tried a cat /dev/sdb1 >/dev/null from a Sandisk Extreme III CF card
> > connected via cf to IDE adapteer to onboard ide of nforce c51. I am usinf
> > 2.6.20 on x86_64. For a few seconds it worked but then it dropped to
> > pio4:
> >
> > ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> > ata3.00: (BMDMA stat 0x65)
> > ata3.00: cmd c8/00:80:1f:7d:01/00:00:00:00:00/e0 tag 0 cdb 0x0 data 65536
> > in res 58/00:00:9e:7d:01/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
> > ata3: soft resetting port
> > ata3.00: simplex DMA is claimed by other device, disabling DMA
> > ata3.00: configured for PIO4
> > ata3: EH complete
> > SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
> > sdb: Write Protect is off
> > sdb: Mode Sense: 00 3a 00 00
> > SCSI device sdb: write cache: enabled, read cache: enabled, doesn't
> > support DPO or FUA
> >
[...]
>
> The ide driver worked better - for a short time and then this happens:
>
> hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
> ide: failed opcode was: unknown
> hda: DMA disabled

I connected the cf to ide adapter to an ide to sata adapter and using this 
combination on sata_nv makes no troubkes whatsoever. So what goues wrong with 
pata_amd/amd ide driver? BTW, I found specs for the cf card on the sandisk 
website. Perhaps someone wants to check whether the amd drivers deal 
corretcly with the true ide mode implemented in the cf card?

http://www.sandisk.com/Assets/File/OEM/Manuals/ProdManCFlashv11.0.pdf


scsi 1:0:0:0: Direct-Access ATA  SanDisk SDCFX-10 HDX  PQ: 0 ANSI: 5
SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
 sdb: sdb1
sd 1:0:0:0: Attached scsi removable disk sdb
sd 1:0:0:0: Attached scsi generic sg1 type 0


-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


pgpYZjLkm4oVW.pgp
Description: PGP signature

Re: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen with pata_amd

[Prakash Punnoor]

Am Samstag 17 Februar 2007 schrieb Prakash Punnoor:
 Am Samstag 17 Februar 2007 schrieb Prakash Punnoor:
  Hi,
 
  I tried a cat /dev/sdb1 /dev/null from a Sandisk Extreme III CF card
  connected via cf to IDE adapteer to onboard ide of nforce c51. I am usinf
  2.6.20 on x86_64. For a few seconds it worked but then it dropped to
  pio4:
 
  ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
  ata3.00: (BMDMA stat 0x65)
  ata3.00: cmd c8/00:80:1f:7d:01/00:00:00:00:00/e0 tag 0 cdb 0x0 data 65536
  in res 58/00:00:9e:7d:01/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
  ata3: soft resetting port
  ata3.00: simplex DMA is claimed by other device, disabling DMA
  ata3.00: configured for PIO4
  ata3: EH complete
  SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
  sdb: Write Protect is off
  sdb: Mode Sense: 00 3a 00 00
  SCSI device sdb: write cache: enabled, read cache: enabled, doesn't
  support DPO or FUA
 
[...]

 The ide driver worked better - for a short time and then this happens:

 hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
 ide: failed opcode was: unknown
 hda: DMA disabled

I connected the cf to ide adapter to an ide to sata adapter and using this 
combination on sata_nv makes no troubkes whatsoever. So what goues wrong with 
pata_amd/amd ide driver? BTW, I found specs for the cf card on the sandisk 
website. Perhaps someone wants to check whether the amd drivers deal 
corretcly with the true ide mode implemented in the cf card?

http://www.sandisk.com/Assets/File/OEM/Manuals/ProdManCFlashv11.0.pdf


scsi 1:0:0:0: Direct-Access ATA  SanDisk SDCFX-10 HDX  PQ: 0 ANSI: 5
SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
 sdb: sdb1
sd 1:0:0:0: Attached scsi removable disk sdb
sd 1:0:0:0: Attached scsi generic sg1 type 0


-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


pgpYZjLkm4oVW.pgp
Description: PGP signature

Re: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen with pata_amd

[Prakash Punnoor]

Am Samstag 17 Februar 2007 schrieb Prakash Punnoor:
> Hi,
>
> I tried a cat /dev/sdb1 >/dev/null from a Sandisk Extreme III CF card
> connected via cf to IDE adapteer to onboard ide of nforce c51. I am usinf
> 2.6.20 on x86_64. For a few seconds it worked but then it dropped to pio4:
>
> ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> ata3.00: (BMDMA stat 0x65)
> ata3.00: cmd c8/00:80:1f:7d:01/00:00:00:00:00/e0 tag 0 cdb 0x0 data 65536
> in res 58/00:00:9e:7d:01/00:00:00:00:00/e0 Emask 0x2 (HSM violation) ata3:
> soft resetting port
> ata3.00: simplex DMA is claimed by other device, disabling DMA
> ata3.00: configured for PIO4
> ata3: EH complete
> SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
> sdb: Write Protect is off
> sdb: Mode Sense: 00 3a 00 00
> SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support
> DPO or FUA
>
>
> While boot I get:
> sata_nv :00:0e.0: version 3.2
> ACPI: PCI Interrupt Link [APSI] enabled at IRQ 22
> ACPI: PCI Interrupt :00:0e.0[A] -> Link [APSI] -> GSI 22 (level, low)
> -> IRQ 22
> PCI: Setting latency timer of device :00:0e.0 to 64
> ata1: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xE000 irq 22
> ata2: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xE008 irq 22
> scsi0 : sata_nv
> ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> ata1.00: ATA-7, max UDMA/133, 586114704 sectors: LBA48 NCQ (depth 0/32)
> ata1.00: ata1: dev 0 multi count 1
> ata1.00: configured for UDMA/133
> scsi1 : sata_nv
> ata2: SATA link down (SStatus 0 SControl 300)
> ATA: abnormal status 0x7F on port 0x977
> scsi 0:0:0:0: Direct-Access ATA  Maxtor 7V300F0   VA11 PQ: 0 ANSI:
> 5 SCSI device sda: 586114704 512-byte hdwr sectors (300091 MB)
> sda: Write Protect is off
> sda: Mode Sense: 00 3a 00 00
> SCSI device sda: write cache: enabled, read cache: enabled, doesn't support
> DPO or FUA
> SCSI device sda: 586114704 512-byte hdwr sectors (300091 MB)
> sda: Write Protect is off
> sda: Mode Sense: 00 3a 00 00
> SCSI device sda: write cache: enabled, read cache: enabled, doesn't support
> DPO or FUA
>  sda: sda1 sda2 < sda5 sda6 sda7 sda8 > sda3
> sd 0:0:0:0: Attached scsi disk sda
> sd 0:0:0:0: Attached scsi generic sg0 type 0
> pata_amd :00:0d.0: version 0.2.7
> PCI: Setting latency timer of device :00:0d.0 to 64
> ata3: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xF400 irq 14
> ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF408 irq 15
> scsi2 : pata_amd
> ata3.00: CFA, max MWDMA2, 2001888 sectors: LBA
> ata3.00: ata3: dev 0 multi count 0
> ata3.00: configured for MWDMA2
> scsi3 : pata_amd
> ata4: port disabled. ignoring.
> ata4: reset failed, giving up
> scsi 2:0:0:0: Direct-Access ATA  SanDisk SDCFX-10 HDX  PQ: 0 ANSI:
> 5 SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
> sdb: Write Protect is off
> sdb: Mode Sense: 00 3a 00 00
> SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support
> DPO or FUA
> SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
> sdb: Write Protect is off
> sdb: Mode Sense: 00 3a 00 00
> SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support
> DPO or FUA
>  sdb: sdb1
> sd 2:0:0:0: Attached scsi removable disk sdb
> sd 2:0:0:0: Attached scsi generic sg1 type 0

The ide driver worked better - for a short time and then this happens:

hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: DMA disabled

Any idea?

-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


pgpb7iLmg1VQd.pgp
Description: PGP signature

exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen with pata_amd

[Prakash Punnoor]

Hi,

I tried a cat /dev/sdb1 >/dev/null from a Sandisk Extreme III CF card 
connected via cf to IDE adapteer to onboard ide of nforce c51. I am usinf 
2.6.20 on x86_64. For a few seconds it worked but then it dropped to pio4:

ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: (BMDMA stat 0x65)
ata3.00: cmd c8/00:80:1f:7d:01/00:00:00:00:00/e0 tag 0 cdb 0x0 data 65536 in
 res 58/00:00:9e:7d:01/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
ata3: soft resetting port
ata3.00: simplex DMA is claimed by other device, disabling DMA
ata3.00: configured for PIO4
ata3: EH complete
SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA


While boot I get:
sata_nv :00:0e.0: version 3.2
ACPI: PCI Interrupt Link [APSI] enabled at IRQ 22
ACPI: PCI Interrupt :00:0e.0[A] -> Link [APSI] -> GSI 22 (level, low) -> 
IRQ 22
PCI: Setting latency timer of device :00:0e.0 to 64
ata1: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xE000 irq 22
ata2: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xE008 irq 22
scsi0 : sata_nv
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-7, max UDMA/133, 586114704 sectors: LBA48 NCQ (depth 0/32)
ata1.00: ata1: dev 0 multi count 1
ata1.00: configured for UDMA/133
scsi1 : sata_nv
ata2: SATA link down (SStatus 0 SControl 300)
ATA: abnormal status 0x7F on port 0x977
scsi 0:0:0:0: Direct-Access ATA  Maxtor 7V300F0   VA11 PQ: 0 ANSI: 5
SCSI device sda: 586114704 512-byte hdwr sectors (300091 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
SCSI device sda: 586114704 512-byte hdwr sectors (300091 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
 sda: sda1 sda2 < sda5 sda6 sda7 sda8 > sda3
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0
pata_amd :00:0d.0: version 0.2.7
PCI: Setting latency timer of device :00:0d.0 to 64
ata3: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xF400 irq 14
ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF408 irq 15
scsi2 : pata_amd
ata3.00: CFA, max MWDMA2, 2001888 sectors: LBA
ata3.00: ata3: dev 0 multi count 0
ata3.00: configured for MWDMA2
scsi3 : pata_amd
ata4: port disabled. ignoring.
ata4: reset failed, giving up
scsi 2:0:0:0: Direct-Access ATA  SanDisk SDCFX-10 HDX  PQ: 0 ANSI: 5
SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
 sdb: sdb1
sd 2:0:0:0: Attached scsi removable disk sdb
sd 2:0:0:0: Attached scsi generic sg1 type 0

-- 
(°=         =°)
//\ Prakash Punnoor /\\
V_/ \_V


pgpI7YX8eVN2j.pgp
Description: PGP signature

exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen with pata_amd

[Prakash Punnoor]

Hi,

I tried a cat /dev/sdb1 /dev/null from a Sandisk Extreme III CF card 
connected via cf to IDE adapteer to onboard ide of nforce c51. I am usinf 
2.6.20 on x86_64. For a few seconds it worked but then it dropped to pio4:

ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: (BMDMA stat 0x65)
ata3.00: cmd c8/00:80:1f:7d:01/00:00:00:00:00/e0 tag 0 cdb 0x0 data 65536 in
 res 58/00:00:9e:7d:01/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
ata3: soft resetting port
ata3.00: simplex DMA is claimed by other device, disabling DMA
ata3.00: configured for PIO4
ata3: EH complete
SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA


While boot I get:
sata_nv :00:0e.0: version 3.2
ACPI: PCI Interrupt Link [APSI] enabled at IRQ 22
ACPI: PCI Interrupt :00:0e.0[A] - Link [APSI] - GSI 22 (level, low) - 
IRQ 22
PCI: Setting latency timer of device :00:0e.0 to 64
ata1: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xE000 irq 22
ata2: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xE008 irq 22
scsi0 : sata_nv
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-7, max UDMA/133, 586114704 sectors: LBA48 NCQ (depth 0/32)
ata1.00: ata1: dev 0 multi count 1
ata1.00: configured for UDMA/133
scsi1 : sata_nv
ata2: SATA link down (SStatus 0 SControl 300)
ATA: abnormal status 0x7F on port 0x977
scsi 0:0:0:0: Direct-Access ATA  Maxtor 7V300F0   VA11 PQ: 0 ANSI: 5
SCSI device sda: 586114704 512-byte hdwr sectors (300091 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
SCSI device sda: 586114704 512-byte hdwr sectors (300091 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
 sda: sda1 sda2  sda5 sda6 sda7 sda8  sda3
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0
pata_amd :00:0d.0: version 0.2.7
PCI: Setting latency timer of device :00:0d.0 to 64
ata3: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xF400 irq 14
ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF408 irq 15
scsi2 : pata_amd
ata3.00: CFA, max MWDMA2, 2001888 sectors: LBA
ata3.00: ata3: dev 0 multi count 0
ata3.00: configured for MWDMA2
scsi3 : pata_amd
ata4: port disabled. ignoring.
ata4: reset failed, giving up
scsi 2:0:0:0: Direct-Access ATA  SanDisk SDCFX-10 HDX  PQ: 0 ANSI: 5
SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
 sdb: sdb1
sd 2:0:0:0: Attached scsi removable disk sdb
sd 2:0:0:0: Attached scsi generic sg1 type 0

-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


pgpI7YX8eVN2j.pgp
Description: PGP signature

Re: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen with pata_amd

[Prakash Punnoor]

Am Samstag 17 Februar 2007 schrieb Prakash Punnoor:
 Hi,

 I tried a cat /dev/sdb1 /dev/null from a Sandisk Extreme III CF card
 connected via cf to IDE adapteer to onboard ide of nforce c51. I am usinf
 2.6.20 on x86_64. For a few seconds it worked but then it dropped to pio4:

 ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
 ata3.00: (BMDMA stat 0x65)
 ata3.00: cmd c8/00:80:1f:7d:01/00:00:00:00:00/e0 tag 0 cdb 0x0 data 65536
 in res 58/00:00:9e:7d:01/00:00:00:00:00/e0 Emask 0x2 (HSM violation) ata3:
 soft resetting port
 ata3.00: simplex DMA is claimed by other device, disabling DMA
 ata3.00: configured for PIO4
 ata3: EH complete
 SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
 sdb: Write Protect is off
 sdb: Mode Sense: 00 3a 00 00
 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support
 DPO or FUA


 While boot I get:
 sata_nv :00:0e.0: version 3.2
 ACPI: PCI Interrupt Link [APSI] enabled at IRQ 22
 ACPI: PCI Interrupt :00:0e.0[A] - Link [APSI] - GSI 22 (level, low)
 - IRQ 22
 PCI: Setting latency timer of device :00:0e.0 to 64
 ata1: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xE000 irq 22
 ata2: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xE008 irq 22
 scsi0 : sata_nv
 ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
 ata1.00: ATA-7, max UDMA/133, 586114704 sectors: LBA48 NCQ (depth 0/32)
 ata1.00: ata1: dev 0 multi count 1
 ata1.00: configured for UDMA/133
 scsi1 : sata_nv
 ata2: SATA link down (SStatus 0 SControl 300)
 ATA: abnormal status 0x7F on port 0x977
 scsi 0:0:0:0: Direct-Access ATA  Maxtor 7V300F0   VA11 PQ: 0 ANSI:
 5 SCSI device sda: 586114704 512-byte hdwr sectors (300091 MB)
 sda: Write Protect is off
 sda: Mode Sense: 00 3a 00 00
 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support
 DPO or FUA
 SCSI device sda: 586114704 512-byte hdwr sectors (300091 MB)
 sda: Write Protect is off
 sda: Mode Sense: 00 3a 00 00
 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support
 DPO or FUA
  sda: sda1 sda2  sda5 sda6 sda7 sda8  sda3
 sd 0:0:0:0: Attached scsi disk sda
 sd 0:0:0:0: Attached scsi generic sg0 type 0
 pata_amd :00:0d.0: version 0.2.7
 PCI: Setting latency timer of device :00:0d.0 to 64
 ata3: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xF400 irq 14
 ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF408 irq 15
 scsi2 : pata_amd
 ata3.00: CFA, max MWDMA2, 2001888 sectors: LBA
 ata3.00: ata3: dev 0 multi count 0
 ata3.00: configured for MWDMA2
 scsi3 : pata_amd
 ata4: port disabled. ignoring.
 ata4: reset failed, giving up
 scsi 2:0:0:0: Direct-Access ATA  SanDisk SDCFX-10 HDX  PQ: 0 ANSI:
 5 SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
 sdb: Write Protect is off
 sdb: Mode Sense: 00 3a 00 00
 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support
 DPO or FUA
 SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
 sdb: Write Protect is off
 sdb: Mode Sense: 00 3a 00 00
 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support
 DPO or FUA
  sdb: sdb1
 sd 2:0:0:0: Attached scsi removable disk sdb
 sd 2:0:0:0: Attached scsi generic sg1 type 0

The ide driver worked better - for a short time and then this happens:

hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: DMA disabled

Any idea?

-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


pgpb7iLmg1VQd.pgp
Description: PGP signature

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Prakash Punnoor]

Am Sonntag 28 Januar 2007 schrieb Giuseppe Bilotta:
> From: Giuseppe Bilotta <[EMAIL PROTECTED]>

> Solve the issue by introducing a new boolean module parameter (useedid)
> which can be set to 0 to prevent the driver from using the EDID
> information.

I don't know whether this is possible, but wouldn't be a cleaner approach be 
to put this parameter to something fb specific and not nvidia specific? As 
Nvidia fb proabably isn't the only one using edid and so it wouldn't be 
necessary to introduce such a parameter for every fb driver...

-- 
(°=         =°)
//\ Prakash Punnoor /\\
V_/ \_V


pgpKeTjFOckVc.pgp
Description: PGP signature

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Prakash Punnoor]

Am Sonntag 28 Januar 2007 schrieb Giuseppe Bilotta:
 From: Giuseppe Bilotta [EMAIL PROTECTED]

 Solve the issue by introducing a new boolean module parameter (useedid)
 which can be set to 0 to prevent the driver from using the EDID
 information.

I don't know whether this is possible, but wouldn't be a cleaner approach be 
to put this parameter to something fb specific and not nvidia specific? As 
Nvidia fb proabably isn't the only one using edid and so it wouldn't be 
necessary to introduce such a parameter for every fb driver...

-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


pgpKeTjFOckVc.pgp
Description: PGP signature