headers
Sebastian Pigulak | 1 Jul 2005 01:01
Picon
Favicon

Re: [2.6 patch] SENSORS_ATXP1 must select I2C_SENSOR

On Fri, 1 Jul 2005 00:17:27 +0200
Adrian Bunk <bunk <at> stusta.de> wrote:

> On Thu, Jun 30, 2005 at 11:47:09PM +0200, Sebastian Pigulak wrote:
> 
> > Hey,
> 
> Hi Sebastian,
> 
> > I've tried patching linux-2.6.13-RC1 with patch-2.6.13-rc1-git2 and building atxp1(it allows Vcore
voltage changing) into the kernel. Unfortunately, the kernel compilation stops with:
> > 
> > LD      init/built-in.o
> > LD      vmlinux
> > drivers/built-in.o(.text+0x92298): In function `atxp1_detect':
> > : undefined reference to `i2c_which_vrm'
> > drivers/built-in.o(.text+0x921ae): In function `atxp1_attach_adapter':
> > : undefined reference to `i2c_detect'
> > make: *** [vmlinux] B??d 1
> > ==> ERROR: Build Failed.  Aborting... 
> > 
> > Could someone have a look at the module and possibly fix it up?
> 
> The patch below should fix it.
> 
> cu
> Adrian
> 
> 
> <--  snip  -->
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 Jul 2005 01:05

Re: setitimer expire too early (Kernel 2.4)

Marcelo Tosatti <marcelo.tosatti <at> cyclades.com> wrote:
>
> On Thu, Jun 30, 2005 at 09:14:50PM +0200, Olivier Croquette wrote:
> > 
> > I am refering to this bug:
> > 
> > http://bugzilla.kernel.org/show_bug.cgi?id=4569
> > 
> > A thread led to a patch from Paulo:
> > 
> > http://kerneltrap.org/mailarchive/1/message/59454/flat
> > 
> > This patch has been included in the kernel 2.6.12.
> > 
> > 1. How can I easily check if the patch is planned for include in the 2.4?
> > 
> > 2. I downloaded the full 2.4.31 source code. The patch appears not to be 
> > included. Where/Who should I signal that?
> 
> And what about the side effects:
> This however will produce pathological cases, like having a idle system
> being requested 1 ms timeouts will give systematically 2 ms timeouts,
> whereas currently it simply gives a few usecs less than 1 ms. 

(20ms rather than 10ms)

> Linus, Andrew, do you consider this critical enough to be merged to 
> the v2.4 tree?

No.  I'd expect this would hurt more people than it would benefit.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Paul E. McKenney | 1 Jul 2005 01:08
Picon
Favicon

Re: PREEMPT_RT and I-PIPE: the numbers, take 3

On Thu, Jun 30, 2005 at 06:17:26PM +0200, Ingo Molnar wrote:
> 
> * Paul E. McKenney <paulmck <at> us.ibm.com> wrote:
> 
> > > another point is that this test is measuring the overhead of PREEMPT_RT, 
> > > without measuring the benefit of the cost: RT-task scheduling latencies.  
> > > We know since the rtirq patch (to which i-pipe is quite similar) that we 
> > > can achieve good irq-service latencies via relatively simple means, but 
> > > that's not what PREEMPT_RT attempts to do. (PREEMPT_RT necessarily has 
> > > to have good irq-response times too, but much of the focus went to the 
> > > other aspects of RT task scheduling.)
> > 
> > Agreed, a PREEMPT_RT-to-IPIPE comparison will never be an 
> > apples-to-apples comparison.  Raw data will never be a substitute for 
> > careful thought, right?  ;-)
> 
> well, it could still be tested, since it's so easy: the dohell script is 
> already doing all of that as it runs rtc_wakeup - which runs a 
> SCHED_FIFO task and carefully measures wakeup latencies. If it is used 
> with 1024 Hz (the default) and it can be used in every test without 
> impacting the system load in any noticeable way.

