by Grant Coady

[permalink] [raw]

Subject: Re: 2.6.13-mm2

On Thu, 8 Sep 2005 05:30:42 -0700, Andrew Morton <[email protected]> wrote:

>
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm2/

Hi Andrew,

After this error:

CC drivers/parport/parport_pc.o
drivers/parport/parport_pc.c:2511: error: via_686a_data causes a section type conflict
drivers/parport/parport_pc.c:2520: error: via_8231_data causes a section type conflict
drivers/parport/parport_pc.c:2705: error: parport_pc_superio_info causes a section type conflict
drivers/parport/parport_pc.c:2782: error: cards causes a section type conflict
make[2]: *** [drivers/parport/parport_pc.o] Error 1
make[1]: *** [drivers/parport] Error 2
make: *** [drivers] Error 2

got this:

grant@sempro:/opt/linux/linux-2.6.13-mm2a$ make menuconfig
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/kxgettext.o
HOSTCC scripts/kconfig/mconf.o
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/mconf
HOSTCC scripts/lxdialog/checklist.o
HOSTCC scripts/lxdialog/inputbox.o
HOSTCC scripts/lxdialog/lxdialog.o
HOSTCC scripts/lxdialog/menubox.o
HOSTCC scripts/lxdialog/msgbox.o
HOSTCC scripts/lxdialog/textbox.o
HOSTCC scripts/lxdialog/util.o
HOSTCC scripts/lxdialog/yesno.o
HOSTLD scripts/lxdialog/lxdialog
scripts/kconfig/mconf arch/i386/Kconfig
Warning! Found recursive dependency: HOSTAP IEEE80211 NET_RADIO HOSTAP IEEE80211_CRYPT_WEP CRYPTO CRYPTO_ANUBIS
Warning! Found recursive dependency: HOSTAP IEEE80211 NET_RADIO HOSTAP IEEE80211_CRYPT_WEP CRYPTO CRYPTO_MD4
Warning! Found recursive dependency: HOSTAP IEEE80211 NET_RADIO HOSTAP IEEE80211_CRYPT_WEP CRYPTO CRYPTO_MD5
Warning! Found recursive dependency: HOSTAP IEEE80211 NET_RADIO HOSTAP IEEE80211_CRYPT_WEP CRYPTO CRYPTO_AES_X86_64
Warning! Found recursive dependency: NET_RADIO HOSTAP IEEE80211 NET_RADIO HERMES TMD_HERMES
Warning! Found recursive dependency: HOSTAP IEEE80211 NET_RADIO HOSTAP HOSTAP_PCI
Warning! Found recursive dependency: NET_RADIO HOSTAP IEEE80211 NET_RADIO WAVELAN
#
# using defaults found in .config
#
from this: http://bugsplatter.mine.nu/test/boxen/sempro/config-2.6.13-mm2a.gz
and: http://bugsplatter.mine.nu/test/boxen/sempro/config-2.6.13-mm2b.gz
when I tried again, slightly different config. I don't do wireless networking,
clueless ;-)

Grant.

2005-09-09 02:55:06

[NETFILTER]: Don't exclude local packets from MASQUERADING

Increases consistency in source-address selection.

Signed-off-by: Patrick McHardy <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

---
commit 9baa5c67ff4ce57b6b9f68c90714a1bb876fccd7
tree 27f2c48e12e1bb5e3e6d5f8320651c213892ed20
parent fb13ab2849074244a51ae5147483610529a29ced
author Patrick McHardy <[email protected]> Sun, 14 Aug 2005 17:32:50 -0700
committer David S. Miller <[email protected]> Mon, 29 Aug 2005 15:58:36 -0700

