Re: [PATCH 2/2] [TULIP] Check the return value from pci_set_mwi()
On Fri, Oct 06, 2006 at 03:59:57PM -0400, Jeff Garzik wrote: > The unmodified tulip driver checks both MWI and cacheline-size because > one of the clones (PNIC or PNIC2) will let you set the MWI bit, but > hardwires cacheline size to zero. Maybe the generic pci_set_mwi() can verify cacheline size is non-zero? I don't think each driver should need to enforce this. > If the arches do not behave consistently, we need to keep the check in > the tulip driver, to avoid incorrectly programming the csr0 MWI bit. Why not fix the arches to be consistent? There's alot more drivers than arches...and we have control of the arch specific PCI support. thanks, grant - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/02] net/ipv6: seperate sit driver to extra module
On Sat, 7 Oct 2006, Bill Fink wrote: > On Fri, 6 Oct 2006 17:15:56 +0200, Joerg Roedel wrote: > > > +config IPV6_SIT > > + tristate "IPv6: IPv6-in-IPv4 tunnel (SIT driver)" > > + depends on IPV6 > > + default y > > + ---help--- > > + Tunneling means encapsulating data of one protocol type within > > + another protocol and sending it over a channel that understands the > > + encapsulating protocol. This driver implements encapsulation of IPv6 > > + into IPv4 packets. This is useful if you want to connect two IPv6 > > + networks over an IPv4-only path. > > + > > + Saying M here will produce a module called sit.ko. If unsure, say N. > > >From a user perspective, I believe it should say "If unsure, say Y". > The unsure case for the unsure user should be the case that works for > the broadest possible usage spectrum, which would be the 'Y' case. > To put it another way, if you pick 'Y' and don't really need it, the > only downside is wasting some memory. But if you pick 'N' and actually > did need it, previously working IPv6 networking would no longer work. > I believe the default setting should match the unsure recommendation. Yes, the unsure value should match the default. People pick the default because they're unsure. -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/02] net/ipv6: seperate sit driver to extra module
On Fri, 6 Oct 2006 17:15:56 +0200, Joerg Roedel wrote: > +config IPV6_SIT > + tristate "IPv6: IPv6-in-IPv4 tunnel (SIT driver)" > + depends on IPV6 > + default y > + ---help--- > + Tunneling means encapsulating data of one protocol type within > + another protocol and sending it over a channel that understands the > + encapsulating protocol. This driver implements encapsulation of IPv6 > + into IPv4 packets. This is useful if you want to connect two IPv6 > + networks over an IPv4-only path. > + > + Saying M here will produce a module called sit.ko. If unsure, say N. >From a user perspective, I believe it should say "If unsure, say Y". The unsure case for the unsure user should be the case that works for the broadest possible usage spectrum, which would be the 'Y' case. To put it another way, if you pick 'Y' and don't really need it, the only downside is wasting some memory. But if you pick 'N' and actually did need it, previously working IPv6 networking would no longer work. I believe the default setting should match the unsure recommendation. -Bill - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.19-rc1 regression: airo suspend fails
Adrian Bunk <[EMAIL PROTECTED]> writes: > On Thu, Oct 05, 2006 at 09:31:16PM -0700, Alex Romosan wrote: >> Linus Torvalds <[EMAIL PROTECTED]> writes: >> >> > so please give it a good testing, and let's see if there are any >> > regressions. >> >> it breaks suspend when the airo module is loaded: >> >> kernel: Stopping tasks: >> = >> kernel: stopping tasks timed out after 20 seconds (1 tasks remaining): >> kernel: eth1 >> kernel: Restarting tasks...<6> Strange, eth1 not stopped >> >> if i remove the airo module suspend works normally (this is on a >> thinkpad t40). > > Thanks for your report. > > Let's try to figure out what broke it. > > As a first step, please replace drivers/net/wireless/airo.c with the > version in 2.6.18 and check whether this fixes the issue (you can ignore > the deprecated warning during compilation). i replaced airo.c with the 2.6.18 version. the good news is i can suspend to memory with it. the bad news is dhcp never got an ip address (so i don't think the 2.6.18 driver really works with the 2.6.19-rc1 infrastructure). any patches i could try? thanks. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 7278] New: forcedeth slowed down by traffic shaping
On Fri, 6 Oct 2006 17:18:13 -0700 [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=7278 > >Summary: forcedeth slowed down by traffic shaping > Kernel Version: 2.6.16 > Status: NEW > Severity: normal > Owner: [EMAIL PROTECTED] > Submitter: [EMAIL PROTECTED] > > > When assigninig a simple Tocket Bucket Filter (TBF) classless trafic shaping > policy to the eth0 device (provided by forcedeth), the device's upstream speed > drops to ~12kbyte/s, regardless of the traffic limit I set in the shaping > rule. > In fact, the traffic limit values could be larger than the connection's > throughput and it'll still limit to mere 12kbyte/s. Once I revert the rule to > pfifo_fast, the rate resumes to the connection's real one (64kbyte/s). > > If I set the TBF lower than 96kbit on eth0, it indeed applies; in other > words, I > can make the connection slower than 12kbyte/s but not faster. > > If I assign the same rule to ppp0, it works just as intended, for rules higher > than 12kbyte/s, leading me to believe forcedeth has something to do with it. > > (Is there any module parameter I can try tweaking?) > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-or-PATCH] IRQ handler cleanups
Acked-by: Alan Cox <[EMAIL PROTECTED]> All looks ok, the bigger change in riscom8 is verifiably safe too - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [TULIP] Fix section mismatch in de2104x.c
Matthew Wilcox wrote: On Fri, Oct 06, 2006 at 03:44:30PM -0400, Jeff Garzik wrote: Matthew Wilcox wrote: On Fri, Oct 06, 2006 at 03:18:33PM -0400, Jeff Garzik wrote: This device will never ever meet a platform where it can be hotplugged. According to a FreeBSD list from 1995, you could get these chips on a PCI card from several different vendors. Yes, they are ancient 32-bit PCI cards, which will never make an appearance on a PCI hotplug platform. So, it's wasteful to support hotplug in code that will never be hotplugged (as I've said for years). Sorry, you're saying that anyone who has found one of these cards and wants to plug them into a hotplug slot in their shiny new server is just SOL? That makes no sense, Jeff. We've fixed *so* many old drivers to confirm to these rules, why's this one so special? I'd understand if it were only found on motherboards, but it can be found on cards. Plus it silences a warning. Isn't that enough reason of its own? Early tulips were electrically "special", so I am highly doubtful it would work in any case. But overall it doesn't make sense to me to force code to exist, that we know will likely never ever be needed. Whatever. This patch comes up every year or two, so I suppose I should just quit fighting and eat the needless code size increase, to silence the human warnings :) Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-mm2 boot failure on x86-64
On Fri, Oct 06, 2006 at 01:03:50PM -0500, Steve Fox wrote:
> On Fri, 2006-10-06 at 18:11 +0100, Mel Gorman wrote:
> > On (06/10/06 11:36), Vivek Goyal didst pronounce:
> > > Where is bss placed in physical memory? I guess bss_start and bss_stop
> > > from System.map will tell us. That will confirm that above memset step is
> > > stomping over bss. Then we have to just find that somewhere probably
> > > we allocated wrong physical memory area for bootmem allocator map.
> > >
> >
> > BSS is at 0x643000 -> 0x777BC4
> > init_bootmem wipes from 0x777000 -> 0x8F7000
> >
> > So the BSS bytes from 0x777000 ->0x777BC4 (which looks very suspiciously
> > pile a page alignment of addr & PAGE_MASK) gets set to 0xFF. One possible
> > fix is below. It adds a check in bad_addr() to see if the BSS section is
> > about to be used for bootmap. It Seems To Work For Me (tm) and illustrates
> > the source of the problem even if it's not the 100% correct fix.
>
> I was able to boot the machine with Mel's patch applied on top of
> -git22.
Please have a look at the attached patch. Does it make some sense.
Steve, can you please give this patch a try if it fixes the problem?
Thanks
Vivek
o Currently some code pieces assume that address returned by find_e820_area()
are page aligned. But looks like find_e820_area() had no such intention
and hence one might end up stomping over some of the data. One such
case is bootmem allocator initialization code stomped over bss.
o This patch modified find_e820_area() to return page aligned address. This
might be little wasteful of memory but at the same time probably it is
easier to handle page aligned memory.
Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/e820.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff -puN
arch/x86_64/kernel/e820.c~x86_64-return-page-aligned-phy-addr-from-find-e820-area
arch/x86_64/kernel/e820.c
---
linux-2.6.19-rc1-1M/arch/x86_64/kernel/e820.c~x86_64-return-page-aligned-phy-addr-from-find-e820-area
2006-10-06 15:28:13.0 -0400
+++ linux-2.6.19-rc1-1M-root/arch/x86_64/kernel/e820.c 2006-10-06
15:44:45.0 -0400
@@ -54,13 +54,13 @@ static inline int bad_addr(unsigned long
/* various gunk below that needed for SMP startup */
if (addr < 0x8000) {
- *addrp = 0x8000;
+ *addrp = PAGE_ALIGN(0x8000);
return 1;
}
/* direct mapping tables of the kernel */
if (last >= table_start<= INITRD_START &&
addr < INITRD_START+INITRD_SIZE) {
- *addrp = INITRD_START + INITRD_SIZE;
+ *addrp = PAGE_ALIGN(INITRD_START + INITRD_SIZE);
return 1;
}
#endif
/* kernel code */
- if (last >= __pa_symbol(&_text) && last < __pa_symbol(&_end)) {
- *addrp = __pa_symbol(&_end);
+ if (last >= __pa_symbol(&_text) && addr < __pa_symbol(&_end)) {
+ *addrp = PAGE_ALIGN(__pa_symbol(&_end));
return 1;
}
if (last >= ebda_addr && addr < ebda_addr + ebda_size) {
- *addrp = ebda_addr + ebda_size;
+ *addrp = PAGE_ALIGN(ebda_addr + ebda_size);
return 1;
}
@@ -152,7 +152,7 @@ unsigned long __init find_e820_area(unsi
continue;
while (bad_addr(&addr, size) && addr+size <= ei->addr+ei->size)
;
- last = addr + size;
+ last = PAGE_ALIGN(addr) + size;
if (last > ei->addr + ei->size)
continue;
if (last > end)
_
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [TULIP] Check the return value from pci_set_mwi()
Matthew Wilcox wrote:
On Fri, Oct 06, 2006 at 03:15:15PM -0400, Jeff Garzik wrote:
Matthew Wilcox wrote:
Also, pci_set_mwi() will fail if the cache line
size is 0, so we don't need to check that ourselves any more.
NAK, not true on all arches. sparc64 at least presumes that the
firmware DTRT with cacheline size, which hurts us now given this tulip patch
How does it hurt us?
int pcibios_prep_mwi(struct pci_dev *dev)
{
/* We set correct PCI_CACHE_LINE_SIZE register values for every
* device probed on this platform. So there is nothing to check
* and this always succeeds.
*/
return 0;
}
If Dave's wrong about that, it hurts him, not us ;-)
It's still not necessary for the Tulip driver to check.
The unmodified tulip driver checks both MWI and cacheline-size because
one of the clones (PNIC or PNIC2) will let you set the MWI bit, but
hardwires cacheline size to zero.
If the arches do not behave consistently, we need to keep the check in
the tulip driver, to avoid incorrectly programming the csr0 MWI bit.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [TULIP] Fix section mismatch in de2104x.c
On Fri, Oct 06, 2006 at 03:44:30PM -0400, Jeff Garzik wrote: > Matthew Wilcox wrote: > >On Fri, Oct 06, 2006 at 03:18:33PM -0400, Jeff Garzik wrote: > >>This device will never ever meet a platform where it can be hotplugged. > > > >According to a FreeBSD list from 1995, you could get these chips on a PCI > >card from several different vendors. > > > > Yes, they are ancient 32-bit PCI cards, which will never make an > appearance on a PCI hotplug platform. So, it's wasteful to support > hotplug in code that will never be hotplugged (as I've said for years). Sorry, you're saying that anyone who has found one of these cards and wants to plug them into a hotplug slot in their shiny new server is just SOL? That makes no sense, Jeff. We've fixed *so* many old drivers to confirm to these rules, why's this one so special? I'd understand if it were only found on motherboards, but it can be found on cards. Plus it silences a warning. Isn't that enough reason of its own? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [TULIP] Fix section mismatch in de2104x.c
Matthew Wilcox wrote: On Fri, Oct 06, 2006 at 03:18:33PM -0400, Jeff Garzik wrote: Stephen Hemminger wrote: On Fri, 06 Oct 2006 12:12:34 -0600 Matthew Wilcox <[EMAIL PROTECTED]> wrote: From: Helge Deller <[EMAIL PROTECTED]> WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to .init.text:de_init_one from .data.rel.local after 'de_driver' (at offset 0x20) WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to .exit.text:de_remove_one from .data.rel.local after 'de_driver' (at offset 0x28) This is caused because with PCI hotplug the device might be probed after the init section has been removed. Ditto for remove. This device will never ever meet a platform where it can be hotplugged. According to a FreeBSD list from 1995, you could get these chips on a PCI card from several different vendors. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=37148+0+archive/1995/freebsd-hardware/19951001.freebsd-hardware Yes, they are ancient 32-bit PCI cards, which will never make an appearance on a PCI hotplug platform. So, it's wasteful to support hotplug in code that will never be hotplugged (as I've said for years). Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[git-or-PATCH] IRQ handler cleanups
This is the pure-cleanup stuff I pulled out of this morning's remove-irq-arg work. No behavior changes, just killing dead code, killing unused 'irq' arguments in sub-functions, and killing void* casts. Please pull from 'irqclean-submit1' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git irqclean-submit1 to receive the following updates: arch/i386/kernel/time.c|4 ++-- drivers/atm/ambassador.c |7 +-- drivers/atm/horizon.c |9 - drivers/atm/lanai.c|4 +--- drivers/block/DAC960.c | 14 +++--- drivers/cdrom/mcdx.c |4 drivers/char/rio/func.h|2 +- drivers/char/rio/rio_linux.c |4 ++-- drivers/char/rio/riointr.c |2 +- drivers/char/riscom8.c |7 +++ drivers/char/specialix.c |2 +- drivers/isdn/act2000/act2000_isa.c | 22 ++ drivers/media/video/zoran_device.c |2 +- drivers/net/3c509.c|7 +-- drivers/net/3c523.c|7 ++- drivers/net/3c527.c|5 - drivers/net/8390.c |8 +--- drivers/net/atp.c |6 +- drivers/net/de600.c|6 -- drivers/net/declance.c |4 ++-- drivers/net/dgrs.c |4 ++-- drivers/net/eepro.c| 22 +- drivers/net/eexpress.c |7 --- drivers/net/irda/ali-ircc.c| 10 ++ drivers/net/irda/donauboe.c| 11 +-- drivers/net/irda/irport.c |8 ++-- drivers/net/irda/irport.h |2 +- drivers/net/irda/nsc-ircc.c|9 ++--- drivers/net/irda/w83977af_ir.c |9 ++--- drivers/net/lance.c|5 - drivers/net/pcmcia/axnet_cs.c |8 +--- drivers/net/pcnet32.c |7 --- drivers/net/plip.c |5 - drivers/net/saa9730.c |2 +- drivers/net/sb1000.c |8 +--- drivers/net/skfp/skfddi.c |7 +-- drivers/net/sonic.c|7 +-- drivers/net/sunhme.c |4 ++-- drivers/net/sunlance.c |2 +- drivers/net/sunqe.c|2 +- drivers/net/tokenring/smctr.c |7 --- drivers/net/tokenring/tms380tr.c |5 - drivers/net/tulip/de4x5.c |6 +- drivers/net/wan/cycx_main.c|4 ++-- drivers/net/wan/sdla.c |8 +--- drivers/net/wireless/orinoco.c |2 +- drivers/net/wireless/wavelan_cs.c | 11 +-- drivers/net/wireless/wl3501_cs.c | 15 --- drivers/net/yellowfin.c|7 --- drivers/net/znet.c |5 - drivers/pcmcia/at91_cf.c |2 +- drivers/pcmcia/hd64465_ss.c|7 +++ drivers/scsi/NCR53c406a.c |8 drivers/scsi/aha152x.c |7 +-- drivers/scsi/aic7xxx_old.c | 12 ++-- drivers/scsi/dc395x.c |2 +- drivers/scsi/qlogicfas408.c|6 +++--- drivers/scsi/tmscsim.c |8 drivers/scsi/ultrastor.c |8 drivers/serial/68360serial.c |2 +- drivers/serial/jsm/jsm_neo.c |2 +- drivers/serial/mpc52xx_uart.c | 10 +- drivers/serial/netx-serial.c |2 +- drivers/serial/pxa.c |2 +- drivers/sn/ioc3.c |2 +- drivers/spi/pxa2xx_spi.c |2 +- sound/isa/gus/gusmax.c |2 +- sound/isa/gus/interwave.c |2 +- sound/oss/es1371.c |2 +- sound/oss/hal2.c |2 +- sound/oss/i810_audio.c |2 +- sound/oss/mpu401.c |2 +- sound/oss/vwsnd.c |2 +- sound/pci/korg1212/korg1212.c |4 74 files changed, 106 insertions(+), 329 deletions(-) Jeff Garzik: arch/i386/kernel/time: don't shadow 'irq' function arg drivers/net: eliminate irq handler impossible checks, needless casts Various drivers' irq handlers: kill dead code, needless casts drivers/net/eepro: kill dead code drivers/isdn/act2000: kill irq2card_map diff --git a/arch/i386/kernel/time.c b/arch/i386/kernel/time.c index 3f221f5..78af572 100644 --- a/arch/i386/kernel/time.c +++ b/arch/i386/kernel/time.c @@ -201,8 +201,8 @@ #endif high bit of the PPI port B (0x61). Note that some PS/2s, notably the 55SX, work fine if this is removed. */ - irq = inb_p( 0x61 );/* read the current state */ - outb_p( irq|0x80, 0x61 ); /* reset the IRQ */ + u8 irq_v = inb_p( 0x61 ); /* read the current state */ + outb_p( irq_v|0x80, 0x61
Re: [PATCH] [TULIP] Fix section mismatch in de2104x.c
On Fri, Oct 06, 2006 at 03:18:33PM -0400, Jeff Garzik wrote: > Stephen Hemminger wrote: > >On Fri, 06 Oct 2006 12:12:34 -0600 > >Matthew Wilcox <[EMAIL PROTECTED]> wrote: > > > >>From: Helge Deller <[EMAIL PROTECTED]> > >> > >>WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to > >>.init.text:de_init_one from .data.rel.local after 'de_driver' (at offset > >>0x20) > >>WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to > >>.exit.text:de_remove_one from .data.rel.local after 'de_driver' (at > >>offset 0x28) > > > >This is caused because with PCI hotplug the device might be probed after > >the init section > >has been removed. Ditto for remove. > > This device will never ever meet a platform where it can be hotplugged. According to a FreeBSD list from 1995, you could get these chips on a PCI card from several different vendors. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=37148+0+archive/1995/freebsd-hardware/19951001.freebsd-hardware - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: From: Matthew Wilcox <[EMAIL PROTECTED]>
On Fri, Oct 06, 2006 at 01:01:34PM -0600, Matthew Wilcox wrote: Sorry about these. Stupid git-send-email requires a line of garbage before the headers. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [TULIP] Check the return value from pci_set_mwi()
On Fri, Oct 06, 2006 at 03:15:15PM -0400, Jeff Garzik wrote:
> Matthew Wilcox wrote:
> >Also, pci_set_mwi() will fail if the cache line
> >size is 0, so we don't need to check that ourselves any more.
>
> NAK, not true on all arches. sparc64 at least presumes that the
> firmware DTRT with cacheline size, which hurts us now given this tulip patch
How does it hurt us?
int pcibios_prep_mwi(struct pci_dev *dev)
{
/* We set correct PCI_CACHE_LINE_SIZE register values for every
* device probed on this platform. So there is nothing to check
* and this always succeeds.
*/
return 0;
}
If Dave's wrong about that, it hurts him, not us ;-)
It's still not necessary for the Tulip driver to check.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
More info on section mismatches (was Re: [PATCH] [TULIP] Fix section mismatch in de2104x.c)
On Fri, Oct 06, 2006 at 02:39:41PM -0400, Jeff Garzik wrote: > Matthew Wilcox wrote: > >From: Helge Deller <[EMAIL PROTECTED]> > > > >WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to > >.init.text:de_init_one from .data.rel.local after 'de_driver' (at offset > >0x20) > >WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to > >.exit.text:de_remove_one from .data.rel.local after 'de_driver' (at offset > >0x28) > > I'm a bit blind, so help me out here... what precisely is mismatched? > > AFAICS everything is properly marked __init or __exit. (Cc'd Richard Henderson as resident gcc guru.) We're discussing a way to get more information out of section mismatch reports so that the causes of section mismatches are a little more obvious. I'd like to see something like: foo() is marked __init at line 34 bar() calls foo() at line 57 Arjan points out that optimization may make this difficult; I'm happy with a separate script running at a lower level of optimization that you can run by hand when one of these warnings shows up. Ideas? -VAL - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [TULIP] Fix section mismatch in de2104x.c
Stephen Hemminger wrote: On Fri, 06 Oct 2006 12:12:34 -0600 Matthew Wilcox <[EMAIL PROTECTED]> wrote: From: Helge Deller <[EMAIL PROTECTED]> WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to .init.text:de_init_one from .data.rel.local after 'de_driver' (at offset 0x20) WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to .exit.text:de_remove_one from .data.rel.local after 'de_driver' (at offset 0x28) This is caused because with PCI hotplug the device might be probed after the init section has been removed. Ditto for remove. This device will never ever meet a platform where it can be hotplugged. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [PCI] Check that MWI bit really did get set
Matthew Wilcox wrote: Since some devices may not implement the MWI bit, we should check that the write did set it and return an error if it didn't. Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]> ACK, though (as it seems you are doing) you should audit pci_set_mwi() users to make sure behavior matches up with this implementation Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [TULIP] Check the return value from pci_set_mwi()
Matthew Wilcox wrote: Also, pci_set_mwi() will fail if the cache line size is 0, so we don't need to check that ourselves any more. NAK, not true on all arches. sparc64 at least presumes that the firmware DTRT with cacheline size, which hurts us now given this tulip patch Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [TULIP] Check the return value from pci_set_mwi()
We used to check whether pci_set_mwi() had succeeded by testing the
hardware MWI bit. Now we need only check the return value (and failing
to do so is a warning). Also, pci_set_mwi() will fail if the cache line
size is 0, so we don't need to check that ourselves any more.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
index d11d28c..64d999b 100644
--- a/drivers/net/tulip/tulip_core.c
+++ b/drivers/net/tulip/tulip_core.c
@@ -1135,7 +1135,6 @@ static void __devinit tulip_mwi_config (
{
struct tulip_private *tp = netdev_priv(dev);
u8 cache;
- u16 pci_command;
u32 csr0;
if (tulip_debug > 3)
@@ -1153,21 +1152,15 @@ static void __devinit tulip_mwi_config (
/* set or disable MWI in the standard PCI command bit.
* Check for the case where mwi is desired but not available
*/
- if (csr0 & MWI) pci_set_mwi(pdev);
- elsepci_clear_mwi(pdev);
-
- /* read result from hardware (in case bit refused to enable) */
- pci_read_config_word(pdev, PCI_COMMAND, &pci_command);
- if ((csr0 & MWI) && (!(pci_command & PCI_COMMAND_INVALIDATE)))
- csr0 &= ~MWI;
-
- /* if cache line size hardwired to zero, no MWI */
- pci_read_config_byte(pdev, PCI_CACHE_LINE_SIZE, &cache);
- if ((csr0 & MWI) && (cache == 0)) {
- csr0 &= ~MWI;
+ if (csr0 & MWI) {
+ if (pci_set_mwi(pdev))
+ csr0 &= ~MWI;
+ } else {
pci_clear_mwi(pdev);
}
+ pci_read_config_byte(pdev, PCI_CACHE_LINE_SIZE, &cache);
+
/* assign per-cacheline-size cache alignment and
* burst length values
*/
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [TULIP] Fix section mismatch in de2104x.c
On Fri, 06 Oct 2006 12:12:34 -0600 Matthew Wilcox <[EMAIL PROTECTED]> wrote: > From: Helge Deller <[EMAIL PROTECTED]> > > WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to > .init.text:de_init_one from .data.rel.local after 'de_driver' (at offset 0x20) > WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to > .exit.text:de_remove_one from .data.rel.local after 'de_driver' (at offset > 0x28) This is caused because with PCI hotplug the device might be probed after the init section has been removed. Ditto for remove. The fix looks correct. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Matthew Wilcox <[EMAIL PROTECTED]>
We used to check whether pci_set_mwi() had succeeded by testing the
hardware MWI bit. Now we need only check the return value (and failing
to do so is a warning). Also, pci_set_mwi() will fail if the cache line
size is 0, so we don't need to check that ourselves any more.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
index d11d28c..64d999b 100644
--- a/drivers/net/tulip/tulip_core.c
+++ b/drivers/net/tulip/tulip_core.c
@@ -1135,7 +1135,6 @@ static void __devinit tulip_mwi_config (
{
struct tulip_private *tp = netdev_priv(dev);
u8 cache;
- u16 pci_command;
u32 csr0;
if (tulip_debug > 3)
@@ -1153,21 +1152,15 @@ static void __devinit tulip_mwi_config (
/* set or disable MWI in the standard PCI command bit.
* Check for the case where mwi is desired but not available
*/
- if (csr0 & MWI) pci_set_mwi(pdev);
- elsepci_clear_mwi(pdev);
-
- /* read result from hardware (in case bit refused to enable) */
- pci_read_config_word(pdev, PCI_COMMAND, &pci_command);
- if ((csr0 & MWI) && (!(pci_command & PCI_COMMAND_INVALIDATE)))
- csr0 &= ~MWI;
-
- /* if cache line size hardwired to zero, no MWI */
- pci_read_config_byte(pdev, PCI_CACHE_LINE_SIZE, &cache);
- if ((csr0 & MWI) && (cache == 0)) {
- csr0 &= ~MWI;
+ if (csr0 & MWI) {
+ if (pci_set_mwi(pdev))
+ csr0 &= ~MWI;
+ } else {
pci_clear_mwi(pdev);
}
+ pci_read_config_byte(pdev, PCI_CACHE_LINE_SIZE, &cache);
+
/* assign per-cacheline-size cache alignment and
* burst length values
*/
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [PCI] Check that MWI bit really did get set
Since some devices may not implement the MWI bit, we should check that
the write did set it and return an error if it didn't.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index a544997..3d041f4 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -900,13 +900,17 @@ #endif
return rc;
pci_read_config_word(dev, PCI_COMMAND, &cmd);
- if (! (cmd & PCI_COMMAND_INVALIDATE)) {
- pr_debug("PCI: Enabling Mem-Wr-Inval for device %s\n",
pci_name(dev));
- cmd |= PCI_COMMAND_INVALIDATE;
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
-
- return 0;
+ if (cmd & PCI_COMMAND_INVALIDATE)
+ return 0;
+
+ pr_debug("PCI: Enabling Mem-Wr-Inval for device %s\n", pci_name(dev));
+ cmd |= PCI_COMMAND_INVALIDATE;
+ pci_write_config_word(dev, PCI_COMMAND, cmd);
+
+ /* read result from hardware (in case bit refused to enable) */
+ pci_read_config_word(dev, PCI_COMMAND, &cmd);
+
+ return (cmd & PCI_COMMAND_INVALIDATE) ? 0 : -EINVAL;
}
/**
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Matthew Wilcox <[EMAIL PROTECTED]>
Since some devices may not implement the MWI bit, we should check that
the write did set it and return an error if it didn't.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index a544997..3d041f4 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -900,13 +900,17 @@ #endif
return rc;
pci_read_config_word(dev, PCI_COMMAND, &cmd);
- if (! (cmd & PCI_COMMAND_INVALIDATE)) {
- pr_debug("PCI: Enabling Mem-Wr-Inval for device %s\n",
pci_name(dev));
- cmd |= PCI_COMMAND_INVALIDATE;
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
-
- return 0;
+ if (cmd & PCI_COMMAND_INVALIDATE)
+ return 0;
+
+ pr_debug("PCI: Enabling Mem-Wr-Inval for device %s\n", pci_name(dev));
+ cmd |= PCI_COMMAND_INVALIDATE;
+ pci_write_config_word(dev, PCI_COMMAND, cmd);
+
+ /* read result from hardware (in case bit refused to enable) */
+ pci_read_config_word(dev, PCI_COMMAND, &cmd);
+
+ return (cmd & PCI_COMMAND_INVALIDATE) ? 0 : -EINVAL;
}
/**
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [TULIP] Fix section mismatch in de2104x.c
Matthew Wilcox wrote: On Fri, Oct 06, 2006 at 02:39:41PM -0400, Jeff Garzik wrote: I'm a bit blind, so help me out here... what precisely is mismatched? AFAICS everything is properly marked __init or __exit. Wasn't my patch, but the markings are now consistent with tulip_core at least. That's a totally separate driver :) These section mismatch warnings occasionally stump me, and this is one of them. I don't want to ACK it until I know _why_ it is needed... Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.19-rc1 regression: airo suspend fails
On Thu, Oct 05, 2006 at 09:31:16PM -0700, Alex Romosan wrote: > Linus Torvalds <[EMAIL PROTECTED]> writes: > > > so please give it a good testing, and let's see if there are any > > regressions. > > it breaks suspend when the airo module is loaded: > > kernel: Stopping tasks: > = > kernel: stopping tasks timed out after 20 seconds (1 tasks remaining): > kernel: eth1 > kernel: Restarting tasks...<6> Strange, eth1 not stopped > > if i remove the airo module suspend works normally (this is on a > thinkpad t40). Thanks for your report. Let's try to figure out what broke it. As a first step, please replace drivers/net/wireless/airo.c with the version in 2.6.18 and check whether this fixes the issue (you can ignore the deprecated warning during compilation). > --alex-- cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [TULIP] Fix section mismatch in de2104x.c
On Fri, Oct 06, 2006 at 02:39:41PM -0400, Jeff Garzik wrote: > I'm a bit blind, so help me out here... what precisely is mismatched? > > AFAICS everything is properly marked __init or __exit. Wasn't my patch, but the markings are now consistent with tulip_core at least. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [TULIP] Fix section mismatch in de2104x.c
Matthew Wilcox wrote: From: Helge Deller <[EMAIL PROTECTED]> WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to .init.text:de_init_one from .data.rel.local after 'de_driver' (at offset 0x20) WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to .exit.text:de_remove_one from .data.rel.local after 'de_driver' (at offset 0x28) I'm a bit blind, so help me out here... what precisely is mismatched? AFAICS everything is properly marked __init or __exit. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [TULIP] Fix section mismatch in de2104x.c
From: Helge Deller <[EMAIL PROTECTED]>
WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to
.init.text:de_init_one from .data.rel.local after 'de_driver' (at offset 0x20)
WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to
.exit.text:de_remove_one from .data.rel.local after 'de_driver' (at offset 0x28)
Signed-off-by: Helge Deller <[EMAIL PROTECTED]>
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
drivers/net/tulip/de2104x.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tulip/de2104x.c b/drivers/net/tulip/de2104x.c
index 2cfd963..f6b3a94 100644
--- a/drivers/net/tulip/de2104x.c
+++ b/drivers/net/tulip/de2104x.c
@@ -1730,7 +1730,7 @@ static void __init de21040_get_media_inf
}
/* Note: this routine returns extra data bits for size detection. */
-static unsigned __init tulip_read_eeprom(void __iomem *regs, int location, int
addr_len)
+static unsigned __devinit tulip_read_eeprom(void __iomem *regs, int location,
int addr_len)
{
int i;
unsigned retval = 0;
@@ -1926,7 +1926,7 @@ bad_srom:
goto fill_defaults;
}
-static int __init de_init_one (struct pci_dev *pdev,
+static int __devinit de_init_one (struct pci_dev *pdev,
const struct pci_device_id *ent)
{
struct net_device *dev;
@@ -2082,7 +2082,7 @@ err_out_free:
return rc;
}
-static void __exit de_remove_one (struct pci_dev *pdev)
+static void __devexit de_remove_one (struct pci_dev *pdev)
{
struct net_device *dev = pci_get_drvdata(pdev);
struct de_private *de = dev->priv;
@@ -2164,7 +2164,7 @@ static struct pci_driver de_driver = {
.name = DRV_NAME,
.id_table = de_pci_tbl,
.probe = de_init_one,
- .remove = __exit_p(de_remove_one),
+ .remove = __devexit_p(de_remove_one),
#ifdef CONFIG_PM
.suspend= de_suspend,
.resume = de_resume,
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-mm2 boot failure on x86-64
On Fri, 2006-10-06 at 18:11 +0100, Mel Gorman wrote: > On (06/10/06 11:36), Vivek Goyal didst pronounce: > > Where is bss placed in physical memory? I guess bss_start and bss_stop > > from System.map will tell us. That will confirm that above memset step is > > stomping over bss. Then we have to just find that somewhere probably > > we allocated wrong physical memory area for bootmem allocator map. > > > > BSS is at 0x643000 -> 0x777BC4 > init_bootmem wipes from 0x777000 -> 0x8F7000 > > So the BSS bytes from 0x777000 ->0x777BC4 (which looks very suspiciously > pile a page alignment of addr & PAGE_MASK) gets set to 0xFF. One possible > fix is below. It adds a check in bad_addr() to see if the BSS section is > about to be used for bootmap. It Seems To Work For Me (tm) and illustrates > the source of the problem even if it's not the 100% correct fix. I was able to boot the machine with Mel's patch applied on top of -git22. -- Steve Fox IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-mm2 boot failure on x86-64
On Fri, Oct 06, 2006 at 06:11:05PM +0100, Mel Gorman wrote: > On (06/10/06 11:36), Vivek Goyal didst pronounce: > > On Fri, Oct 06, 2006 at 03:33:12PM +0100, Mel Gorman wrote: > > > > Linux version 2.6.18-git22 ([EMAIL PROTECTED]) (gcc version 4.1.0 (SUSE > > > > Linux)) #2 SMP Thu Oct 5 19:05:36 PDT 2006 > > > > Command line: root=/dev/sda1 vga=791 > > > > ip=9.47.67.239:9.47.67.50:9.47.67.1:255.255.255.0 resume=/dev/sdb1 > > > > showopts earlyprintk=serial,ttyS0,57600 console=tty0 > > > > console=ttyS0,57600 autobench_args: root=/dev/sda1 ABAT:1160100417 > > > > BIOS-provided physical RAM map: > > > > BIOS-e820: - 0009ac00 (usable) > > > > BIOS-e820: 0009ac00 - 000a (reserved) > > > > BIOS-e820: 000e - 0010 (reserved) > > > > BIOS-e820: 0010 - bff764c0 (usable) > > > > BIOS-e820: bff764c0 - bff98880 (ACPI data) > > > > BIOS-e820: bff98880 - c000 (reserved) > > > > BIOS-e820: fec0 - 0001 (reserved) > > > > BIOS-e820: 0001 - 000c (usable) > > > > > > I continued what Steve was doing this morning to see could this be > > > pinned down. After placing 'CHECK;' in a few places as suggested by > > > Andi's check, the problem code was identified as that following in > > > mm/bootmem.c#init_bootmem_core() > > > > > > mapsize = get_mapsize(bdata); > > > memset(bdata->node_bootmem_map, 0xff, mapsize); > > > > > > That explains the value in the array at least. A few more printfs around > > > this point printed out the following in the boot log > > > > > > init_bootmem_core(0, 1909, 0, 12582912) > > > init_bootmem_core: Calling memset(0x81775000, 1572864) > > > AAGH: afinfo corrupted at mm/bootmem.c:121 > > > > > > where; > > > > > > 1909 == mapstart > > > 0 == start > > > 12582912 == end > > > 1572864 == mapsize > > > > > > mapstart, start and end being the parameters being passed to > > > init_bootmem_core(). This means we are calling memset for the physical > > > range 0x775000 -> 0x8F5000 which is in a usable range according to the > > > BIOS-e820 map it appears. > > > > > > > Hi Mel, > > > > Hi. > > > Where is bss placed in physical memory? I guess bss_start and bss_stop > > from System.map will tell us. That will confirm that above memset step is > > stomping over bss. Then we have to just find that somewhere probably > > we allocated wrong physical memory area for bootmem allocator map. > > > > BSS is at 0x643000 -> 0x777BC4 > init_bootmem wipes from 0x777000 -> 0x8F7000 > > So the BSS bytes from 0x777000 ->0x777BC4 (which looks very suspiciously > pile a page alignment of addr & PAGE_MASK) gets set to 0xFF. One possible > fix is below. It adds a check in bad_addr() to see if the BSS section is > about to be used for bootmap. It Seems To Work For Me (tm) and illustrates > the source of the problem even if it's not the 100% correct fix. > Ok, it looks like that code is assuming that memory area returned by find_e820_area() is page aligned. I found two such instances and that's what is leading to problem. bootmap_size = init_bootmem_node(NODE_DATA(nodeid), bootmap_start >> PAGE_SHIFT, start_pfn, end_pfn); Here bootmap_start is not page aligned and I guess currently should contain the value 0x777BC4 (just beyond _end). But the moement I do bootmap_start>>PAGE_SHIFT, I start stomping bss. Similar is the case here. bootmap = find_e820_area(0, end_pfn<> PAGE_SHIFT, end_pfn); So may be we should return a page aligned address from find_e820_area(). May be we can change bad_addr() to set *addrp to next page aligned boundary for every check? *addrp = PAGE_ALIGN(__pa_symbol(&_end)); Thanks Vivek - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest fixes to bcm43xx-d80211 now available as patch to 2.6.18
On 10/6/06, Larry Finger <[EMAIL PROTECTED]> wrote: Bin Zhang wrote: > CC [M] drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.o > LD [M] drivers/net/wireless/d80211/bcm43xx/bcm43xx-d80211.o > LD drivers/net/wireless/built-in.o > ld: drivers/net/wireless/d80211/built-in.o: No such file: No such file > or directory > make[3]: *** [drivers/net/wireless/built-in.o] Error 1 > make[2]: *** [drivers/net/wireless] Error 2 > make[1]: *** [drivers/net] Error 2 > make: *** [drivers] Error 2 Initially I had seen that error, but thought it was fixed. A new version has been uploaded that builds correctly from a 'make clean' - please try it. Thanks. It works fine now (2.6.18 + the two patches). Best regards, Bin Also, please note Johannes Berg's comments regarding the increased interrupt usage for V4 firmware. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-mm2 boot failure on x86-64
On Fri, Oct 06, 2006 at 06:11:05PM +0100, Mel Gorman wrote:
> On (06/10/06 11:36), Vivek Goyal didst pronounce:
> > On Fri, Oct 06, 2006 at 03:33:12PM +0100, Mel Gorman wrote:
> > > > Linux version 2.6.18-git22 ([EMAIL PROTECTED]) (gcc version 4.1.0 (SUSE
> > > > Linux)) #2 SMP Thu Oct 5 19:05:36 PDT 2006
> > > > Command line: root=/dev/sda1 vga=791
> > > > ip=9.47.67.239:9.47.67.50:9.47.67.1:255.255.255.0 resume=/dev/sdb1
> > > > showopts earlyprintk=serial,ttyS0,57600 console=tty0
> > > > console=ttyS0,57600 autobench_args: root=/dev/sda1 ABAT:1160100417
> > > > BIOS-provided physical RAM map:
> > > > BIOS-e820: - 0009ac00 (usable)
> > > > BIOS-e820: 0009ac00 - 000a (reserved)
> > > > BIOS-e820: 000e - 0010 (reserved)
> > > > BIOS-e820: 0010 - bff764c0 (usable)
> > > > BIOS-e820: bff764c0 - bff98880 (ACPI data)
> > > > BIOS-e820: bff98880 - c000 (reserved)
> > > > BIOS-e820: fec0 - 0001 (reserved)
> > > > BIOS-e820: 0001 - 000c (usable)
> > >
> > > I continued what Steve was doing this morning to see could this be
> > > pinned down. After placing 'CHECK;' in a few places as suggested by
> > > Andi's check, the problem code was identified as that following in
> > > mm/bootmem.c#init_bootmem_core()
> > >
> > > mapsize = get_mapsize(bdata);
> > > memset(bdata->node_bootmem_map, 0xff, mapsize);
> > >
> > > That explains the value in the array at least. A few more printfs around
> > > this point printed out the following in the boot log
> > >
> > > init_bootmem_core(0, 1909, 0, 12582912)
> > > init_bootmem_core: Calling memset(0x81775000, 1572864)
> > > AAGH: afinfo corrupted at mm/bootmem.c:121
> > >
> > > where;
> > >
> > > 1909 == mapstart
> > > 0 == start
> > > 12582912 == end
> > > 1572864 == mapsize
> > >
> > > mapstart, start and end being the parameters being passed to
> > > init_bootmem_core(). This means we are calling memset for the physical
> > > range 0x775000 -> 0x8F5000 which is in a usable range according to the
> > > BIOS-e820 map it appears.
> > >
> >
> > Hi Mel,
> >
>
> Hi.
>
> > Where is bss placed in physical memory? I guess bss_start and bss_stop
> > from System.map will tell us. That will confirm that above memset step is
> > stomping over bss. Then we have to just find that somewhere probably
> > we allocated wrong physical memory area for bootmem allocator map.
> >
>
> BSS is at 0x643000 -> 0x777BC4
> init_bootmem wipes from 0x777000 -> 0x8F7000
>
> So the BSS bytes from 0x777000 ->0x777BC4 (which looks very suspiciously
> pile a page alignment of addr & PAGE_MASK) gets set to 0xFF. One possible
> fix is below. It adds a check in bad_addr() to see if the BSS section is
> about to be used for bootmap. It Seems To Work For Me (tm) and illustrates
> the source of the problem even if it's not the 100% correct fix.
>
> diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
> linux-2.6.18-git22-clean/arch/x86_64/kernel/e820.c
> linux-2.6.18-git22-bss_relocate_fix/arch/x86_64/kernel/e820.c
> --- linux-2.6.18-git22-clean/arch/x86_64/kernel/e820.c2006-10-05
> 20:42:07.0 +0100
> +++ linux-2.6.18-git22-bss_relocate_fix/arch/x86_64/kernel/e820.c
> 2006-10-06 17:39:51.0 +0100
> @@ -51,6 +51,7 @@ extern struct resource code_resource, da
> static inline int bad_addr(unsigned long *addrp, unsigned long size)
> {
> unsigned long addr = *addrp, last = addr + size;
> + unsigned long bss_start, bss_end;
>
> /* various gunk below that needed for SMP startup */
> if (addr < 0x8000) {
> @@ -77,6 +78,14 @@ static inline int bad_addr(unsigned long
> *addrp = __pa_symbol(&_end);
> return 1;
> }
> +
> + /* bss section */
> + bss_start = __pa_symbol(&__bss_start);
> + bss_end = PAGE_ALIGN(__pa_symbol(&__bss_stop));
> + if (addr >= bss_start && addr < bss_end) {
> + *addrp = bss_end;
> + return 1;
> + }
>
Surprising, the kernel code check just before this should have taken care
of it.
/* kernel code */
if (last >= __pa_symbol(&_text) && last < __pa_symbol(&_end)) {
*addrp = __pa_symbol(&_end);
return 1;
}
May be it can be changed to
if (last >= __pa_symbol(&_text) && last <
PAGE_ALIGN(__pa_symbol(&_end))) {
But all this seem to be a stopgap fix. Still the real puzzle is exactly
where did it slip out and should be fixed there.
May be some more printks will help us.
Thanks
Vivek
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT] SELinux/IPsec: bugfix pull request
Hi Dave, please pull the following bugfix patches, for the IPsec/SELinux and related labeled network code. The following changes since commit e77119c769b71c3f10b35d66988a3e279d30388c: James Morris: Merge ../../linux-2.6 into linus are found in the git repository at: git://git.infradead.org/~jmorris/selinux-2.6.git James Morris: IPsec: propagate security module errors up from flow_cache_lookup [EMAIL PROTECTED]: NetLabel: use SECINITSID_UNLABELED for a base SID Venkat Yekkirala: IPsec: correct semantics for SELinux policy matching IPsec: fix handling of errors for socket policies include/linux/security.h| 24 +++-- include/net/flow.h |2 - include/net/xfrm.h |3 + net/core/flow.c | 42 +++- net/ipv4/xfrm4_policy.c |2 - net/ipv6/xfrm6_policy.c |2 - net/key/af_key.c|5 -- net/xfrm/xfrm_policy.c | 101 +-- net/xfrm/xfrm_user.c|9 --- security/dummy.c|3 + security/selinux/include/xfrm.h |3 + security/selinux/ss/services.c | 29 +++ security/selinux/xfrm.c | 53 13 files changed, 171 insertions(+), 107 deletions(-) -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Kernel header changes break glibc build
The kernel headers installed by Linux 2.6.19-rc1 "make headers_install" do not work for building glibc, because glibc expects to provide various definitions, some of which have been moved to and some of which have been removed altogether. This kernel patch allows glibc to build again by making rtnetlink.h include if_addr.h and adding back the removed definitions required by glibc, but I don't know if it's the correct approach or if glibc should change the headers it includes and add its own macro definitions. Signed-off-by: Joseph Myers <[EMAIL PROTECTED]> --- Index: include/linux/rtnetlink.h === --- include/linux/rtnetlink.h +++ include/linux/rtnetlink.h @@ -2,6 +2,7 @@ #define __LINUX_RTNETLINK_H #include +#include #include / Index: include/linux/if_link.h === --- include/linux/if_link.h +++ include/linux/if_link.h @@ -82,6 +82,9 @@ #define IFLA_MAX (__IFLA_MAX - 1) +#define IFLA_RTA(r) ((struct rtattr*)(((char*)(r)) + NLMSG_ALIGN(sizeof(struct ifinfomsg +#define IFLA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct ifinfomsg)) + /* ifi_flags. IFF_* flags. Index: include/linux/if_addr.h === --- include/linux/if_addr.h +++ include/linux/if_addr.h @@ -52,4 +52,7 @@ __u32 tstamp; /* updated timestamp, hundredths of seconds */ }; +#define IFA_RTA(r) ((struct rtattr*)(((char*)(r)) + NLMSG_ALIGN(sizeof(struct ifaddrmsg +#define IFA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct ifaddrmsg)) + #endif -- Joseph S. Myers [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-mm2 boot failure on x86-64
On (06/10/06 11:36), Vivek Goyal didst pronounce:
> On Fri, Oct 06, 2006 at 03:33:12PM +0100, Mel Gorman wrote:
> > > Linux version 2.6.18-git22 ([EMAIL PROTECTED]) (gcc version 4.1.0 (SUSE
> > > Linux)) #2 SMP Thu Oct 5 19:05:36 PDT 2006
> > > Command line: root=/dev/sda1 vga=791
> > > ip=9.47.67.239:9.47.67.50:9.47.67.1:255.255.255.0 resume=/dev/sdb1
> > > showopts earlyprintk=serial,ttyS0,57600 console=tty0 console=ttyS0,57600
> > > autobench_args: root=/dev/sda1 ABAT:1160100417
> > > BIOS-provided physical RAM map:
> > > BIOS-e820: - 0009ac00 (usable)
> > > BIOS-e820: 0009ac00 - 000a (reserved)
> > > BIOS-e820: 000e - 0010 (reserved)
> > > BIOS-e820: 0010 - bff764c0 (usable)
> > > BIOS-e820: bff764c0 - bff98880 (ACPI data)
> > > BIOS-e820: bff98880 - c000 (reserved)
> > > BIOS-e820: fec0 - 0001 (reserved)
> > > BIOS-e820: 0001 - 000c (usable)
> >
> > I continued what Steve was doing this morning to see could this be
> > pinned down. After placing 'CHECK;' in a few places as suggested by
> > Andi's check, the problem code was identified as that following in
> > mm/bootmem.c#init_bootmem_core()
> >
> > mapsize = get_mapsize(bdata);
> > memset(bdata->node_bootmem_map, 0xff, mapsize);
> >
> > That explains the value in the array at least. A few more printfs around
> > this point printed out the following in the boot log
> >
> > init_bootmem_core(0, 1909, 0, 12582912)
> > init_bootmem_core: Calling memset(0x81775000, 1572864)
> > AAGH: afinfo corrupted at mm/bootmem.c:121
> >
> > where;
> >
> > 1909 == mapstart
> > 0 == start
> > 12582912 == end
> > 1572864 == mapsize
> >
> > mapstart, start and end being the parameters being passed to
> > init_bootmem_core(). This means we are calling memset for the physical
> > range 0x775000 -> 0x8F5000 which is in a usable range according to the
> > BIOS-e820 map it appears.
> >
>
> Hi Mel,
>
Hi.
> Where is bss placed in physical memory? I guess bss_start and bss_stop
> from System.map will tell us. That will confirm that above memset step is
> stomping over bss. Then we have to just find that somewhere probably
> we allocated wrong physical memory area for bootmem allocator map.
>
BSS is at 0x643000 -> 0x777BC4
init_bootmem wipes from 0x777000 -> 0x8F7000
So the BSS bytes from 0x777000 ->0x777BC4 (which looks very suspiciously
pile a page alignment of addr & PAGE_MASK) gets set to 0xFF. One possible
fix is below. It adds a check in bad_addr() to see if the BSS section is
about to be used for bootmap. It Seems To Work For Me (tm) and illustrates
the source of the problem even if it's not the 100% correct fix.
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
linux-2.6.18-git22-clean/arch/x86_64/kernel/e820.c
linux-2.6.18-git22-bss_relocate_fix/arch/x86_64/kernel/e820.c
--- linux-2.6.18-git22-clean/arch/x86_64/kernel/e820.c 2006-10-05
20:42:07.0 +0100
+++ linux-2.6.18-git22-bss_relocate_fix/arch/x86_64/kernel/e820.c
2006-10-06 17:39:51.0 +0100
@@ -51,6 +51,7 @@ extern struct resource code_resource, da
static inline int bad_addr(unsigned long *addrp, unsigned long size)
{
unsigned long addr = *addrp, last = addr + size;
+ unsigned long bss_start, bss_end;
/* various gunk below that needed for SMP startup */
if (addr < 0x8000) {
@@ -77,6 +78,14 @@ static inline int bad_addr(unsigned long
*addrp = __pa_symbol(&_end);
return 1;
}
+
+ /* bss section */
+ bss_start = __pa_symbol(&__bss_start);
+ bss_end = PAGE_ALIGN(__pa_symbol(&__bss_stop));
+ if (addr >= bss_start && addr < bss_end) {
+ *addrp = bss_end;
+ return 1;
+ }
if (last >= ebda_addr && addr < ebda_addr + ebda_size) {
*addrp = ebda_addr + ebda_size;
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest fixes to bcm43xx-d80211 now available as patch to 2.6.18
Le vendredi 06 octobre 2006 à 11:24 -0500, Larry Finger a écrit : > Bin Zhang wrote: > > CC [M] drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.o > > LD [M] drivers/net/wireless/d80211/bcm43xx/bcm43xx-d80211.o > > LD drivers/net/wireless/built-in.o > > ld: drivers/net/wireless/d80211/built-in.o: No such file: No such file > > or directory > > make[3]: *** [drivers/net/wireless/built-in.o] Error 1 > > make[2]: *** [drivers/net/wireless] Error 2 > > make[1]: *** [drivers/net] Error 2 > > make: *** [drivers] Error 2 > > Initially I had seen that error, but thought it was fixed. A new version has > been uploaded that > builds correctly from a 'make clean' - please try it. Fixed for the kernel build, thanks ! In test for the driver ;) Regards Didier -- Didier Link <[EMAIL PROTECTED]> Jabber : [EMAIL PROTECTED] MSN : [EMAIL PROTECTED] SIP : [EMAIL PROTECTED] Clé GPG : 75BAC9EE signature.asc Description: Ceci est une partie de message numériquement signée
Re: Latest fixes to bcm43xx-d80211 now available as patch to 2.6.18
Bin Zhang wrote: CC [M] drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.o LD [M] drivers/net/wireless/d80211/bcm43xx/bcm43xx-d80211.o LD drivers/net/wireless/built-in.o ld: drivers/net/wireless/d80211/built-in.o: No such file: No such file or directory make[3]: *** [drivers/net/wireless/built-in.o] Error 1 make[2]: *** [drivers/net/wireless] Error 2 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 Initially I had seen that error, but thought it was fixed. A new version has been uploaded that builds correctly from a 'make clean' - please try it. Also, please note Johannes Berg's comments regarding the increased interrupt usage for V4 firmware. Larry - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-mm2 boot failure on x86-64
On Fri, Oct 06, 2006 at 03:33:12PM +0100, Mel Gorman wrote: > > Linux version 2.6.18-git22 ([EMAIL PROTECTED]) (gcc version 4.1.0 (SUSE > > Linux)) #2 SMP Thu Oct 5 19:05:36 PDT 2006 > > Command line: root=/dev/sda1 vga=791 > > ip=9.47.67.239:9.47.67.50:9.47.67.1:255.255.255.0 resume=/dev/sdb1 showopts > > earlyprintk=serial,ttyS0,57600 console=tty0 console=ttyS0,57600 > > autobench_args: root=/dev/sda1 ABAT:1160100417 > > BIOS-provided physical RAM map: > > BIOS-e820: - 0009ac00 (usable) > > BIOS-e820: 0009ac00 - 000a (reserved) > > BIOS-e820: 000e - 0010 (reserved) > > BIOS-e820: 0010 - bff764c0 (usable) > > BIOS-e820: bff764c0 - bff98880 (ACPI data) > > BIOS-e820: bff98880 - c000 (reserved) > > BIOS-e820: fec0 - 0001 (reserved) > > BIOS-e820: 0001 - 000c (usable) > > I continued what Steve was doing this morning to see could this be > pinned down. After placing 'CHECK;' in a few places as suggested by > Andi's check, the problem code was identified as that following in > mm/bootmem.c#init_bootmem_core() > > mapsize = get_mapsize(bdata); > memset(bdata->node_bootmem_map, 0xff, mapsize); > > That explains the value in the array at least. A few more printfs around > this point printed out the following in the boot log > > init_bootmem_core(0, 1909, 0, 12582912) > init_bootmem_core: Calling memset(0x81775000, 1572864) > AAGH: afinfo corrupted at mm/bootmem.c:121 > > where; > > 1909 == mapstart > 0 == start > 12582912 == end > 1572864 == mapsize > > mapstart, start and end being the parameters being passed to > init_bootmem_core(). This means we are calling memset for the physical > range 0x775000 -> 0x8F5000 which is in a usable range according to the > BIOS-e820 map it appears. > Hi Mel, Where is bss placed in physical memory? I guess bss_start and bss_stop from System.map will tell us. That will confirm that above memset step is stomping over bss. Then we have to just find that somewhere probably we allocated wrong physical memory area for bootmem allocator map. Thanks Vivek - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/02] net/ipv6: seperate sit driver to extra module
On Fri, Oct 06, 2006 at 09:59:35PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > + into IPv4 packets. This is usefull if you want to connect two IPv6 Argh. Bad typo. I appended the fixed patch Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]> diff -upr -X linux-2.6.18/Documentation/dontdiff linux-2.6.18-vanilla/net/ipv6/af_inet6.c linux-2.6.18/net/ipv6/af_inet6.c --- linux-2.6.18-vanilla/net/ipv6/af_inet6.c2006-09-20 05:42:06.0 +0200 +++ linux-2.6.18/net/ipv6/af_inet6.c2006-10-05 16:55:02.0 +0200 @@ -849,7 +849,6 @@ static int __init inet6_init(void) err = addrconf_init(); if (err) goto addrconf_fail; - sit_init(); /* Init v6 extension headers. */ ipv6_rthdr_init(); @@ -920,7 +919,6 @@ static void __exit inet6_exit(void) raw6_proc_exit(); #endif /* Cleanup code parts. */ - sit_cleanup(); ip6_flowlabel_cleanup(); addrconf_cleanup(); ip6_route_cleanup(); diff -upr -X linux-2.6.18/Documentation/dontdiff linux-2.6.18-vanilla/net/ipv6/Kconfig linux-2.6.18/net/ipv6/Kconfig --- linux-2.6.18-vanilla/net/ipv6/Kconfig 2006-09-20 05:42:06.0 +0200 +++ linux-2.6.18/net/ipv6/Kconfig 2006-10-05 18:14:57.0 +0200 @@ -126,6 +126,19 @@ config INET6_XFRM_MODE_TUNNEL If unsure, say Y. +config IPV6_SIT + tristate "IPv6: IPv6-in-IPv4 tunnel (SIT driver)" + depends on IPV6 + default y + ---help--- + Tunneling means encapsulating data of one protocol type within + another protocol and sending it over a channel that understands the + encapsulating protocol. This driver implements encapsulation of IPv6 + into IPv4 packets. This is useful if you want to connect two IPv6 + networks over an IPv4-only path. + + Saying M here will produce a module called sit.ko. If unsure, say N. + config IPV6_TUNNEL tristate "IPv6: IPv6-in-IPv6 tunnel" select INET6_TUNNEL diff -upr -X linux-2.6.18/Documentation/dontdiff linux-2.6.18-vanilla/net/ipv6/Makefile linux-2.6.18/net/ipv6/Makefile --- linux-2.6.18-vanilla/net/ipv6/Makefile 2006-09-20 05:42:06.0 +0200 +++ linux-2.6.18/net/ipv6/Makefile 2006-10-05 17:10:42.0 +0200 @@ -4,7 +4,7 @@ obj-$(CONFIG_IPV6) += ipv6.o -ipv6-objs := af_inet6.o anycast.o ip6_output.o ip6_input.o addrconf.o sit.o \ +ipv6-objs := af_inet6.o anycast.o ip6_output.o ip6_input.o addrconf.o \ route.o ip6_fib.o ipv6_sockglue.o ndisc.o udp.o raw.o \ protocol.o icmp.o mcast.o reassembly.o tcp_ipv6.o \ exthdrs.o sysctl_net_ipv6.o datagram.o proc.o \ @@ -24,6 +24,7 @@ obj-$(CONFIG_INET6_XFRM_MODE_TRANSPORT) obj-$(CONFIG_INET6_XFRM_MODE_TUNNEL) += xfrm6_mode_tunnel.o obj-$(CONFIG_NETFILTER)+= netfilter/ +obj-$(CONFIG_IPV6_SIT) += sit.o obj-$(CONFIG_IPV6_TUNNEL) += ip6_tunnel.o obj-y += exthdrs_core.o diff -upr -X linux-2.6.18/Documentation/dontdiff linux-2.6.18-vanilla/net/ipv6/sit.c linux-2.6.18/net/ipv6/sit.c --- linux-2.6.18-vanilla/net/ipv6/sit.c 2006-09-20 05:42:06.0 +0200 +++ linux-2.6.18/net/ipv6/sit.c 2006-10-05 16:55:02.0 +0200 @@ -850,3 +850,6 @@ int __init sit_init(void) inet_del_protocol(&sit_protocol, IPPROTO_IPV6); goto out; } + +module_init(sit_init); +module_exit(sit_cleanup);
Re: [patch 3/6] 2.6.18: sb1250-mac: Phylib IRQ handling fixes
On Fri, 6 Oct 2006 12:26:22 +0100 (BST)
"Maciej W. Rozycki" <[EMAIL PROTECTED]> wrote:
> On Thu, 5 Oct 2006, Andrew Morton wrote:
>
> > > 2. The driver uses schedule_work() for handling interrupts, but does not
> > >make sure any pending work scheduled thus has been completed before
> > >driver's structures get freed from memory. This is especially
> > >important as interrupts may keep arriving if the line is shared with
> > >another PHY.
> > >
> > >The solution is to ignore phy_interrupt() calls if the reported device
> > >has already been halted and calling flush_scheduled_work() from
> > >phy_stop_interrupts() (but guarded with current_is_keventd() in case
> > >the function has been called through keventd from the MAC device's
> > >close call to avoid a deadlock on the netlink lock).
> > >
> >
> > eww, hack.
> >
> > Also not module-friendly:
> >
> > WARNING: "current_is_keventd" [drivers/net/phy/libphy.ko] undefined!
> >
> > Does this
> >
> > static void flush_cpu_workqueue(struct cpu_workqueue_struct *cwq)
> > {
> > if (cwq->thread == current) {
> > /*
> > * Probably keventd trying to flush its own queue. So simply run
> > * it by hand rather than deadlocking.
> > */
> > run_workqueue(cwq);
> >
> > not work???
>
> It does, too well even! -- in the case I am trying to take care of we are
> run with "rtnl_mutex" held as a result of rtnl_lock() called from
> unregister_netdev() and there is some work already in the workqueue
> (linkwatch_event(), apparently) wanting to acquire the same lock. Hence a
> deadlock.
I don't get it. If some code does
rtnl_lock();
flush_scheduled_work();
and there's some work scheduled which does rtnl_lock() then it'll deadlock.
But it'll deadlock whether or not the caller of flush_scheduled_work() is
keventd.
Calling flush_scheduled_work() under locks is generally a bad idea.
> It seems problematic elsewhere as well -- see tg3.c -- but a
> different way to deal with it has been found there.
>
> I am not that fond of this solution, but at least it works, unlike
> calling flush_scheduled_work() here, which deadlocks the current CPU in my
> system instantly. Any suggestions as to how to do this differently?
> Perhaps linkwatch_event() should be scheduled differently (using a
> separate workqueue?)...
I'd have thought that was still deadlockable. Could you describe the
deadlock more completely please?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cfg80211 take 7
Maybe this time it'll take the announcement too? --- I have * addressed Dan's comments about naming a few things and also fixed the problems he pointed out * moved wext from net/core/wireless.c to net/wireless/wext-old.c * added compat hunking for WE to cfg80211, finally completely separating the userspace interface and the internal interface * made it possible to port drivers to cfg80211 call by call! * fixed a bug with locking in core.c I have not * added get_scan * added event notification Have fun. Oh, I can put this into a git tree too if you think that'd be useful for further collaboration. However, I'm thinking that wireless-dev could also be used since this doesn't really break anything, it just adds new code that might not be in use yet, but should be fairly good to use should anyone want that. I guess what I'm trying to say with that is that there's no way I can finish this all by myself, I also need sleep sometimes ;) I thank everyone for their review and suppose that more people read it than commented (which is probably a good thing). Hopefully I can motivate you with these patches that should ease migration to actually help with code as well :) johannes - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
cfg80211 take 7
Hah, take 6 was eaten by netdev (even the announcement) but it did reach some people (and before those who did get it wonder: I resent to netdev, the original mail was accidentally not addressed to netdev, so it's not that I simply didn't send it). anyway, it's getting large, so... straight from quilt: http://johannes.sipsolutions.net/files/cfg80211/ order is: nl80211.patch move-wext.patch wext-compat.patch johannes - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/02] net/ipv6: seperate sit driver to extra module (addrconf.c changes)
In article <[EMAIL PROTECTED]> (at Fri, 6 Oct 2006 11:39:27 +0200), Joerg Roedel <[EMAIL PROTECTED]> says: > This patch contains the changes to net/ipv6/addrconf.c to remove sit > specific code if the sit driver is not selected. > > Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]> Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> --yoshfuji - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/02] net/ipv6: seperate sit driver to extra module
In article <[EMAIL PROTECTED]> (at Fri, 6 Oct 2006 11:34:02 +0200), Joerg Roedel <[EMAIL PROTECTED]> says: > this is the submit of the patch discussed yesterday to compile the sit > driver as a seperate module. > > changes to yesterday: > - default select changed to y in Kconfig > - added ifdefs to net/ipv6/addrconf.c > (this part is big, to keep the patches around 100 lines the >addrconf.c changes are posted in a seperate patch) > > Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]> > + into IPv4 packets. This is usefull if you want to connect two IPv6 ~~~useful Otherwise, it seems okay to me. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/02] net/ipv6: seperate sit driver to extra module
> "Joerg" == Joerg Roedel <[EMAIL PROTECTED]> writes: Joerg> It is enabled per default because the users get this per Joerg> default when using the current IPv6 module. James Morris Joerg> mentioned this issue yesterday. I think setting the default to Joerg> N would be more consistent, but the Y is probably less painfull Joerg> for the users. Makes sense. I proposed this because I reconfigure my kernel with "make oldconfig" and see new questions pop up. Maybe menuconfig and xconfig should proeminently highlight NEW questions from the top-level (by using a bold font on any item which is either new or has new sub-items) so that users get a clear view of what they may need to configure. Sam -- Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/02] net/ipv6: seperate sit driver to extra module
On Fri, Oct 06, 2006 at 01:38:24PM +0200, Samuel Tardieu wrote: > > "Joerg" == Joerg Roedel <[EMAIL PROTECTED]> writes: > > Joerg> this is the submit of the patch discussed yesterday to compile > Joerg> the sit driver as a seperate module. > > Your patch looks ok to me, but given that many people won't need sit, > why is it enabled by default? Omitting it would save 10k of kernel > text on x86 and people will see the new kernel configuration option > anyway and will enable it if needed. It is enabled per default because the users get this per default when using the current IPv6 module. James Morris mentioned this issue yesterday. I think setting the default to N would be more consistent, but the Y is probably less painfull for the users. Joerg - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/02] net/ipv6: seperate sit driver to extra module
Samuel Tardieu schrieb: >> "Joerg" == Joerg Roedel <[EMAIL PROTECTED]> writes: > > Joerg> this is the submit of the patch discussed yesterday to compile > Joerg> the sit driver as a seperate module. > > Your patch looks ok to me, but given that many people won't need sit, > why is it enabled by default? Omitting it would save 10k of kernel > text on x86 and people will see the new kernel configuration option > anyway and will enable it if needed. At least if set to "n" don't forget to alert the distributors (Red Hat, etc.) to renable this. Otherwise, many clients which using 6to4 will fail... Just my 2 cents, Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto:[EMAIL PROTECTED] Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ OpenBChttp://www.openbc.com/hp/Peter_Bieringer/ Personal invitation to OpenBC http://www.openbc.com/go/invita/3889 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/02] net/ipv6: seperate sit driver to extra module
> "Joerg" == Joerg Roedel <[EMAIL PROTECTED]> writes: Joerg> this is the submit of the patch discussed yesterday to compile Joerg> the sit driver as a seperate module. Your patch looks ok to me, but given that many people won't need sit, why is it enabled by default? Omitting it would save 10k of kernel text on x86 and people will see the new kernel configuration option anyway and will enable it if needed. Sam -- Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/6] 2.6.18: sb1250-mac: Phylib IRQ handling fixes
On Thu, 5 Oct 2006, Andrew Morton wrote:
> > 2. The driver uses schedule_work() for handling interrupts, but does not
> >make sure any pending work scheduled thus has been completed before
> >driver's structures get freed from memory. This is especially
> >important as interrupts may keep arriving if the line is shared with
> >another PHY.
> >
> >The solution is to ignore phy_interrupt() calls if the reported device
> >has already been halted and calling flush_scheduled_work() from
> >phy_stop_interrupts() (but guarded with current_is_keventd() in case
> >the function has been called through keventd from the MAC device's
> >close call to avoid a deadlock on the netlink lock).
> >
>
> eww, hack.
>
> Also not module-friendly:
>
> WARNING: "current_is_keventd" [drivers/net/phy/libphy.ko] undefined!
>
> Does this
>
> static void flush_cpu_workqueue(struct cpu_workqueue_struct *cwq)
> {
> if (cwq->thread == current) {
> /*
>* Probably keventd trying to flush its own queue. So simply run
>* it by hand rather than deadlocking.
>*/
> run_workqueue(cwq);
>
> not work???
It does, too well even! -- in the case I am trying to take care of we are
run with "rtnl_mutex" held as a result of rtnl_lock() called from
unregister_netdev() and there is some work already in the workqueue
(linkwatch_event(), apparently) wanting to acquire the same lock. Hence a
deadlock. It seems problematic elsewhere as well -- see tg3.c -- but a
different way to deal with it has been found there.
I am not that fond of this solution, but at least it works, unlike
calling flush_scheduled_work() here, which deadlocks the current CPU in my
system instantly. Any suggestions as to how to do this differently?
Perhaps linkwatch_event() should be scheduled differently (using a
separate workqueue?)... Or does dev_close() have to be called under this
lock from unregister_netdevice()? Perhaps code like this would do:
while (dev->flags & IFF_UP) {
rtnl_unlock();
dev_close(dev);
rtnl_lock();
}
Maciej
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] cfg80211/nl80211 core
On Thu, 2006-09-14 at 12:49 +0200, Johannes Berg wrote:
> +struct cfg80211_registered_driver *
> +cfg80211_get_drv_from_ifindex(int ifindex)
> +{
> + struct cfg80211_registered_driver *drv;
> + struct net_device *dev;
> +
> + mutex_lock(&cfg80211_drv_mutex);
> + dev = dev_get_by_index(ifindex);
> + if (!dev)
> + return ERR_PTR(-ENODEV);
> + drv = cfg80211_drv_by_priv(dev->ieee80211_ptr);
> + if (drv)
> + mutex_lock(&drv->mtx);
> + dev_put(dev);
> + if (drv)
> + return drv;
> + return ERR_PTR(-ENODEV);
> +}
So... nobody spotted the "obvious" [1] locking problem here ;) fixed,
will update the patches soon and upload somewhere, netdev doesn't like
them and drops my mail (even 0/3 which wasn't that big).
johannes
[1] hint: drv->mtx is supposed to be left locked at the end, but
cfg80211_drv_mutex isn't :) I found out the hard way when testing my WE
backward compat code
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] cfg80211 and nl80211
Let me try to summarise this... probably wrong :) > 1.5 KB sounds like a small scan result set to me.. I'm hitting 100+ > BSSes at work (well, not really your normal environment ;-), and 50 at > home.. These go way beyond 1.5 KB; closer to 32 KB at times, I'd guess. Ok this is easy, we need huge results and thus can't reasonably push them out on each change... Maybe some sequence number thingie could be used? I'd like to have a .dumpit call with genl to actually dump all the scan results to userspace, maybe that message could be multicast to interested stations if someone requests one? No idea... Thomas? As for the auth/crypto/key mgmt issue... It looks like these three are basically orthogonal. If I understand correctly, you need to be able to * set a key including algorithm for the possible - key indexes 0,1,2,3 - a STA identified by MAC address (and the key is identified by these uniquely) This includes - algorithm (none to clear, wep, tkip, ccmp, ...) - key material - TSC/SN (only valid for some algorithms) (key material length is used to decide between wep types, and some attributes may be left off, e.g. to change the tsc/sn without changing the key material or algorithm) * set transmit key index (STA only?) * set multicast/broadcast key index * dot11ExcludeUnecrypted (default true) * authentication mode, including - allowed algorithms (open, shared-key, ...) - key index of key to use - preference of use? That would make the allowed algorithms a list instead of a bitfield * set IE(s) (only some cards) * set allowed cipher suites for RSN/WPA IE generation (only some cards) [do we need to be able to distinguish between these or is it fine to just try both and get an error for one?] * a way to get the device's capabilities (per-net_device) - crypto algorithms - auth algorithms - ...? Does that sound right? (throw in get versions for most of these, of course) Open issues: * associating a key index with a mac address for unicast wep key? Hmm. That's at least 8 operations that WE sticks into 3. No wonder no one understands it... johannes - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/02] net/ipv6: seperate sit driver to extra module (addrconf.c changes)
This patch contains the changes to net/ipv6/addrconf.c to remove sit
specific code if the sit driver is not selected.
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
diff -upr -X linux-2.6.18/Documentation/dontdiff
linux-2.6.18-vanilla/net/ipv6/addrconf.c linux-2.6.18/net/ipv6/addrconf.c
--- linux-2.6.18-vanilla/net/ipv6/addrconf.c2006-09-20 05:42:06.0
+0200
+++ linux-2.6.18/net/ipv6/addrconf.c2006-10-06 11:04:04.0 +0200
@@ -389,8 +389,10 @@ static struct inet6_dev * ipv6_add_dev(s
ndev->regen_timer.data = (unsigned long) ndev;
if ((dev->flags&IFF_LOOPBACK) ||
dev->type == ARPHRD_TUNNEL ||
- dev->type == ARPHRD_NONE ||
- dev->type == ARPHRD_SIT) {
+#if defined(CONFIG_IPV6_SIT) || defined(CONFIG_IPV6_SIT_MODULE)
+ dev->type == ARPHRD_SIT ||
+#endif
+ dev->type == ARPHRD_NONE) {
printk(KERN_INFO
"%s: Disabled Privacy Extensions\n",
dev->name);
@@ -1522,8 +1524,10 @@ addrconf_prefix_route(struct in6_addr *p
This thing is done here expecting that the whole
class of non-broadcast devices need not cloning.
*/
+#if defined(CONFIG_IPV6_SIT) || defined(CONFIG_IPV6_SIT_MODULE)
if (dev->type == ARPHRD_SIT && (dev->flags&IFF_POINTOPOINT))
rtmsg.rtmsg_flags |= RTF_NONEXTHOP;
+#endif
ip6_route_add(&rtmsg, NULL, NULL, NULL);
}
@@ -1545,6 +1549,7 @@ static void addrconf_add_mroute(struct n
ip6_route_add(&rtmsg, NULL, NULL, NULL);
}
+#if defined(CONFIG_IPV6_SIT) || defined(CONFIG_IPV6_SIT_MODULE)
static void sit_route_add(struct net_device *dev)
{
struct in6_rtmsg rtmsg;
@@ -1561,6 +1566,7 @@ static void sit_route_add(struct net_dev
ip6_route_add(&rtmsg, NULL, NULL, NULL);
}
+#endif
static void addrconf_add_lroute(struct net_device *dev)
{
@@ -1831,6 +1837,7 @@ int addrconf_set_dstaddr(void __user *ar
if (dev == NULL)
goto err_exit;
+#if defined(CONFIG_IPV6_SIT) || defined(CONFIG_IPV6_SIT_MODULE)
if (dev->type == ARPHRD_SIT) {
struct ifreq ifr;
mm_segment_toldfs;
@@ -1860,6 +1867,7 @@ int addrconf_set_dstaddr(void __user *ar
err = dev_open(dev);
}
}
+#endif
err_exit:
rtnl_unlock();
@@ -1993,6 +2001,7 @@ int addrconf_del_ifaddr(void __user *arg
return err;
}
+#if defined(CONFIG_IPV6_SIT) || defined(CONFIG_IPV6_SIT_MODULE)
static void sit_add_v4_addrs(struct inet6_dev *idev)
{
struct inet6_ifaddr * ifp;
@@ -2061,6 +2070,7 @@ static void sit_add_v4_addrs(struct inet
}
}
}
+#endif
static void init_loopback(struct net_device *dev)
{
@@ -2124,6 +2134,7 @@ static void addrconf_dev_config(struct n
addrconf_add_linklocal(idev, &addr);
}
+#if defined(CONFIG_IPV6_SIT) || defined(CONFIG_IPV6_SIT_MODULE)
static void addrconf_sit_config(struct net_device *dev)
{
struct inet6_dev *idev;
@@ -2149,6 +2160,7 @@ static void addrconf_sit_config(struct n
} else
sit_route_add(dev);
}
+#endif
static inline int
ipv6_inherit_linklocal(struct inet6_dev *idev, struct net_device *link_dev)
@@ -2243,9 +2255,11 @@ static int addrconf_notify(struct notifi
}
switch(dev->type) {
+#if defined(CONFIG_IPV6_SIT) || defined(CONFIG_IPV6_SIT_MODULE)
case ARPHRD_SIT:
addrconf_sit_config(dev);
break;
+#endif
case ARPHRD_TUNNEL6:
addrconf_ip6_tnl_config(dev);
break;
[PATCH 01/02] net/ipv6: seperate sit driver to extra module
this is the submit of the patch discussed yesterday to compile the sit driver as a seperate module. changes to yesterday: - default select changed to y in Kconfig - added ifdefs to net/ipv6/addrconf.c (this part is big, to keep the patches around 100 lines the addrconf.c changes are posted in a seperate patch) Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]> diff -upr -X linux-2.6.18/Documentation/dontdiff linux-2.6.18-vanilla/net/ipv6/af_inet6.c linux-2.6.18/net/ipv6/af_inet6.c --- linux-2.6.18-vanilla/net/ipv6/af_inet6.c2006-09-20 05:42:06.0 +0200 +++ linux-2.6.18/net/ipv6/af_inet6.c2006-10-05 16:55:02.0 +0200 @@ -849,7 +849,6 @@ static int __init inet6_init(void) err = addrconf_init(); if (err) goto addrconf_fail; - sit_init(); /* Init v6 extension headers. */ ipv6_rthdr_init(); @@ -920,7 +919,6 @@ static void __exit inet6_exit(void) raw6_proc_exit(); #endif /* Cleanup code parts. */ - sit_cleanup(); ip6_flowlabel_cleanup(); addrconf_cleanup(); ip6_route_cleanup(); diff -upr -X linux-2.6.18/Documentation/dontdiff linux-2.6.18-vanilla/net/ipv6/Kconfig linux-2.6.18/net/ipv6/Kconfig --- linux-2.6.18-vanilla/net/ipv6/Kconfig 2006-09-20 05:42:06.0 +0200 +++ linux-2.6.18/net/ipv6/Kconfig 2006-10-05 18:14:57.0 +0200 @@ -126,6 +126,19 @@ config INET6_XFRM_MODE_TUNNEL If unsure, say Y. +config IPV6_SIT + tristate "IPv6: IPv6-in-IPv4 tunnel (SIT driver)" + depends on IPV6 + default y + ---help--- + Tunneling means encapsulating data of one protocol type within + another protocol and sending it over a channel that understands the + encapsulating protocol. This driver implements encapsulation of IPv6 + into IPv4 packets. This is usefull if you want to connect two IPv6 + networks over an IPv4-only path. + + Saying M here will produce a module called sit.ko. If unsure, say N. + config IPV6_TUNNEL tristate "IPv6: IPv6-in-IPv6 tunnel" select INET6_TUNNEL diff -upr -X linux-2.6.18/Documentation/dontdiff linux-2.6.18-vanilla/net/ipv6/Makefile linux-2.6.18/net/ipv6/Makefile --- linux-2.6.18-vanilla/net/ipv6/Makefile 2006-09-20 05:42:06.0 +0200 +++ linux-2.6.18/net/ipv6/Makefile 2006-10-05 17:10:42.0 +0200 @@ -4,7 +4,7 @@ obj-$(CONFIG_IPV6) += ipv6.o -ipv6-objs := af_inet6.o anycast.o ip6_output.o ip6_input.o addrconf.o sit.o \ +ipv6-objs := af_inet6.o anycast.o ip6_output.o ip6_input.o addrconf.o \ route.o ip6_fib.o ipv6_sockglue.o ndisc.o udp.o raw.o \ protocol.o icmp.o mcast.o reassembly.o tcp_ipv6.o \ exthdrs.o sysctl_net_ipv6.o datagram.o proc.o \ @@ -24,6 +24,7 @@ obj-$(CONFIG_INET6_XFRM_MODE_TRANSPORT) obj-$(CONFIG_INET6_XFRM_MODE_TUNNEL) += xfrm6_mode_tunnel.o obj-$(CONFIG_NETFILTER)+= netfilter/ +obj-$(CONFIG_IPV6_SIT) += sit.o obj-$(CONFIG_IPV6_TUNNEL) += ip6_tunnel.o obj-y += exthdrs_core.o diff -upr -X linux-2.6.18/Documentation/dontdiff linux-2.6.18-vanilla/net/ipv6/sit.c linux-2.6.18/net/ipv6/sit.c --- linux-2.6.18-vanilla/net/ipv6/sit.c 2006-09-20 05:42:06.0 +0200 +++ linux-2.6.18/net/ipv6/sit.c 2006-10-05 16:55:02.0 +0200 @@ -850,3 +850,6 @@ int __init sit_init(void) inet_del_protocol(&sit_protocol, IPPROTO_IPV6); goto out; } + +module_init(sit_init); +module_exit(sit_cleanup);
Re: [take19 0/4] kevent: Generic event handling mechanism.
On Thu, Oct 05, 2006 at 07:45:23AM -0700, Ulrich Drepper ([EMAIL PROTECTED]) wrote: > Evgeniy Polyakov wrote: > > And you can add/remove signal events using existing kevent api between > > calls. > > That's far more expensive than using a mask under control of the program. In context you have cut, one updated signal mask between calls to event delivery mechanism (using for example signal()), so it has exactly the same price. > > And creating special cases for usual events is bad. > > There is unified way to deal with events in kevent - > > add/remove/modify/wait on them, signals are just usual events. > > How can this be unified? The installment of the temporary signal mask > is unlike the handling of signal for the purpose of reporting them > through the signal queue. It's equally completely new functionality. > Don't kid yourself in thinking that because this is signal stuff, too, > you're "unifying" something. The way this signal mask is used has > nothing whatsoever to do with the delivering signals via the event > queue. For the latter the signals always must be blocked (similar to > sigwait's requirement). > > As a result it means you want to introduce a new mechanism for the event > queue instead of using the well known and often used method of > optionally passing a signal mask to the syscall. That's just insane. I created it just because I think that POSIX workaround to add signals into the syscall parameters is not good enough. Exactly with the same logic I created kevent to drive AIO completeness, to work with socket notifications and timers and so on. All above (listio(), poll(), setitimer() and so on) are known and good interfaces, but practice shows that having one interface, which can easily work with all existing cases is much more convenient than having tons of them. So, yes, I do introduce new mechanism to solve signal problem here, just because I think all existing have some limitations or problems. > > I think you wanted to say, that 'all event mechanism except the most > > commonly used poll/select/epoll use timespec'. > > Get your facts straight. select uses timeval which is just the > predecessor of of timespec. And epoll is just (badly) designed after > poll. Fact is therefore that poll plus its spawn is the only interface > using such a timeout method. And it was designed very good, although it looks like we disagree a bit here... > > I designed it to be similar to poll(), it is really good interface. > > Not many people agree. All the interfaces designed (not derived) in the > last years take a timespec parameter. > > Plus, you chose to ignore all the nice things using a timespec allow you > like absolute timeout modes etc. See the clock_nanosleep() interface > for a way this can be useful. You again cut my explanation on why just pure timeout is used. We start a syscall, which can block forever, so we want to limit it's time, and we add special parameter to show how long this syscall should run. Timeout is not about how long we should sleep (which indeed can be absolute), but how long syscall should run - which is related to the time syscall started. > -- > ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest fixes to bcm43xx-d80211 now available as patch to 2.6.18
On Thu, 2006-10-05 at 18:33 -0500, Larry Finger wrote: > The patch file contains Michael Buesch's changes of 05-Oct-2006. This > version can use either V3 or V4 firmware. It has been compiled and > tested on my system. Note that there seem to be some problems with v4 firmware, I had the machine hang at about 20% si/hi load with v4, maybe some interrupt the v4 firmware keeps triggering and we never handle the condition or something... I'll keep digging. johannes - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
