Re: via irq quirk breakage
Hi Nick,
Thanks for testing and reporting.
Le Mardi 30 Janvier 2007 03:35, Nick Piggin a écrit :
> Jean Delvare wrote:
> > Here is the patch I have come up with. It might not qualify as elegant,
> > but at least it appears to solve the issue. Nick, can you please give it
> > a try and confirm it works for you as well?
>
> This does not work for me. Again, it boots and runs, but USB interrupts
> don't seem to be getting delivered. Attached is the dmesg. Let me know
> if you need any other info or tests done.
You have an old VT82C686 south bridge, which was tagged as "special" by
Alan. For this chip, Alan's code only allows devices 00:00.x to be quirked.
As my code was merely a reimplementation of Alan's idea, it does the same.
Your USB controllers are at 00:07.x, so I'm not surprised they weren't
quirked.
Alan, why were dev_lo and dev_hi both set to 0 for the VT82C868 in your
implementation? Is it a typo, or...?
Nick, I guess the following patch would work better for you? I've listed
devices 00:07.x as quirkable for the VT82C686.
* * * * *
Fix VIA quirks that were recently broken by Alan Cox in the upstream
kernel (commit 1597cacbe39802d86656d1f2e6329895bd2ef531).
My understanding is that pci_find_present() doesn't work yet at the
time the quirks are run. So I used a two-step quirk as is done for
some other quirks already. First we detect the VIA south bridges
and set the right low and high device limits, then we are ready to
actually run the quirks on the affected devices.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
---
drivers/pci/quirks.c | 78 ++
1 files changed, 42 insertions(+), 36 deletions(-)
--- linux-2.6.20-rc6.orig/drivers/pci/quirks.c 2007-01-26 09:08:14.0
+0100
+++ linux-2.6.20-rc6/drivers/pci/quirks.c 2007-01-29 15:33:30.0
+0100
@@ -654,19 +654,40 @@
* VIA bridges which have VLink
*/
-static const struct pci_device_id via_vlink_fixup_tbl[] = {
- /* Internal devices need IRQ line routing, pre VLink */
- { PCI_VDEVICE(VIA, PCI_DEVICE_ID_VIA_82C686), 0 },
- { PCI_VDEVICE(VIA, PCI_DEVICE_ID_VIA_8231), 17 },
- /* Devices with VLink */
- { PCI_VDEVICE(VIA, PCI_DEVICE_ID_VIA_8233_0), 17},
- { PCI_VDEVICE(VIA, PCI_DEVICE_ID_VIA_8233A), 17 },
- { PCI_VDEVICE(VIA, PCI_DEVICE_ID_VIA_8233C_0), 17 },
- { PCI_VDEVICE(VIA, PCI_DEVICE_ID_VIA_8235), 16 },
- { PCI_VDEVICE(VIA, PCI_DEVICE_ID_VIA_8237), 15 },
- { PCI_VDEVICE(VIA, PCI_DEVICE_ID_VIA_8237A), 15 },
- { 0, },
-};
+static int via_vlink_dev_lo = -1, via_vlink_dev_hi = 18;
+
+static void quirk_via_bridge(struct pci_dev *dev)
+{
+ /* See what bridge we have and find the device ranges */
+ switch (dev->device) {
+ case PCI_DEVICE_ID_VIA_82C686:
+ /* 82C686 is special */
+ via_vlink_dev_lo = 7;
+ via_vlink_dev_hi = 7;
+ break;
+ case PCI_DEVICE_ID_VIA_8237:
+ case PCI_DEVICE_ID_VIA_8237A:
+ via_vlink_dev_lo = 15;
+ break;
+ case PCI_DEVICE_ID_VIA_8235:
+ via_vlink_dev_lo = 16;
+ break;
+ case PCI_DEVICE_ID_VIA_8231:
+ case PCI_DEVICE_ID_VIA_8233_0:
+ case PCI_DEVICE_ID_VIA_8233A:
+ case PCI_DEVICE_ID_VIA_8233C_0:
+ via_vlink_dev_lo = 17;
+ break;
+ }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,PCI_DEVICE_ID_VIA_82C686,
quirk_via_bridge);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,PCI_DEVICE_ID_VIA_8231,
quirk_via_bridge);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,PCI_DEVICE_ID_VIA_8233_0,
quirk_via_bridge);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,PCI_DEVICE_ID_VIA_8233A,
quirk_via_bridge);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,PCI_DEVICE_ID_VIA_8233C_0,
quirk_via_bridge);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,PCI_DEVICE_ID_VIA_8235,
quirk_via_bridge);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,PCI_DEVICE_ID_VIA_8237,
quirk_via_bridge);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,PCI_DEVICE_ID_VIA_8237A,
quirk_via_bridge);
/**
* quirk_via_vlink - VIA VLink IRQ number update
@@ -675,35 +696,20 @@
* If the device we are dealing with is on a PIC IRQ we need to
* ensure that the IRQ line register which usually is not relevant
* for PCI cards, is actually written so that interrupts get sent
- * to the right place
+ * to the right place.
+ * We only do this on systems where a VIA south bridge was detected,
+ * and only for VIA devices on the motherboard (see quirk_via_bridge
+ * above).
*/
static void quirk_via_vlink(struct pci_dev *dev)
{
- const struct pci_device_id *via_vlink_fixup;
- static int dev_lo = -1, dev_hi = 18;
u8 irq, new_irq;
- /* Check if we have VLink and cache the result
Re: [Cbe-oss-dev] [RFC, PATCH 4/4] Add support to OProfile for profiling Cell BE SPUs -- update
> > +/* Defines used for sync_start */
> > +#define SKIP_GENERIC_SYNC 0
> > +#define SYNC_START_ERROR -1
> > +#define DO_GENERIC_SYNC 1
> > +
> > +typedef struct vma_map
> > +{
> > + struct vma_map *next;
> > + unsigned int vma;
> > + unsigned int size;
> > + unsigned int offset;
> > + unsigned int guard_ptr;
> > + unsigned int guard_val;
> > +} vma_map_t;
I haven't had time to look in details yet but in that context, what does
"vma" stands for ? There's already an important vm data structure in
linux routinely called "vma" and thus I suspect this is a poor naming
choice as it will cause confusion.
Cheers,
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc6 - sky2 resume breakage
* Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> >i'm wondering, could we go with Thomas' temporary patch that disables
> >sky2 MSI if CONFIG_PM is enabled - we could revert that after 2.6.20.
> >It's not like MSI is a life and death feature. On IO-APIC systems
> >vectors are abundant and in any case we share irqs just fine. The
> >true advantage of MSI is minimal. (MSI-X has the potential to be
> >better by being message based, but in reality it still goes through
> >the full IRQ layer.) MSI might be useful on really, really large
> >systems - but i really hope those really large systems dont rely on
> >CONFIG_PM. Meanwhile Thomas' patch maximizes the amount of working
> >hardware (it has the chance to produce working systems in 100% of the
> >cases) - which is a few orders of magnitude more important than IRQ
> >management micro-costs. Am i missing anything?
>
>
> Sharing irqs /sucks/. I routinely have to fight a USB device dying,
> because the ATA device is causing an interrupt storm, or vice versa.
> /Very/ common headache.
Yeah. Admittedly, ATA is very special because it is still edge-triggered
most of the time (for legacy reasons):
14: 389907 0 IO-APIC-edge ide0
so if it shares an irq with a device that has level-triggered
assumptions, those two dont intermix very well. That's why i have the
delayed-disable patches (see the two patches below), which will unify
the two methods, and the irq flow handling method will be mostly a
'performance hint' not a correctness issue. This has been in -rt for
quite a few weeks now and it works well.
btw., it would be great if you could help us here: could you perhaps,
from a past example, outline a specific case of such an ATA/USB IRQ
storm and how it occured (precisely) - and what the fix was? I'd like to
analyze a specific case to make sure the genirq layer recovers from such
cases more gracefully. In general, i think the IRQ subsystem needs to
become more failure-resilient and needs to become more auto-learning
(and these two dont stand in the way of good performance). This problem
of shared IRQs will be with us for at least another 10 years, if not
more. (for example ISA is /still/ not dead everywhere and it was already
legacy technology 15 years ago when Linux was started.)
Ingo
--->
Subject: irq: do not mask interrupts by default
From: Ingo Molnar <[EMAIL PROTECTED]>
never mask interrupts immediately upon request. Disabling interrupts in
high-performance codepaths is rare, and on the other hand this change
could recover lost edges (or even other types of lost interrupts) by
conservatively only masking interrupts after they happen. (NOTE: with
this change the highlevel irq-disable code still soft-disables this IRQ
line - and if such an interrupt happens then the IRQ flow handler keeps
the IRQ masked.)
mark i8529A controllers as 'never loses an edge'.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
arch/i386/kernel/i8259.c |1 +
arch/x86_64/kernel/i8259.c |1 +
kernel/irq/chip.c | 17 ++---
3 files changed, 12 insertions(+), 7 deletions(-)
Index: linux/arch/i386/kernel/i8259.c
===
--- linux.orig/arch/i386/kernel/i8259.c
+++ linux/arch/i386/kernel/i8259.c
@@ -41,6 +41,7 @@ static void mask_and_ack_8259A(unsigned
static struct irq_chip i8259A_chip = {
.name = "XT-PIC",
.mask = disable_8259A_irq,
+ .disable= disable_8259A_irq,
.unmask = enable_8259A_irq,
.mask_ack = mask_and_ack_8259A,
};
Index: linux/arch/x86_64/kernel/i8259.c
===
--- linux.orig/arch/x86_64/kernel/i8259.c
+++ linux/arch/x86_64/kernel/i8259.c
@@ -103,6 +103,7 @@ static void mask_and_ack_8259A(unsigned
static struct irq_chip i8259A_chip = {
.name = "XT-PIC",
.mask = disable_8259A_irq,
+ .disable= disable_8259A_irq,
.unmask = enable_8259A_irq,
.mask_ack = mask_and_ack_8259A,
};
Index: linux/kernel/irq/chip.c
===
--- linux.orig/kernel/irq/chip.c
+++ linux/kernel/irq/chip.c
@@ -202,10 +202,6 @@ static void default_enable(unsigned int
*/
static void default_disable(unsigned int irq)
{
- struct irq_desc *desc = irq_desc + irq;
-
- if (!(desc->status & IRQ_DELAYED_DISABLE))
- desc->chip->mask(irq);
}
/*
@@ -270,13 +266,18 @@ handle_simple_irq(unsigned int irq, stru
if (unlikely(desc->status & IRQ_INPROGRESS))
goto out_unlock;
- desc->status &= ~(IRQ_REPLAY | IRQ_WAITING);
kstat_cpu(cpu).irqs[irq]++;
action = desc->action;
- if (unlikely(!action || (desc->status & IRQ_DISABLED)))
+ if (unlikely(!action ||
Re: Fw: Re: [mm PATCH 4/6] RCU: (now) CPU hotplug
* Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> > in fact (new) kprobes uses the freezer, and it's far more
> > performance sensitive than the handling of CPU hotplug events.
>
> Outside of realtime workloads, I agree that performance should not be
> a problem. And I don't know of any reason why realtime systems need
> to be able to do hotplug CPU. Yet, anyway. ;-)
even for -rt it's not really an issue: the hotplug locks are so
all-encompassing and so unbound at the moment that there's no realistic
expectation for them to ever become deterministic. So we might as well
make them encompass "everything" - without any noticeable effect.
> So the thought is to make _cpu_down() and _cpu_up() do something like
> the following (untested, probably does not even compile), perhaps with
> suitable adjustments elsewhere as well?
>
> static int _cpu_down(unsigned int cpu)
> {
> int err;
> struct task_struct *p;
> cpumask_t old_allowed, tmp;
>
> if (num_online_cpus() == 1)
> return -EBUSY;
>
> if (!cpu_online(cpu))
> return -EINVAL;
>
> if (freeze_processes()) {
> err = -EBUSY;
> goto out_freeze_notify_failed;
> }
> err = raw_notifier_call_chain(_chain, CPU_DOWN_PREPARE,
> (void *)(long)cpu);
yeah. This all looks so nice that i almost cannot believe it's true :-)
This would allow us to rip out all the cpu-hotplug locking: wow! If only
someone would volunteer to try to pull this off and then to touch so
many subsystems ;-)
i fully agree that the opposite notifications should be traversed in
inverse order [but this is an orthogonal improvement]. Too bad the
notifier list is a single linked list.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kprobes: Fix compiler warning
On Tue, 30 Jan 2007 01:12:17 -0600 Kumar Gala <[EMAIL PROTECTED]> wrote: > What are your thoughts on forward Masami patch to Linus for 2.6.20 > since it fixes a real bug on PPC? I bumped it up into the for-2.6.20 slot. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] coredump: documentation for proc and sysctl]
Hi Pavel and Andrew, Pavel Machek wrote: >>This patch adds the documentation for the following parameters: >> /proc//core_flags >> /proc/sys/kernel/core_flags_enable > > Sysctl seems really strange to me. Either the feature is safe to use, > or it is not. Users can already ulimit -c 0, and we do not have > "/proc/sys/kernel/allow_users_to_disable_their_core_dumps". Oh, I had forgotten that. Thank you for pointing out. The purpose of this sysctl is to prevent a bad process from hiding its memory. But as you say, this sysctl isn't enough for the purpose. Andrew wrote: > Does this feature have any security implications? For example, there might > be system administration programs which force a coredump on a "bad" > process, and leave the core somewhere for the administrator to look at. I have never heard of the story that ulimit -c 0 bothered an administrator who wanted to force a coredump. So even without this sysctl, the administrator wouldn't bother about security concerns. I'll drop it from the next version. Thanks, -- Hidehiro Kawai Hitachi, Ltd., Systems Development Laboratory - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc6 - sky2 resume breakage
Ingo Molnar wrote: i'm wondering, could we go with Thomas' temporary patch that disables sky2 MSI if CONFIG_PM is enabled - we could revert that after 2.6.20. It's not like MSI is a life and death feature. On IO-APIC systems vectors are abundant and in any case we share irqs just fine. The true advantage of MSI is minimal. (MSI-X has the potential to be better by being message based, but in reality it still goes through the full IRQ layer.) MSI might be useful on really, really large systems - but i really hope those really large systems dont rely on CONFIG_PM. Meanwhile Thomas' patch maximizes the amount of working hardware (it has the chance to produce working systems in 100% of the cases) - which is a few orders of magnitude more important than IRQ management micro-costs. Am i missing anything? Sharing irqs /sucks/. I routinely have to fight a USB device dying, because the ATA device is causing an interrupt storm, or vice versa. /Very/ common headache. Other than that, they use a tiny bit fewer CPU cycles, and allow simplification of the interrupt handler (saving another few CPU cycles). The biggest benefit is (a) for hardware designers, where MSI means a cleaner h/w design, and (b) preparation of drivers and the kernel systems for MSI-only hardware. At present only high end hardware is MSI-only (like infiniband), but that's the future direction. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] coredump: core dump masking support v2
Hi Robin, Robin Holt wrote: > Can you make this a little more transparent? Having a magic bitmask does > not seem like the best way to do stuff. Could you maybe make a core_flags > directory with a seperate file for each flag. It could still map to a > single field in the mm, but be broken out for the proc filesystem. It seems to be one of the good enhancement idea, thanks.:-) But currently, there is only one flag. So we had better keep this simple implementation until someone requests to add a new flag. Thanks, -- Hidehiro Kawai Hitachi, Ltd., Systems Development Laboratory - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Free Linux Driver Development!
Greg KH wrote on 30-01-07 02:29: An offer they can't refuse. This offer is in affect for all different types of devices, from USB toys to PCI video devices to high-speed networking cards. If you build it, we can get Linux drivers working for it. s/affect/effect/ and maybe s/build/manufacture/ ?? bjd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
On Tue, Jan 30, 2007 at 02:18:16AM -0500, Dave Jones wrote: > > Likewise IOMMUs. > > There were a number of people there last year who understood IOMMUs > and could easily talk at length about them if able to do so. iirc, > you were also invited, but were unable to travel due to bad things > falling from the sky in Israel at the time ? That was OLS, not KS. Also, that's not the impression I got from reading the lwn.net summary (and I know several IOMMU people such as Olof were not invited... I think it was just jejb and ak?). Cheers, Muli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc6-mm1
On Sun, 28 Jan 2007 11:25:42 +0100 Jiri Slaby <[EMAIL PROTECTED]> wrote: > Andrew Morton napsal(a): > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.20-rc6-mm1/ > > I'm still seeing this during bootup: > BUG: at /home/l/latest/xxx/arch/i386/mm/highmem.c:52 kmap_atomic() > [] show_trace_log_lvl+0x1a/0x30 > [] show_trace+0x12/0x14 > [] dump_stack+0x16/0x18 > [] kmap_atomic+0x16c/0x20e > [] ntfs_end_buffer_async_read+0x18e/0x2ed > [] end_bio_bh_io_sync+0x26/0x3f > [] bio_endio+0x37/0x62 > [] __end_that_request_first+0x224/0x444 > [] end_that_request_chunk+0x8/0xa > [] scsi_end_request+0x1f/0xc7 > [] scsi_io_completion+0x7b/0x33a > [] sd_rw_intr+0x23/0x1ab > [] scsi_finish_command+0x42/0x47 > [] scsi_softirq_done+0x64/0xcf > [] blk_done_softirq+0x54/0x62 > [] __do_softirq+0x75/0xde > [] do_softirq+0x3b/0x3d > [] irq_exit+0x3b/0x3d > [] do_IRQ+0x51/0x8d > [] common_interrupt+0x23/0x28 > [] cpu_idle+0x80/0xc3 > [] rest_init+0x23/0x36 > [] start_kernel+0x3a5/0x43c > [<>] 0x0 > === > > I.e. KM_BIO_SRC_IRQ through softirq path. > argh. ntfs_end_buffer_async_read() doesn't know whether it will be called from hardirq or from softirq context: it depends upon the underlying driver. In this case, if the CPU running ntfs_end_buffer_async_read() is interrupted by IO completion against a different disk controller and that completion handler uses KM_BIO_SRC_IRQ (as it is allowed to do), it will trash ntfs_end_buffer_async_read()'s atomic kmap and unpleasing things will ensue. I guess a suitable fix here is to protect that kmap with local_irq_save/restore. I wonder where else we have that bug? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI: Correct apparent typo "CONFIG_ACPI_DEBUG_OUTPUT".
Heh, you're right Robert -- this was a typo.
So I applied your patch, looked at my dmesg and realized that
we don't need the output it enables, so I deleted the whole routine:-)
thanks,
-Len
On Saturday 27 January 2007 01:55, Robert P. J. Day wrote:
>
> Replace the apparent typo CONFIG_ACPI_DEBUG_OUTPUT with
> the non-Kconfig conditional ACPI_DEBUG_OUTPUT, which is what every
> other file uses.
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
>
> ---
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 698a154..d65142a 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -891,7 +891,7 @@ static int acpi_device_set_context(struct acpi_device
> *device, int type)
> static void acpi_device_get_debug_info(struct acpi_device *device,
> acpi_handle handle, int type)
> {
> -#ifdef CONFIG_ACPI_DEBUG_OUTPUT
> +#ifdef ACPI_DEBUG_OUTPUT
> char *type_string = NULL;
> char name[80] = { '?', '\0' };
> struct acpi_buffer buffer = { sizeof(name), name };
> @@ -928,7 +928,7 @@ static void acpi_device_get_debug_info(struct acpi_device
> *device,
> }
>
> printk(KERN_DEBUG "Found %s %s [%p]\n", type_string, name, handle);
> -#endif /*CONFIG_ACPI_DEBUG_OUTPUT */
> +#endif /* ACPI_DEBUG_OUTPUT */
> }
>
> static int acpi_bus_remove(struct acpi_device *dev, int rmdevice)
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
On Tue, Jan 30, 2007 at 08:43:12AM +0200, Muli Ben-Yehuda wrote: > On Tue, Jan 30, 2007 at 06:51:51AM +0100, Jes Sorensen wrote: > > > Last year the subject of DMA engines was put up, however most of the > > people interested in the subject weren't even invited. In that case > > there's really little concrete that can come out of the discussion. > > Likewise IOMMUs. There were a number of people there last year who understood IOMMUs and could easily talk at length about them if able to do so. iirc, you were also invited, but were unable to travel due to bad things falling from the sky in Israel at the time ? > I think Andrew's suggestion of adding a CFP phase to KS is excellent - > get some new blood in the room and spice up the discussion. I don't see anything that really precludes the idea. Or even the notion of both that and some of the old format for some of the sessions. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kprobes: Fix compiler warning
On Jan 30, 2007, at 1:05 AM, Kumar Gala wrote: On Jan 29, 2007, at 11:55 PM, Ananth N Mavinakayanahalli wrote: On Mon, Jan 29, 2007 at 11:43:33PM -0600, Kumar Gala wrote: On ppc the compiler gripes about: kernel/kprobes.c: In function 'collect_garbage_slots': kernel/kprobes.c:215: warning: comparison is always false due to limited range of data type The compiler ends up optimizing away the test since char's are unsigned on ppc. Kumar, Masami fixed this last week: http://marc.theaimsgroup.com/?l=linux-kernel=116968723823366=2 Patch currently in -mm. Thanks, Ananth Cool, Masami's patch looks far more complete. Andrew, What are your thoughts on forward Masami patch to Linus for 2.6.20 since it fixes a real bug on PPC? - k - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hidden SSID's
Jouni Malinen wrote: > On Mon, Jan 29, 2007 at 10:52:20PM -0600, Larry Finger wrote: > >> When an AP has a hidden SSID, ieee80211 fails, at least with wpa_supplicant, >> which searches through the scan data looking for a particular ssid. Because >> ieee80211 has substituted a false ssid, namely "", wpa_supplicant >> cannot authenticate. This behavior is fixed by adding a new argument to >> ieee80211_translate_scan that contains the expected ssid. > > Would this be replacing the SSID of all BSSes in scan results with the > SSID for which the latest per-SSID scan was issued? If yes, this does > not sound any better than the current behavior. The driver/802.11 code > should not replace the SSID value with anything else than the value > received from the AP. Any AP with a hidden SSID will only respond to probe requests that specify its SSID, and will ignore any other probes. In addition, the response will have an empty SSID field. These responses are the only ones in which a substitution would occur. These are the same responses where the current code sends back the "" pseudo-SSID. My change would put the correct one there. > In case of hidden SSIDs, the 802.11 implementation should maintain a > list of BSSes found during the scan(s) and update the SSID (in most > cases, by creating a new BSS entry) with the SSID from Probe Response > frames. In other words, if the scan is done for a specific SSID (Probe > Request includes that SSID), the AP that is using hidden SSIDs will > likely include the SSID in Probe Response and data from that Probe > Response can be used to fill in the missing pieces for the > pair. > > Generating false scan results by locally guessing what the SSID > could be is just plain wrong. The scan results need to be based on real > frames from the APs. We aren't guessing. The response frame with the empty SSID field must have come from the AP with the SSID we want. Filling in the expected value is just making it easier for the user-space tools. Larry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kprobes: Fix compiler warning
On Jan 29, 2007, at 11:55 PM, Ananth N Mavinakayanahalli wrote: On Mon, Jan 29, 2007 at 11:43:33PM -0600, Kumar Gala wrote: On ppc the compiler gripes about: kernel/kprobes.c: In function 'collect_garbage_slots': kernel/kprobes.c:215: warning: comparison is always false due to limited range of data type The compiler ends up optimizing away the test since char's are unsigned on ppc. Kumar, Masami fixed this last week: http://marc.theaimsgroup.com/?l=linux-kernel=116968723823366=2 Patch currently in -mm. Thanks, Ananth Cool, Masami's patch looks far more complete. - k - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc6 - sky2 resume breakage
* Linus Torvalds <[EMAIL PROTECTED]> wrote: > On Mon, 29 Jan 2007, Stephen Hemminger wrote: > > > > On one and only one platform. It works fine on others. Don't blame > > the driver, stop it in PCI. > > How sure are you that it's only those Sony laptops? i'm wondering, could we go with Thomas' temporary patch that disables sky2 MSI if CONFIG_PM is enabled - we could revert that after 2.6.20. It's not like MSI is a life and death feature. On IO-APIC systems vectors are abundant and in any case we share irqs just fine. The true advantage of MSI is minimal. (MSI-X has the potential to be better by being message based, but in reality it still goes through the full IRQ layer.) MSI might be useful on really, really large systems - but i really hope those really large systems dont rely on CONFIG_PM. Meanwhile Thomas' patch maximizes the amount of working hardware (it has the chance to produce working systems in 100% of the cases) - which is a few orders of magnitude more important than IRQ management micro-costs. Am i missing anything? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix sparse annotation of spin unlock macros in one case
From: Pavel Roskin <[EMAIL PROTECTED]>
SMP systems without preemption and spinlock debugging enabled use unlock
macros that don't tell sparse that the lock is being released. Add
sparse annotations in this case.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
include/linux/spinlock.h | 33 -
1 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
index 94b767d..d3b6397 100644
--- a/include/linux/spinlock.h
+++ b/include/linux/spinlock.h
@@ -228,15 +228,30 @@ do {
\
# define read_unlock_irq(lock) _read_unlock_irq(lock)
# define write_unlock_irq(lock)_write_unlock_irq(lock)
#else
-# define spin_unlock(lock) __raw_spin_unlock(&(lock)->raw_lock)
-# define read_unlock(lock) __raw_read_unlock(&(lock)->raw_lock)
-# define write_unlock(lock)__raw_write_unlock(&(lock)->raw_lock)
-# define spin_unlock_irq(lock) \
-do { __raw_spin_unlock(&(lock)->raw_lock); local_irq_enable(); } while (0)
-# define read_unlock_irq(lock) \
-do { __raw_read_unlock(&(lock)->raw_lock); local_irq_enable(); } while (0)
-# define write_unlock_irq(lock) \
-do { __raw_write_unlock(&(lock)->raw_lock); local_irq_enable(); } while (0)
+# define spin_unlock(lock) \
+do {__raw_spin_unlock(&(lock)->raw_lock); __release(lock); } while (0)
+# define read_unlock(lock) \
+do {__raw_read_unlock(&(lock)->raw_lock); __release(lock); } while (0)
+# define write_unlock(lock) \
+do {__raw_write_unlock(&(lock)->raw_lock); __release(lock); } while (0)
+# define spin_unlock_irq(lock) \
+do { \
+ __raw_spin_unlock(&(lock)->raw_lock); \
+ local_irq_enable(); \
+ __release(lock);\
+} while (0)
+# define read_unlock_irq(lock) \
+do { \
+ __raw_read_unlock(&(lock)->raw_lock); \
+ local_irq_enable(); \
+ __release(lock);\
+} while (0)
+# define write_unlock_irq(lock)\
+do { \
+ __raw_write_unlock(&(lock)->raw_lock); \
+ local_irq_enable(); \
+ __release(lock);\
+} while (0)
#endif
#define spin_unlock_irqrestore(lock, flags) \
--
Regards,
Pavel Roskin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
On Tue, Jan 30, 2007 at 06:51:51AM +0100, Jes Sorensen wrote: > Last year the subject of DMA engines was put up, however most of the > people interested in the subject weren't even invited. In that case > there's really little concrete that can come out of the discussion. Likewise IOMMUs. I think Andrew's suggestion of adding a CFP phase to KS is excellent - get some new blood in the room and spice up the discussion. Cheers, Muli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tty: cleanup release_mem
On 1/30/07, Andrew Morton <[EMAIL PROTECTED]> wrote: BUG: unable to handle kernel paging request at virtual address 6b6b6bdf Use after free. The new code does module_put() _after_ free_tty_struct() which is obviously wrong. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] -mm2: typo in ipc/ipc_sysctl.c -> compile failure
Hi there, Dunno who does IPC so hoping you do ;) (ref.config: 20-rc6-mm2b/048) Cheers, Grant. From: Grant Coady <[EMAIL PROTECTED]> Fix typos causing compile failure when CONFIG_PROC_FS not set in ipc/ipc_sysctl.c, compile tested. ipc/ipc_sysctl.c:107: error: `proc_ipc_doulongvec_minmax' undeclared here (not in a function) ipc/ipc_sysctl.c:107: error: initializer element is not constant [...] ipc/ipc_sysctl.c:164: error: (near initialization for `ipc_kern_table[7]') make[1]: *** [ipc/ipc_sysctl.o] Error 1 make: *** [ipc] Error 2 Also applies cleanly to 2.6.20-rc6-mm3. Signed-off-by: Grant Coady <[EMAIL PROTECTED]> --- ipc_sysctl.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) --- linux-2.6.20-rc6-mm2a/ipc/ipc_sysctl.c 2007-01-30 07:41:08.0 +1100 +++ linux-2.6.20-rc6-mm2b/ipc/ipc_sysctl.c 2007-01-30 16:45:03.0 +1100 @@ -50,8 +50,8 @@ } #else -#define proc_ipc_do_ulongvec_minmax NULL -#define proc_ipc_do_intvec NULL +#define proc_ipc_doulongvec_minmax NULL +#define proc_ipc_dointvec NULL #endif #ifdef CONFIG_SYSCTL_SYSCALL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
On Tue, Jan 30, 2007 at 06:11:18AM +0100, Andi Kleen wrote: > On Tuesday 30 January 2007 04:41, Dave Jones wrote: > > Right, other than during the CPU architects panel, I don't remember > > any non x86/ia64/ppc stuff being brought up at all. > > No IA64 stuff that I can remember. And there was a presentation on PPC. > > But that was planned to be differently with more focus on embedded, > unfortunately the comittee didn't manage to find more embedded CPU > people in time. > It might be interesting to have a more condensed CPU panel, something like the OLS lightning talks. Gather a larger number of vendors, and give each a small window to bring up the most relevant issues for them in the future, while also allowing for some feedback and Q It would be nice to get more input from CPU architects, but only if it's possible to keep it entirely technical and moving along without anyone having to hurry their window of time due to someone else overstepping theirs. If they only have a small window to present their concerns, I think we'll see a lot of the fluff (as itemized by davej) go away. As soon as a vendor starts rambling on about value-added IP blocks, we've already lost.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
Andi Kleen wrote: Abstract of a discussion? Interesting concept. Maybe. If you mean abstract of a talk then I think you're wrong. Not sure that abstract of a discussion thing would really work though. It seems a bit contradicting in itself. I was thinking more an abstract as in something that should provide a short summary of the problem and why it should be discussed at KS. I don't think papers etc. would do any good at this level. Something specifically targetted at KS. Cheers, Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
> Last year the subject of DMA engines was put up, however most of the > people interested in the subject weren't even invited. In that case > there's really little concrete that can come out of the discussion. Nobody claimed the committee was perfect. Shit happens. There were also plenty of productive discussions. > Expecting everyone to sit down and get the full picture of a subject > in 5 minutes is unrealistic and will not lead to very useful outcome. If they never heard of the issue before they are unlikely to be useful in the discussion even after an hour of talk. That is not how it works again. > Of course, thats why I suggested more like an abstract published in > advance, like why is this subject worthy and what would the person > like to achieve by having it discussed. Hopefully with some technical > ideas included. Abstract of a discussion? Interesting concept. Maybe. If you mean abstract of a talk then I think you're wrong. Not sure that abstract of a discussion thing would really work though. It seems a bit contradicting in itself. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Discussion starting on the 2007 ksummit discuss list
Hi, this is just a reminder that discussion is now starting on the 2007 ksummit discuss list, and that I will be turning off the 2006 discuss list shortly after sending out this note. Please direct all comments about the Kernel Summit to the 2007 ksummit discussion list. If you missed last week's announcement, the list submission address and subscription URL can be found by executing the following perl script. Not that I expect this will keep the spammers out, but maybe it will slow them down a little... #!/usr/bin/perl $at="@"; $AD=(gmtime(time))[5]+1900; print "ksummit-" . $AD . "-discuss" . $at . "thunk.org\n"; print "http://thunk.org/mailman/listinfo/ksummit-; . $AD . "-discuss\n"; - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kprobes: Fix compiler warning
On Mon, Jan 29, 2007 at 11:43:33PM -0600, Kumar Gala wrote:
> On ppc the compiler gripes about:
>
> kernel/kprobes.c: In function 'collect_garbage_slots':
> kernel/kprobes.c:215: warning: comparison is always false due to limited
> range of data type
>
> The compiler ends up optimizing away the test since char's are unsigned on
> ppc.
Kumar,
Masami fixed this last week:
http://marc.theaimsgroup.com/?l=linux-kernel=116968723823366=2
Patch currently in -mm.
Thanks,
Ananth
>
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
>
> ---
> commit 1ee2dc5300b1c454f92eeea82da300f72db1b26f
> tree c73cdacb43e154292708d967e11b1cbf7ab4904f
> parent c0d4d573feed199b16094c072e7cb07afb01c598
> author Kumar Gala <[EMAIL PROTECTED]> Mon, 29 Jan 2007 23:38:11
> -0600
> committer Kumar Gala <[EMAIL PROTECTED]> Mon, 29 Jan 2007 23:38:11
> -0600
>
> kernel/kprobes.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 17ec4af..514276f 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -212,7 +212,7 @@ static int __kprobes collect_garbage_slots(void)
> continue;
> kip->ngarbage = 0; /* we will collect all garbages */
> for (i = 0; i < INSNS_PER_PAGE; i++) {
> - if (kip->slot_used[i] == -1 &&
> + if (kip->slot_used[i] == (char)-1 &&
> collect_one_slot(kip, i))
> break;
> }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
Andi Kleen wrote: Next is the issue of subjects. Last year the final list came out a few days before the summit started, making it impossible for people who were not attending the summit to prepare material for those attending to present/include on their behalf. I think you completely miss the point of KS here. It is not the venue for someone presenting long material on something and "selling" it, but for free discussion on specific topics. That is why the invitee list is so closely controlled to make sure these productions are productive. Last year the subject of DMA engines was put up, however most of the people interested in the subject weren't even invited. In that case there's really little concrete that can come out of the discussion. Expecting everyone to sit down and get the full picture of a subject in 5 minutes is unrealistic and will not lead to very useful outcome. If there are any presentations they should be very short and merely be a quick intro -- anything elaborate is not really welcome. That's quite different from other conferences. Of course, thats why I suggested more like an abstract published in advance, like why is this subject worthy and what would the person like to achieve by having it discussed. Hopefully with some technical ideas included. Cheers, Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
Dave Jones wrote: On Tue, Jan 30, 2007 at 05:51:00AM +0100, Jes Sorensen wrote: > I'm not too bothered about the subjects, but rather the issue that we > keep seeing this strict "only this small group, which defines the most > important people in the community" thing. I don't think it's intentionally meant to come across that way. Not being invited to kernel-summit shouldn't be interpreted as "you're not good enough" in any way or form. True, but unfortunately the KS has gotten itself a real bad reputation for being a closed club of the same people meeting year after year. If this is warranted or not is open to discussion, but at least thats the general message I get when I talk to people and the subject of KS is brought up. When Jon posted how the selection process worked last year a few people (yourself included iirc) brought up concerns, but it seems no-one has any real answers on how to improve things beyond the status quo. In this case I think Andrew's suggestion of trying to twist it more towards the traditional conference style would be worth investigating. The other issue here is that at least historically it has felt a bit like pounding sand when anyone trying to state that the summit wasn't working too well as it has been operating the last couple of years. It hasn't gotten easier by us shrinking in size slightly each year too. This has both positive and negative points. Yes, more people are going to get left out, but there's a point where so many voices in a room just becomes uncontrollable, especially when it's a room full of people with strong opinions. A number of people mentioned last year that the level of interaction during the sessions seemed higher than ever, with less people staring at laptops, and actually getting involved in what was happening in the room. I strongly believe that the lower head count was responsible for this. Well laptops are a problem, but I think some of this can be addressed mostly at the on-site level. The other problem is often that people are not interested or prepared for a given subject and therefore ignore it. I think the requirement of having an abstract submitted in advance could help here too. The one solution (well, in part) to the lower headcount last year was the addition of the mini-summits. If we had invited all the power management guys, all the networking guys, all the wireless guys etc etc we would probably have doubled in size. In future I wouldn't be surprised if these specialised summits happen more often. Even the mini summits have the problem of being selective and some projects are more likely to be included than others. For some projects it's a lot more clear that there's a specific lead on it, whereas others, such as file systems it's many very different projects in parallel with different requirements. That said, I think using the KS as more of an overall architecture handling summit and leaving more specifics to the mini summits is a good way to go. Cheers, Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kprobes: Fix compiler warning
On ppc the compiler gripes about:
kernel/kprobes.c: In function 'collect_garbage_slots':
kernel/kprobes.c:215: warning: comparison is always false due to limited range
of data type
The compiler ends up optimizing away the test since char's are unsigned on ppc.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
commit 1ee2dc5300b1c454f92eeea82da300f72db1b26f
tree c73cdacb43e154292708d967e11b1cbf7ab4904f
parent c0d4d573feed199b16094c072e7cb07afb01c598
author Kumar Gala <[EMAIL PROTECTED]> Mon, 29 Jan 2007 23:38:11 -0600
committer Kumar Gala <[EMAIL PROTECTED]> Mon, 29 Jan 2007 23:38:11 -0600
kernel/kprobes.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 17ec4af..514276f 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -212,7 +212,7 @@ static int __kprobes collect_garbage_slots(void)
continue;
kip->ngarbage = 0; /* we will collect all garbages */
for (i = 0; i < INSNS_PER_PAGE; i++) {
- if (kip->slot_used[i] == -1 &&
+ if (kip->slot_used[i] == (char)-1 &&
collect_one_slot(kip, i))
break;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: + mm-search_binary_handler-mem-limit-fix.patch added to -mm tree
> > > The function changes mem limit to USER_DS before possible modprobe, but > > > never restored it again. Truly. The road to hell is paved with good intentions. Martin Schwidefsky <[EMAIL PROTECTED]> writes: > On Mon, 2007-01-29 at 09:37 -0800, Andrew Morton wrote: >> hm, thanks for testing - I'll drop it. >> >> I don't really understand what's wrong with it though. Maybe it's settng >> USER_DS on kernel threads? > > For architectures with a split address space there has to be a call > set_fs(USER_DS) that switches from KERNEL_DS to USER_DS for the init > process. So far this has been done in search_binary_handler and > traditionally the kernel starts with KERNEL_DS to make the early > copy_from_user calls work. > So, what is wrong with always setting USER_DS? We are starting a user > space process after all. May be add some comment to prevent future attempts to make this place more "correct"? > > -- > blue skies, > Martin. > > Martin Schwidefsky > Linux for zSeries Development & Services > IBM Deutschland Entwicklung GmbH > > "Reality continues to ruin my life." - Calvin. > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] AGPGART compat ioctl
Hi Christoph,
Thanks for the input. The following has your recommendations;
drivers/char/agp/Makefile |1
drivers/char/agp/agp.h |2
drivers/char/agp/compat_ioctl.c | 282
drivers/char/agp/compat_ioctl.h | 105 ++
drivers/char/agp/frontend.c | 31 ++--
5 files changed, 407 insertions(+), 14 deletions(-)
Index: linux-2.6.20-rc4-mm1/drivers/char/agp/Makefile
===
RCS file: /home/cvsroot/linux-2.6.20-rc4-mm1/drivers/char/agp/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 Makefile
--- linux-2.6.20-rc4-mm1/drivers/char/agp/Makefile 27 Jan 2007 22:03:38
- 1.1.1.1
+++ linux-2.6.20-rc4-mm1/drivers/char/agp/Makefile 30 Jan 2007 04:42:21
-
@@ -1,6 +1,7 @@
agpgart-y := backend.o frontend.o generic.o isoch.o
obj-$(CONFIG_AGP) += agpgart.o
+obj-$(CONFIG_COMPAT) += compat_ioctl.o
obj-$(CONFIG_AGP_ALI) += ali-agp.o
obj-$(CONFIG_AGP_ATI) += ati-agp.o
obj-$(CONFIG_AGP_AMD) += amd-k7-agp.o
Index: linux-2.6.20-rc4-mm1/drivers/char/agp/agp.h
===
RCS file: /home/cvsroot/linux-2.6.20-rc4-mm1/drivers/char/agp/agp.h,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 agp.h
--- linux-2.6.20-rc4-mm1/drivers/char/agp/agp.h 27 Jan 2007 22:03:38 -
1.1.1.1
+++ linux-2.6.20-rc4-mm1/drivers/char/agp/agp.h 30 Jan 2007 04:05:33 -
@@ -298,6 +298,8 @@ extern struct aper_size_info_16 agp3_gen
extern int agp_off;
extern int agp_try_unsupported_boot;
+long compat_agp_ioctl(struct file *file, unsigned int cmd, unsigned long arg);
+
/* Chipset independant registers (from AGP Spec) */
#define AGP_APBASE 0x10
Index: linux-2.6.20-rc4-mm1/drivers/char/agp/compat_ioctl.c
===
RCS file: linux-2.6.20-rc4-mm1/drivers/char/agp/compat_ioctl.c
diff -N linux-2.6.20-rc4-mm1/drivers/char/agp/compat_ioctl.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ linux-2.6.20-rc4-mm1/drivers/char/agp/compat_ioctl.c30 Jan 2007
05:15:44 -
@@ -0,0 +1,282 @@
+/*
+ * AGPGART driver frontend compatibility ioctls
+ * Copyright (C) 2004 Silicon Graphics, Inc.
+ * Copyright (C) 2002-2003 Dave Jones
+ * Copyright (C) 1999 Jeff Hartmann
+ * Copyright (C) 1999 Precision Insight, Inc.
+ * Copyright (C) 1999 Xi Graphics, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * JEFF HARTMANN, OR ANY OTHER CONTRIBUTORS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE
+ * OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include "agp.h"
+#include "compat_ioctl.h"
+
+static int compat_agpioc_info_wrap(struct agp_file_private *priv, void __user
*arg)
+{
+ struct agp_info32 userinfo;
+ struct agp_kern_info kerninfo;
+
+ agp_copy_info(agp_bridge, );
+
+ userinfo.version.major = kerninfo.version.major;
+ userinfo.version.minor = kerninfo.version.minor;
+ userinfo.bridge_id = kerninfo.device->vendor |
+ (kerninfo.device->device << 16);
+ userinfo.agp_mode = kerninfo.mode;
+ userinfo.aper_base = (compat_long_t)kerninfo.aper_base;
+ userinfo.aper_size = kerninfo.aper_size;
+ userinfo.pg_total = userinfo.pg_system = kerninfo.max_memory;
+ userinfo.pg_used = kerninfo.current_memory;
+
+ if (copy_to_user(arg, , sizeof(userinfo)))
+ return -EFAULT;
+
+ return 0;
+}
+
+static int compat_agpioc_reserve_wrap(struct agp_file_private *priv, void
__user *arg)
+{
+ struct agp_region32 ureserve;
+ struct agp_region kreserve;
+ struct agp_client *client;
+ struct agp_file_private *client_priv;
+
+ DBG("");
+ if (copy_from_user(, arg, sizeof(ureserve)))
+ return -EFAULT;
+
+ if ((unsigned) ureserve.seg_count >= ~0U/sizeof(struct agp_segment32))
+ return -EFAULT;
+
+ kreserve.pid
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
On Tue, Jan 30, 2007 at 06:11:18AM +0100, Andi Kleen wrote: > On Tuesday 30 January 2007 04:41, Dave Jones wrote: > > > Right, other than during the CPU architects panel, I don't remember > > any non x86/ia64/ppc stuff being brought up at all. > > No IA64 stuff that I can remember. And there was a presentation on PPC. > > But that was planned to be differently with more focus on embedded, > unfortunately the comittee didn't manage to find more embedded CPU > people in time. given we barely had enough time for freescale, perhaps that was for the best. > My personal preference would be to go for a chipset panel this year > instead. Chipsets seem to impact kernels much more than CPUs. That could be interesting. I wonder if its worth doing both ? Depends if enough people are bored with CPU panels I guess :) Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
On Tue, Jan 30, 2007 at 05:51:00AM +0100, Jes Sorensen wrote: > I'm not too bothered about the subjects, but rather the issue that we > keep seeing this strict "only this small group, which defines the most > important people in the community" thing. I don't think it's intentionally meant to come across that way. Not being invited to kernel-summit shouldn't be interpreted as "you're not good enough" in any way or form. > Thats where I think the > current model fails, even if someone has done a lot of work all over > Linux for years, doesn't mean said people are the ones driving things > this year. Right. I see your point, and attendance shouldn't be solely down to a "what have you done for me lately?" decision, which is why there are additional criteria. That still doesn't make the process perfect, but we're open to good solutions to solve the problem of trying to pick 80 or so people out of the hundreds of developers that make the first pass. When Jon posted how the selection process worked last year a few people (yourself included iirc) brought up concerns, but it seems no-one has any real answers on how to improve things beyond the status quo. It hasn't gotten easier by us shrinking in size slightly each year too. This has both positive and negative points. Yes, more people are going to get left out, but there's a point where so many voices in a room just becomes uncontrollable, especially when it's a room full of people with strong opinions. A number of people mentioned last year that the level of interaction during the sessions seemed higher than ever, with less people staring at laptops, and actually getting involved in what was happening in the room. I strongly believe that the lower head count was responsible for this. The one solution (well, in part) to the lower headcount last year was the addition of the mini-summits. If we had invited all the power management guys, all the networking guys, all the wireless guys etc etc we would probably have doubled in size. In future I wouldn't be surprised if these specialised summits happen more often. Perhaps one day even negating the need for kernel summit at all (unless it becomes two days of wrap ups and cpu architect roadmaps), well, maybe not, but hopefully it'll help at least partially address the concerns of developers who didn't get to be at the kernel summit. > Personally I think Andrew's suggestion is really good, turning it more > towards the traditional conference means people who have something they > want to say are more likely to push for things. It may indeed have merit. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc6-mm3
On Mon, 29 Jan 2007 23:50:51 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.20-rc6-mm3/ > > > > Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/ > > > > > > - Restored git-block.patch: mainly the block unplugging rework. The > > problematic CFQ updates have been taken out. > > > > - Restored the fsaio patches as a consequence. > > > > - A huge ACPI update. > > > > - A decent number of x86 patches have been temporarily dropped due to their > > clash against the ACPI update. > > > > - A few problems reported against 2.6.20-rc6-mm2 have been fixed. > > Now that kevent work has settled down, would you be open to including it > in -mm? > I just haven't had the bandwidth to track what's been happening there lately. The two main things which need to be done are - a detailed line-by-line review - for someone to gain a full understanding of the delta between and and to explain these differences to mortals and to convince themselves and the rest of us that we're all OK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
On Tue, 2007-01-30 at 05:51 +0100, Jes Sorensen wrote: > > So far though, there's been nothing proposed at all, so feel free > > to throw your hat in the ring, if nothing else, it'll kickstart > > the process. > > Actually I'm in the process of investigating launching a mini summit > cabal, which I think would cover most of my current issues :) Actually, perhaps we should track these more closely. At the moment we have mini summits in Networking Wireless Filesystems Storage Power Management And probably several others I can't remember. Right at the moment, the organisation and funding for all of these is completely ad-hoc, so if mini summits are the way to go, it would certainly be better to move them on to a more templated basis (so anyone wishing to organise one would know whom to go to for these things). James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
On Tuesday 30 January 2007 04:41, Dave Jones wrote: > Right, other than during the CPU architects panel, I don't remember > any non x86/ia64/ppc stuff being brought up at all. No IA64 stuff that I can remember. And there was a presentation on PPC. But that was planned to be differently with more focus on embedded, unfortunately the comittee didn't manage to find more embedded CPU people in time. My personal preference would be to go for a chipset panel this year instead. Chipsets seem to impact kernels much more than CPUs. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hidden SSID's
On Mon, Jan 29, 2007 at 10:52:20PM -0600, Larry Finger wrote: > When an AP has a hidden SSID, ieee80211 fails, at least with wpa_supplicant, > which searches through the scan data looking for a particular ssid. Because > ieee80211 has substituted a false ssid, namely "", wpa_supplicant > cannot authenticate. This behavior is fixed by adding a new argument to > ieee80211_translate_scan that contains the expected ssid. Would this be replacing the SSID of all BSSes in scan results with the SSID for which the latest per-SSID scan was issued? If yes, this does not sound any better than the current behavior. The driver/802.11 code should not replace the SSID value with anything else than the value received from the AP. In case of hidden SSIDs, the 802.11 implementation should maintain a list of BSSes found during the scan(s) and update the SSID (in most cases, by creating a new BSS entry) with the SSID from Probe Response frames. In other words, if the scan is done for a specific SSID (Probe Request includes that SSID), the AP that is using hidden SSIDs will likely include the SSID in Probe Response and data from that Probe Response can be used to fill in the missing pieces for the pair. Generating false scan results by locally guessing what the SSID could be is just plain wrong. The scan results need to be based on real frames from the APs. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
> Next is the issue of subjects. Last year the final list came out a few > days before the summit started, making it impossible for people who were > not attending the summit to prepare material for those attending to > present/include on their behalf. I think you completely miss the point of KS here. It is not the venue for someone presenting long material on something and "selling" it, but for free discussion on specific topics. That is why the invitee list is so closely controlled to make sure these productions are productive. If there are any presentations they should be very short and merely be a quick intro -- anything elaborate is not really welcome. That's quite different from other conferences. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
Greg Ungerer wrote: Dave Jones wrote: Again, I don't recall us spending any time at all discussing m68k, or sparc, whilst the others you mention were well represented. Well, others where represented, I was there looking after non-mmu m68k for example (and other general non-mmu stuff). There just wasn't much contentious stuff in that space that needed wider discussion. Which is good, provided that non-mmu work is actively driving some of the decisions in mainline. Given that I don't follow the non-mmu work at all, I don't have a feel for whether that is the case, but I could imagine that it would have some impact that needs to be taken into account at times. My worry is for spending time and slots on things / people dealing with classic architectures which are no longer being manufactured and are only being maintained in catch-up mode. Cheers, Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] vmi: cleanups
Adrian Bunk wrote: This patch contains the following cleanups: - make needlessly global code static - remove pointless fastcall annotations - don't mark functions in C files as inline - #if 0 the following unused function: - arch/i386/kernel/vmitime.c: read_stolen_cycles() Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Acked-by: Zachary Amsden <[EMAIL PROTECTED]> Thanks Adrian! I have some more bugfix / cleanup patches queued up, but somehow I think you magically avoided creating conflicts with them. Zach - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hidden SSID's
Dan Williams wrote:
> On Mon, 2007-01-29 at 19:09 -0800, Jouni Malinen wrote:
>> On Mon, Jan 29, 2007 at 08:00:11AM -0500, Dan Williams wrote:
>>
>>> Well, there's no way a userspace program could depend on all hidden SSID
>>> APs having the tag, since if you stick in another,
>>> non-ieee80211-stack card it won't be like that. So I don't think we
>>> should care about in d80211, but I don't think we can remove it
>>> from ieee80211 either.
>> Use of '' is just not acceptable. IMHO, it should be removed
>> from everywhere, including net/ieee80211. The sooner this is done, the
>> better.
>
> You're probably right. Lets just pull it out of ieee80211 and be done.
Before it gets pulled, please look at this patch.
Larry
===
When an AP has a hidden SSID, ieee80211 fails, at least with wpa_supplicant,
which searches through the scan data looking for a particular ssid. Because
ieee80211 has substituted a false ssid, namely "", wpa_supplicant
cannot authenticate. This behavior is fixed by adding a new argument to
ieee80211_translate_scan that contains the expected ssid. A new routine,
ieee80211_wx_get_scan_essid, has an additional argument that contains the essid
of the AP that wpa_supplicant is trying to find. The existing routine,
ieee80211_wx_get_scan, calls the new one with the false ssid. The code in
ieee80211softmac is also modified to use the new routine and has been tested
with bcm43xx.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
Index: linux-2.6/include/net/ieee80211.h
===
--- linux-2.6.orig/include/net/ieee80211.h
+++ linux-2.6/include/net/ieee80211.h
@@ -946,6 +946,11 @@ struct ieee80211_network {
struct list_head list;
};
+struct ieee80211_essid {
+ u8 len;
+ char data[IW_ESSID_MAX_SIZE];
+};
+
enum ieee80211_state {
IEEE80211_UNINITIALIZED = 0,
IEEE80211_INITIALIZED,
@@ -1296,6 +1301,10 @@ extern const struct ieee80211_channel *i
extern int ieee80211_wx_get_scan(struct ieee80211_device *ieee,
struct iw_request_info *info,
union iwreq_data *wrqu, char *key);
+extern int ieee80211_wx_get_scan_essid(struct ieee80211_device *ieee,
+struct iw_request_info *info,
+union iwreq_data *wrqu, char *key,
+struct ieee80211_essid *essid);
extern int ieee80211_wx_set_encode(struct ieee80211_device *ieee,
struct iw_request_info *info,
union iwreq_data *wrqu, char *key);
Index: linux-2.6/net/ieee80211/ieee80211_wx.c
===
--- linux-2.6.orig/net/ieee80211/ieee80211_wx.c
+++ linux-2.6/net/ieee80211/ieee80211_wx.c
@@ -44,7 +44,8 @@ static const char *ieee80211_modes[] = {
#define MAX_CUSTOM_LEN 64
static char *ieee80211_translate_scan(struct ieee80211_device *ieee,
char *start, char *stop,
- struct ieee80211_network *network)
+ struct ieee80211_network *network,
+ struct ieee80211_essid *essid)
{
char custom[MAX_CUSTOM_LEN];
char *p;
@@ -65,10 +66,10 @@ static char *ieee80211_translate_scan(st
iwe.cmd = SIOCGIWESSID;
iwe.u.data.flags = 1;
if (network->flags & NETWORK_EMPTY_ESSID) {
- iwe.u.data.length = sizeof("");
- start = iwe_stream_add_point(start, stop, , "");
+ iwe.u.data.length = min(essid->len, (u8) IW_ESSID_MAX_SIZE);
+ start = iwe_stream_add_point(start, stop, , essid->data);
} else {
- iwe.u.data.length = min(network->ssid_len, (u8) 32);
+ iwe.u.data.length = min(network->ssid_len, (u8)
IW_ESSID_MAX_SIZE);
start = iwe_stream_add_point(start, stop, , network->ssid);
}
@@ -247,9 +248,15 @@ static char *ieee80211_translate_scan(st
#define SCAN_ITEM_SIZE 128
-int ieee80211_wx_get_scan(struct ieee80211_device *ieee,
+static struct ieee80211_essid hidden_essid = {
+ .len = sizeof (""),
+ .data = {""},
+};
+
+int ieee80211_wx_get_scan_essid(struct ieee80211_device *ieee,
struct iw_request_info *info,
- union iwreq_data *wrqu, char *extra)
+ union iwreq_data *wrqu, char *extra,
+ struct ieee80211_essid *essid)
{
struct ieee80211_network *network;
unsigned long flags;
@@ -272,7 +279,7 @@ int ieee80211_wx_get_scan(struct ieee802
if (ieee->scan_age == 0 ||
time_after(network->last_scanned + ieee->scan_age, jiffies))
- ev = ieee80211_translate_scan(ieee, ev, stop,
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
Dave Jones wrote: > Then there is the issue of architectures, at least in my book KS should > focus on the ones that are really live and not in maintenance mode. > x86_64, x86_32, PPC, ia64, ARM seems to be the driving ones these days, > m68k, Sparc32, and others, somewhat less so . Again, I don't recall us spending any time at all discussing m68k, or sparc, whilst the others you mention were well represented. Hi Dave, I'm not too bothered about the subjects, but rather the issue that we keep seeing this strict "only this small group, which defines the most important people in the community" thing. Thats where I think the current model fails, even if someone has done a lot of work all over Linux for years, doesn't mean said people are the ones driving things this year. Personally I think Andrew's suggestion is really good, turning it more towards the traditional conference means people who have something they want to say are more likely to push for things. If one doesn't have something to say, then going to the KS is probably not the right thing. One of the problems with this approach is sometimes we don't know about subjects that become important to us all until the last minute, and others that seem important now will become moot by the time the summit comes around. Thats true, and there should certainly be space for new subjects coming in on short notice. However, I would suggest that at least a significant portion of the summit applies this requirement. Most of the more important issues are architectural and it's often not something that shows up last minute. So far though, there's been nothing proposed at all, so feel free to throw your hat in the ring, if nothing else, it'll kickstart the process. Actually I'm in the process of investigating launching a mini summit cabal, which I think would cover most of my current issues :) Cheers, Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc6-mm3
Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.20-rc6-mm3/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/ - Restored git-block.patch: mainly the block unplugging rework. The problematic CFQ updates have been taken out. - Restored the fsaio patches as a consequence. - A huge ACPI update. - A decent number of x86 patches have been temporarily dropped due to their clash against the ACPI update. - A few problems reported against 2.6.20-rc6-mm2 have been fixed. Now that kevent work has settled down, would you be open to including it in -mm? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20-rc6-mm3
Temporarily at http://userweb.kernel.org/~akpm/2.6.20-rc6-mm3/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/ - Restored git-block.patch: mainly the block unplugging rework. The problematic CFQ updates have been taken out. - Restored the fsaio patches as a consequence. - A huge ACPI update. - A decent number of x86 patches have been temporarily dropped due to their clash against the ACPI update. - A few problems reported against 2.6.20-rc6-mm2 have been fixed. Boilerplate: - See the `hot-fixes' directory for any important updates to this patchset. - To fetch an -mm tree using git, use (for example) git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1 git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1 - -mm kernel commit activity can be reviewed by subscribing to the mm-commits mailing list. echo "subscribe mm-commits" | mail [EMAIL PROTECTED] - If you hit a bug in -mm and it is not obvious which patch caused it, it is most valuable if you can perform a bisection search to identify which patch introduced the bug. Instructions for this process are at http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt But beware that this process takes some time (around ten rebuilds and reboots), so consider reporting the bug first and if we cannot immediately identify the faulty patch, then perform the bisection search. - When reporting bugs, please try to Cc: the relevant maintainer and mailing list on any email. - When reporting bugs in this kernel via email, please also rewrite the email Subject: in some manner to reflect the nature of the bug. Some developers filter by Subject: when looking for messages to read. - Semi-daily snapshots of the -mm lineup are uploaded to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on the mm-commits list. Changes since 2.6.20-rc6-mm2: origin.patch git-acpi.patch git-ibm-acpi.patch git-alsa.patch git-agpgart.patch git-arm.patch git-avr32.patch git-cpufreq.patch git-powerpc.patch git-drm.patch git-dvb.patch git-gfs2-nmw.patch git-hid.patch git-ieee1394.patch git-infiniband.patch git-input.patch git-jfs.patch git-libata-all.patch git-lxdialog.patch git-mips.patch git-mmc.patch git-mtd.patch git-ubi.patch git-netdev-all.patch git-net.patch git-ioat.patch git-ocfs2.patch git-pciseg.patch git-s390.patch git-sh.patch git-scsi-misc.patch git-scsi-rc-fixes.patch git-block.patch git-qla3xxx.patch git-unionfs.patch git-watchdog.patch git-ipwireless_cs.patch git-cryptodev.patch git-gccbug.patch git trees -bonding-arp-monitoring-broken-on-x86_64.patch -powerpc-fix-sys_pciconfig_iobase-bus-matching.patch -netfilter-is-subscribers-only.patch -remove-useless-reference-to-obsolete-kerneld.patch -sound-isa-gus-gus_mainc-use-abs-instead-of-x-0-x-x.patch -fix-gfs2-circular-dependency.patch -git-ieee1494-build-fix.patch -git-netdev-all-fixup.patch -pnpacpi-remove-experimental-dependency.patch -cdevh-forward-declarations.patch Merged into mainline or a subsystem tree. +fuse-fix-bug-in-control-filesystem-mount.patch +cdevh-forward-declarations.patch +fix-via-irq-quirk-breakage.patch +i386-in-assign_irq_vector-look-at-all-vectors-before-giving-up.patch +translate-dashes-in-filenames-for-headers-install.patch +remove-warning-vfs-is-out-of-sync-with-lock-manager.patch +scsi_ioctl-sg_io-timeout-conversion-fix.patch +fix-for-patch-ecdfc9787fe527491baefc22dce8b2dbd5b2908d.patch 2.6.20 queue. +enable-mouse-button-23-emulation-for-x86-macs.patch Might be 2.6.20. -x86-fix-vdso-mapping-for-aout-executables-fixes.patch -x86-fix-vdso-mapping-for-aout-executables-fixes-2.patch -x86-fix-vdso-mapping-for-aout-executables-cleanups.patch -x86-fix-vdso-mapping-for-aout-executables-doh.patch -x86-fix-vdso-mapping-for-aout-executables-sh-fix.patch -x86-fix-vdso-mapping-for-aout-executables-x86_64-fixpatch.patch Folded into x86-fix-vdso-mapping-for-aout-executables.patch +acpi-updates-rtc-cmos-device-platform_data-vs-git-acpi.patch Update acpi-updates-rtc-cmos-device-platform_data.patch for git-acpi. +drivers-acpi-hotkeyc-make-2-structs-static.patch ACPI cleanup +powerpc-rtas-msi-support.patch powerpc MSI support +spider-fix-gregkh-driver-network-device.patch Fix gregkh patch +drivers-media-video-cafe_ccicc-fix-warning.patch +cx88-videoc-remove-struct-radionorms.patch +if-0-v4l_printk_ioctl_arg.patch DVB things +tsl2550-support-i2c-device-driver.patch I2C driver +config_input_debug-improvements.patch input Kconfig tweaks +make-help-in-build-tree-doesnt-show-headers_-targets.patch +kbuild-remove-references-to-deprecated-prepare-all-target.patch +new-toplevel-target-headers_check_all.patch kbuild things +libata-fix-translation-for-start-stop-unit.patch libata fix
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
On Tue, Jan 30, 2007 at 01:08:26PM +0900, Paul Mundt wrote: > On Tue, Jan 30, 2007 at 02:01:07PM +1000, Greg Ungerer wrote: > > Dave Jones wrote: > > >Right, other than during the CPU architects panel, I don't remember > > >any non x86/ia64/ppc stuff being brought up at all. > > > > Yep. IIRC the CPU architects panel was all x86/x86_64/ppc too wasn't it? > > > Similarly, it would be nice if we could avoid marketing oriented CPU > roadmap presentations this year, before any other vendors start > getting ideas.. It might be worth putting together a list of do's and don'ts for the CPU architects if we have a panel again this year (and its usually a fairly popular session, so I'd be surprised if it got dropped). something along the lines of Do: - Detail what new features next-gen cpu out in Q1'08 will have that we may need to care about - Ask for input on what features _we_ would like in CPUs in Q1 2010 - Tell us how we're taking advantage of things before that other OS, it makes us happy ;) Don't: - Waffle about process shrink roadmaps. Whilst it's good to hear, it doesn't affect the code we write. - Moves to new substrates are fascinating to CPU manufacturers, not so much for kernel engineers. - If something can't be discussed other than under NDA, don't bother bringing it up. Those interested will likely find out about it through their employers anyway. This came up last year with a number of "we can't tell you" reponses, which made one presentation almost worthless. or perhaps it was particularly "we can't tell hch" :-) Any others? Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug report : reproducible memory bug (hardware failure, sorry)
I finally re-ran memtest86 on the machine since it began to have too many different kind of errors (GPF, invalid instruction...). It turned out that one of the memory modules was bad. I guess my brand new list_debug race condition debugger will be useful in the future, but not now. :) I'll remember to let memtest86 run a few hours more on my new machines next time. Heh, well that's a lot less confusing at least ;-) M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 LinuxKernel Summit
On 1/29/07 8:22 PM, "Greg Ungerer" <[EMAIL PROTECTED]> wrote: >>> Yep. IIRC the CPU architects panel was all x86/x86_64/ppc too wasn't it? >> >> I thought there was coldfire mentioned too, or maybe my memory is >> playing tricks on me. Maybe I'm misremembering the ppc bit. > > Your right, the person from Freescale did mention it. Oops yeah. Hit send to early. The presenter from Freescale spoke about PPC as well. /D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 LinuxKernel Summit
On 1/29/07 8:10 PM, "Dave Jones" <[EMAIL PROTECTED]> wrote: > > Again, I don't recall us spending any time at all discussing m68k, or > sparc, whilst the others you mention were well represented. Well, others where represented, I was there looking after non-mmu m68k for example (and other general non-mmu stuff). There just wasn't much contentious stuff in that space that needed wider discussion. >>> >>> Right, other than during the CPU architects panel, I don't remember >>> any non x86/ia64/ppc stuff being brought up at all. >> >> Yep. IIRC the CPU architects panel was all x86/x86_64/ppc too wasn't it? > > I thought there was coldfire mentioned too, or maybe my memory is > playing tricks on me. Maybe I'm misremembering the ppc bit. I believe we had AMD, Freescale and Intel last year, no PPC. /D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Cbe-oss-dev] [RFC, PATCH 3/4] Add support to OProfile for profiling Cell BE SPUs -- update
On Monday 29 January 2007 20:48, Maynard Johnson wrote:
> Subject: Enable SPU switch notification to detect currently active SPU tasks.
>
> From: Maynard Johnson <[EMAIL PROTECTED]>
>
> This patch adds to the capability of spu_switch_event_register so that the
> caller is also notified of currently active SPU tasks. It also exports
> spu_switch_event_register and spu_switch_event_unregister.
>
> Signed-off-by: Maynard Johnson <[EMAIL PROTECTED]>
I looked through it again, and think I found a serious bug, but that
should be easy enough to solve:
> +static void notify_spus_active(void)
> +{
> + int node;
> + /* Wake up the active spu_contexts. When the awakened processes
> +* sees their notify_active flag is set, they will call
> +* spu_switch_notify();
> +*/
> + for (node = 0; node < MAX_NUMNODES; node++) {
> + struct spu *spu;
> + mutex_lock(_prio->active_mutex[node]);
> +list_for_each_entry(spu, _prio->active_list[node], list)
> {
> + struct spu_context *ctx = spu->ctx;
[side note]
There is a small whitespace breakage in here, please make sure you always
use tabs for indenting, not space characters.
[/side note]
> @@ -45,9 +45,10 @@
> u64 pte_fault;
>
> *stat = ctx->ops->status_read(ctx);
> - if (ctx->state != SPU_STATE_RUNNABLE)
> - return 1;
> +
> spu = ctx->spu;
> + if (ctx->state != SPU_STATE_RUNNABLE || spu->notify_active)
> + return 1;
> pte_fault = spu->dsisr &
> (MFC_DSISR_PTE_NOT_FOUND | MFC_DSISR_ACCESS_DENIED);
> return (!(*stat & 0x1) || pte_fault || spu->class_0_pending) ? 1 : 0;
> @@ -305,6 +306,7 @@
>u32 *npc, u32 *event)
> {
> int ret;
> + struct spu * spu;
> u32 status;
>
> if (down_interruptible(>run_sema))
> @@ -318,8 +320,16 @@
>
> do {
> ret = spufs_wait(ctx->stop_wq, spu_stopped(ctx, ));
> + spu = ctx->spu;
> if (unlikely(ret))
> break;
> + if (unlikely(spu->notify_active)) {
> + spu->notify_active = 0;
> + if (!(status & SPU_STATUS_STOPPED_BY_STOP)) {
> + spu_switch_notify(spu, ctx);
> + continue;
> + }
> + }
This is before spu_reacquire_runnable, so in case the spu got
preempted at the same time when oprofile was enabled, ctx->spu
is NULL, and you can't load the notify_active flag from it.
On solution would be to move the notify_active flag from ctx->spu
into ctx itself, but maybe there are other ways to solve this.
Thanks,
Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
Dave Jones wrote: On Tue, Jan 30, 2007 at 02:01:07PM +1000, Greg Ungerer wrote: > > > > Again, I don't recall us spending any time at all discussing m68k, or > > > > sparc, whilst the others you mention were well represented. > > > > > > Well, others where represented, I was there looking after non-mmu m68k > > > for example (and other general non-mmu stuff). There just wasn't much > > > contentious stuff in that space that needed wider discussion. > > > > Right, other than during the CPU architects panel, I don't remember > > any non x86/ia64/ppc stuff being brought up at all. > > Yep. IIRC the CPU architects panel was all x86/x86_64/ppc too wasn't it? I thought there was coldfire mentioned too, or maybe my memory is playing tricks on me. Maybe I'm misremembering the ppc bit. Your right, the person from Freescale did mention it. Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm] jmicron: 40/80pin primary detection
Patch is against 2.6.20-rc6-mm2, jmicron module detects all JMB36x as JMB361
and PATA0 has wrong pin status of XICBLID.
--- a/drivers/ide/pci/jmicron.c 2007-01-30 10:08:35.0 +0800
+++ b/drivers/ide/pci/jmicron.c 2007-01-30 10:11:31.0 +0800
@@ -70,8 +70,8 @@
{
case PORT_PATA0:
if (control & (1 << 3)) /* 40/80 pin primary */
- return 1;
- return 0;
+ return 0;
+ return 1;
case PORT_PATA1:
if (control5 & (1 << 19)) /* 40/80 pin secondary */
return 0;
@@ -205,11 +205,11 @@
}
static struct pci_device_id jmicron_pci_tbl[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB361), 0},
- { PCI_DEVICE(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB363), 1},
- { PCI_DEVICE(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB365), 2},
- { PCI_DEVICE(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB366), 3},
- { PCI_DEVICE(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB368), 4},
+ { PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB361, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
+ { PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB363, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 1},
+ { PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB365, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 2},
+ { PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB366, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 3},
+ { PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB368, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 4},
{ 0, },
};
Best Regards,
Ethan Hsiao
智微科技股份有限公司 ( JMicron Technology )
新竹科學工業園區新竹縣創新一路13號1F
1F,No. 13, Innovation Road 1, Science-Based Industrial Park,
Hsinchu, Taiwan.
Tel : 886-3-579-7389 # 8729
Fax : 886-3-579-9566
jmicron.c.patch
Description: Binary data
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
On Tue, Jan 30, 2007 at 02:01:07PM +1000, Greg Ungerer wrote: > > > > Again, I don't recall us spending any time at all discussing m68k, or > > > > sparc, whilst the others you mention were well represented. > > > > > > Well, others where represented, I was there looking after non-mmu m68k > > > for example (and other general non-mmu stuff). There just wasn't much > > > contentious stuff in that space that needed wider discussion. > > > > Right, other than during the CPU architects panel, I don't remember > > any non x86/ia64/ppc stuff being brought up at all. > > Yep. IIRC the CPU architects panel was all x86/x86_64/ppc too wasn't it? I thought there was coldfire mentioned too, or maybe my memory is playing tricks on me. Maybe I'm misremembering the ppc bit. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
Dave Jones wrote: On Tue, Jan 30, 2007 at 01:06:17AM +0100, Jes Sorensen wrote: > Then there is the issue of architectures, at least in my book KS should > focus on the ones that are really live and not in maintenance mode. > x86_64, x86_32, PPC, ia64, ARM seems to be the driving ones these days, > m68k, Sparc32, and others, somewhat less so . Again, I don't recall us spending any time at all discussing m68k, or sparc, whilst the others you mention were well represented. Well, others where represented, I was there looking after non-mmu m68k for example (and other general non-mmu stuff). There just wasn't much contentious stuff in that space that needed wider discussion. Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
On Tue, Jan 30, 2007 at 02:01:07PM +1000, Greg Ungerer wrote: > Dave Jones wrote: > >Right, other than during the CPU architects panel, I don't remember > >any non x86/ia64/ppc stuff being brought up at all. > > Yep. IIRC the CPU architects panel was all x86/x86_64/ppc too wasn't it? > Similarly, it would be nice if we could avoid marketing oriented CPU roadmap presentations this year, before any other vendors start getting ideas.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Cbe-oss-dev] [RFC, PATCH 2/4] Add support to OProfile for profiling Cell BE SPUs -- update
On Monday 29 January 2007 20:47, Maynard Johnson wrote: > The code was setting up the debug bus for group 21 when profiling on the > event PPU CYCLES. The debug bus is not actually used by the hardware > performance counters when counting PPU CYCLES. Setting up the debug bus > for PPU CYCLES causes signal routing conflicts on the debug bus when > profiling PPU cycles and another PPU event. This patch fixes the code to > only setup the debug bus to route the performance signals for the non > PPU CYCLE events. > > Signed-off-by: Maynard Johnson <[EMAIL PROTECTED]> > Signed-off-by: Carl Love <[EMAIL PROTECTED]> Acked-by: Arnd Bergmann <[EMAIL PROTECTED]> Any suggestion for a one-line patch title? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Cbe-oss-dev] [RFC, PATCH 1/4] Add support to OProfile for profiling Cell BE SPUs -- update
On Monday 29 January 2007 20:46, Maynard Johnson wrote: > This is a clean up patch that includes the following changes: > > -It removes some macro definitions that are only used once > with the actual code. > -Some comments were added to clarify the code based on feedback > from the community. > -The write_pm_cntrl() and set_count_mode() were passed a structure > element from a global variable. The argument was removed so the > functions now just operate on the global directly. > -The set_pm_event() function call in the cell_virtual_cntr() routine > was moved to a for-loop before the for_each_cpu loop > > Signed-off-by: Carl Love <[EMAIL PROTECTED]> > Signed-off-by: Maynard Johnson <[EMAIL PROTECTED]> > Acked-by: Arnd Bergmann <[EMAIL PROTECTED]> Just a small side note: Please give each of your patches a one-line summary in the subject of the email. I'm filing this one under: "cell: oprofile cleanup". It would also be good if you could use a mailer that sends out patches as inline, so you don't need to resort to using attachments. Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
Dave Jones wrote: On Tue, Jan 30, 2007 at 01:30:56PM +1000, Greg Ungerer wrote: > > Dave Jones wrote: > > On Tue, Jan 30, 2007 at 01:06:17AM +0100, Jes Sorensen wrote: > > > Then there is the issue of architectures, at least in my book KS should > > > focus on the ones that are really live and not in maintenance mode. > > > x86_64, x86_32, PPC, ia64, ARM seems to be the driving ones these days, > > > m68k, Sparc32, and others, somewhat less so . > > > > Again, I don't recall us spending any time at all discussing m68k, or > > sparc, whilst the others you mention were well represented. > > Well, others where represented, I was there looking after non-mmu m68k > for example (and other general non-mmu stuff). There just wasn't much > contentious stuff in that space that needed wider discussion. Right, other than during the CPU architects panel, I don't remember any non x86/ia64/ppc stuff being brought up at all. Yep. IIRC the CPU architects panel was all x86/x86_64/ppc too wasn't it? Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
Dave Jones wrote: On Tue, Jan 30, 2007 at 01:30:56PM +1000, Greg Ungerer wrote: > > Dave Jones wrote: > > On Tue, Jan 30, 2007 at 01:06:17AM +0100, Jes Sorensen wrote: > > > Then there is the issue of architectures, at least in my book KS should > > > focus on the ones that are really live and not in maintenance mode. > > > x86_64, x86_32, PPC, ia64, ARM seems to be the driving ones these days, > > > m68k, Sparc32, and others, somewhat less so . > > > > Again, I don't recall us spending any time at all discussing m68k, or > > sparc, whilst the others you mention were well represented. > > Well, others where represented, I was there looking after non-mmu m68k > for example (and other general non-mmu stuff). There just wasn't much > contentious stuff in that space that needed wider discussion. Right, other than during the CPU architects panel, I don't remember any non x86/ia64/ppc stuff being brought up at all. Yep. IIRC the CPU architects panel was all x86/x86_64/ppc too wasn't it? Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tty: cleanup release_mem
On Mon, 29 Jan 2007 14:06:04 -0500 Alan Cox <[EMAIL PROTECTED]> wrote: > On Mon, Jan 29, 2007 at 07:12:35PM +0100, Christoph Hellwig wrote: > > Okay. Now that we get into the details I've also added some renaming, > > release_mem becomes release_tty and the new factored out function is > > release_one_tty. The difference is documented in the kdoc comments. > > > > > > Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]> > Acked-by: Alan Cox <[EMAIL PROTECTED]> VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 300k freed Write protecting the kernel read-only data: 920k BUG: unable to handle kernel paging request at virtual address 6b6b6bdf printing eip: c02a91ec *pde = Oops: [#1] SMP last sysfs file: /block/hdc/range Modules linked in: CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010286 (2.6.20-rc6-mm3 #1) EIP is at release_tty+0x2c/0x40 eax: 6b6b6b6b ebx: f71c860c ecx: c0175e24 edx: esi: edi: 0001 ebp: c222fe88 esp: c222fe80 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process init (pid: 1, ti=c222e000 task=c222cae0 task.ti=c222e000) Stack: f71c860c c222ff3c c02aac29 c22e453c c222fea0 0006 c222fec4 002ad15c 0001 0001 c06650a0 01d8 c222ff24 c013d53f c0178d34 f7c383c4 c222ff20 Call Trace: [] show_trace_log_lvl+0x1a/0x30 [] show_stack_log_lvl+0xa8/0xe0 [] show_registers+0x1e9/0x2f0 [] die+0x11a/0x250 [] do_page_fault+0x2f0/0x5f0 [] error_code+0x7c/0x84 [] release_dev+0x519/0x750 [] tty_release+0x12/0x20 [] __fput+0xb4/0x180 [] fput+0x22/0x40 [] filp_close+0x47/0x70 [] sys_close+0x6d/0xc0 [] sysenter_past_esp+0x5d/0x99 === Code: 89 e5 83 ec 08 89 1c 24 89 c3 89 74 24 04 89 d6 8b 80 fc 00 00 00 85 c0 74 05 e8 00 ff ff ff 89 f2 89 d8 e8 f7 fe ff ff 8b 43 04 <8b> 40 74 e8 8c b3 e9 ff 8b 1c 24 8b 74 24 04 89 ec 5d c3 90 55 EIP: [] release_tty+0x2c/0x40 SS:ESP 0068:c222fe80 Kernel panic - not syncing: Attempted to kill init! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] use __u32 in asm-x86_64/msr.h
On Mon, Jan 29, 2007 at 07:25:08PM -0500, Mike Frysinger wrote: > the checking_wrmsrl() macro in asm-x86_64/msr.h which is exported to > userspace > utilizes the u32 type instead of __u32 ... trivial attached patch fixes that Better would be to not export those macros to userspace at all, as they can't be used outside of ring 0 anyway. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
Dave Jones wrote: On Tue, Jan 30, 2007 at 01:06:17AM +0100, Jes Sorensen wrote: > Then there is the issue of architectures, at least in my book KS should > focus on the ones that are really live and not in maintenance mode. > x86_64, x86_32, PPC, ia64, ARM seems to be the driving ones these days, > m68k, Sparc32, and others, somewhat less so . Again, I don't recall us spending any time at all discussing m68k, or sparc, whilst the others you mention were well represented. Well, others where represented, I was there looking after non-mmu m68k for example (and other general non-mmu stuff). There just wasn't much contentious stuff in that space that needed wider discussion. Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: software read-only flag for rw partition or disk ?
"Yakov Lerner" <[EMAIL PROTECTED]> writes: > Does /proc have any entries to flip the "software read-only flag" > for a partition or disk (which are physically read-write) ? No, but you can use blockdev --setro /dev/hdXX Phil. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: O_NONBLOCK setting "leak" outside of a process??
Denis Vlasenko <[EMAIL PROTECTED]> writes:
> Hi,
>
> I am currently on Linux 2.6.18, x86_64.
> I came across strange behavior while working on one
> of busybox applets. I narrowed it down to these two
> trivial testcases:
>
> #include
> #include
> int main() {
> fcntl(0, F_SETFL, fcntl(0, F_GETFL, 0) | O_NONBLOCK);
> return 0;
> }
>
> #include
> #include
> int main() {
> fcntl(0, F_SETFL, fcntl(0, F_GETFL, 0) & ~O_NONBLOCK);
> return 0;
> }
>
> If I run "nonblock" in Midnight Commander in KDE's Konsole,
> screen redraw starts to work ~5 times slower. For example,
> Ctrl-O ("show/hide panels" in MC) takes ~0.5 sec to redraw.
> This persists after the program exist (which it
> does immediately as you see).
> Running "block" reverts things to normal.
>
> I mean: how can O_NONBLOCK _issued in a process which
> already exited_ have any effect whatsoever on MC or Konsole?
> They can't even know that it did it, right?
>
> Either I do not know something subtle about Unix or some sort
> of bug is at work.
Because they all share the same stdin file descriptor, therefore they
share the same file descriptor flags?
Phil.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
On Tue, Jan 30, 2007 at 01:30:56PM +1000, Greg Ungerer wrote: > > Dave Jones wrote: > > On Tue, Jan 30, 2007 at 01:06:17AM +0100, Jes Sorensen wrote: > > > Then there is the issue of architectures, at least in my book KS should > > > focus on the ones that are really live and not in maintenance mode. > > > x86_64, x86_32, PPC, ia64, ARM seems to be the driving ones these days, > > > m68k, Sparc32, and others, somewhat less so . > > > > Again, I don't recall us spending any time at all discussing m68k, or > > sparc, whilst the others you mention were well represented. > > Well, others where represented, I was there looking after non-mmu m68k > for example (and other general non-mmu stuff). There just wasn't much > contentious stuff in that space that needed wider discussion. Right, other than during the CPU architects panel, I don't remember any non x86/ia64/ppc stuff being brought up at all. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hidden SSID's
On Mon, Jan 29, 2007 at 08:00:11AM -0500, Dan Williams wrote: > Well, there's no way a userspace program could depend on all hidden SSID > APs having the tag, since if you stick in another, > non-ieee80211-stack card it won't be like that. So I don't think we > should care about in d80211, but I don't think we can remove it > from ieee80211 either. Use of '' is just not acceptable. IMHO, it should be removed from everywhere, including net/ieee80211. The sooner this is done, the better. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hidden SSID's
On Mon, 2007-01-29 at 19:09 -0800, Jouni Malinen wrote: > On Mon, Jan 29, 2007 at 08:00:11AM -0500, Dan Williams wrote: > > > Well, there's no way a userspace program could depend on all hidden SSID > > APs having the tag, since if you stick in another, > > non-ieee80211-stack card it won't be like that. So I don't think we > > should care about in d80211, but I don't think we can remove it > > from ieee80211 either. > > Use of '' is just not acceptable. IMHO, it should be removed > from everywhere, including net/ieee80211. The sooner this is done, the > better. You're probably right. Lets just pull it out of ieee80211 and be done. dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug report : reproducible memory bug (hardware failure, sorry)
* Martin J. Bligh ([EMAIL PROTECTED]) wrote: > Mathieu Desnoyers wrote: > >Hi, > > > >Trying to build cross-compilers (or kernels) on a 2-way x86_64 (amd64) with > >make -j3 triggers the following OOPS after about 30 minutes on > >2.6.19.2. Due to the amount of time and the heavy load it takes before it > >happens, I suspect a race condition. Memtest86 tests passed ok. The > >amount of swap used when the condition happens is about 52k and stable > >(only ~800MB/1GB are used). > > > >I am going to give it a look, but I suspect you might help narrowing it > >down more quickly. Any insight would be appreciated. > > Mmm. that's going to be messy to debug ... but didn't we already know > that kernel was racy? Or is 2.6.19.2 after that fix already? Does 20-rc6 > still break? Hi Martin, I finally re-ran memtest86 on the machine since it began to have too many different kind of errors (GPF, invalid instruction...). It turned out that one of the memory modules was bad. I guess my brand new list_debug race condition debugger will be useful in the future, but not now. :) I'll remember to let memtest86 run a few hours more on my new machines next time. Mathieu -- OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc6-mm1
Andrew Morton wrote: On Tue, 30 Jan 2007 08:12:31 +0530 Suparna Bhattacharya <[EMAIL PROTECTED]> wrote: On Sun, Jan 28, 2007 at 03:01:33PM -0800, Andrew Morton wrote: On Sun, 28 Jan 2007 08:56:08 -0800 "Martin J. Bligh" <[EMAIL PROTECTED]> wrote: - It seems that people have been busy creating the need for this. I had to apply over sixty patches to this tree to fix post-2.6.20-rc4-mm1 compilation errors. And a number of patches were dropped due to no-compile or to runtime errors. Heaven knows how many runtime bugs were added. dbench seems to panic on xfs / cfq ? OK, I'll dump git-block.patch. That means that the fsaio patches get temporarily dropped as well as they depend on git-block changes somewhat. Would you like me to rework these back again to not depend on git-block ? Is OK thanks, I now have a git-block minus CFQ changes, so I have restored the fsaio patches. On a happy note - mm2 seems to pass testing much better ;-) M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] namespaces: fix exit race by splitting exit
Quoting Herbert Poetzl ([EMAIL PROTECTED]): > On Thu, Jan 25, 2007 at 10:30:56PM -0800, Andrew Morton wrote: > > On Thu, 25 Jan 2007 23:26:59 -0600 > > "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > > > > > Fix exit race by splitting the nsproxy putting into two pieces. > > > First piece reduces the nsproxy refcount. If we dropped the last > > > reference, then it puts the mnt_ns, and returns the nsproxy as a > > > hint to the caller. Else it returns NULL. The second piece of > > > exiting task namespaces sets tsk->nsproxy to NULL, and drops the > > > references to other namespaces and frees the nsproxy only if an > > > nsproxy was passed in. > > > > > > A little awkward and should probably be reworked, but hopefully > > > it fixes the NFS oops. > > > > I'm a bit worried about jamming something like this into 2.6.20. > > Could the usual culprits please review this carefully with > > some urgency? > > okay, after integrating this into two Linux-VServer > branches and some testing, I can confirm that it > _seems_ to fix the nfs and related issues, but still, > I do not like it :) I don't either :) > here my issues with this approach: > > - the code is quite hard to read and can easily >lead to unexpected issues when spaces are >manipulated Yes, but I do think fixing the naming will help that. > - it breaks the basic get/put refcounting for >nsproxy references outside the task struct >i.e. we had to add a vs_put_nsproxy() which >does what the put_nsproxy() did before, to >keep and handle a reference to the nsproxy >from the context structure Was the put_and_finalize_nsproxy() not sufficient? > - the following scenario might become a problem >for future spaces (especially the pid space?) > > A B > > exit_task_namespaces_early() > exit_task_namespaces_early() > exit_notify() > exit_task_namespaces() > --- > exit_notify() > exit_task_namespaces() Confounded, you're right, the exit_task_namespaces() in B would see that B had reduced the nsproxy->count to 0, and free the nsproxy, so that exit_notify() in A would oops. And that should be triggerable right now. I'm afraid adding an extra refcount for the mounts is unavoidable. > note: I still consider it the best available fix > for this issues, especially as 2.6.20 is in a > late rc stage ... but IMHO the nfs threads should > be modified to handle the nsproxy disposal properly That *would* lead to much more readable code. > > And Daniel, if you can find time to runtime test it please? > > he did, looks like it works fine with vanilla too > (even when stressing the described cornercase) > > best, > Herbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Change constant zero to NOTIFY_DONE in ratelimit_handler()
Hello!
Change a hard-coded constant 0 to the symbolic equivalent NOTIFY_DONE
in the ratelimit_handler() CPU notifier handler function.
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---
page-writeback.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -urpNa -X dontdiff linux-2.6.20-rc6/mm/page-writeback.c
linux-2.6.20-rc6-ratelimit_handler-fix/mm/page-writeback.c
--- linux-2.6.20-rc6/mm/page-writeback.c2007-01-29 16:34:16.0
-0800
+++ linux-2.6.20-rc6-ratelimit_handler-fix/mm/page-writeback.c 2007-01-29
18:04:16.0 -0800
@@ -517,7 +517,7 @@ static int __cpuinit
ratelimit_handler(struct notifier_block *self, unsigned long u, void *v)
{
writeback_set_ratelimit();
- return 0;
+ return NOTIFY_DONE;
}
static struct notifier_block __cpuinitdata ratelimit_nb = {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: Re: [mm PATCH 4/6] RCU: (now) CPU hotplug
On Mon, Jan 29, 2007 at 08:12:41PM +0100, Ingo Molnar wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > The idea being to essentially suspend the system to RAM, remove the
> > > CPU and then unsuspend it? Seems like quite high overhead -- or am
> > > I misunderstanding the proposal?
> >
> > The process freezer basically wakes up all threads in the machine and
> > makes them go to sleep in a specific place, so they're all in a known
> > state. kernel threads are also captured, via their open-coded polling
> > call to try_to_freeze().
> >
> > The machine suspend code uses the process freezer, as does kprobes.
> > The freezer isn't tied to suspend or to power management.
> >
> > The freezer does have potential to be expensive if used frequently and
> > if there are many threads. But I don't think anyone has looked at
> > optimising it. [...]
>
> i've measured it and it takes a few milliseconds typically - certainly
> not noticeable even for hypothetical highly scripted CPU-hotplug
> environments. (i doubt they really exist in practice)
>
> in fact (new) kprobes uses the freezer, and it's far more performance
> sensitive than the handling of CPU hotplug events.
Outside of realtime workloads, I agree that performance should not be
a problem. And I don't know of any reason why realtime systems need to
be able to do hotplug CPU. Yet, anyway. ;-)
> And there was almost no effort put into making the freezer fast, i'm
> sure if it ever becomes a problem we could improve it quite drastically.
> And that effort would improve suspend performance and kprobes
> performance as well - while the cpu-hotplug locking hell is just an
> unneeded distraction nobody really can deal with properly. So i say lets
> ditch CPU hotplug locking completely and lets go for the dead-simple
> freezer based design ...
I never have seen anyone try a freezer-based approach, so why not?
However, it seems to me that the notifiers are still needed in some form
or another -- for example, RCU needs to manipulate its masks. My guess
is that you are proposing doing the CPU-down and CPU-up notifications
between the freeze_processes() and the thaw_processes().
Going through the list:
o migration_call() needs to create a kthread, which can fail,
so there still needs to be the dual phase bring-up, with
CPU_ONLINE and CPU_UP_CANCELED.
o comp_pool_callback() can also fail during CPU_UP_PREPARE,
as can kernel/softirq.c:cpu_callback(),
kernel/softlockup.c:cpu_callback(), timer_cpu_notify(),
ratelimit_handler() [which returns 0 rather than NOTIFY_DONE,
patch in separate email], pageset_cpuup_callback(), and
cpuup_callback().
o The following are unconditional: vmstat_cpuup_callback(),
sysfs_cpu_notify(), cpu_numa_callback(), hrtimer_cpu_notify(),
and rcu_cpu_notify().
o None of the notifier handlers currently say "no" to a CPU
going down, which is reassuring -- at least given that
move_task_off_dead_cpu() is willing to forcibly migrate
if needed.
OK, I indeed do not see any obvious dependencies amoung current CPU
notifier handlers, though the same-order up/down traversal still seems to
me to be an accident waiting to happen. However, this is independent of
the method to be used to bring CPUs up and down.
And yes, I did in fact suffer severe trauma due to same-order up/down
traversal in a previous life, involving (among other things) CPUs
attempting to do useful work with out-of-date TLBs and attempting to
execute RCU read-side critical sections on CPUs that were no longer
participating in grace-period processing. Not pretty. :-/ But I don't
immediately see similar issues in Linux at the moment (with the caveat
that I can't claim to be expert in every area using CPU notifiers), and
if such problems do arise, it is pretty easy to provide reverse-order
down traversal. The fact that RCU doesn't stop grace-period processing
until CPU_DEAD is at least somewhat comforting to me. ;-)
So the thought is to make _cpu_down() and _cpu_up() do something like
the following (untested, probably does not even compile), perhaps with
suitable adjustments elsewhere as well?
static int _cpu_down(unsigned int cpu)
{
int err;
struct task_struct *p;
cpumask_t old_allowed, tmp;
if (num_online_cpus() == 1)
return -EBUSY;
if (!cpu_online(cpu))
return -EINVAL;
if (freeze_processes()) {
err = -EBUSY;
goto out_freeze_notify_failed;
}
err = raw_notifier_call_chain(_chain, CPU_DOWN_PREPARE,
(void *)(long)cpu);
if (err == NOTIFY_BAD) {
printk("%s: attempt to take down CPU %u
Re: 2.6.20-rc6-mm1
On Tue, 30 Jan 2007 08:12:31 +0530 Suparna Bhattacharya <[EMAIL PROTECTED]> wrote: > On Sun, Jan 28, 2007 at 03:01:33PM -0800, Andrew Morton wrote: > > On Sun, 28 Jan 2007 08:56:08 -0800 > > "Martin J. Bligh" <[EMAIL PROTECTED]> wrote: > > > > > > - It seems that people have been busy creating the need for this. I > > > > had to > > > > apply over sixty patches to this tree to fix post-2.6.20-rc4-mm1 > > > > compilation > > > > errors. And a number of patches were dropped due to no-compile or to > > > > runtime errors. Heaven knows how many runtime bugs were added. > > > > > > dbench seems to panic on xfs / cfq ? > > > > OK, I'll dump git-block.patch. That means that the fsaio patches get > > temporarily dropped as well as they depend on git-block changes somewhat. > > Would you like me to rework these back again to not depend on git-block ? Is OK thanks, I now have a git-block minus CFQ changes, so I have restored the fsaio patches. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] namespaces: fix exit race by splitting exit
On Thu, Jan 25, 2007 at 10:30:56PM -0800, Andrew Morton wrote: > On Thu, 25 Jan 2007 23:26:59 -0600 > "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > > > Fix exit race by splitting the nsproxy putting into two pieces. > > First piece reduces the nsproxy refcount. If we dropped the last > > reference, then it puts the mnt_ns, and returns the nsproxy as a > > hint to the caller. Else it returns NULL. The second piece of > > exiting task namespaces sets tsk->nsproxy to NULL, and drops the > > references to other namespaces and frees the nsproxy only if an > > nsproxy was passed in. > > > > A little awkward and should probably be reworked, but hopefully > > it fixes the NFS oops. > > I'm a bit worried about jamming something like this into 2.6.20. > Could the usual culprits please review this carefully with > some urgency? okay, after integrating this into two Linux-VServer branches and some testing, I can confirm that it _seems_ to fix the nfs and related issues, but still, I do not like it :) here my issues with this approach: - the code is quite hard to read and can easily lead to unexpected issues when spaces are manipulated - it breaks the basic get/put refcounting for nsproxy references outside the task struct i.e. we had to add a vs_put_nsproxy() which does what the put_nsproxy() did before, to keep and handle a reference to the nsproxy from the context structure - the following scenario might become a problem for future spaces (especially the pid space?) A B exit_task_namespaces_early() exit_task_namespaces_early() exit_notify() exit_task_namespaces() --- exit_notify() exit_task_namespaces() note: I still consider it the best available fix for this issues, especially as 2.6.20 is in a late rc stage ... but IMHO the nfs threads should be modified to handle the nsproxy disposal properly > And Daniel, if you can find time to runtime test it please? he did, looks like it works fine with vanilla too (even when stressing the described cornercase) best, Herbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] TSL2550 support (I2C device driver)
On Mon, 29 Jan 2007 18:39:50 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > > attached a patch to add support for Taos TSL2550 ambient light sensors > > (http://www.taosinc.com/product_detail.asp?cateid=4=18). > > > > Some minor things: Oh, and please send a signoff for this work as per section 11 of Documentation/SubmittingPatches, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] TSL2550 support (I2C device driver)
On Tue, 30 Jan 2007 00:56:19 +0100
Rodolfo Giometti <[EMAIL PROTECTED]> wrote:
> Hello,
>
> attached a patch to add support for Taos TSL2550 ambient light sensors
> (http://www.taosinc.com/product_detail.asp?cateid=4=18).
>
Some minor things:
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Address to scan */
> +static unsigned short normal_i2c[] = { 0x39, I2C_CLIENT_END };
> +
> +/* Insmod parameters */
> +I2C_CLIENT_INSMOD_1(tsl2550);
> +
> +static int operating_mode = 0;
The `= 0' is unneeded and undesirable.
> ...
>
> +static int tsl2550_get_adc_value(struct i2c_client *client, int channel)
> +{
> + u8 cmd = channel == 0 ? TSL2550_READ_ADC0 : TSL2550_READ_ADC1;
> + int timeout, ret;
> +
> + /* Read ADC channel waiting at most 400ms (see data sheet for further
> + * info) */
> + for (timeout = 400; timeout > 0; timeout--) {
> + i2c_smbus_write_byte(client, cmd);
> + mdelay(1);
> + ret = i2c_smbus_read_byte(client);
> + if (ret < 0)
> + return ret;
> + else if (ret & 0x0080)
> + break;
> + }
> + if (timeout == 0)
> + return -EIO;
> + return ((u8) ret) & 0x7f; /* remove the "valid" bit */
> +}
eek. Is there no way to avoid the busy-wait? We cannot sleep here?
> +/* --- LUX calculation -
> */
> +
> +#define TSL2550_MAX_LUX 1846
> +
> +static u8 ratio_lut[] = {
> + 100, 100, 100, 100, 100, 100, 100, 100,
> + 100, 100, 100, 100, 100, 100, 99, 99,
> + 99, 99, 99, 99, 99, 99, 99, 99,
> + 99, 99, 99, 98, 98, 98, 98, 98,
> + 98, 98, 97, 97, 97, 97, 97, 96,
> + 96, 96, 96, 95, 95, 95, 94, 94,
> + 93, 93, 93, 92, 92, 91, 91, 90,
> + 89, 89, 88, 87, 87, 86, 85, 84,
> + 83, 82, 81, 80, 79, 78, 77, 75,
> + 74, 73, 71, 69, 68, 66, 64, 62,
> + 60, 58, 56, 54, 52, 49, 47, 44,
> + 42, 41, 40, 40, 39, 39, 38, 38,
> + 37, 37, 37, 36, 36, 36, 35, 35,
> + 35, 35, 34, 34, 34, 34, 33, 33,
> + 33, 33, 32, 32, 32, 32, 32, 31,
> + 31, 31, 31, 31, 30, 30, 30, 30,
> + 30,
> +};
> +
> +static u16 count_lut[] = {
> + 0, 1, 2, 3, 4, 5, 6, 7,
> + 8, 9, 10, 11, 12, 13, 14, 15,
> + 16, 18, 20, 22, 24, 26, 28, 30,
> + 32, 34, 36, 38, 40, 42, 44, 46,
> + 49, 53, 57, 61, 65, 69, 73, 77,
> + 81, 85, 89, 93, 97, 101, 105, 109,
> + 115, 123, 131, 139, 147, 155, 163, 171,
> + 179, 187, 195, 203, 211, 219, 227, 235,
> + 247, 263, 279, 295, 311, 327, 343, 359,
> + 375, 391, 407, 423, 439, 455, 471, 487,
> + 511, 543, 575, 607, 639, 671, 703, 735,
> + 767, 799, 831, 863, 895, 927, 959, 991,
> + 1039, 1103, 1167, 1231, 1295, 1359, 1423, 1487,
> + 1551, 1615, 1679, 1743, 1807, 1871, 1935, 1999,
> + 2095, 2223, 2351, 2479, 2607, 2735, 2863, 2991,
> + 3119, 3247, 3375, 3503, 3631, 3759, 3887, 4015
> +};
These tables could perhaps be const?
> +static ssize_t tsl2550_show_power_state(struct device *dev, struct
> device_attribute *attr, char *buf)
It's preferred to try to fit the code into an 80-col window. (But some
people disagree with this specifically for function definitions such as
this).
> +static ssize_t tsl2550_store_power_state(struct device *dev, struct
> device_attribute *attr, const char *buf, size_t count)
Ditto (and other places).
> +static int tsl2550_detach_client(struct i2c_client *client)
> +{
> + int err;
> +
> + sysfs_remove_group(>dev.kobj, _attr_group);
> +
> + if ((err = i2c_detach_client(client)))
> + return err;
Preferred coding style is
err = i2c_detach_client(client);
if (err)
return err;
(multiple places)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc6-mm1
On Sun, Jan 28, 2007 at 03:01:33PM -0800, Andrew Morton wrote: > On Sun, 28 Jan 2007 08:56:08 -0800 > "Martin J. Bligh" <[EMAIL PROTECTED]> wrote: > > > > - It seems that people have been busy creating the need for this. I had > > > to > > > apply over sixty patches to this tree to fix post-2.6.20-rc4-mm1 > > > compilation > > > errors. And a number of patches were dropped due to no-compile or to > > > runtime errors. Heaven knows how many runtime bugs were added. > > > > dbench seems to panic on xfs / cfq ? > > OK, I'll dump git-block.patch. That means that the fsaio patches get > temporarily dropped as well as they depend on git-block changes somewhat. Would you like me to rework these back again to not depend on git-block ? > > btw, I didn't actually include the list-aio patches in rc6-mm1 due to > various discouraging-looking review comments - I'll be awaiting version 2 > there. Regards Suparna -- Suparna Bhattacharya ([EMAIL PROTECTED]) Linux Technology Center IBM Software Lab, India - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: via irq quirk breakage
Jean Delvare wrote: Ni Nick, Alan, Le Mercredi 24 Janvier 2007 01:33, Nick Piggin a écrit : Recently updated an old box to a new kernel, and the USB mouse stops working. Well it sort of works, but stutters and is very unresponsive. This happens now and again when the IRQ routing for my board gets broken. Attached a dmesg from a bad 2.6.20-rc5, and a quick hack that gets everything working again, and a diff between good and bad dmesg, and lspci. Your hack seems quite broken to me, I suspect it works somewhat by accident and would probably do bad things on other machines. Well it works because I know I need that particular quirk applied to my USB IRQ. But definitely it is a hack because I've otherwise got no idea what I'm doing ;) I can test patches or send any other info needed. The same bug was reported to me by someone else, and my investigation led me to the conclusion that pci_find_present() doesn't work yet at the moment the quirks are run. Am I right? Which makes me wonder if this VIA quirks update was ever tested. Alan? Here is the patch I have come up with. It might not qualify as elegant, but at least it appears to solve the issue. Nick, can you please give it a try and confirm it works for you as well? This does not work for me. Again, it boots and runs, but USB interrupts don't seem to be getting delivered. Attached is the dmesg. Let me know if you need any other info or tests done. Note: I'm not sure if the quirk will survive suspend/resume or not, testers and comments are welcome. I expect lots of complaints from users if we release 2.6.20 with the VIA quirks broken. -- SUSE Labs, Novell Inc. Linux version 2.6.20-rc5-via ([EMAIL PROTECTED]) (gcc version 4.1.2 20061020 (prerelease) (Debian 4.1.1-17)) #5 SMP PREEMPT Tue Jan 30 13:03:11 EST 2007 BIOS-provided physical RAM map: sanitize start sanitize end copy_e820_map() start: size: 0009fc00 end: 0009fc00 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 0009fc00 size: 0400 end: 000a type: 2 copy_e820_map() start: 000f size: 0001 end: 0010 type: 2 copy_e820_map() start: 0010 size: 0fef end: 0fff type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 0fff size: 8000 end: 0fff8000 type: 3 copy_e820_map() start: 0fff8000 size: 8000 end: 1000 type: 4 copy_e820_map() start: fec0 size: 1000 end: fec01000 type: 2 copy_e820_map() start: fee0 size: 1000 end: fee01000 type: 2 copy_e820_map() start: size: 0001 end: 0001 type: 2 BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0fff (usable) BIOS-e820: 0fff - 0fff8000 (ACPI data) BIOS-e820: 0fff8000 - 1000 (ACPI NVS) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: - 0001 (reserved) 255MB LOWMEM available. found SMP MP-table at 000fb110 Entering add_active_range(0, 0, 65520) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 ->65520 early_node_map[1] active PFN ranges 0:0 ->65520 On node 0 totalpages: 65520 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 479 pages used for memmap Normal zone: 60945 pages, LIFO batch:15 DMI 2.3 present. ACPI: RSDP (v000 AMI ) @ 0x000fc590 ACPI: RSDT (v001 AMIINT 0x0010 MSFT 0x0099) @ 0x0fff ACPI: FADT (v001 AMIINT 0x0011 MSFT 0x0099) @ 0x0fff0030 ACPI: MADT (v001 AMIINT 0x0009 MSFT 0x0099) @ 0x0fff00b0 ACPI: DSDT (v001VIA APOLLO-P 0x1000 MSFT 0x010b) @ 0x ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 17 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 6:8 APIC version 17 ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 2000 (gap: 1000:eec0) Detected 996.609 MHz processor. Built 1 zonelists. Total pages: 65009 Kernel command line:
Re: Free Linux Driver Development!
On Mon, Jan 29, 2007 at 09:19:21PM -0500, Rik van Riel wrote: > Greg KH wrote: > >Free Linux Driver Development! > > Mind if I include this offer on http://kernelnewbies.org/UpstreamMerge ? Please do, spread it around as much as you want. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Free Linux Driver Development!
Greg KH wrote: Free Linux Driver Development! Mind if I include this offer on http://kernelnewbies.org/UpstreamMerge ? -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: remove global locks from mm/highmem.c
On Mon, 29 Jan 2007 17:49:14 -0800 "Martin J. Bligh" <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > On Mon, 29 Jan 2007 17:31:20 -0800 > > "Martin J. Bligh" <[EMAIL PROTECTED]> wrote: > > > >> Peter Zijlstra wrote: > >>> On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote: > >>> > As Christoph says, it's very much preferred that code be migrated over to > kmap_atomic(). Partly because kmap() is deadlockable in situations > where a > large number of threads are trying to take two kmaps at the same time and > we run out. This happened in the past, but incidences have gone away, > probably because of kmap->kmap_atomic conversions. > From which callsite have you measured problems? > >>> CONFIG_HIGHPTE code in -rt was horrid. I'll do some measurements on > >>> mainline. > >>> > >> CONFIG_HIGHPTE is always horrid -we've known that for years. > > > > We have? What's wrong with it? > > http://www.ussg.iu.edu/hypermail/linux/kernel/0307.0/0463.html 2% overhead for a pte-intensive workload for unknown reasons four years ago. Sort of a mini-horrid, no? We still don't know what is the source of kmap() activity which necessitated this patch btw. AFAIK the busiest source is ext2 directories, but perhaps NFS under certain conditions? ->prepare_write no longer requires that the caller kmap the page. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slow module build--what am I doing wrong?
Ben Pfaff <[EMAIL PROTECTED]> writes: > When I modify a source file or two that belong to a particular > module, and then rebuild just that module with "make > dir1/dir/module.ko" (e.g.), the build system spends a couple of > minutes grinding away on "MODPOST" operations. Am I doing > something wrong? Is there a way to avoid this? It slows down my > build-and-test cycle quite a bit. I was privately emailed a suggestion to use "make M=dir1/dir" instead of "make dir1/dir/module.ko". It helps a great deal. -- Ben Pfaff [EMAIL PROTECTED] http://benpfaff.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: remove global locks from mm/highmem.c
Ingo Molnar wrote: For every 64-bit Fedora box there's more than seven 32-bit boxes. I think 32-bit is going to live with us far longer than many thought, so we might as well make it work better. Both HIGHMEM and HIGHPTE is the default on many distro kernels, which pushes the kmap infrastructure quite a bit. I don't think anybody would argue against numbers, but just that there are not many big 32-bit SMPs anymore. And if Bill Irwin didn't fix the kmap problem back then, it would be interesting to see a system and workload where it actually is a bottleneck. Not that I'm against any patch to improve scalability, if it doesn't hurt single-threaded performance ;) the problem is that everything that was easy to migrate was migrated off kmap() already - and it's exactly those hard cases that cannot be converted (like the pagecache use) which is the most frequent kmap() users. Which pagecache use? file_read_actor()? -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: page_mkwrite caller is racy?
On Tue, Jan 30, 2007 at 12:14:24PM +1100, Nick Piggin wrote: > This is another discussion, but do we want the page locked here? Or > are the filesystems happy to exclude truncate themselves? No page lock please. Generally, Ocfs2 wants to order cluster locks outside of page locks. Also, the sparse b-tree support I'm working on right now will need to be able to allocate in ->page_mkwrite() which would become very nasty if we came in with the page lock - aside from the additional cluster locks taken, ocfs2 will want to zero some adjacent pages (because we support atomic allocation up to 1 meg). Thanks, --Mark -- Mark Fasheh Senior Software Developer, Oracle [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: remove global locks from mm/highmem.c
Andrew Morton wrote: On Mon, 29 Jan 2007 17:31:20 -0800 "Martin J. Bligh" <[EMAIL PROTECTED]> wrote: Peter Zijlstra wrote: On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote: As Christoph says, it's very much preferred that code be migrated over to kmap_atomic(). Partly because kmap() is deadlockable in situations where a large number of threads are trying to take two kmaps at the same time and we run out. This happened in the past, but incidences have gone away, probably because of kmap->kmap_atomic conversions. From which callsite have you measured problems? CONFIG_HIGHPTE code in -rt was horrid. I'll do some measurements on mainline. CONFIG_HIGHPTE is always horrid -we've known that for years. We have? What's wrong with it? http://www.ussg.iu.edu/hypermail/linux/kernel/0307.0/0463.html July 2003. M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: remove global locks from mm/highmem.c
On Mon, 29 Jan 2007 17:31:20 -0800 "Martin J. Bligh" <[EMAIL PROTECTED]> wrote: > Peter Zijlstra wrote: > > On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote: > > > >> As Christoph says, it's very much preferred that code be migrated over to > >> kmap_atomic(). Partly because kmap() is deadlockable in situations where a > >> large number of threads are trying to take two kmaps at the same time and > >> we run out. This happened in the past, but incidences have gone away, > >> probably because of kmap->kmap_atomic conversions. > > > >> From which callsite have you measured problems? > > > > CONFIG_HIGHPTE code in -rt was horrid. I'll do some measurements on > > mainline. > > > > CONFIG_HIGHPTE is always horrid -we've known that for years. We have? What's wrong with it? > Don't use it. > > If that's all we're fixing here, I'd be highly suspect ... highpte uses atomic kmaps - it is unrelated to this work. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19.2: bad reads/writes from/to CMOS clock
I have since found out that SMP kernels should(must?) have Enhanced RTC support built-in. It is stated in kernel config help for Enhanced RTC support, and I found a number of references on the net as well. Now I wonder why selecting SMP does not set Enhanced RTC support to "Y" automatically? I am building a kernel right now, and will monitor for a week or so, then come back and report if it removes the problem. Yavuz [EMAIL PROTECTED] wrote: Hi everyone, I am running 2.6.19.2 kernel from kernel.org. This is my first SMP kernel. The problem I describe below has not happend with non-SMP kernels ever... I have installed my new AMD64 x2 4800 CPU just a few days ago. My mobo is Asus A8N SLI (Nvidia chipset). My problem with this new setup is that my CMOS clock is thrown off by varying amounts of time. I have seen system times as long as ten months into future, and as long as 25 days in the past. At the moment my system clock has correct hh:mm:ss, but it shows the date Jan 1st, instead of correct 25th. In last few days have systematically checked CMOS clock after shutdown and before boot-up. I have observed CMOS clock set to a wrong value, immediately after shutdown. I also ended up with a wrong system time following a boot after verifying correctness of the CMOS clock. Problem does not happen 100% of the time. But 6-7 times in a week is bad enough. I searched mailing list archives, and found some NMI-RTC race condition discussion, and some other discussions about timers not running, clock ticks being missed etc. But they were all at least one year old. The fixes to those should have found their way into 2.6.19 kernels. I would appreciate any ideas on how to follow-up on this problem. I am eager to try things, collect data as needed. Just tell me what to do. Thanks in advance. Yavuz Onder - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: remove global locks from mm/highmem.c
Peter Zijlstra wrote: On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote: As Christoph says, it's very much preferred that code be migrated over to kmap_atomic(). Partly because kmap() is deadlockable in situations where a large number of threads are trying to take two kmaps at the same time and we run out. This happened in the past, but incidences have gone away, probably because of kmap->kmap_atomic conversions. From which callsite have you measured problems? CONFIG_HIGHPTE code in -rt was horrid. I'll do some measurements on mainline. CONFIG_HIGHPTE is always horrid -we've known that for years. Don't use it. If that's all we're fixing here, I'd be highly suspect ... M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded
Acked-by: Tejun Heo <[EMAIL PROTECTED]> Please repost with proper subject. http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch -mm 3/5] x86_64: fixed-size remaining fake nodes
On Mon, 29 Jan 2007, David Rientjes wrote: > On Mon, 29 Jan 2007, Andi Kleen wrote: > > > On Thursday 25 January 2007 22:37, David Rientjes wrote: > > > Any leftover memory is allocated > > > to a final node unless the command-line ends with a comma. > > > > That sounds like syntactical vinegar and a nasty trap. Remember > > that venus probe that got lost because of a wrong comma. > > Can you find some nicer syntax for that please? > > > I agree it's not a good idea to prevent the remaining RAM from being allocated to an additional node. It was helpful in testing and the gathering of benchmarks for the purpose of memory management, but not for real-world cases. It's been removed. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANN] Userspace M-on-N threading model implementation. Alpha release.
Hi, Evgenity, le Mon 29 Jan 2007 16:47:36 +0100, a écrit : > Userspace M-on-N threading model is based on the idea, that when signal > is delivered, kernel saves all information related to previous context > in stack, so it is possible to find it and replace. You may want to have a look at some existing implementations: - Good old `FSU Pthreads' http://moss.csc.ncsu.edu/~mueller/pthreads/ - fully POSIX-compliant `GnuPth' http://www.gnu.org/software/pth/ - server-targetted `Capriccio' www.cs.berkeley.edu/~jcondit/capriccio-sosp-2003.pdf - efficient `ELiTE/Erlangen' http://www4.informatik.uni-erlangen.de/Projects/FORTWIHR/ELiTE/ - and our portable, flexible, efficient `Marcel' http://runtime.futurs.inria.fr/marcel/ Samuel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: page_mkwrite caller is racy?
Hugh Dickins wrote: On Mon, 29 Jan 2007, Nick Piggin wrote: Moving page_cache_release(old_page) to below the next statement will fix that problem. Yes. I'm reluctant to steal your credit, but also reluctant to go back and forth too much over this: please insert your Signed-off-by _before_ mine in the patch below (substituting your own comment if you prefer) and send it Andrew. Not a priority for 2.6.20 or -stable: aside from the unlikelihood, we don't seem to have any page_mkwrite users yet, as you point out. Agreed. Thanks for doing the patch. But it is sad that this thing got merged without any callers to even know how it is intended to work. I'm rather to blame for that: I pushed Peter to rearranging his work on top of what David had, since they were dabbling in related issues, and we'd already solved a number of them in relation to page_mkwrite; so then when dirty tracking was wanted in, page_mkwrite came with it. Well its not a big problem -- I knew there were several people lined up who wanted it. XFS is another one IIRC. Must it be able to sleep? Not as David was using it: that was something I felt strongly it should be allowd to do. For example, in order to allocate backing store for the mmap'ed page to be written (that need has been talked about off and on for years). Fine, and Mark and Anton confirm it (cc'ed, thanks guys). This is another discussion, but do we want the page locked here? Or are the filesystems happy to exclude truncate themselves? After do_wp_page has tested page_mkwrite, it must release old_page after acquiring page table lock, not before: at some stage that ordering got reversed, leaving a (very unlikely) window in which old_page might be truncated, freed, and reused in the same position. Andrew please apply. Signed-off-by: Nick Piggin <[EMAIL PROTECTED]> Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> --- mm/memory.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- 2.6.20-rc6/mm/memory.c 2007-01-25 08:25:27.0 + +++ linux/mm/memory.c 2007-01-29 15:35:56.0 + @@ -1531,8 +1531,6 @@ static int do_wp_page(struct mm_struct * if (vma->vm_ops->page_mkwrite(vma, old_page) < 0) goto unwritable_page; - page_cache_release(old_page); - /* * Since we dropped the lock we need to revalidate * the PTE as someone else may have changed it. If @@ -1541,6 +1539,7 @@ static int do_wp_page(struct mm_struct * */ page_table = pte_offset_map_lock(mm, pmd, address, ); + page_cache_release(old_page); if (!pte_same(*page_table, orig_pte)) goto unlock; } -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] drivers/char/pcmcia/ipwireless_cs_*: possible cleanups
On Sat, Jan 27, 2007 at 11:49:28PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-rc4-mm1:
>...
> git-ipwireless_cs.patch
>...
> git trees.
>...
This patch contains the following possible cleanups:
- proper prototypes for global functions in header files
- make the following needlessly global function static:
- ipwireless_cs_hardware.c: data_type()
- make the following needlessly global struct static:
- ipwireless_cs_tty.c: ipw_tty_driver
- #if 0 the following unused global functions:
- ipwireless_cs_hardware.c: ipwireless_get_config()
- ipwireless_cs_tty.c: ipw_flush_buffer()
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/char/pcmcia/ipwireless_cs_hardware.c |4 +++-
drivers/char/pcmcia/ipwireless_cs_hardware.h |5 ++---
drivers/char/pcmcia/ipwireless_cs_network.h |2 ++
drivers/char/pcmcia/ipwireless_cs_tty.c | 10 +++---
4 files changed, 10 insertions(+), 11 deletions(-)
--- linux-2.6.20-rc6-mm1/drivers/char/pcmcia/ipwireless_cs_network.h.old
2007-01-29 00:17:28.0 +0100
+++ linux-2.6.20-rc6-mm1/drivers/char/pcmcia/ipwireless_cs_network.h
2007-01-29 00:17:56.0 +0100
@@ -43,4 +43,6 @@
int ipwireless_ppp_channel_index(struct ipw_network_t *);
int ipwireless_ppp_unit_number(struct ipw_network_t *);
+int ipwireless_dump_network_state(char *p, struct ipw_network_t *network);
+
#endif
--- linux-2.6.20-rc6-mm1/drivers/char/pcmcia/ipwireless_cs_hardware.h.old
2007-01-29 00:20:14.0 +0100
+++ linux-2.6.20-rc6-mm1/drivers/char/pcmcia/ipwireless_cs_hardware.h
2007-01-29 00:16:54.0 +0100
@@ -43,9 +43,6 @@
unsigned int, ipw_packet_sent_callback_t,
void *);
-/* Get the configuration settings for this modem instance. */
-struct ipw_config_t *ipwireless_get_config(struct ipw_hardware_t *);
-
/* Associate the specified network with this hardware */
void ipwireless_associate_network(struct ipw_hardware_t *, struct
ipw_network_t *);
@@ -64,4 +61,6 @@
void ipwireless_sleep(u_int tenths);
+int ipwireless_dump_hardware_state(char *p, struct ipw_hardware_t *hw);
+
#endif
--- linux-2.6.20-rc6-mm1/drivers/char/pcmcia/ipwireless_cs_hardware.c.old
2007-01-28 23:34:55.0 +0100
+++ linux-2.6.20-rc6-mm1/drivers/char/pcmcia/ipwireless_cs_hardware.c
2007-01-28 23:36:26.0 +0100
@@ -375,7 +375,7 @@
-char *data_type(const u_char * buf, unsigned length)
+static char *data_type(const u_char * buf, unsigned length)
{
NLPacketHeader *hdr = (NLPacketHeader *) buf;
if (length == 0)
@@ -1592,10 +1592,12 @@
kfree(hw);
}
+#if 0
ipw_config_t *ipwireless_get_config(struct ipw_hardware_t *hw)
{
return >config;
}
+#endif /* 0 */
/* Associate the specified network with this hardware, so it will receive
events
* from it. */
--- linux-2.6.20-rc6-mm1/drivers/char/pcmcia/ipwireless_cs_tty.c.old
2007-01-28 23:36:46.0 +0100
+++ linux-2.6.20-rc6-mm1/drivers/char/pcmcia/ipwireless_cs_tty.c
2007-01-29 00:18:02.0 +0100
@@ -463,10 +463,12 @@
return ppp_ioctl(linux_tty, file, cmd, arg);
}
+#if 0
void ipw_flush_buffer(struct tty_struct *tty)
{
wake_up_interruptible(>write_wait);
}
+#endif /* 0 */
static void add_tty(int first, int *j, dev_node_t ** nodesp,
struct pcmcia_device *link,
@@ -578,7 +580,7 @@
.tiocmset = ipw_tiocmset,
};
-struct tty_driver *ipw_tty_driver;
+static struct tty_driver *ipw_tty_driver;
static int proc_read(char *page, char **start, off_t off, int count,
int *eof, void *data)
@@ -586,12 +588,6 @@
int i, j;
char *p = page;
int len;
-#ifdef IPWIRELESS_STATE_DEBUG
- int ipwireless_dump_hardware_state(char *p,
- struct ipw_hardware_t *hw);
- int ipwireless_dump_network_state(char *p,
- struct ipw_network_t *network);
-#endif
if (off == 0) {
p += sprintf(p, "driver: %s\nversion: %s\n\n",
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC: -mm patch] #if 0 v4l_printk_ioctl_arg()
On Sat, Jan 27, 2007 at 11:49:28PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-rc4-mm1:
>...
> git-dvb.patch
>...
> git trees.
>...
v4l_printk_ioctl_arg() is no longer used.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/media/video/v4l2-common.c |7 ++-
include/media/v4l2-common.h |3 ---
2 files changed, 6 insertions(+), 4 deletions(-)
--- linux-2.6.20-rc6-mm1/include/media/v4l2-common.h.old2007-01-29
00:02:58.0 +0100
+++ linux-2.6.20-rc6-mm1/include/media/v4l2-common.h2007-01-29
00:03:10.0 +0100
@@ -64,9 +64,6 @@
/* Prints the ioctl in a human-readable format */
extern void v4l_printk_ioctl(unsigned int cmd);
-/* Prints the ioctl and arg in a human-readable format */
-extern void v4l_printk_ioctl_arg(char *s,unsigned int cmd, void *arg);
-
/* Use this macro for non-I2C drivers. Pass the driver name as the first arg.
*/
#define v4l_print_ioctl(name, cmd) \
do { \
--- linux-2.6.20-rc6-mm1/drivers/media/video/v4l2-common.c.old 2007-01-29
00:21:54.0 +0100
+++ linux-2.6.20-rc6-mm1/drivers/media/video/v4l2-common.c 2007-01-29
00:45:55.0 +0100
@@ -271,11 +271,13 @@
[V4L2_BUF_TYPE_SLICED_VBI_OUTPUT] = "slicec-vbi-out",
};
+#if 0
static char *v4l2_memory_names[] = {
[V4L2_MEMORY_MMAP]= "mmap",
[V4L2_MEMORY_USERPTR] = "userptr",
[V4L2_MEMORY_OVERLAY] = "overlay",
};
+#endif /* 0 */
#define prt_names(a,arr) (((a)>=0)&&((a)field,v4l2_field_names),
fmt->bytesperline,fmt->sizeimage,fmt->colorspace);
};
+#endif /* 0 */
/* Common ioctl debug function. This function can be used by
external ioctl messages as well as internal V4L ioctl */
@@ -466,6 +470,7 @@
}
}
+#if 0
/* Common ioctl debug function. This function can be used by
external ioctl messages as well as internal V4L ioctl and its
arguments */
@@ -1036,6 +1041,7 @@
}
}
}
+#endif /* 0 */
/* - */
@@ -1544,7 +1550,6 @@
EXPORT_SYMBOL(v4l2_field_names);
EXPORT_SYMBOL(v4l2_type_names);
EXPORT_SYMBOL(v4l_printk_ioctl);
-EXPORT_SYMBOL(v4l_printk_ioctl_arg);
EXPORT_SYMBOL(v4l2_ctrl_next);
EXPORT_SYMBOL(v4l2_ctrl_check);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC: -mm patch] CONFIG_INPUT_DEBUG improvements
On Sat, Jan 27, 2007 at 11:49:28PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-rc4-mm1:
>...
> git-hid.patch
>...
> git trees.
>...
This patch contains the following CONFIG_INPUT_DEBUG improvements:
- remove Makefile code for the nonexisting CONFIG_INPUT_DEBUG
- simpler Makefile for hid-debug.o
- replace all HID debug #define's with CONFIG_INPUT_DEBUG
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/hid/Makefile| 15 ++-
drivers/hid/hid-core.c |6 ++
drivers/hid/hid-input.c |6 ++
3 files changed, 6 insertions(+), 21 deletions(-)
--- linux-2.6.20-rc6-mm1/drivers/hid/Makefile.old 2007-01-28
23:50:41.0 +0100
+++ linux-2.6.20-rc6-mm1/drivers/hid/Makefile 2007-01-29 00:13:22.0
+0100
@@ -2,18 +2,7 @@
# Makefile for the HID driver
#
-# Multipart objects.
-hid-objs := hid-core.o hid-input.o
-
-# Optional parts of multipart objects.
-ifeq ($(CONFIG_HID_DEBUG),y)
-hid-objs += hid-debug.o
-endif
-
-ifeq ($(CONFIG_INPUT_DEBUG),y)
-EXTRA_CFLAGS += -DDEBUG
-endif
-
-
obj-$(CONFIG_HID) += hid.o
+hid-objs := hid-core.o hid-input.o
+hid-$(CONFIG_HID_DEBUG)+= hid-debug.o
--- linux-2.6.20-rc6-mm1/drivers/hid/hid-core.c.old 2007-01-28
23:52:34.0 +0100
+++ linux-2.6.20-rc6-mm1/drivers/hid/hid-core.c 2007-01-28 23:53:47.0
+0100
@@ -27,8 +27,6 @@
#include
#include
-#undef DEBUG_DATA
-
#include
#include
#include
@@ -950,7 +948,7 @@
return -1;
}
-#ifdef DEBUG_DATA
+#ifdef CONFIG_INPUT_DEBUG
printk(KERN_DEBUG __FILE__ ": report (size %u) (%snumbered)\n", size,
report_enum->numbered ? "" : "un");
#endif
@@ -960,7 +958,7 @@
size--;
}
-#ifdef DEBUG_DATA
+#ifdef CONFIG_INPUT_DEBUG
{
int i;
printk(KERN_DEBUG __FILE__ ": report %d (size %u) = ", n, size);
--- linux-2.6.20-rc6-mm1/drivers/hid/hid-input.c.old2007-01-28
23:53:56.0 +0100
+++ linux-2.6.20-rc6-mm1/drivers/hid/hid-input.c2007-01-28
23:54:21.0 +0100
@@ -31,8 +31,6 @@
#include
#include
-#undef DEBUG
-
#include
#include
@@ -248,7 +246,7 @@
field->hidinput = hidinput;
-#ifdef DEBUG
+#ifdef CONFIG_HID_DEBUG
printk(KERN_DEBUG "Mapping: ");
hid_resolv_usage(usage->hid);
printk(" ---> ");
@@ -685,7 +683,7 @@
return;
ignore:
-#ifdef DEBUG
+#ifdef CONFIG_HID_DEBUG
printk("IGNORED\n");
#endif
return;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC: -mm patch] fs/ecryptfs/: make code static
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 13 Jan 2007
fs/ecryptfs/crypto.c | 24
fs/ecryptfs/ecryptfs_kernel.h | 18 --
fs/ecryptfs/messaging.c | 20 +++-
3 files changed, 23 insertions(+), 39 deletions(-)
--- linux-2.6.20-rc4-mm1/fs/ecryptfs/ecryptfs_kernel.h.old 2007-01-13
08:34:46.0 +0100
+++ linux-2.6.20-rc4-mm1/fs/ecryptfs/ecryptfs_kernel.h 2007-01-13
14:31:01.0 +0100
@@ -329,18 +329,6 @@
struct mutex mux;
};
-extern struct list_head ecryptfs_msg_ctx_free_list;
-extern struct list_head ecryptfs_msg_ctx_alloc_list;
-extern struct mutex ecryptfs_msg_ctx_lists_mux;
-
-#define ecryptfs_uid_hash(uid) \
-hash_long((unsigned long)uid, ecryptfs_hash_buckets)
-extern struct hlist_head *ecryptfs_daemon_id_hash;
-extern struct mutex ecryptfs_daemon_id_hash_mux;
-extern int ecryptfs_hash_buckets;
-
-extern unsigned int ecryptfs_msg_counter;
-extern struct ecryptfs_msg_ctx *ecryptfs_msg_ctx_arr;
extern unsigned int ecryptfs_transport;
struct ecryptfs_daemon_id {
@@ -538,15 +526,9 @@
int ecryptfs_decrypt_page(struct file *file, struct page *page);
int ecryptfs_write_metadata(struct dentry *ecryptfs_dentry,
struct file *lower_file);
-int ecryptfs_write_headers_virt(char *page_virt, size_t *size,
- struct ecryptfs_crypt_stat *crypt_stat,
- struct dentry *ecryptfs_dentry);
int ecryptfs_read_metadata(struct dentry *ecryptfs_dentry,
struct file *lower_file);
int ecryptfs_new_file_context(struct dentry *ecryptfs_dentry);
-int contains_ecryptfs_marker(char *data);
-int ecryptfs_read_header_region(char *data, struct dentry *dentry,
- struct vfsmount *mnt);
int ecryptfs_read_and_validate_header_region(char *data, struct dentry *dentry,
struct vfsmount *mnt);
int ecryptfs_read_and_validate_xattr_region(char *page_virt,
--- linux-2.6.20-rc4-mm1/fs/ecryptfs/crypto.c.old 2007-01-13
08:35:23.0 +0100
+++ linux-2.6.20-rc4-mm1/fs/ecryptfs/crypto.c 2007-01-13 14:27:02.0
+0100
@@ -1026,7 +1026,7 @@
*
* Returns one if marker found; zero if not found
*/
-int contains_ecryptfs_marker(char *data)
+static int contains_ecryptfs_marker(char *data)
{
u32 m_1, m_2;
@@ -1213,8 +1213,8 @@
*
* Returns zero on success; non-zero otherwise
*/
-int ecryptfs_read_header_region(char *data, struct dentry *dentry,
- struct vfsmount *mnt)
+static int ecryptfs_read_header_region(char *data, struct dentry *dentry,
+ struct vfsmount *mnt)
{
struct file *lower_file;
mm_segment_t oldfs;
@@ -1310,9 +1310,9 @@
*
* Returns zero on success
*/
-int ecryptfs_write_headers_virt(char *page_virt, size_t *size,
- struct ecryptfs_crypt_stat *crypt_stat,
- struct dentry *ecryptfs_dentry)
+static int ecryptfs_write_headers_virt(char *page_virt, size_t *size,
+ struct ecryptfs_crypt_stat *crypt_stat,
+ struct dentry *ecryptfs_dentry)
{
int rc;
size_t written;
@@ -1339,9 +1339,9 @@
return rc;
}
-int ecryptfs_write_metadata_to_contents(struct ecryptfs_crypt_stat *crypt_stat,
- struct file *lower_file,
- char *page_virt)
+static int ecryptfs_write_metadata_to_contents(struct ecryptfs_crypt_stat
*crypt_stat,
+ struct file *lower_file,
+ char *page_virt)
{
mm_segment_t oldfs;
int current_header_page;
@@ -1366,9 +1366,9 @@
return 0;
}
-int ecryptfs_write_metadata_to_xattr(struct dentry *ecryptfs_dentry,
-struct ecryptfs_crypt_stat *crypt_stat,
-char *page_virt, size_t size)
+static int ecryptfs_write_metadata_to_xattr(struct dentry *ecryptfs_dentry,
+ struct ecryptfs_crypt_stat
*crypt_stat,
+ char *page_virt, size_t size)
{
int rc;
--- linux-2.6.20-rc4-mm1/fs/ecryptfs/messaging.c.old2007-01-13
14:28:20.0 +0100
+++ linux-2.6.20-rc4-mm1/fs/ecryptfs/messaging.c2007-01-13
14:31:27.0 +0100
@@ -22,16 +22,18 @@
#include "ecryptfs_kernel.h"
-LIST_HEAD(ecryptfs_msg_ctx_free_list);
-LIST_HEAD(ecryptfs_msg_ctx_alloc_list);
-struct mutex ecryptfs_msg_ctx_lists_mux;
-
-struct hlist_head *ecryptfs_daemon_id_hash;
-struct mutex ecryptfs_daemon_id_hash_mux;
-int ecryptfs_hash_buckets;
+static
[-mm patch] cx88-video.c: remove struct radionorms
On Sat, Jan 27, 2007 at 11:49:28PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-rc4-mm1:
>...
> git-dvb.patch
>...
> git trees.
>...
This patch removes the unused struct radionorms.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.20-rc6-mm1/drivers/media/video/cx88/cx88-video.c.old
2007-01-28 23:59:19.0 +0100
+++ linux-2.6.20-rc6-mm1/drivers/media/video/cx88/cx88-video.c 2007-01-28
23:59:28.0 +0100
@@ -86,8 +86,6 @@
/* --- */
/* static data */
-v4l2_std_id radionorms[] = { 0 };
-
static struct cx8800_fmt formats[] = {
{
.name = "8 bpp, gray",
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] vmi: cleanups
This patch contains the following cleanups:
- make needlessly global code static
- remove pointless fastcall annotations
- don't mark functions in C files as inline
- #if 0 the following unused function:
- arch/i386/kernel/vmitime.c: read_stolen_cycles()
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
arch/i386/kernel/vmi.c | 89 ++--
arch/i386/kernel/vmitime.c | 39 ---
include/asm-i386/vmi_time.h | 14 ++---
3 files changed, 72 insertions(+), 70 deletions(-)
--- linux-2.6.20-rc6-mm1/include/asm-i386/vmi_time.h.old2007-01-28
20:27:42.0 +0100
+++ linux-2.6.20-rc6-mm1/include/asm-i386/vmi_time.h2007-01-28
20:27:48.0 +0100
@@ -37,12 +37,12 @@
/* Cached VMI timer operations */
extern struct vmi_timer_ops {
- u64 (fastcall *get_cycle_frequency)(void);
- u64 (fastcall *get_cycle_counter)(int);
- u64 (fastcall *get_wallclock)(void);
- int (fastcall *wallclock_updated)(void);
- void (fastcall *set_alarm)(u32 flags, u64 expiry, u64 period);
- void (fastcall *cancel_alarm)(u32 flags);
+ u64 (*get_cycle_frequency)(void);
+ u64 (*get_cycle_counter)(int);
+ u64 (*get_wallclock)(void);
+ int (*wallclock_updated)(void);
+ void (*set_alarm)(u32 flags, u64 expiry, u64 period);
+ void (*cancel_alarm)(u32 flags);
} vmi_timer_ops;
/* Prototypes */
@@ -54,7 +54,7 @@
#ifdef CONFIG_X86_LOCAL_APIC
extern void __init vmi_timer_setup_boot_alarm(void);
extern void __init vmi_timer_setup_secondary_alarm(void);
-extern fastcall void apic_vmi_timer_interrupt(void);
+extern void apic_vmi_timer_interrupt(void);
#endif
#ifdef CONFIG_NO_IDLE_HZ
--- linux-2.6.20-rc6-mm1/arch/i386/kernel/vmi.c.old 2007-01-28
20:15:42.0 +0100
+++ linux-2.6.20-rc6-mm1/arch/i386/kernel/vmi.c 2007-01-28 20:22:15.0
+0100
@@ -56,19 +56,19 @@
static int disable_mtrr;
/* Cached VMI operations */
-struct {
- void (fastcall *cpuid)(void /* non-c */);
- void (fastcall *_set_ldt)(u32 selector);
- void (fastcall *set_tr)(u32 selector);
- void (fastcall *set_kernel_stack)(u32 selector, u32 esp0);
- void (fastcall *allocate_page)(u32, u32, u32, u32, u32);
- void (fastcall *release_page)(u32, u32);
- void (fastcall *set_pte)(pte_t, pte_t *, unsigned);
- void (fastcall *update_pte)(pte_t *, unsigned);
- void (fastcall *set_linear_mapping)(int, u32, u32, u32);
- void (fastcall *flush_tlb)(int);
- void (fastcall *set_initial_ap_state)(int, int);
- void (fastcall *halt)(void);
+static struct {
+ void (*cpuid)(void /* non-c */);
+ void (*_set_ldt)(u32 selector);
+ void (*set_tr)(u32 selector);
+ void (*set_kernel_stack)(u32 selector, u32 esp0);
+ void (*allocate_page)(u32, u32, u32, u32, u32);
+ void (*release_page)(u32, u32);
+ void (*set_pte)(pte_t, pte_t *, unsigned);
+ void (*update_pte)(pte_t *, unsigned);
+ void (*set_linear_mapping)(int, u32, u32, u32);
+ void (*flush_tlb)(int);
+ void (*set_initial_ap_state)(int, int);
+ void (*halt)(void);
} vmi_ops;
/* XXX move this to alternative.h */
@@ -90,7 +90,7 @@
#define IRQ_PATCH_INT_MASK 0
#define IRQ_PATCH_DISABLE 5
-static inline void patch_offset(unsigned char *eip, unsigned char *dest)
+static void patch_offset(unsigned char *eip, unsigned char *dest)
{
*(unsigned long *)(eip+1) = dest-eip-5;
}
@@ -169,8 +169,8 @@
}
/* CPUID has non-C semantics, and paravirt-ops API doesn't match hardware ISA
*/
-static fastcall void vmi_cpuid(unsigned int *eax, unsigned int *ebx,
- unsigned int *ecx, unsigned int *edx)
+static void vmi_cpuid(unsigned int *eax, unsigned int *ebx,
+ unsigned int *ecx, unsigned int *edx)
{
int override = 0;
if (*eax == 1)
@@ -195,13 +195,14 @@
}
}
-static inline void vmi_maybe_load_tls(struct desc_struct *gdt, int nr, struct
desc_struct *new)
+static void vmi_maybe_load_tls(struct desc_struct *gdt, int nr,
+ struct desc_struct *new)
{
if (gdt[nr].a != new->a || gdt[nr].b != new->b)
write_gdt_entry(gdt, nr, new->a, new->b);
}
-static fastcall void vmi_load_tls(struct thread_struct *t, unsigned int cpu)
+static void vmi_load_tls(struct thread_struct *t, unsigned int cpu)
{
struct desc_struct *gdt = get_cpu_gdt_table(cpu);
vmi_maybe_load_tls(gdt, GDT_ENTRY_TLS_MIN + 0, >tls_array[0]);
@@ -209,7 +210,7 @@
vmi_maybe_load_tls(gdt, GDT_ENTRY_TLS_MIN + 2, >tls_array[2]);
}
-static fastcall void vmi_set_ldt(const void *addr, unsigned entries)
+static void vmi_set_ldt(const void *addr, unsigned entries)
{
unsigned cpu = smp_processor_id();
u32 low, high;
@@ -221,13 +222,13 @@
vmi_ops._set_ldt(entries ? GDT_ENTRY_LDT*sizeof(struct desc_struct) :
0);
}
[2.6 patch] drivers/acpi/hotkey.c: make 2 structs static
This patch makes two needlessly global structs static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.20-rc6-mm1/drivers/acpi/hotkey.c.old 2007-01-28
23:31:03.0 +0100
+++ linux-2.6.20-rc6-mm1/drivers/acpi/hotkey.c 2007-01-28 23:31:23.0
+0100
@@ -234,8 +234,8 @@
.release = single_release,
};
-struct acpi_hotkey_list global_hotkey_list;/* link all ev or pl hotkey */
-struct list_head hotkey_entries; /* head of the list of hotkey_list */
+static struct acpi_hotkey_list global_hotkey_list; /* link all ev or pl
hotkey */
+static struct list_head hotkey_entries;/* head of the list of
hotkey_list */
static int hotkey_info_seq_show(struct seq_file *seq, void *offset)
{
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Advice on APM-EMU reunion
On Tue, Jan 30, 2007 at 12:07:56AM +0100, Rodolfo Giometti wrote: > some months ago I sent to the MIPS and ARM mail lists a patch to unify > the several APM emulation codes adding a new dedicated directory so it > can be used to put there the per board specific code avoiding code > duplications (see files ./arch/arm/kernel/apm.c, > ./arch/mips/kernel/apm.c and ./arch/sh/kernel/apm.c that are almost > the same). > > The patch is here > "http://www.linux-mips.org/archives/linux-mips/2006-07/msg00144.html; > and it has been lost in the deep space... > Not quite, the rationale for it being dropped was here: http://article.gmane.org/gmane.linux.kernel/485831 However, it has since been reposted: http://article.gmane.org/gmane.linux.kernel/485833 http://article.gmane.org/gmane.linux.kernel/485834 http://article.gmane.org/gmane.linux.kernel/485835 http://article.gmane.org/gmane.linux.kernel/485837 and merged back in to -mm. This is all post 2.6.20 stuff, though.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] sd: spin down disks on removal or power-down
James Bottomley wrote: On Mon, 2007-01-29 at 15:47 -0800, Andrew Morton wrote: What we don't want to happen is for those disks to spin down during a reboot. It seems that this is OK with this patch. Also, we probably don't want them to be spun down during a kexec_load, but I expect that's OK too. Actually, there's another case where we don't want to do spin down, and that's when we don't own the disc (think external array on a SAN). Telling this has always been the biggest stumbling block to spin down of SCSI devices. There's a patch similar to yours which takes this into account, which is currently under discussion: http://marc.theaimsgroup.com/?t=11692262122 It looks like Tejun's patch essentially does the same thing as mine with the addition of the control from userspace. There is one exception though, my patch also does the stop on removal of the SCSI disk (i.e. writing 1 to its "delete" file in sysfs, what scsiadd -r does). I think it makes sense if the user selected the disk to be spun down on shutdown to do it on removal as well, as it is potentially about to be physically removed/powered down (especially for USB or FireWire disks). -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
