"Dr. Michael Weller" wrote:
>
> Dear list,
>
> I run a Compaq Proliant 1500 (dual Pentium 75.200) with hardware raid
> (Smart2) with two ethernet cards 3com905 (b or c, I can't tell you right
> now) as a firewall and web/mail virus scanner which (needless to say)
> needs to be up 7d/24h.
>
>
Boszormenyi Zoltan <[EMAIL PROTECTED]> writes:
> The idea is that when it is sure that _only one_ (or some) CPU will access
> a PCI card's mmio area then only that CPU's (those CPUs') MTRRs needs to
> contain an entry for that area.
>
> Although there are (must be) common MTRR entries for the
Igmar Palsenberg <[EMAIL PROTECTED]> writes:
> On Wed, 11 Oct 2000 [EMAIL PROTECTED] wrote:
>
> > Can anyone tell me which tool can open RPM package on Window 95 and where to
>download it?
>
> There isn't, and it serves no use anyway.
I can think of a number of uses for such a tool. For
On Thu, 12 Oct 2000 [EMAIL PROTECTED] wrote:
> hi,
> Is there any way to call system call from a kernel module???
yes, just call it. system calls are just functions (mostly exported and
when otherwise, use sys_call_table[] which is exported, but it won't work
on __mips__) so you can just call
hi,
Is there any way to call system call from a kernel module???
-
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/
"[EMAIL PROTECTED] wrote:"
> * Use PCI DMA by default in IDE is unsafe (must not do so on via
>VPx, x < 3) (Vojtech Pavlik --- requires chipset tuning to be
>enabled according to Andre Hedrick --- we need to turn this on by
>default, if it is safe -- TYT)
Using PCI
On Wed, 11 Oct 2000 [EMAIL PROTECTED] wrote:
> Can anyone tell me which tool can open RPM package on Window 95 and where to
>download it?
There isn't, and it serves no use anyway.
Second, I'm glad there isn't. Saves tons of bugus bug reports.
Igmar
-
To unsubscribe from this
> Note that the sync-rate of target 6, the device I added, has been
> turned down to try to eliminate any hardware problems. Also note
> that the entire drive has been read/written with the BusLogic BIOS
> diagnostic setup utility.
That BIOS setup tool might just use asynchronous I/O for
>10. To Do But Non Showstopper
>
> * Go through as 2.4pre kicks in and figure what we should mark
> obsolete for the final 2.4 (i.e. XT hard disk support?)
> * Union mount (Al Viro)
^^^
Anyone know the status of this? I have seen postings saying it's
likely a
Cort Dougan <[EMAIL PROTECTED]> said:
> Horst von Brand on Wed, Oct 11, 2000 at 11:21:06PM -0400 said:
[...]
> } Oh, come on. The kernel (or glibc for that matter) is not about "inline
> } asm()" at all! That is a tiny fraction of each. The kernel is different in
> } that it has lots of
On 12 Oct 2000, David Wragg wrote:
> Boszormenyi Zoltan <[EMAIL PROTECTED]> writes:
> > I came up with an idea. The MTRRs are per-cpu things.
> > Ingo Molnar's IRQ affinity code helps binding certain
> > IRQ sources to certain CPUs.
>
> They are implemented as per-cpu things but the Intel
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
> On 12 Oct 2000, David Wragg wrote:
> > Ok. I'll wait for feedback from Tigran, and if I don't get anything
> > negative I'll submit to Linus. The 2.2 version of my patch fixes
> > problems for other people, VA Linux have included it in their kernel
> Hi,
> I want to setup RAID.
> I am working on kernel version 2.2.12.
> I am using RAID patches available.
>
> I create a RAID configuring file called
> /etc/raidtab
>
> #mkraid /dev/md0/*md0 is the device I am
> selecting*/
>
> After this when I check
Hi Linus,
This patch converts all initializations of `struct console' objects to new
style initialization constructs.
--- linux-2.4.0-test10-pre1/drivers/char/console.c Fri Aug 11 13:53:24 2000
+++ geert-console-2.4.0-test10-pre1/drivers/char/console.c Thu Oct 12 15:27:04
On Thu, 12 Oct 2000, Jeff Garzik wrote:
> Please test if you have Via hardware, and report any bugs found.
> Feedback, comments, questions, and patches welcome.
Preliminary report after using 1.1.9:
On Module load:
Via 686a audio driver 1.1.9
ac97_codec: AC97 Audio codec, vendor id1: 0x4943,
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
> ok, doing it from the bottom up was fine (didn't lockup) but reaching the
> last (first in your list) entry was refused by mtrr:
>
> mtrr: 0x0,0x1 overlaps existing 0xfeafe000,0x2000
Try the attached patch, and the driver will accept some
> If the problem only impacts User-mode Linux, it's hard for me to
> justify
> hanging the "critical" label on it. However I'm willing to look at
> the
> patch, bless it, and send it on to Linus (who as you know sometimes is
> a
> softy about such things. :-)
I wasn't considering it a
Searching for the cause of some strange corruption
of the MBR I noticed that invalidate_buffers is not
guaranteed to invalidate the buffers - very unfortunate.
(Indeed, bh is removed only when bh->b_count is zero.
This means that one will get disk corruption if one
changes disks while some
[EMAIL PROTECTED] wrote:
> > Sounds like you got caught by the conditional move instruction that is
> > generated for 686. It causes oops on 586, and somewhere in the oops or
> > printk code you hit another cmove. Double fault, kernel hang.
>
> Ah yes, it all comes back to me now :)
> Also
Boszormenyi Zoltan <[EMAIL PROTECTED]> writes:
> I came up with an idea. The MTRRs are per-cpu things.
> Ingo Molnar's IRQ affinity code helps binding certain
> IRQ sources to certain CPUs.
They are implemented as per-cpu things but the Intel manuals say that
all cpus should have the same MTRR
On 12 Oct 2000, David Wragg wrote:
> Ok. I'll wait for feedback from Tigran, and if I don't get anything
> negative I'll submit to Linus. The 2.2 version of my patch fixes
> problems for other people, VA Linux have included it in their kernel
> for a while with no problems that have been
On Thu, 12 Oct 2000, Guest section DW wrote:
> On Wed, Oct 11, 2000 at 05:11:39PM -0400, Richard B. Johnson wrote:
>
> > Linux version 2.2.17
> > I tried to add a new Hard disk. It's s Seagate ST39102LW 8.1 Gb.
>
> Hmm. Your C/H/S multiplies out to 9.1 GB.
> On the other hand, Seagate
Richard Gooch <[EMAIL PROTECTED]> writes:
> David Wragg writes:
> > mtrr.c is broken for machines with >=4GB of memory (or less than 4GB,
> > if the chipset reserves an addresses range below 4GB for PCI).
> >
> > The patch against 2.4.0-test9 to fix this is below.
> >
> > Richard: Is there a
Hi,
Having done a few more reboots I got more info -- one of the eepro100
interfaces is dead only in 4 out 5 cases. So, sometimes, doing ifdown eth0
; ifup eth0 does help.
So, the latest status: all 6G of RAM work fast but the onboard eepro100
interface, often, doesn't work. This starts to look
On Thu, Oct 12, 2000 at 06:26:57AM -0400, Horst von Brand wrote:
> [EMAIL PROTECTED] said:
> > Foolhardy as it may be, people do _use_ the operating system to run
> > important applications and an "application goes down or screws up" can be
> > quite serious.
>
> Yes. But "the kernel screws up
Linus Torvalds wrote:
>
> On Wed, 11 Oct 2000, Dag B wrote:
> >
[snip]
> > Expansion ROM at 1800 [disabled] [size=32M]
> > Capabilities: [dc] Power Management version 1
>
> There's something really wrong going on with your ethernet controller. It
> seems to try to take up
On Thu, 12 Oct 2000 [EMAIL PROTECTED] wrote:
> * DMFE is not SMP safe (Frank Davis patch exists, but hasn't gotten
>much commens yet)
Can anyone tell me where to get this patch? I've got a DM9102A card in a
SMP machine currently on which it can be tested.
David Huen
-
To
On Thu, Oct 12 2000, [EMAIL PROTECTED] wrote:
> 8. Fix Exists But Isnt Merged
> * TLAN nic appears to be adding a timer twice (2.4.0test8pre6, Arjan
>ve de Ven) (Fixed, but patch not sent to Linus yet -- Torben
>Mathiasen)
> * Loading the qlogicfc driver in 2.4.0-test8
On Thu, 12 Oct 2000, Andrea Arcangeli wrote:
> On Wed, Oct 11, 2000 at 03:35:40PM -0200, Marcelo Tosatti wrote:
> > Now I'm not sure if this can be caused by a memory problem.
>
> It can.
Ok, thanks.
Mike, could you try to run memtest86 (you can find it at freshmeat) to
find out if your
Hello,
Ok, I despaired a bit about mtrrs on the Linux side and went into BIOS and
started playing with the cache settings there. The change that fixed the
problem was to disable all "area CXXX-> : cached". Now, I have a really
fast quad Xeon 6G RAM with consistently failing eepro100
interface.
OK, here's an updated Linux 2.4 TODO list. It's actually somewhat up
to date as for test10-pre1, but there a bunch of test10-pre1 bug reports
that defied easy categoricalization (i.e., real bug vs. PEBCAK) so I've
left the offical page as saying that it's hopefully up-to-date as of
pre9.
On Thu, 12 Oct 2000 12:56:09 +0100 (BST),
Tigran Aivazian <[EMAIL PROTECTED]> wrote:
>one correction -- it was "down and up the interface" that did the trick
>and not deleting the 64M mtrr entry. I.e. the eepro100 problem is better
>formulated as "when highmem is enabled one or both eepro100
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
> On Thu, 12 Oct 2000, Tigran Aivazian wrote:
>
> > On Wed, 11 Oct 2000, Linus Torvalds wrote:
> > > What happens if MTRR support is entirely disabled?
> >
> > If MTRR support is disabled then both eepro100 interfaces work fine but
> > the system is
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
> On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
>
> > echo "base=0 size=0x1 type=write-back" >/proc/mtrr
> > echo "base=0x1 size=0x8000 type=write-back" >/proc/mtrr
> > echo "base=0xfe00 size=0x80 type=write-combining"
On Thu, Oct 12, 2000 at 03:58:21AM -0700, Amit D Chaudhary wrote:
> Hi,
>
> When trying to create a patch with linux 2.2.17 sources, I found the
> following files to be of size 0 in linux-2.2.17.tar.gz.
> linux/include/linux/dasd.h
> linux/include/linux/coda_opstats.h
>
> Since the file is
On Thu, 12 Oct 2000, Ingo Molnar wrote:
> [...] pgd_clear() should stay a 64-bit operation [...]
even this isnt strictly necessery - pgds and pmds are allocated in 'low
memory', and thus a simple 32-bit write to the lower 32 bits of the pgd
entry is enough to clear a PAE pgd. But it still must
Hi,
When trying to create a patch with linux 2.2.17 sources, I found the
following files to be of size 0 in linux-2.2.17.tar.gz.
linux/include/linux/dasd.h
linux/include/linux/coda_opstats.h
Since the file is the most latest in the kernel/v2.2 directory, thought
should point this out.
Amit
Hi,
This patch will make the sx card work again. Somehow the added line was
removed in the last patch.
Patrick
diff -u -r --new-file linux-2.2.18-15.clean/drivers/char/sx.c
linux-2.2.18-15.sx/drivers/char/sx.c
--- linux-2.2.18-15.clean/drivers/char/sx.c Thu Oct 12 10:39:33 2000
Michal Jaegermann writes:
> > Somewhere floating around there is a perl version of rpm2cpio.
>
> This is what I wrote one day a long time ago:
>
> #!/usr/bin/perl -w
> use strict;
>
> my ($buffer, $pos, $gzmagic);
> $gzmagic = "\037\213";
> open OUT, "| gunzip" or die "cannot find gunzip;
[EMAIL PROTECTED] said:
> On Wed, Oct 11, 2000 at 11:21:06PM -0400, Horst von Brand wrote:
> > also moves forward a lot faster than glibc, and grows a lot. A bug in glibc
> > means an application goes down or screws up, a bug in the kernel can mean
> > masive data loss in no time at all.
>
On Thu, 12 Oct 2000, Keith Owens wrote:
> Sounds like you got caught by the conditional move instruction that is
> generated for 686. It causes oops on 586, and somewhere in the oops or
> printk code you hit another cmove. Double fault, kernel hang.
Ah yes, it all comes back to me now :)
Also
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
> > On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
> >
> > > echo "base=0 size=0x1 type=write-back" >/proc/mtrr
>
> this line immediately locks up the machine. But I want to understand where
We just shared an experience. :-( This is what I
On Thu, Oct 12, 2000 at 12:12:19PM +0200, Boszormenyi Zoltan wrote:
> I came up with an idea. The MTRRs are per-cpu things.
> Ingo Molnar's IRQ affinity code helps binding certain
> IRQ sources to certain CPUs.
>
> What if the MTRR driver allows per-CPU settings, maybe only on
> uncached areas?
I came up with an idea. The MTRRs are per-cpu things.
Ingo Molnar's IRQ affinity code helps binding certain
IRQ sources to certain CPUs.
What if the MTRR driver allows per-CPU settings, maybe only on
uncached areas? Of course the real memory should be cached in
every CPU to avoid slowdowns. So
On Thu, 12 Oct 2000 00:24:51 +0200, Guest section DW blurted forth:
> On Wed, Oct 11, 2000 at 05:11:39PM -0400, Richard B. Johnson wrote:
>
> > In the BIOS setup of the BusLogic adapter, I was able to format
> > and verify the disk with no problems whatsoever.
> >
> > fdisk seemed to
> On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
>
> > echo "base=0 size=0x1 type=write-back" >/proc/mtrr
this line immediately locks up the machine. But I want to understand where
did you get base=0 and size=0x1 from? Shouldn't it be
base=0x10 and size=0xfccf according
On Thu, 12 Oct 2000, David S. Miller wrote:
>clear neither user-space pgds, nor user-space pmds in PAE mode
>
> Eh?
>
> munmap() --> clear_page_tables() --> free_one_pgd() --> pgd_clear
you are right, i was focused too much on the swapping case. I dont think
munmap() is a problem in the
On Thu, 12 Oct 2000 10:45:11 +0100 (BST),
Tigran Aivazian <[EMAIL PROTECTED]> wrote:
>It would be nice if /proc/mtrr showed eip of
>the caller who set up the entry :)
How? If you compile with egcs-2.91.66 without frame pointers on ix86 then
__builtin_return_address() yields garbage. Does
On Wed, 11 Oct 2000, Nathan Paul Simons wrote:
> On Wed, Oct 11, 2000 at 10:55:17PM +0100, Alan Cox wrote:
> > Hardly. In fact the idea of distributing a different compiler for kernels
> > comes from debian and the kgcc naming convention from Conectiva.
>
> What different compiler? If
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
> echo "base=0 size=0x1 type=write-back" >/proc/mtrr
> echo "base=0x1 size=0x8000 type=write-back" >/proc/mtrr
> echo "base=0xfe00 size=0x80 type=write-combining" >/proc/mtrr
> echo "base=0xfde0 size=0x10
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
> suggestions?
I looked at what you sent (e820 map and lspci output) and came up with
this.
Cover 6 GB with write-back, the VGA memory with write-combining, and
all the other PCI areas as uncached.
echo "base=0 size=0x1 type=write-back"
[EMAIL PROTECTED] said:
> The genuine Linux kernel distribution contains its own documentation
> on how to build and configure it.
Indeed it does. Documentation/Changes says:
GCC
---
You will need at least gcc 2.7.2 to compile the kernel. You currently
have several options for gcc-derived
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
> On Wed, 11 Oct 2000, Linus Torvalds wrote:
> > What happens if MTRR support is entirely disabled?
>
> If MTRR support is disabled then both eepro100 interfaces work fine but
> the system is still 40x slower. This is the entire bootlog of
>
Date:Thu, 12 Oct 2000 10:13:48 +0200 (CEST)
From: Ingo Molnar <[EMAIL PROTECTED]>
the PAE pgd 'anomaly' should not affect this case, because we never
clear neither user-space pgds, nor user-space pmds in PAE mode
Eh?
munmap() --> clear_page_tables() --> free_one_pgd() -->
[Dan Aloni]
> --- linux/drivers/sound/cs46xx.c Sat Oct 7 11:49:18 2000
> +++ linux/drivers/sound/cs46xx.c Wed Oct 11 07:41:02 2000
[...]
> +#define DEBUG
> +
Note that for trivial, temporary cases like this it may be simpler to
use a compiler flag:
make modules
Hello, I'm a new entry in this kernel mailing list.
I'm working on udp functions (those in ipv4/udp.c) and I'm focusing on
"udp_sendmsg(..)" and "udp_recvmsg". I'm trying to understand what is the
duty, what these next functions(used by udp_sendmsg and/or udp_recvmsg) really
do:
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
> Look at the e820 map in the boot log, mark those areas
> as write-back and tell me what happens.
Here is e820 map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @ 0009fc00 (reserved)
BIOS-e820:
Hi,
someone looked at the XEON errata already, perhaps one can find the problem there?
Just in case.
G16 seems to have something to do with it ... But there are others also. I´ll boot
linux and look into the sources ...
Cheers Markus
Tigran Aivazian wrote:
> On Wed, 11 Oct 2000, Linus
> had been resolved. On my machine that is not true (dual ppro with
> supermicro mobo). I have a 3c509 and a netgear fa 310tx. With the above
> line in my lilo.conf the 3com should get eth1, but doesn't. Wasn't this
> labeled as fixed?
ether= isnt applied to PCI devices . They don't need io
The Thu, Oct 12, 2000 at 11:02:50AM +0530, [EMAIL PROTECTED] wrote :
> once i have got the pci_dev structure( by calling pci_find*), do i
> explicitly need to call ioremap for remapping mmio.
> i think pci_enable_device does this. correct me if i am wrong..
ioremap does not only remap mmio but
Hi!
I reported this BUG on a few days ago but got no response - happens
on UP with only 32M ram, too. (see below). Also note the second
BUG at vmscan.c:538 which I believe never saw reported again.
Richard.
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> On Wed, 11 Oct 2000, Rik van Riel wrote:
> I don't think I understand your point. Are you saying that gcc cannot be
> expected to keep up with the ways in which the kernel uses it? My argument
> is that providing a compiler that actually regresses (old version compiles
> kernel, redhat 7.0 included one does not) is not a good choice.
> What different compiler? If you're talking about the kernel-package
> package of Debian, that's only scripts to generate a Debian kernel package
> from custom source.
The gcc272 package
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Thu, 12 Oct 2000, Matti Aarnio wrote:
> > CPU0: Intel Pentium III (Cascades) stepping 01
> > CPU1: Intel Pentium III (Cascades) stepping 01
> > CPU2: Intel Pentium III (Cascades) stepping 01
> > CPU3: Intel Pentium III (Cascades) stepping 01
> > Total of 4 processors activated (5606.60
On Thu, Oct 12, 2000 at 09:21:00AM +0100, Tigran Aivazian wrote:
> If MTRR support is disabled then both eepro100 interfaces work fine but
> the system is still 40x slower. This is the entire bootlog of
> 2.4.0-test10-pre1 + lspci-vvx + /proc/interrupts + /proc/iomem + ifconfig
> output
>
> Two
On Wed, 11 Oct 2000, Linus Torvalds wrote:
> What happens if MTRR support is entirely disabled?
If MTRR support is disabled then both eepro100 interfaces work fine but
the system is still 40x slower. This is the entire bootlog of
2.4.0-test10-pre1 + lspci-vvx + /proc/interrupts + /proc/iomem +
On Wed, 11 Oct 2000, Linus Torvalds wrote:
> (Instead of doing an atomic 64-bit memory write, we would be doing the
> atomic "pte_xchg_clear()" followed by two _non_atomic 32-bit writes where
> the second write would set the present bit. Although maybe the erratum
> about the PAE pgd entry not
> " " == johna <[EMAIL PROTECTED]> writes:
> Rootfs works fine, but attempting to mount other directories
> via nfs causes problems. Error messages like : RPC: sendmsg
> returned error 101, nfs warning: mount version is older than
The 'sendmsg' error means you're trying to
[EMAIL PROTECTED] wrote:
> Maybe we should have the kernel print the CPU information it was
> compiled with before it does anything else. It'll make it easier to
> catch what may be a fairly common set of PEBCAK case
I was told that "printing" anything was out of the question, as the
On Thu, 12 Oct 2000, Benjamin C.R. LaHaise wrote:
>
> Note the fragment above those portions of the patch where the
> pte_xchg_clear is done on the page table: this results in a page fault
> for any other cpu that looks at the pte while it is unavailable.
Ok, I see..
Hmm.. That's a
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> Hi Zoltan,
>
> I have tried your patch and although it works:
>
> # cat /proc/mtrr
> reg00: base=0x ( 0MB), size=4096MB: write-back, count=1
> reg01: base=0x001 (4096MB), size=2048MB: write-back,
> count=1
> reg02:
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
Hi Zoltan,
I have tried your patch and although it works:
# cat /proc/mtrr
reg00: base=0x ( 0MB), size=4096MB: write-back, count=1
reg01: base=0x001 (4096MB), size=2048MB: write-back,
count=1
reg02: base=0xfc00
On Thu, 12 Oct 2000, Benjamin C.R. LaHaise wrote:
Note the fragment above those portions of the patch where the
pte_xchg_clear is done on the page table: this results in a page fault
for any other cpu that looks at the pte while it is unavailable.
Ok, I see..
Hmm.. That's a singularly
[EMAIL PROTECTED] wrote:
Maybe we should have the kernel print the CPU information it was
compiled with before it does anything else. It'll make it easier to
catch what may be a fairly common set of PEBCAK case
I was told that "printing" anything was out of the question, as the
" " == johna [EMAIL PROTECTED] writes:
Rootfs works fine, but attempting to mount other directories
via nfs causes problems. Error messages like : RPC: sendmsg
returned error 101, nfs warning: mount version is older than
The 'sendmsg' error means you're trying to mount with
On Wed, 11 Oct 2000, Linus Torvalds wrote:
(Instead of doing an atomic 64-bit memory write, we would be doing the
atomic "pte_xchg_clear()" followed by two _non_atomic 32-bit writes where
the second write would set the present bit. Although maybe the erratum
about the PAE pgd entry not
On Wed, 11 Oct 2000, Linus Torvalds wrote:
What happens if MTRR support is entirely disabled?
If MTRR support is disabled then both eepro100 interfaces work fine but
the system is still 40x slower. This is the entire bootlog of
2.4.0-test10-pre1 + lspci-vvx + /proc/interrupts + /proc/iomem +
On Thu, Oct 12, 2000 at 09:21:00AM +0100, Tigran Aivazian wrote:
If MTRR support is disabled then both eepro100 interfaces work fine but
the system is still 40x slower. This is the entire bootlog of
2.4.0-test10-pre1 + lspci-vvx + /proc/interrupts + /proc/iomem + ifconfig
output
Two
On Thu, 12 Oct 2000, Matti Aarnio wrote:
CPU0: Intel Pentium III (Cascades) stepping 01
CPU1: Intel Pentium III (Cascades) stepping 01
CPU2: Intel Pentium III (Cascades) stepping 01
CPU3: Intel Pentium III (Cascades) stepping 01
Total of 4 processors activated (5606.60 BogoMIPS).
What different compiler? If you're talking about the kernel-package
package of Debian, that's only scripts to generate a Debian kernel package
from custom source.
The gcc272 package
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
I don't think I understand your point. Are you saying that gcc cannot be
expected to keep up with the ways in which the kernel uses it? My argument
is that providing a compiler that actually regresses (old version compiles
kernel, redhat 7.0 included one does not) is not a good choice.
The
Hi!
I reported this BUG on a few days ago but got no response - happens
on UP with only 32M ram, too. (see below). Also note the second
BUG at vmscan.c:538 which I believe never saw reported again.
Richard.
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
On Wed, 11 Oct 2000, Rik van Riel wrote:
The Thu, Oct 12, 2000 at 11:02:50AM +0530, [EMAIL PROTECTED] wrote :
once i have got the pci_dev structure( by calling pci_find*), do i
explicitly need to call ioremap for remapping mmio.
i think pci_enable_device does this. correct me if i am wrong..
ioremap does not only remap mmio but
had been resolved. On my machine that is not true (dual ppro with
supermicro mobo). I have a 3c509 and a netgear fa 310tx. With the above
line in my lilo.conf the 3com should get eth1, but doesn't. Wasn't this
labeled as fixed?
ether= isnt applied to PCI devices . They don't need io and
Hi,
someone looked at the XEON errata already, perhaps one can find the problem there?
Just in case.
G16 seems to have something to do with it ... But there are others also. I´ll boot
linux and look into the sources ...
Cheers Markus
Tigran Aivazian wrote:
On Wed, 11 Oct 2000, Linus
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
Look at the e820 map in the boot log, mark those areas
as write-back and tell me what happens.
Here is e820 map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @ 0009fc00 (reserved)
BIOS-e820:
Hello, I'm a new entry in this kernel mailing list.
I'm working on udp functions (those in ipv4/udp.c) and I'm focusing on
"udp_sendmsg(..)" and "udp_recvmsg". I'm trying to understand what is the
duty, what these next functions(used by udp_sendmsg and/or udp_recvmsg) really
do:
[Dan Aloni]
--- linux/drivers/sound/cs46xx.c Sat Oct 7 11:49:18 2000
+++ linux/drivers/sound/cs46xx.c Wed Oct 11 07:41:02 2000
[...]
+#define DEBUG
+
Note that for trivial, temporary cases like this it may be simpler to
use a compiler flag:
make modules CFLAGS_cs46xx.o=-DDEBUG
Date:Thu, 12 Oct 2000 10:13:48 +0200 (CEST)
From: Ingo Molnar [EMAIL PROTECTED]
the PAE pgd 'anomaly' should not affect this case, because we never
clear neither user-space pgds, nor user-space pmds in PAE mode
Eh?
munmap() -- clear_page_tables() -- free_one_pgd() --
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
On Wed, 11 Oct 2000, Linus Torvalds wrote:
What happens if MTRR support is entirely disabled?
If MTRR support is disabled then both eepro100 interfaces work fine but
the system is still 40x slower. This is the entire bootlog of
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
suggestions?
I looked at what you sent (e820 map and lspci output) and came up with
this.
Cover 6 GB with write-back, the VGA memory with write-combining, and
all the other PCI areas as uncached.
echo "base=0 size=0x1 type=write-back"
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
echo "base=0 size=0x1 type=write-back" /proc/mtrr
echo "base=0x1 size=0x8000 type=write-back" /proc/mtrr
echo "base=0xfe00 size=0x80 type=write-combining" /proc/mtrr
echo "base=0xfde0 size=0x10 type=uncached"
On Wed, 11 Oct 2000, Nathan Paul Simons wrote:
On Wed, Oct 11, 2000 at 10:55:17PM +0100, Alan Cox wrote:
Hardly. In fact the idea of distributing a different compiler for kernels
comes from debian and the kgcc naming convention from Conectiva.
What different compiler? If you're
On Thu, 12 Oct 2000 10:45:11 +0100 (BST),
Tigran Aivazian [EMAIL PROTECTED] wrote:
It would be nice if /proc/mtrr showed eip of
the caller who set up the entry :)
How? If you compile with egcs-2.91.66 without frame pointers on ix86 then
__builtin_return_address() yields garbage. Does anybody
On Thu, 12 Oct 2000, David S. Miller wrote:
clear neither user-space pgds, nor user-space pmds in PAE mode
Eh?
munmap() -- clear_page_tables() -- free_one_pgd() -- pgd_clear
you are right, i was focused too much on the swapping case. I dont think
munmap() is a problem in the PAE
On Thu, 12 Oct 2000 00:24:51 +0200, Guest section DW blurted forth:
On Wed, Oct 11, 2000 at 05:11:39PM -0400, Richard B. Johnson wrote:
In the BIOS setup of the BusLogic adapter, I was able to format
and verify the disk with no problems whatsoever.
fdisk seemed to work okay. I
I came up with an idea. The MTRRs are per-cpu things.
Ingo Molnar's IRQ affinity code helps binding certain
IRQ sources to certain CPUs.
What if the MTRR driver allows per-CPU settings, maybe only on
uncached areas? Of course the real memory should be cached in
every CPU to avoid slowdowns. So
On Thu, Oct 12, 2000 at 12:12:19PM +0200, Boszormenyi Zoltan wrote:
I came up with an idea. The MTRRs are per-cpu things.
Ingo Molnar's IRQ affinity code helps binding certain
IRQ sources to certain CPUs.
What if the MTRR driver allows per-CPU settings, maybe only on
uncached areas? Of
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
echo "base=0 size=0x1 type=write-back" /proc/mtrr
this line immediately locks up the machine. But I want to understand where
We just shared an experience. :-( This is what I wrote some
On Thu, 12 Oct 2000, Keith Owens wrote:
Sounds like you got caught by the conditional move instruction that is
generated for 686. It causes oops on 586, and somewhere in the oops or
printk code you hit another cmove. Double fault, kernel hang.
Ah yes, it all comes back to me now :)
Also
101 - 200 of 336 matches
Mail list logo
