* RE: Does dom0 see all physical processors? (RE:[Xen-ia64-devel] SAL INFO virtualization)
From: Magenheimer, Dan (HP Labs Fort Collins) @ 2006-04-05 14:07 UTC (permalink / raw)
To: Ian Pratt, Keir Fraser, Tian, Kevin
Cc: Jimi Xenidis, xen-devel, okrieg, Tristan Gingold, xen-ia64-devel
(Orran/Jimi cc'ed, see question below...)
> > I understand and sympathize with the need for dom0 to
> > sometimes get and use information from each processor that is
> > only available if dom0 is running on each processor.
> >
> > However, AFAIK, SMP guests are always gang-scheduled, correct?
>
> No, there's no need to strictly gang schedule, and the
> current scheduler makes no attempt to do so. It may generally
> be a decent thing to do, though.
>
> > (If not, aren't there some very knotty research issues
> > related to locking and forward progress?)
>
> You could end up preempting a vCPU holding a lock which could
> lead to daft behaviour of naïve spin locks. A number of
> possible workarounds have been prototyped, but since it
> doesn't seem to be much of a problem in practice nothing has
> been checked in.
I wonder if "not a problem in practice" is more of an indication
of lack of practice than lack of problem. I can see that the
problem would be unlikely to occur with small numbers of
processors and one SMP guests running a highly scalable SMP app
(such as a web server), but I'll bet a real enterprise load
of home-grown SMP apps running in a IT shop that's had big SMP
boxes for years would see the problem more quickly, especially
after multiple SMP guests are consolidated onto a single box.
I believe ppc has "paravirtualized spinlocks" in their Linux
kernel, though even this won't necessarily help with a poorly
written SMP application.
No data, admittedly, but perhaps our good buddies at
Watson could comment?
> > So on a 16-processor system, every time dom0 needs to run
> > (e.g. to handle backend I/O for any one of perhaps hundreds
> > of domains), *every* domain gets descheduled so that dom0 can
> > be (gang-)scheduled on all 16 processors?
> >
> > If true, this sounds like a _horrible_ performance hit, so I
> > hope I'm misunderstanding something...
>
> This isn't an issue.
>
> After booting you probably want dom0 to give up all but 1 vCPU anyway.
Unless of course the PCPU's have data that change over time, such
as variable cycle rate (for power management) or hot-plug memory...
> Ian
>
Dan
^ permalink raw reply
* Re: [PATCH 08/15] powerpc: move asm/open_pic.h
From: Kumar Gala @ 2006-04-05 14:07 UTC (permalink / raw)
To: sfr; +Cc: linuxppc-dev, paulus
In-Reply-To: <11442138641124-git-send-email-sfr@canb.auug.org.au>
I'd need to check, but I dont think we should move this since arch/
powerpc is using mpic to handle openpic and I'm guessing it has its
own headers.
- k
On Apr 5, 2006, at 12:10 AM, sfr@canb.auug.org.au wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
>
> Since the ARCH=powerpc build depends on this file, move it to
> include/asm-powerpc.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>
> ---
>
> include/asm-powerpc/open_pic.h | 99 +++++++++++++++++++++++++++++
> +++++++++++
> include/asm-ppc/open_pic.h | 99
> ----------------------------------------
> 2 files changed, 99 insertions(+), 99 deletions(-)
> create mode 100644 include/asm-powerpc/open_pic.h
> delete mode 100644 include/asm-ppc/open_pic.h
>
> 54316678b9e6aad8349f2df50dadd2597b675804
> diff --git a/include/asm-powerpc/open_pic.h b/include/asm-powerpc/
> open_pic.h
> new file mode 100644
> index 0000000..3f197cf
> --- /dev/null
> +++ b/include/asm-powerpc/open_pic.h
> @@ -0,0 +1,99 @@
> +#ifndef _ASM_POWERPC_OPEN_PIC_H
> +#define _ASM_POWERPC_OPEN_PIC_H
> +
> +/*
> + * include/asm-ppc/open_pic.h -- OpenPIC Interrupt Handling
> + *
> + * Copyright (C) 1997 Geert Uytterhoeven
> + *
> + * This file is subject to the terms and conditions of the GNU
> General Public
> + * License. See the file COPYING in the main directory of this
> archive
> + * for more details.
> + *
> + */
> +
> +#include <linux/irq.h>
> +
> +#define OPENPIC_SIZE 0x40000
> +
> +/*
> + * Non-offset'ed vector numbers
> + */
> +
> +#define OPENPIC_VEC_TIMER 110 /* and up */
> +#define OPENPIC_VEC_IPI 118 /* and up */
> +#define OPENPIC_VEC_SPURIOUS 255
> +
> +/* Priorities */
> +#define OPENPIC_PRIORITY_IPI_BASE 10
> +#define OPENPIC_PRIORITY_DEFAULT 4
> +#define OPENPIC_PRIORITY_NMI 9
> +
> +/* OpenPIC IRQ controller structure */
> +extern struct hw_interrupt_type open_pic;
> +
> +/* OpenPIC IPI controller structure */
> +#ifdef CONFIG_SMP
> +extern struct hw_interrupt_type open_pic_ipi;
> +#endif /* CONFIG_SMP */
> +
> +extern u_int OpenPIC_NumInitSenses;
> +extern u_char *OpenPIC_InitSenses;
> +extern void __iomem * OpenPIC_Addr;
> +extern int epic_serial_mode;
> +
> +/* Exported functions */
> +extern void openpic_set_sources(int first_irq, int num_irqs, void
> __iomem *isr);
> +extern void openpic_init(int linux_irq_offset);
> +extern void openpic_init_nmi_irq(u_int irq);
> +extern void openpic_set_irq_priority(u_int irq, u_int pri);
> +extern void openpic_hookup_cascade(u_int irq, char *name,
> + int (*cascade_fn)(struct pt_regs *));
> +extern u_int openpic_irq(void);
> +extern void openpic_eoi(void);
> +extern void openpic_request_IPIs(void);
> +extern void do_openpic_setup_cpu(void);
> +extern int openpic_get_irq(struct pt_regs *regs);
> +extern void openpic_reset_processor_phys(u_int cpumask);
> +extern void openpic_setup_ISU(int isu_num, unsigned long addr);
> +extern void openpic_cause_IPI(u_int ipi, cpumask_t cpumask);
> +extern void smp_openpic_message_pass(int target, int msg);
> +extern void openpic_set_k2_cascade(int irq);
> +extern void openpic_set_priority(u_int pri);
> +extern u_int openpic_get_priority(void);
> +
> +extern inline int openpic_to_irq(int irq)
> +{
> + /* IRQ 0 usually means 'disabled'.. don't mess with it
> + * exceptions to this (sandpoint maybe?)
> + * shouldn't use openpic_to_irq
> + */
> + if (irq != 0){
> + return irq += NUM_8259_INTERRUPTS;
> + } else {
> + return 0;
> + }
> +}
> +/* Support for second openpic on G5 macs */
> +
> +// FIXME: To be replaced by sane cascaded controller management */
> +
> +#define PMAC_OPENPIC2_OFFSET 128
> +
> +#define OPENPIC2_VEC_TIMER 110 /* and up */
> +#define OPENPIC2_VEC_IPI 118 /* and up */
> +#define OPENPIC2_VEC_SPURIOUS 127
> +
> +
> +extern void* OpenPIC2_Addr;
> +
> +/* Exported functions */
> +extern void openpic2_set_sources(int first_irq, int num_irqs, void
> *isr);
> +extern void openpic2_init(int linux_irq_offset);
> +extern void openpic2_init_nmi_irq(u_int irq);
> +extern u_int openpic2_irq(void);
> +extern void openpic2_eoi(void);
> +extern int openpic2_get_irq(struct pt_regs *regs);
> +extern void openpic2_setup_ISU(int isu_num, unsigned long addr);
> +
> +#endif /* _ASM_POWERPC_OPEN_PIC_H */
> diff --git a/include/asm-ppc/open_pic.h b/include/asm-ppc/open_pic.h
> deleted file mode 100644
> index ec2f466..0000000
> --- a/include/asm-ppc/open_pic.h
> +++ /dev/null
> @@ -1,99 +0,0 @@
> -/*
> - * include/asm-ppc/open_pic.h -- OpenPIC Interrupt Handling
> - *
> - * Copyright (C) 1997 Geert Uytterhoeven
> - *
> - * This file is subject to the terms and conditions of the GNU
> General Public
> - * License. See the file COPYING in the main directory of this
> archive
> - * for more details.
> - *
> - */
> -
> -#ifndef _PPC_KERNEL_OPEN_PIC_H
> -#define _PPC_KERNEL_OPEN_PIC_H
> -
> -#include <linux/config.h>
> -#include <linux/irq.h>
> -
> -#define OPENPIC_SIZE 0x40000
> -
> -/*
> - * Non-offset'ed vector numbers
> - */
> -
> -#define OPENPIC_VEC_TIMER 110 /* and up */
> -#define OPENPIC_VEC_IPI 118 /* and up */
> -#define OPENPIC_VEC_SPURIOUS 255
> -
> -/* Priorities */
> -#define OPENPIC_PRIORITY_IPI_BASE 10
> -#define OPENPIC_PRIORITY_DEFAULT 4
> -#define OPENPIC_PRIORITY_NMI 9
> -
> -/* OpenPIC IRQ controller structure */
> -extern struct hw_interrupt_type open_pic;
> -
> -/* OpenPIC IPI controller structure */
> -#ifdef CONFIG_SMP
> -extern struct hw_interrupt_type open_pic_ipi;
> -#endif /* CONFIG_SMP */
> -
> -extern u_int OpenPIC_NumInitSenses;
> -extern u_char *OpenPIC_InitSenses;
> -extern void __iomem * OpenPIC_Addr;
> -extern int epic_serial_mode;
> -
> -/* Exported functions */
> -extern void openpic_set_sources(int first_irq, int num_irqs, void
> __iomem *isr);
> -extern void openpic_init(int linux_irq_offset);
> -extern void openpic_init_nmi_irq(u_int irq);
> -extern void openpic_set_irq_priority(u_int irq, u_int pri);
> -extern void openpic_hookup_cascade(u_int irq, char *name,
> - int (*cascade_fn)(struct pt_regs *));
> -extern u_int openpic_irq(void);
> -extern void openpic_eoi(void);
> -extern void openpic_request_IPIs(void);
> -extern void do_openpic_setup_cpu(void);
> -extern int openpic_get_irq(struct pt_regs *regs);
> -extern void openpic_reset_processor_phys(u_int cpumask);
> -extern void openpic_setup_ISU(int isu_num, unsigned long addr);
> -extern void openpic_cause_IPI(u_int ipi, cpumask_t cpumask);
> -extern void smp_openpic_message_pass(int target, int msg);
> -extern void openpic_set_k2_cascade(int irq);
> -extern void openpic_set_priority(u_int pri);
> -extern u_int openpic_get_priority(void);
> -
> -extern inline int openpic_to_irq(int irq)
> -{
> - /* IRQ 0 usually means 'disabled'.. don't mess with it
> - * exceptions to this (sandpoint maybe?)
> - * shouldn't use openpic_to_irq
> - */
> - if (irq != 0){
> - return irq += NUM_8259_INTERRUPTS;
> - } else {
> - return 0;
> - }
> -}
> -/* Support for second openpic on G5 macs */
> -
> -// FIXME: To be replaced by sane cascaded controller management */
> -
> -#define PMAC_OPENPIC2_OFFSET 128
> -
> -#define OPENPIC2_VEC_TIMER 110 /* and up */
> -#define OPENPIC2_VEC_IPI 118 /* and up */
> -#define OPENPIC2_VEC_SPURIOUS 127
> -
> -
> -extern void* OpenPIC2_Addr;
> -
> -/* Exported functions */
> -extern void openpic2_set_sources(int first_irq, int num_irqs, void
> *isr);
> -extern void openpic2_init(int linux_irq_offset);
> -extern void openpic2_init_nmi_irq(u_int irq);
> -extern u_int openpic2_irq(void);
> -extern void openpic2_eoi(void);
> -extern int openpic2_get_irq(struct pt_regs *regs);
> -extern void openpic2_setup_ISU(int isu_num, unsigned long addr);
> -#endif /* _PPC_KERNEL_OPEN_PIC_H */
> --
> 1.2.4
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] add support for XCHG instruction accessing APIC
From: Keir Fraser @ 2006-04-05 14:05 UTC (permalink / raw)
To: Boris Ostrovsky; +Cc: xen-devel
In-Reply-To: <4433CDB4.6080408@virtualiron.com>
On 5 Apr 2006, at 15:01, Boris Ostrovsky wrote:
>> In fact I'm pretty sure the locking is not needed even if we did care
>> about atomicity. You're only protecting guest accesses from other
>> guest accesses, and each VCPU has its own local APIC model, so there
>> cannot be multiple simultaneous guest accesses to a single local
>> APIC.
>
>
> My only argument in favor of using the lock would be for completeness
> of the emulation. You are
> absolutely right in that for Linux there seems to be no need to hold
> the lock. My concern is that
> other OSs may treat this differently. And if we don't have sources,
> it may be somewhat difficult
> to figure out that the atomicity (or lack of it) was the cause of a
> problem.
>
> If, however, there is a strong feeling that we don't need the lock, I
> am happy to drop it.
> I guess you are mostly unhappy about adding a new field to hvm_domain,
> not about performance
> impact?
Yes, also my second argument was that there is *no way* for two VCPUs
to conflict on a local APIC access, since LAPIC accesses are always to
the VCPU's own LAPIC. So there is no potential concurrency that needs
to be serialised, regardless of the guest OS.
-- Keir
^ permalink raw reply
* Re: [PATCH 04/15] powerpc: move asm/bootinfo.h
From: Kumar Gala @ 2006-04-05 14:05 UTC (permalink / raw)
To: sfr; +Cc: linuxppc-dev, paulus
In-Reply-To: <11442138551674-git-send-email-sfr@canb.auug.org.au>
Nack, we are using the flat dev tree so old boot methods should stay
in arch/ppc.
- k
On Apr 5, 2006, at 12:10 AM, sfr@canb.auug.org.au wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
>
> Since files in arch/powerpc now depend on asm/bootinfo.h,
> move it to include/asm-powerpc.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>
> ---
>
> include/asm-powerpc/bootinfo.h | 52 +++++++++++++++++++++++++++++
> +++++++++++
> include/asm-ppc/bootinfo.h | 52
> ----------------------------------------
> 2 files changed, 52 insertions(+), 52 deletions(-)
> create mode 100644 include/asm-powerpc/bootinfo.h
> delete mode 100644 include/asm-ppc/bootinfo.h
>
> 355987a8cf0cf4b644e83b8268a9a34cf4524ee0
> diff --git a/include/asm-powerpc/bootinfo.h b/include/asm-powerpc/
> bootinfo.h
> new file mode 100644
> index 0000000..231c534
> --- /dev/null
> +++ b/include/asm-powerpc/bootinfo.h
> @@ -0,0 +1,52 @@
> +#ifndef _ASM_POWERPC_BOOTINFO_H
> +#define _ASM_POWERPC_BOOTINFO_H
> +
> +/*
> + * Non-machine dependent bootinfo structure. Basic idea
> + * borrowed from the m68k.
> + *
> + * Copyright (C) 1999 Cort Dougan <cort@ppc.kernel.org>
> + */
> +
> +#ifdef __KERNEL__
> +
> +#include <asm/page.h>
> +
> +#if defined(CONFIG_APUS) && !defined(__BOOTER__)
> +#include <asm-m68k/bootinfo.h>
> +#else
> +
> +struct bi_record {
> + unsigned long tag; /* tag ID */
> + unsigned long size; /* size of record (in bytes) */
> + unsigned long data[0]; /* data */
> +};
> +
> +#define BI_FIRST 0x1010 /* first record - marker */
> +#define BI_LAST 0x1011 /* last record - marker */
> +#define BI_CMD_LINE 0x1012
> +#define BI_BOOTLOADER_ID 0x1013
> +#define BI_INITRD 0x1014
> +#define BI_SYSMAP 0x1015
> +#define BI_MACHTYPE 0x1016
> +#define BI_MEMSIZE 0x1017
> +#define BI_BOARD_INFO 0x1018
> +
> +extern struct bi_record *find_bootinfo(void);
> +extern void bootinfo_init(struct bi_record *rec);
> +extern void bootinfo_append(unsigned long tag, unsigned long size,
> void * data);
> +extern void parse_bootinfo(struct bi_record *rec);
> +extern unsigned long boot_mem_size;
> +
> +static inline struct bi_record *
> +bootinfo_addr(unsigned long offset)
> +{
> +
> + return (struct bi_record *)_ALIGN((offset) + (1 << 20) - 1,
> + (1 << 20));
> +}
> +#endif /* CONFIG_APUS */
> +
> +
> +#endif /* __KERNEL__ */
> +#endif /* _ASM_POWERPC_BOOTINFO_H */
> diff --git a/include/asm-ppc/bootinfo.h b/include/asm-ppc/bootinfo.h
> deleted file mode 100644
> index 93d955c..0000000
> --- a/include/asm-ppc/bootinfo.h
> +++ /dev/null
> @@ -1,52 +0,0 @@
> -/*
> - * Non-machine dependent bootinfo structure. Basic idea
> - * borrowed from the m68k.
> - *
> - * Copyright (C) 1999 Cort Dougan <cort@ppc.kernel.org>
> - */
> -
> -#ifdef __KERNEL__
> -#ifndef _PPC_BOOTINFO_H
> -#define _PPC_BOOTINFO_H
> -
> -#include <linux/config.h>
> -#include <asm/page.h>
> -
> -#if defined(CONFIG_APUS) && !defined(__BOOTER__)
> -#include <asm-m68k/bootinfo.h>
> -#else
> -
> -struct bi_record {
> - unsigned long tag; /* tag ID */
> - unsigned long size; /* size of record (in bytes) */
> - unsigned long data[0]; /* data */
> -};
> -
> -#define BI_FIRST 0x1010 /* first record - marker */
> -#define BI_LAST 0x1011 /* last record - marker */
> -#define BI_CMD_LINE 0x1012
> -#define BI_BOOTLOADER_ID 0x1013
> -#define BI_INITRD 0x1014
> -#define BI_SYSMAP 0x1015
> -#define BI_MACHTYPE 0x1016
> -#define BI_MEMSIZE 0x1017
> -#define BI_BOARD_INFO 0x1018
> -
> -extern struct bi_record *find_bootinfo(void);
> -extern void bootinfo_init(struct bi_record *rec);
> -extern void bootinfo_append(unsigned long tag, unsigned long size,
> void * data);
> -extern void parse_bootinfo(struct bi_record *rec);
> -extern unsigned long boot_mem_size;
> -
> -static inline struct bi_record *
> -bootinfo_addr(unsigned long offset)
> -{
> -
> - return (struct bi_record *)_ALIGN((offset) + (1 << 20) - 1,
> - (1 << 20));
> -}
> -#endif /* CONFIG_APUS */
> -
> -
> -#endif /* _PPC_BOOTINFO_H */
> -#endif /* __KERNEL__ */
> --
> 1.2.4
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [U-Boot-Users] [patch] Support IDE secondary disk without primary disk.
From: ito at mlb.co.jp @ 2006-04-05 14:04 UTC (permalink / raw)
To: u-boot
Hello
Current u-boot does not search disks on secondary port if there is no disks
on primary port.
this patch fixes this problem.
Signed-off-by: Hiroshi Ito <ito@mlb.co.jp>
CHANGELOG:
* Support IDE secondary disk without primary disk.
Patch by Hiroshi Ito, 5 Apr 2006
-------------- next part --------------
diff --git a/common/cmd_ide.c b/common/cmd_ide.c
index 41621ba..f37aa07 100644
--- a/common/cmd_ide.c
+++ b/common/cmd_ide.c
@@ -617,10 +617,11 @@ void ide_init (void)
if (s) ata_reset_time = 2*simple_strtol(s, NULL, 10);
#endif
i = 0;
- do {
+ for (;;) {
udelay (10000); /* 10 ms */
c = ide_inb (dev, ATA_STATUS);
+ if (!(c & ATA_STAT_BUSY)) break;
i++;
#ifdef CONFIG_AMIGAONEG3SE
if (i > (ata_reset_time * 100)) {
@@ -636,12 +637,12 @@ void ide_init (void)
goto skip_bus;
}
#endif
- return;
+ break;
}
if ((i >= 100) && ((i%100)==0)) {
putc ('.');
}
- } while (c & ATA_STAT_BUSY);
+ }
if (c & (ATA_STAT_BUSY | ATA_STAT_FAULT)) {
puts ("not available ");
^ permalink raw reply related
* Re: [PATCHl] localtime basis for paravirtualized guests
From: Keir Fraser @ 2006-04-05 14:03 UTC (permalink / raw)
To: Bruce Rogers; +Cc: Ian Pratt, xen-devel
In-Reply-To: <442D2D2D.092E.0048.1@novell.com>
On 31 Mar 2006, at 21:22, Bruce Rogers wrote:
> This patch allows the localtime parameter to be used for
> para-virtualized guests.
> Some paravirtualized guests may need to start with a local time basis
> instead of UTC.
> This patch provides for that need. Please review and apply.
I've just checked in a patch to provide a clean wallclock update
interface from common Xen code. Please re-send based on that patch.
Your dom0_op implementation should modify d->time_offset_seconds
directly and then call update_domain_wallclock_time(d).
Apart from that, the time_offset_seconds field in dom0_op.h should be
type int32_t (we don't use s32 in public headers).
-- Keir
^ permalink raw reply
* Re: VMX status report 9532:5baf152d63ef
From: Dave Feustel @ 2006-04-05 14:03 UTC (permalink / raw)
To: xen-devel; +Cc: Shi, Alex
In-Reply-To: <97482BF90993634BAE7D886C5B89B5ED887685@pdsmsx403>
On Wednesday 05 April 2006 07:42, Shi, Alex wrote:
> We have tested the latest xen on VT platform with Intel 915/E8500
> chipset.Here is the test summary.
Are any status reports for testing xen on AMD Pacifica being published yet?
Thanks,
Dave Feustel
--
Lose, v., experience a loss, get rid of, "lose the weight"
Loose, adj., not tight, let go, free, "loose clothing"
^ permalink raw reply
* Huge impact of the conntrack mechanism on routing performance (30% with a single conntrack entry)
From: Eddy Kvetny @ 2006-04-05 14:03 UTC (permalink / raw)
To: netfilter-devel, netfilter
Netfilter gurus,
Could someone shed light on pretty strange problem of
a huge impact of the conntrack mechanism on routing
performance ?
The configuration is as follows:
- the ARM9E-based (500Mhz) board with Linux 2.6.12
- 2 GbE interfaces connected to the traffic generator
tool (Smartbit)
- Smartbit injects UDP packets to the device via 1st
network interface, then the devices routes these
packets back to Smartbit via the 2nd interface
When only plain routing without any netfilter stuff
(conntrack, NAT, filter modules) is done, 40K packets
per second are processed and returned to Smartbit
giving about 485Mbps througput (40000 packets x 8 bit
x 1518 byte/packet)
Right after "insmod ip_conntrack.ko" the throughput
drastically falls to 28 kpps (-12 kpps or -30% !!!). I
know that "conntrack" mechanism has some overhead but
30% is still seems to be too much, especially when in
my case there is only 1 connection in the conntrack
table and as far as I know most of the "conntrack"
processing is done for the 1st packet of each
connection only. Then this connection is put in the
"conntrack" hash table and it is supposed to be very
quickly found for successive packets belonging to the
same connection
After "insmod iptable_filter.ko" throughput is 25
kpps (-3 kpps) and after "insmod iptable_nat.ko" (NAT
mechanism) throughput is 23 kpps (-2 kpps). Insertion
of additional modules (like ipt_state.ko,
ip_conntrack_ftp.ko etc.) and configuring rules for
firewall/NAT (not talking about hundreds or more
rules) has no significant impact on throughput
So, I am wondering whether there is some logic
explanation for this huge impact of the conntrack
mechanism on routing performance.
I would appreciate any information in this regard
Thanks in advance
Eddy
P.S. I found a couple of similar observations in
Internet
>From http://lwn.net/Articles/103858/
.......
13.3. Netfilter benchmarking by HW
.....
Lose 30% of performance (850kpps to 500kpps)
...
Initial rate (forwarding only) 800kpps
insmod ip_conntrack -200 kpps
load IPtable (even empty) 25%
oprofile (non-halted) everything in ip_tables (3%)
static compiling makes 5% difference
full test (nat, mangle, filter, ip_conntrack): down to
350kpps
....................
================================================
>From http://lkml.org/lkml/2004/9/8/235
.................................................
I'm sure others here have far better examples, but one
post to the netfilter-devel list last December
provided an example of a firewall that
could process 580kpps with netfilter/conntrack turned
off. Granted, the post noted that adding netfilter
brought that down to 450kpps, and adding conntrack on
top of that brought it down to 295kpps,but all three
of those numbers are well over the claimed 100kpps.
..................................................
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Huge impact of the conntrack mechanism on routing performance (30% with a single conntrack entry)
From: Eddy Kvetny @ 2006-04-05 14:03 UTC (permalink / raw)
To: netfilter-devel, netfilter
Netfilter gurus,
Could someone shed light on pretty strange problem of
a huge impact of the conntrack mechanism on routing
performance ?
The configuration is as follows:
- the ARM9E-based (500Mhz) board with Linux 2.6.12
- 2 GbE interfaces connected to the traffic generator
tool (Smartbit)
- Smartbit injects UDP packets to the device via 1st
network interface, then the devices routes these
packets back to Smartbit via the 2nd interface
When only plain routing without any netfilter stuff
(conntrack, NAT, filter modules) is done, 40K packets
per second are processed and returned to Smartbit
giving about 485Mbps througput (40000 packets x 8 bit
x 1518 byte/packet)
Right after "insmod ip_conntrack.ko" the throughput
drastically falls to 28 kpps (-12 kpps or -30% !!!). I
know that "conntrack" mechanism has some overhead but
30% is still seems to be too much, especially when in
my case there is only 1 connection in the conntrack
table and as far as I know most of the "conntrack"
processing is done for the 1st packet of each
connection only. Then this connection is put in the
"conntrack" hash table and it is supposed to be very
quickly found for successive packets belonging to the
same connection
After "insmod iptable_filter.ko" throughput is 25
kpps (-3 kpps) and after "insmod iptable_nat.ko" (NAT
mechanism) throughput is 23 kpps (-2 kpps). Insertion
of additional modules (like ipt_state.ko,
ip_conntrack_ftp.ko etc.) and configuring rules for
firewall/NAT (not talking about hundreds or more
rules) has no significant impact on throughput
So, I am wondering whether there is some logic
explanation for this huge impact of the conntrack
mechanism on routing performance.
I would appreciate any information in this regard
Thanks in advance
Eddy
P.S. I found a couple of similar observations in
Internet
From http://lwn.net/Articles/103858/
.......
13.3. Netfilter benchmarking by HW
.....
Lose 30% of performance (850kpps to 500kpps)
...
Initial rate (forwarding only) 800kpps
insmod ip_conntrack -200 kpps
load IPtable (even empty) 25%
oprofile (non-halted) everything in ip_tables (3%)
static compiling makes 5% difference
full test (nat, mangle, filter, ip_conntrack): down to
350kpps
....................
================================================
From http://lkml.org/lkml/2004/9/8/235
.................................................
I'm sure others here have far better examples, but one
post to the netfilter-devel list last December
provided an example of a firewall that
could process 580kpps with netfilter/conntrack turned
off. Granted, the post noted that adding netfilter
brought that down to 450kpps, and adding conntrack on
top of that brought it down to 295kpps,but all three
of those numbers are well over the claimed 100kpps.
..................................................
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH] add support for XCHG instruction accessing APIC
From: Boris Ostrovsky @ 2006-04-05 14:01 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel
In-Reply-To: <93eed1ff132a9eaf49f74dd3c8d57f5b@cl.cam.ac.uk>
Keir Fraser wrote:
>
> On 5 Apr 2006, at 10:50, Keir Fraser wrote:
>
>>> 32-bit SMP Linux uses xchg instruction to access APIC (see
>>> apic_write_atomic()). Attached is patch that adds support for
>>> this instruction.
>>>
>>> The patch also fixes missed dependencies (in xen/Rules.mk) on
>>> header files in include/asm-x86/hvm.
>>
>>
>> I wonder if it is worth adding the locking? xchg is only used to
>> write to broken APICs -- the OS does not care about the returned
>> value. The APIC is implemented entirely in Xen, so the lock isn't
>> held across an ioreq round-trip to qemu-dm, right?
>
Yes, that's right --- we never leave Xen to handle APIC access.
> In fact I'm pretty sure the locking is not needed even if we did care
> about atomicity. You're only protecting guest accesses from other
> guest accesses, and each VCPU has its own local APIC model, so there
> cannot be multiple simultaneous guest accesses to a single local APIC.
My only argument in favor of using the lock would be for completeness of
the emulation. You are
absolutely right in that for Linux there seems to be no need to hold the
lock. My concern is that
other OSs may treat this differently. And if we don't have sources, it
may be somewhat difficult
to figure out that the atomicity (or lack of it) was the cause of a
problem.
If, however, there is a strong feeling that we don't need the lock, I am
happy to drop it.
I guess you are mostly unhappy about adding a new field to hvm_domain,
not about performance
impact?
-boris
^ permalink raw reply
* Re: p4-clockmod not working in 2.6.16
From: Mike Galbraith @ 2006-04-05 13:59 UTC (permalink / raw)
To: Tim Phipps; +Cc: linux-kernel, Edgar Toernig, Dave Jones
In-Reply-To: <1144245205.7571.11.camel@homer>
On Wed, 2006-04-05 at 13:02 +0100, Tim Phipps wrote:
> On Tuesday 04 Apr 2006 11:47, Tim Phipps wrote:
> > On Wed, 2006-03-22 at 06:20, Mike Galbraith wrote:
> > > On Wed, 2006-03-22 at 06:57 +0100, Edgar Toernig wrote:
> > > > | N60. Processor May Hang under Certain Frequencies and 12.5%
> > > > | STPCLK# Duty Cycle
> > > > |
> > > > | Problem: If a system de-asserts STPCLK# at a 12.5% duty cycle,
> > > > | the processor is running below 2 GHz, and the processor thermal
> > > > | control circuit (TCC) on-demand clock modulation is active, the
> > > > | processor may hang. This erratum does not occur under the automatic
> > > > | mode of the TCC.
> >
> Here's a patch to 2.6.17-rc1 that disables the 12.5% DC on any CPU that has
> N60. The frequencies in the errata are a bit vague so this is the safe bet
> and it only disables one of the eight frequencies rather than the current
> behaviour which disables all of mine!
Works for me. Perhaps you should update...
dprintk("has errata -- disabling frequencies lower than 2ghz\n");
...,slap a Signed-off-by: on it and see if it flys.
-Mike
P.S. server can't find computer.systems.pipex.net: NXDOMAIN
^ permalink raw reply
* [PATCH 4/8] libata: separate out sil24_poll_register()
From: Tejun Heo @ 2006-04-05 13:29 UTC (permalink / raw)
To: jgarzik, Carlos.Pardo, linux-ide; +Cc: Tejun Heo
In-Reply-To: <11442437413563-git-send-email-htejun@gmail.com>
This will be used by later patches.
Signed-off-by: Tejun Heo <htejun@gmail.com>
---
drivers/scsi/sata_sil24.c | 34 +++++++++++++++++++++++-----------
1 files changed, 23 insertions(+), 11 deletions(-)
dbf21a7fbc3fe926671416fecebfea70aef78c8a
diff --git a/drivers/scsi/sata_sil24.c b/drivers/scsi/sata_sil24.c
index 86233ac..0941f74 100644
--- a/drivers/scsi/sata_sil24.c
+++ b/drivers/scsi/sata_sil24.c
@@ -431,6 +431,24 @@ static void sil24_tf_read(struct ata_por
*tf = pp->tf;
}
+static int sil24_poll_register(void __iomem *reg, u32 mask, u32 val,
+ unsigned long interval_msec,
+ unsigned long timeout_msec)
+{
+ unsigned long timeout;
+ u32 tmp;
+
+ timeout = jiffies + (timeout_msec * HZ) / 1000;
+ do {
+ tmp = readl(reg);
+ if ((tmp & mask) == val)
+ return 0;
+ msleep(interval_msec);
+ } while (time_before(jiffies, timeout));
+
+ return -1;
+}
+
static int sil24_softreset(struct ata_port *ap, unsigned int *class)
{
void __iomem *port = (void __iomem *)ap->ioaddr.cmd_addr;
@@ -949,13 +967,12 @@ static int sil24_init_one(struct pci_dev
probe_ent->host_flags &= ~SIL24_FLAG_PCIX_IRQ_WOC;
}
- /* Mask interrupts during initialization */
+ /* Clear global reset & mask interrupts during initialization */
writel(0, host_base + HOST_CTRL);
for (i = 0; i < probe_ent->n_ports; i++) {
void __iomem *port = port_base + i * PORT_REGS_SIZE;
unsigned long portu = (unsigned long)port;
- int cnt;
probe_ent->port[i].cmd_addr = portu + PORT_PRB;
probe_ent->port[i].scr_addr = portu + PORT_SCONTROL;
@@ -975,16 +992,11 @@ static int sil24_init_one(struct pci_dev
tmp = readl(port + PORT_CTRL_STAT);
if (tmp & PORT_CS_PORT_RST) {
writel(PORT_CS_PORT_RST, port + PORT_CTRL_CLR);
- readl(port + PORT_CTRL_STAT); /* sync */
- for (cnt = 0; cnt < 10; cnt++) {
- msleep(10);
- tmp = readl(port + PORT_CTRL_STAT);
- if (!(tmp & PORT_CS_PORT_RST))
- break;
- }
- if (tmp & PORT_CS_PORT_RST)
+ if (sil24_poll_register(port + PORT_CTRL_STAT,
+ PORT_CS_PORT_RST, 0, 10, 100))
dev_printk(KERN_ERR, &pdev->dev,
- "failed to clear port RST\n");
+ "failed to clear RST for port %d\n",
+ i);
}
/* Zero error counters. */
--
1.2.4
^ permalink raw reply related
* Re: VMX status report 9532:5baf152d63ef
From: Mark Williamson @ 2006-04-05 13:59 UTC (permalink / raw)
To: xen-devel
In-Reply-To: <200604050903.07180.dfeustel@mindspring.com>
> On Wednesday 05 April 2006 07:42, Shi, Alex wrote:
> > We have tested the latest xen on VT platform with Intel 915/E8500
> > chipset.Here is the test summary.
>
> Are any status reports for testing xen on AMD Pacifica being published
> yet?
Yes, IBM publish them for Linux and Windows XP guests (with other Windows OSes
to follow once the tests are automated. I forget who's responsible, though,
sorry.
HTH,
Mark
--
Dave: Just a question. What use is a unicyle with no seat? And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!
^ permalink raw reply
* Re: [PATCH 0/3] [RFC] fixed duration connection
From: Patrick McHardy @ 2006-04-05 13:57 UTC (permalink / raw)
To: Eric Leblond; +Cc: Netfilter Development Mailinglist, nufw-devel
In-Reply-To: <1144139619.5186.24.camel@localhost.localdomain>
Eric Leblond wrote:
> Hi,
>
> While working on NuFW development branch, we have had to
> implement policy just as :
> * connection to server is authorised from 08h to 18h and
> connection must be switched off at 18h.
>
> Such features are frequently asked by customers or netfilter addicts but
> even with current conntrack related code, it can not be done cleanly.
>
> Thus, we've added the notion of fixed duration before expiration to
> connection in the conntrack. (See extended information on bottom for
> details)
>
> The following set of patches is against kernel (linus git tree),
> libnetfilter_conntrack, and conntrack tool.
>
> -- Extended --
>
> When trying to implement this feature with current connection tracking
> code, we have faced some issues :
> 1. userspace code has to duplicate conntrack entries, thus it's
> complex and uses memory
> 2. there is no hope to have it done by a simple command line
> (because of 1.)
> 3. if replication of conntrack in userspace is needed there will be
> many synchronisation problems : stop and start of an
> hypothetical "expiration" daemon would cause conntrack
> duplication and/or loss of information ...
>
> For this reason, we've worked on a simple kernel level implementation.
> This is done via a second "struct timer" that is added in connection
> structure. Activation of the timer, is for now done via userspace by
> using libnetfilter_conntrack or by using new option -T of the conntrack
> tool.
If I understand you correctly, a fixed timeout is just a timeout that
isn't refreshed, right? Why can't we just use the regular timers etc.
and add a flag that it should not be touched by ip_ct_refresh? This
would also eliminate the need for any ctnetlink changes since the
timeout value can already be specified.
^ permalink raw reply
* Re: [-mm patch] drivers/media/video/bt866.c: small fixes
From: Martin Samuelsson @ 2006-04-05 13:54 UTC (permalink / raw)
To: Johannes Stezenbach; +Cc: bunk, akpm, linux-kernel, mchehab, v4l-dvb-maintainer
In-Reply-To: <20060405083204.GA5058@linuxtv.org>
On Wed, 5 Apr 2006 10:32:04 +0200
Johannes Stezenbach <js@linuxtv.org> wrote:
> On Tue, Apr 04, 2006, Martin Samuelsson wrote:
> > current->state = TASK_INTERRUPTIBLE;
> > - schedule_timeout(HZ/10);
> > + schedule_timeout_interruptible(HZ/10);
>
> schedule_timeout_interruptible() already sets current->state.
I have much to learn, it seems. I'll trim that off, too. Thanks!
Regards,
/Sam
^ permalink raw reply
* Re: patch bus_add_device-losing-an-error-return-from-the-probe-method.patch added to gregkh-2.6 tree
From: Rene Herman @ 2006-04-05 13:55 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Greg KH, alsa-devel, linux-kernel, tiwai, Andrew Morton,
Russell King
In-Reply-To: <200604042148.57286.dtor_core@ameritech.net>
[-- Attachment #1: Type: text/plain, Size: 4596 bytes --]
Dmitry Torokhov wrote:
[ crap, attached the wrong patch, this time with correct attachment ]
> On Tuesday 04 April 2006 18:12, Rene Herman wrote:
>> To Dmitry, I see you saying "probe() failing is driver's problem.
>> The device is still there and should still be presented in sysfs.".
>> No, at least in the case of these platform drivers (or at least
>> these old ISA cards using the platform driver interface), a -ENODEV
>> return from the probe() method would mean the device is _not_
>> present (or not found at least). NODEV.
>
> Or you could separate device probing code from driver->probe(). BTW I
> think that ->probe() is not the best name for that method.
Right...
> It really is supposed to allocate resources and initialize the device
> so that it is ready to be used, not to verify that device is present.
> The code that created device shoudl've done that.
How do you feel about the flag that I've been proposing that a driver
that needs to probe for its hardware could set and that says "if we
return an error (or specifically -ENODEV I guess) the hardware's
reallyreally not present and the device should not register"?
Greg, and how do you feel about such a flag?
As an alternative to the flag, how would either of you feel about either
1) adding a .discover method to struct device_driver that noone other
than drivers for this old non generically discoverable hardware would
set but which would make a registration fail if set and returning < 0?
2) adding that method only to platform_driver?
3) ... and after a few months when people aren't paying attention
anymore rename .probe to .init and .discover back to .probe? ;-)
Russel, you wrote:
> Note also that this patch will not do what the ALSA folk want - they
> want to know if the device was found or whether the probe returned
> -ENODEV. We knock -ENODEV and -ENXIO to zero in
> driver_probe_device(), so they won't even see that.
Yes, I know about the -ENODEV / -ENXIO thing. I asked for comment on
that as well, but haven't gotten any.
Anyways, the additional method would, I feel, be the conceptually
cleanest approach. Practically speaking though, simply doing a manual
probe and only calling platform_register() after everything is found to
be present and accounted for is not much of a problem either.
Takashi, how would you feel about a setup for ALSA going like:
static struct platform_device *devices[SNDRV_CARDS];
static int __devinit snd_foo_probe(int i)
{
struct snd_card *card;
if (port[i] == SNDRV_AUTO_PORT) {
snd_printk(KERN_ERR "specify port\n");
return -EINVAL;
}
card = snd_card_new(index[i], id[i], THIS_MODULE, 0);
if (!card) {
snd_printk(KERN_ERR "could not create card\n");
return -EWHATEVER;
}
/* all the other things the probe method does */
if (snd_card_register(card) < 0) {
snd_printk(KERN_ERR "could not register card\n");
return -EWHATEVERSNDCARDREGISTERRETURNED;
}
devices[i] = platform_device_register_simple(NAME, i, NULL, 0);
if (IS_ERR(devices[i])) {
snd_printk(KERN_ERR "could not register device\n");
snd_card_free(card);
return PTR_ERR(devices[i]);
}
platform_set_drvdata(devices[i], card);
return 0;
}
Then deleting the .probe method from the foo_platform_driver struct and
in the module init simply do a manual probe, using:
if (platform_driver_register(&snd_foo_driver) < 0) {
snd_printk(KERN_ERR "could not register driver\n");
return -EARGHH;
}
for (cards = 0, i = 0; i < SNDRV_CARDS; i++)
if (enable[i] && snd_foo_probe(i) >= 0)
cards++
if (!cards) {
printk(KERN_ER "foo not found or device busy\n");
platform_driver_unregister(&snd_foo_driver);
return -ENODEV;
}
Also attached as a patch against adlib.c (it's the simplest driver by
far, so using that one as an example. it's present in 2.6.17-rc1).
The platform_device registration could also stay in the init loop, but
since we want the free the card again if it fails same as with all the
other failures it's best off at the end of probe() I feel. You
introduced all these nonpnp_probe() methods for platform devices so we
do have a nice place to put this...
Would you feel this would be an okay setup, assuming we're not getting
that .discover method?
Rene.
[-- Attachment #2: adlib-manual-probe.diff --]
[-- Type: text/plain, Size: 2284 bytes --]
Index: local/sound/isa/adlib.c
===================================================================
--- local.orig/sound/isa/adlib.c 2006-04-05 13:41:27.000000000 +0200
+++ local/sound/isa/adlib.c 2006-04-05 14:31:32.000000000 +0200
@@ -38,13 +38,12 @@ static void snd_adlib_free(struct snd_ca
release_and_free_resource(card->private_data);
}
-static int __devinit snd_adlib_probe(struct platform_device *device)
+static int __devinit snd_adlib_probe(int i)
{
struct snd_card *card;
struct snd_opl3 *opl3;
int error;
- int i = device->id;
if (port[i] == SNDRV_AUTO_PORT) {
snd_printk(KERN_ERR DRV_NAME ": please specify port\n");
@@ -91,12 +90,18 @@ static int __devinit snd_adlib_probe(str
goto out1;
}
- platform_set_drvdata(device, card);
+ devices[i] = platform_device_register_simple(DRV_NAME, i, NULL, 0);
+ if (IS_ERR(devices[i])) {
+ snd_printk(KERN_ERR DRV_NAME ": could not register device\n");
+ error = PTR_ERR(devices[i]);
+ goto out1;
+ }
+
+ platform_set_drvdata(devices[i], card);
return 0;
out1: snd_card_free(card);
- out0: error = -EINVAL; /* FIXME: should be the original error code */
- return error;
+out0: return error;
}
static int __devexit snd_adlib_remove(struct platform_device *device)
@@ -107,9 +112,7 @@ static int __devexit snd_adlib_remove(st
}
static struct platform_driver snd_adlib_driver = {
- .probe = snd_adlib_probe,
.remove = __devexit_p(snd_adlib_remove),
-
.driver = {
.name = DRV_NAME
}
@@ -117,26 +120,17 @@ static struct platform_driver snd_adlib_
static int __init alsa_card_adlib_init(void)
{
- int i, cards;
+ int error, cards, i;
- if (platform_driver_register(&snd_adlib_driver) < 0) {
+ error = platform_driver_register(&snd_adlib_driver);
+ if (error < 0) {
snd_printk(KERN_ERR DRV_NAME ": could not register driver\n");
- return -ENODEV;
+ return error;
}
- for (cards = 0, i = 0; i < SNDRV_CARDS; i++) {
- struct platform_device *device;
-
- if (!enable[i])
- continue;
-
- device = platform_device_register_simple(DRV_NAME, i, NULL, 0);
- if (IS_ERR(device))
- continue;
-
- devices[i] = device;
- cards++;
- }
+ for (cards = 0, i = 0; i < SNDRV_CARDS; i++)
+ if (enable[i] && snd_adlib_probe(i) >= 0)
+ cards++
if (!cards) {
#ifdef MODULE
^ permalink raw reply
* PATCH: [Fwd: PROBLEM: Kernel 2.6.16 fails to boot on API CS20]
From: Brian Uhrain @ 2006-04-05 13:54 UTC (permalink / raw)
To: linux-kernel; +Cc: rth, Alan Cox
[-- Attachment #1: Type: text/plain, Size: 831 bytes --]
Hi,
About two weeks ago I sent Richard Henderson the attached email
detailing a problem with the 2.6.16 kernel booting on my dual processor
Alpha system. Today I was able to track down the problem to the call to
topology_cpu_callback() in drivers/base/topology.c--specifically, in
that function the call to get_cpu_sysdev() is returning NULL. I have
tracked down the reason and created a small patch that solves the
problem on my system. Basically for the Alpha architecture,
register_cpu is never being called, so get_cpu_sysdev() has nothing to
return. Using ppc_init() in arch/ppc/kernel/setup.c, I created a
similiar function for the Alpha architecture that just registers the CPU
devices. Attached are two versions of the patch: one against 2.6.16.1
and the other against 2.6.17-rc1.
Regards,
Brian Uhrain
[-- Attachment #2: alpha-cpu-fix-2.6.16.1.patch --]
[-- Type: text/plain, Size: 766 bytes --]
--- linux-2.6.16.1/arch/alpha/kernel/setup.c.old 2006-04-05 13:01:38.585051580 +0100
+++ linux-2.6.16.1/arch/alpha/kernel/setup.c 2006-04-05 13:02:24.412099456 +0100
@@ -24,6 +24,7 @@
#include <linux/config.h> /* CONFIG_ALPHA_LCA etc */
#include <linux/mc146818rtc.h>
#include <linux/console.h>
+#include <linux/cpu.h>
#include <linux/errno.h>
#include <linux/init.h>
#include <linux/string.h>
@@ -477,6 +478,22 @@
#undef PFN_PHYS
#undef PFN_MAX
+static struct cpu cpu_devices[NR_CPUS];
+
+int __init alpha_init(void)
+{
+ int i;
+
+ /* register CPU devices */
+ for (i = 0; i < NR_CPUS; i++)
+ if (cpu_possible(i))
+ register_cpu(&cpu_devices[i], i, NULL);
+
+ return 0;
+}
+
+arch_initcall(alpha_init);
+
void __init
setup_arch(char **cmdline_p)
{
[-- Attachment #3: alpha-cpu-fix-2.6.17-rc1.patch --]
[-- Type: text/plain, Size: 722 bytes --]
--- linux-2.6.17-rc1/arch/alpha/kernel/setup.c.old 2006-04-05 12:52:25.636715545 +0100
+++ linux-2.6.17-rc1/arch/alpha/kernel/setup.c 2006-04-05 12:53:01.645504167 +0100
@@ -24,6 +24,7 @@
#include <linux/config.h> /* CONFIG_ALPHA_LCA etc */
#include <linux/mc146818rtc.h>
#include <linux/console.h>
+#include <linux/cpu.h>
#include <linux/errno.h>
#include <linux/init.h>
#include <linux/string.h>
@@ -471,6 +472,21 @@
return 0;
}
+static struct cpu cpu_devices[NR_CPUS];
+
+int __init alpha_init(void)
+{
+ int i;
+
+ /* register CPU devices */
+ for_each_possible_cpu(i)
+ register_cpu(&cpu_devices[i], i, NULL);
+
+ return 0;
+}
+
+arch_initcall(alpha_init);
+
void __init
setup_arch(char **cmdline_p)
{
[-- Attachment #4: PROBLEM: Kernel 2.6.16 fails to boot on API CS20 --]
[-- Type: message/rfc822, Size: 20809 bytes --]
[-- Attachment #4.1.1: Type: text/plain, Size: 3018 bytes --]
Hi,
When trying to boot a 2.6.16 kernel (kernel.org sources with the only
patch being for Reiser4 FS support), the kernel dies on bootup on my
dual-processor Alpha system, with the error "Unable to handle kernel
paging request at virtual address 0000000000000058". The system is an
API CS20 with 2 833MHz 21264b processors and 1 GB of RAM (8 x 128 MB). I
have attached all of the output from the serial console, including the
error message, along with a gzipped version of the .config used to
compile the kernel and the output of "lspci -vvv". Looking at the
kernel output prior to the kernel panic, I noticed it only activated one
processor even though it probed two.
Here is the output of the ver_linux script:
mantheren:/usr/src/linux-2.6.16# sh ./scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux mantheren 2.6.15.6-mantheren #1 SMP Tue Mar 7 09:03:30 GMT 2006
alpha unknown unknown GNU/Linux
Gnu C 4.1.0
Gnu make 3.80
binutils 2.16.91.0.7
util-linux 2.13-pre7
mount 2.13-pre7
module-init-tools 3.3-pre1
e2fsprogs 1.38
reiserfsprogs 3.6.19
reiser4progs 1.0.5
xfsprogs 2.7.3
Linux C Library 2.3.6
Dynamic linker (ldd) 2.3.6
Procps 3.2.6
Net-tools 1.60
Kbd 83:
Sh-utils 5.2.1
udev 087
Modules Loaded alim15x3 snd_usb_audio sg snd_pcm snd_timer
snd_page_alloc generic snd_usb_lib snd_rawmidi snd_hwdep snd sr_mod
cdrom ide_core soundcore e100 mii i2c_ali1535 i2c_ali15x3 zd1211 i2c_dev
i2c_core
And of /proc/cpuinfo:
cpu : Alpha
cpu model : EV68AL
cpu variation : 7
cpu revision : 0
cpu serial number :
system type : Tsunami
system variation : Clipper
system revision : 0
system serial number :
cycle frequency [Hz] : 833333333
timer frequency [Hz] : 1024.00
page size [bytes] : 8192
phys. address bits : 44
max. addr. space # : 255
BogoMIPS : 1657.40
kernel unaligned acc : 963348 (pc=fffffc0000447340,va=fffffc003f8ddff2)
user unaligned acc : 0 (pc=0,va=0)
platform string : API CS20D 833 MHz
cpus detected : 2
cpus active : 2
cpu active mask : 0000000000000003
L1 Icache : 64K, 2-way, 64b line
L1 Dcache : 64K, 2-way, 64b line
L2 cache : 4096K, 1-way, 64b line
L3 cache : n/a
If you need any other information or would like me to test anything,
please let me know.
Regards,
Brian Uhrain
P.S. The system is running a home-brew "distro" with everything
compiled from scratch, and running a 2.6.15.6 kernel it has not given
any problems even through recompiles of all of the installed software
(glibc through firefox).
[-- Attachment #4.1.2: alpha-crash.txt --]
[-- Type: text/plain, Size: 3589 bytes --]
aboot> 2
aboot: loading compressed vmlinux-custom.gz...
aboot: zero-filling 132648 bytes at 0xfffffc0000764710
aboot: starting kernel vmlinux-custom.gz with arguments root=/dev/sda2 console=ttyS0 console=tty0
Linux version 2.6.16-mantheren (root@mantheren) (gcc version 4.1.0) #1 SMP Mon Mar 20 23:11:35 GMT 6
Booting on Tsunami variation Clipper using machine vector Clipper from SRM
Major Options: SMP EV67 LEGACY_START VERBOSE_MCHECK MAGIC_SYSRQ
Command line: root=/dev/sda2 console=ttyS0 console=tty0
memcluster 0, usage 1, start 0, end 256
memcluster 1, usage 0, start 256, end 130981
memcluster 2, usage 1, start 130981, end 131072
freeing pages 256:384
freeing pages 965:130981
reserving pages 965:967
4096K Bcache detected; load hit latency 18 cycles, load miss latency 164 cycles
SMP: 2 CPUs probed -- cpu_present_mask = 1
Built 1 zonelists
Kernel command line: root=/dev/sda2 console=ttyS0 console=tty0
PID hash table entries: 4096 (order: 12, 131072 bytes)
Using epoch = 2000
Console: colour VGA+ 80x25
Dentry cache hash table entries: 262144 (order: 8, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 7, 1048576 bytes)
Memory: 1027944k/1047848k available (3258k kernel code, 17200k reserved, 395k data, 144k init)
Mount-cache hash table entries: 512
SMP starting up secondaries.
Brought up 1 CPUs
SMP: Total of 1 processors activated (1646.17 BogoMIPS).
migration_cost=0
NET: Registered protocol family 16
PCI quirk: region 7e20-7e3f claimed by ali7101 SMB
Linux Plug and Play Support v0.97 (c) Adam Belay
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
TC classifier action (bugs to netdev@vger.kernel.org cc hadi@cyberus.ca)
srm_env: version 0.0.5 loaded successfully
Loading Reiser4. See www.namesys.com for a description of Reiser4.
SGI XFS with large block/inode numbers, no debug enabled
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Activating ISA DMA hang workarounds.
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
rtc: SRM (post-2000) epoch (2000) detected
Real Time Clock Driver v1.12ac
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Unable to handle kernel paging request at virtual address 0000000000000058
CPU 0 swapper(1): Oops 0
pc = [<fffffc00003cdbb8>] ra = [<fffffc00006ee128>] ps = 0000 Not tainted
pc is at sysfs_create_group+0x28/0x160
ra is at topology_cpu_callback+0x68/0xc0
v0 = 0000000000000000 t0 = 0000000000000000 t1 = 0000000000000001
t2 = 0000000000000001 t3 = fffffc003fd73170 t4 = fffffc003fd730c8
t5 = fffffc003fd730c8 t6 = 0000000000000002 t7 = fffffc0000244000
s0 = 0000000000000001 s1 = fffffc0000764828 s2 = fffffc0000722b00
s3 = fffffc000071f048 s4 = fffffc00006f4fb8 s5 = fffffc0000652b00
s6 = fffffc0000652b00
a0 = 0000000000000010 a1 = fffffc000071f048 a2 = 0000000000000000
a3 = 0000000000008080 a4 = 0000000000000004 a5 = 0000000000000000
t8 = 0000000000000001 t9 = fffffc000063c2a0 t10= fffffc00006f70c0
t11= 0000000000000004 pv = fffffc00003cdb90 at = 0000000000000000
gp = fffffc0000762b00 sp = fffffc0000247df8
Trace:
[<fffffc00003102b8>] init+0x198/0x5c0
[<fffffc0000311868>] kernel_thread+0x28/0x90
Code: b75e0000 47f1040c b53e0008 b55e0010 b57e0018 e6000043 <a4300048> e4200041
Kernel panic - not syncing: Attempted to kill init!
[-- Attachment #4.1.3: config.gz --]
[-- Type: application/gzip, Size: 8348 bytes --]
[-- Attachment #4.1.4: pci-devs.txt.gz --]
[-- Type: application/gzip, Size: 1300 bytes --]
^ permalink raw reply
* Re: patch bus_add_device-losing-an-error-return-from-the-probe-method.patch added to gregkh-2.6 tree
From: Rene Herman @ 2006-04-05 13:55 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Greg KH, alsa-devel, linux-kernel, tiwai, Andrew Morton,
Russell King
In-Reply-To: <200604042148.57286.dtor_core@ameritech.net>
[-- Attachment #1: Type: text/plain, Size: 4596 bytes --]
Dmitry Torokhov wrote:
[ crap, attached the wrong patch, this time with correct attachment ]
> On Tuesday 04 April 2006 18:12, Rene Herman wrote:
>> To Dmitry, I see you saying "probe() failing is driver's problem.
>> The device is still there and should still be presented in sysfs.".
>> No, at least in the case of these platform drivers (or at least
>> these old ISA cards using the platform driver interface), a -ENODEV
>> return from the probe() method would mean the device is _not_
>> present (or not found at least). NODEV.
>
> Or you could separate device probing code from driver->probe(). BTW I
> think that ->probe() is not the best name for that method.
Right...
> It really is supposed to allocate resources and initialize the device
> so that it is ready to be used, not to verify that device is present.
> The code that created device shoudl've done that.
How do you feel about the flag that I've been proposing that a driver
that needs to probe for its hardware could set and that says "if we
return an error (or specifically -ENODEV I guess) the hardware's
reallyreally not present and the device should not register"?
Greg, and how do you feel about such a flag?
As an alternative to the flag, how would either of you feel about either
1) adding a .discover method to struct device_driver that noone other
than drivers for this old non generically discoverable hardware would
set but which would make a registration fail if set and returning < 0?
2) adding that method only to platform_driver?
3) ... and after a few months when people aren't paying attention
anymore rename .probe to .init and .discover back to .probe? ;-)
Russel, you wrote:
> Note also that this patch will not do what the ALSA folk want - they
> want to know if the device was found or whether the probe returned
> -ENODEV. We knock -ENODEV and -ENXIO to zero in
> driver_probe_device(), so they won't even see that.
Yes, I know about the -ENODEV / -ENXIO thing. I asked for comment on
that as well, but haven't gotten any.
Anyways, the additional method would, I feel, be the conceptually
cleanest approach. Practically speaking though, simply doing a manual
probe and only calling platform_register() after everything is found to
be present and accounted for is not much of a problem either.
Takashi, how would you feel about a setup for ALSA going like:
static struct platform_device *devices[SNDRV_CARDS];
static int __devinit snd_foo_probe(int i)
{
struct snd_card *card;
if (port[i] == SNDRV_AUTO_PORT) {
snd_printk(KERN_ERR "specify port\n");
return -EINVAL;
}
card = snd_card_new(index[i], id[i], THIS_MODULE, 0);
if (!card) {
snd_printk(KERN_ERR "could not create card\n");
return -EWHATEVER;
}
/* all the other things the probe method does */
if (snd_card_register(card) < 0) {
snd_printk(KERN_ERR "could not register card\n");
return -EWHATEVERSNDCARDREGISTERRETURNED;
}
devices[i] = platform_device_register_simple(NAME, i, NULL, 0);
if (IS_ERR(devices[i])) {
snd_printk(KERN_ERR "could not register device\n");
snd_card_free(card);
return PTR_ERR(devices[i]);
}
platform_set_drvdata(devices[i], card);
return 0;
}
Then deleting the .probe method from the foo_platform_driver struct and
in the module init simply do a manual probe, using:
if (platform_driver_register(&snd_foo_driver) < 0) {
snd_printk(KERN_ERR "could not register driver\n");
return -EARGHH;
}
for (cards = 0, i = 0; i < SNDRV_CARDS; i++)
if (enable[i] && snd_foo_probe(i) >= 0)
cards++
if (!cards) {
printk(KERN_ER "foo not found or device busy\n");
platform_driver_unregister(&snd_foo_driver);
return -ENODEV;
}
Also attached as a patch against adlib.c (it's the simplest driver by
far, so using that one as an example. it's present in 2.6.17-rc1).
The platform_device registration could also stay in the init loop, but
since we want the free the card again if it fails same as with all the
other failures it's best off at the end of probe() I feel. You
introduced all these nonpnp_probe() methods for platform devices so we
do have a nice place to put this...
Would you feel this would be an okay setup, assuming we're not getting
that .discover method?
Rene.
[-- Attachment #2: adlib-manual-probe.diff --]
[-- Type: text/plain, Size: 2284 bytes --]
Index: local/sound/isa/adlib.c
===================================================================
--- local.orig/sound/isa/adlib.c 2006-04-05 13:41:27.000000000 +0200
+++ local/sound/isa/adlib.c 2006-04-05 14:31:32.000000000 +0200
@@ -38,13 +38,12 @@ static void snd_adlib_free(struct snd_ca
release_and_free_resource(card->private_data);
}
-static int __devinit snd_adlib_probe(struct platform_device *device)
+static int __devinit snd_adlib_probe(int i)
{
struct snd_card *card;
struct snd_opl3 *opl3;
int error;
- int i = device->id;
if (port[i] == SNDRV_AUTO_PORT) {
snd_printk(KERN_ERR DRV_NAME ": please specify port\n");
@@ -91,12 +90,18 @@ static int __devinit snd_adlib_probe(str
goto out1;
}
- platform_set_drvdata(device, card);
+ devices[i] = platform_device_register_simple(DRV_NAME, i, NULL, 0);
+ if (IS_ERR(devices[i])) {
+ snd_printk(KERN_ERR DRV_NAME ": could not register device\n");
+ error = PTR_ERR(devices[i]);
+ goto out1;
+ }
+
+ platform_set_drvdata(devices[i], card);
return 0;
out1: snd_card_free(card);
- out0: error = -EINVAL; /* FIXME: should be the original error code */
- return error;
+out0: return error;
}
static int __devexit snd_adlib_remove(struct platform_device *device)
@@ -107,9 +112,7 @@ static int __devexit snd_adlib_remove(st
}
static struct platform_driver snd_adlib_driver = {
- .probe = snd_adlib_probe,
.remove = __devexit_p(snd_adlib_remove),
-
.driver = {
.name = DRV_NAME
}
@@ -117,26 +120,17 @@ static struct platform_driver snd_adlib_
static int __init alsa_card_adlib_init(void)
{
- int i, cards;
+ int error, cards, i;
- if (platform_driver_register(&snd_adlib_driver) < 0) {
+ error = platform_driver_register(&snd_adlib_driver);
+ if (error < 0) {
snd_printk(KERN_ERR DRV_NAME ": could not register driver\n");
- return -ENODEV;
+ return error;
}
- for (cards = 0, i = 0; i < SNDRV_CARDS; i++) {
- struct platform_device *device;
-
- if (!enable[i])
- continue;
-
- device = platform_device_register_simple(DRV_NAME, i, NULL, 0);
- if (IS_ERR(device))
- continue;
-
- devices[i] = device;
- cards++;
- }
+ for (cards = 0, i = 0; i < SNDRV_CARDS; i++)
+ if (enable[i] && snd_adlib_probe(i) >= 0)
+ cards++
if (!cards) {
#ifdef MODULE
^ permalink raw reply
* Re: Q on audit, audit-syscall
From: Herbert Rosmanith @ 2006-04-05 13:50 UTC (permalink / raw)
To: Kyle Moffett; +Cc: Robin Holt, linux-kernel
In-Reply-To: <0CC157BB-7180-4B94-817A-E96A6099FBA6@mac.com>
> On Apr 5, 2006, at 08:06:30, Herbert Rosmanith wrote:
> >> On Wed, Apr 05, 2006 at 01:27:03PM +0200, Herbert Rosmanith wrote:
> >>>
> >>> good afternoon,
> >>>
> >>> I'm searching for a way to trace/intercept syscalls, both before
> >>> and after execution. "ptrace" is not an option (you probably know
> >>> why).
> >>
> >> Does strace do what you are asking for?
> >
> > as I said, "ptrace" is not an option.
>
> Why not, exactly? (No, we don't know why).
according to the man-page:
RETURN VALUES
EPERM The specified process [...] is already being traced.
this makes it unusable for me.
> ptrace is _the_ Linux mechanism to trace and intercept syscalls.
>
> There is no other way.
"there is no other way": [1,2,3,4]
regards,
h.rosmanith
[1] http://www.uniforum.chi.il.us/slides/HardeningLinux/LAuS-Design.pdf
[2] http://www.usenix.org/publications/library/proceedings/als01/full_papers/edwards/edwards.pdf
[3] http://www.citi.umich.edu/u/provos/papers/systrace.pdf
[4] http://www.nsa.gov/selinux/papers/freenix01.pdf
^ permalink raw reply
* Re: FW: [Xen-changelog] Added tag3.0.2-branchedforchangesetd0d3fef37685be264a7f52201f8ef44c030daad3
From: Michael Paesold @ 2006-04-05 13:51 UTC (permalink / raw)
To: Keir Fraser; +Cc: Ian Pratt, xen-devel
In-Reply-To: <d76566958ed57d4bf2951fbf86442031@cl.cam.ac.uk>
Keir Fraser wrote:
> On 5 Apr 2006, at 14:23, Michael Paesold wrote:
>
>> I have noticed that the 3.0.2 release candidate tree/repository is
>> obviously not the one available as 3.0-testing on the XenSource website.
>> Is it available for public consumption anywhere? Guessing from some
>> emails, I think that you are applying bugfixes to that -testing repo, no?
>> I would like to test this rc before release, but without access to it, I
>> am limited to what is available in xen-unstable.
>
> We have a 'rolling' release process in which bugfixes will be applied to
> the 3.0.2 branch even after an initial release is declared. So even after
> we have pushed '3.0.2' out to the public tree, public testing, bug reports
> and bug fixes will be very welcome.
I have already learned about the general release process here, now I have a
name for it, too. ;-)
> Currently I would estimate we'll make the tree public tomorrow: we want to
> do one more full regression-testing run, and also do a full workout of
> older domU kernels (3.0.0 and 3.0.1) on 3.0.2 to ensure we have maintained
> full backward compatibility.
Ah, thanks for the quick heads up. Btw. I appreciate your extensive testing,
thanks!
Best Regards,
Michael Paesold
^ permalink raw reply
* Re: [PATCH] [AUDIT] auditfilter.c cleanup/const-ification
From: Mitchell Blank Jr @ 2006-04-05 13:50 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <200604050829.05446.sgrubb@redhat.com>
Steve Grubb wrote:
> We loosely sync to -mm as our working group's patches are ready for wider
> testing. There is a git tree at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current.git/
OK, I cloned that. I'll try to rebase my changes against that when I get
some spare moments.
I still don't see the change that Amy mentioned though: the only divergence
in auditfilter.c from mainline is some added "#ifdef CONFIG_AUDIT_SYSCALL"
stuff... nothing touches those "bufp" variables that I can see.
-Mitch
^ permalink raw reply
* Re: patch bus_add_device-losing-an-error-return-from-the-probe-method.patch added to gregkh-2.6 tree
From: Rene Herman @ 2006-04-05 13:50 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Greg KH, alsa-devel, linux-kernel, tiwai, Andrew Morton,
Russell King
In-Reply-To: <200604042148.57286.dtor_core@ameritech.net>
[-- Attachment #1: Type: text/plain, Size: 4509 bytes --]
Dmitry Torokhov wrote:
> On Tuesday 04 April 2006 18:12, Rene Herman wrote:
>> To Dmitry, I see you saying "probe() failing is driver's problem.
>> The device is still there and should still be presented in sysfs.".
>> No, at least in the case of these platform drivers (or at least
>> these old ISA cards using the platform driver interface), a -ENODEV
>> return from the probe() method would mean the device is _not_
>> present (or not found at least). NODEV.
>
> Or you could separate device probing code from driver->probe(). BTW I
> think that ->probe() is not the best name for that method.
Right...
> It really is supposed to allocate resources and initialize the device
> so that it is ready to be used, not to verify that device is present.
> The code that created device shoudl've done that.
How do you feel about the flag that I've been proposing that a driver
that needs to probe for its hardware could set and that says "if we
return an error (or specifically -ENODEV I guess) the hardware's
reallyreally not present and the device should not register"?
Greg, and how do you feel about such a flag?
As an alternative to the flag, how would either of you feel about either
1) adding a .discover method to struct device_driver that noone other
than drivers for this old non generically discoverable hardware would
set but which would make a registration fail if set and returning < 0?
2) adding that method only to platform_driver?
3) ... and after a few months when people aren't paying attention
anymore rename .probe to .init and .discover back to .probe? ;-)
Russel, you wrote:
> Note also that this patch will not do what the ALSA folk want - they
> want to know if the device was found or whether the probe returned
> -ENODEV. We knock -ENODEV and -ENXIO to zero in
> driver_probe_device(), so they won't even see that.
Yes, I know about the -ENODEV / -ENXIO thing. I asked for comment on
that as well, but haven't gotten any.
Anyways, the additional method would, I feel, be the conceptually
cleanest approach. Practically speaking though, simply doing a manual
probe and only calling platform_register() after everything is found to
be present and accounted for is not much of a problem either.
Takashi, how would you feel about a setup for ALSA going like:
static struct platform_device *devices[SNDRV_CARDS];
static int __devinit snd_foo_probe(int i)
{
struct snd_card *card;
if (port[i] == SNDRV_AUTO_PORT) {
snd_printk(KERN_ERR "specify port\n");
return -EINVAL;
}
card = snd_card_new(index[i], id[i], THIS_MODULE, 0);
if (!card) {
snd_printk(KERN_ERR "could not create card\n");
return -EWHATEVER;
}
/* all the other things the probe method does */
if (snd_card_register(card) < 0) {
snd_printk(KERN_ERR "could not register card\n");
return -EWHATEVERSNDCARDREGISTERRETURNED;
}
devices[i] = platform_device_register_simple(NAME, i, NULL, 0);
if (IS_ERR(devices[i])) {
snd_printk(KERN_ERR "could not register device\n");
snd_card_free(card);
return PTR_ERR(devices[i]);
}
platform_set_drvdata(devices[i], card);
return 0;
}
Then deleting the .probe method from the foo_platform_driver struct and
in the module init simply do a manual probe, using:
if (platform_driver_register(&snd_foo_driver) < 0) {
snd_printk(KERN_ERR "could not register driver\n");
return -EARGHH;
}
for (cards = 0, i = 0; i < SNDRV_CARDS; i++)
if (enable[i] && snd_foo_probe(i) >= 0)
cards++
if (!cards) {
printk(KERN_ER "foo not found or device busy\n");
platform_driver_unregister(&snd_foo_driver);
return -ENODEV;
}
Also attached as a patch against adlib.c (it's the simplest driver by
far, so using that one as an example. it's present in 2.6.17-rc1).
The platform_device registration could also stay in the init loop, but
since we want the free the card again if it fails same as with all the
other failures it's best off at the end of probe() I feel. You
introduced all these nonpnp_probe() methods for platform devices so we
do have a nice place to put this...
Would you feel this would be an okay setup, assuming we're not getting
that .discover method?
Rene.
[-- Attachment #2: adlib-unregister.diff --]
[-- Type: text/plain, Size: 1033 bytes --]
Index: local/sound/isa/adlib.c
===================================================================
--- local.orig/sound/isa/adlib.c 2006-04-05 02:00:55.000000000 +0200
+++ local/sound/isa/adlib.c 2006-04-05 02:05:45.000000000 +0200
@@ -43,8 +43,7 @@ static int __devinit snd_adlib_probe(str
struct snd_card *card;
struct snd_opl3 *opl3;
- int error;
- int i = device->id;
+ int error, i = device->id;
if (port[i] == SNDRV_AUTO_PORT) {
snd_printk(KERN_ERR DRV_NAME ": please specify port\n");
@@ -95,8 +94,7 @@ static int __devinit snd_adlib_probe(str
return 0;
out1: snd_card_free(card);
- out0: error = -EINVAL; /* FIXME: should be the original error code */
- return error;
+out0: return error;
}
static int __devexit snd_adlib_remove(struct platform_device *device)
@@ -134,6 +132,11 @@ static int __init alsa_card_adlib_init(v
if (IS_ERR(device))
continue;
+ if (!platform_get_drvdata(device)) {
+ platform_device_unregister(device);
+ continue;
+ }
+
devices[i] = device;
cards++;
}
^ permalink raw reply
* Re: patch bus_add_device-losing-an-error-return-from-the-probe-method.patch added to gregkh-2.6 tree
From: Rene Herman @ 2006-04-05 13:50 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Greg KH, alsa-devel, linux-kernel, tiwai, Andrew Morton,
Russell King
In-Reply-To: <200604042148.57286.dtor_core@ameritech.net>
[-- Attachment #1: Type: text/plain, Size: 4509 bytes --]
Dmitry Torokhov wrote:
> On Tuesday 04 April 2006 18:12, Rene Herman wrote:
>> To Dmitry, I see you saying "probe() failing is driver's problem.
>> The device is still there and should still be presented in sysfs.".
>> No, at least in the case of these platform drivers (or at least
>> these old ISA cards using the platform driver interface), a -ENODEV
>> return from the probe() method would mean the device is _not_
>> present (or not found at least). NODEV.
>
> Or you could separate device probing code from driver->probe(). BTW I
> think that ->probe() is not the best name for that method.
Right...
> It really is supposed to allocate resources and initialize the device
> so that it is ready to be used, not to verify that device is present.
> The code that created device shoudl've done that.
How do you feel about the flag that I've been proposing that a driver
that needs to probe for its hardware could set and that says "if we
return an error (or specifically -ENODEV I guess) the hardware's
reallyreally not present and the device should not register"?
Greg, and how do you feel about such a flag?
As an alternative to the flag, how would either of you feel about either
1) adding a .discover method to struct device_driver that noone other
than drivers for this old non generically discoverable hardware would
set but which would make a registration fail if set and returning < 0?
2) adding that method only to platform_driver?
3) ... and after a few months when people aren't paying attention
anymore rename .probe to .init and .discover back to .probe? ;-)
Russel, you wrote:
> Note also that this patch will not do what the ALSA folk want - they
> want to know if the device was found or whether the probe returned
> -ENODEV. We knock -ENODEV and -ENXIO to zero in
> driver_probe_device(), so they won't even see that.
Yes, I know about the -ENODEV / -ENXIO thing. I asked for comment on
that as well, but haven't gotten any.
Anyways, the additional method would, I feel, be the conceptually
cleanest approach. Practically speaking though, simply doing a manual
probe and only calling platform_register() after everything is found to
be present and accounted for is not much of a problem either.
Takashi, how would you feel about a setup for ALSA going like:
static struct platform_device *devices[SNDRV_CARDS];
static int __devinit snd_foo_probe(int i)
{
struct snd_card *card;
if (port[i] == SNDRV_AUTO_PORT) {
snd_printk(KERN_ERR "specify port\n");
return -EINVAL;
}
card = snd_card_new(index[i], id[i], THIS_MODULE, 0);
if (!card) {
snd_printk(KERN_ERR "could not create card\n");
return -EWHATEVER;
}
/* all the other things the probe method does */
if (snd_card_register(card) < 0) {
snd_printk(KERN_ERR "could not register card\n");
return -EWHATEVERSNDCARDREGISTERRETURNED;
}
devices[i] = platform_device_register_simple(NAME, i, NULL, 0);
if (IS_ERR(devices[i])) {
snd_printk(KERN_ERR "could not register device\n");
snd_card_free(card);
return PTR_ERR(devices[i]);
}
platform_set_drvdata(devices[i], card);
return 0;
}
Then deleting the .probe method from the foo_platform_driver struct and
in the module init simply do a manual probe, using:
if (platform_driver_register(&snd_foo_driver) < 0) {
snd_printk(KERN_ERR "could not register driver\n");
return -EARGHH;
}
for (cards = 0, i = 0; i < SNDRV_CARDS; i++)
if (enable[i] && snd_foo_probe(i) >= 0)
cards++
if (!cards) {
printk(KERN_ER "foo not found or device busy\n");
platform_driver_unregister(&snd_foo_driver);
return -ENODEV;
}
Also attached as a patch against adlib.c (it's the simplest driver by
far, so using that one as an example. it's present in 2.6.17-rc1).
The platform_device registration could also stay in the init loop, but
since we want the free the card again if it fails same as with all the
other failures it's best off at the end of probe() I feel. You
introduced all these nonpnp_probe() methods for platform devices so we
do have a nice place to put this...
Would you feel this would be an okay setup, assuming we're not getting
that .discover method?
Rene.
[-- Attachment #2: adlib-unregister.diff --]
[-- Type: text/plain, Size: 1033 bytes --]
Index: local/sound/isa/adlib.c
===================================================================
--- local.orig/sound/isa/adlib.c 2006-04-05 02:00:55.000000000 +0200
+++ local/sound/isa/adlib.c 2006-04-05 02:05:45.000000000 +0200
@@ -43,8 +43,7 @@ static int __devinit snd_adlib_probe(str
struct snd_card *card;
struct snd_opl3 *opl3;
- int error;
- int i = device->id;
+ int error, i = device->id;
if (port[i] == SNDRV_AUTO_PORT) {
snd_printk(KERN_ERR DRV_NAME ": please specify port\n");
@@ -95,8 +94,7 @@ static int __devinit snd_adlib_probe(str
return 0;
out1: snd_card_free(card);
- out0: error = -EINVAL; /* FIXME: should be the original error code */
- return error;
+out0: return error;
}
static int __devexit snd_adlib_remove(struct platform_device *device)
@@ -134,6 +132,11 @@ static int __init alsa_card_adlib_init(v
if (IS_ERR(device))
continue;
+ if (!platform_get_drvdata(device)) {
+ platform_device_unregister(device);
+ continue;
+ }
+
devices[i] = device;
cards++;
}
^ permalink raw reply
* Update: Patch-o-matic cleanup
From: Patrick McHardy @ 2006-04-05 13:47 UTC (permalink / raw)
To: Netfilter Development Mailinglist
In-Reply-To: <443165AA.4030509@trash.net>
Patrick McHardy wrote:
> Following (quite late) the decision taken at the netfilter workshop to
> clean up the pomng repository by removing old patches and moving some
> patches out of the netfilter repository, I've started by removing the
> obsolete ipsec* patches and the policy match. Both have been merged
> and were pretty outdated.
>
> If noone can name good reasons against it, I will also remove the
> following patches in a few days:
> [...]
After receiving multiple "please keep this patch" mails, it seems I
started the wrong way.
Removing old patches is part of a greater plan to reduce the content of
pom to only those things the netfilter team has an interest in
maintaining, and most of these things will be merged in not too long
time. _All_ other patches will be removed and the "runme" tool will
be enhanced by an apt-get like mechanism to download patches from
external sources, so people interested in keeping patches around can
maintain them themselves and publish them somewhere for others to use.
This should benefit both us and the authors since they usually maintain
their own versions of the patches anyway and periodically send us
updates to include in pom, which unnecessarily cost time for everyone
involved.
This is the full list of patches to be removed. Instructions how to set
up a pomng repository are at the end of this mail, I'll commit the code
soon.
- ACCOUNT
- IPMARK
- NETLINK
- NETMAP
- TARPIT
- TCPLAG
- TRACE
- XOR
- account
- comment
- connlimit
- connrate
- conntrack_locking
- cuseeme-nat
- dropped-table
- expire
- fuzzy
- geoip
- goto
- ip_queue_vwmark
- ipp2p
- mport
- nat-reservations
- netfilter-docbook
- osf
- owner-socketlookup
- pool
- pptp-conntrack-nat
- psd
- time
- tproxy
The patches will be removed in 30 days, authors or other people that
want to maintain them in an external repository are welcome to send
the URL to be included in the distrubuted sources.list.
How to set up a repository:
The repository must be accessible in a way supported by curl (HTTP or
FTP for example). The name of each patchlet is listed in a file named
"index". Each patchlet must be contained in a .tar.gz file, which
contains a directory named like the patchlet itself. The directories
contents are similar to those in patchlets/ today, but the Repository
specified in the info file must be "external".
So to create a repository from one of the patches currently in pom:
- cd patchlets
- edit $patch/info, change repository to "external"
- tar cz $patch > /wwwroot/pom-repo/$patch.tar.gz
- echo $patch >> /wwwroot/pom-repo/index
As I said above, I'll commit the code for this soon.
^ permalink raw reply
* Re: CSCAN I/O scheduler for 2.6.10 kernel
From: Vishal Patil @ 2006-04-05 13:46 UTC (permalink / raw)
To: Antonio Vargas; +Cc: Bill Davidsen, Linux Kernel Mailing List
In-Reply-To: <69304d110604050448x60fd5bb1ub74f66b720dc7d8a@mail.gmail.com>
The two queues are used for sorting purposes ONLY. There is the
dispatch queue to which the requests are moved from one of the queues
and the request is processes of the dispatch queue.
Example:
Current request = 40
Q1 = 55 58 67 72
Q2 = 10 23 38
Assuming no other request arrives, these will be pushed on the
dispatch queue in the following order
55 58 67 72 10 23 38
I hope this clears things up.
Also I have found that the patch that I had submitted earlier has few
bugs in it. I am going to fix those and then submit a patch for 2.6.16
Thanks.
- Vishal
On 4/5/06, Antonio Vargas <windenntw@gmail.com> wrote:
> On 4/4/06, Vishal Patil <vishpat@gmail.com> wrote:
> > In that case it would be a normal elevator algorithm and that has a
> > possiblity of starving the requests at one end of the disk.
> >
> > - Vishal
> >
> > On 4/4/06, Bill Davidsen <davidsen@tmr.com> wrote:
> > > Vishal Patil wrote:
> > > > Maintain two queues which will be sorted in ascending order using Red
> > > > Black Trees. When a disk request arrives and if the block number it
> > > > refers to is greater than the block number of the current request
> > > > being served add (merge) it to the first sorted queue or else add
> > > > (merge) it to the second sorted queue. Keep on servicing the requests
> > > > from the first request queue until it is empty after which switch over
> > > > to the second queue and now reverse the roles of the two queues.
> > > > Simple and Sweet. Many thanks for the awesome block I/O layer in the
> > > > 2.6 kernel.
> > > >
> > > Why both queues sorting in ascending order? I would think that one
> > > should be in descending order, which would reduce the seek distance
> > > between the last i/o on one queue and the first on the next.
> > >
>
> But, if there are two queues, one which is being processed and other
> which gets the new requests (and the corresponding queue switch when
> the current is empty), then there is no way to get starved when they
> are sorted in opposite order.
>
>
> --
> Greetz, Antonio Vargas aka winden of network
>
> http://wind.codepixel.com/
> windNOenSPAMntw@gmail.com
> thesameasabove@amigascne.org
>
> Every day, every year
> you have to work
> you have to study
> you have to scene.
>
--
Every passing minute is another chance to turn it all around.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.