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. Beside
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 wit
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
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 te
[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 t
> "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 script
> "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
--- a/sr
> "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 int
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
>stil
> "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 symb
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
>nec
> "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, f
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 ad
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
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 q->p
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_d
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 >= inod
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
dist/device_control/kernel/pci_id_tables-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-6
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
[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 PC
--
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 The Rest Of Us."
--- linux-2.4.0-test11/inclu
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
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_audi
[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
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 ref
On Wed, 22 Nov 2000 14:01:36 -0800,
"Adam J. Richter" <[EMAIL PROTECTED]> 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/blo
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. F
"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
to
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 r
[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
> 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. so
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 the
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 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 +2
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 chan
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 me
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 c
.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 direct
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 CONF
"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 __usbdev{init,exit}{,da
>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 CONFIG
> 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 s
> = 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/
Jeff Garzik wrote:
>"Adam J. Richter" wrote:
>> If a programmer errs in favor of __devinit, the result is
>> extra memory consumption under CONFIG_HOTPLUG. If a programmer
>> errs in favor of __init, the result is a crash during hot p
>> ug insertion. Avoiding crashes at the expensive of
On Wed, Nov 15, 2000 at 12:54:35AM -0500, Jeff Garzik wrote:
>
> 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/So
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 each hotplug bus.
>
> Argh!
> I thought the whole
On Wed, Nov 15, 2000 at 12:29:15AM -0500, Jeff Garzik wrote:
>
> This is not just a USB issue. Please discuss this on linux-kernel, so
> we can have a coherent hotplug strategy for the entire kernel.
I agree. If I see the topic come up on linux-usb-devel again, I'll push
it over to linux-kerne
hot plugging regardless of whether CONFIG_HOTPLUG is
> specified.
>
> bash% find linux-2.4.0-test11-pre4/drivers/usb -type f | xargs egrep HOTPLUG
Read the code. test11-pre[34] was broken due to my recent
CONFIG_KMOD/CONFIG_HOTPLUG separation, and should have had
CONFIG_HOTPLUG. test11-p
but USB users too...
We have been discussing this on linux-devel-usb. The
latest patches submitted to Linus and in 2.4.0-test10-pre{3,4}
support USB hot plugging regardless of whether CONFIG_HOTPLUG is
specified.
bash% find linux-2.4.0-test11-pre4/drivers/usb -type f | xargs egrep HO
On Tue, 14 Nov 2000, Jeff Garzik wrote:
> Bartlomiej Zolnierkiewicz wrote:
> >
> > On Mon, 13 Nov 2000, Adam J. Richter wrote:
> >
> > > linux-2.4.0-test11-pre4/drivers/sound/yss225.c uses __initdata
> > > but does not include , so it could no
Bartlomiej Zolnierkiewicz wrote:
>
> On Mon, 13 Nov 2000, Adam J. Richter wrote:
>
> > linux-2.4.0-test11-pre4/drivers/sound/yss225.c uses __initdata
> > but does not include , so it could not compile. I have
> > attached below.
> >
> > N
On Mon, 13 Nov 2000, Adam J. Richter wrote:
> linux-2.4.0-test11-pre4/drivers/sound/yss225.c uses __initdata
> but does not include , so it could not compile. I have
> attached below.
>
> Note that I am a bit uncertain about the correctness of
> the __initdata
linux-2.4.0-test11-pre4/drivers/sound/yss225.c uses __initdata
but does not include , so it could not compile. I have
attached below.
Note that I am a bit uncertain about the correctness of
the __initdata prefix here in the first place. Is yss225 a PCI
device? If so, a
linux-2.4.0-test11-pre{3,4}/drivers/net/irda/toshoboe.c contains
a reference to the undefined symbol toshoboe_change_speed. I guess
this should be a reference to toshoboe_setbaud. Because I am not
positive, I am not sending this message directly to Linus, but I
am cc'ing it to
linux-2.4.0-test11-pre{3,4}/drivers/net/irda/smc-ircc.c contains
a reference to the undefined symbol smcc_ircc_change_speed. I guess
this should be a reference to ircc_change_speed. Because I am not
positive, I am not sending this message directly to Linus, but I
am cc'ing it to
"reiser.angus" <[EMAIL PROTECTED]> writes:
> cannot make a success compilation of 2.4.0-test11pre2 with the same
> .config than for a successfull 2.4.0-test10 compilation.
> Same problem when apply patch-2.4.0test11pre2-ac1 from alan cox
>
> arch/i386/mm/mm.o: In function `do_page_fault':
> arch
* [vmlinux] Error 1
It was inside an ifdef. Apologies.
This patch against test11-pre2 moves it to fault.c.
--- linux-2.4.0-test11-pre2/arch/i386/kernel/traps.cFri Nov 10 15:59:15 2000
+++ linux/arch/i386/kernel/traps.c Fri Nov 10 15:52:40 2000
@@ -63,6 +63,7 @@
struct desc_struct idt
cannot make a success compilation of 2.4.0-test11pre2 with the same
.config than for a successfull 2.4.0-test10 compilation.
Same problem when apply patch-2.4.0test11pre2-ac1 from alan cox
arch/i386/mm/mm.o: In function `do_page_fault':
arch/i386/mm/mm.o(.text+0x821): undefined reference to `bus
71 matches
Mail list logo