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.

Re: [Fastboot] Re: Re: tg3: issue for reboot/kexec

Greg KH <greg <at> kroah.com> writes:

> On Fri, Jun 24, 2005 at 05:46:52PM -0700, randy_dunlap wrote:
>> On Fri, 24 Jun 2005 17:02:17 -0700 Haren Myneni wrote:
>> 
>> | 
>> | Hello,
>> |     The kexec boot on power blade (JS20) is not successfull without 
>> | doing 'ifdown <ethernet device>'.  Based on my initial look in tg3 code, 
>> | the driver does not have shutdown nor reboot notifier code unlike in 
>> | other drivers. Hence, I added the the following patch (based on e1000) 
>> | and it is working. Is it OK to include this patch? If not, any help to 
>> | track down the issue would be appreciated.
>> | 
>> | My system is having the following cards:
>> | 0000:11:01.0 Ethernet controller: Broadcom Corporation NetXtreme 
>> | BCM5704S Gigabit Ethernet (rev 03)
>> | 0000:11:01.1 Ethernet controller: Broadcom Corporation NetXtreme 
>> | BCM5704S Gigabit Ethernet (rev 03)
>> | 
>> | lspci -n -s 0000:11:01
>> | 0000:11:01.0 Class 0200: 14e4:16a8 (rev 03)
>> | 0000:11:01.1 Class 0200: 14e4:16a8 (rev 03)
>> 
>> [adding fastboot & linux-pm mailing lists]
>> 
>> There was just a SCSI driver patch that tried to use a reboot
>> notifier on shutdown and the patch got this comment:
>> 
>> Subject: Re: [PATCH] 2.6 aacraid: shutdown notification

Re: [Fastboot] Re: Re: tg3: issue for reboot/kexec

On Thu, Jun 30, 2005 at 05:21:45PM -0600, Eric W. Biederman wrote:
> However I have gotten feedback a couple of times that
> driver writers tend to prefer using reboot notifiers.  In part
> because shutdown functions don't exist for non-pci devices.

That's a very lame excuse.  All busses should have shutdown functions.
And any device that is just bypassing all of the existing bus logic is
still tying into the driver core directly (which is a bad thing by
itself, but that's a different matter.)  And there's a shutdown method
there too.

So there is no excuse to not use it.  Please, if they complain, point
them to me :)

thanks,

greg k-h

On Thu, Jun 30, 2005 at 05:21:45PM -0600, Eric W. Biederman wrote:
> However I have gotten feedback a couple of times that
> driver writers tend to prefer using reboot notifiers.  In part
> because shutdown functions don't exist for non-pci devices.

That's a very lame excuse.  All busses should have shutdown functions.
And any device that is just bypassing all of the existing bus logic is
still tying into the driver core directly (which is a bad thing by
itself, but that's a different matter.)  And there's a shutdown method
there too.

はじめまして。

こんばんわ♪

はずかしくってちょっと書きづらいんだけど、
すごいＨ☆なサイトをがあるの知ってますか？

有名な人がいっぱいで隠し撮りやいろんな種類の動画が盛りだくさん♪
芸能人のもあるから驚きだよ！

とりあえずサンプル見てみよ☆
http://the-premium-movie.com

Re: [Fastboot] Re: Re: tg3: issue for reboot/kexec

Greg KH <greg <at> kroah.com> writes:

> On Thu, Jun 30, 2005 at 05:21:45PM -0600, Eric W. Biederman wrote:
>> However I have gotten feedback a couple of times that
>> driver writers tend to prefer using reboot notifiers.  In part
>> because shutdown functions don't exist for non-pci devices.
>
> That's a very lame excuse.  All busses should have shutdown functions.
> And any device that is just bypassing all of the existing bus logic is
> still tying into the driver core directly (which is a bad thing by
> itself, but that's a different matter.)  And there's a shutdown method
> there too.
>
> So there is no excuse to not use it.  Please, if they complain, point
> them to me :)

Ok.

Then there is still my complaint and device_shutdown doesn't get called
on module removal which means it really doesn't get implemented.  Perhaps
with kexec now being in the mainline kernel this will get better.

Currently I have the following patch outstanding against the e1000
driver because on reboot on some boxes it card revisions
it places the card into a sleep state the driver initialization 
routing cannot get the card out of.

And yes the e1000 is bad and is using a reboot_notifier.

Eric

Re: [PATCH] multipath routing algorithm, better patch

Patrick Jenkins wrote:
> Hi,
> 
> The last patch wont work, this should.
> 
> 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).