OK, I think that I finally understand what you are getting at -- and I
agree that it would be interesting to get latency measurements during the
actual lmbench runs.  However, if I understand correctly, you would want
roughly 1,000,000 latency measurements per lmbench run segment, which,
at 1024 Hz, would mean that each segment would take about 20 minutes.
A single lmbench run would then take many hours.

Is this really what you are getting at, or are you instead thinking
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jesper Juhl | 1 Jul 2005 01:20
Picon

Re: reiser4 plugins

On 6/27/05, Markus   Törnqvist <mjt <at> nysv.org> wrote:
[...]
> 
> I hate to say this without digging out any URLs, but one friend
> of mine says he has a very hard time doing any networking code
> because it's too labile. Maybe that's being embettered for something
> else too?
> 
> Or the other friend who curses that the networking code is just
> crap and basically has to rewrite the code to get it working.
> Yes, I've tried to get these guys to submit their code, but they
> argue back that no one wants to see it.
> 
[...]

I'm pretty damn sure the relevant maintainers (and a bunch of people
on LKML and the netdev lists in general) would like to see patches
that improves their code.
If these friends of yours are sitting on patches that make massive
improvements to the code and they are not submitting patches then they
are not exactely helping (and I'd suspect them to just be full of BS)
- they should get their code merged instead of having to maintain it
themselves out-of-tree for ever - let the rest of us bennefit as well.
It's my experience that if you can explain the problems your patch fix
and explain well why the fix is sane, then getting your patches merged
doesn't have to be hard.

--

-- 
Jesper Juhl <jesper.juhl <at> gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 Jul 2005 01:14

Re: -mm -> 2.6.13 merge status (dropped patches?)

Chuck Ebbert <76306.1226 <at> compuserve.com> wrote:
>
> On Mon, 20 Jun 2005 at 23:54:58 -0700, Andrew Morton wrote:
> 
> > This summarises my current thinking on various patches which are presently
> > in -mm.  I cover large things and small-but-controversial things.  Anything
> > which isn't covered here (and that's a lot of material) is probably a "will
> > merge", unless it obviously isn't.
> 
> What happened to:
> 
>         remove-last_rx-update-from-loopback-device.patch

Davem rejected it.  hm, I can't find the email trail - it was cc'ed to
netdev <at> oss.sgi.com mid-March, but nothing seems to have been sent back.

> It was dropped in 2.6.12-rc1-mm4 with a status of "merged" but it's not
> in either 2.6.12 or 2.6.13-rc1.
> 
> And in general, who is tracking whether things are being lost?

Things don't get lost.  I have a habit of misremembering the disposition of
patches when preparing -mm release summaries.
Permalink | Reply | 2 comments |
headers
Benjamin Herrenschmidt | 1 Jul 2005 01:32