net/ipv4/netfilter/ipt_MASQUERADE.c | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/net/ipv4/netfilter/ipt_MASQUERADE.c b/net/ipv4/netfilter/ipt_MASQUERADE.c
--- a/net/ipv4/netfilter/ipt_MASQUERADE.c
+++ b/net/ipv4/netfilter/ipt_MASQUERADE.c
@@ -86,11 +86,6 @@ masquerade_target(struct sk_buff **pskb,

IP_NF_ASSERT(hooknum == NF_IP_POST_ROUTING);

- /* FIXME: For the moment, don't do local packets, breaks
- testsuite for 2.3.49 --RR */
- if ((*pskb)->sk)
- return NF_ACCEPT;
-
ct = ip_conntrack_get(*pskb, &ctinfo);
IP_NF_ASSERT(ct && (ctinfo == IP_CT_NEW || ctinfo == IP_CT_RELATED
|| ctinfo == IP_CT_RELATED + IP_CT_IS_REPLY));

Attachments:

x (1.19 kB)

2005-09-11 01:22:40

by J.A. Magallon

[permalink] [raw]

Subject: Re: 2.6.13-mm2

On 09.11, Patrick McHardy wrote:
> J.A. Magallon wrote:
> > And I also get this on syslog:
> >
> > Sep 11 02:56:58 werewolf kernel: MASQUERADE: eth0 ate my IP address
> > Sep 11 02:56:58 werewolf kernel: MASQUERADE: eth0 ate my IP address
>
> Thanks, I'm pretty sure its caused by this patch. The problem is that
> pump uses a regular UDP socket (some other dhcp clients use AF_PACKET
> sockets), and packet sent by it are also handled by iptables. The
> MASQUERADE rule can't find a local IP address and drops the packet.
> I'm not sure how to fix it yet, reverting the patch is not a good
> option.
>
>

> [NETFILTER]: Don't exclude local packets from MASQUERADING
>
> Increases consistency in source-address selection.
>
> Signed-off-by: Patrick McHardy <[email protected]>
> Signed-off-by: David S. Miller <[email protected]>
>
> ---
> commit 9baa5c67ff4ce57b6b9f68c90714a1bb876fccd7
> tree 27f2c48e12e1bb5e3e6d5f8320651c213892ed20
> parent fb13ab2849074244a51ae5147483610529a29ced
> author Patrick McHardy <[email protected]> Sun, 14 Aug 2005 17:32:50 -0700
> committer David S. Miller <[email protected]> Mon, 29 Aug 2005 15:58:36 -0700
>
> net/ipv4/netfilter/ipt_MASQUERADE.c | 5 -----
> 1 files changed, 0 insertions(+), 5 deletions(-)
>
> diff --git a/net/ipv4/netfilter/ipt_MASQUERADE.c b/net/ipv4/netfilter/ipt_MASQUERADE.c
> --- a/net/ipv4/netfilter/ipt_MASQUERADE.c
> +++ b/net/ipv4/netfilter/ipt_MASQUERADE.c
> @@ -86,11 +86,6 @@ masquerade_target(struct sk_buff **pskb,
>
> IP_NF_ASSERT(hooknum == NF_IP_POST_ROUTING);
>
> - /* FIXME: For the moment, don't do local packets, breaks
> - testsuite for 2.3.49 --RR */
> - if ((*pskb)->sk)
> - return NF_ACCEPT;
> -
> ct = ip_conntrack_get(*pskb, &ctinfo);
> IP_NF_ASSERT(ct && (ctinfo == IP_CT_NEW || ctinfo == IP_CT_RELATED
> || ctinfo == IP_CT_RELATED + IP_CT_IS_REPLY));
>

Thanks, reverting this made things work again.

Are you confident in fixing this shortly, or should I just drop pump ?

--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.13-jam3 (gcc 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0))

2005-09-11 01:25:18

by Patrick McHardy

[permalink] [raw]

Subject: Re: 2.6.13-mm2

J.A. Magallon wrote:
> On 09.11, Patrick McHardy wrote:
>
>>[NETFILTER]: Don't exclude local packets from MASQUERADING
>>
> Thanks, reverting this made things work again.
>
> Are you confident in fixing this shortly, or should I just drop pump ?

I should have a fix within the next couple of days.

2005-09-11 17:03:48

> Date: Fri, 30 Sep 2005 09:33:13 -0700 (PDT)
> From: Linus Torvalds <[email protected]>
>
> On Wed, 28 Sep 2005, David Brownell wrote:
> >
> > You could try adding
> >
> > ohci_writel(ohci, OHCI_INTR_MIE, &ohci->regs->intrdisable);
> >
> > near the end of ohci_pci_suspend().
>
> Btw, wouldn't this make more sense in ohci_hub_suspend()? That would pair
> up with the resume, and there seems to be nothing PCI-specific about this?
>
> There are other callers of suspend than just the PCI bus suspend.
>
> Just wondering..

Actually, no it wouldn't make sense.

Think of the OHCI driver as being in two parts: (a) downstream links,
the guts of OHCI which I'll summarize here as being the root hub;
and (b) the upstream link, a PCI or SOC bus. Both parts have their
own power management rules.

Now the OHCI controller itself supports four internal states, one of
which is called SUSPEND. It's the lowest power state that all OHCI
silicon supports. It's the state the controller enters whenever the
root hub suspends.

The OHCI driver keeps the controller in that OHCI_USB_SUSPEND state
whenever it can ... like when no devices are connected, or when all
connected devices have been suspended. At this very second, most
OHCIs running Linux are probably in this state.

And the way the controller leaves the SUSPEND state is to issue an IRQ
when someone connects a new USB device, or a suspended device (like a
USB keyboard or mouse) issues a wakeup signal.

You can see what that means. Disabling IRQs in ohci_hub_suspend()
would mean the controller couldn't wake up for new devices etc.
USB would just "not work".

It might not be appropriate to disable that in the PCI glue either;
I came across a comment from Benjamin Herrenschmidt a while back,
that some "legacy" PCI systems drive system wakeup through normal
IRQs rather than through PME#. That dovetails nicely with your
comments about disabling IRQs during suspend being ungood. :)

- Dave