On Wed, Dec 27 2000, Andrea Arcangeli wrote:
> I think right behaviour of the blkdev layer is to BUG() if the driver eats
> requests while the device is plugged.
The device is supposed to know what it's doing. Sure it defeats the
elevators work a bit, but again the driver should know best.
On Wed, Dec 27 2000, Andrea Arcangeli wrote:
I think right behaviour of the blkdev layer is to BUG() if the driver eats
requests while the device is plugged.
The device is supposed to know what it's doing. Sure it defeats the
elevators work a bit, but again the driver should know best.
On Wed, Nov 29, 2000 at 12:56:44PM +0100, [EMAIL PROTECTED] wrote:
>
>
> Hi,
> I experienced disk hangs with linux-2.4.0-test11 on S/390 and after
> some debugging I found the cause. It the new method of unplugging
> block devices that doesn't go along with the
On Wed, Nov 29, 2000 at 12:56:44PM +0100, [EMAIL PROTECTED] wrote:
Hi,
I experienced disk hangs with linux-2.4.0-test11 on S/390 and after
some debugging I found the cause. It the new method of unplugging
block devices that doesn't go along with the S/390 disk driver:
/*
* remove
On Thu, 14 Dec 2000 14:55:59 -0500,
Gerard Beekmans <[EMAIL PROTECTED]> wrote:
>Every time I try to copy a specific directory to a mounted loop file system,
>Linux freezes up on me. I've tried this several times and it freezes up at
>the same place every time. When I copy that same directory
On Thu, 14 Dec 2000 14:55:59 -0500,
Gerard Beekmans [EMAIL PROTECTED] wrote:
Every time I try to copy a specific directory to a mounted loop file system,
Linux freezes up on me. I've tried this several times and it freezes up at
the same place every time. When I copy that same directory to a
Hi,
Every time I try to copy a specific directory to a mounted loop file system,
Linux freezes up on me. I've tried this several times and it freezes up at
the same place every time. When I copy that same directory to a regular file
system everything is ok.
This happens on 2.4.0 test11 and
Hi,
Every time I try to copy a specific directory to a mounted loop file system,
Linux freezes up on me. I've tried this several times and it freezes up at
the same place every time. When I copy that same directory to a regular file
system everything is ok.
This happens on 2.4.0 test11 and
[Georg Nikodym]
> + case 'x':
> + fprintf(stderr,
> + "klogd: %c option is obsolete. Ignoring\n", ch);
Clearer (IMHO): "klogd: warning: ignoring obsolete option '-%c'\n", ch);
Peter
-
To unsubscribe from this list: send
> "KO" == Keith Owens <[EMAIL PROTECTED]> writes:
KO> Looks good, except that you need to keep the option flags for
KO> backwards compatibility. There are a *lot* of scripts out there
KO> which invoke klogd with various options and they will fail with
KO> this change. It is OK to issue
On Mon, 11 Dec 2000 20:13:46 -0500 (EST),
"Georg Nikodym" <[EMAIL PROTECTED]> wrote:
>Here's a patch (against sysklogd-1.3-31) that completely tear out the
>symbol processing code.
Looks good, except that you need to keep the option flags for backwards
compatibility. There are a *lot* of
> "GN" == Georg Nikodym <[EMAIL PROTECTED]> writes:
GN> Here's a patch (against sysklogd-1.3-31) that completely tear out
GN> the symbol processing code.
Doh! Forgot a chunk (to be applied after the others):
diff -Nru a/src/sysklogd-1.3-31/Makefile b/src/sysklogd-1.3-31/Makefile
---
> "KO" == Keith Owens <[EMAIL PROTECTED]> writes:
KO> klogd maps the kernel messages from text to syslog levels and
KO> does some fiddling with kernel log levels at start up. It needs
KO> to be more than a simple 'cat'. When symbol handling was added
KO> to klogd, ksymoops was built
"KO" == Keith Owens [EMAIL PROTECTED] writes:
KO klogd maps the kernel messages from ntext to syslog levels and
KO does some fiddling with kernel log levels at start up. It needs
KO to be more than a simple 'cat'. When symbol handling was added
KO to klogd, ksymoops was built into the
"GN" == Georg Nikodym [EMAIL PROTECTED] writes:
GN Here's a patch (against sysklogd-1.3-31) that completely tear out
GN the symbol processing code.
Doh! Forgot a chunk (to be applied after the others):
diff -Nru a/src/sysklogd-1.3-31/Makefile b/src/sysklogd-1.3-31/Makefile
---
On Mon, 11 Dec 2000 20:13:46 -0500 (EST),
"Georg Nikodym" [EMAIL PROTECTED] wrote:
Here's a patch (against sysklogd-1.3-31) that completely tear out the
symbol processing code.
Looks good, except that you need to keep the option flags for backwards
compatibility. There are a *lot* of scripts
"KO" == Keith Owens [EMAIL PROTECTED] writes:
KO Looks good, except that you need to keep the option flags for
KO backwards compatibility. There are a *lot* of scripts out there
KO which invoke klogd with various options and they will fail with
KO this change. It is OK to issue a warning
[Georg Nikodym]
+ case 'x':
+ fprintf(stderr,
+ "klogd: %c option is obsolete. Ignoring\n", ch);
Clearer (IMHO): "klogd: warning: ignoring obsolete option '-%c'\n", ch);
Peter
-
To unsubscribe from this list: send the
On Fri, 8 Dec 2000 11:30:06 -0500 (EST),
"Georg Nikodym" <[EMAIL PROTECTED]> wrote:
>But since you seem to and while we're doing extreme surgery, why have
>klogd at all? Every other unix, kernel messages are handled by the
>syslog system. What problem did klogd solve and does that problem
> "KO" == Keith Owens <[EMAIL PROTECTED]> writes:
KO> You only removed the module symbol handling. The problem is that
KO> the entire klogd oops handling is out of date and broken. I
KO> recommend removing all oops processing from klogd, which means
KO> that klogd does not need any
"KO" == Keith Owens [EMAIL PROTECTED] writes:
KO You only removed the module symbol handling. The problem is that
KO the entire klogd oops handling is out of date and broken. I
KO recommend removing all oops processing from klogd, which means
KO that klogd does not need any symbols nor
On Fri, 8 Dec 2000 11:30:06 -0500 (EST),
"Georg Nikodym" [EMAIL PROTECTED] wrote:
But since you seem to and while we're doing extreme surgery, why have
klogd at all? Every other unix, kernel messages are handled by the
syslog system. What problem did klogd solve and does that problem
still
On Thu, 7 Dec 2000 12:36:01 -0500 (EST),
"Georg Nikodym" <[EMAIL PROTECTED]> wrote:
>> "KO" == Keith Owens <[EMAIL PROTECTED]> writes:
>
> KO> I would prefer to see the oops decoding completely removed from
> KO> klogd.
>
>Since nobody else has weighed in on this issue, I quickly did the
> "KO" == Keith Owens <[EMAIL PROTECTED]> writes:
KO> I would prefer to see the oops decoding completely removed from
KO> klogd. The only justification for klogd converting the oops is
KO> to save users from running ksymoops by hand. I would not mind
KO> klogd capturing the oops text,
"KO" == Keith Owens [EMAIL PROTECTED] writes:
KO I would prefer to see the oops decoding completely removed from
KO klogd. The only justification for klogd converting the oops is
KO to save users from running ksymoops by hand. I would not mind
KO klogd capturing the oops text, forking to
On Thu, 7 Dec 2000 12:36:01 -0500 (EST),
"Georg Nikodym" [EMAIL PROTECTED] wrote:
"KO" == Keith Owens [EMAIL PROTECTED] writes:
KO I would prefer to see the oops decoding completely removed from
KO klogd.
Since nobody else has weighed in on this issue, I quickly did the
necessary to effect
On Wed, 6 Dec 2000 17:24:58 -0500 (EST),
"Georg Nikodym" <[EMAIL PROTECTED]> wrote:
>sysklogd 1.3-31 no longer compiles using the latest headers in test11.
>
>Strictly speaking this isn't a kernel bug...
>
>sysklogd's ksym_mod.c includes
Speaking as the modutils maintainer and the person who
sysklogd 1.3-31 no longer compiles using the latest headers in test11.
Strictly speaking this isn't a kernel bug...
sysklogd's ksym_mod.c includes
In test11, added struct inter_module_entry. Its
first member is "struct list_head list;". This necessitates the
inclusion of .
The trouble is
sysklogd 1.3-31 no longer compiles using the latest headers in test11.
Strictly speaking this isn't a kernel bug...
sysklogd's ksym_mod.c includes linux/module.h
In test11, linux/module.h added struct inter_module_entry. Its
first member is "struct list_head list;". This necessitates the
On Wed, 6 Dec 2000 17:24:58 -0500 (EST),
"Georg Nikodym" [EMAIL PROTECTED] wrote:
sysklogd 1.3-31 no longer compiles using the latest headers in test11.
Strictly speaking this isn't a kernel bug...
sysklogd's ksym_mod.c includes linux/module.h
Speaking as the modutils maintainer and the
On Wed, Nov 29 2000, Linus Torvalds wrote:
> I would much rather actually go back to the original setup, which did
> nothing at all if the queue wasn't plugged in the first place.
But that potentially breaks devices that either don't use plugging
or alternatively implement their own, because
On Wed, 29 Nov 2000, Jens Axboe wrote:
>
> I agree with your reasoning, even if the s390 behaviour is a bit
> "non-standard" wrt block devices. Linus, could you apply?
>
> --- drivers/block/ll_rw_blk.c~Wed Nov 29 15:17:33 2000
> +++ drivers/block/ll_rw_blk.c Wed Nov 29 15:18:43 2000
>
On Wed, Nov 29 2000, [EMAIL PROTECTED] wrote:
> request queue to put them on its internal queue. You could argue
> that it shouldn't dequeue request if q->plugged == 1. On the other
> hand why not, before the disk has nothing to do. Anyway the result
I agree with your reasoning, even if the s390
Hi,
I experienced disk hangs with linux-2.4.0-test11 on S/390 and after
some debugging I found the cause. It the new method of unplugging
block devices that doesn't go along with the S/390 disk driver:
/*
* remove the plug and let it rip..
*/
static inline void __generic_unplug_device
Hi,
I experienced disk hangs with linux-2.4.0-test11 on S/390 and after
some debugging I found the cause. It the new method of unplugging
block devices that doesn't go along with the S/390 disk driver:
/*
* remove the plug and let it rip..
*/
static inline void __generic_unplug_device
On Wed, Nov 29 2000, [EMAIL PROTECTED] wrote:
request queue to put them on its internal queue. You could argue
that it shouldn't dequeue request if q-plugged == 1. On the other
hand why not, before the disk has nothing to do. Anyway the result
I agree with your reasoning, even if the s390
On Wed, 29 Nov 2000, Jens Axboe wrote:
I agree with your reasoning, even if the s390 behaviour is a bit
"non-standard" wrt block devices. Linus, could you apply?
--- drivers/block/ll_rw_blk.c~Wed Nov 29 15:17:33 2000
+++ drivers/block/ll_rw_blk.c Wed Nov 29 15:18:43 2000
@@
On Wed, Nov 29 2000, Linus Torvalds wrote:
I would much rather actually go back to the original setup, which did
nothing at all if the queue wasn't plugged in the first place.
But that potentially breaks devices that either don't use plugging
or alternatively implement their own, because
On Mon, Nov 27, 2000 at 09:09:12PM +0100, Jörg Schütter wrote:
> after upgrading from test9 to test11, skipping test 10, I get
> the messages "_isofs_bmap: block < 0", "_isofs_bmap: block < ..."
> which also means I can't read the cd.
A FAQ. Remove the two lines
- if (filp->f_pos >=
Hello,
after upgrading from test9 to test11, skipping test 10, I get
the messages "_isofs_bmap: block < 0", "_isofs_bmap: block < ..."
which also means I can't read the cd.
I hope I don't missed a flag in the new kernel configuration.
I will attach the configuration file which works fine with
Hello,
after upgrading from test9 to test11, skipping test 10, I get
the messages "_isofs_bmap: block 0", "_isofs_bmap: block ..."
which also means I can't read the cd.
I hope I don't missed a flag in the new kernel configuration.
I will attach the configuration file which works fine with
On Mon, Nov 27, 2000 at 09:09:12PM +0100, Jörg Schütter wrote:
after upgrading from test9 to test11, skipping test 10, I get
the messages "_isofs_bmap: block 0", "_isofs_bmap: block ..."
which also means I can't read the cd.
A FAQ. Remove the two lines
- if (filp-f_pos =
ables-2.4.0-test11.patch.gz.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For Th
Hi!
On Thu, 23 Nov 2000, Adam J. Richter wrote:
> The following patch adds some missing PCI_VENDOR_ID's and
> PCI_DEVICE_ID's that are scattered throughout a bunch of .c files in
> drivers/isdn/hisax/. The definitions in the .c files are protected
> by '#ifndef PCI_VENDOR_ID_...', so it
Hi!
On Thu, 23 Nov 2000, Adam J. Richter wrote:
The following patch adds some missing PCI_VENDOR_ID's and
PCI_DEVICE_ID's that are scattered throughout a bunch of .c files in
drivers/isdn/hisax/. The definitions in the .c files are protected
by '#ifndef PCI_VENDOR_ID_...', so it is
EVICE_ID_ARK_STING 0xa091
--- linux-2.4.0-test11/drivers/atm/ambassador.c Thu Jul 6 21:37:24 2000
+++ linux/drivers/atm/ambassador.c Thu Nov 23 21:08:24 2000
@@ -326,6 +326,17 @@
static const unsigned long onegigmask = -1 30;
+static struct pci_device_id ambassador_pci_tbl[] _
[Adam J. Richter]
> +#define PCI_VENDOR_ID_ELSA 0x1048
> +#define PCI_DEVICE_ID_ELSA_MIRCOLINK 0x1000
> +#define PCI_DEVICE_ID_ELSA_QS30000x3000
Oh, don't propagate the typo. Spell it MICROLINK here and in
hisax/elsa.c.
> #define PCI_VENDOR_ID_PLX0x10b5
> +#define
Pavel Machek wrote:
>
> Hi!
>
> > > I also agree that the ioctl patch is kind of a bandaid over
> > > the problems that you described, and, while Zach Brown can speak
> >
> > The biggest problem is that the current code is gross gross gross.
> > I've been avoiding dealing with it too much
Hi!
> > I also agree that the ioctl patch is kind of a bandaid over
> > the problems that you described, and, while Zach Brown can speak
>
> The biggest problem is that the current code is gross gross gross.
> I've been avoiding dealing with it too much in the hopes that moving to
>
[Adam J. Richter]
> +static struct pci_device_id isicom_pci_tbl[] __initdata = {
> + { VENDOR_ID, 0x2028, PCI_ANY_ID, PCI_ANY_ID },
> + { VENDOR_ID, 0x2051, PCI_ANY_ID, PCI_ANY_ID },
> + { VENDOR_ID, 0x2052, PCI_ANY_ID, PCI_ANY_ID },
> + { VENDOR_ID, 0x2053, PCI_ANY_ID,
[Adam J. Richter]
+static struct pci_device_id isicom_pci_tbl[] __initdata = {
+ { VENDOR_ID, 0x2028, PCI_ANY_ID, PCI_ANY_ID },
+ { VENDOR_ID, 0x2051, PCI_ANY_ID, PCI_ANY_ID },
+ { VENDOR_ID, 0x2052, PCI_ANY_ID, PCI_ANY_ID },
+ { VENDOR_ID, 0x2053, PCI_ANY_ID, PCI_ANY_ID },
Hi!
I also agree that the ioctl patch is kind of a bandaid over
the problems that you described, and, while Zach Brown can speak
The biggest problem is that the current code is gross gross gross.
I've been avoiding dealing with it too much in the hopes that moving to
oss_audio will
Pavel Machek wrote:
Hi!
I also agree that the ioctl patch is kind of a bandaid over
the problems that you described, and, while Zach Brown can speak
The biggest problem is that the current code is gross gross gross.
I've been avoiding dealing with it too much in the hopes
[Adam J. Richter]
+#define PCI_VENDOR_ID_ELSA 0x1048
+#define PCI_DEVICE_ID_ELSA_MIRCOLINK 0x1000
+#define PCI_DEVICE_ID_ELSA_QS30000x3000
Oh, don't propagate the typo. Spell it MICROLINK here and in
hisax/elsa.c.
#define PCI_VENDOR_ID_PLX0x10b5
+#define
The following patch adds a pci_device_id table and a
MODULE_DEVICE_TABLE delcaration to each remaining PCI driver
in linux-2.4.0-test11/drivers/char/. I have used the named initializer
format for drivers that have only one or two PCI entries, initialize from
anonymous integers or where
>"Adam J. Richter" wrote:
>> Just to avoid duplication of effort, I am posting this preliminary
>> patch which adds PCI MODULE_DEVICE_TABLE declarations to the three PCI
>> drivers in linux-2.4.0-test11/drivers/block. In response to input from
>>
Adam J. Richter writes:
> + { PCI_VENDOR_ID_DEC, PCI_DEVICE_ID_DEC_21285, PCI_ANY_ID, PCI_ANY_ID},
No no no no no no no.
This "device" should be identified by either the class code OR the
subsystem device/vendor IDs.
By using "PCI_VENDOR_ID_DEC" and "PCI_DEVICE_ID_DEC_21285" you are
Andi Kleen wrote:
>
> On Wed, Nov 22, 2000 at 05:14:38PM -0500, Jeff Garzik wrote:
> > *This* is the over-engineering attitude I was talking about. The only
> > reason why you are preferring named initializers is because
> > pci_device_id MIGHT be changed. And if it is changed, it makes the
>
On Wed, Nov 22, 2000 at 05:14:38PM -0500, Jeff Garzik wrote:
> *This* is the over-engineering attitude I was talking about. The only
> reason why you are preferring named initializers is because
> pci_device_id MIGHT be changed. And if it is changed, it makes the
> changeover just tad easier.
"Adam J. Richter" wrote:
> Just to avoid duplication of effort, I am posting this preliminary
> patch which adds PCI MODULE_DEVICE_TABLE declarations to the three PCI
> drivers in linux-2.4.0-test11/drivers/block. In response to input from
> Christoph Hell
Just to avoid duplication of effort, I am posting this preliminary
patch which adds PCI MODULE_DEVICE_TABLE declarations to the three PCI
drivers in linux-2.4.0-test11/drivers/block. In response to input from
Christoph Hellwig, I have reduced my threshhold on using named initializers
It seems like lastest kernels cannot run lmbench successfully.
lmbench stops at "Local networking", between lat_connect
and bw_tcp, as far as I can see from 'top'.
No errors reported, lat_connect or bw_tcp exit silently.
All 2.4.0-test[5-11] seem to have this problem.
2.4.0-test1 and 2.2.x all
It seems like lastest kernels cannot run lmbench successfully.
lmbench stops at "Local networking", between lat_connect
and bw_tcp, as far as I can see from 'top'.
No errors reported, lat_connect or bw_tcp exit silently.
All 2.4.0-test[5-11] seem to have this problem.
2.4.0-test1 and 2.2.x all
Just to avoid duplication of effort, I am posting this preliminary
patch which adds PCI MODULE_DEVICE_TABLE declarations to the three PCI
drivers in linux-2.4.0-test11/drivers/block. In response to input from
Christoph Hellwig, I have reduced my threshhold on using named initializers
"Adam J. Richter" wrote:
Just to avoid duplication of effort, I am posting this preliminary
patch which adds PCI MODULE_DEVICE_TABLE declarations to the three PCI
drivers in linux-2.4.0-test11/drivers/block. In response to input from
Christoph Hellwig, I have reduced my
On Wed, Nov 22, 2000 at 05:14:38PM -0500, Jeff Garzik wrote:
*This* is the over-engineering attitude I was talking about. The only
reason why you are preferring named initializers is because
pci_device_id MIGHT be changed. And if it is changed, it makes the
changeover just tad easier. For
Andi Kleen wrote:
On Wed, Nov 22, 2000 at 05:14:38PM -0500, Jeff Garzik wrote:
*This* is the over-engineering attitude I was talking about. The only
reason why you are preferring named initializers is because
pci_device_id MIGHT be changed. And if it is changed, it makes the
Adam J. Richter writes:
+ { PCI_VENDOR_ID_DEC, PCI_DEVICE_ID_DEC_21285, PCI_ANY_ID, PCI_ANY_ID},
No no no no no no no.
This "device" should be identified by either the class code OR the
subsystem device/vendor IDs.
By using "PCI_VENDOR_ID_DEC" and "PCI_DEVICE_ID_DEC_21285" you are
"Adam J. Richter" wrote:
Just to avoid duplication of effort, I am posting this preliminary
patch which adds PCI MODULE_DEVICE_TABLE declarations to the three PCI
drivers in linux-2.4.0-test11/drivers/block. In response to input from
Christoph Hellwig, I have reduced my
The following patch adds a pci_device_id table and a
MODULE_DEVICE_TABLE delcaration to each remaining PCI driver
in linux-2.4.0-test11/drivers/char/. I have used the named initializer
format for drivers that have only one or two PCI entries, initialize from
anonymous integers or where
[first off, thanks for kicking this stuff into gear Adam. I'm way too
lazy to do this stuff of my own volition :)]
> >was to serialize access to the mixer, there are surely better ways to do
> >it. Why are interrupts disabled?
the maestro has crappy register indirection that you must use to
> Unrelated to your change: the maestro reboot notifier shouldn't need to
> unregister all that stuff. Who cares if the sound devices are freed,
> since we are rebooting. free_irq+maestro_power seems sufficient. or
> maybe stop_dma+free_irq+poweroff.
its only the power stuff that matters.
I forgot to mention that I have tested the updated maestro.c
patch that I just submitted by loading the module on a
notebook computer, playing some sound, and unloading it.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /
Jeff Garzik critiqued my patch for linux-2.4.0-test11/drivers/sound/maestro.c:
>[...] if the intention
>was to serialize access to the mixer, there are surely better ways to do
>it. Why are interrupts disabled?
As far as I can tell, I agree with you, but I do not think
that i
"Adam J. Richter" wrote:
>
> Here is a patch which ports drivers/sound/maestro.c to the new PCI
> interface, which Zach Brown asked me to post here for comments.
> This patch includes Zach's changes eliminating the ioctl lockups which
> he posted separately, just to make it easier to generate
8 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
--- linux-2.4.0-test11/drivers/sound/maestro.c Sat Nov 11 18:33:13 2000
+++ linux/drivers/sound/maestro.c Wed Nov 15 22:25:42 2000
@@ -243,7 +243,6 @@
#
Jeff Garzik critiqued my patch for linux-2.4.0-test11/drivers/sound/maestro.c:
[...] if the intention
was to serialize access to the mixer, there are surely better ways to do
it. Why are interrupts disabled?
As far as I can tell, I agree with you, but I do not think
that is related
I forgot to mention that I have tested the updated maestro.c
patch that I just submitted by loading the module on a
notebook computer, playing some sound, and unloading it.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /
Unrelated to your change: the maestro reboot notifier shouldn't need to
unregister all that stuff. Who cares if the sound devices are freed,
since we are rebooting. free_irq+maestro_power seems sufficient. or
maybe stop_dma+free_irq+poweroff.
its only the power stuff that matters. some
[first off, thanks for kicking this stuff into gear Adam. I'm way too
lazy to do this stuff of my own volition :)]
was to serialize access to the mixer, there are surely better ways to do
it. Why are interrupts disabled?
the maestro has crappy register indirection that you must use to do
On Sun, 19 Nov 2000, Linus Torvalds wrote:
> - Asit Mallick: enable the APIC in the official order
What is this intended to fix? Please revert it -- it breaks for i82489DX
APICs configured to the PIC mode upon boot -- local interrupt registers
are hardwired to 0x0001 and cannot be
On Sun, 19 Nov 2000, Rich Baum wrote:
>
> The patch is in the v2.3 directory. You may want to move it to the
> v2.4 directory so people can find it easier.
Oops. Thanks. Done.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
The patch is in the v2.3 directory. You may want to move it to the
v2.4 directory so people can find it easier.
On 19 Nov 2000, at 18:19, Linus Torvalds wrote:
>
> Ok, test11 is out there. The most noticeable fixes since pre7 are the
> Athlon lockup fix, the PCI routing handling, and getting
Ok, test11 is out there. The most noticeable fixes since pre7 are the
Athlon lockup fix, the PCI routing handling, and getting the Joliet stuff
right for iso9660.
Linus
- final:
- Patrick Mochel: export the ACPI facs table in /proc too
- Brian Gerst: Video4Linux
The patch is in the v2.3 directory. You may want to move it to the
v2.4 directory so people can find it easier.
On 19 Nov 2000, at 18:19, Linus Torvalds wrote:
Ok, test11 is out there. The most noticeable fixes since pre7 are the
Athlon lockup fix, the PCI routing handling, and getting
On Sun, 19 Nov 2000, Rich Baum wrote:
The patch is in the v2.3 directory. You may want to move it to the
v2.4 directory so people can find it easier.
Oops. Thanks. Done.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Sun, 19 Nov 2000, Linus Torvalds wrote:
- Asit Mallick: enable the APIC in the official order
What is this intended to fix? Please revert it -- it breaks for i82489DX
APICs configured to the PIC mode upon boot -- local interrupt registers
are hardwired to 0x0001 and cannot be
.c
inode.c:1054: conflicting types for `new_inode'
/usr/src/linux/include/linux/fs.h:1153: previous declaration of
`new_inode'
make[3]: *** [inode.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.4.0-test11-pre6/fs/ntfs'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/l
.c
inode.c:1054: conflicting types for `new_inode'
/usr/src/linux/include/linux/fs.h:1153: previous declaration of
`new_inode'
make[3]: *** [inode.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.4.0-test11-pre6/fs/ntfs'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/l
I think the definition of ISAPNP_DEVICE in
linux-2.4.0-test11-pre5/include/linux/isapnp.h is unnecessarily complex.
Here is a proposed patch.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California
I think the definition of ISAPNP_DEVICE in
linux-2.4.0-test11-pre5/include/linux/isapnp.h is unnecessarily complex.
Here is a proposed patch.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California
linux-2.4.0-test11-pre5/drivers/net/hamradio/baycomm_epp.c and
linux-2.4.0-test11-pre5/drivers/net/hamradio/soundmodem.h refer to
current_cpu.x86_capability, which has changed from an integer to
an array, causing compile errors in these files. Here is a proposed
patch. Thomas, will you
Jeff Garzik wrote:
>"Adam J. Richter" wrote:
>> You were right: the
>> __devinitdata being used in the USB drivers will probably crash the
>> kernel if CONFIG_HOTPLUG is not defined and the USB code attempts to
>> recover from an error by faking disconnect/reconnect.
>[...]
>> Until there
Hi Adam,
> From: Adam J. Richter [mailto:[EMAIL PROTECTED]]
>
> >From [EMAIL PROTECTED] Wed Nov 15 09:04:36 2000
> >> From: Jeff Garzik [mailto:[EMAIL PROTECTED]]
> >>
> >> Greg KH wrote:
> >> > On Wed, Nov 15, 2000 at 12:29:15AM -0500, Jeff Garzik wrote:
> >> > > If we are going to create
"Adam J. Richter" wrote:
> You were right: the
> __devinitdata being used in the USB drivers will probably crash the
> kernel if CONFIG_HOTPLUG is not defined and the USB code attempts to
> recover from an error by faking disconnect/reconnect.
[...]
> Until there is
>From [EMAIL PROTECTED] Wed Nov 15 09:04:36 2000
>> From: Jeff Garzik [mailto:[EMAIL PROTECTED]]
>>
>> Greg KH wrote:
>> > On Wed, Nov 15, 2000 at 12:29:15AM -0500, Jeff Garzik wrote:
>> > > If we are going to create CONFIG_USB_HOTPLUG, we must -eliminate-
>> > > CONFIG_HOTPLUG, and create
> From: Jeff Garzik [mailto:[EMAIL PROTECTED]]
>
> Greg KH wrote:
> > On Wed, Nov 15, 2000 at 12:29:15AM -0500, Jeff Garzik wrote:
> > > If we are going to create CONFIG_USB_HOTPLUG, we must -eliminate-
> > > CONFIG_HOTPLUG, and create CONFIG_PCI_HOTPLUG, and
> > > CONFIG_ANOTHERBUS_HOTPLUG and
> = Greg KH
>> = Jeff Garzik
>> I -want- there to be only one hotplug strategy, but Adam seemed to be
>> talking about the opposite, with his CONFIG_USB_HOTPLUG suggestion.
>Here's Adam's proposal for CONFIG_USB_HOTPLUG:
> http://www.geocrawler.com/lists/3/SourceForge/2571/250/4599696/
= Greg KH
= Jeff Garzik
I -want- there to be only one hotplug strategy, but Adam seemed to be
talking about the opposite, with his CONFIG_USB_HOTPLUG suggestion.
Here's Adam's proposal for CONFIG_USB_HOTPLUG:
http://www.geocrawler.com/lists/3/SourceForge/2571/250/4599696/
Thanks,
From: Jeff Garzik [mailto:[EMAIL PROTECTED]]
Greg KH wrote:
On Wed, Nov 15, 2000 at 12:29:15AM -0500, Jeff Garzik wrote:
If we are going to create CONFIG_USB_HOTPLUG, we must -eliminate-
CONFIG_HOTPLUG, and create CONFIG_PCI_HOTPLUG, and
CONFIG_ANOTHERBUS_HOTPLUG and so on, for
1 - 100 of 135 matches
Mail list logo
