Re: SATALink Sil3112 and Linux woes
On Mon, Aug 08, 2005 at 11:45:22PM +, Shaun Jackman wrote: > I have a Silicon Image SATALink Sil3112 PCI card connected to two 200 > GB SATA Seagate drives. I'm running into many problems with this > setup. Is this card well supported under Linux? If it's a black sheep, > could someone please recommend a PCI SATA card that works well? What's the model number? You can the source for it, to see if it's blacklisted. -- Tom Vier <[EMAIL PROTECTED]> DSA Key ID 0x15741ECE - 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: SATALink Sil3112 and Linux woes
On Mon, Aug 08, 2005 at 11:45:22PM +, Shaun Jackman wrote: I have a Silicon Image SATALink Sil3112 PCI card connected to two 200 GB SATA Seagate drives. I'm running into many problems with this setup. Is this card well supported under Linux? If it's a black sheep, could someone please recommend a PCI SATA card that works well? What's the model number? You can the source for it, to see if it's blacklisted. -- Tom Vier [EMAIL PROTECTED] DSA Key ID 0x15741ECE - 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: [discuss] Re: NUMA support for dual core Opteron
On Thu, Jul 14, 2005 at 09:09:29PM +0200, Andi Kleen wrote: > However with 90+W CPUs I would strongly recommend having support > for PowerNow! and the old style PST table doesn't support > dual core or SMP, so you need ACPI for that anyways. Do opterons even support powernow? The proc or sysfs control file never shows up on mine and the cpu flags don't list it. Then again, neither does my athlon64. They're all in 32bit mode. -- Tom Vier <[EMAIL PROTECTED]> DSA Key ID 0x15741ECE - 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: [discuss] Re: NUMA support for dual core Opteron
On Thu, Jul 14, 2005 at 09:09:29PM +0200, Andi Kleen wrote: However with 90+W CPUs I would strongly recommend having support for PowerNow! and the old style PST table doesn't support dual core or SMP, so you need ACPI for that anyways. Do opterons even support powernow? The proc or sysfs control file never shows up on mine and the cpu flags don't list it. Then again, neither does my athlon64. They're all in 32bit mode. -- Tom Vier [EMAIL PROTECTED] DSA Key ID 0x15741ECE - 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: Distinguish real vs. virtual CPUs?
On Tue, Mar 22, 2005 at 04:26:47PM -0500, Bill Davidsen wrote: > It's not clear if that's bizarre practice on AMD system boards or if > it's mis-reported. Of course Tom may be running a NUMA setup, in which > case I won't guess what's expected to be displayed. I've added him to > the CC list, in hopes of comment. It's numa (two cores, one ram ctrlr per core, one core per package). I'm running an x86 kernel, btw, not 64bit. I have CONFIG_X86_HT set, and it looks like it gets the pkg id from the apic (there's only one in multicore packages?), but i might be reading it wrong. My dmseg overflows before syslog starts, so all i could gather is: Mar 23 12:04:25 zero kernel: Brought up 2 CPUs Mar 23 12:04:25 zero kernel: CPU0 attaching sched-domain: Mar 23 12:04:25 zero kernel: domain 0: span 3 Mar 23 12:04:25 zero kernel: groups: 1 2 Mar 23 12:04:25 zero kernel: CPU1 attaching sched-domain: Mar 23 12:04:25 zero kernel: domain 0: span 3 Mar 23 12:04:25 zero kernel: groups: 2 1 I don't know how the scheduling domains work, and i'm too busy to look it up right now. -- Tom Vier <[EMAIL PROTECTED]> DSA Key ID 0x15741ECE - 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: Squashfs without ./..
On Wed, Mar 23, 2005 at 06:31:24PM +0100, Jan Engelhardt wrote: > Which scripts use that? As stated, these two directory entries exist when you > stat() them, they just do not show up in readdir(), and I bet few programs > care for "." and ".." when doing their readdir. There's probably a number of apps that skip the first two dirents, instead of checking for the dot dirs. -- Tom Vier <[EMAIL PROTECTED]> DSA Key ID 0x15741ECE - 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: Squashfs without ./..
On Wed, Mar 23, 2005 at 06:31:24PM +0100, Jan Engelhardt wrote: Which scripts use that? As stated, these two directory entries exist when you stat() them, they just do not show up in readdir(), and I bet few programs care for . and .. when doing their readdir. There's probably a number of apps that skip the first two dirents, instead of checking for the dot dirs. -- Tom Vier [EMAIL PROTECTED] DSA Key ID 0x15741ECE - 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: Distinguish real vs. virtual CPUs?
On Tue, Mar 22, 2005 at 04:26:47PM -0500, Bill Davidsen wrote: It's not clear if that's bizarre practice on AMD system boards or if it's mis-reported. Of course Tom may be running a NUMA setup, in which case I won't guess what's expected to be displayed. I've added him to the CC list, in hopes of comment. It's numa (two cores, one ram ctrlr per core, one core per package). I'm running an x86 kernel, btw, not 64bit. I have CONFIG_X86_HT set, and it looks like it gets the pkg id from the apic (there's only one in multicore packages?), but i might be reading it wrong. My dmseg overflows before syslog starts, so all i could gather is: Mar 23 12:04:25 zero kernel: Brought up 2 CPUs Mar 23 12:04:25 zero kernel: CPU0 attaching sched-domain: Mar 23 12:04:25 zero kernel: domain 0: span 3 Mar 23 12:04:25 zero kernel: groups: 1 2 Mar 23 12:04:25 zero kernel: CPU1 attaching sched-domain: Mar 23 12:04:25 zero kernel: domain 0: span 3 Mar 23 12:04:25 zero kernel: groups: 2 1 I don't know how the scheduling domains work, and i'm too busy to look it up right now. -- Tom Vier [EMAIL PROTECTED] DSA Key ID 0x15741ECE - 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/
not for amd Re: Distinguish real vs. virtual CPUs?
On Mon, Mar 21, 2005 at 08:56:03PM -0500, Dave Jones wrote: > Compare the 'physical id' fields of /proc/cpuinfo, and count > how many unique values you get. It doesn't work for opteron, at least. These are in two sockets, but the phys id is the same. processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 244 stepping: 8 cpu MHz : 1792.493 cache size : 1024 KB physical id : 0 siblings: 1 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 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 pni syscall nx mmxext lm 3dnowext 3dnow bogomips: 3514.36 processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 244 stepping: 10 cpu MHz : 1792.493 cache size : 1024 KB physical id : 0 siblings: 1 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 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 pni syscall nx mmxext lm 3dnowext 3dnow bogomips: 3571.71 -- Tom Vier <[EMAIL PROTECTED]> DSA Key ID 0x15741ECE - 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/
not for amd Re: Distinguish real vs. virtual CPUs?
On Mon, Mar 21, 2005 at 08:56:03PM -0500, Dave Jones wrote: Compare the 'physical id' fields of /proc/cpuinfo, and count how many unique values you get. It doesn't work for opteron, at least. These are in two sockets, but the phys id is the same. processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 244 stepping: 8 cpu MHz : 1792.493 cache size : 1024 KB physical id : 0 siblings: 1 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 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 pni syscall nx mmxext lm 3dnowext 3dnow bogomips: 3514.36 processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 244 stepping: 10 cpu MHz : 1792.493 cache size : 1024 KB physical id : 0 siblings: 1 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 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 pni syscall nx mmxext lm 3dnowext 3dnow bogomips: 3571.71 -- Tom Vier [EMAIL PROTECTED] DSA Key ID 0x15741ECE - 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: [Fwd: United States Patent: 6,862,609]
On Thu, Mar 03, 2005 at 01:21:08AM -0500, Gene Heskett wrote: > It brings up another sore point with me. I'm of the opinion that both > copyright, and patent, should be granted to the author/inventor on a > non-transferable basis. He could then sell rights to use it for a > set period of time, at the end of which it is still his. The You can already license patents, it's done all the time. There's no need for the government to restrict the rights of patents holders to sell all their rights, if they choose to. -- Tom Vier <[EMAIL PROTECTED]> DSA Key ID 0x15741ECE - 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: [Fwd: United States Patent: 6,862,609]
On Thu, Mar 03, 2005 at 01:21:08AM -0500, Gene Heskett wrote: It brings up another sore point with me. I'm of the opinion that both copyright, and patent, should be granted to the author/inventor on a non-transferable basis. He could then sell rights to use it for a set period of time, at the end of which it is still his. The You can already license patents, it's done all the time. There's no need for the government to restrict the rights of patents holders to sell all their rights, if they choose to. -- Tom Vier [EMAIL PROTECTED] DSA Key ID 0x15741ECE - 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.5-ac17 swapoff machine check
i had about 50megs of swap "used" when i ran swapoff -a. that trigger two machine checks, but the box stayed up and seemed none the worse. here's the syslog. Jun 24 12:55:54 zero kernel: CIA machine check: vector=0x670 pc=0xfc8470b8 code=0x98 Jun 24 12:55:54 zero kernel: machine check type: processor detected hard error Jun 24 12:55:54 zero kernel: pc = [__get_swap_page+120/832] ra = [try_to_swap_out+656/896] ps = Jun 24 12:55:54 zero kernel: v0 = 0001 t0 = t1 = 000149177150 Jun 24 12:55:54 zero kernel: t2 = fcace084 t3 = fc0149c77c58 t4 = 0001 Jun 24 12:55:54 zero kernel: t5 = t6 = 041d17d1 t7 = fc001ffe4000 Jun 24 12:55:54 zero kernel: a0 = fc001ffe7ce0 a1 = 0001 a2 = fc8428b0 Jun 24 12:55:54 zero kernel: a3 = fc0016563ff8 a4 = fccf1460 a5 = Jun 24 12:55:54 zero kernel: t8 = t9 = fcb00b08 t10= fcace084 Jun 24 12:55:54 zero kernel: t11= 10745f44 pv = fc847040 at = fcacf208 Jun 24 12:55:54 zero kernel: gp = fcac53a0 sp = fc001ffe7ca0 Jun 24 12:55:54 zero kernel: CIA machine check: vector=0x670 pc=0xfc847330 code=0x98 Jun 24 12:55:54 zero kernel: machine check type: processor detected hard error Jun 24 12:55:54 zero kernel: pc = [__get_swap_page+752/832] ra = [try_to_swap_out+656/896] ps = Jun 24 12:55:54 zero kernel: v0 = 0001 t0 = t1 = 000149177150 Jun 24 12:55:54 zero kernel: t2 = fcace084 t3 = fc0149c77c58 t4 = 0001 Jun 24 12:55:54 zero kernel: t5 = t6 = t7 = fc001ffe4000 Jun 24 12:55:54 zero kernel: a0 = fc001ffe7ce0 a1 = 0001 a2 = fc8428b0 Jun 24 12:55:54 zero kernel: a3 = fc0016563ff8 a4 = fccf1460 a5 = Jun 24 12:55:54 zero kernel: t8 = t9 = fcb00b08 t10= fcace084 Jun 24 12:55:54 zero kernel: t11= 10745f44 pv = fc847040 at = fcacf208 Jun 24 12:55:54 zero kernel: gp = fcac53a0 sp = fc001ffe7ca0 -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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.5-ac17 swapoff machine check
i had about 50megs of swap used when i ran swapoff -a. that trigger two machine checks, but the box stayed up and seemed none the worse. here's the syslog. Jun 24 12:55:54 zero kernel: CIA machine check: vector=0x670 pc=0xfc8470b8 code=0x98 Jun 24 12:55:54 zero kernel: machine check type: processor detected hard error Jun 24 12:55:54 zero kernel: pc = [__get_swap_page+120/832] ra = [try_to_swap_out+656/896] ps = Jun 24 12:55:54 zero kernel: v0 = 0001 t0 = t1 = 000149177150 Jun 24 12:55:54 zero kernel: t2 = fcace084 t3 = fc0149c77c58 t4 = 0001 Jun 24 12:55:54 zero kernel: t5 = t6 = 041d17d1 t7 = fc001ffe4000 Jun 24 12:55:54 zero kernel: a0 = fc001ffe7ce0 a1 = 0001 a2 = fc8428b0 Jun 24 12:55:54 zero kernel: a3 = fc0016563ff8 a4 = fccf1460 a5 = Jun 24 12:55:54 zero kernel: t8 = t9 = fcb00b08 t10= fcace084 Jun 24 12:55:54 zero kernel: t11= 10745f44 pv = fc847040 at = fcacf208 Jun 24 12:55:54 zero kernel: gp = fcac53a0 sp = fc001ffe7ca0 Jun 24 12:55:54 zero kernel: CIA machine check: vector=0x670 pc=0xfc847330 code=0x98 Jun 24 12:55:54 zero kernel: machine check type: processor detected hard error Jun 24 12:55:54 zero kernel: pc = [__get_swap_page+752/832] ra = [try_to_swap_out+656/896] ps = Jun 24 12:55:54 zero kernel: v0 = 0001 t0 = t1 = 000149177150 Jun 24 12:55:54 zero kernel: t2 = fcace084 t3 = fc0149c77c58 t4 = 0001 Jun 24 12:55:54 zero kernel: t5 = t6 = t7 = fc001ffe4000 Jun 24 12:55:54 zero kernel: a0 = fc001ffe7ce0 a1 = 0001 a2 = fc8428b0 Jun 24 12:55:54 zero kernel: a3 = fc0016563ff8 a4 = fccf1460 a5 = Jun 24 12:55:54 zero kernel: t8 = t9 = fcb00b08 t10= fcace084 Jun 24 12:55:54 zero kernel: t11= 10745f44 pv = fc847040 at = fcacf208 Jun 24 12:55:54 zero kernel: gp = fcac53a0 sp = fc001ffe7ca0 -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - 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.5-ac17
On Fri, Jun 22, 2001 at 09:06:42AM +0200, Mike Galbraith wrote: > It's not actually swapping unless you see IO (si/so). It's allocating > swap space, but won't send pages out to disk unless there's demand. One if it's pre-allocation, why does it show up as "used"? "reserved" would be a better fit. > benefit of this early allocation is that idle pages will be identified > prior to demand, and will be moved out of the way sooner. Watch as how long can swap allocation possibly take? certainly no where near as long as a write to disk takes. my box has a half gig of ram, pre-allocation is a waste of cpu. i never hit swap. > memory demand rises, and you should see these pages migrating to disk > and staying there.. buys you more working space. -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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.5-ac17
On Fri, Jun 22, 2001 at 09:06:42AM +0200, Mike Galbraith wrote: It's not actually swapping unless you see IO (si/so). It's allocating swap space, but won't send pages out to disk unless there's demand. One if it's pre-allocation, why does it show up as used? reserved would be a better fit. benefit of this early allocation is that idle pages will be identified prior to demand, and will be moved out of the way sooner. Watch as how long can swap allocation possibly take? certainly no where near as long as a write to disk takes. my box has a half gig of ram, pre-allocation is a waste of cpu. i never hit swap. memory demand rises, and you should see these pages migrating to disk and staying there.. buys you more working space. -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - 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.5-ac17
i having some strange vm behavour with -ac17 that didn't happen with -ac14 (i haven't tried 15 or 16). it starts swapping even when i have hundreds of megs of free ram. another strange thing is that the first time i tried to boot ac17, it machine checked in the palcode. i hit reset and it booted correctly. vmstat: procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 1 0 0 2864 408488 2488 67080 0 0 21628 1052 470 83 4 13 buffermem: 2 10 60 freepages: 255 510 765 pagecache: 2 15 75 pagetable_cache: 25 50 also, overcommit_memory is 1 -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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.5-ac17
anyone working on a bootflag.c for alpha? init/main.o: In function `init': main.c(.text+0x148): undefined reference to `linux_booted_ok' main.c(.text+0x14c): undefined reference to `linux_booted_ok' make: *** [vmlinux] Error 1 -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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.5-ac17
anyone working on a bootflag.c for alpha? init/main.o: In function `init': main.c(.text+0x148): undefined reference to `linux_booted_ok' main.c(.text+0x14c): undefined reference to `linux_booted_ok' make: *** [vmlinux] Error 1 -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - 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.5-ac17
i having some strange vm behavour with -ac17 that didn't happen with -ac14 (i haven't tried 15 or 16). it starts swapping even when i have hundreds of megs of free ram. another strange thing is that the first time i tried to boot ac17, it machine checked in the palcode. i hit reset and it booted correctly. vmstat: procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 1 0 0 2864 408488 2488 67080 0 0 21628 1052 470 83 4 13 buffermem: 2 10 60 freepages: 255 510 765 pagecache: 2 15 75 pagetable_cache: 25 50 also, overcommit_memory is 1 -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - 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.5-ac15
mach_kbd_rate was changed to kbd_rate, but not defined. vt.c: In function `vt_ioctl': vt.c:504: `kbd_rate' undeclared (first use in this function) vt.c:504: (Each undeclared identifier is reported only once vt.c:504: for each function it appears in.) vt.c:510: `kbd_rate' used prior to declaration vt.c:510: warning: implicit declaration of function `kbd_rate' make[3]: *** [vt.o] Error 1 make[2]: *** [first_rule] Error 2 make[1]: *** [_subdir_char] Error 2 make: *** [_dir_drivers] Error 2 -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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.5-ac15
mach_kbd_rate was changed to kbd_rate, but not defined. vt.c: In function `vt_ioctl': vt.c:504: `kbd_rate' undeclared (first use in this function) vt.c:504: (Each undeclared identifier is reported only once vt.c:504: for each function it appears in.) vt.c:510: `kbd_rate' used prior to declaration vt.c:510: warning: implicit declaration of function `kbd_rate' make[3]: *** [vt.o] Error 1 make[2]: *** [first_rule] Error 2 make[1]: *** [_subdir_char] Error 2 make: *** [_dir_drivers] Error 2 -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - 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: obsolete code must die
i have a corvus 20meg drive and a xebec 10meg that both still spin up. those are from mid to late 80s. i have seagate hawks from '94 that still work, but quantums from the same period are all dead. the difference is that newer drives have much tighter tolerances and are much more sensitive to dust. it varies from drive to drive, of course. On Thu, Jun 14, 2001 at 11:41:15AM +1000, David Luyer wrote: > Even old Eagle drives from 1988 still spin up... given you have to flick the > starter switch to spin them up half a dozen times, but they still work... > seems they don't make disk drives like they used to. -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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: obsolete code must die
i have a corvus 20meg drive and a xebec 10meg that both still spin up. those are from mid to late 80s. i have seagate hawks from '94 that still work, but quantums from the same period are all dead. the difference is that newer drives have much tighter tolerances and are much more sensitive to dust. it varies from drive to drive, of course. On Thu, Jun 14, 2001 at 11:41:15AM +1000, David Luyer wrote: Even old Eagle drives from 1988 still spin up... given you have to flick the starter switch to spin them up half a dozen times, but they still work... seems they don't make disk drives like they used to. -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - 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.2 <-> 2.4.5-ac5 tcp too slow
i tracked it down to the 8139 driver in 2.4. On Mon, Jun 04, 2001 at 06:28:34PM -0400, Tom Vier wrote: > has the same effect) and an alpha pws 500 running 2.4.5-ac5. tcp starts slow > and get slower. it's not a 10/100 or duplex issue. icmp goes at full speed. -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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.2 <-> 2.4.5-ac5 tcp too slow
i seem to remember this being mentioned before, but couldn't find any reference in the list archives. i have an x86 laptop running 2.2.17 (2.2.19 has the same effect) and an alpha pws 500 running 2.4.5-ac5. tcp starts slow and get slower. it's not a 10/100 or duplex issue. icmp goes at full speed. it doesn't matter which side starts the connection. has anyone else experienced this? any suggestions? -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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.2 - 2.4.5-ac5 tcp too slow
i seem to remember this being mentioned before, but couldn't find any reference in the list archives. i have an x86 laptop running 2.2.17 (2.2.19 has the same effect) and an alpha pws 500 running 2.4.5-ac5. tcp starts slow and get slower. it's not a 10/100 or duplex issue. icmp goes at full speed. it doesn't matter which side starts the connection. has anyone else experienced this? any suggestions? -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - 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.2 - 2.4.5-ac5 tcp too slow
i tracked it down to the 8139 driver in 2.4. On Mon, Jun 04, 2001 at 06:28:34PM -0400, Tom Vier wrote: has the same effect) and an alpha pws 500 running 2.4.5-ac5. tcp starts slow and get slower. it's not a 10/100 or duplex issue. icmp goes at full speed. -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - 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.5-ac6
> o Fix mmap cornercase (Maciej Rozycki) when i try running osf/1 netscape on alpha, mmap of libXmu fails. works fine on -ac5. -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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.5-ac6
o Fix mmap cornercase (Maciej Rozycki) when i try running osf/1 netscape on alpha, mmap of libXmu fails. works fine on -ac5. -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - 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.5-ac3: qlogic corruption on alpha
On Tue, May 29, 2001 at 10:05:27PM -0400, Jeff Garzik wrote: > Also, what compiler are you using? Depending on your current compiler, > switching to another compiler according to one of the following > permutations would be very instructive for us debugging the problem, at > least. debian 2.25.2 2220 > gcc-2.96-RH -> gcc-2.95.3 > gcc-2.95.2 -> gcc-2.95.3 > gcc-2.95.3 -> egcs-1.1.2 i'll give another one a try, tomorrow. -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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.5-ac3: qlogic corruption on alpha
On Tue, May 29, 2001 at 09:17:45PM -0400, Jeff Garzik wrote: > Tom Vier wrote: > > i narrowed down some corruption i was having. it only happens on drives > > attached to my qlogic isp card. 2.2 has no problem, and in 2.4.5-ac3 my > > sym53c875 works fine. this machine is an alpha miata. it only happens when > > writing out a lot to disk. eg, untarring a kernel tarball, restoring a > > backup. anyone else see this? > > Is this reproducible? yes. by restoring a backup from tape. i tried cat /dev/zero > /dev/sdb1, but that wasn't enough to trigger any corruption (i correctly wrote all zeros). actually, now that i think about it, a good chunk of /dev/sdb2 was cached when i read it back, so that wasn't a very good test. i definetly get corruption under 2.4.5-ac4. > Other questions - is your machine SMP? How much RAM? UP, half gig. -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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.5-ac3: qlogic corruption on alpha
i narrowed down some corruption i was having. it only happens on drives attached to my qlogic isp card. 2.2 has no problem, and in 2.4.5-ac3 my sym53c875 works fine. this machine is an alpha miata. it only happens when writing out a lot to disk. eg, untarring a kernel tarball, restoring a backup. anyone else see this? -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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.5-ac3: qlogic corruption on alpha
i narrowed down some corruption i was having. it only happens on drives attached to my qlogic isp card. 2.2 has no problem, and in 2.4.5-ac3 my sym53c875 works fine. this machine is an alpha miata. it only happens when writing out a lot to disk. eg, untarring a kernel tarball, restoring a backup. anyone else see this? -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - 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.5-ac3: qlogic corruption on alpha
On Tue, May 29, 2001 at 09:17:45PM -0400, Jeff Garzik wrote: Tom Vier wrote: i narrowed down some corruption i was having. it only happens on drives attached to my qlogic isp card. 2.2 has no problem, and in 2.4.5-ac3 my sym53c875 works fine. this machine is an alpha miata. it only happens when writing out a lot to disk. eg, untarring a kernel tarball, restoring a backup. anyone else see this? Is this reproducible? yes. by restoring a backup from tape. i tried cat /dev/zero /dev/sdb1, but that wasn't enough to trigger any corruption (i correctly wrote all zeros). actually, now that i think about it, a good chunk of /dev/sdb2 was cached when i read it back, so that wasn't a very good test. i definetly get corruption under 2.4.5-ac4. snip Other questions - is your machine SMP? How much RAM? UP, half gig. -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - 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.5-ac3: qlogic corruption on alpha
On Tue, May 29, 2001 at 10:05:27PM -0400, Jeff Garzik wrote: Also, what compiler are you using? Depending on your current compiler, switching to another compiler according to one of the following permutations would be very instructive for us debugging the problem, at least. debian 2.25.2 2220 gcc-2.96-RH - gcc-2.95.3 gcc-2.95.2 - gcc-2.95.3 gcc-2.95.3 - egcs-1.1.2 i'll give another one a try, tomorrow. -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - 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.5-ac2
actually, it happens on ext2, also. it was fun trying to switch back to 2.2 after converting raid devs for 2.4 and trashing my emergency boot disk. i was finally able to restore from tape by mounting -o sync. there was still some minor corruption caught by fsck, though. the new sym53c875 driver seems to have fixed the pci_map_sg() problem i was having, but now it complains about scsi script errors. changing the TCQ defaults from 32 to 8 fixes that. though, the corruption (even with TCQ max 8 and -o sync) may be related. anyone else tried 2.4.5-ac2 on a miata or other alpha? On Sun, May 27, 2001 at 11:38:01PM -0400, Tom Vier wrote: > i haven't had any reiserfs crashes on my alpha, but restoring a backup of a > debian installation to a reiserfs partition doesn't quite work. untarring a > linux kernel tarball to the fs works, does work though. i get these kernel > messages: -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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.5-ac2
i haven't had any reiserfs crashes on my alpha, but restoring a backup of a debian installation to a reiserfs partition doesn't quite work. untarring a linux kernel tarball to the fs works, does work though. i get these kernel messages: May 27 23:28:47 zero kernel: is_leaf: free space seems wrong: level=1, nr_items=17, free_space=132 rdkey May 27 23:28:47 zero kernel: vs-5150: search_by_key: invalid format found in block 11693. Fsck? May 27 23:28:47 zero kernel: vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [1361 1362 0x0 SD] May 27 23:28:47 zero kernel: vs-13048: reiserfs_iget: bad_inode. Stat data of (1361 1362) not found May 27 23:28:47 zero last message repeated 2 times May 27 23:28:48 zero kernel: is_leaf: free space seems wrong: level=1, nr_items=18, free_space=568 rdkey May 27 23:28:48 zero kernel: vs-5150: search_by_key: invalid format found in block 14392. Fsck? May 27 23:28:48 zero kernel: vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [3215 3216 0x0 SD] May 27 23:28:48 zero kernel: vs-13048: reiserfs_iget: bad_inode. Stat data of (3215 3216) not found May 27 23:28:48 zero last message repeated 2 times May 27 23:28:49 zero kernel: is_leaf: free space seems wrong: level=1, nr_items=18, free_space=568 rdkey May 27 23:28:49 zero kernel: vs-5150: search_by_key: invalid format found in block 14392. Fsck? May 27 23:28:49 zero kernel: vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [3208 3210 0x0 SD] May 27 23:28:49 zero kernel: vs-13048: reiserfs_iget: bad_inode. Stat data of (3208 3210) not found May 27 23:28:49 zero last message repeated 2 times May 27 23:28:49 zero kernel: is_leaf: free space seems wrong: level=1, nr_items=18, free_space=568 rdkey May 27 23:28:49 zero kernel: vs-5150: search_by_key: invalid format found in block 14392. Fsck? May 27 23:28:49 zero kernel: vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [3208 3211 0x0 SD] May 27 23:28:49 zero kernel: vs-13048: reiserfs_iget: bad_inode. Stat data of (3208 3211) not found May 27 23:28:49 zero last message repeated 8 times On Mon, May 28, 2001 at 01:33:42AM +0100, Alan Cox wrote: > 2.4.5-ac2 > o Restore lock_kernel on umount (Al Viro) > | Should cure Reiserfs crash in 2.4.5 -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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.5-ac2
i haven't had any reiserfs crashes on my alpha, but restoring a backup of a debian installation to a reiserfs partition doesn't quite work. untarring a linux kernel tarball to the fs works, does work though. i get these kernel messages: May 27 23:28:47 zero kernel: is_leaf: free space seems wrong: level=1, nr_items=17, free_space=132 rdkey May 27 23:28:47 zero kernel: vs-5150: search_by_key: invalid format found in block 11693. Fsck? May 27 23:28:47 zero kernel: vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [1361 1362 0x0 SD] May 27 23:28:47 zero kernel: vs-13048: reiserfs_iget: bad_inode. Stat data of (1361 1362) not found May 27 23:28:47 zero last message repeated 2 times May 27 23:28:48 zero kernel: is_leaf: free space seems wrong: level=1, nr_items=18, free_space=568 rdkey May 27 23:28:48 zero kernel: vs-5150: search_by_key: invalid format found in block 14392. Fsck? May 27 23:28:48 zero kernel: vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [3215 3216 0x0 SD] May 27 23:28:48 zero kernel: vs-13048: reiserfs_iget: bad_inode. Stat data of (3215 3216) not found May 27 23:28:48 zero last message repeated 2 times May 27 23:28:49 zero kernel: is_leaf: free space seems wrong: level=1, nr_items=18, free_space=568 rdkey May 27 23:28:49 zero kernel: vs-5150: search_by_key: invalid format found in block 14392. Fsck? May 27 23:28:49 zero kernel: vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [3208 3210 0x0 SD] May 27 23:28:49 zero kernel: vs-13048: reiserfs_iget: bad_inode. Stat data of (3208 3210) not found May 27 23:28:49 zero last message repeated 2 times May 27 23:28:49 zero kernel: is_leaf: free space seems wrong: level=1, nr_items=18, free_space=568 rdkey May 27 23:28:49 zero kernel: vs-5150: search_by_key: invalid format found in block 14392. Fsck? May 27 23:28:49 zero kernel: vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [3208 3211 0x0 SD] May 27 23:28:49 zero kernel: vs-13048: reiserfs_iget: bad_inode. Stat data of (3208 3211) not found May 27 23:28:49 zero last message repeated 8 times On Mon, May 28, 2001 at 01:33:42AM +0100, Alan Cox wrote: 2.4.5-ac2 o Restore lock_kernel on umount (Al Viro) | Should cure Reiserfs crash in 2.4.5 -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - 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.5-ac2
actually, it happens on ext2, also. it was fun trying to switch back to 2.2 after converting raid devs for 2.4 and trashing my emergency boot disk. i was finally able to restore from tape by mounting -o sync. there was still some minor corruption caught by fsck, though. the new sym53c875 driver seems to have fixed the pci_map_sg() problem i was having, but now it complains about scsi script errors. changing the TCQ defaults from 32 to 8 fixes that. though, the corruption (even with TCQ max 8 and -o sync) may be related. anyone else tried 2.4.5-ac2 on a miata or other alpha? On Sun, May 27, 2001 at 11:38:01PM -0400, Tom Vier wrote: i haven't had any reiserfs crashes on my alpha, but restoring a backup of a debian installation to a reiserfs partition doesn't quite work. untarring a linux kernel tarball to the fs works, does work though. i get these kernel messages: -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - 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: alpha iommu fixes
On Sat, May 19, 2001 at 02:48:15PM +0400, Ivan Kokshaysky wrote: > This is incorrect. If you want directly mapped PCI window then you don't > need the iommu_arena for it. If you want scatter-gather mapping, you > should write address of the SG page table into the T3_BASE register. i've tried both direct mapped and sg, but it still get pci_map_sg() failures in sym53c8xx. the sg version, below, won't boot (scsi commands all timeout). while the added direct map version does boot, it suffers the same problem as the stock code. third direct map: hose->sg_pci = NULL; hose->sg_isa = iommu_arena_new(hose, 0x0080, 0x0080, 32768); __direct_map_base = 0x4000; __direct_map_size = 0x8800; *(vip)CIA_IOC_PCI_W3_BASE = 0xc000 | 1; *(vip)CIA_IOC_PCI_W3_MASK = (0x0800 - 1) & 0xfff0; *(vip)CIA_IOC_PCI_T3_BASE = 0x8000 >> 2; sg (doesn't work): hose->sg_isa = iommu_arena_new(hose, 0x0080, 0x0080, 32768); hose->sg_pci = iommu_arena_new(hose, 0xc000, 0x0800, 32768); __direct_map_base = 0x4000; __direct_map_size = 0x8000; *(vip)CIA_IOC_PCI_W3_BASE = hose->sg_pci->dma_base | 3; *(vip)CIA_IOC_PCI_W3_MASK = (hose->sg_pci->size - 1) & 0xfff0; *(vip)CIA_IOC_PCI_T3_BASE = virt_to_phys(hose->sg_pci->ptes) >> 2; -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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: alpha iommu fixes
On Sat, May 19, 2001 at 02:48:15PM +0400, Ivan Kokshaysky wrote: This is incorrect. If you want directly mapped PCI window then you don't need the iommu_arena for it. If you want scatter-gather mapping, you should write address of the SG page table into the T3_BASE register. i've tried both direct mapped and sg, but it still get pci_map_sg() failures in sym53c8xx. the sg version, below, won't boot (scsi commands all timeout). while the added direct map version does boot, it suffers the same problem as the stock code. third direct map: hose-sg_pci = NULL; hose-sg_isa = iommu_arena_new(hose, 0x0080, 0x0080, 32768); __direct_map_base = 0x4000; __direct_map_size = 0x8800; *(vip)CIA_IOC_PCI_W3_BASE = 0xc000 | 1; *(vip)CIA_IOC_PCI_W3_MASK = (0x0800 - 1) 0xfff0; *(vip)CIA_IOC_PCI_T3_BASE = 0x8000 2; sg (doesn't work): hose-sg_isa = iommu_arena_new(hose, 0x0080, 0x0080, 32768); hose-sg_pci = iommu_arena_new(hose, 0xc000, 0x0800, 32768); __direct_map_base = 0x4000; __direct_map_size = 0x8000; *(vip)CIA_IOC_PCI_W3_BASE = hose-sg_pci-dma_base | 3; *(vip)CIA_IOC_PCI_W3_MASK = (hose-sg_pci-size - 1) 0xfff0; *(vip)CIA_IOC_PCI_T3_BASE = virt_to_phys(hose-sg_pci-ptes) 2; -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - 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: alpha iommu fixes
maybe this third window stuff in cia_enable_broken_tbia() is why i can't seem to get the third window to open up. from my reading of the 21174 docs, my code should work. since T2_BASE is at 0x4000 for 1gig, i'd think T3_BASE should be at 0x8000. am i missing something? hose->sg_pci = iommu_arena_new(hose, 0xc000, 0x0800, 32768); *(vip)CIA_IOC_PCI_W3_BASE = 0xc000 | 1; *(vip)CIA_IOC_PCI_W3_MASK = (0x0800 - 1) & 0xfff0; *(vip)CIA_IOC_PCI_T3_BASE = 0x8000 >> 2; On Fri, May 18, 2001 at 09:46:17PM +0400, Ivan Kokshaysky wrote: > - *(vip)CIA_IOC_PCI_W3_BASE = CIA_BROKEN_TBI_TRY2_BASE | 3; > - *(vip)CIA_IOC_PCI_W3_MASK = (PAGE_SIZE - 1) & 0xfff0; > + *(vip)CIA_IOC_PCI_W3_BASE = CIA_BROKEN_TBIA_BASE | 3; > + *(vip)CIA_IOC_PCI_W3_MASK = (CIA_BROKEN_TBIA_SIZE*1024 - 1) > + & 0xfff0; > *(vip)CIA_IOC_PCI_T3_BASE = virt_to_phys(ppte) >> 2; > } -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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: alpha iommu fixes
maybe this third window stuff in cia_enable_broken_tbia() is why i can't seem to get the third window to open up. from my reading of the 21174 docs, my code should work. since T2_BASE is at 0x4000 for 1gig, i'd think T3_BASE should be at 0x8000. am i missing something? hose-sg_pci = iommu_arena_new(hose, 0xc000, 0x0800, 32768); *(vip)CIA_IOC_PCI_W3_BASE = 0xc000 | 1; *(vip)CIA_IOC_PCI_W3_MASK = (0x0800 - 1) 0xfff0; *(vip)CIA_IOC_PCI_T3_BASE = 0x8000 2; On Fri, May 18, 2001 at 09:46:17PM +0400, Ivan Kokshaysky wrote: - *(vip)CIA_IOC_PCI_W3_BASE = CIA_BROKEN_TBI_TRY2_BASE | 3; - *(vip)CIA_IOC_PCI_W3_MASK = (PAGE_SIZE - 1) 0xfff0; + *(vip)CIA_IOC_PCI_W3_BASE = CIA_BROKEN_TBIA_BASE | 3; + *(vip)CIA_IOC_PCI_W3_MASK = (CIA_BROKEN_TBIA_SIZE*1024 - 1) + 0xfff0; *(vip)CIA_IOC_PCI_T3_BASE = virt_to_phys(ppte) 2; } -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - 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/
pci_map_sg() failure on alpha
has anyone else had problems with pci_map_sg() in 2.4.4-ac*? i get the message from line 512 in pci_iommu.c, "pci_map_sg failed: could not allocate dma page tables" printed about 10 times, then a second or two later, it kills the interrupt handler. it's being called by the sym53c8xx driver. it's easily reproducible, by bunzip linux.tar.bz | tar x. this is on a pws 500ua, btw. -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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/
pci_map_sg() failure on alpha
has anyone else had problems with pci_map_sg() in 2.4.4-ac*? i get the message from line 512 in pci_iommu.c, pci_map_sg failed: could not allocate dma page tables printed about 10 times, then a second or two later, it kills the interrupt handler. it's being called by the sym53c8xx driver. it's easily reproducible, by bunzip linux.tar.bz | tar x. this is on a pws 500ua, btw. -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - 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: O_DSYNC flag for open
fdatasync() is the same as fsync(), in linux. until fdatasync() is implimented (ie, syncs the data only), there's no reason to define O_DSYNC. just use: #ifndef O_DSYNC # define O_DSYNC O_SYNC #endif On Sat, Mar 10, 2001 at 01:03:57PM +0600, Denis Perchine wrote: > one small question... Will O_DSYNC flag be available in Linux? > It is available at least on AIX, and HP-UX. The difference with O_SYNC is the > same as between fsync and fdatasync. -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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: O_DSYNC flag for open
fdatasync() is the same as fsync(), in linux. until fdatasync() is implimented (ie, syncs the data only), there's no reason to define O_DSYNC. just use: #ifndef O_DSYNC # define O_DSYNC O_SYNC #endif On Sat, Mar 10, 2001 at 01:03:57PM +0600, Denis Perchine wrote: one small question... Will O_DSYNC flag be available in Linux? It is available at least on AIX, and HP-UX. The difference with O_SYNC is the same as between fsync and fdatasync. -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - 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: Sparc64 compile error for 2.4.0-prerelease
same on alpha On Tue, Jan 02, 2001 at 09:36:09AM +0800, Tommy Wu wrote: > panic.c: In function `panic': > panic.c:80: `loops_per_sec' undeclared (first use in this function) > panic.c:80: (Each undeclared identifier is reported only once > panic.c:80: for each function it appears in.) -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Sparc64 compile error for 2.4.0-prerelease
same on alpha On Tue, Jan 02, 2001 at 09:36:09AM +0800, Tommy Wu wrote: panic.c: In function `panic': panic.c:80: `loops_per_sec' undeclared (first use in this function) panic.c:80: (Each undeclared identifier is reported only once panic.c:80: for each function it appears in.) -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No more DoS
This has already been discused here and on slashdot, on 9/25/2000. On Fri, Dec 22, 2000 at 01:24:44PM +1100, Mike OConnor wrote: > I would like to point who ever is in charge of the TCP stack for the linux > kernel at a site which claims to have a method of eliminate denial of service > (DoS) attacks > > http://grc.com/r/nomoredos.htm -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No more DoS
This has already been discused here and on slashdot, on 9/25/2000. On Fri, Dec 22, 2000 at 01:24:44PM +1100, Mike OConnor wrote: I would like to point who ever is in charge of the TCP stack for the linux kernel at a site which claims to have a method of eliminate denial of service (DoS) attacks http://grc.com/rd/nomoredos.htm snip -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Dropping chars on 16550
On Thu, Dec 14, 2000 at 08:51:42AM -0600, Chad Schwartz wrote: > And what kind of serial ports do you find on your Alpha? 16550's! Your > PowerPC? 16550's! Your PA-RISC box? 16550's! Hey! Even RS/6000's use > 16550's! macs and sun machines use z85c30 chips, so there are some non-16550 boxes out there. -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Dropping chars on 16550
On Thu, Dec 14, 2000 at 08:51:42AM -0600, Chad Schwartz wrote: And what kind of serial ports do you find on your Alpha? 16550's! Your PowerPC? 16550's! Your PA-RISC box? 16550's! Hey! Even RS/6000's use 16550's! macs and sun machines use z85c30 chips, so there are some non-16550 boxes out there. -- Tom Vier [EMAIL PROTECTED] DSA Key id 0x27371A2C - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
