Hi,
i wrote:
> EIP:0010:[__mark_inode_dirty+92/112]
> EFLAGS: 00010202
> eax: ebx: cc85b240 ecx: cc85b428 edx: cc85b248
> esi: c15dc200 edi: 0001 ebp: c361dfa4 esp: c361df24
This is a bit-flipper. There is a valid super-block entry at c14dc200.
Mich
Hi,
had an Oops in __mark_inode_dirty running kernel 2.4.2-pre3 on i386 UP
(actually a PII-300). It did happen during the daily cron job. Currently
on proc, devpts and ext2 filesystems are used no nfs and the like. The
system is still running. So if you need further information mail me or
come
--
A E Lawrence
2.4.2-pre4 freezes, 2.4.2-pre3 ext2/scsi problem
This is a minimal report of a problem on a modestly overclocked but very well
tested Athlon system. In view of the overclocking, it will require
confirmation by others, and some
On Wed, 14 Feb 2001, Grant Grundler wrote:
> Philipp Rumpf wrote:
> > Jeff Garzik wrote:
> > > Looks ok, but I wonder if we should include this list in the docs.
> > > These is stuff defined by the PCI spec, and this list could potentially
> > > get longer... (opinions either way wanted...)
>
>
Hi,
I'm having some problems with XFree86 4.0.2 and DRI/DRM in 2.4.2-pre3.
I'm using a Dell Inspiron 8000 with a ATI Rage Mobility M4 32 MB,
and can get it running with DRI under 2.4.0-ac10. When using 2.4.2-pre3, I
can see each individual widget being built when I enable DRI.
outpu
On Fri, 16 Feb 2001 10:07:32 + (GMT), you wrote:
>I'm just waiting for linus to put out a 2pre4
>so I can start feeding him more stuff
When are we likely to see 2.4.2? (and 2pre4)?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL P
> The "ld" program in binutils-2.10.1.0.7 and in
> binutils-2.10.91.0.2 now requires "--oformat" instead of "-oformat".
> This breaks linux-2.4.2-pre3/arch/i386/boot/Makefile. I have attached
> the fix below. I am running a kernel built with th
> The "ld" program in binutils-2.10.1.0.7 and in binutils-2.10.91.0.2 now
> requires "--oformat" instead of "-oformat".
[root@debian-f5ibh] /usr/src/kernel-sources-2.4.2 # ld -v
GNU ld version 2.9.5 (with BFD 2.9.5.0.37)
[root@debian-f5ibh] /usr/src/kernel-sources-2.4.2 # ld --help
Usa
The "ld" program in binutils-2.10.1.0.7 and in
binutils-2.10.91.0.2 now requires "--oformat" instead of "-oformat".
This breaks linux-2.4.2-pre3/arch/i386/boot/Makefile. I have attached
the fix below. I am running a kernel built with this updated
So I assume we wait on baited breathe for 2.4.2-pre4 or
branch off soon to 2.5 blah?
Frank
-
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 th
,
first without dma, or irq_unmask enabled for both /dev/hda and /dev/hdb.
Then with dma, then with dma and irq_unmask enabled(as usually have it).
No Segfaults, no Ooops...yet :)
I didn't do any of the above tests in 2.4.2-pre3, as my system just
seemed unstable. If there is an indication th
I'm getting an intermittent (but fairly reproducible) lockup under
2.4.1 and 2.4.2-pre3, which seems to be occurring when usbdevfs is
unmounted. The system appears to freeze almost completely; I can still
switch VCs (assuming I wasn't in X at the time) but little else.
Sometimes (but
Philipp Rumpf wrote:
> On Wed, 14 Feb 2001, Grant Grundler wrote:
> > Having people look things up in the spec isn't very user friendly.
>
> Having the constants in some well-known header file should be sufficient,
> shouldn't it ?
I would hope anyone bothering to include the constants in a docu
On Wed, 14 Feb 2001, Grant Grundler wrote:
> Philipp Rumpf wrote:
> > Jeff Garzik wrote:
> > > Looks ok, but I wonder if we should include this list in the docs.
> > > These is stuff defined by the PCI spec, and this list could potentially
> > > get longer... (opinions either way wanted...)
>
>
On Wed, 14 Feb 2001, Roeland Th. Jansen wrote:
> On Tue, Feb 13, 2001 at 09:13:10PM +0100, Maciej W. Rozycki wrote:
> > Please test it extensively, as much as you can, before I submit it for
> > inclusion. If you ever get "Aieee!!! Remote IRR still set after unlock!"
> > message, please rep
On Wed, Feb 14, 2001 at 05:30:57PM +, Roeland Th. Jansen wrote:
> other observations -- approx 6000 ints from the ne2k card/sec.
> MIS shows approx 1% that goes wrong with a ping flood.
oops. had to count both CPU0 and CPU1's interrupts. after 23 minutes :
CPU0 CPU1
19:
On Tue, Feb 13, 2001 at 09:13:10PM +0100, Maciej W. Rozycki wrote:
> Please test it extensively, as much as you can, before I submit it for
> inclusion. If you ever get "Aieee!!! Remote IRR still set after unlock!"
> message, please report it to me immediately -- it means the code failed.
o
Philipp Rumpf wrote:
> Jeff Garzik wrote:
> > Looks ok, but I wonder if we should include this list in the docs.
> > These is stuff defined by the PCI spec, and this list could potentially
> > get longer... (opinions either way wanted...)
Having people look things up in the spec isn't very user
On Wed, 14 Feb 2001, Andrew Morton wrote:
> Tell me, please: what tradeoffs are involved in this patch?
> Obviously it works around a pretty fatal problem, but
> what are we giving away?
The change decreases performance a bit. For well-behaved systems the
loss is fifteen instructions: a local
On Wed, 14 Feb 2001, Jeff Garzik wrote:
> On Wed, 14 Feb 2001, Tim Waugh wrote:
> > +/**
> > + * pci_find_capability - query for devices' capabilities
> > + * @dev: PCI device to query
> > + * @cap: capability code
> > + *
> > + * Tell if a device supports a given PCI capability.
> > + * Returns
"Maciej W. Rozycki" wrote:
>
> Hi,
>
> After performing various tests I came to the following workaround for
> APIC lockups which people observe under IRQ load, mostly for networking
> stuff.
Works fine on the dual-PII. No "Aieee!!!" messages at all.
After sending a few gigs across the ether
On Wed, 14 Feb 2001, Tim Waugh wrote:
> + * pci_find_subsys - begin or continue searching for a PCI device by
>vendor/subvendor/device/subdevice id
> + * @vendor: PCI vendor id to match, or %PCI_ANY_ID to match all vendor ids
> + * @device: PCI device id to match, or %PCI_ANY_ID to match all vend
On Wed, 14 Feb 2001, Tim Waugh wrote:
> }
>
> -
> +/**
> + * pci_find_capability - query for devices' capabilities
> + * @dev: PCI device to query
> + * @cap: capability code
> + *
> + * Tell if a device supports a given PCI capability.
> + * Returns the address of the requested capability str
On Wed, Feb 14, 2001 at 05:14:19AM -0600, Jeff Garzik wrote:
> Should the call to pci_unregister_driver in cleanup_module be
> conditional on registered_parport as well? I didn't check...
No. (cleanup_module is only called if init_module succeeded.)
> Also, is it possible to convert parport_pc
On Wed, 14 Feb 2001, Andrew Morton wrote:
> Jeff Garzik wrote:
> >
> > Bad patch. It should be
> >
> > if (r >= 0) {
> > registered_parport = 1;
> > if (r > 0)
> > count += r;
> > }
> >
> > If pci_register_driver returns
On Wed, Feb 14, 2001 at 10:21:38PM +1100, Andrew Morton wrote:
> Now, if there were some actual COMMENTS (scary, I know) in the pci
> code which described the API, stuff like this wouldn't happen.
Oh yeah, that reminds me: if someone would like to make sure that the
following changes are accurat
On Wed, 14 Feb 2001, Tim Waugh wrote:
> On Wed, Feb 14, 2001 at 02:03:07AM -0600, Jeff Garzik wrote:
>
> > If pci_register_driver returns < 0, the driver is not registered with
> > the system.
>
> Thanks. Okay, second try:
>
> 2001-01-14 Tim Waugh <[EMAIL PROTECTED]>
>
> * parport_pc
Jeff Garzik wrote:
>
> Bad patch. It should be
>
> if (r >= 0) {
> registered_parport = 1;
> if (r > 0)
> count += r;
> }
>
> If pci_register_driver returns < 0, the driver is not registered with
> the system.
eh?
pci_re
On Wed, Feb 14, 2001 at 02:03:07AM -0600, Jeff Garzik wrote:
> If pci_register_driver returns < 0, the driver is not registered with
> the system.
Thanks. Okay, second try:
2001-01-14 Tim Waugh <[EMAIL PROTECTED]>
* parport_pc.c: Fix PCI driver list corruption on
unsuccessfu
On Wed, 14 Feb 2001, Jeff Garzik wrote:
> On Tue, 13 Feb 2001, Tim Waugh wrote:
> > Here's a patch that fixes a bug that can cause PCI driver list
> > corruption. If parport_pc's init_module fails after it calls
> > pci_register_driver, cleanup_module isn't called and so it's still
> > registere
On Tue, 13 Feb 2001, Tim Waugh wrote:
> Here's a patch that fixes a bug that can cause PCI driver list
> corruption. If parport_pc's init_module fails after it calls
> pci_register_driver, cleanup_module isn't called and so it's still
> registered when it gets unloaded.
> --- linux/drivers/parpo
On Tue, 13 Feb 2001, Zink, Dan wrote:
> Does it make sense to try and keep up with the latest and greatest in
> chipsets
> when there is a hardware independent way of doing things? You may be able
> to
> get information on current chipsets, but every time something changes, the
> kernel may be br
Get rid of the special case in drivers/acpi/Makefile. mkdep now uses
the same -I options in the same order as the compiler. Against 2.4.2-pre3.
Please jump up and down on this patch before I send it to Linus.
Change from take 1 - make is too dumb to realise that /path/name/file.h
is the same
Linus,
Here's a patch that fixes a bug that can cause PCI driver list
corruption. If parport_pc's init_module fails after it calls
pci_register_driver, cleanup_module isn't called and so it's still
registered when it gets unloaded.
Tim.
*/
2001-01-13 Tim Waugh <[EMAIL PROTECTED]>
*
On Tue, Feb 13, 2001 at 09:13:10PM +0100, Maciej W. Rozycki wrote:
> There is also an additional debugging/statistics counter provided in
> /proc/cpuinfo that counts interrupts which got delivered with its trigger
> mode mismatched. Check it out to find if you get any misdelivered
> interrupts at
"Maciej W. Rozycki" wrote:
>
> Hi,
>
> After performing various tests I came to the following workaround for
> APIC lockups which people observe under IRQ load, mostly for networking
> stuff. I believe the test should work in all cases as it basically
> implements a manual replacement for EOI
The patch applies to 2.4.1 and 2.4.2-pre3 cleanly. For -ac series you
need to revert patch-2.4.0-io_apic-2 first -- check list archives for the
patch.
Andrew, Manfred: that's a one-line-updated version comparing to what you
already have.
Ingo: while implementing irq_mis_count, I corrected irq_
undamental reason for the
BIOS's existence.
Dan
-Original Message-
From: Jeff Garzik [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 13, 2001 11:12 AM
To: Tim Wright
Cc: Adam Lackorzynski; Jan-Benedict Glaw; [EMAIL PROTECTED];
Zink, Dan
Subject: Re: PCI bridge handling 2.4.0-test1
On Tue, 13 Feb 2001, Tim Wright wrote:
> I believe that, in general, we want working fixup routines so the we don't
> have to rely on the BIOS. That said, it's apparent that the ServerWorks
> routines are broken. Fixing them is going to be troublesome, given ServerWorks
> attitude towards releasin
ote:
> > > On Mon Feb 12, 2001 at 14:04:20 +0100, Jan-Benedict Glaw wrote:
> > > > I've got a "Bull Express5800/Series" (dual P3) with a DAC1164 RAID
> > > > controller. The mainboard is ServerWorks based and however, 2.4.2-pre3
> > > >
AC1164 RAID
> > > controller. The mainboard is ServerWorks based and however, 2.4.2-pre3
> > > fails to find the RAID controller. I think there's a problem at
> > > scanning PCI busses behind PCI bridges. Here's the PCI bus layout as
> > > 2.4.0-
On Tue, Feb 13, 2001 at 12:38:15AM +0100, Adam Lackorzynski wrote:
Hi Adam!
> On Mon Feb 12, 2001 at 14:04:20 +0100, Jan-Benedict Glaw wrote:
> > I've got a "Bull Express5800/Series" (dual P3) with a DAC1164 RAID
> > controller. The mainboard is ServerWorks
On Mon Feb 12, 2001 at 14:04:20 +0100, Jan-Benedict Glaw wrote:
> I've got a "Bull Express5800/Series" (dual P3) with a DAC1164 RAID
> controller. The mainboard is ServerWorks based and however, 2.4.2-pre3
> fails to find the RAID controller. I think there's a pro
Hi!
I've got a "Bull Express5800/Series" (dual P3) with a DAC1164 RAID
controller. The mainboard is ServerWorks based and however, 2.4.2-pre3
fails to find the RAID controller. I think there's a problem at
scanning PCI busses behind PCI bridges. Here's the PCI b
Alan Cox wrote:
>
> > Do you really prefer if drivers contain a
> >
> > static inline void* safe_kmalloc(size, flags)
> > {
> > if(size > LIMIT)
> > return NULL;
> > return kmalloc(size, flags);
> > }
>
> It isnt that simple. Look at af_unix.c for example. It needs to k
> Do you really prefer if drivers contain a
>
> static inline void* safe_kmalloc(size, flags)
> {
> if(size > LIMIT)
> return NULL;
> return kmalloc(size, flags);
> }
It isnt that simple. Look at af_unix.c for example. It needs to know the
maximum safe request size to
Alan Cox wrote:
>
> > > Would it be costly/reasonable to have kmalloc -not- panic if given a
> > > too-large size? Principle of Least Surprises says it should return NULL
> > > at the very least.
> >
> > It's on purpose; to find the erroneous drivers.
>
> Unfortunately Linus forgot to provide a
> > printk a message and fail the call. Don't panic.
>
> Perhaps add a compile time warning, similar to __bad_udelay();
> The BUG is a bad idea.
They are all dynamic allocations
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTE
> > Would it be costly/reasonable to have kmalloc -not- panic if given a
> > too-large size? Principle of Least Surprises says it should return NULL
> > at the very least.
>
> It's on purpose; to find the erroneous drivers.
Unfortunately Linus forgot to provide a way to check if a kmalloc is to
Jeff Garzik wrote:
>
>
> printk a message and fail the call. Don't panic.
>
Perhaps add a compile time warning, similar to __bad_udelay();
The BUG is a bad idea.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL P
David Weinehall wrote:
>
> On Sun, Feb 11, 2001 at 02:59:13PM -0500, Jeff Garzik wrote:
> > Alan Cox wrote:
> > >
> > > > 2.4.2-pre3 doesn't compile with 6pack as a module; I had to disable it;
> > > > now it compiles (and so far, works fine).
&
On Sun, Feb 11, 2001 at 02:59:13PM -0500, Jeff Garzik wrote:
> Alan Cox wrote:
> >
> > > 2.4.2-pre3 doesn't compile with 6pack as a module; I had to disable it;
> > > now it compiles (and so far, works fine).
> >
> > It has a slight dependancy on -a
Alan Cox wrote:
>
> > 2.4.2-pre3 doesn't compile with 6pack as a module; I had to disable it;
> > now it compiles (and so far, works fine).
>
> It has a slight dependancy on -ac right now.
>
> KMALLOC_MAXSIZE is the alloc size limit - 131072. It checks this a
> 2.4.2-pre3 doesn't compile with 6pack as a module; I had to disable it;
> now it compiles (and so far, works fine).
It has a slight dependancy on -ac right now.
KMALLOC_MAXSIZE is the alloc size limit - 131072. It checks this as kmalloc
now panics if called with an oversize req
> hrm. it misbehaved on ac9 now. i'll try a different soundcard and see
> what happens. is es1370 known to be relatively stable? i have one of
> those lying about somewhere.
The es1370 hasnt changed much but the VM code had a little (and testing ac9
tests who different sets of behaviour). If
fault after all. :-) 2.4.2-pre3
behaves also, haven't bothered trying anything else yet. note that
commenting out the bits of XF86Config relevant to the s3 was sufficient,
didn't need to physically remove the card.
it is still odd, since there aren't any resource conflicts (t
Dear folks,
2.4.2-pre3 doesn't compile with 6pack as a module; I had to disable it;
now it compiles (and so far, works fine).
kgcc -D__KERNEL__ -I/home/nicku/linux/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686
-DMODULE -DMODVERSIONS -in
On Sun, Feb 11, 2001 at 10:20:33PM +1100, john slee wrote:
> i'm fairly sure its not ram at fault, since nothing else is acting
> strangely, and it only crops up when i use /dev/dsp.
>
> anything else i can try to narrow it down? this is just a home
> workstation, so i can try practically anythi
On Sat, Feb 10, 2001 at 07:33:53PM +, Alan Cox wrote:
> Does 2.4.1-ac9 behave ?
hrm. it misbehaved on ac9 now. i'll try a different soundcard and see
what happens. is es1370 known to be relatively stable? i have one of
those lying about somewhere.
i'm fairly sure its not ram at fault, si
Get rid of the special case in drivers/acpi/Makefile. mkdep now uses
the same -I options in the same order as the compiler. Against 2.4.2-pre3.
Please jump up and down on this patch before I send it to Linus.
Index: 2-pre3.1/scripts/mkdep.c
--- 2-pre3.1/scripts/mkdep.c Fri, 05 Jan 2001 13:42
BTW, the kernel version is 2.4.2-pre3 (2.4.1 with patch-pre3 applied)
NO other patches have been applied.
I used hdparm v3.9 to set the params with.
--
David D.W. Downey - RHCE
Consulting Engineer
Ensim Corporation - Sunnyvale, CA
-
To unsubscribe from this list: send the line "unsubs
OK, got some problems here.
Here is the dmesg dump for my machine. Please grep for IO-APIC and APIC
errors on CPU#. I get TONS of these messages whenever I do any heavy I/O
like a dd if=/dev/zero of=/tmp/testing.img bs=1024k count=1500.
I also get errors about exceeding the file size. As far
> Are you using XFree86 4.0 on a matrox card ?
No, it's an nVIDIA Riva TNT2 Ultra 32 MB AGP (card manufacturer: Creative). But these
problems are not related to X, as they are the same whether I use mpg123 in a plain
console or xmms in X. But, I've also tried something else, I compiled a kernel
On Sat, Feb 10, 2001 at 07:33:53PM +, Alan Cox wrote:
> > it doesn't happen to me on 2.4.1-pre11 with andrew morton's low
> > scheduling latency patch.
>
> Does 2.4.1-ac9 behave ?
yep, works fine.
j.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
As the subject states, w/ 2.4.2-pre3, whenever something starts doing
heavy i/o (most notably mozilla during startup, diff, recursive greps,
etc), it drops into 'D' state:
343 ?S 0:00 /bin/sh /usr/local/src/mozilla/dist/bin/run-mozilla.sh
/usr/local/src/mozilla/dist/b
> it doesn't happen to me on 2.4.1-pre11 with andrew morton's low
> scheduling latency patch.
Does 2.4.1-ac9 behave ?
-
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/
> After upgrading to 2.4.2-pre3 I get sound corruption (I believe this proble=
> m has existed since pre2, since I suspect the " - driver sync up with Alan"=
> part of the changes in pre2 to be the source of the problem. I've also tri=
No es1370 changes went in
> e
ppropriate kernel patch for it.
thanks in advance,
j.
ver_linux: (all debian-testing versions of things, except kernel)
--
Linux elektra 2.4.2-pre3 #10 Sun Feb 11 02:57:42 EST 2001 i686 unknown
Kernel modules 2.4.1
Gnu C 2.95.3
Gnu Make 3.79.1
0
After upgrading to 2.4.2-pre3 I get sound corruption (I believe this problem has
existed since pre2, since I suspect the " - driver sync up with Alan" part of the
changes in pre2 to be the source of the problem. I've also tried 2.4.1-ac9, which
gives me the exact same proble
haha thats funny, I just compiled 2.4.2-pre2 ;-)
oh well...time to patch again.
Linus Torvalds wrote:
> Nothing too radical here..
>
> Linus
>
>
> -pre3:
> - Jens: better ordering of requests when unable to merge
> - Neil Brown: make md work as a module again (we cannot
Nothing too radical here..
Linus
-pre3:
- Jens: better ordering of requests when unable to merge
- Neil Brown: make md work as a module again (we cannot autodetect
in modules, not enough background information)
- Neil Brown: raid5 SMP locking cleanups
- Neil Brown: n
71 matches
Mail list logo