Multiple algorithms can be compiled in at once, so this patch is wrong.
mp_alg is supplied by userspace:

        if (rta->rta_mp_alg) {
                mp_alg = *rta->rta_mp_alg;

                if (mp_alg < IP_MP_ALG_NONE ||
                    mp_alg > IP_MP_ALG_MAX)
                        goto err_inval;
        }

If it isn't set correctly its an iproute problem. Did you actually
experience any problems?

Regards
Patrick

Re: [Fastboot] Re: Re: tg3: issue for reboot/kexec

Eric W. Biederman wrote:

>A couple stray bits of feedback.  Downing the interface is generally
>a user space requirement like unmounting filesystems.
>/sbin/kexec and /sbin/reboot both perform this operation so I don't
>see how this bug was hit.
>
>  
>
Thanks for your feedback. We are still working on kexec tools for PPC64. 
In the mean time, I was using a temporary tool which does not do ifdown. 
I was in the impression that the kexec boot will be successful since the 
normal kexec code path (kernel/sys.c) contains device_shutdown/reboot 
notifier. It turns out I am wrong.

Thanks
Haren

Eric W. Biederman wrote:

>A couple stray bits of feedback.  Downing the interface is generally
>a user space requirement like unmounting filesystems.
>/sbin/kexec and /sbin/reboot both perform this operation so I don't
>see how this bug was hit.
>
>  
>
Thanks for your feedback. We are still working on kexec tools for PPC64. 

Re: [Fastboot] Re: Re: tg3: issue for reboot/kexec

Haren Myneni <haren <at> us.ibm.com> writes:

> Eric W. Biederman wrote:
>
>>A couple stray bits of feedback.  Downing the interface is generally
>>a user space requirement like unmounting filesystems.
>>/sbin/kexec and /sbin/reboot both perform this operation so I don't
>>see how this bug was hit.
>>
>>
>>
> Thanks for your feedback. We are still working on kexec tools for PPC64. In the
> mean time, I was using a temporary tool which does not do ifdown. I was in the
> impression that the kexec boot will be successful since the normal kexec code
> path (kernel/sys.c) contains device_shutdown/reboot notifier. It turns out I am
> wrong.

Buggy drivers will do that to you as well.  But not doing a clean shutdown
(downing interfaces, and unmounting the filesystems) doesn't help things  :)

Eric

Haren Myneni <haren <at> us.ibm.com> writes:

> Eric W. Biederman wrote:
>
>>A couple stray bits of feedback.  Downing the interface is generally
>>a user space requirement like unmounting filesystems.
>>/sbin/kexec and /sbin/reboot both perform this operation so I don't

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

From: Andrew Morton <akpm <at> osdl.org>
Date: Thu, 30 Jun 2005 16:14:56 -0700

> Chuck Ebbert <76306.1226 <at> compuserve.com> wrote:
> >
> > 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.

Every network device must reliably set ->last_rx, there are parts
of the kernel which depend upon this attribute having an accurate
value.

The bonding driver is one example.  And whilst one can argue that
loopback is unlikely to be used as part of a bond, it's massively
better from a consistency perspective if this invariant can be
relied upon across all networking drivers.

In short, the NUMA scalability hacks to loopback have gotten out
of control, and we need to stop this madness somewhere.

general bonding question

To any of you that deal with the nic bonding driver.
Is there a special reason why the bond interface is not using
the slave device features, such as "scatter gather" or hardware checksum ?
I think of fixing the driver but i thought it would better to advise first.   

--

-- 
Raz
Long Live the Penguin