On Thu, 26 Oct 2000, Brian Gerst wrote:
> "Richard B. Johnson" wrote:
> > Stand-alone, it can't do anything useful. However, if it generates
> > a page-fault due to the read or write, the page-fault handler could
> > do "something". Currently, the fault it fatal, probably because
> > the passed
Then shouldn't it be removed?
Craig Schlenter wrote:
> On Thu, Oct 26, 2000 at 07:25:34AM -0600, Steven Cole wrote:
> > Stephen Clark wrote:
> > >
> > >I recently installed 2.4test9pre5 and noticed that when I cat
> > >/proc/meminfo the value for shared memory is 0. Am I the only one that
> >
Richard B. Johnson wrote:
> > And here is the broken routine:
> >
> > 03f4 :
[...]
> This is not good code. It does the following:
>
> o Gets a parameter off the stack and puts into eax (a pointer).
> o Put the value 1 into ecx.
> o Take a byte from the pointed-to location and
"Richard B. Johnson" wrote:
> Stand-alone, it can't do anything useful. However, if it generates
> a page-fault due to the read or write, the page-fault handler could
> do "something". Currently, the fault it fatal, probably because
> the passed pointer is invalid.
The write-protect test code is
On Thu, Oct 26, 2000 at 02:57:30PM +0300, Pasi Kärkkäinen wrote:
>
> On Thu, 26 Oct 2000, Andrew Morton wrote:
>
> > "Pasi Kärkkäinen" wrote:
> >
> > gcc-2.7.2.3 miscompiles kernel/module.c and it has been decided that
> > this will not be worked around. The new baseline gcc release for x86
>
Mircea Damian wrote:
>
> Hello,
>
> I'm unable to boot kernel 2.4.0-test10-pre5 on a:
Upgrade GCC to 2.91.66 (aka egcs-1.1.2)
--
Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
++ 26/10/00 16:11 +0200 - Vojtech Pavlik:
> On Thu, Oct 26, 2000 at 04:13:51PM +0200, Yoann Vandoorselaere wrote:
>
> > > > > I've found a bug in my VIA SuperSouth (vt82c686a) chip (ISA bridge
> > > > > revision 0x12, silicon rev CD) on my FIC VA-503A rev 1.2:
> > > > >
> > > > > When there is
On Thu, 26 Oct 2000, Mircea Damian wrote:
>
>
> Hello,
>
> I'm unable to boot kernel 2.4.0-test10-pre5 on a:
>
>
> And here is the broken routine:
>
> 03f4 :
> 3f4: 8b 44 24 04 movl 0x4(%esp,1),%eax
> 3f8: b9 01 00 00 00 movl $0x1,%ecx
> 3fd: 8a 10
On Thu, Oct 26, 2000 at 04:13:51PM +0200, Yoann Vandoorselaere wrote:
> > > > I've found a bug in my VIA SuperSouth (vt82c686a) chip (ISA bridge
> > > > revision 0x12, silicon rev CD) on my FIC VA-503A rev 1.2:
> > > >
> > > > When there is heavy disk activity (several tars running concurrently
Vojtech Pavlik <[EMAIL PROTECTED]> writes:
> On Thu, Oct 26, 2000 at 03:58:21PM +0200, Yoann Vandoorselaere wrote:
>
> > > I've found a bug in my VIA SuperSouth (vt82c686a) chip (ISA bridge
> > > revision 0x12, silicon rev CD) on my FIC VA-503A rev 1.2:
> > >
> > > When there is heavy disk
On Thu, Oct 26, 2000 at 03:58:21PM +0200, Yoann Vandoorselaere wrote:
> > I've found a bug in my VIA SuperSouth (vt82c686a) chip (ISA bridge
> > revision 0x12, silicon rev CD) on my FIC VA-503A rev 1.2:
> >
> > When there is heavy disk activity (several tars running concurrently on
> > UDMA66
On Thu, 26 Oct 2000 15:39:59 +0200 (CEST),
Christian Reiser <[EMAIL PROTECTED]> wrote:
> kernel BUG at slab.c:804!
>Code: 0f 0b 83 c4 0c 8d b4 26 00 00 00 00 8b 1b 81 fb bc 23 26 c0
>... hope it could help ...
Almost completely useless until you follow the procedures in
linux/REPORTING-BUGS.
On Thu, 26 Oct 2000 09:17:49 -0400 (EDT),
"Richard B. Johnson" <[EMAIL PROTECTED]> wrote:
>On Thu, 26 Oct 2000, Albert D. Cahalan wrote:
>> I doubt this is true on most modern processors. On the Pentium
>> and above, large pages are used for the kernel. The PowerPC port
> ^^^
Hello,
I'm unable to boot kernel 2.4.0-test10-pre5 on a:
root@cyrix:/usr/src/linux/arch/i386/mm# cat /proc/cpuinfo
processor : 0
vendor_id : CyrixInstead
cpu family : 6
model : 2
model name : 6x86MX 2.5x Core/Bus Clock
stepping: 7
cpu MHz :
On Thu, 26 Oct 2000 23:52:02 +1100,
Andrew Morton <[EMAIL PROTECTED]> wrote:
>[ You could put a show_stack(0) in here, but I believe ksymoops
> doesn't understand show_stack() output ].
It does, and extracts the "Call Trace:" data. The stack is not printed
by ksymoops because it does not have
Vojtech Pavlik <[EMAIL PROTECTED]> writes:
> Hi!
>
> I've found a bug in my VIA SuperSouth (vt82c686a) chip (ISA bridge
> revision 0x12, silicon rev CD) on my FIC VA-503A rev 1.2:
>
> When there is heavy disk activity (several tars running concurrently on
> UDMA66 drive, or tar'ing from one
Hi Linus,
in the current kernel versions we have a lot of new list-style makefiles
(find -name Makefile | xargs grep -l obj- | wc -l gives 48 in -pre5) and
the number increases all the time.
This patch adds a new makefile ($(TOPDIR])/Makefile.inc) that can be
included by the list-style
On Thu, Oct 26, 2000 at 07:25:34AM -0600, Steven Cole wrote:
> Stephen Clark wrote:
> >
> >I recently installed 2.4test9pre5 and noticed that when I cat
> >/proc/meminfo the value for shared memory is 0. Am I the only one that
> >is seeing this.
>
> I'm seeing this also for 2.4.0-test10-pre5.
Hi,
i hope i am right here, and this problem wasn't mailed a thousand times
before - but it is not older than 3 days (2.4.0-test10-pre5 is'nt
older...)
I am playing around with usb and usb-storage, and then i wanted to reload
the usb-ohci-module, during the insmod i got this error:
Oct 26
Hi!
I've found a bug in my VIA SuperSouth (vt82c686a) chip (ISA bridge
revision 0x12, silicon rev CD) on my FIC VA-503A rev 1.2:
When there is heavy disk activity (several tars running concurrently on
UDMA66 drive, or tar'ing from one UDMA66 drive to another over two
channels), the system time,
Stephen Clark wrote:
>
>I recently installed 2.4test9pre5 and noticed that when I cat
>/proc/meminfo the value for shared memory is 0. Am I the only one that
>is seeing this.
I'm seeing this also for 2.4.0-test10-pre5. Here is /proc/meminfo followed
by the same for a 2.2 machine running the
On Thu, 26 Oct 2000, Albert D. Cahalan wrote:
> Richard B. Johnson writes:
> > On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote:
>
> > o Once installed, a kernel module is every bit as "efficient"
> > as some driver linked into the kernel at build-time. Of course
>
> I doubt this is true
Hi,
I got the following OOPS while doing some heavy compilations (make -j4) on dual SMP
P-III,
2.4.0-test10-pre5 and reiserfs 3.6.18 for 2.4.0-test9.
It looks like page without page->mapping has been passed to
block_read_full_page().
Unable to handle kernel NULL pointer dereference at
"Pasi Kärkkäinen" wrote:
>
> Ok. I recompiled the kernel and modules with 2.95.2 and it still seems not
> to work. This is from syslog:
>
> __alloc_pages: 2-order allocation failed.
> __alloc_pages: 2-order allocation failed.
> __alloc_pages: 5-order allocation failed.
> __alloc_pages: 4-order
You can use an initial ramdisk (initrd), and specify the load order of your
drivers (driver for internal disk first, qlogic driver second). That
removes the dependency on the static link order in hosts.c.
Thanks,
Matt
-Original Message-
From: Klaus Naumann [mailto:[EMAIL PROTECTED]]
I recently installed 2.4test9pre5 and noticed that when I cat
/proc/meminfo the value for shared memory is 0. Am I the only one that
is seeing this.
Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ
On Thu, 26 Oct 2000 14:22:54 +0200,
Klaus Naumann <[EMAIL PROTECTED]> wrote:
>The problem with that is that on boot up (for lilo) the internal disk
>is disk number one. But when I'm in the system and want to install lilo
>it's disk number two - that's what lilo is complaining about on boot up.
>
>Yes, it will break on any machine with multiple primary PCI busses, because
>the registers assigning bus number ranges to primary busses are chipset
>specific.
>
>In 2.5, I'd like to rewrite the resource + bus number assignment code to be
>able to re-layout the busses and resources even on
On Wed, 25 Oct 2000, Anil kumar wrote:
> Hi,
> After I create a RAID setup on the drives,The
> superblock will be generated at the end of the drives.
> If I move these drives to other linux system, will
> this
> system recognise the RAID setup without reconfiguring
> the Linux ?
If the CHS /
Byeong-ryeol Kim wrote:
>
> On Thu, 26 Oct 2000, Klaus Naumann wrote:
>
> > I was having some little trouble with the QLOGIC Fibre Channel SCSI
> > cards.
> > The issue is, that I have a box with an internal SCSI controller/disk
> > and a QLOGIC card which is connected to an external RAID. The
On Thu, 26 Oct 2000, Andrew Morton wrote:
> "Pasi Kärkkäinen" wrote:
> >
> > I'm using 2.4.0-test10-pre5 on a PIII (compiled with gcc 2.7.2.3) and
> > ...
>
> gcc-2.7.2.3 miscompiles kernel/module.c and it has been decided that
> this will not be worked around. The new baseline gcc release
> Perhaps syslogd is not giving higher priority to local messages; if it
> did, maybe it could recover from the deadlock. But this would not be
> a reliable solution; the only reliable solution is for syslogd to be
> independent of any processes which need to talk to it.
In that case, don't do
> No, I didn't say they "should" be dropped but merely that dropping them
> would fix your problem. Personally, I'd look closely at your setup to
> determine exactly why this has become a problem. named is being blocked
> on writing to /dev/log. This should only happen if there is sufficient
On Thu, 26 Oct 2000, Klaus Naumann wrote:
> I was having some little trouble with the QLOGIC Fibre Channel SCSI
> cards.
> The issue is, that I have a box with an internal SCSI controller/disk
> and a QLOGIC card which is connected to an external RAID. The probelm
> is, that the internal disk
Hi,
I was having some little trouble with the QLOGIC Fibre Channel SCSI
cards.
The issue is, that I have a box with an internal SCSI controller/disk
and
a QLOGIC card which is connected to an external RAID. The probelm is,
that the internal disk is my root disk but is the second in the chain
Hi,
This bug was triggered by trying ctrl-alt-del for reboot in
test10-pre5. It appears to show schedule() getting stuck in
a loop with the stack growing unbounded.
Unfortunately, the module list and symbols are not exposed.
I don't know what had been unloaded before the bug
triggered. The
On 23 Oct 2000, Patrick J. LoPresti wrote:
> Jesse Pollard <[EMAIL PROTECTED]> writes:
>
> > Don't configure syslogd to do reverse lookups.
>
> Our syslogd has no option to disable the reverse lookups.
Requires a recompile.
> > You can NEVER guarantee that the reverse lookup will succeed,
> Ulrich Drepper <[EMAIL PROTECTED]> writes:
>
> > If anything has to be changed it's (as suggested) the configuration
> > or even the implementation of syslogd. Make it robust.
>
> OK, but my current syslogd only listens to /dev/log as a SOCK_DGRAM.
> If I wanted reliable syslogging, it
"Pasi Kärkkäinen" wrote:
>
> I'm using 2.4.0-test10-pre5 on a PIII (compiled with gcc 2.7.2.3) and
> ...
gcc-2.7.2.3 miscompiles kernel/module.c and it has been decided that
this will not be worked around. The new baseline gcc release for x86
is gcc-2.91.66 (otherwise known as egcs-1.1.2).
-
> You obviously don't understand the communication channel being used.
> "/dev/log" is a UNIX DOMAIN SOCKET -- AF_UNIX. Datagrams are unreliable
> for _IP_ (AF_INET). Traffic on an AF_UNIX socket is always reliable.
>
> Ok, smarty, go change the syslogd source to open /dev/log as SOCK_STREAM
On Wed, Oct 25, 2000 at 05:59:39PM -0400, Jeff Garzik wrote:
> It may work, but the bridge secondary/subordinate numbers look wrong.
>
No, these numbers look correct for me. Read comment in drivers/pci/pci.c:
if (!is_cardbus) {
/* Now we can scan all subordinate buses...
On 23 Oct 2000, Patrick J. LoPresti wrote:
> If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3,
> kernel 2.2.x), within a few minutes you will find your entire machine
> grinds to a halt. For example, nobody can log in.
>
> This happens because once the /dev/log buffer fills,
Jonathan Lemon wrote:
>
> Also, consider the following scenario for the proposed get_event():
>
>1. packet arrives, queues an event.
>2. user retrieves event.
>3. second packet arrives, queues event again.
>4. user reads() all data.
>
> Now, next time around the loop, we get a
Hi Jeff!
> First, some definitions:
> downstream - away from the host processor
> primary - number of the PCI bus closer to the host processor
> secondary - number of the PCI bus on the downstream side of the PCI
> bridge
> subordinate - number of the highest-numbered bus on the downstream side
Anil kumar wrote:
>
> Hi,
> After I create a RAID setup on the drives,The
> superblock will be generated at the end of the drives.
> If I move these drives to other linux system, will
> this
> system recognise the RAID setup without reconfiguring
> the Linux ?
>
Yes - if that other linux
I'm using 2.4.0-test10-pre5 on a PIII (compiled with gcc 2.7.2.3) and
having problems with usb. I'm able to load the usb-driver (usb-uhci) and
then the driver for my usb-webcam (cpia_usb). The webcam works fine for
something like 20 minutes. After that I start to get this kind of messages
to the
Dan Kegel <[EMAIL PROTECTED]> writes:
> It's harder to write correct programs that use edge-triggered events.
Huh? The race between when an event is reported, and when you take action
on it effectively means all events are edge triggered.
So making the interface clearly edge triggered seems
I am not sure if this message has to do with kernel development or not. All
I know is that most the people on this list are nothing short of being
genius'. My question is, on my computer I get an error when booting on my
/hda5 partition and in order to bootup I need to enter root user mode and
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Followup to: <[EMAIL PROTECTED]>
> By author:Martin Mares <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > This doesn't make much sense to me: Why don't we just reinitialize the timings
> > as we do when programming the chipset
> * David Schwartz <[EMAIL PROTECTED]> [001025 15:35] wrote:
> >
> > If a programmer does not ever wish to block under any
> circumstances, it's
> > his obligation to communicate this desire to the
> implementation. Otherwise,
> > the implementation can block if it doesn't have data or an
> error
I've updated the sysrq event registration patches that I've got at:
http://bama.ua.edu/~dunna001/sysrq-register/
The update:
a) reworks the exposed table functions to be much cleaner, allowing for
flexible and safe operation table manipulation.
b) ports the patch up to the test10-pre5
[ ... blocking read after signalling that data is available ... ]
> Yes, and as you mentioned, it was _bugs_ in the operating system
> that did this.
I think it's reasonable for the OS to discard, for example,
connection requests which are not serviced in a reasonable
time window. Likewise,
[ ... blocking read after signalling that data is available ... ]
Yes, and as you mentioned, it was _bugs_ in the operating system
that did this.
I think it's reasonable for the OS to discard, for example,
connection requests which are not serviced in a reasonable
time window. Likewise, it's
I've updated the sysrq event registration patches that I've got at:
http://bama.ua.edu/~dunna001/sysrq-register/
The update:
a) reworks the exposed table functions to be much cleaner, allowing for
flexible and safe operation table manipulation.
b) ports the patch up to the test10-pre5
* David Schwartz [EMAIL PROTECTED] [001025 15:35] wrote:
If a programmer does not ever wish to block under any
circumstances, it's
his obligation to communicate this desire to the
implementation. Otherwise,
the implementation can block if it doesn't have data or an
error available
"H. Peter Anvin" [EMAIL PROTECTED] writes:
Followup to: [EMAIL PROTECTED]
By author:Martin Mares [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
This doesn't make much sense to me: Why don't we just reinitialize the timings
as we do when programming the chipset instead of
I am not sure if this message has to do with kernel development or not. All
I know is that most the people on this list are nothing short of being
genius'. My question is, on my computer I get an error when booting on my
/hda5 partition and in order to bootup I need to enter root user mode and
Dan Kegel [EMAIL PROTECTED] writes:
It's harder to write correct programs that use edge-triggered events.
Huh? The race between when an event is reported, and when you take action
on it effectively means all events are edge triggered.
So making the interface clearly edge triggered seems to
I'm using 2.4.0-test10-pre5 on a PIII (compiled with gcc 2.7.2.3) and
having problems with usb. I'm able to load the usb-driver (usb-uhci) and
then the driver for my usb-webcam (cpia_usb). The webcam works fine for
something like 20 minutes. After that I start to get this kind of messages
to the
Anil kumar wrote:
Hi,
After I create a RAID setup on the drives,The
superblock will be generated at the end of the drives.
If I move these drives to other linux system, will
this
system recognise the RAID setup without reconfiguring
the Linux ?
Yes - if that other linux system has a
Hi Jeff!
First, some definitions:
downstream - away from the host processor
primary - number of the PCI bus closer to the host processor
secondary - number of the PCI bus on the downstream side of the PCI
bridge
subordinate - number of the highest-numbered bus on the downstream side
of
On Wed, Oct 25, 2000 at 05:59:39PM -0400, Jeff Garzik wrote:
It may work, but the bridge secondary/subordinate numbers look wrong.
No, these numbers look correct for me. Read comment in drivers/pci/pci.c:
if (!is_cardbus) {
/* Now we can scan all subordinate buses... */
You obviously don't understand the communication channel being used.
"/dev/log" is a UNIX DOMAIN SOCKET -- AF_UNIX. Datagrams are unreliable
for _IP_ (AF_INET). Traffic on an AF_UNIX socket is always reliable.
Ok, smarty, go change the syslogd source to open /dev/log as SOCK_STREAM
and
"Pasi Kärkkäinen" wrote:
I'm using 2.4.0-test10-pre5 on a PIII (compiled with gcc 2.7.2.3) and
...
gcc-2.7.2.3 miscompiles kernel/module.c and it has been decided that
this will not be worked around. The new baseline gcc release for x86
is gcc-2.91.66 (otherwise known as egcs-1.1.2).
-
To
Ulrich Drepper [EMAIL PROTECTED] writes:
If anything has to be changed it's (as suggested) the configuration
or even the implementation of syslogd. Make it robust.
OK, but my current syslogd only listens to /dev/log as a SOCK_DGRAM.
If I wanted reliable syslogging, it would be
On 23 Oct 2000, Patrick J. LoPresti wrote:
Jesse Pollard [EMAIL PROTECTED] writes:
Don't configure syslogd to do reverse lookups.
Our syslogd has no option to disable the reverse lookups.
Requires a recompile.
You can NEVER guarantee that the reverse lookup will succeed, and
can be
Hi,
I was having some little trouble with the QLOGIC Fibre Channel SCSI
cards.
The issue is, that I have a box with an internal SCSI controller/disk
and
a QLOGIC card which is connected to an external RAID. The probelm is,
that the internal disk is my root disk but is the second in the chain
Hi,
This bug was triggered by trying ctrl-alt-del for reboot in
test10-pre5. It appears to show schedule() getting stuck in
a loop with the stack growing unbounded.
Unfortunately, the module list and symbols are not exposed.
I don't know what had been unloaded before the bug
triggered. The
On Thu, 26 Oct 2000, Klaus Naumann wrote:
I was having some little trouble with the QLOGIC Fibre Channel SCSI
cards.
The issue is, that I have a box with an internal SCSI controller/disk
and a QLOGIC card which is connected to an external RAID. The probelm
is, that the internal disk is my
No, I didn't say they "should" be dropped but merely that dropping them
would fix your problem. Personally, I'd look closely at your setup to
determine exactly why this has become a problem. named is being blocked
on writing to /dev/log. This should only happen if there is sufficient
Perhaps syslogd is not giving higher priority to local messages; if it
did, maybe it could recover from the deadlock. But this would not be
a reliable solution; the only reliable solution is for syslogd to be
independent of any processes which need to talk to it.
In that case, don't do
On Thu, 26 Oct 2000, Andrew Morton wrote:
"Pasi Kärkkäinen" wrote:
I'm using 2.4.0-test10-pre5 on a PIII (compiled with gcc 2.7.2.3) and
...
gcc-2.7.2.3 miscompiles kernel/module.c and it has been decided that
this will not be worked around. The new baseline gcc release for x86
is
Byeong-ryeol Kim wrote:
On Thu, 26 Oct 2000, Klaus Naumann wrote:
I was having some little trouble with the QLOGIC Fibre Channel SCSI
cards.
The issue is, that I have a box with an internal SCSI controller/disk
and a QLOGIC card which is connected to an external RAID. The probelm
On Wed, 25 Oct 2000, Anil kumar wrote:
Hi,
After I create a RAID setup on the drives,The
superblock will be generated at the end of the drives.
If I move these drives to other linux system, will
this
system recognise the RAID setup without reconfiguring
the Linux ?
If the CHS / LBA
Yes, it will break on any machine with multiple primary PCI busses, because
the registers assigning bus number ranges to primary busses are chipset
specific.
In 2.5, I'd like to rewrite the resource + bus number assignment code to be
able to re-layout the busses and resources even on i386 if it
On Thu, 26 Oct 2000 14:22:54 +0200,
Klaus Naumann [EMAIL PROTECTED] wrote:
The problem with that is that on boot up (for lilo) the internal disk
is disk number one. But when I'm in the system and want to install lilo
it's disk number two - that's what lilo is complaining about on boot up.
(By
I recently installed 2.4test9pre5 and noticed that when I cat
/proc/meminfo the value for shared memory is 0. Am I the only one that
is seeing this.
Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ
"Pasi Kärkkäinen" wrote:
Ok. I recompiled the kernel and modules with 2.95.2 and it still seems not
to work. This is from syslog:
__alloc_pages: 2-order allocation failed.
__alloc_pages: 2-order allocation failed.
__alloc_pages: 5-order allocation failed.
__alloc_pages: 4-order
Hi,
I got the following OOPS while doing some heavy compilations (make -j4) on dual SMP
P-III,
2.4.0-test10-pre5 and reiserfs 3.6.18 for 2.4.0-test9.
It looks like page without page-mapping has been passed to
block_read_full_page().
Unable to handle kernel NULL pointer dereference at
Stephen Clark wrote:
I recently installed 2.4test9pre5 and noticed that when I cat
/proc/meminfo the value for shared memory is 0. Am I the only one that
is seeing this.
I'm seeing this also for 2.4.0-test10-pre5. Here is /proc/meminfo followed
by the same for a 2.2 machine running the same
Hi!
I've found a bug in my VIA SuperSouth (vt82c686a) chip (ISA bridge
revision 0x12, silicon rev CD) on my FIC VA-503A rev 1.2:
When there is heavy disk activity (several tars running concurrently on
UDMA66 drive, or tar'ing from one UDMA66 drive to another over two
channels), the system time,
Hi,
i hope i am right here, and this problem wasn't mailed a thousand times
before - but it is not older than 3 days (2.4.0-test10-pre5 is'nt
older...)
I am playing around with usb and usb-storage, and then i wanted to reload
the usb-ohci-module, during the insmod i got this error:
Oct 26
On Thu, Oct 26, 2000 at 07:25:34AM -0600, Steven Cole wrote:
Stephen Clark wrote:
I recently installed 2.4test9pre5 and noticed that when I cat
/proc/meminfo the value for shared memory is 0. Am I the only one that
is seeing this.
I'm seeing this also for 2.4.0-test10-pre5. Here is
Hi Linus,
in the current kernel versions we have a lot of new list-style makefiles
(find -name Makefile | xargs grep -l obj- | wc -l gives 48 in -pre5) and
the number increases all the time.
This patch adds a new makefile ($(TOPDIR])/Makefile.inc) that can be
included by the list-style
Vojtech Pavlik [EMAIL PROTECTED] writes:
Hi!
I've found a bug in my VIA SuperSouth (vt82c686a) chip (ISA bridge
revision 0x12, silicon rev CD) on my FIC VA-503A rev 1.2:
When there is heavy disk activity (several tars running concurrently on
UDMA66 drive, or tar'ing from one UDMA66
On Thu, 26 Oct 2000 23:52:02 +1100,
Andrew Morton [EMAIL PROTECTED] wrote:
[ You could put a show_stack(0) in here, but I believe ksymoops
doesn't understand show_stack() output ].
It does, and extracts the "Call Trace:" data. The stack is not printed
by ksymoops because it does not have the
On Thu, 26 Oct 2000 15:39:59 +0200 (CEST),
Christian Reiser [EMAIL PROTECTED] wrote:
kernel BUG at slab.c:804!
Code: 0f 0b 83 c4 0c 8d b4 26 00 00 00 00 8b 1b 81 fb bc 23 26 c0
... hope it could help ...
Almost completely useless until you follow the procedures in
linux/REPORTING-BUGS.
-
On Thu, Oct 26, 2000 at 03:58:21PM +0200, Yoann Vandoorselaere wrote:
I've found a bug in my VIA SuperSouth (vt82c686a) chip (ISA bridge
revision 0x12, silicon rev CD) on my FIC VA-503A rev 1.2:
When there is heavy disk activity (several tars running concurrently on
UDMA66 drive, or
Vojtech Pavlik [EMAIL PROTECTED] writes:
On Thu, Oct 26, 2000 at 03:58:21PM +0200, Yoann Vandoorselaere wrote:
I've found a bug in my VIA SuperSouth (vt82c686a) chip (ISA bridge
revision 0x12, silicon rev CD) on my FIC VA-503A rev 1.2:
When there is heavy disk activity (several
On Thu, Oct 26, 2000 at 04:13:51PM +0200, Yoann Vandoorselaere wrote:
I've found a bug in my VIA SuperSouth (vt82c686a) chip (ISA bridge
revision 0x12, silicon rev CD) on my FIC VA-503A rev 1.2:
When there is heavy disk activity (several tars running concurrently on
UDMA66
On Thu, 26 Oct 2000, Mircea Damian wrote:
Hello,
I'm unable to boot kernel 2.4.0-test10-pre5 on a:
And here is the broken routine:
03f4 do_test_wp_bit:
3f4: 8b 44 24 04 movl 0x4(%esp,1),%eax
3f8: b9 01 00 00 00 movl $0x1,%ecx
3fd: 8a 10
++ 26/10/00 16:11 +0200 - Vojtech Pavlik:
On Thu, Oct 26, 2000 at 04:13:51PM +0200, Yoann Vandoorselaere wrote:
I've found a bug in my VIA SuperSouth (vt82c686a) chip (ISA bridge
revision 0x12, silicon rev CD) on my FIC VA-503A rev 1.2:
When there is heavy disk activity
Mircea Damian wrote:
Hello,
I'm unable to boot kernel 2.4.0-test10-pre5 on a:
Upgrade GCC to 2.91.66 (aka egcs-1.1.2)
--
Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Thu, Oct 26, 2000 at 02:57:30PM +0300, Pasi Kärkkäinen wrote:
On Thu, 26 Oct 2000, Andrew Morton wrote:
"Pasi Kärkkäinen" wrote:
gcc-2.7.2.3 miscompiles kernel/module.c and it has been decided that
this will not be worked around. The new baseline gcc release for x86
is
"Richard B. Johnson" wrote:
Stand-alone, it can't do anything useful. However, if it generates
a page-fault due to the read or write, the page-fault handler could
do "something". Currently, the fault it fatal, probably because
the passed pointer is invalid.
The write-protect test code is a
Richard B. Johnson wrote:
And here is the broken routine:
03f4 do_test_wp_bit:
[...]
This is not good code. It does the following:
o Gets a parameter off the stack and puts into eax (a pointer).
o Put the value 1 into ecx.
o Take a byte from the pointed-to location
Then shouldn't it be removed?
Craig Schlenter wrote:
On Thu, Oct 26, 2000 at 07:25:34AM -0600, Steven Cole wrote:
Stephen Clark wrote:
I recently installed 2.4test9pre5 and noticed that when I cat
/proc/meminfo the value for shared memory is 0. Am I the only one that
is seeing this.
On Thu, 26 Oct 2000, Brian Gerst wrote:
"Richard B. Johnson" wrote:
Stand-alone, it can't do anything useful. However, if it generates
a page-fault due to the read or write, the page-fault handler could
do "something". Currently, the fault it fatal, probably because
the passed pointer
On Thu, Oct 26, 2000 at 10:40:33AM -0400, Stephen Clark wrote:
[/proc/meminfo shared is 0]
Then shouldn't it be removed?
Probably not. There may be tools that rely on it existing that may break
if it goes away altogether.
Maybe 'free' does for example.
--C
-
To unsubscribe from this list:
That makes sense.
Steve
Craig Schlenter wrote:
On Thu, Oct 26, 2000 at 10:40:33AM -0400, Stephen Clark wrote:
[/proc/meminfo shared is 0]
Then shouldn't it be removed?
Probably not. There may be tools that rely on it existing that may break
if it goes away altogether.
Maybe 'free'
101 - 200 of 290 matches
Mail list logo
