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.
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
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
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.
Michael
--
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
--
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...)
>
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...)
Having
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.
output lspci -v
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
> 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
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
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 M
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
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.
output lspci -v
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
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 that it's no
, 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 that it's not my machine being
flaky
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
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
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 not always
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
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
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.
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
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
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
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
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
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]>
>
> *
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?
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
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
> >
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
registered when
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
unsuccessful
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?
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.c: Fix PCI
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 0, the driver is not
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
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, 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 vendor
"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 ethernet,
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 the address of
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
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 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.
ok,
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 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 report it
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 document
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 not always
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.
> ---
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
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
"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
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-test10 -> 2.4.2-p
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
> 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 RA
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-test10 recogniz
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 base
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 based and however, 2.4.2-pr
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-test10 recognizes it:
--- pci-pc.c.orig Tue Feb 13 00:02:50 2001
+++ pci-pc.cTue
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 problem at
scanning PCI busses behind P
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 releasing
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-test10 - 2.4.2-pre3
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
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
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]
*
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
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 broken
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.
---
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 problem at
&g
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 bus layout as
2.
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 bus layout as
2.
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 problem at
scanning PCI bus
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
> 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
> > 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
> > 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
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
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
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 as kma
> 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 r
> 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 (that i am
aware
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 -include
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
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,
1 - 100 of 136 matches
Mail list logo
