* Re: New NUMA scheduler and hotplug CPU
From: Martin J. Bligh @ 2004-01-27 7:19 UTC (permalink / raw)
To: Nick Piggin, Rusty Russell; +Cc: linux-kernel
In-Reply-To: <4015F9A8.6000801@cyberone.com.au>
> Well lets not worry too much about this for now. We could use
> static arrays and cpu_possible for now until we get a feel
> for what specific architectures want.
>
> To be honest I haven't seen the hotplug CPU code and I don't
> know about what architectures want to be doing with it, so
> this is my preferred direction just out of ignorance.
>
> An easy next step toward a dynamic scheme would be just to
> re-init the entire sched domain topology (the generic init uses
> the generic NUMA topology info which will have to be handled
> by these architectures anyway). Modulo a small locking problem.
>
> There aren't any fundamental design issues (with sched domains)
> that I can see preventing a more dynamic system so we can keep
> that in mind.
Yeah, I talked it over with Rusty some on IRC. I have more of a feeling
why he's trying to do it that way now. However, one other thought occurs
to me ... it'd be good to use the same infrastructure (sched domains)
for the workload management stuff as well (where the domains would be
defined from userspace). That'd also necessitate them being dynamic,
if you think that'd work out as a usage model.
The cpu_possible stuff might work for a first cut at hotplug I guess.
I still think it's ugly though ;-)
M.
^ permalink raw reply
* Re: atkbd.c: Unknown key released
From: Voluspa @ 2004-01-27 7:16 UTC (permalink / raw)
To: linux-kernel
On 2004-01-27 it was written:
> > I keep getting the following in my syslog whenever I startx:
In fact, it is preemptively written even _before_ I start X :-)
I'm using an ancient IBM PS2 swedish keyboard, and this 0x7a crap began
showing somewhere at 2.6.1 (then without blaming X). Now it is - and the
blame on X came with 2.6.2-rc2:
Booting:
Jan 26 16:29:10 loke kernel: atkbd.c: Unknown key released (translated
set 2, code 0x7a on isa0060/serio0).
Jan 26 16:29:10 loke kernel: atkbd.c: This is an XFree86 bug. It
shouldn't access hardware directly.
Jan 26 16:29:11 loke kernel: atkbd.c: Unknown key released (translated
set 2, code 0x7a on isa0060/serio0).
Jan 26 16:29:11 loke kernel: atkbd.c: This is an XFree86 bug. It
shouldn't access hardware directly.
Starting X:
Jan 26 16:33:50 loke kernel: atkbd.c: Unknown key released (translated
set 2, code 0x7a on isa0060/serio0).
Jan 26 16:33:50 loke kernel: atkbd.c: This is an XFree86 bug. It
shouldn't access hardware directly.
Jan 26 16:33:50 loke kernel: atkbd.c: Unknown key released (translated
set 2, code 0x7a on isa0060/serio0).
Jan 26 16:33:50 loke kernel: atkbd.c: This is an XFree86 bug. It
shouldn't access hardware directly.
Mvh
Mats Johannesson
^ permalink raw reply
* Re: udevinfo query
From: Kay Sievers @ 2004-01-27 7:12 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20040127030511.18446.qmail@web14914.mail.yahoo.com>
On Mon, Jan 26, 2004 at 07:05:11PM -0800, Jon Smirl wrote:
> It would be nice to be able to query for the full path to the node. This would
> make it easier to script things. Instead of "udevinfo -r" and "udevinfo -p
> /class/dri/card0 -q name", I could just do something like "udevinfo -p
> /class/dri/card0 -q fullname" and get back /udev/dri/card0
You don't like man pages, or do you?
-r Print the the udev_root directory. When used
in conjunction with a query for the node name, the
udev_root will be prepended.
/sbin/udevinfo -r -p /sys/class/video4linux/video0 -q name
/udev/video/webcam0
> I tried "udevinfo -p /class/dri/card0 -q name" without udev running. It gives
> the error "device not found in database". udevinfo -r returns "/udev/".
> Shouldn't these messages be changed to indicate that udev is not mounted and
> running?
What do you mean with 'running'?
If you have a database we query it, if you don't have it, we will fail
with "unable to open udev database". That's perfectly ok, I think.
Kay
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: atkbd.c: Unknown key released
From: Vojtech Pavlik @ 2004-01-27 7:12 UTC (permalink / raw)
To: yoann; +Cc: linux-kernel
In-Reply-To: <bv4vbb$ru3$1@sea.gmane.org>
On Tue, Jan 27, 2004 at 07:09:56AM +0100, yoann wrote:
> >>I keep getting the following in my syslog whenever I startx:
> >
> >Which hardware?
> >
> >>Jan 26 13:43:56 debian kernel: atkbd.c: Unknown key released (translated
> >>set 2, code 0x7a on isa0060/serio0).
> >>Jan 26 13:43:56 debian kernel: atkbd.c: This is an XFree86 bug. It
> >>shouldn't access hardware directly.
> >>Jan 26 13:43:57 debian kernel: atkbd.c: Unknown key released (translated
> >>set 2, code 0x7a on isa0060/serio0).
> >>Jan 26 13:43:57 debian kernel: atkbd.c: This is an XFree86 bug. It
> >>shouldn't access hardware directly.
> >>
> >>I don't get the error with the 2.4.24 kernel.
> >
> >Same here.
>
> same here with a 2.6.2-rc1-mm2
> Xfree86 Version: 4.2.1-15 (debian sid)
2.4 just keeps its mouth shut and doesn't complain.
Hopefully someone fixes X.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply
* Re: Q: Filesystem choice..
From: Eric W. Biederman @ 2004-01-27 7:13 UTC (permalink / raw)
To: manningc2; +Cc: linux-mtd
In-Reply-To: <20040127042233.C8D0416623@desire.actrix.co.nz>
Charles Manning <manningc2@actrix.gen.nz> writes:
>
> First up: Do you really need a full-blown file system? Maybe something more
> along the lines of a linear file store is more suited. Maybe too just some
> basic storage in binary partitions.
As I don't have one at the moment I don't. At the moment I am considering
my options. I am looking at having several different pieces of firmware
by different authors so a filesystem would be useful.
> YAFFS is not really designed for NOR, though it has been used for NOR. For
> the sizes you're talking about YAFFS would not really be a good choice
> because the file headers use one "chunk" per file. THis eases garbage
> collection, but swallows flash.
Thanks, that was my impression but having it confirmed is appreciated.
Eric
^ permalink raw reply
* re ax25 support in aprsd
From: John Williams @ 2004-01-27 7:05 UTC (permalink / raw)
To: linux-hams
OK
second, third and fourth appear to have filtered feeds.
In the case of third they are
23 & 10152 Full APRS-IS Feed (no echo)
10151 Full APRS-IS Feed (echo)
10153 Full APRS-IS Feed w/ 30 Minute Dump
1314 Messages Only
14580 User Defined Filtering & CW
14579 East Coast USA Only Feed
10154 USA Only Feed
10155 Europe Only Feed
14501 Status Page (html)
14511 Status Page (text)
So if you did this
Server third.aprs.net 14579 hub-sr
You would only see East cost US stations.
For your area in CA you will probably want to define your own filter
In this case used port 14580 and use the range and or prefix filters.
Read the info in this link.
http://www.aprsfl.net/status.txt
Cheers
John
VK5ZTY
^ permalink raw reply
* Re: [Bluez-devel] Device specific pins
From: Eugene Crosser @ 2004-01-27 7:05 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Dave Henriksen, BlueZ Mailing List
In-Reply-To: <1075151423.25442.135.camel@pegasus>
[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]
On Tue, 2004-01-27 at 00:10, Marcel Holtmann wrote:
> > Just wondering if there is any way to have pins that vary depending upon
> > what device you are connecting to. Currently, I just use
> > /etb/bluetooth/givepin to supply a pin, but this pin must be the same
> > for every device that my Linux laptop connects to.
>
> this is a planned future for the new security manager which also
> includes one-time PIN codes.
>
> For the current version you must do it by yourself in a pin-helper
> script. The BD_ADDR of the remote device is one of the parameters.
Do you think it might be right to leave "low level" PIN management as it
is now, via an executable helper? It is very much the same way as
kernel "hotplug" works. So it can stay the same even if hcid eventually
becomes a kernel thread.
The "real" PIN management, with the database, GUI prompt boxes etc.
could be isolated from the BT stack, helper executable being the only
interface.
E.g., a Gnome or KDE applet could listen on a unix domain socket. The
helper, when invoked, would try to talk over this socket, and if the
latter is not present or nobody listens on it, default to preexisting
database. This way, both fancy GUI dialogues and unattended operation
could be implemented rather easily.
Sorry if I say stupid or trivial things, I did not really try to learn
how these things are currently done in Blues..
Eugene
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [U-Boot-Users] tftpboot of BIG file fails !
From: Wolfgang Denk @ 2004-01-27 6:57 UTC (permalink / raw)
To: u-boot
In-Reply-To: <01a401c3e2a9$c29a0510$6706a8c0@Rupesh>
In message <01a401c3e2a9$c29a0510$6706a8c0@Rupesh> you wrote:
>
> I find a typical problem downloading a BIG ( 4MB) linux image to the SDRAM
I don't think this is a typical problem. On contrary, it is a very
UNtypical problem since this has always been working fine on many,
many boards.
> using u-boot's _tftpboot_ command.
> The Linux image is Linked at 0x20000.
Then your Linux image is broken. You must not change the kernel's
link address unless you know exactly what you are doing. This means
that for example on PowerPC the kernel will be linked for (virtual)
address 0xC0000000 and started at (physical) address 0x00000000.
> My u-boot is liked at 0x3e0000 (I understaood this from the following two
> macros)
> TEXT_BASE = 0x3E0000
> CFG_MONITOR_BASE = 0x3E0000
Then your port of U-Boot is seriously broken.
I would like to point out that NONE of the configurations in the
public source tree uses such a broken definition.
> So I reconfigured the macros to link the u-boot on _top_ of the SDRAM (SDRAM
> map is 0x00000000 to 0x01000000)
A correctly configured U-Boot will automatically copy itself at the
end of the RAM (at least on PPC).
> But still I face the problem of not able to download the BIG image.
You probably have other problems in your port.
> Dows the tftp boot itself restrict the size of the file to be downloaded ?
Yes. The current implementation puts a limit at 16 MB.
Best regards,
Wolfgang Denk
--
See us @ Embedded World, Nuremberg, Feb 17 - 19, Hall 12.0 Booth 440
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
Immortality consists largely of boredom.
-- Zefrem Cochrane, "Metamorphosis", stardate 3219.8
^ permalink raw reply
* Re: PATCH: (as177) Add class_device_unregister_wait() and platform_device_unregister_wait() to the driver model core
From: Rusty Russell @ 2004-01-27 6:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: stern, greg, linux-kernel, mochel
In-Reply-To: <Pine.LNX.4.58.0401251054340.18932@home.osdl.org>
On Sun, 25 Jan 2004 11:02:58 -0800 (PST)
Linus Torvalds <torvalds@osdl.org> wrote:
> On Sun, 25 Jan 2004, Alan Stern wrote:
> >
> > Is there some reason why modules don't work like this?
>
> There's a few:
>
> - pain. pain. pain.
>
> - doing proper refcounting of modules is _really_ really hard. The reason
> is that proper refcounting is a "local" issue: you reference count a
> single data structure. It's basically impossible to make a "global"
> reference count without jumping through hoops.
>
> - lack of testing. Unloading a module happens once in a blue moon, if
> even then.
And modules do work like you proposed, if you use "rmmod --wait".
Doing proper refcounting is actually fairly easy: every function pointer
has an associated reference count (or pointer to the module containing
the refcount).
But how much pain are you prepared to put up with to have a pseudo-pagable
kernel?
> (As an example of "too painful, too slow", think of something like a
> packet filter module. You'd literally have to increment the count in every
> part that gets a packet, and decrement the count at every point where it
> lets the packet go. And since it would have to be SMP-safe, it would have
> to be a locked cycle, or we'd have to have per-CPU counters - at which
> point you now also have to worry about things like preemption and
> sleeping, which just means that it would be a _lot_ of very fragile code).
Actually, this is already handled. The module reference counts are per-cpu
and don't contain any barriers. We go to an *awful* lot of pain on remove
to synchronize, but as Linus says, it's not the normal case.
Since we hit the (atomic_t) ref to the devices on every packet, bumping
the refcount on the module is lost in the noise.
But Dave doesn't want to do it: it makes the code uglier and painful.
Cheers,
Rusty.
--
there are those who do and those who hang on and you don't see too
many doers quoting their contemporaries. -- Larry McVoy
^ permalink raw reply
* Re: PATCH: (as177) Add class_device_unregister_wait() and platform_device_unregister_wait() to the driver model core
From: Rusty Russell @ 2004-01-27 6:51 UTC (permalink / raw)
To: viro; +Cc: torvalds, stern, greg, linux-kernel, mochel
In-Reply-To: <20040125202136.GR21151@parcelfarce.linux.theplanet.co.uk>
On Sun, 25 Jan 2004 20:21:37 +0000
viro@parcelfarce.linux.theplanet.co.uk wrote:
> Basically, "protect the module" is wrong - it should be "protect specific
> object" and we need that anyway.
Agreed. You're oversimplifying a little, though.
In this model, the object here is the function text. So if you hand out
a pointer to the function text, you need to hold a refcount.
BUT since the module itself is the only one which can hand these out,
and it unregisters everything it has registered, and all those references
fall to zero, it's trivial to prove that there are no more references to
the module functions.
This (as Al points out by referring to lifetime) is the same problem if you
want to kfree() the thing you've registered: either deregistration is
synchronous or it supplies a callback which does the actual kfree. And most
registration interfaces in the kernel are headed towards this model, and
it can be pressed into service for module removal as well.
Hope that clarifies,
Rusty.
--
there are those who do and those who hang on and you don't see too
many doers quoting their contemporaries. -- Larry McVoy
^ permalink raw reply
* Re: [patch] udevd - cleanup and better timeout handling
From: Kay Sievers @ 2004-01-27 6:56 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20040125200314.GA8376@vrfy.org>
[-- Attachment #1: Type: text/plain, Size: 11813 bytes --]
On Mon, Jan 26, 2004 at 11:28:19AM -0800, Greg KH wrote:
> On Mon, Jan 26, 2004 at 08:11:10PM +0100, Kay Sievers wrote:
> > On Mon, Jan 26, 2004 at 10:22:34AM -0800, Greg KH wrote:
> > > On Sun, Jan 25, 2004 at 09:03:14PM +0100, Kay Sievers wrote:
> > > > 1. We are much too slow.
> > > > We want to exec the real udev in the background, but a 'remove'
> > > > is much much faster than a 'add', so we have a problem.
> > > > Question: is it neccessary to order events for different devpath's?
> > > > If no, we may wait_pid() for the exec only if we have another udev
> > > > working on the same devpath.
> > >
> > > But how will we keep track of that? It's probably easier just to wait
> > > for each one to finish, right?
> >
> > We leave the message in the queue until we reach the SIGCHLD for this
> > pid. So we can search the queue if we are already working on this devpath,
> > and delay the new exec until the former exec comes back.
>
> Ok, if that isn't too much trouble.
>
> > Is it feasible to run in parallel for different paths, or can you think
> > of any problem?
>
> I can't think of any problem with that.
Here is the next round. We have three queues now. All incoming messages
are queued in msg_list and if nothing is missing we move it to the
running_list and exec in the background.
If the exec comes back, it removes the message from the running_list and
frees the message.
Before we exec, we check the running_list if there is a udev running on
the same device path. If yes, we move the message to the delay_list. If
the former exec comes back, we move the message to the running_list and
exec it.
The very first event is delayed now to catch possible earlier sequences,
every following event is executed without delay if no sequence is missing.
The daemon doesn't exit by itself any longer, cause we don't want to
delay every first exec.
I've put a $(PWD) for now in the Makefile for testing this beast. Only
the local binaries are executed, not the /sbin/udev. We can change it
if we are ready for real testing.
And SIGKILL can't be cought, so I removed it from the handler :)
thanks,
Kay
06:58:36 sig_handler: caught signal 15
06:58:36 main: using ipc queue 0x2d548
06:58:37 message is still in the ipc queue, starting daemon...
06:58:37 work: received sequence 3, expected sequence 0
06:58:37 msg_dump_queue: sequence 3 in queue
06:58:37 set_timeout: set timeout in 1 seconds
06:58:37 main: using ipc queue 0x2d548
06:58:37 main: using ipc queue 0x2d548
06:58:37 work: received sequence 1, expected sequence 1
06:58:37 msg_dump_queue: sequence 1 in queue
06:58:37 msg_dump_queue: sequence 3 in queue
06:58:37 msg_dump: sequence 1, 'add', '/block/sda', 'block'
06:58:37 msg_exec: child [8038] created
06:58:37 running_moveto_queue: move sequence 1 [8038] to running queue '/block/sda'
06:58:37 set_timeout: set timeout in 5 seconds
06:58:37 work: received sequence 2, expected sequence 2
06:58:37 msg_dump_queue: sequence 2 in queue
06:58:37 msg_dump_queue: sequence 3 in queue
06:58:37 msg_dump: sequence 2, 'add', '/block/sdb', 'block'
06:58:37 msg_exec: child [8039] created
06:58:37 running_moveto_queue: move sequence 2 [8039] to running queue '/block/sdb'
06:58:37 msg_dump: sequence 3, 'add', '/block/sdc', 'block'
06:58:37 msg_exec: child [8040] created
06:58:37 running_moveto_queue: move sequence 3 [8040] to running queue '/block/sdc'
06:58:37 main: using ipc queue 0x2d548
06:58:37 main: using ipc queue 0x2d548
06:58:37 work: received sequence 4, expected sequence 4
06:58:37 msg_dump_queue: sequence 4 in queue
06:58:37 msg_dump: sequence 4, 'remove', '/block/sdc', 'block'
06:58:37 msg_exec: delay exec of sequence 4, [8040] already working on '/block/sdc'
06:58:37 delayed_moveto_queue: move event to delayed queue '/block/sdc'
06:58:37 msg_exec: child [8043] created
06:58:37 running_moveto_queue: move sequence 4 [8043] to running queue '/block/sdc'
06:58:37 work: received sequence 5, expected sequence 5
06:58:37 msg_dump_queue: sequence 5 in queue
06:58:37 msg_dump: sequence 5, 'remove', '/block/sdb', 'block'
06:58:37 msg_exec: delay exec of sequence 5, [8039] already working on '/block/sdb'
06:58:37 delayed_moveto_queue: move event to delayed queue '/block/sdb'
06:58:37 msg_exec: child [8044] created
06:58:37 running_moveto_queue: move sequence 5 [8044] to running queue '/block/sdb'
06:58:37 main: using ipc queue 0x2d548
06:58:37 main: using ipc queue 0x2d548
06:58:37 work: received sequence 8, expected sequence 6
06:58:37 msg_dump_queue: sequence 8 in queue
06:58:37 set_timeout: set timeout in 5 seconds
06:58:37 work: received sequence 6, expected sequence 6
06:58:37 msg_dump_queue: sequence 6 in queue
06:58:37 msg_dump_queue: sequence 8 in queue
06:58:37 msg_dump: sequence 6, 'remove', '/block/sda', 'block'
06:58:37 msg_exec: delay exec of sequence 6, [8038] already working on '/block/sda'
06:58:37 delayed_moveto_queue: move event to delayed queue '/block/sda'
06:58:37 msg_exec: child [8047] created
06:58:37 running_moveto_queue: move sequence 6 [8047] to running queue '/block/sda'
06:58:37 set_timeout: set timeout in 5 seconds
06:58:38 sig_handler: caught signal 17
06:58:38 sig_handler: exec finished, pid 8038
06:58:38 set_timeout: set timeout in 4 seconds
06:58:38 msg_dump_queue: sequence 8 in queue
06:58:38 sig_handler: caught signal 17
06:58:38 sig_handler: exec finished, pid 8039
06:58:38 set_timeout: set timeout in 4 seconds
06:58:38 msg_dump_queue: sequence 8 in queue
06:58:38 sig_handler: caught signal 17
06:58:38 sig_handler: exec finished, pid 8040
06:58:38 set_timeout: set timeout in 4 seconds
06:58:38 msg_dump_queue: sequence 8 in queue
06:58:38 sig_handler: caught signal 17
06:58:38 sig_handler: exec finished, pid 8043
06:58:38 set_timeout: set timeout in 4 seconds
06:58:38 msg_dump_queue: sequence 8 in queue
06:58:38 sig_handler: caught signal 17
06:58:38 sig_handler: exec finished, pid 8044
06:58:38 set_timeout: set timeout in 4 seconds
06:58:38 msg_dump_queue: sequence 8 in queue
06:58:38 sig_handler: caught signal 17
06:58:38 sig_handler: exec finished, pid 8047
06:58:38 set_timeout: set timeout in 4 seconds
06:58:38 msg_dump_queue: sequence 8 in queue
06:58:39 main: using ipc queue 0x2d548
06:58:39 main: using ipc queue 0x2d548
06:58:39 work: received sequence 9, expected sequence 7
06:58:39 msg_dump_queue: sequence 8 in queue
06:58:39 msg_dump_queue: sequence 9 in queue
06:58:39 set_timeout: set timeout in 3 seconds
06:58:39 work: received sequence 11, expected sequence 7
06:58:39 msg_dump_queue: sequence 8 in queue
06:58:39 msg_dump_queue: sequence 9 in queue
06:58:39 msg_dump_queue: sequence 11 in queue
06:58:39 set_timeout: set timeout in 3 seconds
06:58:39 main: using ipc queue 0x2d548
06:58:39 work: received sequence 10, expected sequence 7
06:58:39 msg_dump_queue: sequence 8 in queue
06:58:39 msg_dump_queue: sequence 9 in queue
06:58:39 msg_dump_queue: sequence 10 in queue
06:58:39 msg_dump_queue: sequence 11 in queue
06:58:39 set_timeout: set timeout in 3 seconds
06:58:39 main: using ipc queue 0x2d548
06:58:39 work: received sequence 13, expected sequence 7
06:58:39 msg_dump_queue: sequence 8 in queue
06:58:39 msg_dump_queue: sequence 9 in queue
06:58:39 msg_dump_queue: sequence 10 in queue
06:58:39 msg_dump_queue: sequence 11 in queue
06:58:39 msg_dump_queue: sequence 13 in queue
06:58:39 set_timeout: set timeout in 3 seconds
06:58:39 main: using ipc queue 0x2d548
06:58:39 work: received sequence 14, expected sequence 7
06:58:39 msg_dump_queue: sequence 8 in queue
06:58:39 msg_dump_queue: sequence 9 in queue
06:58:39 msg_dump_queue: sequence 10 in queue
06:58:39 msg_dump_queue: sequence 11 in queue
06:58:39 msg_dump_queue: sequence 13 in queue
06:58:39 msg_dump_queue: sequence 14 in queue
06:58:39 set_timeout: set timeout in 3 seconds
06:58:39 main: using ipc queue 0x2d548
06:58:39 work: received sequence 15, expected sequence 7
06:58:39 msg_dump_queue: sequence 8 in queue
06:58:39 msg_dump_queue: sequence 9 in queue
06:58:39 msg_dump_queue: sequence 10 in queue
06:58:39 msg_dump_queue: sequence 11 in queue
06:58:39 msg_dump_queue: sequence 13 in queue
06:58:39 msg_dump_queue: sequence 14 in queue
06:58:39 msg_dump_queue: sequence 15 in queue
06:58:39 set_timeout: set timeout in 3 seconds
06:58:41 main: using ipc queue 0x2d548
06:58:41 work: received sequence 12, expected sequence 7
06:58:41 msg_dump_queue: sequence 8 in queue
06:58:41 msg_dump_queue: sequence 9 in queue
06:58:41 msg_dump_queue: sequence 10 in queue
06:58:41 msg_dump_queue: sequence 11 in queue
06:58:41 msg_dump_queue: sequence 12 in queue
06:58:41 msg_dump_queue: sequence 13 in queue
06:58:41 msg_dump_queue: sequence 14 in queue
06:58:41 msg_dump_queue: sequence 15 in queue
06:58:41 set_timeout: set timeout in 1 seconds
06:58:42 sig_handler: caught signal 14
06:58:42 sig_handler: event timeout reached
06:58:42 event 8, age 5 seconds, skip event 7-7
06:58:42 msg_dump: sequence 8, 'add', '/block/sdb', 'block'
06:58:42 msg_exec: child [8057] created
06:58:42 running_moveto_queue: move sequence 8 [8057] to running queue '/block/sdb'
06:58:42 msg_dump: sequence 9, 'add', '/block/sdc', 'block'
06:58:42 msg_exec: child [8058] created
06:58:42 running_moveto_queue: move sequence 9 [8058] to running queue '/block/sdc'
06:58:42 msg_dump: sequence 10, 'remove', '/block/sdc', 'block'
06:58:42 msg_exec: delay exec of sequence 10, [8058] already working on '/block/sdc'
06:58:42 delayed_moveto_queue: move event to delayed queue '/block/sdc'
06:58:42 msg_exec: child [8059] created
06:58:42 running_moveto_queue: move sequence 10 [8059] to running queue '/block/sdc'
06:58:42 msg_dump: sequence 11, 'remove', '/block/sdb', 'block'
06:58:42 msg_exec: delay exec of sequence 11, [8057] already working on '/block/sdb'
06:58:42 delayed_moveto_queue: move event to delayed queue '/block/sdb'
06:58:42 msg_exec: child [8060] created
06:58:42 running_moveto_queue: move sequence 11 [8060] to running queue '/block/sdb'
06:58:42 msg_dump: sequence 12, 'remove', '/block/sda', 'block'
06:58:42 msg_exec: child [8061] created
06:58:42 running_moveto_queue: move sequence 12 [8061] to running queue '/block/sda'
06:58:42 msg_dump: sequence 13, 'add', '/block/sda', 'block'
06:58:42 msg_exec: delay exec of sequence 13, [8061] already working on '/block/sda'
06:58:42 delayed_moveto_queue: move event to delayed queue '/block/sda'
06:58:42 msg_exec: child [8062] created
06:58:42 running_moveto_queue: move sequence 13 [8062] to running queue '/block/sda'
06:58:42 msg_dump: sequence 14, 'add', '/block/sdb', 'block'
06:58:42 msg_exec: delay exec of sequence 14, [8057] already working on '/block/sdb'
06:58:42 delayed_moveto_queue: move event to delayed queue '/block/sdb'
06:58:42 msg_exec: child [8063] created
06:58:42 running_moveto_queue: move sequence 14 [8063] to running queue '/block/sdb'
06:58:42 msg_dump: sequence 15, 'add', '/block/sdc', 'block'
06:58:42 msg_exec: delay exec of sequence 15, [8058] already working on '/block/sdc'
06:58:42 delayed_moveto_queue: move event to delayed queue '/block/sdc'
06:58:42 msg_exec: child [8064] created
06:58:42 running_moveto_queue: move sequence 15 [8064] to running queue '/block/sdc'
06:58:43 sig_handler: caught signal 17
06:58:43 sig_handler: exec finished, pid 8057
06:58:43 sig_handler: exec finished, pid 8058
06:58:43 sig_handler: caught signal 17
06:58:43 sig_handler: exec finished, pid 8059
06:58:43 sig_handler: caught signal 17
06:58:43 sig_handler: exec finished, pid 8060
06:58:43 sig_handler: exec finished, pid 8061
06:58:43 sig_handler: caught signal 17
06:58:43 sig_handler: exec finished, pid 8062
06:58:43 sig_handler: caught signal 17
06:58:43 sig_handler: exec finished, pid 8063
06:58:43 sig_handler: caught signal 17
06:58:43 sig_handler: exec finished, pid 8064
[-- Attachment #2: 01-udevd-execqueue.patch --]
[-- Type: text/plain, Size: 12631 bytes --]
diff -Nru a/Makefile b/Makefile
--- a/Makefile Tue Jan 27 07:29:28 2004
+++ b/Makefile Tue Jan 27 07:29:28 2004
@@ -232,6 +232,8 @@
@echo \#define UDEV_CONFIG_FILE \"$(configdir)\udev.conf\" >> $@
@echo \#define UDEV_RULES_FILE \"$(configdir)\udev.rules\" >> $@
@echo \#define UDEV_PERMISSION_FILE \"$(configdir)\udev.permissions\" >> $@
+ @echo \#define UDEV_BIN \"$(PWD)/udev\" >> $@
+ @echo \#define UDEVD_BIN \"$(PWD)/udevd\" >> $@
# config files automatically generated
GEN_CONFIGS = $(LOCAL_CFG_DIR)/udev.conf
diff -Nru a/test/udevd_test.sh b/test/udevd_test.sh
--- a/test/udevd_test.sh Tue Jan 27 07:29:28 2004
+++ b/test/udevd_test.sh Tue Jan 27 07:29:28 2004
@@ -3,7 +3,12 @@
# kill daemon, first event will start it again
killall udevd
-# connect(123) - disconnect(456) - connect(789) sequence of sda/sdb/sdc
+# 3 x connect/disconnect sequence of sda/sdb/sdc
+
+export SEQNUM=3
+export ACTION=add
+export DEVPATH=/block/sdc
+./udevsend block
export SEQNUM=1
export ACTION=add
@@ -17,36 +22,64 @@
export SEQNUM=4
export ACTION=remove
-export DEVPATH=/block/sda
-./udevsend block
-
-export SEQNUM=3
-export ACTION=add
export DEVPATH=/block/sdc
./udevsend block
-export SEQNUM=6
+export SEQNUM=5
export ACTION=remove
-export DEVPATH=/block/sdc
+export DEVPATH=/block/sdb
./udevsend block
-export SEQNUM=5
-export ACTION=remove
+export SEQNUM=8
+export ACTION=add
export DEVPATH=/block/sdb
./udevsend block
+export SEQNUM=6
+export ACTION=remove
+export DEVPATH=/block/sda
+./udevsend block
+
export SEQNUM=7
export ACTION=add
export DEVPATH=/block/sda
#./udevsend block
+sleep 2
+
export SEQNUM=9
export ACTION=add
export DEVPATH=/block/sdc
./udevsend block
-export SEQNUM=8
+export SEQNUM=11
+export ACTION=remove
+export DEVPATH=/block/sdb
+./udevsend block
+
+export SEQNUM=10
+export ACTION=remove
+export DEVPATH=/block/sdc
+./udevsend block
+
+export SEQNUM=13
+export ACTION=add
+export DEVPATH=/block/sda
+./udevsend block
+
+export SEQNUM=14
export ACTION=add
export DEVPATH=/block/sdb
./udevsend block
+export SEQNUM=15
+export ACTION=add
+export DEVPATH=/block/sdc
+./udevsend block
+
+sleep 2
+
+export SEQNUM=12
+export ACTION=remove
+export DEVPATH=/block/sda
+./udevsend block
diff -Nru a/udev.c b/udev.c
--- a/udev.c Tue Jan 27 07:29:28 2004
+++ b/udev.c Tue Jan 27 07:29:28 2004
@@ -45,7 +45,6 @@
switch (signum) {
case SIGINT:
case SIGTERM:
- case SIGKILL:
sysbus_disconnect();
udevdb_exit();
exit(20 + signum);
@@ -143,7 +142,6 @@
/* set up a default signal handler for now */
signal(SIGINT, sig_handler);
signal(SIGTERM, sig_handler);
- signal(SIGKILL, sig_handler);
/* initialize the naming deamon */
namedev_init();
diff -Nru a/udevd.c b/udevd.c
--- a/udevd.c Tue Jan 27 07:29:28 2004
+++ b/udevd.c Tue Jan 27 07:29:28 2004
@@ -38,27 +38,42 @@
#include "list.h"
#include "udev.h"
+#include "udev_version.h"
#include "udevd.h"
#include "logging.h"
+
#define BUFFER_SIZE 1024
+static int running_remove_queue(pid_t pid);
+static int msg_exec(struct hotplug_msg *msg);
+
static int expect_seqnum = 0;
static int lock_file = -1;
static char *lock_filename = ".udevd_lock";
LIST_HEAD(msg_list);
+LIST_HEAD(running_list);
+LIST_HEAD(delayed_list);
static void sig_handler(int signum)
{
+ pid_t pid;
+
dbg("caught signal %d", signum);
switch (signum) {
case SIGALRM:
dbg("event timeout reached");
break;
+ case SIGCHLD:
+ /* catch signals from exiting childs */
+ while ( (pid = waitpid(-1, NULL, WNOHANG)) > 0) {
+ dbg("exec finished, pid %d", pid);
+ running_remove_queue(pid);
+ }
+ break;
case SIGINT:
case SIGTERM:
- case SIGKILL:
if (lock_file >= 0) {
close(lock_file);
unlink(lock_filename);
@@ -70,34 +85,104 @@
}
}
-static void dump_queue(void)
+static void set_timeout(int seconds)
{
- struct hotplug_msg *msg;
+ alarm(seconds);
+ dbg("set timeout in %d seconds", seconds);
+}
- list_for_each_entry(msg, &msg_list, list)
- dbg("sequence %d in queue", msg->seqnum);
+static int running_moveto_queue(struct hotplug_msg *msg)
+{
+ dbg("move sequence %d [%d] to running queue '%s'",
+ msg->seqnum, msg->pid, msg->devpath);
+ list_move_tail(&msg->list, &running_list);
+ return 0;
+}
+
+static int running_remove_queue(pid_t pid)
+{
+ struct hotplug_msg *child;
+ struct hotplug_msg *tmp_child;
+
+ list_for_each_entry_safe(child, tmp_child, &running_list, list)
+ if (child->pid == pid) {
+ list_del_init(&child->list);
+ free(child);
+ return 0;
+ }
+ return -EINVAL;
+}
+
+static pid_t running_getpid_by_devpath(struct hotplug_msg *msg)
+{
+ struct hotplug_msg *child;
+ struct hotplug_msg *tmp_child;
+
+ list_for_each_entry_safe(child, tmp_child, &running_list, list)
+ if (strncmp(child->devpath, msg->devpath, sizeof(child->devpath)) == 0)
+ return child->pid;
+ return 0;
}
-static void dump_msg(struct hotplug_msg *msg)
+static void delayed_dump_queue(void)
+{
+ struct hotplug_msg *child;
+
+ list_for_each_entry(child, &delayed_list, list)
+ dbg("event for '%s' in queue", child->devpath);
+}
+
+static int delayed_moveto_queue(struct hotplug_msg *msg)
+{
+ dbg("move event to delayed queue '%s'", msg->devpath);
+ list_move_tail(&msg->list, &delayed_list);
+ return 0;
+}
+
+static void delayed_check_queue(void)
+{
+ struct hotplug_msg *delayed_child;
+ struct hotplug_msg *running_child;
+ struct hotplug_msg *tmp_child;
+
+ /* see if we have delayed exec's that can run now */
+ list_for_each_entry_safe(delayed_child, tmp_child, &delayed_list, list)
+ list_for_each_entry_safe(running_child, tmp_child, &running_list, list)
+ if (strncmp(delayed_child->devpath, running_child->devpath,
+ sizeof(running_child->devpath)) == 0) {
+ dbg("delayed exec for '%s' can run now", delayed_child->devpath);
+ msg_exec(delayed_child);
+ }
+}
+
+static void msg_dump(struct hotplug_msg *msg)
{
dbg("sequence %d, '%s', '%s', '%s'",
msg->seqnum, msg->action, msg->devpath, msg->subsystem);
}
-static int dispatch_msg(struct hotplug_msg *msg)
+static int msg_exec(struct hotplug_msg *msg)
{
pid_t pid;
- dump_msg(msg);
+ msg_dump(msg);
setenv("ACTION", msg->action, 1);
setenv("DEVPATH", msg->devpath, 1);
+ /* delay exec, if we already have a udev working on the same devpath */
+ pid = running_getpid_by_devpath(msg);
+ if (pid != 0) {
+ dbg("delay exec of sequence %d, [%d] already working on '%s'",
+ msg->seqnum, pid, msg->devpath);
+ delayed_moveto_queue(msg);
+ }
+
pid = fork();
switch (pid) {
case 0:
/* child */
- execl(UDEV_EXEC, "udev", msg->subsystem, NULL);
+ execl(UDEV_BIN, "udev", msg->subsystem, NULL);
dbg("exec of child failed");
exit(1);
break;
@@ -105,18 +190,23 @@
dbg("fork of child failed");
return -1;
default:
- wait(NULL);
+ /* exec in background, get the SIGCHLD with the sig handler */
+ msg->pid = pid;
+ running_moveto_queue(msg);
+ break;
}
return 0;
}
-static void set_timeout(int seconds)
+static void msg_dump_queue(void)
{
- alarm(seconds);
- dbg("set timeout in %d seconds", seconds);
+ struct hotplug_msg *msg;
+
+ list_for_each_entry(msg, &msg_list, list)
+ dbg("sequence %d in queue", msg->seqnum);
}
-static void check_queue(void)
+static void msg_check_queue(void)
{
struct hotplug_msg *msg;
struct hotplug_msg *tmp_msg;
@@ -127,30 +217,32 @@
list_for_each_entry_safe(msg, tmp_msg, &msg_list, list) {
if (msg->seqnum != expect_seqnum)
break;
- dispatch_msg(msg);
+ msg_exec(msg);
expect_seqnum++;
- list_del_init(&msg->list);
- free(msg);
}
- /* recalculate timeout */
+ /* recalculate next timeout */
if (list_empty(&msg_list) == 0) {
msg_age = time(NULL) - msg->queue_time;
- if (msg_age > EVENT_TIMEOUT_SECONDS-1) {
+ if (msg_age > EVENT_TIMEOUT_SEC-1) {
info("event %d, age %li seconds, skip event %d-%d",
msg->seqnum, msg_age, expect_seqnum, msg->seqnum-1);
expect_seqnum = msg->seqnum;
goto recheck;
}
- set_timeout(EVENT_TIMEOUT_SECONDS - msg_age);
+
+ /* the first sequence gets its own timeout */
+ if (expect_seqnum == 0) {
+ msg_age = EVENT_TIMEOUT_SEC - FIRST_EVENT_TIMEOUT_SEC;
+ expect_seqnum = 1;
+ }
+
+ set_timeout(EVENT_TIMEOUT_SEC - msg_age);
return;
}
-
- /* queue is empty */
- set_timeout(UDEVD_TIMEOUT_SECONDS);
}
-static int queue_msg(struct hotplug_msg *msg)
+static int msg_add_queue(struct hotplug_msg *msg)
{
struct hotplug_msg *new_msg;
struct hotplug_msg *tmp_msg;
@@ -182,7 +274,7 @@
char buf[BUFFER_SIZE];
int ret;
- key = ftok(UDEVD_EXEC, IPC_KEY_ID);
+ key = ftok(UDEVD_BIN, IPC_KEY_ID);
msg = (struct hotplug_msg *) buf;
msgid = msgget(key, IPC_CREAT);
if (msgid == -1) {
@@ -192,41 +284,20 @@
while (1) {
ret = msgrcv(msgid, (struct msgbuf *) buf, BUFFER_SIZE-4, HOTPLUGMSGTYPE, 0);
if (ret != -1) {
- /* init the expected sequence with value from first call */
- if (expect_seqnum == 0) {
- expect_seqnum = msg->seqnum;
- dbg("init next expected sequence number to %d", expect_seqnum);
- }
- dbg("current sequence %d, expected sequence %d", msg->seqnum, expect_seqnum);
- if (msg->seqnum == expect_seqnum) {
- /* execute expected event */
- dispatch_msg(msg);
- expect_seqnum++;
- check_queue();
- dump_queue();
+ dbg("received sequence %d, expected sequence %d", msg->seqnum, expect_seqnum);
+ if (msg->seqnum >= expect_seqnum) {
+ msg_add_queue(msg);
+ msg_dump_queue();
+ msg_check_queue();
continue;
}
- if (msg->seqnum > expect_seqnum) {
- /* something missing, queue event*/
- queue_msg(msg);
- check_queue();
- dump_queue();
- continue;
- }
- dbg("too late for event with sequence %d, even skipped ", msg->seqnum);
+ dbg("too late for event with sequence %d, event skipped ", msg->seqnum);
} else {
if (errno == EINTR) {
- /* timeout */
- if (list_empty(&msg_list)) {
- info("we have nothing to do, so daemon exits...");
- if (lock_file >= 0) {
- close(lock_file);
- unlink(lock_filename);
- }
- exit(0);
- }
- check_queue();
- dump_queue();
+ msg_check_queue();
+ msg_dump_queue();
+ delayed_check_queue();
+ delayed_dump_queue();
continue;
}
dbg("ipc message receive error '%s'", strerror(errno));
@@ -266,11 +337,8 @@
/* set up signal handler */
signal(SIGINT, sig_handler);
signal(SIGTERM, sig_handler);
- signal(SIGKILL, sig_handler);
signal(SIGALRM, sig_handler);
-
- /* we exit if we have nothing to do, next event will start us again */
- set_timeout(UDEVD_TIMEOUT_SECONDS);
+ signal(SIGCHLD, sig_handler);
work();
exit(0);
diff -Nru a/udevd.h b/udevd.h
--- a/udevd.h Tue Jan 27 07:29:28 2004
+++ b/udevd.h Tue Jan 27 07:29:28 2004
@@ -23,18 +23,18 @@
#include "list.h"
-#define UDEV_EXEC "./udev"
-#define UDEVD_EXEC "./udevd"
-#define UDEVD_TIMEOUT_SECONDS 60
-#define EVENT_TIMEOUT_SECONDS 5
+#define FIRST_EVENT_TIMEOUT_SEC 1
+#define EVENT_TIMEOUT_SEC 5
+#define UDEVSEND_RETRY_COUNT 50 /* x 10 millisec */
-#define IPC_KEY_ID 0
+#define IPC_KEY_ID 1
#define HOTPLUGMSGTYPE 44
struct hotplug_msg {
long mtype;
struct list_head list;
+ pid_t pid;
int seqnum;
time_t queue_time;
char action[8];
diff -Nru a/udevsend.c b/udevsend.c
--- a/udevsend.c Tue Jan 27 07:29:28 2004
+++ b/udevsend.c Tue Jan 27 07:29:28 2004
@@ -34,6 +34,7 @@
#include <wait.h>
#include "udev.h"
+#include "udev_version.h"
#include "udevd.h"
#include "logging.h"
@@ -64,7 +65,7 @@
static int build_hotplugmsg(struct hotplug_msg *msg, char *action,
char *devpath, char *subsystem, int seqnum)
{
- memset(msg, 0x00, sizeof(msg));
+ memset(msg, 0x00, sizeof(*msg));
msg->mtype = HOTPLUGMSGTYPE;
msg->seqnum = seqnum;
strncpy(msg->action, action, 8);
@@ -88,7 +89,7 @@
/* daemon */
setsid();
chdir("/");
- execl(UDEVD_EXEC, "udevd", NULL);
+ execl(UDEVD_BIN, "udevd", NULL);
dbg("exec of daemon failed");
exit(1);
case -1:
@@ -150,7 +151,8 @@
seq = atoi(seqnum);
/* create ipc message queue or get id of our existing one */
- key = ftok(UDEVD_EXEC, IPC_KEY_ID);
+ key = ftok(UDEVD_BIN, IPC_KEY_ID);
+ dbg("using ipc queue 0x%0x", key);
size = build_hotplugmsg(&message, action, devpath, subsystem, seq);
msgid = msgget(key, IPC_CREAT);
if (msgid == -1) {
@@ -168,7 +170,7 @@
/* get state of ipc queue */
tspec.tv_sec = 0;
tspec.tv_nsec = 10000000; /* 10 millisec */
- loop = 30;
+ loop = UDEVSEND_RETRY_COUNT;
while (loop--) {
retval = msgctl(msgid, IPC_STAT, &msg_queue);
if (retval == -1) {
^ permalink raw reply
* Re: r8169, 2.6.2-rc2, Sager 4780 laptop
From: bhartin @ 2004-01-27 6:51 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20040126235559.A3832@electric-eye.fr.zoreil.com>
Okay, I patched using only the patches listed below. These are actually
applied against 2.6.2-rc2, since I don't have 2.6.2-rc1 on hand at the
moment, and your patches still apply cleanly.
acpi=off
- RX - Pushed about a gig, averaging 8.2MB/sec. Appeared to work ok.
- TX - Once I hit 642MB transfered (avg 8.9MB/sec), the system locked up
hard.
SMP off, acpi on
- TX - Hard lock at 307MB.
SMP off, acpi off
- TX - Hard lock at 345MB.
I'll try to investigate further tomorrow. I have to go out of town
starting Thursday, and was hoping to have everything working by then.
Unfortunately, I have other problems to deal with as well (ati-drivers,
slmodem, etc).
Thanks
On Mon, 26 Jan 2004, Francois Romieu wrote:
> bhartin@straus-frank.com <bhartin@straus-frank.com> :
> [...]
> > Attached is a tar.gz containing the outputs you request in your README,
> > plus 'lspci -v' output and my .config for the kernel. This data was
> > collected from a fresh 2.6.2-rc2 bootup, using your full set of 2.6.2-rc1
> > patches, manually doing a 'modprobe r8169' once booted up. The system is
> > running a P4 with HT enabled, with an SMP kernel.
>
> There has been report of non-regression on non-SMP kernel with the following
> patches applied (2.6.2-rc1 serie):
> r8169-tx-index-overflow.patch
> r8169-dma-api-tx.patch
> r8169-dma-api-rx-buffers.patch
> r8169-dma-api-tx-buffers.patch
> r8169-rx_copybreak.patch
> r8169-mac-phy-version.patch
> r8169-init_one.patch
> r8169-timer.patch
> r8169-hw_start.patch
> r8169-intr_mask.patch
> r8169-suspend.patch
> r8169-endianness.patch
> r8169-getstats.patch
>
> Can you confirm that the driver behaves the same as the standard driver
> with a non-SMP enabled kernel ?
>
> Does it make a difference if you give an 'acpi=off' option at boot time ?
>
> r8169-addr-high.patch is not doing its job on amd64 so it is not suggested
> to use it at all.
>
> There is something broken wrt SMP and the r8169 patches: do not use both at
> the same time. I still have to find what happens here.
>
> --
> Ueimor
>
Bradley Hartin - bhartin@straus-frank.com
Communications and Network Administrator
Straus-Frank Company
^ permalink raw reply
* ALERT - GroupShield ticket number OA454_1075186111_DEATCSSTRMSX0 3_3 was generated
From: GroupShield for Exchange (DEATCSSTRMSX03) @ 2004-01-27 6:49 UTC (permalink / raw)
To: 'linux1394-devel@lists.sourceforge.net', 'LKML'
Action Taken:
The attachment was quarantined from the message and replaced with a text
file informing the recipient of the action taken.
To:
linux1394-devel@lists.sourceforge.net
<linux1394-devel@lists.sourceforge.net>; LKML <linux-kernel@vger.kernel.org>
From:
Jean Delvare <khali@linux-fr.org>
Sent:
-1232340736,29615265
Subject:
Message about PCILynx in kernel config
Attachment Details:-
Attachment Name: message.scr
File: message.scr
Infected? No
Repaired? No
Blocked? Yes
Deleted? No
Virus Name:
^ permalink raw reply
* Re: virus warning
From: Unknown, Alistair Tonner @ 2004-01-27 6:45 UTC (permalink / raw)
To: Netfilter Mailing List (E-mail)
In-Reply-To: <F22386C3FEB012449238672E38ED61E71642A9@overlord.overturemedia.com>
Obviously this is a really new one ... F-prot didn't catch it .. and mines up to date ...
However ... since kmail and linux don't much like 7 bit mime ... *grin*
I'm handing this one up to the folks at F-Prot to see why they didn't catch it...
Alistair.
On January 27, 2004 12:44 am, Fritz Mesedilla wrote:
> friends,
>
> we got a virus in our list.
> clamav warned me about it.
> it's now spreading like fire even on other lists.
>
> thought you might like to be warned.
>
>
> Cheers,
>
> fritz <www.mesedilla.com>
> ---
> + Basta Ikaw Lord
>
>
>
>
> ----------------------------------------------------------------------
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the sender immediately by e-mail and delete this e-mail from your
> system. Please note that any views or opinions presented in this
> email are solely those of the author and do not necessarily represent
> those of the company. Finally, the recipient should check this email
> and any attachments for the presence of viruses. The company accepts
> no liability for any damage caused by any virus transmitted by this
> email.
>
> Overture Media, Inc.
> Direct Line: (632) 635-4785
> Trunkline: (632) 631-8971 Local 146
> Fax: (632) 637-2206
> Level 1 Summit Media Offices, Robinsons Galleria EDSA Cor. Ortigas Ave.,
> Quezon City 1100
^ permalink raw reply
* Re: [patch] Re: Kernels > 2.6.1-mm3 do not boot. - SOLVED
From: Eric @ 2004-01-27 6:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: stoffel, ak, Valdis.Kletnieks, bunk, cova, linux-kernel
In-Reply-To: <20040126215056.4e891086.akpm@osdl.org>
On Monday 26 January 2004 23:50, Andrew Morton wrote:
> Eric <eric@cisu.net> wrote:
> > YES. I finally have a working 2.6.2-rc1-mm3 booted kernel.
> > Lets review folks---
> > reverted -funit-at-a-time
> > patched test_wp_bit so exception tables are sorted sooner
> > reverted md-partition patch
>
> The latter two are understood, but the `-funit-at-a-time' problem is not.
>
> Can you plesae confirm that restoring only -funit-at-a-time again produces
> a crashy kernel? And that you are using a flavour of gcc-3.3? If so, I
> guess we'll need to only enable it for gcc-3.4 and later.
>
Yes, confirmed. My version of gcc, I just sent you adding the
-funit-at-a-time hung after uncompressing the kernel. I booted a secondary
kernel, recompiled without it and all was fine again. Confirmed non-boot for
2.6.2-rc1-mm3 but without a doubt for all kernels previous where
-funit-at-a-time is active in the makefile.
-------------------------
Eric Bambach
Eric at cisu dot net
-------------------------
^ permalink raw reply
* Re: RE: preparing toshiba_acpi driver release
From: Tod Morrison @ 2004-01-27 6:33 UTC (permalink / raw)
To: Karol Kozimor
Cc: Brown, Len, Ducrot Bruno, John Belmonte,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20040127031247.GA28233-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org>
I have a Dell Inspiron 8500, I'd be happy to play tester with when you're
looking for a generalized solution. I did have one thought (quite beyond
me to implement though), I was looking at the ACPI VID extensions and
wondered if LCD._DSS could be used to our advantage. It appears that it's
designed to allow the OS to handle video output switching, i.e.
turn off LCD -> turn on CRT
What I thought was that I don't see a reason we couldn't just turn off
LCD output, i.e. call
LCD._DSS(0);
to turn off output, and
LCD._DSS(80000001L);
to turn it back on. Anyway, I'm really unqualified to say whether this
make any sense, it was just a thought.
Tod Morrison <tmorriso-o2OswTf4RFv//ikEAC0814dd74u8MsAO@public.gmane.org>
http://math.cudenver.edu/~tmorriso
"Everyone thinks of changing the world,
but no one thinks of changing himself."
- Leo Tolstoy
On Tue, 27 Jan 2004, Karol Kozimor wrote:
> Thus wrote Brown, Len:
> > I was thinking about ergonomics rather than power-savings -- though
> > probably brightness control has some power savings benefits too -- maybe
> > somebody on the list has numbers for screen power consumption?
>
> Last time I checked it was about 6 W for my 15" display (100% brightness,
> power consumption goes down linearly).
>
> What I consider more important, is the ability to switch the LCD on / off
> by demand -- unfortunately, DPMS is mostly unsupported on modern machines
> and a generic approach (provided it works) could make a difference here.
>
> Once I update the acpi4asus driver, I'll take a look on how those generic
> methods to manipulate video work here and see where it gets me.
>
> Best regards,
>
> --
> Karol 'sziwan' Kozimor
> sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
>
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: 2.6.2-rc1-mm1 oops with X
From: Glenn Johnson @ 2004-01-27 4:47 UTC (permalink / raw)
To: Andrew Morton, linux-kernel
In-Reply-To: <20040127040446.GA2445@srv-lnx2600.matchmail.com>
On Mon, Jan 26, 2004 at 08:04:46PM -0800, Mike Fedyk wrote:
> On Fri, Jan 23, 2004 at 10:33:27PM -0600, Glenn Johnson wrote:
>
> > On Fri, Jan 23, 2004 at 01:56:24PM -0800, Mike Fedyk wrote:
> >
> > > How far does it get through, and at what point in X startup does
> > > the kernel oops?
> >
> > I would say fairly early on but I do not know how to quantify that.
>
> Post your log file, and show where in the log the oops occours...
Okay, below is the XFree log file. It is truncated at the point where
the oops occurs. I sent an e-mail to Andrew confirming that backing out
sysfs-class-10-vc.patch fixes the problem for me.
---begin X log for kernel oops---
XFree86 Version 4.3.0
Release Date: 27 February 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: Linux 2.6.1-mm5 i686 [ELF]
Build Date: 20 January 2004
Before reporting problems, check http://www.XFree86.Org/
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/XFree86.0.log", Time: Mon Jan 26 22:33:10 2004
(==) Using config file: "/etc/X11/XF86Config"
(==) ServerLayout "XFree86 Configured"
(**) |-->Screen "Screen0" (0)
(**) | |-->Monitor "Monitor0"
(**) | |-->Device "Card0"
(**) |-->Input Device "Mouse0"
(**) |-->Input Device "Keyboard0"
(==) Keyboard: CustomKeycode disabled
(**) FontPath set to "unix/:-1"
(**) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(**) ModulePath set to "/usr/X11R6/lib/modules"
(++) using VT number 8
---end X log for kernel oops
The VT number it tries to use jumps around. Sometimes it is VT10, VT11,
etc. It should be using VT7 however.
Cheers,
Glenn
^ permalink raw reply
* Re: ax25 support in aprsd
From: John Williams @ 2004-01-27 6:30 UTC (permalink / raw)
To: Adi Linden, linux-hams
In-Reply-To: <Pine.LNX.4.44.0401262346000.11381-100000@mobile.adis.ca>
I am not sure if you can.
Might be a question for the aprsd list.
If the aprs server remembers the last setting then you could setup the filter with an aprs client.
Otherwise try to locate a Canadian aprs server with preset filters, like we have in Australia.
Cheers
John
VK5ZTY
On 26 Jan 2004 at 23:47, Adi Linden wrote:
> Things are beginning to make a lot of sense now. If I want to connect to
> port 14580 with aprsd, how do I get aprsd to send the filter string?
>
> 73,
> Adi
> va3adi
>
>
^ permalink raw reply
* Re: [LARTC] 1000's of classes and filters
From: jayesh rathod @ 2004-01-27 6:20 UTC (permalink / raw)
To: lartc
In-Reply-To: <1074950866.401272d23b136@smwp01.maa.sify.net>
Hi ,
Let me rephrase my problem with more details and some history.
We are running an application on a system which does NAT'ting and shaping. TC and iptable rules are added and deleted at runtime.
A TC rule will be,
tc class add dev eth1 parent 1:1 classid 1:5001 htb rate 256kbit ceil 256kbit
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 10.1.1.1 match ip flowid 1:5001
At peak some 700 to 800 such rules will be present.
Same rules for the other inteface. Deleting a rule is flush out all the rules and reapply :) ( handler could have been used to delete a particular rule, but we have not yet upgraded )
We had ext3 filesystem installed at he beginning. But regularly the box would go down with a kernel panic. The stack trace when this occured is attached.
We then moved to resiserfs filesystem. This time although there was no kernel panic, the box hanged
with junk messages printed in all our application logs. The box doesnt even respond on the console. Hard reboot is the only thing we can do.
Pls find all the details given below. Any suggestions/solutions are welcome.
Regards
Jayesh
System details :
Kernel version : 2.4.23
HTB init, kernel part version 3.13
SCSI Adaptec storage controllers
1 GB RAM
lspci
-----------
00:00.0 Host bridge: Intel Corp.: Unknown device 254c (rev 01)
00:02.0 PCI bridge: Intel Corp. e7500 HI_B Virtual PCI-to-PCI Bridge (F0) (rev 01)
00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA PCI Bridge (rev 42)
00:1f.0 ISA bridge: Intel Corp. 82801CA ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801CA IDE U100 (rev 02)
00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus (rev 02)
01:02.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
02:1c.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 04)
02:1d.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 04)
02:1e.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 04)
02:1f.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 04)
03:01.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08)
03:02.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08)
04:01.0 Ethernet controller: Intel Corp.: Unknown device 100f (rev 01)
04:04.0 SCSI storage controller: Adaptec: Unknown device 801f (rev 03)
04:04.1 SCSI storage controller: Adaptec: Unknown device 801f (rev 03)
Ksymoops output with ext3 filesystem
-----------------------------
Dec 21 06:57:02 theseus kernel: kernel BUG at checkpoint.c:587!
Dec 21 06:57:02 theseus kernel: invalid operand: 0000
Dec 21 06:57:02 theseus kernel: CPU: 0
Dec 21 06:57:02 theseus kernel: EIP: 0010:[<c01662ec>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
Dec 21 06:57:02 theseus kernel: EFLAGS: 00010292
Dec 21 06:57:02 theseus kernel: eax: 00000069 ebx: f6c46660 ecx: fffffffe edx: 00000000
Dec 21 06:57:02 theseus kernel: esi: f7ecc660 edi: f6c46660 ebp: e03fdc10 esp: f7de9e1c
Dec 21 06:57:02 theseus kernel: ds: 0018 es: 0018 ss: 0018
Dec 21 06:57:02 theseus kernel: Process kjournald (pid: 11, stackpage÷de9000)
Dec 21 06:57:02 theseus kernel: Stack: c0257500 c02558c6 c025583d 0000024b c02558a9 f6c46660 c0166173 f7ecc660
Dec 21 06:57:02 theseus kernel: f6c46660 cd59ce60 e03fdc10 c0165b6f e03fdc10 e03fdc10 c01660fb e03fdc10
Dec 21 06:57:02 theseus kernel: 00000012 f19f0540 f19f0540 f19f0d40 f7ecc660 00000000 f7ecc660 c01643ef
Dec 21 06:57:02 theseus kernel: Call Trace: [<c0166173>] [<c0165b6f>] [<c01660fb>] [<c01643ef>] [<c020036c>]
Dec 21 06:57:02 theseus kernel: [<c0109cea>] [<c011a94b>] [<c0109e9c>] [<c01142c3>] [<c0166e26>] [<c0166d00>]
Dec 21 06:57:02 theseus kernel: [<c0107136>] [<c0166d20>]
Dec 21 06:57:02 theseus kernel: Code: 0f 0b 4b 02 3d 58 25 c0 83 c4 14 8b 53 1c 85 d2 74 29 68 a0
>>EIP; c01662ec <__journal_drop_transaction+5c/282> <==Trace; c0166173 <__journal_remove_checkpoint+53/80>
Trace; c0165b6f <__try_to_free_cp_buf+1f/40>
Trace; c01660fb <__journal_clean_checkpoint_list+5b/80>
Trace; c01643ef <journal_commit_transaction+19f/fd4>
Trace; c020036c <net_rx_action+6c/100>
Trace; c0109cea <handle_IRQ_event+3a/70>
Trace; c011a94b <do_softirq+4b/90>
Trace; c0109e9c <do_IRQ+9c/b0>
Trace; c01142c3 <schedule+2e3/310>
Trace; c0166e26 <kjournald+106/1b0>
Trace; c0166d00 <commit_timeout+0/10>
Trace; c0107136 <arch_kernel_thread+26/30>
Trace; c0166d20 <kjournald+0/1b0>
Code; c01662ec <__journal_drop_transaction+5c/282>
00000000 <_EIP>:
Code; c01662ec <__journal_drop_transaction+5c/282> <== 0: 0f 0b ud2a <==Code; c01662ee <__journal_drop_transaction+5e/282>
2: 4b dec %ebx
Code; c01662ef <__journal_drop_transaction+5f/282>
3: 02 3d 58 25 c0 83 add 0x83c02558,%bh
Code; c01662f5 <__journal_drop_transaction+65/282>
9: c4 14 8b les (%ebx,%ecx,4),%edx
Code; c01662f8 <__journal_drop_transaction+68/282>
c: 53 push %ebx
Code; c01662f9 <__journal_drop_transaction+69/282>
d: 1c 85 sbb $0x85,%al
Code; c01662fb <__journal_drop_transaction+6b/282>
f: d2 (bad)
Code; c01662fc <__journal_drop_transaction+6c/282>
10: 74 29 je 3b <_EIP+0x3b> c0166327 <__journal_drop_transaction+97/282>
Code; c01662fe <__journal_drop_transaction+6e/282>
12: 68 a0 00 00 00 push $0xa0
-------------------------------------------------
Still single? Click here to find the perfect match.
http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?141
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* RE: Submission for S2io 10GbE driver
From: Leonid Grossman @ 2004-01-27 6:19 UTC (permalink / raw)
To: 'Jeff Garzik'
Cc: 'Stephen Hemminger', 'Andi Kleen', netdev,
raghavendra.koushik
In-Reply-To: <40160060.4010709@pobox.com>
>
> The ethtool diag stuff is more of a quick sanity test than anything
> exhaustive.
>
> I definitely want to discourage tons of test code in drivers, as its
> code that users will almost-never run, it bloats the driver,
> and can be
> done with a special diag-only driver or diag program (or a
> combination
> of both).
>
> A lot of the 10/100 drivers originated from Donald Becker,
> who typically
> creates a userland (i.e. separate) diag program for each
> driver he writes.
I see the point; we'll go ahead and get rid of the loopback.
We actually have pretty extensive standalone diag tool that is based on
diag driver.
Thanks, Leonid
>
> Jeff
>
>
>
^ permalink raw reply
* Re: [PATCH] 2.6.2-rc2 - MPT Fusion driver 3.00.02 update
From: Jeremy Higdon @ 2004-01-27 6:18 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: James Bottomley, Moore, Eric Dean, SCSI Mailing List
In-Reply-To: <20040126193413.A3302@infradead.org>
On Mon, Jan 26, 2004 at 07:34:13PM +0000, Christoph Hellwig wrote:
> On Mon, Jan 26, 2004 at 11:05:26AM -0600, James Bottomley wrote:
> > > I had avoided it due the comments in the code
> > > from sralston and pdelaney about sg interface
> > > gererating wrong direction in some cases.
> >
> > If you find a problem, I'll fix the generic code...
>
> I think it's just very old comments. We had such a problem in early 2.4
> kernels, but it has been fixed for ages. If it wasn't most of the scsi
> drivers would have a big problem.
Aren't there three interfaces for sg, or did the early ones go away
in 2.6? I recall that we ran into trouble with sg setting the
direction incorrectly in 2.4 kernels when using older interface,
I think.
jeremy
^ permalink raw reply
* Is gcc 3.2.2 suitable for kernel builds?
From: John Heil @ 2004-01-27 6:15 UTC (permalink / raw)
To: linux-kernel
It seems that some gcc 3.2.2 optimizations are generating
bogus code sequences.
Has anyone else had compiler issues w gcc 3.2.2?
Thanks much,
johnh
-
-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
johnhscs@sc-software.com
http://www.sc-software.com
-----------------------------------------------------------------
^ permalink raw reply
* Re: [uPATCH] refuse plain ufs mount
From: Linus Torvalds @ 2004-01-27 6:15 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: akpm, gotom, linux-kernel
In-Reply-To: <UTC200401270407.i0R47oi29367.aeb@smtp.cwi.nl>
On Tue, 27 Jan 2004 Andries.Brouwer@cwi.nl wrote:
>
> Funny how we alternate - when I choose the pure, theoretical point of view
> you prefer practice, when I prefer practice you become pure.
Heh.
I'm actually usually very easy to predict:
- when it comes to "core technology" bugs, I'd much rather fix them
_right_. To the point where I prefer to not fix them at all if the fix
is only hiding the real bug. Then I'd rather leave it as a known bug
and hope the _real_ fix comes in.
- but when it comes to things that are more about "usability", I tend to
try to take the very practical approach. So we'll disagree on things
like "should the kernel autodetect", because I think that's a usability
issue, and consider that it should be as easy for users as possible.
The reiserfs/ufs issue to me is about "usability", not "core technology".
As such, to me it falls under the "practical" heading, and the solution
should be the pragmatic trivial "just test reiserfs first" kind of silly
thing.
Linus
^ permalink raw reply
* Re: [uPATCH] ufs.txt update
From: Frédéric L. W. Meunier @ 2004-01-27 6:13 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <81ektm9dvh.wl@omega.webmasters.gr.jp>
On Tue, 27 Jan 2004, GOTO Masanori wrote:
> At Sun, 25 Jan 2004 09:26:21 +0100,
> Jochen Hein wrote:
> > Andries.Brouwer@cwi.nl writes:
> >
> > > old old format of ufs
> > > - default value, supported os read-only
> > > + supported os read-only
> >
> > s/os/as/ ?
> >
> > > 44bsd used in FreeBSD, NetBSD, OpenBSD
> > > supported os read-write
> >
> > s/os/as/ ?
>
> Exactly. In addition I think removing "default value" from "old"
> entry is no effectiveness, so I revive this sentence.
>
> This patch updates typos and HP-UX description in
> Documentation/filesystems/ufs.txt, suggested by Andries.Brouwer@cwi.nl
> and Jochen Hein <jochen@jochen.org>.
Someone could also add some notes to ufs.txt and the Configure
entry for 2.4 and 2.6 about the lack of UFS2 support, which is
the default since FreeBSD 5.1.
--
http://www.pervalidus.net/contact.html
^ permalink raw reply
* Re: atkbd.c: Unknown key released
From: yoann @ 2004-01-27 6:09 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20040127052507.GF18411@charite.de>
>>I keep getting the following in my syslog whenever I startx:
>
> Which hardware?
>
>>Jan 26 13:43:56 debian kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
>>Jan 26 13:43:56 debian kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
>>Jan 26 13:43:57 debian kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
>>Jan 26 13:43:57 debian kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
>>
>>I don't get the error with the 2.4.24 kernel.
>
> Same here.
same here with a 2.6.2-rc1-mm2
Xfree86 Version: 4.2.1-15 (debian sid)
Yoann
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.