Re: reason for VIA performance drop since 2.4.2-ac21
> It has nothing to do with mtrr or K6. In file arch/i386/kernel/pci-pc.c there > is a pci_fixup_via691_2 function. It appeared in 2.4.2-ac21. And it works for > my chipset - VIA_82C598. When I put "return" in body of this function, > recompile and start kernel 2.4.4 - "x11perf -putimage100" shows that video > works fast again. My log says that this was a change pulled in from Linus tree. I don't know who put it there or why > 1) this is just a debug code, and kernels >2.4.2-ac20 shouldn't be used by VIA > MVP3 owners > 2) this code fix crash possibility, and all kernels without it (including > 2.2.19) are buggy with VIA MVP3 Im not aware of any write posting bugs on the MVP3 but I dont follow the chipset in detail. - 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/
reason for VIA performance drop since 2.4.2-ac21
I have motherboard with VIA MVP3 chipset. I noticed big video slowdown since 2.4.2-ac21. Watching "divx" by avifile with new kernels is impossible, becouse very bad performance. Now, after few hours - I found the reason, and I don't understand it. It has nothing to do with mtrr or K6. In file arch/i386/kernel/pci-pc.c there is a pci_fixup_via691_2 function. It appeared in 2.4.2-ac21. And it works for my chipset - VIA_82C598. When I put "return" in body of this function, recompile and start kernel 2.4.4 - "x11perf -putimage100" shows that video works fast again. I see two possibilities: 1) this is just a debug code, and kernels >2.4.2-ac20 shouldn't be used by VIA MVP3 owners 2) this code fix crash possibility, and all kernels without it (including 2.2.19) are buggy with VIA MVP3 What is true, and is it safe to skip that function if I need 2.4 and fast video? - 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/
slow video since 2.4.2-ac21
After compiling 2.4.2-ac21 I noticed, that aviplay works much slower than before. "benchmark" from avifile shows that video output is about 3 times slower. I tested -ac22, -ac23, ..., -ac27, then 2.4.1, 2.4.2 and few other versions earlier than -ac21. 2.4.2-ac20 x11perf -putimage100 8000 reps @ 0.7736 msec ( 1290.0/sec): PutImage 100x100 square 2.4.2-ac27 x11perf -putimage100 3600 reps @ 1.3980 msec ( 715.0/sec): PutImage 100x100 square 2.2.19 - same result like 2.4.2-ac20 only "-putimage100" shows diffrences, results of "x11perf -scroll100" and "x11perf -rect100" for all kernel versions were similiar My hardware: VIA VT82C586B, K6-2, Voodoo3. My software: XFree86 Version 4.0.99.1 (CVS), glibc-2.1.3, gcc-2.95.3. - 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: 2.4.2-ac21
On Fri, Mar 23, 2001 at 01:12:06AM +, Andrew Morton wrote: > Lawrence Walton wrote: > > > > Hello all > > 2.4.2-ac21 seems to have a couple problems. > > ... > > > > Mar 22 15:15:55 the-penguin kernel: NETDEV WATCHDOG: eth0: transmit timed out > > ... > > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if >00 [Normal decode]) > > People have recently been changing VIA PCI bridge settings > to try to fix the file corruption thing. There has been one > report that this change causes a 3c905C to go silly. > > This looks like the same problem to me. Could very well be. The problem is that your VIA chipset (or rather the chipset as used on at least some of the boards out there) will corrupt your data if this setting is not done. Greetings, Arjan van de Ven - 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: Linux 2.4.2-ac21
On Fri, 23 Mar 2001, Admin Mailing Lists wrote: > > >It was causing SMP boxes to crash mysteriously after > > >several hours or days. Quite a lot of them. Nobody > > >was able to explain why, so it was turned off. > > > > I know why it was turned off by default. The annoying this is that now > > the *only* way to activate the watchdog is via a boot command. It is > > not possible to compile a standard debugging kernel with this option > > turned on, you have to rely on every user setting the boot options for > > every kernel. If it is going to be off by default there should be a > > way to patch the kernel to make it on by default. > > > > i'm troubled by that fact that something the would be used to debug the > kernel, is something that actually causes crashes. doesn't that kind of > defeat the purpose..and introduce just another unstable element to the > problem/crash at hand? I had some unreproducable system crashes with NO watchdog and NO SMP enabled that do no longer occure since I compile my kernels without CONFIG_DEBUG_KERNEL. I don't know if it this is related, but there seems to be a problem in one of the "Kernel hacking" options that isn't related to watchdog or SMP. > -Tony cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig. - 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: Linux 2.4.2-ac21
> > > >It was causing SMP boxes to crash mysteriously after > >several hours or days. Quite a lot of them. Nobody > >was able to explain why, so it was turned off. > > I know why it was turned off by default. The annoying this is that now > the *only* way to activate the watchdog is via a boot command. It is > not possible to compile a standard debugging kernel with this option > turned on, you have to rely on every user setting the boot options for > every kernel. If it is going to be off by default there should be a > way to patch the kernel to make it on by default. > i'm troubled by that fact that something the would be used to debug the kernel, is something that actually causes crashes. doesn't that kind of defeat the purpose..and introduce just another unstable element to the problem/crash at hand? -Tony .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. Anthony J. Biacco Network Administrator/Engineer [EMAIL PROTECTED] Intergrafix Internet Services "Dream as if you'll live forever, live as if you'll die today" http://www.asteroid-b612.orghttp://www.intergrafix.net .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. - 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: Linux 2.4.2-ac21
On Thu, 22 Mar 2001, Alan Cox wrote:
> 2.4.2-ac21
> o atyfb mode updates for powermac (Olaf Hering)
60 Hz modes should be marked 60 Hz.
Add separator comment.
--- linux-2.4.2-ac21/drivers/video/macmodes.c.orig Fri Mar 23 08:17:54 2001
+++ linux-2.4.2-ac21/drivers/video/macmodes.c Fri Mar 23 08:37:27 2001
@@ -96,11 +96,11 @@
FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
}, {
/* 1152x768, 60 Hz, Titanium PowerBook */
- "mac21", 75, 1152, 768, 15386, 158, 26, 29, 3, 136, 6,
+ "mac21", 60, 1152, 768, 15386, 158, 26, 29, 3, 136, 6,
FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
}, {
/* 1600x1024, 60 Hz, Non-Interlaced (112.27 MHz dotclock) */
- "mac22", 75, 1600, 1024, 8908, 88, 104, 1, 10, 16, 1,
+ "mac22", 60, 1600, 1024, 8908, 88, 104, 1, 10, 16, 1,
FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
}
@@ -162,6 +162,7 @@
{ VMODE_1024_768_75V, &mac_modedb[9] },
{ VMODE_1024_768_70, &mac_modedb[8] },
{ VMODE_1024_768_60, &mac_modedb[7] },
+/* 1152x768 */
{ VMODE_1152_768_60, &mac_modedb[14] },
/* 1152x870 */
{ VMODE_1152_870_75, &mac_modedb[11] },
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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: 2.4.2-ac21
I also had my 3c905 behave this way with ac21. ac20 is ok. System uses an ABit kt7a board. Andrew Morton wrote: > Lawrence Walton wrote: > > > > Hello all > > 2.4.2-ac21 seems to have a couple problems. > > ... > > > > Mar 22 15:15:55 the-penguin kernel: NETDEV WATCHDOG: eth0: transmit timed out > > ... > > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if >00 [Normal decode]) > > People have recently been changing VIA PCI bridge settings > to try to fix the file corruption thing. There has been one > report that this change causes a 3c905C to go silly. > > This looks like the same problem to me. > > Arjan? > > - > - > 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/ - 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: Linux 2.4.2-ac21
On Fri, 23 Mar 2001 01:50:49 +, "Andrew Morton" <[EMAIL PROTECTED]> wrote: >Keith Owens wrote: >> >> Am I the only person who is annoyed that nmi watchdog is now off by >> default and the only way to activate it is by a boot parameter? You >> cannot even patch the kernel to build a version that has nmi watchdog >> on because the startup code runs out of the __setup routine, no boot >> parameter, no watchdog. > >It was causing SMP boxes to crash mysteriously after >several hours or days. Quite a lot of them. Nobody >was able to explain why, so it was turned off. I know why it was turned off by default. The annoying this is that now the *only* way to activate the watchdog is via a boot command. It is not possible to compile a standard debugging kernel with this option turned on, you have to rely on every user setting the boot options for every kernel. If it is going to be off by default there should be a way to patch the kernel to make it on by default. - 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: Linux 2.4.2-ac21
Keith Owens wrote: > > Am I the only person who is annoyed that nmi watchdog is now off by > default and the only way to activate it is by a boot parameter? You > cannot even patch the kernel to build a version that has nmi watchdog > on because the startup code runs out of the __setup routine, no boot > parameter, no watchdog. It was causing SMP boxes to crash mysteriously after several hours or days. Quite a lot of them. Nobody was able to explain why, so it was turned off. - 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: Linux 2.4.2-ac21
On Fri, 23 Mar 2001 00:02:54 +0100, Frank de Lange <[EMAIL PROTECTED]> wrote: >Linux 2.4.2-ac21 does not like my box, or the other way around: > >loading the agpgart module (MGA G400 AGP) -> system hangs >loading the SCSI module (53c875) -> system hangs > >In both cases, the magic SysRq sequence does not work, but it is still possible >to ping the box from the outside. Connecting to it (ssh) does not work, >however. I backed out both the SCSI driver patches as well as the agpgart >patches, but this did not fix the symptoms. Looks more like a module-loading >related issue, but I have not found it yet. > >All this on an SMP (Abit BP6) box by the way... Activate the nmi watchdog with nmi_watchdog=1 in the boot parameters[*]. That will trip after 5 seconds and point to where it is hanging. If the nmi watchdog alone does not give enough data, add the kdb patch (with nmi watchdog on) and start debugging. http://oss.sgi.com/projects/kdb/download/ix86/, the -ac20 patch should fit -ac21 as well. Am I the only person who is annoyed that nmi watchdog is now off by default and the only way to activate it is by a boot parameter? You cannot even patch the kernel to build a version that has nmi watchdog on because the startup code runs out of the __setup routine, no boot parameter, no watchdog. - 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: 2.4.2-ac21
Lawrence Walton wrote: > > Hello all > 2.4.2-ac21 seems to have a couple problems. > ... > > Mar 22 15:15:55 the-penguin kernel: NETDEV WATCHDOG: eth0: transmit timed out > ... > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00 >[Normal decode]) People have recently been changing VIA PCI bridge settings to try to fix the file corruption thing. There has been one report that this change causes a 3c905C to go silly. This looks like the same problem to me. Arjan? - - 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: 2.4.2-ac21
> Hello all > 2.4.2-ac21 seems to have a couple problems. First the fs was acting very > strangely, while compiling; the compiler complained about being unable > to find files and directory's that existed. I was able to cd to those > directory's and see the files with ls, (I was recompiling ac20 at the > time.). Second was every half a minute or so, I would get this message. Ok the further VIA bitfiddling with the pci config is causing the problems it seems. I'll back that out soon - 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: Linux 2.4.2-ac21
On Thu, 22 Mar 2001, Alan Cox wrote: OK. > > On Thu, 22 Mar 2001, Alan Cox wrote: > > > > Does not build for PPro/P-II. i586 is OK. > > You need to avoid enabling 64G support. The PAE stuff (as Linus said > with > 2.4.3pre6) is currently broken. Once Linus and co fix it I'll merge the > fixed > one --- Sergey Kubushin Sr. Unix Administrator CyberBills, Inc.Phone: 702-567-8857 874 American Pacific Dr,Fax:702-567-8808 Henderson, NV, 89014 - 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/
2.4.2-ac21
Hello all 2.4.2-ac21 seems to have a couple problems. First the fs was acting very strangely, while compiling; the compiler complained about being unable to find files and directory's that existed. I was able to cd to those directory's and see the files with ls, (I was recompiling ac20 at the time.). Second was every half a minute or so, I would get this message. Mar 22 15:15:55 the-penguin kernel: NETDEV WATCHDOG: eth0: transmit timed out Mar 22 15:15:55 the-penguin kernel: eth0: transmit timed out, tx_status 00 status e000. Mar 22 15:15:55 the-penguin kernel: diagnostics: net 0cd8 media 8880 dma 00a0. Mar 22 15:15:55 the-penguin kernel: Flags; bus-master 1, dirty 16(0) current 32(0) Mar 22 15:15:55 the-penguin kernel: Transmit list 17a7e200 vs. d7a7e200. Mar 22 15:15:55 the-penguin kernel: 0: @d7a7e200 length 806e status 006e Mar 22 15:15:55 the-penguin kernel: 1: @d7a7e240 length 806e status 006e Mar 22 15:15:55 the-penguin kernel: 2: @d7a7e280 length 806e status 006e Mar 22 15:15:55 the-penguin kernel: 3: @d7a7e2c0 length 806e status 006e Mar 22 15:15:55 the-penguin kernel: 4: @d7a7e300 length 806e status 006e Mar 22 15:15:55 the-penguin kernel: 5: @d7a7e340 length 806e status 006e Mar 22 15:15:55 the-penguin kernel: 6: @d7a7e380 length 806e status 006e Mar 22 15:15:55 the-penguin kernel: 7: @d7a7e3c0 length 806e status 006e Mar 22 15:15:55 the-penguin kernel: 8: @d7a7e400 length 806e status 006e Mar 22 15:15:55 the-penguin kernel: 9: @d7a7e440 length 806e status 006e Mar 22 15:15:55 the-penguin kernel: 10: @d7a7e480 length 806e status 006e Mar 22 15:15:55 the-penguin kernel: 11: @d7a7e4c0 length 806e status 006e Mar 22 15:15:55 the-penguin kernel: 12: @d7a7e500 length 806e status 006e Mar 22 15:15:55 the-penguin kernel: 13: @d7a7e540 length 806e status 006e Mar 22 15:15:55 the-penguin kernel: 14: @d7a7e580 length 806e status 806e Mar 22 15:15:55 the-penguin kernel: 15: @d7a7e5c0 length 8063 status 8063 Mar 22 15:15:55 the-penguin kernel: eth0: Resetting the Tx ring pointer. I rebooted back into 2.4.2-ac20 and everything was fine. No opps, or other kernel messages out of the ordinary. I was pretty afraid of booting back into ac21. Linux the-penguin 2.4.2-ac20 #2 Thu Mar 22 16:04:42 PST 2001 i686 unknown Gnu C 2.95.3 Gnu make 3.79.1 binutils 2.11.90.0.1 util-linux util-linux Note: /usr/bin/fdformat is obsolete and is no longer available. util-linux Please use /usr/bin/superformat instead (make sure you have the util-linux fdutils package installed first). Also, there had been some util-linux major changes from version 4.x. Please refer to the documentation. util-linux modutils 2.4.2 e2fsprogs 1.19 PPP2.4.0 Linux C Library2.2.2 Dynamic linker (ldd) 2.2.2 Procps 2.0.7 Net-tools 1.59 Console-tools 0.2.3 Sh-utils 2.0.11 Modules Loaded nls_cp437 nls_iso8859-1 smbfs mga ipx agpgart emu10k1 soundcore 3c59x # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_USE_3DNOW=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_
Re: Linux 2.4.2-ac21
On Thu, 22 Mar 2001, Alan Cox wrote: Does not build for PPro/P-II. i586 is OK. === Cut === ld -m elf_i386 -T /tmp/build-kernel/usr/src/linux-2.4.2ac21/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ drivers/block/block.o drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/char/drm/drm.o drivers/net/fc/fc.o drivers/net/appletalk/appletalk.o drivers/net/tokenring/tr.o drivers/net/wan/wan.o drivers/atm/atm.o drivers/cdrom/driver.o drivers/pci/driver.o drivers/video/video.o drivers/net/hamradio/hamradio.o drivers/md/mddev.o \ net/network.o \ /tmp/build-kernel/usr/src/linux-2.4.2ac21/arch/i386/lib/lib.a /tmp/build-kernel/usr/src/linux-2.4.2ac21/lib/lib.a /tmp/build-kernel/usr/src/linux-2.4.2ac21/arch/i386/lib/lib.a \ --end-group \ -o vmlinux arch/i386/mm/mm.o: In function `do_check_pgt_cache': arch/i386/mm/mm.o(.text+0x201): undefined reference to `get_pmd_slow' mm/mm.o: In function `clear_page_tables': mm/mm.o(.text+0x150): undefined reference to `pmd_free' mm/mm.o: In function `__pmd_alloc': mm/mm.o(.text+0x1fe4): undefined reference to `get_pmd_slow' mm/mm.o(.text+0x207a): undefined reference to `pmd_free' mm/mm.o(.text+0x208a): undefined reference to `pgd_populate' make: *** [vmlinux] Error 1 === Cut === Here is the config (processor part). Full config is available on request. Everything's modular except romfs and initrd. === Cut === # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_TOSHIBA=m CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # CONFIG_NOHIGHMEM is not set # CONFIG_HIGHMEM4G is not set CONFIG_HIGHMEM64G=y CONFIG_HIGHMEM=y CONFIG_X86_PAE=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y === Cut === --- Sergey Kubushin Sr. Unix Administrator CyberBills, Inc.Phone: 702-567-8857 874 American Pacific Dr,Fax:702-567-8808 Henderson, NV, 89014 - 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: Linux 2.4.2-ac21
> On Thu, 22 Mar 2001, Alan Cox wrote: > > Does not build for PPro/P-II. i586 is OK. You need to avoid enabling 64G support. The PAE stuff (as Linus said with 2.4.3pre6) is currently broken. Once Linus and co fix it I'll merge the fixed one Alan - 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: Linux 2.4.2-ac21
Oops...
Linux 2.4.2-ac21 does not like my box, or the other way around:
loading the agpgart module (MGA G400 AGP) -> system hangs
loading the SCSI module (53c875) -> system hangs
In both cases, the magic SysRq sequence does not work, but it is still possible
to ping the box from the outside. Connecting to it (ssh) does not work,
however. I backed out both the SCSI driver patches as well as the agpgart
patches, but this did not fix the symptoms. Looks more like a module-loading
related issue, but I have not found it yet.
All this on an SMP (Abit BP6) box by the way...
The changes which introduced these symptoms have occured somewhere between -ac7
and -ac21, since -ac7 DID run on the same hardware.
Cheers//Frank
--
W ___
## o o\/ Frank de Lange \
}# \| / \
##---# _/ \
\ +31-320-252965/
\[EMAIL PROTECTED]/
-
[ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est." ]
-
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: 2.4.2-ac21: aviplay slowdown
> I compiled 2.4.3-pre6 and 2.4.2-ac21 and noticed, that aviplay works > much worse than before. Avifile benchmark told me: > > Average video output speed: 20.566223 Mb/s > > On 2.2.18 and earlier 2.4.2-ac* it gives 50-55Mb/s. > > mtrr is enabled: > > [jp@darkwood jp]$ cat /proc/mtrr > reg00: base=0xe800 (3712MB), size= 32MB: write-combining, count=2 > > My hardware: K6-2 500, VIA MVP3, Voodoo3 Are the numbers comparable if you have mtrr disabled on both the old and new kernel tree ? - 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/
2.4.2-ac21: aviplay slowdown
I compiled 2.4.3-pre6 and 2.4.2-ac21 and noticed, that aviplay works much worse than before. Avifile benchmark told me: Average video output speed: 20.566223 Mb/s On 2.2.18 and earlier 2.4.2-ac* it gives 50-55Mb/s. mtrr is enabled: [jp@darkwood jp]$ cat /proc/mtrr reg00: base=0xe800 (3712MB), size= 32MB: write-combining, count=2 My hardware: K6-2 500, VIA MVP3, Voodoo3 - 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: Weird bttv errors and video hangs with 2.4.2-ac21
Alan Cox wrote: > > > With -ac21 I'm getting occasional long delays in video output with xawtv > > or the picture totally freezes until I click with the mouse in the xawtv > > window. dmesg shows: > > You have a VIA chipset ? Yes. Via KT133. lspci output under -ac20: 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305 (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- > bttv0: resetting chip > > bttv0: PLL: 28636363 => 35468950 ... ok > > bttv0: irq: OCERR risc_count=0fb54810 > > > > All of this did not happen with -ac20 under the exact same circumstances, > > so -ac21 does something which the bttv driver (0.7.57) doesn't quite like. > > The only candidate I can think of is the pci quirk stuff added for the VIA > chipsets That is probably the problem then. If you have a patch, want me to try something or need more info, just let me know. Regards, Udo. - 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: Weird bttv errors and video hangs with 2.4.2-ac21
> With -ac21 I'm getting occasional long delays in video output with xawtv > or the picture totally freezes until I click with the mouse in the xawtv > window. dmesg shows: You have a VIA chipset ? > bttv0: resetting chip > bttv0: PLL: 28636363 => 35468950 ... ok > bttv0: irq: OCERR risc_count=0fb54810 > > All of this did not happen with -ac20 under the exact same circumstances, > so -ac21 does something which the bttv driver (0.7.57) doesn't quite like. The only candidate I can think of is the pci quirk stuff added for the VIA chipsets - 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: Linux 2.4.2-ac21
Credit where credit's due...
On Thu, 22 Mar 2001, Alan Cox wrote:
> 2.4.2-ac21
> o Update NEC DDB5476 eval board support (Geert Uytterhoeven)
Actually this port was done by Jun Sun (based on the DDB5074 port).
> o Update NEC DDB5074 eval board support (Geert Uytterhoeven)
And here Ralf just used indent on the existing sources :-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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/
Weird bttv errors and video hangs with 2.4.2-ac21
Hi, With -ac21 I'm getting occasional long delays in video output with xawtv or the picture totally freezes until I click with the mouse in the xawtv window. dmesg shows: bttv0: PLL: 28636363 => 35468950 ... ok bttv0: irq: OCERR risc_count=0fb54810 bttv0: irq: OCERR risc_count=0fb54810 bttv0: irq: OCERR risc_count=0fb54810 bttv0: irq: SCERR risc_count=0fb54810 bttv0: irq: SCERR risc_count=0fb54810 bttv0: aiee: error loops bttv0: resetting chip bttv0: PLL: 28636363 => 35468950 ... ok bttv0: irq: OCERR risc_count=0fb54810 bttv0: irq: OCERR risc_count=0fb54820 bttv0: irq: OCERR risc_count=0fb54810 bttv0: irq: OCERR risc_count=0fb54810 bttv0: irq: SCERR risc_count=0fb54810 bttv0: aiee: error loops bttv0: irq: SCERR risc_count=0c898014 bttv0: aiee: error loops bttv0: resetting chip bttv0: PLL: 28636363 => 35468950 ... ok bttv0: irq: OCERR risc_count=0fb54810 All of this did not happen with -ac20 under the exact same circumstances, so -ac21 does something which the bttv driver (0.7.57) doesn't quite like. Regards, Udo. - 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/
Linux 2.4.2-ac21
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org (Note that the cmsfs port to 2.4 is a work in progress) 2.4.2-ac21 o Merge with Linus 2.4.3pre6 o Close last known reiserfs tail bug (Chris Mason) o Fix link order bug with iso8859_8 and cp1255(Dan Aloni) o Generate generic CPU namings for 386/486(Cesar Eduardo Barros) o First set of ISDN fixes from Stanford code (Kai Germaschewski) analyser o Allow up to 16 parallel ports by default(Tim Waugh) o Use long delays on low speed usb hub ports (Pete Zaitcev) o Update credits for assorted Australians (Stephen Rothwell) o Fix ali_restore_regs thinko (Pavel Roskin) o Fix whiteheat usb driver bugs (Greg Kroah-Hartman) o Fix kfree in belkin_sa (Greg Kroah-Hartman) o Fix omninet copy*user bug (Greg Kroah-Hartman) o Fix modular atyfb (Geert Uytterhoeven) o Update joystick and input drivers (Vojtech Pavlik) o Relax checksum enforcement on ISAPnP CSN(Gunther Mayer) o Resync ids/comments with ISDN cvs (Kai Germaschewski) o Update Harald Hoyer Credits entry (Harald Hoyer) o Fix off by 2* mtrr handling bug (David Wragg) o Fix irda hang on boot (Dag Brattli) o FB device init updates (Geert Uytterhoeven) o Add it8712 misp eval board support (P. Popov) o Update NEC DDB5476 eval board support (Geert Uytterhoeven) o Update NEC DDB5074 eval board support (Geert Uytterhoeven) o Add Karsten Merker and Michael Engel to credits (Ralf Baechle) o Update Baget port (Vladimir Roganov, Gleb Raiko) o Add LVM ioctls to sparc64 ioctl32 convertor (Patrick Caulfield) o Powerpc updates for openfirmware mm, python etc (Cort Dougan) o Add the casio qv digitalcamera to the usb unusual devices list(Harald Schreiber) o atyfb mode updates for powermac (Olaf Hering) o Fix khubd locking (Pete Zaitcev) o More on the great aic7xxx libdb game(Nathan Dabney) o Further console handling updates(Andrew Morton) o Fix i2o build problem when half modular (Michael Mueller) o Fix off by one in prink check (Mitchell Blank Jr) o Fix do_swap_page hang (Linus Torvalds) 2.4.2-ac20 o Add support for the GoHubs GO-COM232(Greg Kroah-Hartman) o Remove cobalt remnants (Ralf Baechle) o First block of mm documentation (Rik van Riel) o Replace ancient Zoran driver with new one (Serguei Miridonov, Wolfgang Scherr, Rainer Johanni, Dave Perks) o Fix Alpha build (Jeff Garzik) o Fix K7 mtrr breakage(Dave Jones) o Fix pcnet32 touching resources before enable(Dave Jones) o Merge with Linus 2.4.3pre4 2.4.2-ac19 o Typo fixes (David Weinehall) o Merge first block of OHCI non x86 support (Greg Kroah-Hartman) o Add Edgeport USB serial support (David Iacovelli, Greg Kroah-Hartman) o Fix doorlock on scsi removables (Alex Davies) o Fix hang when usb storage thread died (me) o Change watchdog disable setup (Ingo Molnar) o Fix bluetooth close and error bugs (Narayan Mohanram) o mpt now has an assigned minor (me) | Remember to fix your /dev/mptctl if using MPT o Clean up 3270 ifdefs/printk a little(me) o Fix NBD deadlocks and update it (Steve Whitehouse) o Fix sercon printk divide by zero bug(Roger Gammans) o Remove cosine support from MIPS tree(Ralf Baechle) o bust_spinlocks for Alpha(Jeff Garzik) o Hopefully fix the buslogic corruptions (me) | This is a 'test if they went away' release not a 'its fixed' one. o Some mips makefile fixes(Ralf Baechle) | except mips/kernel/Makefile (I got .rej Ralf) o ARC firmware interface fixes(Harald Koerfgen) o DECstation console drivers