Re: PCI Power management (was: Re: [PATCH 4/13]: PCI Err: e100 ethernet driver recovery

On Thu, 2005-06-30 at 15:39 -0500, Linas Vepstas wrote:

> Thus, the right thing to do might be to split up the 
> struct pci_dev->suspend() and pci_dev->resume() calls into
> 
>    suspend()
>    poweroff()
>    poweron()
>    resume()

No. There are very good reasons not to do that split at the pci_dev
level.

> and then have the generic pci error recovery routines call
> suspend/resume only, skipping the poweroff-on calls.  Does that 
> sound good?
> 
> I'm not sure I can pull this off without having someone from 
> the power-management world throw a brick at me.

Just keep the error recovery callbacks for now, and we might be able to
provide a generic "helper" doing the watchdog thing (yes, there is a
watchdog in the net core)

Ben.
Permalink | Reply | 0 comments |
headers
Stephen Rothwell | 1 Jul 2005 01:36
Picon
Picon

Re: xtensa-cleanups-for-errno-and-ipc.patch added to -mm tree

On Thu, 30 Jun 2005 13:07:59 +0200 Arnd Bergmann <arnd <at> arndb.de> wrote:
>
> On Dunnersdag 30 Juni 2005 03:13, akpm <at> osdl.org wrote:
> 
> > From: Chris Zankel <chris <at> zankel.net>
> >
> > I noticed this because I was doing some more ipc cleanups and I did the
> > original errno and ipc cleanups for other architectures, so it stuck out.
> > 
> > Signed-off-by: Stephen Rothwell <sfr <at> canb.auug.org.au>
> > Signed-off-by: Chris Zankel <chris <at> zankel.net>
> > Signed-off-by: Andrew Morton <akpm <at> osdl.org>
> 
> Actually, it would be better not to have sys_ipc or include/asm-xtensa/ipc.h
> at all but rather have all ipc syscalls as separate entry points.

Absolutely true and I think the patch xtensa-remove-old-syscalls.patch
that is in -mm also gets rid of sys_ipc.  If that is the case, then 
include/asm-xtensa/ipc.h can, indeed, be completely removed.

> IIRC, parisc is the only architecture to get this right so far, so please
> have a look there.

alpha, x86_64 also has this done.

--

-- 
Cheers,
Stephen Rothwell                    sfr <at> canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Francois Romieu | 1 Jul 2005 01:37

Re: sis190

Pascal CHAPPERON <pascal.chapperon <at> wanadoo.fr> :
[...]
> 1) sis190 freezes the box when kernel PREEMPT is enabled :
> 
> I made many tries, but i could not solve it;
> - it does not occur while receiving huge files.
> - it does not occur when only a few packets are
>   transmitted (remote connection, ls, find)
> - it occurs only while transmiting huge files AND
>   trying to do someting else (open a new term,...)
> - I could transfer a huge file (700MB) several times
>   as i was at the console (and i could switch to another
> console to perform find, ls,... during the transfer).

Are you saying that PREEMPT and X are both needed to freeze the box ?

If so, could you try preempt + console + rsync (+ dd from disk) ?

> I managed the system so the sis190 had its own IRQ, but it
> made no difference.
> 
> As i suspected nvidia driver, i switched to nv driver : no result.

Please keep binary modules out of the loop until the things are stable.
I do not want to try and diagnose a bug in a system wherein such an amount
of unknown code was loaded (even if it was unloaded later).

> It seems to me that a task inside the sis190_tx_interrupt() is 
> not protected against preemption (and it is probably the same
> on a SMP not prempted).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick Jenkins | 1 Jul 2005 01:53
Picon
Picon

[PATCH] Multipath routing algorithm determination

Hi,

This patch assigns the multipath routing algorithm into the fib_info
struct's fib_mp_alg variable. Previously, the algorithm was always set to
IP_MP_ALG_NONE which was incorrect. This patch corrects the problem by
assigning the correct value when a fib_info is initialized.

This patch was tested against kernel 2.6.12.1 for all multipath routing
algorithms (none, round robin, interface round robin, random, weighted
random).

Please look this patch over and apply it to the kernel. I have been unable 
to contact the creators of the multipath algorithm feature so this is why 
I sent it to the lkml.

I am not a member of the list so please cc me in the reply.

Signed-off-by: Patrick Jenkins <patjenk <at> wam.umd.edu>

--- net/ipv4/fib_semantics.orig.c       2005-06-30 18:47:05.000000000 
-0400
+++ net/ipv4/fib_semantics.c    2005-06-30 18:55:08.000000000 -0400
 <at>  <at>  -9,6 +9,9  <at>  <at> 
   *
   * Authors:    Alexey Kuznetsov, <kuznet <at> ms2.inr.ac.ru>
   *
+ * Fixes:
+ *             Patrick Jenkins :       multipath routing algorithm wasnt 
being assigned correctly
+ *
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wakko Warner | 1 Jul 2005 02:25

Re: [OT] build just one driver

Jesper Juhl wrote:
> > Unfortunately, one cannot do make dir/module.ko... Would it be too 
> > difficult to add?
> 
> Hmm, I suspect people would find that useful. 
> I'm not making any promises, but I might take a look at adding that later, 
> on the other hand I don't have much time at the moment, so maybe I 
> won't...

How about a target that does only stage 2 module building?

--

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
Permalink | Reply | 0 comments |

Gmane