[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]> you
>wrote:
> > Dear Kernel People,
> > A friend of mine has a new PC with an ASUS CUV4X-D motherboard
> > and dual 1GHZ PIII's.
...
> For several people the following works:
> 1) Upgrade to the latest bios
> 2) Change the "MPS"
[EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED] you
wrote:
Dear Kernel People,
A friend of mine has a new PC with an ASUS CUV4X-D motherboard
and dual 1GHZ PIII's.
...
For several people the following works:
1) Upgrade to the latest bios
2) Change the MPS level in the bios.
John Cavan wrote:
> I have an AIC7 based SCSI card in my machine as well, hooked up to a
> Jaz. I haven't actually used it in ages, but I'll test it to see of the
> problem is apparent on CUV4X-D board as well.
First, I copied 640 Mb file to the jaz disk, no problem. Then I ran
"J. Nick Koston" wrote:
>
> Thanks for the tips, however it doesn't help :-(
It was worth a shot...
> > Also, try passing "noapic" to the kernel on boot if the problem still
> > persists. The downside is that all interrupts will be handled by a
> > single CPU. There is a definite problem with
J. Nick Koston wrote:
Thanks for the tips, however it doesn't help :-(
It was worth a shot...
Also, try passing noapic to the kernel on boot if the problem still
persists. The downside is that all interrupts will be handled by a
single CPU. There is a definite problem with VIA
John Cavan wrote:
I have an AIC7 based SCSI card in my machine as well, hooked up to a
Jaz. I haven't actually used it in ages, but I'll test it to see of the
problem is apparent on CUV4X-D board as well.
First, I copied 640 Mb file to the jaz disk, no problem. Then I ran the
same
Dieter Nützel wrote:
>
> Hello Alan,
>
> I see 4.29 GB under shm with your latest try.
> something wrong?
total:used:free: shared: buffers: cached:
Mem: 1053483008 431419392 622063616 122880 24387584 260923392
Swap: 3947642880 394764288
MemTotal: 1028792 kB
Dieter Nützel wrote:
Hello Alan,
I see 4.29 GB under shm with your latest try.
something wrong?
total:used:free: shared: buffers: cached:
Mem: 1053483008 431419392 622063616 122880 24387584 260923392
Swap: 3947642880 394764288
MemTotal: 1028792 kB
Not to sound dense, but what part of the GPL prohibits a piece of GPL'd
software from including non-GPL'd code? The GPL does explicitly state
that you can't include it's software in proprietary code, but I don't
recall seeing a provision that prohibits the other way around.
It may not be in the
Not to sound dense, but what part of the GPL prohibits a piece of GPL'd
software from including non-GPL'd code? The GPL does explicitly state
that you can't include it's software in proprietary code, but I don't
recall seeing a provision that prohibits the other way around.
It may not be in the
Hi,
I've seen a lot of messages regarding problems with the VIA chipset...
I've experienced them myself.
Anyways, I just put in a new ASUS CUV4X-D motherboard, BIOS revision
1004. Once installed, I ran into a raft of problems when IO-APIC was
enabled... and discovered that ASUS had a BIOS
Hi,
I've seen a lot of messages regarding problems with the VIA chipset...
I've experienced them myself.
Anyways, I just put in a new ASUS CUV4X-D motherboard, BIOS revision
1004. Once installed, I ran into a raft of problems when IO-APIC was
enabled... and discovered that ASUS had a BIOS
On Thu, 26 Apr 2001 [EMAIL PROTECTED] wrote:
> you're right, we could do it in more than one way. like copying
> with mcopy without mounting a fat disk. the question is where to put it.
> why we do it is an important thing.
> taking place as a clueless user, i think i should be able to do
On Wed, 25 Apr 2001 [EMAIL PROTECTED] wrote:
> so i guess i deserve opinions instead of flames. the
> approach is from personal use, not the usual server use.
> if you think a server setup is best for all use just say so,
> i'm listening.
Several distributions (Red Hat and Mandrake certainly)
On Wed, 25 Apr 2001 [EMAIL PROTECTED] wrote:
so i guess i deserve opinions instead of flames. the
approach is from personal use, not the usual server use.
if you think a server setup is best for all use just say so,
i'm listening.
Several distributions (Red Hat and Mandrake certainly) offer
Manuel McLure wrote:
> Did you try nesting more than one "su -"? The first one after a boot works
> for me - every other one fails.
I tried it with about a half-dozen nested and no problem. Mandrake
cooker here...
uname -a
Linux lion 2.4.3-ac11 #5 SMP Fri Apr 20 22:10:41 EDT 2001 i686 unknown
Alan Cox wrote:
>
> > > Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > symbol rwsem_up_write_wake
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > symbol
Alan Cox wrote:
> 2.4.3-ac12
> o Further semaphore fixes (David Howells)
Getting unresolved symbols in some modules (notably, for me, microcode.o
and radeon.o)...
Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
Alan Cox wrote:
2.4.3-ac12
o Further semaphore fixes (David Howells)
Getting unresolved symbols in some modules (notably, for me, microcode.o
and radeon.o)...
Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
Alan Cox wrote:
Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
/lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
symbol rwsem_up_write_wake
/lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
symbol rwsem_down_write_failed
Manuel McLure wrote:
Did you try nesting more than one "su -"? The first one after a boot works
for me - every other one fails.
I tried it with about a half-dozen nested and no problem. Mandrake
cooker here...
uname -a
Linux lion 2.4.3-ac11 #5 SMP Fri Apr 20 22:10:41 EDT 2001 i686 unknown
Alan Cox wrote:
> VIA users should test this kernel carefully. It has what are supposed to be
> the right fixes for the VIA hardware bugs. Obviously the right fixes are not
> as tested as the deduced ones.
>
> 2.4.3-ac7
> o Updated VIA quirk handling for the chipset (Andre Hedrick,
>
Alan Cox wrote:
VIA users should test this kernel carefully. It has what are supposed to be
the right fixes for the VIA hardware bugs. Obviously the right fixes are not
as tested as the deduced ones.
2.4.3-ac7
o Updated VIA quirk handling for the chipset (Andre Hedrick,
"Jeffrey W. Baker" wrote:
> So, I conclude that the patch was created incorrectly, or that something
> changed between cutting the patch and the tarball.
Compiled fine for me without the complete tarball, just patched. Now, I
went straight to ac2 (now ac3) without building the 2.4.3 stock
Alan Cox wrote:
> 2.4.2-ac24
Is DRI still hosed?
-
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/
Phil Oester wrote:
>
> one more try...
>
> anyone else get the following:
>
> make[5]: Entering directory
> `/usr/src/linux-2.4.2-ac13/drivers/scsi/aic7xxx/aicasm'
> lex -t aicasm_scan.l > aicasm_scan.c
> gcc -I/usr/include -ldb aicasm_gram.c aicasm_scan.c aicasm.c
> aicasm_symbol.c -o aicasm
Phil Oester wrote:
one more try...
anyone else get the following:
make[5]: Entering directory
`/usr/src/linux-2.4.2-ac13/drivers/scsi/aic7xxx/aicasm'
lex -t aicasm_scan.l aicasm_scan.c
gcc -I/usr/include -ldb aicasm_gram.c aicasm_scan.c aicasm.c
aicasm_symbol.c -o aicasm
Alan Cox wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
>
> 2.4.2-ac11
Doesn't apply cleanly against a 2.4.2 tree...
./mm/slab.c.rej
./net/irda/irnet/irnet.h.rej
./arch/i386/kernel/traps.c.rej
./drivers/net/tulip/tulip.h.rej
./drivers/net/tulip/tulip_core.c.rej
Alan Cox wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
2.4.2-ac11
Doesn't apply cleanly against a 2.4.2 tree...
./mm/slab.c.rej
./net/irda/irnet/irnet.h.rej
./arch/i386/kernel/traps.c.rej
./drivers/net/tulip/tulip.h.rej
./drivers/net/tulip/tulip_core.c.rej
"Henning P. Schmiedehausen" wrote:
>
> [EMAIL PROTECTED] (Michael H. Warfield) writes:
>
> > Excuse me? A 1 billion dolar investment in Linux is not
> >supporting it?
>
> On their own hardware.
Which is really the point and they won't be the only ones. If IBM wants
to attract and keep
"Henning P. Schmiedehausen" wrote:
[EMAIL PROTECTED] (Michael H. Warfield) writes:
Excuse me? A 1 billion dolar investment in Linux is not
supporting it?
On their own hardware.
Which is really the point and they won't be the only ones. If IBM wants
to attract and keep customers on
Dennis wrote:
> objective, arent we?
You might ask yourself the same question...
> For example, if there were six different companies that marketed ethernet
> drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> with different "features" that were of value to you.
David Wood wrote:
>
> I believe you, although... why doesn't it happen with 2.2.17? vconsole
> buffers in a different place in memory, I suppose?
>
> I'll forward this to the XFree team. Thanks!
> -David
Known bug, they're working on it.
If you want to avoid the corruption, use the Vesa
David Wood wrote:
I believe you, although... why doesn't it happen with 2.2.17? vconsole
buffers in a different place in memory, I suppose?
I'll forward this to the XFree team. Thanks!
-David
Known bug, they're working on it.
If you want to avoid the corruption, use the Vesa framebuffer
Dennis wrote:
objective, arent we?
You might ask yourself the same question...
For example, if there were six different companies that marketed ethernet
drivers for the eepro100, you'd have a choice of which one to buy..perhaps
with different "features" that were of value to you. Instead,
"Albert D. Cahalan" wrote:
>
> > It had always been my assumption that non-optical storage media used
> > the 'disk' spelling, whereas optical media, such as CDs, DVDs, and MO,
> > were reffered to using the 'disc' spelling.
>
> No, "disk" is correct for everything, but we use "disc" for a
Greg KH wrote:
>
> On Fri, Feb 09, 2001 at 07:22:54PM -0500, John Cavan wrote:
> >
> > Current config:
> >
> > Dual P3-500 w/ 512mb of RAM
> > Tyan Tiger 133 mobo with VIA chipset, onboard USB
> > Kernel 2.4.1-ac9 compiled with egcs-1.1.2
>
> T
Greg KH wrote:
>
> On Fri, Feb 09, 2001 at 07:22:54PM -0500, John Cavan wrote:
> >
> > Current config:
> >
> > Dual P3-500 w/ 512mb of RAM
> > Tyan Tiger 133 mobo with VIA chipset, onboard USB
> > Kernel 2.4.1-ac9 compiled with egcs-1.1.2
>
> T
Hi,
Just got a D-Link USB radio (R100) and I'm seeing lots of timeouts with
it. I've seen this through the last few 2.4.1+ and -ac+ kernels.
Current config:
Dual P3-500 w/ 512mb of RAM
Tyan Tiger 133 mobo with VIA chipset, onboard USB
Kernel 2.4.1-ac9 compiled with egcs-1.1.2
The only thing
Hi,
Just got a D-Link USB radio (R100) and I'm seeing lots of timeouts with
it. I've seen this through the last few 2.4.1+ and -ac+ kernels.
Current config:
Dual P3-500 w/ 512mb of RAM
Tyan Tiger 133 mobo with VIA chipset, onboard USB
Kernel 2.4.1-ac9 compiled with egcs-1.1.2
The only thing
Greg KH wrote:
On Fri, Feb 09, 2001 at 07:22:54PM -0500, John Cavan wrote:
Current config:
Dual P3-500 w/ 512mb of RAM
Tyan Tiger 133 mobo with VIA chipset, onboard USB
Kernel 2.4.1-ac9 compiled with egcs-1.1.2
This motherboard does not currently work with USB in SMP mode
Greg KH wrote:
On Fri, Feb 09, 2001 at 07:22:54PM -0500, John Cavan wrote:
Current config:
Dual P3-500 w/ 512mb of RAM
Tyan Tiger 133 mobo with VIA chipset, onboard USB
Kernel 2.4.1-ac9 compiled with egcs-1.1.2
This motherboard does not currently work with USB in SMP mode
Hi,
I noticed an odd thing about my / file system:
du -hx reports 74mb used
df -h . reports 236mb used
The same behaviour does not show on other mounted filesystems... I'm not
sure which to believe...
I've seen this with 2.4.1 and 2.4.1-ac1, the filesystem is ReiserFS and
the kernel was
Hi,
I noticed an odd thing about my / file system:
du -hx reports 74mb used
df -h . reports 236mb used
The same behaviour does not show on other mounted filesystems... I'm not
sure which to believe...
I've seen this with 2.4.1 and 2.4.1-ac1, the filesystem is ReiserFS and
the kernel was
David Ford wrote:
>
> PCI: No IRQ known for interrupt pin A of device 01:00.0. Please try
> using pci=biosirq.
>
> 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 RF
> (prog-if 00 [VGA])
> Subsystem: ATI Technologies Inc: Unknown device 0008
> Flags: bus master,
David Ford wrote:
PCI: No IRQ known for interrupt pin A of device 01:00.0. Please try
using pci=biosirq.
01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 RF
(prog-if 00 [VGA])
Subsystem: ATI Technologies Inc: Unknown device 0008
Flags: bus master,
Hi all,
I've seen this for a while... the output from netstat and ifconfig do
not agree on the MTU of the device:
[root@lion /root]# netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt
Iface
10.1.11.0 * 255.255.255.0
Hi all,
I've seen this for a while... the output from netstat and ifconfig do
not agree on the MTU of the device:
[root@lion /root]# netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt
Iface
10.1.11.0 * 255.255.255.0
David Ford wrote:
> > One other thing. Allot of people neglect to brace a statement if
> > it has a single line body. This is VERY bad, always brace your
> > statements
> >
> > if (x = 1)
> >if (y = 2)
> > if (z = 3)
> >for (i = 1; i < 10; i++)
> > if
> >
David Ford wrote:
One other thing. Allot of people neglect to brace a statement if
it has a single line body. This is VERY bad, always brace your
statements
if (x = 1)
if (y = 2)
if (z = 3)
for (i = 1; i 10; i++)
if
switch (foo)
> I have been trying to figure out
> why linux tcp is failing to ack
> properly in some situations.
This is exactly the same problem I'm seeing with a Solaris box talking
to my Linux box. It has a similar problem with Linux as well, but does
not manifest as bad against a 2.2 kernel machine.
Hi all,
I've seen this for a while... the output from netstat and ifconfig do
not agree on the MTU of the device:
[root@lion /root]# netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt
Iface
10.1.11.0 * 255.255.255.0
Hi all,
I've seen this for a while... the output from netstat and ifconfig do
not agree on the MTU of the device:
[root@lion /root]# netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt
Iface
10.1.11.0 * 255.255.255.0
I have been trying to figure out
why linux tcp is failing to ack
properly in some situations.
This is exactly the same problem I'm seeing with a Solaris box talking
to my Linux box. It has a similar problem with Linux as well, but does
not manifest as bad against a 2.2 kernel machine. Seems I
Alan Cox wrote:
> > to fall through, but is this correct? I've inserted a break at the end
> > of the Intel switch before and have not had problems, but I left it out
>
> Lucky
Wouldn't be the first time...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Petr Vandrovec wrote:
> > kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary
> > last message repeated 2 times
>
> For some strange reason X thinks that you have 24MB of memory on the G450.
> You can either create 32MB write-combining region at 0xd400, or
> teach X
> kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary
> last message repeated 2 times
>
> and finally:
>
> %cat /proc/mtrr
> reg00: base=0x ( 0MB), size= 256MB: write-back, count=1
> reg01: base=0xd000 (3328MB), size= 64MB: write-combining, count=1
>
kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary
last message repeated 2 times
and finally:
%cat /proc/mtrr
reg00: base=0x ( 0MB), size= 256MB: write-back, count=1
reg01: base=0xd000 (3328MB), size= 64MB: write-combining, count=1
reg02:
Petr Vandrovec wrote:
kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary
last message repeated 2 times
For some strange reason X thinks that you have 24MB of memory on the G450.
You can either create 32MB write-combining region at 0xd400, or
teach X that your
Alan Cox wrote:
> o Fix ppa and imm hangs on io_request_lock(Tim Waugh)
Just so I understand the differences, for learning purposes... Tim did
this a little different than I did and I'd just like to understand the
"whys" of it.
Can't learn if I don't understand. :o)
Thanks,
John
Alan Cox wrote:
o Fix ppa and imm hangs on io_request_lock(Tim Waugh)
Just so I understand the differences, for learning purposes... Tim did
this a little different than I did and I'd just like to understand the
"whys" of it.
Can't learn if I don't understand. :o)
Thanks,
John
Petr Vandrovec wrote:
>
> On Sat, Nov 18, 2000 at 10:43:20PM -0500, John Cavan wrote:
> > Bus 1, device 0, function 0:
> > VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 5).
> > IRQ 16.
> > Master Capable. Late
Petr Vandrovec wrote:
On Sat, Nov 18, 2000 at 10:43:20PM -0500, John Cavan wrote:
Bus 1, device 0, function 0:
VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 5).
IRQ 16.
Master Capable. Latency=64. Min Gnt=16.Max Lat=32.
Prefetchable 32 bit
I don't know if this is specifically a problem with the AGP driver or
with X, but basically the AGP driver detects an aperture base address
different from that of the prefetchable memory area of the video card
and the mtrr's are not in agreement.
I'm using this with a Dual P3-500mhz and a Matrox
Tim Waugh wrote:
>
> On Thu, Nov 16, 2000 at 09:50:40PM -0500, John Cavan wrote:
>
> > [...] This patch unlocks, allows the lowlevel driver to do it's
> > probes, and then relocks. It could probably be more granular in the
> > parport_pc code, but my own home tests
Tim Waugh wrote:
On Thu, Nov 16, 2000 at 09:50:40PM -0500, John Cavan wrote:
[...] This patch unlocks, allows the lowlevel driver to do it's
probes, and then relocks. It could probably be more granular in the
parport_pc code, but my own home tests show it to be working fine
I don't know if this is specifically a problem with the AGP driver or
with X, but basically the AGP driver detects an aperture base address
different from that of the prefetchable memory area of the video card
and the mtrr's are not in agreement.
I'm using this with a Dual P3-500mhz and a Matrox
Jens Axboe wrote:
> Wouldn't it be more interesting to fix the reason the new error
> handling code dies with imm and ppa?
Yes it would... :o) I think I've got it here.
The new error handling code spinlocks the IRQ which cause the lowlevel
parport driver to choke. This patch unlocks, allows the
John Cavan wrote:
>
> Similar to the imm patch, it's working for me.
>
> John
Again... not all screwed up...
patch -ur linux.clean/drivers/scsi/ppa.h linux.current/drivers/scsi/ppa.h
--- linux.clean/drivers/scsi/ppa.h Thu Sep 14 20:27:05 2000
+++ linux.current/drivers/scsi/
Similar to the imm patch, it's working for me.
John
diff -ru linux.clean/drivers/scsi/ppa.h linux.current/drivers/scsi/ppa.h
--- linux.clean/drivers/scsi/ppa.h Thu Sep 14 20:27:05 2000
+++ linux.current/drivers/scsi/ppa.hThu Nov 16 07:26:38 2000
@@ -170,7 +170,7 @@
Similar to the imm patch, it's working for me.
John
diff -ru linux.clean/drivers/scsi/ppa.h linux.current/drivers/scsi/ppa.h
--- linux.clean/drivers/scsi/ppa.h Thu Sep 14 20:27:05 2000
+++ linux.current/drivers/scsi/ppa.hThu Nov 16 07:26:38 2000
@@ -170,7 +170,7 @@
John Cavan wrote:
Similar to the imm patch, it's working for me.
John
Again... not all screwed up...
patch -ur linux.clean/drivers/scsi/ppa.h linux.current/drivers/scsi/ppa.h
--- linux.clean/drivers/scsi/ppa.h Thu Sep 14 20:27:05 2000
+++ linux.current/drivers/scsi/ppa.hThu Nov
Jens Axboe wrote:
Wouldn't it be more interesting to fix the reason the new error
handling code dies with imm and ppa?
Yes it would... :o) I think I've got it here.
The new error handling code spinlocks the IRQ which cause the lowlevel
parport driver to choke. This patch unlocks, allows the
Tim Waugh wrote:
>
> On Wed, Oct 11, 2000 at 11:01:20PM -0400, John Cavan wrote:
>
> > I don't if this is specifically a problem in the module or with modprobe
> > (2.3.17), but it doesn't happen with any other module. Unfortunately
> > parport_pc.c was as far as I
Tim Waugh wrote:
On Wed, Oct 11, 2000 at 11:01:20PM -0400, John Cavan wrote:
I don't if this is specifically a problem in the module or with modprobe
(2.3.17), but it doesn't happen with any other module. Unfortunately
parport_pc.c was as far as I traced before my work life sucked me
I managed to follow, with a number of debug statements, a problem that
appears to be in parport_pc that causes the following lockup on a dual
P3 500 with modprobe:
NMI Watchdog detected LOCKUP on CPU0, registers:
CPU:0
EIP:0010:[]
EFLAGS: 0086
eax: 0301 ebx: 0216 ecx:
I managed to follow, with a number of debug statements, a problem that
appears to be in parport_pc that causes the following lockup on a dual
P3 500 with modprobe:
NMI Watchdog detected LOCKUP on CPU0, registers:
CPU:0
EIP:0010:[c01deec3]
EFLAGS: 0086
eax: 0301 ebx: 0216
77 matches
Mail list logo
