On Sun, 04 Mar 2001 16:24:57 +1100,
Andrew Morton <[EMAIL PROTECTED]> wrote:
>I do builds in /usr/src/linux, which is a symlink
>to /usr/src/linux-akpm. The recent `mkdep' changes
>have broken this practice most horridly. When searching
>.hdepend, `make' doesn't recognise that nested headers
>h
Keith,
I do builds in /usr/src/linux, which is a symlink
to /usr/src/linux-akpm. The recent `mkdep' changes
have broken this practice most horridly. When searching
.hdepend, `make' doesn't recognise that nested headers
have changed. This is because .hdepend has things like
/usr/src/linux/inclu
> > kernel: PAP-5660: reiserfs_do_truncate: wrong result -1 of search for
> > [7906789 7906806 0xfff DIRECT]
> > .
>
> These aren't good at all, and show a general corruption problem. I know the ac
>kernels have at least one small DAC960 bug fixes, are there other fixes pending
On Thursday, February 08, 2001 04:00:26 PM +0100 Andrius Adomaitis <[EMAIL PROTECTED]>
wrote:
>
> Hello,
>
> I have dual PIII 800 machine running as mail server on DAC 960 RAID &
> reiserfs comming with 2.4.1kernel.
>
> Under very high loads I get following messages in my kernel log:
>
Hello,
I have dual PIII 800 machine running as mail server on DAC 960 RAID &
reiserfs comming with 2.4.1kernel.
Under very high loads I get following messages in my kernel log:
kernel: vs-13060: reiserfs_update_sd: stat data of object [7906789
7906806 0x0 SD](nlink == 1) not found (pos 23)
OK, talked with someone who knows a little more about this than i do.
According to him, one reason I may be getting these errors is due to the
fact that the HPT370 controller is using IRQ18 which falls in the APIC
extended IRQ range (16 - 31).
If this is a problem is there a work-around? I don't
First off, here's something from my dmesg.
mapped APIC to e000 (fee0)
mapped IOAPIC to d000 (fec0)
CALLIN, before setup_local_APIC().
ENABLING IO-APIC IRQs
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-9, 2-10, 2-11, 2-20, 2-21,
2.4.2-pre1 + ReiserFS 3.6.25 (included) + loop-4
ksymoops 2.3.7 on i686 2.4.2-pre1. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.2-pre1/ (default)
-m /boot/System.map (specified)
Unable to handle kernel NULL pointer
On Tue, Feb 06, 2001 at 01:52:36PM -0500, Jeff Garzik wrote:
> Tom Rini wrote:
> > Er, what exactly is the CONFIG_PREP stuff in this driver supposed to be
> > for? "CONFIG_PREP" doesn't exist anymore to start with, and secondly I'm
> > not sure if any PReP boxes ever shipped with a riva card to s
Tom Rini wrote:
> Er, what exactly is the CONFIG_PREP stuff in this driver supposed to be
> for? "CONFIG_PREP" doesn't exist anymore to start with, and secondly I'm
> not sure if any PReP boxes ever shipped with a riva card to start with. The
> only real way to handle this in 2.4 is something li
On Sat, Feb 03, 2001 at 08:24:27PM -0800, Linus Torvalds wrote:
...
> -pre1:
...
> - riva FB driver update
Er, what exactly is the CONFIG_PREP stuff in this driver supposed to be
for? "CONFIG_PREP" doesn't exist anymore to start with, and secondly I'm
not sure if any PReP boxes ever shipped wi
he kernel makes you guess what the error messages are, to add some
spice to life :-)
>Attached are two ksymoops outputs, for the two times I did this.
Error (expand_objects): cannot
stat(/lib/modules/2.4.2-pre1/kernel/drivers/usb/uhci.o) for uhci
Error (expand_objects): cannot
stat(/lib/modu
When trying to figure out how to get USB to work (it was the MPS
setting, more in other post) I got a repeatable Oops (is it an
oops? it doesn't say "Oops!" like I thought they do). That is,
I'd boot, modprobe uhci, plug something in, get lots of timeouts,
unplug the something, modprobe -r uhci. O
In the usual spot:
ftp://ftp.kernel.org/pub/linux/kernel/people/davem/zerocopy-2.4.2p1-1.diff.gz
Changes since last installment:
1) Merge in lots of AC patch fixes, from Alan.
2) Use more reasonable MTU for loopback under
Zerocopy, basically it's 16K + sizeof TCP/IP headers now.
Later,
Dav
ok, since so many people ask for it to be called "rootfstype=", I will do
so and resend the patch.
Any other comments? I think on the last round I have incorporated all the
comments (except the "rootfs" -> "rootfstype" one)...
Tigran
On Mon, 5 Feb 2001, Werner Almesberger wrote:
> Tigran Aiva
Tigran Aivazian wrote:
> This patch adds "rootfs" boot parameter which selects the filesystem type
> for the root filesystem.
Could you please make this rootfstype= or fstype= or maybe
root=[,] or such ? Calling it "rootfs" is just asking
for trouble ...
- Werner
--
_
Hi Linus,
This patch adds "rootfs" boot parameter which selects the filesystem type
for the root filesystem. Useful (nay, live-saving :) to distinguish
between filesystems which cannot detect damage to their structural
integrity. E.g. ext2 cannot detect if the block device has had another
filesys
Mikael Pettersson wrote:
> Bryan W. Headley writes:
> > Last kernel that booted was Redhat's build of 2.4.0-pre11. I'm not sure
> > where the issue is at, so I attach a log of the system booting up.
> >
> > It's an ASUS P2B-DS with dual Deschutes
Bryan W. Headley writes:
> Last kernel that booted was Redhat's build of 2.4.0-pre11. I'm not sure
> where the issue is at, so I attach a log of the system booting up.
>
> It's an ASUS P2B-DS with dual Deschutes PII-450s.
> Linux version 2.4.2-pre1 ([EMAIL PROTECTE
ther boot
logs)
--
.:.
Bryan W. Headley - [EMAIL PROTECTED]
bootup-2.4.2-pre1.log
[ Linux-kernel added to the cc, as others probably also wonder ]
On Sat, 3 Feb 2001, David D.W. Downey wrote:
>
> How often does Alan's patches get rolled into your main line? I'm
> having difficulty following the divergence here. I'm trying to run THE
> latest release(s) of your kernel wi
Mainly a number of small details and some driver updates. The socket
datagram handling one is important, and has already been posted separately
here on linux-kernel. The VIA driver update is rather important if you
have one of the newer VIA chipsets.
Linus
-pre1:
- XMM: do
22 matches
Mail list logo
