* [Adeos-main] [PATCH] armnommu compile fix
From: Paul Mundt @ 2004-01-27 0:00 UTC (permalink / raw)
To: adeos-main
[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]
Hi,
The current kernel-2.4/adeos-common/include/asm-armnommu/adeos.h has a broken
__adeos_clear_irq(). This looks like it was copied from an SMP-able adeos.h
and cleaned up, with only this one line being left over and subsequently
causing the build to fail.
Against current CVS HEAD.
kernel-2.4/adeos-common/include/asm-armnommu/adeos.h | 1 -
1 files changed, 1 deletion(-)
Index: kernel-2.4/adeos-common/include/asm-armnommu/adeos.h
===================================================================
RCS file: /cvsroot/adeos/adeos/platforms/linux/kernel-2.4/adeos-common/include/asm-armnommu/adeos.h,v
retrieving revision 1.20
diff -u -r1.20 adeos.h
--- kernel-2.4/adeos-common/include/asm-armnommu/adeos.h 9 Jan 2004 10:06:15 -0000 1.20
+++ kernel-2.4/adeos-common/include/asm-armnommu/adeos.h 26 Jan 2004 23:59:04 -0000
@@ -204,7 +204,6 @@
clear_bit(IPIPE_LOCK_FLAG,&(adp)->irqs[irq].control); \
(adp)->cpudata[0].irq_hits[irq] = 0; \
__adeos_clear_pend(adp,irq); \
- } \
} while(0)
#define adeos_virtual_irq_p(irq) ((irq) >= IPIPE_VIRQ_BASE && \
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: i/o wait eating all of CPU on 2.6.1
From: bill davidsen @ 2004-01-26 23:59 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20040125143042.GA20274@ihme.org>
In article <20040125143042.GA20274@ihme.org>,
Jaakko Helminen <haukkari@ihme.org> wrote:
|
| I have two servers, both of which have more than 300 gigabytes of hard drive
| space and those files are made available to the network with samba, nfs and
| http and it worked fine with 2.6.0 but when I upgraded to 2.6.1 I noticed
| that everything was VERY slow, from a machine that is connected to the other
| server with a 100M link, 57kB/s tops. i/o wait eats up all of the cpu.
| On the other hand, Apache (and everything else) works very fast when I only
| send /dev/zero to a client, since that doesn't need disk operations.
Actually, io-wait is an indication that the CPU is idle with io
outstanding, and doesn't eat the machine any more than idle time. It is
an indication that the io is not keeping up, of course.
The fact that sending /dev/zero is fast sort of eliminates the reported
problems with NFS and setting the read/write size to 8k on the client.
Just for grins, hopefully you have followed the "NFS is slow" thread,
but I saw people having the issue with 2.6.0, so that's not likely to be
be involved.
I have some preliminary numbers which indicate 2.6.2-rc2 is faster at
some disk operations than 2.6.1, but since that's one benchmark on one
machine all I can say is that if you want to move forward, that kernel
is working well for me. Of course if there's nothing in 2.6.1 you
really want or need, falling back is a sure cure.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
* Re: [PATCH]: altq HFSC port
From: Jamie Lokier @ 2004-01-26 23:59 UTC (permalink / raw)
To: Patrick McHardy; +Cc: hadi, netdev, linux-net, David S. Miller
In-Reply-To: <40155F1A.7070507@trash.net>
Patrick McHardy wrote:
> I talked to the original authors and they removed the advertising
> clause
> (http://orange.kame.net/dev/cvsweb.cgi/kame/kame/sys/altq/altq_hfsc.c),
> but they didn't want to release the code under the GPL. Various posts on
> linux-kernel indicate that combining GPL code with BSD code without
> advertising clause makes the end-product automatically be subject to the
> GPL, even without consent of the authors. I basically meant to ask if
> this is true.
Yes, the end-product Linux kernel (the combined work) is subject to
the GPL. You _do_ have the consent of the authors: their decision to
release under the BSD-without-advertising license _is_ consent to
incorporate it into a GPL work, just as it is consent to incorporate
it into a closed source work. Asking for their blessing is politeness.
When the authors release the code under the BSD-without-advertising
clause, they are declaring that it's ok to use the code in lots of
different ways. One of those is that it's ok to re-release the code
under GPL - the authors may not like that, but they have explicitly
declared that you may to do it.
You can do that.
Alternatively you can keep the code licensed under BSD-without-advertising.
When you combine BSD-without-advertising code with GPL code, the
resulting combined work is covered by both licenses, and because the
BSD-without-advertising permissions are a superset of the GPL
permissions, the combined work is effectively covered by the GPL.
However, the BSD-without-advertising code retains its own license, and
provided it remains an "identifiable section" of the program and "can
be reasonably considered independent and separate" in itself, then
anyone may copy that code from the combined work and use it according
to the BSD-without-advertising license. See clause 2, paragraph 5 of
the GPL. Unfortunately it is not 100% clear on this matter.
Whether that code remains independent and separate will depend on the
changes made and the licensing of patches, which is a grey area
because people don't tend to make the licensing of Linux patches
clear. Most likely, as soon as people make changes to the code within
the context of Linux development, it may be assumed that the derived
work (the hfsc code + patches from Linux authors) is covered by the GPL.
Btw, IANAL.
-- Jamie
^ permalink raw reply
* Re: UDEV and USB Mass Storage
From: Greg KH @ 2004-01-26 23:58 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <200401241909.29233.tom.gufler@tirol.com>
On Sat, Jan 24, 2004 at 07:09:29PM +0100, Thomas Gufler wrote:
> Hello,
>
> I use udev-013 on an gentoo 1.4 system. When I connect my USB mass storage
> camera (Sony DSC-P1) for the first time I get a /dev/sda1 device, however
> when I connect the camera for the second time I get /dev/sdb1.
Did you run 'eject' and unmount the device after you were done with it,
before (or after) you removed it?
> What is needed to get always the same device for a mass storage device? Can
> someone show me how an entry in udev.rules should look like for this
> behavior?
I use:
BUS="usb", SYSFS_vendor="FUJIFILM", SYSFS_model="M100", NAME="camera%n"
to name my camera.
Hope this helps,
greg k-h
-------------------------------------------------------
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: [ANNOUNCE] udev 015 release
From: Greg KH @ 2004-01-26 23:56 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20040126215036.GA6906@kroah.com>
On Mon, Jan 26, 2004 at 11:15:39PM +0100, Tomasz Torcz wrote:
> On Mon, Jan 26, 2004 at 01:50:36PM -0800, Greg KH wrote:
> > I've released the 015 version of udev. It can be found at:
>
> Great, 15 minuts after I've installed 014 ;-)
>
> 014 and 015 errors for me when made with 'make USE_DBUS=true':
Here's a patch to fix this. I've never tested the DBUS stuff before, so
had to go install the latest packages...
Sorry about that.
greg k-h
# allow dbus code to actually build again.
diff -Nru a/udev_dbus.c b/udev_dbus.c
--- a/udev_dbus.c Mon Jan 26 15:54:56 2004
+++ b/udev_dbus.c Mon Jan 26 15:54:56 2004
@@ -12,6 +12,7 @@
#include "udev.h"
#include "udev_version.h"
#include "udev_dbus.h"
+#include "logging.h"
/** variable for the connection the to system message bus or #NULL
-------------------------------------------------------
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
* [LARTC] HTB/SFQ dequeueing in pairs
From: Andy Furniss @ 2004-01-26 23:54 UTC (permalink / raw)
To: lartc
I set up a little test to see what the behaviour of (e)sfq was - because
I couldn't work it out from the source :-) .
I wanted to see where from a slot the packets got dropped when the queue
was full. (e)sfq drops from the longest slot to make space for an
incoming packet, so it's not tail drop as such, but the results show me
it does drop from the tail of the slot - which if you are trying to
shape inbound, is a PITA as tcp "slow" start grows exponentially and
overflows into my ISP/telecos buffer, causing a latency bump. I think it
would be alot nicer if It head dropped to make the sender go into
congestion control quicker.
However this is not the reason for this post. I tested by capturing with
tcpdump before and after the queue.
I noticed that the packets were being released in pairs, which probably
doesn't help either.
I assume it is htb that calls esfq to dequeue a packet - but I don't know.
For the test my DWIFLIMIT bandwidth was set at 51kbit/s which is 10% of
my bandwidth.
My mtu is set at 1478 as it's slightly more efficient for adsl using
pppoa/vcmux in the UK.
I used -
$TC class add dev $DWIF parent 1:2 classid 1:21 htb rate
$[$DWIFLIMIT/2]kbit \
ceil ${DWIFLIMIT}kbit burst 0b cburst 0b mtu 1478 quantum 1478
prio 1
$TC qdisc add dev $DWIF parent 1:21 handle 21: esfq perturb 0 hash
classic limit 10
This is part of tc -s -d class show dev imq1
class htb 1:21 parent 1:2 leaf 21: prio 1 quantum 1478 rate 25Kbit ceil
51Kbit burst 1507b/8 mpu 0b cburst 1540b/8 mpu 0b level 0
Is there anything obvious here that would cause the packets to dequeue
in pairs.
TIA
Andy.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: PNP depends on ISA ? (2.6.2-rc2
From: Adam Belay @ 2004-01-26 18:37 UTC (permalink / raw)
To: David Sanders; +Cc: linux-kernel
In-Reply-To: <200401261813.48324@sandersweb.net>
On Mon, Jan 26, 2004 at 06:15:43PM -0500, David Sanders wrote:
> On Monday 26 January 2004 11:17 am, Adam Belay wrote:
> > On Mon, Jan 26, 2004 at 09:31:44PM +0200, Micha Feigin wrote:
> > > I was wondering why pnp depends on isa being selected in 2.6.2-rc2,
>
> > Yes, it only is related to isa devices, but they include onboard
> I the 2.4.x kernel I seem to remember being able to cat /proc/isapnp
> and getting info about pnp devices on my system. Is there an
> equivalent in 2.6.x ?
Yes. A complete interface, including id information and control over
resource management is provided through sysfs.
#mkdir /sys
#mount -t sysfs none /sys
Look in /sys/bus/pnp for more information.
Thanks,
Adam
^ permalink raw reply
* Re: 2.6.2-rc in BK: Oops loading parport_pc.
From: bill davidsen @ 2004-01-26 23:46 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20040126010832.GA5462@merlin.emma.line.org>
In article <20040126010832.GA5462@merlin.emma.line.org>,
Matthias Andree <matthias.andree@gmx.de> wrote:
| On Sun, 25 Jan 2004, Andrew Morton wrote:
|
| > Matthias Andree <matthias.andree@gmx.de> wrote:
| > >
| > > Loading the parport_pc modules crashes in 2.6.2-rc; I have recently done
| > > a "bk pull" and enabled some PNP options, among them ISA PNP.
| >
| > Often this is because some other, unrelated module left things registered
| > after it was removed. Or otherwise wrecked shared data structures.
|
| The breakage is somehow related to CONFIG_PNP. I set that option to N,
| ran "make oldconfig ; make", installed the kernel, rebooted, problem
| gone.
2.6.2-rc2:
root> grep PNP .config
CONFIG_PNP=y
CONFIG_PNP_DEBUG=y
CONFIG_ISAPNP=y
CONFIG_PNPBIOS=y
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
Boots and loads parport_pc just fine, so it looks as if either it got
fixed (likely) or other evildoers are at work.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
* Re: Strange xmms deaths under high disk load
From: Måns Rullgård @ 2004-01-26 23:45 UTC (permalink / raw)
To: Nick Piggin; +Cc: linux-kernel
In-Reply-To: <4015A24A.3090101@cyberone.com.au>
Nick Piggin <piggin@cyberone.com.au> writes:
>>If I play music with TCVP instead, it keeps playing, but sound is
>>choppy at intervals. Below is vmstat output during a copying.
>>
>>procs ---------memory---------- ---swap-- -----io---- --system-- ----cpu----
>> r b swpd free buff cache si so bi bo in cs us sy id wa
>> 0 0 0 86128 3424 165920 0 0 66 66 24 4 23 23 54 0
>> 0 0 0 86128 3424 165920 0 0 0 0 1131 1352 17 14 69 0
>> 0 0 0 86128 3424 165920 0 0 0 0 1128 1360 13 4 84 0
>> 0 0 0 86128 3424 165920 0 0 0 0 1129 1351 13 4 84 0
>> 0 0 0 86128 3424 165920 0 0 0 153 1142 1361 14 3 83 0
>> 0 0 0 86128 3424 165920 0 0 0 0 1127 1353 14 4 83 0
>> 0 0 0 86128 3424 165920 0 0 0 0 1128 1348 12 3 84 0
>> 0 0 0 86128 3424 165920 0 0 0 0 1130 1344 17 15 69 0
>> 0 0 0 86000 3424 166048 0 0 128 0 1132 1356 13 3 84 0
>>
> ...
>
>>11 2 0 2400 3392 246368 0 0 768 26112 969 626 25 71 0 3
>>
> ...
>
>>11 0 0 3040 1704 248160 0 0 0 33704 696 58 10 90 0 0
>>
> ...
>
>>
>> 1 1 0 2528 1736 250608 0 0 1756 21332 965 590 35 56 0 8
>>
>
> Looks like you might be losing timer interrupts, possibly caused by
> an IDE disk doing PIO?
All the disks are doing ATA-100, so that's not it. Something else
could have caused it, of course. Rather bad of xmms to crash, too.
What worries me most is the file corruption I saw in connection with
one such crash. It hasn't happened again, though.
--
Måns Rullgård
mru@kth.se
^ permalink raw reply
* [LARTC] NEW imq driver
From: Roy @ 2004-01-26 23:47 UTC (permalink / raw)
To: lartc
Finaly I made imq driver stable it did not crashed for all 5 hours under
high load, soo looks stable.
(old one was crashing after 1-5 min for me)
no need to patch anything just compile and insmod, should work with any
kernel probably must be > than 2.4.20
This is completely diferent code than old imq.
you can find it on my server http://pupa.da.ru
please tell how it works for you and how stable it is.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* kernel BUG at include/linux/list.h:148!
From: David Martínez Moreno @ 2004-01-26 23:42 UTC (permalink / raw)
To: linux-kernel, Andrew Morton; +Cc: ender
Hello, I'm using -mm branch since 2.6.0-pre kernels, and now I'm finding
problems (well, *another* type of problems) since 2.6.1-rc1-mm2. Last kernel
without this error was 2.6.1-rc2-mm1.
The error is always the same (at least to me, poor non kernel-hacker):
------------[ cut here ]------------
kernel BUG at include/linux/list.h:148!
invalid operand: 0000 [#1]
CPU: 0
EIP: 0060:[<c012ee1d>] Not tainted VLI
EFLAGS: 00010203
EIP is at __remove_from_page_cache+0x71/0x7b
eax: c13e22b8 ebx: dd2058bc ecx: c13e22c0 edx: c1122c90
esi: c13e22b8 edi: dfdb5e60 ebp: dd2058bc esp: dfdb5d88
ds: 007b es: 007b ss: 0068
Process kswapd0 (pid: 8, threadinfo=dfdb4000 task=dfdbace0)
Stack: dd2058c0 000145cd 00000001 c13e22b8 c0137e0b c13e22b8 c02fce0a d6df1480
00000001 000000b1 00000000 dfdb5db4 dfdb5db4 dfdb5dc0 00000003 c04ade88
00000001 c10502f8 c03d58b4 00000003 c04b0560 00000001 00000001 c13a7c80
Call Trace:
[<c0137e0b>] shrink_list+0x2c0/0x476
[<c02fce0a>] __kfree_skb+0x68/0xd9
[<c013813f>] shrink_cache+0x17e/0x2df
[<c015b74b>] shrink_dcache_memory+0x23/0x25
[<c0137a76>] shrink_slab+0x11b/0x15e
[<c0138b4a>] balance_pgdat+0x18e/0x21e
[<c0138cec>] kswapd+0x112/0x122
[<c011add5>] autoremove_wake_function+0x0/0x4f
[<c011add5>] autoremove_wake_function+0x0/0x4f
[<c0138bda>] kswapd+0x0/0x122
[<c0108d45>] kernel_thread_helper+0x5/0xb
Code: 01 10 00 c7 46 10 00 00 00 00 83 6b 30 01 83 05 80 04 4b c0 ff 8b 74 24 0c 8b 5c 24 08 83 c4 10 c3 0f 0b 95 00 f6 e8 38 c0 eb c5 <0f> 0b 94 00 f6 e8 38 c0 eb b3 8b 54 24 04 8b 02 f7 d0 a8 01 75
This error, for example, is printed with the server's current kernel,
2.6.2-rc1-mm1.
The machine is P4 with XFS over RAID0 by software, Apache2 in thread mode,
and root filesystem on ext3.
Please don't hesitate to request further info.
Kind regards,
Ender.
^ permalink raw reply
* Re: [PATCH 2.6.2-rc1-mm3] fs/xfs/xfs_log_recover.c
From: Nathan Scott @ 2004-01-26 23:41 UTC (permalink / raw)
To: Bryan Whitehead; +Cc: linux-kernel
In-Reply-To: <20040125044859.8A67F13A354@mrhankey.megahappy.net>
On Sat, Jan 24, 2004 at 08:48:59PM -0800, Bryan Whitehead wrote:
> On compile I get this:
>
> fs/xfs/xfs_log_recover.c: In function `xlog_recover_reorder_trans':
> fs/xfs/xfs_log_recover.c:1534: warning: `flags' might be used uninitialized in this function
>
> I previously sent this patch and it was wrong.
What compiler version are you using? Is this a recent gcc or an
older version - if the former, is gcc really getting dumber? if
the latter, I'm wondering why I haven't come across this anytime
in the last few years of compiling xfs. Or is this some non-gcc
compiler out of left field?
thanks.
--
Nathan
^ permalink raw reply
* Re: New NUMA scheduler and hotplug CPU
From: Andrew Theurer @ 2004-01-26 23:40 UTC (permalink / raw)
To: Nick Piggin, Martin J. Bligh; +Cc: Rusty Russell, linux-kernel
In-Reply-To: <40159C41.9030707@cyberone.com.au>
> >To me, it'd make more sense to add the CPUs to the scheduler structures
> >as they get brought online. I can also imagine machines where you have
> >a massive (infinite?) variety of possible CPUs that could appear -
> >like an NUMA box where you could just plug arbitrary numbers of new
> >nodes in as you wanted.
>
> I guess so, but you'd still need NR_CPUS to be >= that arbitrary
> number.
>
> >Moreover, as the CPUs aren't fixed numbers in advance, how are you going
> >to know which node to put them in, etc? Setting up every possible thing
> >in advance seems like an infeasible way to do hotplug to me.
>
> Well this would be the problem. I guess its quite possible that
> one doesn't know the topology of newly added CPUs before hand.
>
> Well OK, this would require a per architecture function to handle
> CPU hotplug. It could possibly just default to arch_init_sched_domains,
> and just completely reinitialise everything which would be the simplest.
Call me crazy, but why not let the topology be determined via userspace at a
more appropriate time? When you hotplug, you tell it where in the scheduler
to plug it. Have structures in the scheduler which represent the
nodes-runqueues-cpus topology (in the past I tried a node/rq/cpu structs with
simple pointers), but let the topology be built based on user's desires thru
hotplug.
For example, you boot on just the boot cpu, which by default is in the first
node on the first runqueue. All other cpus, whether being "booted" for the
for the first time or hotplugged (maybe now there's really no difference),
the hotplugging tells where the cpu should be, in what node and what
runqueue. HT cpus work even better, because you can hotplug siblings, once
at a time if you wanted, to the same runqueue. Or you have cpus sharing a
die, same thing, lots of choices here. This removes any per-arch updates to
the kernel for things like scheduler topology, and lets them go somewhere
else more easily changes, like userspace.
Forgive me if this sounds stupid; I have not been following the discussion
closely.
^ permalink raw reply
* Re: FYI: ACPI 'sleep 1' resets atkbd keycodes
From: bill davidsen @ 2004-01-26 23:41 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <200401251137.21646.p_christ@hol.gr>
In article <200401251137.21646.p_christ@hol.gr>,
P. Christeas <p_christ@hol.gr> wrote:
| This may be just a minor issue:
| I had to use the setkeycodes utility to enable some extra keys (that weren't
| mapped by kernel's atkbd tables).
| After waking from sleep 1, those keys were reset. That is, I had to use
| 'setkeycodes' again to customize the tables again.
|
| IMHO the way kernel works now is correct. It should *not* have extra code just
| to handle that. Just make sure anybody that alters his kbd tables puts some
| extra script to recover the tables after an ACPI wake.
| This should be more like a note to Linux distributors.
I'm not totally sure I agree that the kernel should save this
information. With all the things the kernel does save, keyboard might be
a good thing. Consider someone with a REALLY hacked layout, like
modified dvorak or some of the keyboards for the access challenged. Now
think "can't use the keyboard enough to type in the ...ing commands to
do the load."
If we can carry the code for two competing disfunctional ACPI
implementations and a used-to-work but we broke it for some machines
APM, we can surely add a pair om memcpy lines to eliminate at least one
"oh-shit moment."
Obviously my opinion only, some breakage due to BIOS misfeatures,
contents may settle in shipping, etc.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
* Re: [PATCH] multple rules files support/symlink rules support
From: Kay Sievers @ 2004-01-26 23:42 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <200401172313.00189.arvidjaar@mail.ru>
On Mon, Jan 26, 2004 at 08:31:23PM +0300, Andrey Borzenkov wrote:
> On Thursday 22 January 2004 20:44, Svetoslav Slavtchev wrote:
> > > On Sat, Jan 17, 2004 at 11:13:00PM +0300, Andrey Borzenkov wrote:
> > > > Attached patch adds support for
> > > >
> > > > - multiple rules files. You can now do
...
> I do not :) the only reason to allow multiple files was to allow overriding; I
> had to update patch for ude-014 and sorting directory contents turned out to
> be quite easy so this is the final version - it takes single name which is
> either file or directory; directory is scanned, sorted in ascending order and
> read. klibc version does not support directory.
>
> > >
> > > I don't really understand this. Can you give an example of how this
> > > would work? Why do we want to have multiple symlinks from different
> > > rules?
>
> you simply can't easily merge these two rules. Allowing second rule (in second
> file) is much more flexible - you simply get two symlinks pointing to the
> same file. None of them knows or cares about device is really named as long
> as symlinks are correctly created.
>
> because this version assumes configuration be ordered it now ignores name only
> if it has not already been defined; else name with empty NAME/SYMLINK is
> silently ignored.
Uhh, why do this inside of udev?
You must be root to setup the rules. So we can expect that you are able
to run a update script or something that creates the main file.
This can also merge your conflicting rules if needed.
thanks,
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: New NUMA scheduler and hotplug CPU
From: Nick Piggin @ 2004-01-26 23:40 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Rusty Russell, linux-kernel
In-Reply-To: <31860000.1075159471@flay>
Martin J. Bligh wrote:
>>>Well isn't it a bad idea to have cpus in the data that are offline?
>>>It'll throw off all your balancing calculations, won't it? You seemed
>>>to be careful to do things like divide the total load on the node by
>>>the number of CPUs on the node, and that'll get totally borked if you
>>>have fake CPUs in there.
>>>
>>I think it mostly does a good job at making sure to only take
>>online cpus into account. If there are places where it doesn't
>>then it shouldn't be too hard to fix.
>>
>
>It'd make the code a damned sight simpler and cleaner if you dropped
>all that stuff, and updated the structures when you hotplugged a CPU,
>which is really the only sensible way to do it anyway ...
>
>For instance, if I remove cpu X, then bring back a new CPU on another node
>(or in another HT sibling pair) as CPU X, then you'll need to update all
>that stuff anyway. CPUs aren't fixed position in that map - the ordering
>handed out is arbitrary.
>
>
>>>To me, it'd make more sense to add the CPUs to the scheduler structures
>>>as they get brought online. I can also imagine machines where you have
>>>a massive (infinite?) variety of possible CPUs that could appear -
>>>like an NUMA box where you could just plug arbitrary numbers of new
>>>nodes in as you wanted.
>>>
>>I guess so, but you'd still need NR_CPUS to be >= that arbitrary
>>number.
>>
>
>Yup ... but you don't have to enumerate all possible positions that way.
>See Linus' arguement re dynamic device numbers and ISCSI disks, etc.
>Same thing applies.
>
>
>>Well this would be the problem. I guess its quite possible that
>>one doesn't know the topology of newly added CPUs before hand.
>>
>>Well OK, this would require a per architecture function to handle
>>CPU hotplug. It could possibly just default to arch_init_sched_domains,
>>and just completely reinitialise everything which would be the simplest.
>>
>
>Yeah, it's not trivially simple. But then neither is the rest of CPU
>hotplug, to do it right ;-) Requiring CPU hotplug callback hooks does
>seem to be the right way to interface with the sched code though ...
>
OK you've convinced me.
^ permalink raw reply
* Re: (Wrong ID) USB Crontroller
From: Greg KH @ 2004-01-26 23:39 UTC (permalink / raw)
To: Robert Reardon; +Cc: linux-kernel
In-Reply-To: <1075147348.7156.12.camel@mordor>
On Mon, Jan 26, 2004 at 08:02:28PM +0000, Robert Reardon wrote:
> Hi all,
>
> I've been trying to get USB working with the 2.6 and keep getting
> the attached error messages. The kernel appears (to me at least)
> to detect the USB controller correctly on boot, but it still doesn't
> want to work. This is my first post to the list, so please be gentle
> :-).
>
> The motherboard is a Supermicro 370DDE, currently running
> kernel-2.6.2-rc1-mm3. I've tried to attached any relevant information
> but I'm happy to provide more if it's needed.
>
> cat /proc/version reports:
>
> Linux version 2.6.2-rc1-mm3 (root@mordor) (gcc version 3.3.2 20031218
> (Gentoo Linux 3.3.2-r5, propolice-3.3-7)) #2 SMP Sun Jan 25 21:16:13 GMT
> 2004
>
> Anyone got any ideas?
Yeah, get rid of your usbmodules binary. It's not needed and is causing
the problem.
thanks,
greg k-h
^ permalink raw reply
* atkbd.c: Unknown key released
From: David Sanders @ 2004-01-26 23:37 UTC (permalink / raw)
To: linux-kernel
I keep getting the following in my syslog whenever I startx:
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.
--
David Sanders
linux@sandersweb.net
^ permalink raw reply
* Re: gkrellm reports cpu temp*10! linux-athlon kernel=2.6.2-rc1-mm2
From: Greg KH @ 2004-01-26 23:37 UTC (permalink / raw)
To: Gene Heskett; +Cc: linux-kernel
In-Reply-To: <200401261612.17942.gene.heskett@verizon.net>
On Mon, Jan 26, 2004 at 04:12:17PM -0500, Gene Heskett wrote:
> Hi all;
>
> I just rebooted 2 days ago to 2.6.2-rc1-mm2, and I just now noticed
> that gkrellm is reporting my cpu at 680C. Thats about 10x what its
> running at, still warm at 68C, but functional for 2 years now. I
> didn't have this error under 2.6.1-rc2-mm4.
>
> Any idea what patch to back out? And where to get it?
It's part of the recent i2c changes. Ask on the sensor's list for what
needs to be changed in gkrellm to fix this.
thanks,
greg k-h
^ permalink raw reply
* Re: Fried the onboard Broadcom 4401 network...
From: Andrew Walrond @ 2004-01-26 23:34 UTC (permalink / raw)
To: Jamie Lokier, Tomas Ogren, linux-kernel
In-Reply-To: <20040126123023.GA27087@mail.shareable.org>
On Monday 26 Jan 2004 12:30 pm, Jamie Lokier wrote:
>
> I was startled when I bought a power meter to find that my computers
> and even some monitors consume power when switched off. I don't mean
> "soft" off - even with the mechanical switch in the off position they
> still consume significant power.
>
> My AMD box consumes about 15W of power when the mechanical switch on
> its power supply is off. About 35W when the mechanical switch is on
> but the computer is in the "soft off" state (i.e. what you get when
> you ask it to turn itself off).
>
I've got some dual xeon machines where the psu's get too hot to touch when
switched _off_! Thankfully they run cool when switched on (and the fan is
running) I've always assumed some sort of fault, but maybe not...
Andrew Walrond
^ permalink raw reply
* Re: [patch] 2.6.1-mm5 compile do not use shared extable code for ia64
From: David Mosberger @ 2004-01-26 23:33 UTC (permalink / raw)
To: Paul Mackerras
Cc: davidm, Andrew Morton, Jes Sorensen, linux-kernel, linux-ia64
In-Reply-To: <16402.19894.686335.695215@cargo.ozlabs.ibm.com>
>>>>> On Sat, 24 Jan 2004 21:49:26 +1100, Paul Mackerras <paulus@samba.org> said:
Paul> David Mosberger writes:
>> How about something along these lines? If you want to
>> standardize on a single instruction-address format, I'd strongly
>> favor using the location-relative addresses used on Alpha and
>> ia64 (it makes no sense to uses a full 64-bit address for those
>> members).
Paul> Won't you have to change the offset when you move the entry,
Paul> if the value you store is relative to the address of the
Paul> entry?
Details, details!
How about the attached one? It will touch memory more when moving an
element down, but we're talking about exception tables here, and I
don't think module loading time would be affected in any noticable
fashion.
--david
===== arch/ia64/mm/extable.c 1.7 vs edited =====
--- 1.7/arch/ia64/mm/extable.c Sun Jan 18 03:36:30 2004
+++ edited/arch/ia64/mm/extable.c Fri Jan 23 18:04:24 2004
@@ -10,11 +10,6 @@
#include <asm/uaccess.h>
#include <asm/module.h>
-void sort_extable(struct exception_table_entry *start,
- struct exception_table_entry *finish)
-{
-}
-
const struct exception_table_entry *
search_extable (const struct exception_table_entry *first,
const struct exception_table_entry *last,
===== include/asm-ia64/uaccess.h 1.16 vs edited =====
--- 1.16/include/asm-ia64/uaccess.h Fri Jan 23 16:43:32 2004
+++ edited/include/asm-ia64/uaccess.h Mon Jan 26 15:15:28 2004
@@ -283,13 +283,42 @@
__su_ret; \
})
-#define ARCH_HAS_SORT_EXTABLE
#define ARCH_HAS_SEARCH_EXTABLE
struct exception_table_entry {
- int addr; /* gp-relative address of insn this fixup is for */
- int cont; /* gp-relative continuation address; if bit 2 is set, r9 is set to 0 */
+ int addr; /* loc-relative address of insn this fixup is for */
+ int cont; /* loc-relative continuation address; if bit 2 is set, r9 is set to 0 */
};
+
+static inline int
+extable_compare_entries (struct exception_table_entry *l, struct exception_table_entry *r)
+{
+ u64 lip = (u64) &l->addr + l->addr;
+ u64 rip = (u64) &r->addr + r->addr;
+
+ if (lip < rip)
+ return -1;
+ if (lip == rip)
+ return 0;
+ else
+ return 1;
+}
+
+static inline void
+extable_swap_entries (struct exception_table_entry *l, struct exception_table_entry *r)
+{
+ u64 delta = (u64) r - (u64) l;
+ struct exception_table_entry tmp;
+
+ tmp = *l;
+ l->addr = r->addr + delta;
+ l->cont = r->cont + delta;
+ r->addr = tmp.addr - delta;
+ r->cont = tmp.cont - delta;
+}
+
+#define extable_compare_entries extable_compare_entries
+#define extable_swap_entries extable_swap_entries
extern void handle_exception (struct pt_regs *regs, const struct exception_table_entry *e);
extern const struct exception_table_entry *search_exception_tables (unsigned long addr);
===== lib/extable.c 1.3 vs edited =====
--- 1.3/lib/extable.c Tue Jan 20 17:58:55 2004
+++ edited/lib/extable.c Mon Jan 26 15:23:12 2004
@@ -18,7 +18,25 @@
extern struct exception_table_entry __start___ex_table[];
extern struct exception_table_entry __stop___ex_table[];
-#ifndef ARCH_HAS_SORT_EXTABLE
+#ifndef extable_compare_entries
+
+/*
+ * Compare exception-table entries L and R and return <0 if L is smaller, 0 if L and R are
+ * equal and >0 if L is bigger.
+ */
+# define extable_compare_entries(l,r) ((l)->insn - (r)->insn)
+
+static inline void
+extable_swap_entries (struct exception_table_entry *l, struct exception_table_entry *r)
+{
+ struct exception_table_entry tmp;
+
+ tmp = *l;
+ *l = *r;
+ *r = tmp;
+}
+#endif /* !extable_compare_entries */
+
/*
* The exception table needs to be sorted so that the binary
* search that we use to find entries in it works properly.
@@ -28,25 +46,14 @@
void sort_extable(struct exception_table_entry *start,
struct exception_table_entry *finish)
{
- struct exception_table_entry el, *p, *q;
+ struct exception_table_entry *p, *q;
/* insertion sort */
- for (p = start + 1; p < finish; ++p) {
- /* start .. p-1 is sorted */
- if (p[0].insn < p[-1].insn) {
- /* move element p down to its right place */
- el = *p;
- q = p;
- do {
- /* el comes before q[-1], move q[-1] up one */
- q[0] = q[-1];
- --q;
- } while (q > start && el.insn < q[-1].insn);
- *q = el;
- }
- }
+ for (p = start + 1; p < finish; ++p)
+ /* start .. p-1 is sorted; push p down to it's proper place */
+ for (q = p; q > start && extable_compare_entries(&q[0], &q[-1]) < 0; --q)
+ extable_swap_entries(&q[0], &q[-1]);
}
-#endif
#ifndef ARCH_HAS_SEARCH_EXTABLE
/*
^ permalink raw reply
* Re: [patch] 2.6.1-mm5 compile do not use shared extable code for
From: David Mosberger @ 2004-01-26 23:33 UTC (permalink / raw)
To: Paul Mackerras
Cc: davidm, Andrew Morton, Jes Sorensen, linux-kernel, linux-ia64
In-Reply-To: <16402.19894.686335.695215@cargo.ozlabs.ibm.com>
>>>>> On Sat, 24 Jan 2004 21:49:26 +1100, Paul Mackerras <paulus@samba.org> said:
Paul> David Mosberger writes:
>> How about something along these lines? If you want to
>> standardize on a single instruction-address format, I'd strongly
>> favor using the location-relative addresses used on Alpha and
>> ia64 (it makes no sense to uses a full 64-bit address for those
>> members).
Paul> Won't you have to change the offset when you move the entry,
Paul> if the value you store is relative to the address of the
Paul> entry?
Details, details!
How about the attached one? It will touch memory more when moving an
element down, but we're talking about exception tables here, and I
don't think module loading time would be affected in any noticable
fashion.
--david
=== arch/ia64/mm/extable.c 1.7 vs edited ==--- 1.7/arch/ia64/mm/extable.c Sun Jan 18 03:36:30 2004
+++ edited/arch/ia64/mm/extable.c Fri Jan 23 18:04:24 2004
@@ -10,11 +10,6 @@
#include <asm/uaccess.h>
#include <asm/module.h>
-void sort_extable(struct exception_table_entry *start,
- struct exception_table_entry *finish)
-{
-}
-
const struct exception_table_entry *
search_extable (const struct exception_table_entry *first,
const struct exception_table_entry *last,
=== include/asm-ia64/uaccess.h 1.16 vs edited ==--- 1.16/include/asm-ia64/uaccess.h Fri Jan 23 16:43:32 2004
+++ edited/include/asm-ia64/uaccess.h Mon Jan 26 15:15:28 2004
@@ -283,13 +283,42 @@
__su_ret; \
})
-#define ARCH_HAS_SORT_EXTABLE
#define ARCH_HAS_SEARCH_EXTABLE
struct exception_table_entry {
- int addr; /* gp-relative address of insn this fixup is for */
- int cont; /* gp-relative continuation address; if bit 2 is set, r9 is set to 0 */
+ int addr; /* loc-relative address of insn this fixup is for */
+ int cont; /* loc-relative continuation address; if bit 2 is set, r9 is set to 0 */
};
+
+static inline int
+extable_compare_entries (struct exception_table_entry *l, struct exception_table_entry *r)
+{
+ u64 lip = (u64) &l->addr + l->addr;
+ u64 rip = (u64) &r->addr + r->addr;
+
+ if (lip < rip)
+ return -1;
+ if (lip = rip)
+ return 0;
+ else
+ return 1;
+}
+
+static inline void
+extable_swap_entries (struct exception_table_entry *l, struct exception_table_entry *r)
+{
+ u64 delta = (u64) r - (u64) l;
+ struct exception_table_entry tmp;
+
+ tmp = *l;
+ l->addr = r->addr + delta;
+ l->cont = r->cont + delta;
+ r->addr = tmp.addr - delta;
+ r->cont = tmp.cont - delta;
+}
+
+#define extable_compare_entries extable_compare_entries
+#define extable_swap_entries extable_swap_entries
extern void handle_exception (struct pt_regs *regs, const struct exception_table_entry *e);
extern const struct exception_table_entry *search_exception_tables (unsigned long addr);
=== lib/extable.c 1.3 vs edited ==--- 1.3/lib/extable.c Tue Jan 20 17:58:55 2004
+++ edited/lib/extable.c Mon Jan 26 15:23:12 2004
@@ -18,7 +18,25 @@
extern struct exception_table_entry __start___ex_table[];
extern struct exception_table_entry __stop___ex_table[];
-#ifndef ARCH_HAS_SORT_EXTABLE
+#ifndef extable_compare_entries
+
+/*
+ * Compare exception-table entries L and R and return <0 if L is smaller, 0 if L and R are
+ * equal and >0 if L is bigger.
+ */
+# define extable_compare_entries(l,r) ((l)->insn - (r)->insn)
+
+static inline void
+extable_swap_entries (struct exception_table_entry *l, struct exception_table_entry *r)
+{
+ struct exception_table_entry tmp;
+
+ tmp = *l;
+ *l = *r;
+ *r = tmp;
+}
+#endif /* !extable_compare_entries */
+
/*
* The exception table needs to be sorted so that the binary
* search that we use to find entries in it works properly.
@@ -28,25 +46,14 @@
void sort_extable(struct exception_table_entry *start,
struct exception_table_entry *finish)
{
- struct exception_table_entry el, *p, *q;
+ struct exception_table_entry *p, *q;
/* insertion sort */
- for (p = start + 1; p < finish; ++p) {
- /* start .. p-1 is sorted */
- if (p[0].insn < p[-1].insn) {
- /* move element p down to its right place */
- el = *p;
- q = p;
- do {
- /* el comes before q[-1], move q[-1] up one */
- q[0] = q[-1];
- --q;
- } while (q > start && el.insn < q[-1].insn);
- *q = el;
- }
- }
+ for (p = start + 1; p < finish; ++p)
+ /* start .. p-1 is sorted; push p down to it's proper place */
+ for (q = p; q > start && extable_compare_entries(&q[0], &q[-1]) < 0; --q)
+ extable_swap_entries(&q[0], &q[-1]);
}
-#endif
#ifndef ARCH_HAS_SEARCH_EXTABLE
/*
^ permalink raw reply
* Re: 2.6.2-rc1 / ACPI sleep / irqbalance / kirqd / pentium 4 HT problems on Uniwill N258SA0
From: bill davidsen @ 2004-01-26 23:33 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20040124233749.5637.COUNT0@localnet.com>
In article <20040124233749.5637.COUNT0@localnet.com>,
Huw Rogers <count0@localnet.com> wrote:
| Uniwill N258SA0 (http://www.uniwill.com/Product/N258SA0/N258SA0.html) aka
| Hypersonic Aviator NX6, Fujitsu-Siemens AMILO D 1840 Widescreen, etc.).
| SiS 648FX chipset, SiS 900 Ethercard, AMI BIOS, ATI AV350/M10 128Mb.
| My machine: Hyperthreaded P4 2.8GHz, .5Gb PC3200 RAM.
|
| Installed Fedora. Upgraded to 2.6.2-rc1 per
| http://thomer.com/linux/migrate-to-2.6.html.
|
| Applied kernel patches:
| - SiS AGP (http://lkml.org/lkml/2004/1/20/233)
| (needed to run ATI's 3.7 fglrx drivers on the SiS/M10 combo)
| - ACPI 20031203 (http://acpi.sourceforge.net/)
|
| All good, but ACPI sleep doesn't work and neither does userland IRQ
| balancing with Arjan's irqbalance (http://people.redhat.com/arjanv/irqbalance/),
| a standard part of the Fedora install.
Let me ask a question which probably has an obvious answer... why do you
care to balance the irq on the siblings of a single CPU? Is there some
hidden value I totally miss?
Noting that WBEL-3.0 balances all of the interrupts *except* NICs, I am
sure I don't understand the benefits of balancing between siblings, but
I'm sure someone will enlighten me.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
* Re: Strange xmms deaths under high disk load
From: Nick Piggin @ 2004-01-26 23:27 UTC (permalink / raw)
To: Måns Rullgård; +Cc: linux-kernel
In-Reply-To: <yw1xu12i1fak.fsf@ford.guide>
Måns Rullgård wrote:
>I have encountered a very strange (to me, at least) error. I can
>reliably cause xmms to crash by simply doing some intensive disk IO.
>Copying a few hundred megabytes usually does it. After about 20
>seconds of heavy disk IO, xmms will die with this message:
>
>** WARNING **: snd_pcm_wait: Input/output error
>Xlib: unexpected async reply (sequence 0x2ef5c)!
>
>The hex number varies.
>
>The machine is an Alpha SX164 running Linux 2.6.2-rc2 patched up to
>ALSA 1.0.1. The problem has been around for quite a while, probably
>also with kernel 2.4.21, though I can't confirm that at the moment.
>The sound card is a cmi8738.
>
>If I play music with TCVP instead, it keeps playing, but sound is
>choppy at intervals. Below is vmstat output during a copying.
>
>procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
> r b swpd free buff cache si so bi bo in cs us sy id wa
> 0 0 0 86128 3424 165920 0 0 66 66 24 4 23 23 54 0
> 0 0 0 86128 3424 165920 0 0 0 0 1131 1352 17 14 69 0
> 0 0 0 86128 3424 165920 0 0 0 0 1128 1360 13 4 84 0
> 0 0 0 86128 3424 165920 0 0 0 0 1129 1351 13 4 84 0
> 0 0 0 86128 3424 165920 0 0 0 153 1142 1361 14 3 83 0
> 0 0 0 86128 3424 165920 0 0 0 0 1127 1353 14 4 83 0
> 0 0 0 86128 3424 165920 0 0 0 0 1128 1348 12 3 84 0
> 0 0 0 86128 3424 165920 0 0 0 0 1130 1344 17 15 69 0
> 0 0 0 86000 3424 166048 0 0 128 0 1132 1356 13 3 84 0
>
...
>11 2 0 2400 3392 246368 0 0 768 26112 969 626 25 71 0 3
>
...
>11 0 0 3040 1704 248160 0 0 0 33704 696 58 10 90 0 0
>
...
>
> 1 1 0 2528 1736 250608 0 0 1756 21332 965 590 35 56 0 8
>
Looks like you might be losing timer interrupts, possibly caused
by an IDE disk doing PIO?
^ permalink raw reply
* Re: [Bluez-devel] Device specific pins
From: Marcel Holtmann @ 2004-01-26 23:26 UTC (permalink / raw)
To: Dave Henriksen; +Cc: BlueZ Mailing List
In-Reply-To: <1075157711.3751.1.camel@linux.local>
Hi Dave,
> Thanks for the reply. Are you saying that the BD_ADDR gets passed into
> the pin helper script as a parameter ? Or is it an environment variable
> that I can reference within my pin_helper script ?
it is a parameter. For more details look at utils/hcid/security.c at
line 254ff.
Regards
Marcel
-------------------------------------------------------
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
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ 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.