Mapping PCI memory to user-space
I am writing a driver to map a PCI board memory space (pcibar2) into a
user-space vma via 'mmap'. What is the relationship between the address
returned from ioremap and the type of address needed in the
'io_remap_page_range' or 'remap_pfn_range' functions? How about the
following? (I am developing under RHEL4 and a 2.6.9 kernel)
In the 'init' part of the driver:
dev.pcibar2 = ioremap_nocache(resource,size);
dev.region_start = dev.pcibar2 + offset; // RAM is at some offset
from base
dev.region_size =
In the mydriver_mmap function:
static ssize_t mydriver_mmap (struct file *filp,
struct vm_area_struct
*vma)
{
// off = convert vm_pgoff back to user-space mmap 'off' value
// phyaddr = physical address of PCI memory area
// vsize = total size of area user wants to map
// psize = total avail size in device
struct mydriver_dev *dev = filp->private_data;
unsigned long off = vma->vm_pgoff << PAGE_SHIFT;
unsigned long phy= __pa(dev->region_start + off);
unsigned long vsize = vma->vm_end - vma->vm_start;
unsigned long psize = dev->region_size - off;
if (vsize > psize)
return -EINVAL; /* spans too high */
if (io_remap_page_range(vma, phyaddr, vma->vm_start, vsize,
vma->vm_page_prot))
return -EAGAIN;
vma->vm_ops= &mydriver_vm_ops;
vma->vm_flags |= VM_IO | VM_RESERVED;
mydriver_vma_open(vma);
return 0;
}
--
View this message in context:
http://www.nabble.com/Mapping-PCI-memory-to-user-space-tf4682416.html#a13380086
Sent from the linux-kernel mailing list archive at Nabble.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] LinuxPPS - PPS support for Linux
On Tue, Oct 23, 2007 at 02:08:19PM -0700, Roland Dreier wrote:
> A few comments:
>
> > + dev_err(port->dev, "PPS support disabled due port \"%s\" is "
> > + "in polling mode\n",
>
> I think "because" instead of "due" is closer to standard English.
Fixed.
> > + printk(KERN_ERR "pps: %s: too much PPS sources in the system\n",
> > + info->name);
>
> Similarly should be "many" instead of "much".
Fixed.
> > + /* Get new ID for the new PPS source */
> > + if (idr_pre_get(&pps_idr, GFP_KERNEL) == 0) {
> > + err = -ENOMEM;
> > + goto kfree_pps;
> > + }
> > +
> > + spin_lock_irq(&idr_lock);
> > + err = idr_get_new(&pps_idr, pps, &id);
> > + spin_unlock_irq(&idr_lock);
> > +
> > + if (err < 0)
> > + goto kfree_pps;
>
> You usually can handle idr_get_new() returning -EAGAIN by jumping back
> to the idr_pre_get(), to handle someone else coming in and stealing
> the memory you just preallocated. In this case it may not matter
> since it's pretty unlikely that a lot of contexts are using the idr at
> the same time. But anyway...
I don't understand what you mean. Can you please submit an example
code?
> > +void pps_unregister_source(int source)
> > ...
> > + wait_event(pps->usage_queue, atomic_read(&pps->usage) == 0);
> > +
> > + pps_sysfs_remove_source_entry(pps);
> > + pps_unregister_cdev(pps);
> > + kfree(pps);
>
> This reference counting looks dubious to me... later on in the code
> you have:
>
> > +static int pps_cdev_open(struct inode *inode, struct file *file)
> > +{
> > + struct pps_device *pps = container_of(inode->i_cdev,
> > + struct pps_device, cdev);
> > +
> > + /* Lock the PPS source against (possible) deregistration */
> > + atomic_inc(&pps->usage);
>
> with no locking, so I see no reason why the atomic_inc() couldn't
> happen right after the wait_event() sees a count of 0 and lets the
> deregistration continue. Which would lead to use-after-free.
Mmm... you are right... can you please suggest to me how can I easily
fix this problem?
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
Linux Device Driver [EMAIL PROTECTED]
Embedded Systems[EMAIL PROTECTED]
UNIX programming phone: +39 349 2432127
-
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] usb/core/message.c: scatterlist include fix
On Tue, Oct 23 2007, Helge Deller wrote: > This fixes following bug when building for parisc-linux: > > drivers/usb/core/message.c: In function `usb_sg_init': > drivers/usb/core/message.c:440: error: implicit declaration of function > `sg_virt' This already got fixed by commit 117636092a87a28a013a4acb5de5492645ed620f from Ralf. -- Jens Axboe - 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 09/10] Change table chaining layout
On Tue, Oct 23 2007, Geert Uytterhoeven wrote: > On Tue, 23 Oct 2007, Ingo Molnar wrote: > > * Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > > > Linus' latest tree, which has your SG-list enhancements included, > > > > certainly works fine here and does not have the problems of the > > > > first iteration. > > > > > > That's good to hear :-) > > > > > > I have a series of pending patches where I've collected fallout > > > patches from people and some from myself here: > > > > > > http://git.kernel.dk/?p=linux-2.6-block.git;a=shortlog;h=sg > > > > > > or pullable from > > > > > > git://git.kernel.dk/inux-2.6-block.git sg > > > > i've attached your fixes as a diff against linus-latest below - for > > those who'd like to have it in patch form. > > The below are still needed for m68k The wep.c was already applied, I applied the rest of them. Thanks! -- Jens Axboe - 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] PCI: disable MSI on more ATI NorthBridges
On Tue, Oct 23, 2007 at 07:41:55PM -0700, David Miller wrote: > From: "Shane Huang" <[EMAIL PROTECTED]> > Date: Tue, 23 Oct 2007 18:56:03 +0800 > > > Also I wonder why the USB MSI patch is not added into kernel at last? > > Will it lead to other bugs? > > Probably someone just needs to be more vocal and active in pushing it > to the USB subsystem maintainer(s). I've even had trouble getting > even simple bug fixes integrated recently, so perhaps it will take a > few retransmits and some patience to get it included. Yeah, I appologize for some of our developers, they seem a bit grumpy at times :( > Greg, can you at least devote a few minutes to going over that USB MSI > patch, giving it any obvious things it needs (perhaps some > pci_msi_enable() return value checks, for example, but may not be > needed at all in this case) and then stash it somewhere so it doesn't > get lost in the void? Can someone forward it to me so that I can see it? I can't seem to locate it at the moment, was I copied on it? 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/
[PATCH] taskstats scaled time cleanup
This moves the ability to scale cputime into generic code. This
allows us to fix the issue in kernel/timer.c (noticed by Balbir) where
we could only add an unscaled value to the scaled utime/stime.
This adds a cputime_to_scaled function. As before, the POWERPC
version does the scaling based on the last SPURR/PURR ratio
calculated. The generic and s390 (only other arch to implement
asm/cputime.h) versions are both NOPs.
Also moves the SPURR and PURR snapshots closer.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/time.c| 14 +++---
include/asm-generic/cputime.h |1 +
include/asm-powerpc/cputime.h | 14 ++
include/asm-powerpc/paca.h|2 --
include/asm-s390/cputime.h|1 +
kernel/timer.c|9 +
6 files changed, 28 insertions(+), 13 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/time.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/time.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/time.c
@@ -66,6 +66,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_PPC_ISERIES
#include
#include
@@ -186,6 +187,8 @@ u64 __cputime_sec_factor;
EXPORT_SYMBOL(__cputime_sec_factor);
u64 __cputime_clockt_factor;
EXPORT_SYMBOL(__cputime_clockt_factor);
+DEFINE_PER_CPU(unsigned long, cputime_last_delta);
+DEFINE_PER_CPU(unsigned long, cputime_scaled_last_delta);
static void calc_cputime_factors(void)
{
@@ -232,9 +235,9 @@ void account_system_vtime(struct task_st
local_irq_save(flags);
now = read_purr();
+ nowscaled = read_spurr(now);
delta = now - get_paca()->startpurr;
get_paca()->startpurr = now;
- nowscaled = read_spurr(now);
deltascaled = nowscaled - get_paca()->startspurr;
get_paca()->startspurr = nowscaled;
if (!in_interrupt()) {
@@ -247,9 +250,9 @@ void account_system_vtime(struct task_st
get_paca()->system_time = 0;
}
account_system_time(tsk, 0, delta);
- get_paca()->purrdelta = delta;
+ per_cpu(cputime_last_delta, smp_processor_id()) = delta;
account_system_time_scaled(tsk, deltascaled);
- get_paca()->spurrdelta = deltascaled;
+ per_cpu(cputime_scaled_last_delta, smp_processor_id()) = deltascaled;
local_irq_restore(flags);
}
@@ -267,10 +270,7 @@ void account_process_vtime(struct task_s
get_paca()->user_time = 0;
account_user_time(tsk, utime);
- /* Estimate the scaled utime by scaling the real utime based
-* on the last spurr to purr ratio */
- utimescaled = utime * get_paca()->spurrdelta / get_paca()->purrdelta;
- get_paca()->spurrdelta = get_paca()->purrdelta = 0;
+ utimescaled = cputime_to_scaled(utime);
account_user_time_scaled(tsk, utimescaled);
}
Index: linux-2.6-ozlabs/include/asm-generic/cputime.h
===
--- linux-2.6-ozlabs.orig/include/asm-generic/cputime.h
+++ linux-2.6-ozlabs/include/asm-generic/cputime.h
@@ -18,6 +18,7 @@ typedef unsigned long cputime_t;
#define cputime_lt(__a, __b) ((__a) < (__b))
#define cputime_le(__a, __b) ((__a) <= (__b))
#define cputime_to_jiffies(__ct) (__ct)
+#define cputime_to_scaled(__ct)(__ct)
#define jiffies_to_cputime(__hz) (__hz)
typedef u64 cputime64_t;
Index: linux-2.6-ozlabs/include/asm-powerpc/cputime.h
===
--- linux-2.6-ozlabs.orig/include/asm-powerpc/cputime.h
+++ linux-2.6-ozlabs/include/asm-powerpc/cputime.h
@@ -52,12 +52,26 @@ typedef u64 cputime64_t;
* Convert cputime <-> jiffies
*/
extern u64 __cputime_jiffies_factor;
+DECLARE_PER_CPU(unsigned long, cputime_last_delta);
+DECLARE_PER_CPU(unsigned long, cputime_scaled_last_delta);
static inline unsigned long cputime_to_jiffies(const cputime_t ct)
{
return mulhdu(ct, __cputime_jiffies_factor);
}
+/* Estimate the scaled cputime by scaling the real cputime based on
+ * the last scaled to real ratio */
+static inline cputime_t cputime_to_scaled(const cputime_t ct)
+{
+ if (cpu_has_feature(CPU_FTR_SPURR) &&
+ per_cpu(cputime_last_delta, smp_processor_id()))
+ return ct *
+ per_cpu(cputime_scaled_last_delta, smp_processor_id())/
+ per_cpu(cputime_last_delta, smp_processor_id());
+ return ct;
+}
+
static inline cputime_t jiffies_to_cputime(const unsigned long jif)
{
cputime_t ct;
Index: linux-2.6-ozlabs/include/asm-powerpc/paca.h
===
--- linux-2.6-ozlabs.orig/include/asm-powerpc/paca.h
+++ linux-2.6-ozlabs/include/asm-powerpc/paca.h
@@ -115,8 +115,6 @@ struct paca_struct {
u64 system_time;/* accumulated system TB ticks */
u64 startpurr;
sysfs sys/kernel/ namespace (was Re: [PATCH 0/2] add new notifier function ,take2)
On Tuesday 23 October 2007 10:55, Takenori Nagano wrote: > Nick Piggin wrote: > > One thing I'd suggest is not to use debugfs, if it is going to > > be a useful end-user feature. > > Is /sys/kernel/notifier_name/ an appropriate place? Hi list, I'm curious about the /sys/kernel/ namespace. I had presumed that it is intended to replace /proc/sys/ basically with the same functionality. I _assume_ these are system software stats and tunables that are not exactly linked to device drivers (OTOH, where do you draw the line? eg. Would filesystems go here? Core network algorithm tunables might, but per interface ones probably not...). I don't know. Is there guidelines for sysfs (and procfs for that matter)? Is anyone maintaining it (not the infrastructure, but the actual content)? It's kind of ironic that /proc/sys/ looks like one of the best organised directories in proc, while /sys/kernel seems to be in danger of becoming a mess: it has kexec and uevent files in the base directory, rather than in subdirectories... - 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/
is CONFIG_APUS sufficiently deceased to be removed?
since a couple relatively recent commits show support for APUS being ripped out of powerpc: commit e6b6e3ffb9ee8926f9f2f7dc9147df73e27d5828 Author: Adrian Bunk <[EMAIL PROTECTED]> Date: Mon Aug 27 23:29:53 2007 +0200 [POWERPC] Remove APUS support from arch/ppc Current status of APUS: - arch/powerpc/: removed in 2.6.23 - arch/ppc/: marked BROKEN since 2 years This therefore removes the remaining parts of APUS support from arch/ppc, include/asm-ppc, arch/powerpc and include/asm-powerpc. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> ... commit f21f49ea639ac3f24824177dac1268af75a2d373 Author: David Gibson <[EMAIL PROTECTED]> Date: Wed Jun 13 14:52:54 2007 +1000 [POWERPC] Remove the dregs of APUS support from arch/powerpc APUS (the Amiga Power-Up System) is not supported under arch/powerpc and it's unlikely it ever will be. Therefore, this patch removes the fragments of APUS support code from arch/powerpc which have been copied from arch/ppc. A few APUS references are left in asm-powerpc in .h files which are still used from arch/ppc. Signed-off-by: David Gibson <[EMAIL PROTECTED]> Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> ... is it safe to assume that references to that non-existent Kconfig variable can be tossed? drivers/ide/ide-probe.c:#if defined(__mc68000__) || defined(CONFIG_APUS) drivers/ide/ide-probe.c:#endif /* __mc68000__ || CONFIG_APUS */ drivers/ide/ide-probe.c:#if !defined(__mc68000__) && !defined(CONFIG_APUS) drivers/ide/ide-probe.c:#endif /* __mc68000__ && CONFIG_APUS */ drivers/isdn/hisax/avm_pci.c:#ifdef CONFIG_APUS drivers/isdn/hisax/avm_pci.c:#endif /* CONFIG_APUS */ drivers/isdn/hisax/avm_pci.c:#ifdef CONFIG_APUS drivers/isdn/hisax/avm_pci.c:#endif /* CONFIG_APUS */ drivers/video/console/fbcon.c:#if defined(__mc68000__) || defined(CONFIG_APUS) drivers/video/console/fonts.c:#if defined(__mc68000__) || defined(CONFIG_APUS) drivers/video/console/fonts.c:#if defined(__mc68000__) || defined(CONFIG_APUS) drivers/scsi/oktagon_esp.c:#if defined(CONFIG_AMIGA) || defined(CONFIG_APUS) drivers/scsi/oktagon_io.S:#ifdef CONFIG_APUS sound/oss/dmasound/dmasound_paula.c:#ifdef CONFIG_APUS[well, i'd ignore this one] and i'm guessing this can be nullified as well, yes? no? arch/m68k/amiga/chipram.c:#ifndef CONFIG_APUS_FAST_EXCEPT rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - 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/12] riscom8: fix SMP brokenness
Jiri Slaby wrote: On 10/24/2007 12:36 AM, Jeff Garzik wrote: After analyzing the elements that save_flags/cli/sti/restore_flags were protecting, convert their usages to a global spinlock (the easiest and most obvious next-step). There were some usages of flags being intentionally cached, because the code already knew the state of interrupts. These have been taken into account. This allows us to remove CONFIG_BROKEN_ON_SMP. Completely untested. Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> --- [...] diff --git a/drivers/char/riscom8.c b/drivers/char/riscom8.c index b37e626..45d109c 100644 --- a/drivers/char/riscom8.c +++ b/drivers/char/riscom8.c [...] @@ -82,6 +83,8 @@ static struct riscom_board * IRQ_to_board[16]; static struct tty_driver *riscom_driver; +static spinlock_t riscom_lock = SPIN_LOCK_UNLOCKED; This is deprecated (see linux/spinlock_types.h for details), use DEFINE_SPINLOCK instead, otherwise seems OK. Revieweved-by: Jiri Slaby <[EMAIL PROTECTED]> I noticed you reviewed my other riscom8 patch... you don't have hardware perchance, do you? :) 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 1/2] CFS CGroup: Code cleanup
* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote: > On Tue, Oct 23, 2007 at 07:32:27PM -0700, Paul Menage wrote: > > Clean up some CFS CGroup code > > > > - replace "cont" with "cgrp" in a few places in the CFS cgroup code, > > - use write_uint rather than write for cpu.shares write function > > > > Signed-off-by: Paul Menage <[EMAIL PROTECTED]> > > Acked-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]> thanks, applied. 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 4/12] riscom8: fix SMP brokenness
On 10/24/2007 12:36 AM, Jeff Garzik wrote: > After analyzing the elements that save_flags/cli/sti/restore_flags were > protecting, convert their usages to a global spinlock (the easiest and > most obvious next-step). There were some usages of flags being > intentionally cached, because the code already knew the state of > interrupts. These have been taken into account. > > This allows us to remove CONFIG_BROKEN_ON_SMP. Completely untested. > > Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> > --- > [...] > diff --git a/drivers/char/riscom8.c b/drivers/char/riscom8.c > index b37e626..45d109c 100644 > --- a/drivers/char/riscom8.c > +++ b/drivers/char/riscom8.c [...] > @@ -82,6 +83,8 @@ > static struct riscom_board * IRQ_to_board[16]; > static struct tty_driver *riscom_driver; > > +static spinlock_t riscom_lock = SPIN_LOCK_UNLOCKED; This is deprecated (see linux/spinlock_types.h for details), use DEFINE_SPINLOCK instead, otherwise seems OK. Revieweved-by: Jiri Slaby <[EMAIL PROTECTED]> thanks, -- Jiri Slaby ([EMAIL PROTECTED]) Faculty of Informatics, Masaryk University - 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: IDE crash...
On Tue, Oct 23 2007, John Stoffel wrote:
> > "Jens" == Jens Axboe <[EMAIL PROTECTED]> writes:
>
> Jens> On Tue, Oct 23 2007, David Miller wrote:
> >> From: Jens Axboe <[EMAIL PROTECTED]>
> >> Date: Tue, 23 Oct 2007 09:23:59 +0200
> >>
> >> > On Tue, Oct 23 2007, David Miller wrote:
> >> > > From: Jens Axboe <[EMAIL PROTECTED]>
> >> > > Date: Tue, 23 Oct 2007 09:09:33 +0200
> >> > >
> >> > > > Eh this wont work, it's the wrong entry... Here's a temporary
> >> > > > work-around.
> >> > > >
> >> > > > diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
> >> > > > index c89f0d3..108202b 100644
> >> > > > --- a/drivers/ide/ide-io.c
> >> > > > +++ b/drivers/ide/ide-io.c
> >> > > > @@ -822,6 +822,7 @@ void ide_map_sg(ide_drive_t *drive, struct
> >> > > > request *rq)
> >> > > > return;
> >> > > >
> >> > > > if (rq->cmd_type != REQ_TYPE_ATA_TASKFILE) {
> >> > > > +sg_init_table(hwif->sg_table, hwif->sg_max_nents);
> >> > > > hwif->sg_nents = blk_rq_map_sg(drive->queue, rq, sg);
> >> > > > } else {
> >> > > > sg_init_one(sg, rq->buffer, rq->nr_sectors *
> >> > > > SECTOR_SIZE);
> >> > >
> >> > > That's the exact patch I'm about to boot test :-)
> >> >
> >> > That should work - once you verify that, would you mind testing this one
> >> > as well? Thanks!
> >>
> >> This one works here too, thanks.
>
> Jens> Great, thanks for testing that as well. Thinking a bit more
> Jens> about it, I think the forced clear should stay in
> Jens> blk_rq_map_sg() since we don't want to advertise it to
> Jens> drivers. So I'll just open-code it in there.
>
> Should there be more bounds checking here, so that if you try to do a
> _force() you at least check to make sure that there's something beyond
> there and useable on the list?
>
> We're saving the time from not reallocating from scratch, but let's
> make it robust by doing at least some more checks here.
We have to rely on the caller passing in an sgtable that is big enough
to map the request, we have always made that assumption. Anything else
would be a bug, of course. Now, catching that bug would indeed be nice.
Any suggestions?
--
Jens Axboe
-
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] sg: add missing sg_init_table calls to zfcp
On Wed, Oct 24 2007, Heiko Carstens wrote: > From: Heiko Carstens <[EMAIL PROTECTED]> > > CONFIG_DEBUG_SG reveals two missing sg_init_table calls. Add them. > > kernel BUG at include/linux/scatterlist.h:50! > illegal operation: 0001 [#1] > [...] > Call Trace: > ([<0026f184>] zfcp_ns_gid_pn_request+0x4c/0x2a0) > [<00276dd4>] zfcp_erp_strategy_do_action+0x1410/0x1938 > [<00278412>] zfcp_erp_thread+0x4fa/0x1430 > [<0001990a>] kernel_thread_starter+0x6/0xc > [<00019904>] kernel_thread_starter+0x0/0xc > > Cc: Swen Schillig <[EMAIL PROTECTED]> > Cc: Christof Schmitt <[EMAIL PROTECTED]> > Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]> > --- > > Jens, could you please push this one via your tree? Thanks! You bet, thanks! -- Jens Axboe - 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: [SPARC64]: More SG build fixes
On Tue, Oct 23 2007, David Miller wrote: > > diff --git a/arch/sparc64/kernel/ldc.c b/arch/sparc64/kernel/ldc.c > index c8313cb..217478a 100644 > --- a/arch/sparc64/kernel/ldc.c > +++ b/arch/sparc64/kernel/ldc.c > @@ -2121,7 +2121,7 @@ int ldc_map_sg(struct ldc_channel *lp, > state.nc = 0; > > for (i = 0; i < num_sg; i++) > - fill_cookies(&state, page_to_pfn(sg[i].page) << PAGE_SHIFT, > + fill_cookies(&state, page_to_pfn(sg_page(&sg[i])) << PAGE_SHIFT, >sg[i].offset, sg[i].length); > > return state.nc; > diff --git a/drivers/block/sunvdc.c b/drivers/block/sunvdc.c > index 7276f7d..fac4c6c 100644 > --- a/drivers/block/sunvdc.c > +++ b/drivers/block/sunvdc.c > @@ -15,6 +15,7 @@ > #include > #include > #include > +#include > > #include > #include added -- Jens Axboe - 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]: [PCI]: Add MSI INTX_DISABLE quirks for ATI SB700/800 SATA and IXP SB400 USB
This patch and the third one seems can make my SB700 SATA controller work under MSI(simply tested on 2.6.23-rc5). So you may withdraw the RS690/RD580/RX790 MSI disablement patches http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi t;h=4be8f906435a6af241821ab5b94b2b12cb7d57d8 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi t;h=aea6a433f50cd89b9cbd10850fd0b32f961f9883 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi t;h=f122392f679ebed39db08074f935d770504623eb after the commit of these MSI/INTx quirks. Thanks Shane > -Original Message- > From: David Miller [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 24, 2007 10:54 AM > To: linux-kernel@vger.kernel.org > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Shane Huang; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [PATCH 4/4]: [PCI]: Add MSI INTX_DISABLE quirks for ATI SB700/800 SATA and IXP SB400 USB > > > Signed-off-by: David S. Miller <[EMAIL PROTECTED]> > --- > drivers/pci/quirks.c | 20 > 1 files changed, 20 insertions(+), 0 deletions(-) > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index 591eaa4..5795a3d 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -1725,4 +1725,24 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM, > PCI_DEVICE_ID_TIGON3_5714S, > quirk_msi_intx_disable_bug); > > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4390, > + quirk_msi_intx_disable_bug); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4391, > + quirk_msi_intx_disable_bug); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4392, > + quirk_msi_intx_disable_bug); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4393, > + quirk_msi_intx_disable_bug); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4394, > + quirk_msi_intx_disable_bug); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4395, > + quirk_msi_intx_disable_bug); > + > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4373, > + quirk_msi_intx_disable_bug); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4374, > + quirk_msi_intx_disable_bug); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4375, > + quirk_msi_intx_disable_bug); > + > #endif /* CONFIG_PCI_MSI */ > -- > 1.5.3.4 > > - 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: [SPARC64]: SG build fix.
On Tue, Oct 23 2007, David Miller wrote: > > Jens could you queue up this obvious typo build fix > for me? Certainly, thanks! -- Jens Axboe - 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/3] x86: unify crash_32/64.c
On Fri, Oct 19, 2007 at 06:18:27PM -0700, Hiroshi Shimamoto wrote: > Hi, > > I made patches to unify crash_32/64.c. > There are three patches; > 1. add lapic_shutdown for x86_64 > 2. add safe_smp_processor_id for x86_64 > 3. unify crash_32/64.c > > I'm not sure that it's good to split to these patches. > > I've compiled on both of 32bit and 64bit, and tested > kdump on 64bit. > Hi Hiroshi, Thanks for the patches. Can you please also test it on 32bit to make sure nothing is broken. Thanks Vivek - 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 2/3] x86: add safe_smp_processor_id for x86_64
On Fri, Oct 19, 2007 at 06:23:02PM -0700, Hiroshi Shimamoto wrote: > From: Hiroshi Shimamoto <[EMAIL PROTECTED]> > > Signed-off-by: Hiroshi Shimamoto <[EMAIL PROTECTED]> > --- > include/asm-x86/smp_64.h |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/include/asm-x86/smp_64.h b/include/asm-x86/smp_64.h > index 6f0e027..ab612b0 100644 > --- a/include/asm-x86/smp_64.h > +++ b/include/asm-x86/smp_64.h > @@ -76,6 +76,8 @@ extern unsigned __cpuinitdata disabled_cpus; > > #endif /* CONFIG_SMP */ > > +#define safe_smp_processor_id() smp_processor_id() > + Can you please implement a patch for safe_smp_processor_id() instead of using smp_processor_id(). safe_smp_processor_id() was introduced to make sure that we are not dependent on the stack of threads after kernel has crashed instead read the apic id and convert it to cpu id with other data structures. This helped in stack overflow case. Hardcoding it to smp_processor_id() will give the false impression. Thanks Vivek - 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 1/3] x86: add lapic_shutdown for x86_64
On Fri, Oct 19, 2007 at 06:21:11PM -0700, Hiroshi Shimamoto wrote:
> From: Hiroshi Shimamoto <[EMAIL PROTECTED]>
>
> Signed-off-by: Hiroshi Shimamoto <[EMAIL PROTECTED]>
> ---
> arch/x86/kernel/apic_64.c | 14 ++
> include/asm-x86/apic_64.h |1 +
> 2 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel/apic_64.c
> index f47bc49..f28ccb5 100644
> --- a/arch/x86/kernel/apic_64.c
> +++ b/arch/x86/kernel/apic_64.c
> @@ -287,6 +287,20 @@ void disable_local_APIC(void)
> apic_write(APIC_SPIV, value);
> }
>
> +void lapic_shutdown(void)
> +{
> + unsigned long flags;
> +
> + if (!cpu_has_apic)
> + return;
> +
> + local_irq_save(flags);
> +
> + disable_local_APIC();
> +
> + local_irq_restore(flags);
> +}
> +
> /*
Do we really have to introduce this function for 64bit? I remember some
issues were faced on i386 w.r.t kernel enabling the LAPIC against the
wishes of BIOS hence kernel was disabling it while shutting down. No
such problems were reported for x86_64 hence this function existed only
for i386.
If that is the case, probably we don't have to introduce lapic_shutdown()
for x86_64. Instead call lapic_shutdown() for X86_32, and disble_local_APIC()
otherwise?
Thanks
Vivek
-
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] Fixing the warning in cgroup.c
On Sun, 21 Oct 2007 23:00:20 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> Removing the unused variable root.
>
> kernel/cgroup.c: In function ‘proc_cgroupstats_show’:
> kernel/cgroup.c:2405: warning: unused variable ‘root’
ERROR: Invalid UTF-8
#3:
kernel/cgroup.c: In function proc_cgroupstats_show:
ERROR: Invalid UTF-8
#4:
kernel/cgroup.c:2405: warning: unused variable root
total: 2 errors, 0 warnings, 7 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Please use LANG=C so gcc doesn't do this.
> Signed-off-by: Kamalesh Babulal <[EMAIL PROTECTED]>
>
> Index: linux-git/kernel/cgroup.c
> ===
> --- linux-git.orig/kernel/cgroup.c 2007-10-21 08:49:15.0 +0530
> +++ linux-git/kernel/cgroup.c 2007-10-21 22:24:13.0 +0530
> @@ -2402,7 +2402,6 @@ struct file_operations proc_cgroup_opera
> static int proc_cgroupstats_show(struct seq_file *m, void *v)
> {
> int i;
> - struct cgroupfs_root *root;
>
> seq_puts(m, "#subsys_name\thierarchy\tnum_cgroups\n");
> mutex_lock(&cgroup_mutex);
your email client is converting tabs to spaces.
-
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 2/12] X86: fix nvidia HPET warning
Jeremy Fitzhardinge wrote: Jeff Garzik wrote: arch/x86/kernel/early-quirks.c:40: warning: ‘nvidia_hpet_check’ defined but not used Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> --- diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c index dc34acb..639e632 100644 --- a/arch/x86/kernel/early-quirks.c +++ b/arch/x86/kernel/early-quirks.c @@ -35,12 +35,14 @@ static void __init via_bugs(void) } #ifdef CONFIG_ACPI +#ifdef CONFIG_X86_IO_APIC Why not #if defined(CONFIG_ACPI) && defined(CONFIG_X86_IO_APIC)? Saves a line and a layer of #if(def). quite agreed, but I was merely duplicating (with precision :)) the ifdef-ery used in the caller 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.22.7 reboots if PCI-X eth card is used for capture
Hi, i run a machine with 4 dual gigabit ethernet cards utilizing 2.6.22.7. All cards are PCI-E, one card is PCI-X, all Gigabit Ethernet from Intel. This is working fine and stable if only the PCI-E cards are used. If i try to capture packets on the PCI-X card, the machine reboots after some seconds. I think i can rule out a hardware defect, as i actually run two of this machines with equal hard and software and the problem occurs on both machines. This is perfectly reproducible but i am unable to debug this, as no (oops) messages are ever written to the syslog. As the machine instantly reboots i guess there will be nothing valueable shown on the display. The interrupt layout: (cat /proc/interrupts) 16: 36 6430 0 IO-APIC-fasteoi eth0 18: 33 5305126 IO-APIC-fasteoi uhci_hcd:us b1, ehci_hcd:usb4, eth1 211: 2143 2210 127682533 PCI-MSI-edge eth9 212: 5332 5818 102983594001 PCI-MSI-edge eth8 213:129 464195525683 6 PCI-MSI-edge eth7 214: 13528 14184 34425 11239040 PCI-MSI-edge eth6 215: 502771165821388 14 PCI-MSI-edge eth5 216:595590 347154857 PCI-MSI-edge eth4 217: 48153 5760 2653 PCI-MSI-edge eth2 The card in question is eth0+eth1. I even tried the following boot kernel parameters with NO success. nousb (don't need it, suspected the irq sharing as problem source) pci=nomsi (this recommended my hardware vendor) I need some advice, howto debug or solve this. As i usually don't read the list, i would like to be cc'd. Cheers Michael - 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: Hard lockups on 2.6.22.4-SMP
Hello, Answering to myself. OAA> We have a problem with spontaneous (there is no relation with CPU OAA> load, memory load, uptime) hard lockups on linux 2.6.22.4 (no OAA> additional patches) on SMP system (Intel E7230 ICH7 Montherboard). Num OAA> Lock (Caps Lock - no matter) on keyboard is not responding. There is OAA> no debug on console (no oops, no kernel panic, no NMI watchdog info OAA> [but nmi_watchdog=1 and NMI in /proc/interrupts is OK]). All we see is OAA> just previous console state (for example - login: prompt). We have the OAA> same situation on another PC with abosolutely the some hardware and OAA> software configuration. Could you give us some hints about how to OAA> debug this situation? If you need some additional information about OAA> our system, feel free to ask. I can post a lot of output (i.e. lspci, OAA> dmesg, etc...) but i don't want to post any useless information. Yesterday we added CONFIG_DEBUG_SPINLOCK and CONFIG_DEBUG_SPINLOCK_SLEEP to our kernel config. After six hours of uptime we got the same lockup, but the kernel became a little verbose: BUG: spinlock lockup on CPU#1, swapper/0, e9bcb200 Nothing else. No call trace, no cpu registers dump. Just this line. Any hints? -- wbr, Olegmailto:[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] Add eeprom_bad_csum_allow module option to e1000.
On Tue, Oct 23, 2007 at 04:03:38PM -0700, Kok, Auke wrote: > Dave Jones wrote: > > On Tue, Oct 23, 2007 at 04:40:01PM -0400, Jeff Garzik wrote: > > > > > > In any case, this patch should not be merged. We often send it around > > to users to > > > > debug their issue in case it involves eeproms, but merging it will > > just conceal > > > > the real issue and all of a sudden a flood of people stop reporting > > *real* issues > > > > to us. > > > > > > Sorry, I disagree. Just as with e100, if there is a clear way the user > > > can recover their setup -- and Adam says his was effective -- I don't > > > see why we should be denying users the ability to use their own > > hardware. > > > > Indeed. This is a common enough problem that not including it causes more > > pain > > than its worth. I have two affected boxes myself that I actually thought > > the hardware was dead before I tried ajax's patch. > > > look: You should have reported this to us and you didn't. Now you are using > the > fact that you did not report it as an argument which is out of place. you're missing the point. It looks like a hardware failure. Why would I report this? > why do you say it is common? how often have you seen this and not reported > it back > to our support? are you willingly trying to frustrate this issue? Not at all. The only frustration here is that I used to have a kernel that worked, upgraded, and thought that my hardware was broken. How many other users thought the same ? 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/
[RFC PATCH 5/5] Update get_online_cpus() in Documentation/cpu-hotplug.c
Update the documentation for cpu hotplug to reflect the use of newly added API's get_online_cpus()/put_online_cpus(); Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]> --- Documentation/cpu-hotplug.txt | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) Index: linux-2.6.23/Documentation/cpu-hotplug.txt === --- linux-2.6.23.orig/Documentation/cpu-hotplug.txt +++ linux-2.6.23/Documentation/cpu-hotplug.txt @@ -109,12 +109,13 @@ Never use anything other than cpumask_t for_each_cpu_mask(x,mask) - Iterate over some random collection of cpu mask. #include - lock_cpu_hotplug() and unlock_cpu_hotplug(): + get_online_cpus() and put_online_cpus(): -The above calls are used to inhibit cpu hotplug operations. While holding the -cpucontrol mutex, cpu_online_map will not change. If you merely need to avoid -cpus going away, you could also use preempt_disable() and preempt_enable() -for those sections. Just remember the critical section cannot call any +The above calls are used to inhibit cpu hotplug operations. While the +cpu_hotplug.refcount is non zero, the cpu_online_map will not change. +If you merely need to avoid cpus going away, you could also use +preempt_disable() and preempt_enable() for those sections. +Just remember the critical section cannot call any function that can sleep or schedule this process away. The preempt_disable() will work as long as stop_machine_run() is used to take a cpu down. -- Gautham R Shenoy Linux Technology Center IBM India. "Freedom comes with a price tag of responsibility, which is still a bargain, because Freedom is priceless!" - 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 PATCH 4/5] Remove CPU_DEAD/CPU_UP_CANCELLED handling from workqueue.c
cleanup_workqueue_thread() in the CPU_DEAD and CPU_UP_CANCELLED path
will cause a deadlock if the worker thread is executing a work item
which is blocked on get_online_cpus(). This will lead to a irrecoverable
hang.
Solution is not to cleanup the worker thread. Instead let it remain
even after the cpu goes offline. Since no one can queue any work
on an offlined cpu, this thread will be forever sleeping, untill
someone onlines the cpu.
With get_online_cpus()/put_online_cpus(), we can eliminate
the workqueue_mutex and reintroduce the workqueue_lock,
which is a spinlock which serializes the accesses to the
workqueues list.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
---
kernel/workqueue.c | 49 ++---
1 file changed, 18 insertions(+), 31 deletions(-)
Index: linux-2.6.23/kernel/workqueue.c
===
--- linux-2.6.23.orig/kernel/workqueue.c
+++ linux-2.6.23/kernel/workqueue.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -67,9 +68,8 @@ struct workqueue_struct {
#endif
};
-/* All the per-cpu workqueues on the system, for hotplug cpu to add/remove
- threads to each one as cpus come/go. */
-static DEFINE_MUTEX(workqueue_mutex);
+/* Serializes accesses to the workqueues list. */
+static DEFINE_SPINLOCK(workqueue_lock);
static LIST_HEAD(workqueues);
static int singlethread_cpu __read_mostly;
@@ -712,7 +712,7 @@ static void start_workqueue_thread(struc
if (p != NULL) {
if (cpu >= 0)
- kthread_bind(p, cpu);
+ set_cpus_allowed(p, cpumask_of_cpu(cpu));
wake_up_process(p);
}
}
@@ -748,9 +748,9 @@ struct workqueue_struct *__create_workqu
start_workqueue_thread(cwq, -1);
} else {
get_online_cpus();
- mutex_lock(&workqueue_mutex);
+ spin_lock(&workqueue_lock);
list_add(&wq->list, &workqueues);
- mutex_unlock(&workqueue_mutex);
+ spin_unlock(&workqueue_lock);
for_each_possible_cpu(cpu) {
cwq = init_cpu_workqueue(wq, cpu);
@@ -773,26 +773,19 @@ EXPORT_SYMBOL_GPL(__create_workqueue_key
static void cleanup_workqueue_thread(struct cpu_workqueue_struct *cwq, int cpu)
{
/*
-* Our caller is either destroy_workqueue() or CPU_DEAD,
-* workqueue_mutex protects cwq->thread
+* Our caller is destroy_workqueue(). So warn on a double
+* destroy.
*/
- if (cwq->thread == NULL)
+ if (cwq->thread == NULL) {
+ WARN_ON(1);
return;
+ }
lock_acquire(&cwq->wq->lockdep_map, 0, 0, 0, 2, _THIS_IP_);
lock_release(&cwq->wq->lockdep_map, 1, _THIS_IP_);
flush_cpu_workqueue(cwq);
- /*
-* If the caller is CPU_DEAD and cwq->worklist was not empty,
-* a concurrent flush_workqueue() can insert a barrier after us.
-* However, in that case run_workqueue() won't return and check
-* kthread_should_stop() until it flushes all work_struct's.
-* When ->worklist becomes empty it is safe to exit because no
-* more work_structs can be queued on this cwq: flush_workqueue
-* checks list_empty(), and a "normal" queue_work() can't use
-* a dead CPU.
-*/
+
kthread_stop(cwq->thread);
cwq->thread = NULL;
}
@@ -810,9 +803,9 @@ void destroy_workqueue(struct workqueue_
int cpu;
get_online_cpus();
- mutex_lock(&workqueue_mutex);
+ spin_lock(&workqueue_lock);
list_del(&wq->list);
- mutex_unlock(&workqueue_mutex);
+ spin_unlock(&workqueue_lock);
put_online_cpus();
for_each_cpu_mask(cpu, *cpu_map) {
@@ -842,33 +835,27 @@ static int __devinit workqueue_cpu_callb
cpu_set(cpu, cpu_populated_map);
}
- mutex_lock(&workqueue_mutex);
list_for_each_entry(wq, &workqueues, list) {
cwq = per_cpu_ptr(wq->cpu_wq, cpu);
switch (action) {
case CPU_UP_PREPARE:
+ if (likely(cwq->thread != NULL))
+ break;
if (!create_workqueue_thread(cwq, cpu))
break;
printk(KERN_ERR "workqueue [%s] for %i failed\n",
wq->name, cpu);
ret = NOTIFY_BAD;
- goto out_unlock;
+ goto out;
case CPU_ONLINE:
start_workqueue_thread(cwq, cpu);
break;
-
- case CPU_UP_CANCELED:
- start_workqueue_thread(cwq, -1);
- case CPU_DEAD:
- cleanup_workqueue_thread(cwq, cpu);
-
[SPARC64]: More SG build fixes
diff --git a/arch/sparc64/kernel/ldc.c b/arch/sparc64/kernel/ldc.c index c8313cb..217478a 100644 --- a/arch/sparc64/kernel/ldc.c +++ b/arch/sparc64/kernel/ldc.c @@ -2121,7 +2121,7 @@ int ldc_map_sg(struct ldc_channel *lp, state.nc = 0; for (i = 0; i < num_sg; i++) - fill_cookies(&state, page_to_pfn(sg[i].page) << PAGE_SHIFT, + fill_cookies(&state, page_to_pfn(sg_page(&sg[i])) << PAGE_SHIFT, sg[i].offset, sg[i].length); return state.nc; diff --git a/drivers/block/sunvdc.c b/drivers/block/sunvdc.c index 7276f7d..fac4c6c 100644 --- a/drivers/block/sunvdc.c +++ b/drivers/block/sunvdc.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include - 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 PATCH 3/5] Replace per-subsystem mutexes with get_online_cpus()
This patch converts the known per-subsystem mutexes to get_online_cpus
put_online_cpus. It also eliminates the CPU_LOCK_ACQUIRE
and CPU_LOCK_RELEASE hotplug notification events.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
---
include/linux/notifier.h |4 +---
kernel/cpu.c |4
kernel/sched.c | 27 ++-
kernel/workqueue.c | 31 ---
mm/slab.c| 18 +++---
5 files changed, 38 insertions(+), 46 deletions(-)
Index: linux-2.6.23/kernel/sched.c
===
--- linux-2.6.23.orig/kernel/sched.c
+++ linux-2.6.23/kernel/sched.c
@@ -360,7 +360,6 @@ struct rq {
};
static DEFINE_PER_CPU_SHARED_ALIGNED(struct rq, runqueues);
-static DEFINE_MUTEX(sched_hotcpu_mutex);
static inline void check_preempt_curr(struct rq *rq, struct task_struct *p)
{
@@ -4337,13 +4336,13 @@ long sched_setaffinity(pid_t pid, cpumas
struct task_struct *p;
int retval;
- mutex_lock(&sched_hotcpu_mutex);
+ get_online_cpus();
read_lock(&tasklist_lock);
p = find_process_by_pid(pid);
if (!p) {
read_unlock(&tasklist_lock);
- mutex_unlock(&sched_hotcpu_mutex);
+ put_online_cpus();
return -ESRCH;
}
@@ -4370,7 +4369,7 @@ long sched_setaffinity(pid_t pid, cpumas
out_unlock:
put_task_struct(p);
- mutex_unlock(&sched_hotcpu_mutex);
+ put_online_cpus();
return retval;
}
@@ -4427,7 +4426,7 @@ long sched_getaffinity(pid_t pid, cpumas
struct task_struct *p;
int retval;
- mutex_lock(&sched_hotcpu_mutex);
+ get_online_cpus();
read_lock(&tasklist_lock);
retval = -ESRCH;
@@ -4443,7 +4442,7 @@ long sched_getaffinity(pid_t pid, cpumas
out_unlock:
read_unlock(&tasklist_lock);
- mutex_unlock(&sched_hotcpu_mutex);
+ put_online_cpus();
return retval;
}
@@ -5342,9 +5341,6 @@ migration_call(struct notifier_block *nf
struct rq *rq;
switch (action) {
- case CPU_LOCK_ACQUIRE:
- mutex_lock(&sched_hotcpu_mutex);
- break;
case CPU_UP_PREPARE:
case CPU_UP_PREPARE_FROZEN:
@@ -5398,7 +5394,7 @@ migration_call(struct notifier_block *nf
BUG_ON(rq->nr_running != 0);
/* No need to migrate the tasks: it was best-effort if
-* they didn't take sched_hotcpu_mutex. Just wake up
+* they didn't do a get_online_cpus(). Just wake up
* the requestors. */
spin_lock_irq(&rq->lock);
while (!list_empty(&rq->migration_queue)) {
@@ -5412,9 +5408,6 @@ migration_call(struct notifier_block *nf
spin_unlock_irq(&rq->lock);
break;
#endif
- case CPU_LOCK_RELEASE:
- mutex_unlock(&sched_hotcpu_mutex);
- break;
}
return NOTIFY_OK;
}
@@ -6338,10 +6331,10 @@ static int arch_reinit_sched_domains(voi
{
int err;
- mutex_lock(&sched_hotcpu_mutex);
+ get_online_cpus();
detach_destroy_domains(&cpu_online_map);
err = arch_init_sched_domains(&cpu_online_map);
- mutex_unlock(&sched_hotcpu_mutex);
+ put_online_cpus();
return err;
}
@@ -6452,12 +6445,12 @@ void __init sched_init_smp(void)
{
cpumask_t non_isolated_cpus;
- mutex_lock(&sched_hotcpu_mutex);
+ get_online_cpus();
arch_init_sched_domains(&cpu_online_map);
cpus_andnot(non_isolated_cpus, cpu_possible_map, cpu_isolated_map);
if (cpus_empty(non_isolated_cpus))
cpu_set(smp_processor_id(), non_isolated_cpus);
- mutex_unlock(&sched_hotcpu_mutex);
+ put_online_cpus();
/* XXX: Theoretical race here - CPU may be hotplugged now */
hotcpu_notifier(update_sched_domains, 0);
Index: linux-2.6.23/mm/slab.c
===
--- linux-2.6.23.orig/mm/slab.c
+++ linux-2.6.23/mm/slab.c
@@ -730,8 +730,7 @@ static inline void init_lock_keys(void)
#endif
/*
- * 1. Guard access to the cache-chain.
- * 2. Protect sanity of cpu_online_map against cpu hotplug events
+ * Guard access to the cache-chain.
*/
static DEFINE_MUTEX(cache_chain_mutex);
static struct list_head cache_chain;
@@ -1331,12 +1330,11 @@ static int __cpuinit cpuup_callback(stru
int err = 0;
switch (action) {
- case CPU_LOCK_ACQUIRE:
- mutex_lock(&cache_chain_mutex);
- break;
case CPU_UP_PREPARE:
case CPU_UP_PREPARE_FROZEN:
+ mutex_lock(&cache_chain_mutex);
err = cpuup_prepare(cpu);
+ mutex_unlock(&cache_chain_mutex);
break;
case CPU_ONLINE:
case CPU_ONLINE_FROZEN:
@@ -1373,9 +1
[RFC PATCH 2/5] Replace lock_cpu_hotplug() with get_online_cpus()
Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel and use
get_online_cpus and put_online_cpus instead as it highlights
the refcount semantics in these operations.
The new API guarantees protection against the cpu-hotplug operation,
but it doesn't guarantee serialized access to any of the local data
structures. Hence the changes needs to be reviewed.
In case of pseries_add_processor/pseries_remove_processor, use
cpu_maps_update_begin()/cpu_maps_update_done() as we're modifying the
cpu_present_map there.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/mtrr/main.c |8
arch/i386/kernel/microcode.c | 16
arch/mips/kernel/mips-mt-fpaff.c | 10 +-
arch/powerpc/platforms/pseries/hotplug-cpu.c |8
arch/powerpc/platforms/pseries/rtasd.c |8
drivers/lguest/core.c|8
drivers/s390/char/sclp_config.c |4 ++--
include/linux/cpu.h |8
kernel/cpu.c | 10 +-
kernel/cpuset.c | 14 +++---
kernel/rcutorture.c |6 +++---
kernel/stop_machine.c|4 ++--
net/core/flow.c |4 ++--
13 files changed, 54 insertions(+), 54 deletions(-)
Index: linux-2.6.23/include/linux/cpu.h
===
--- linux-2.6.23.orig/include/linux/cpu.h
+++ linux-2.6.23/include/linux/cpu.h
@@ -100,8 +100,8 @@ static inline void cpuhotplug_mutex_unlo
mutex_unlock(cpu_hp_mutex);
}
-extern void lock_cpu_hotplug(void);
-extern void unlock_cpu_hotplug(void);
+extern void get_online_cpus(void);
+extern void put_online_cpus(void);
#define hotcpu_notifier(fn, pri) { \
static struct notifier_block fn##_nb = \
{ .notifier_call = fn, .priority = pri }; \
@@ -119,8 +119,8 @@ static inline void cpuhotplug_mutex_lock
static inline void cpuhotplug_mutex_unlock(struct mutex *cpu_hp_mutex)
{ }
-#define lock_cpu_hotplug() do { } while (0)
-#define unlock_cpu_hotplug() do { } while (0)
+#define get_online_cpus() do { } while (0)
+#define put_online_cpus() do { } while (0)
#define hotcpu_notifier(fn, pri) do { (void)(fn); } while (0)
/* These aren't inline functions due to a GCC bug. */
#define register_hotcpu_notifier(nb) ({ (void)(nb); 0; })
Index: linux-2.6.23/kernel/cpu.c
===
--- linux-2.6.23.orig/kernel/cpu.c
+++ linux-2.6.23/kernel/cpu.c
@@ -48,7 +48,7 @@ void __init cpu_hotplug_init(void)
#ifdef CONFIG_HOTPLUG_CPU
-void lock_cpu_hotplug(void)
+void get_online_cpus(void)
{
might_sleep();
if (cpu_hotplug.active_writer == current)
@@ -58,9 +58,9 @@ void lock_cpu_hotplug(void)
mutex_unlock(&cpu_hotplug.lock);
}
-EXPORT_SYMBOL_GPL(lock_cpu_hotplug);
+EXPORT_SYMBOL_GPL(get_online_cpus);
-void unlock_cpu_hotplug(void)
+void put_online_cpus(void)
{
if (cpu_hotplug.active_writer == current)
return;
@@ -73,7 +73,7 @@ void unlock_cpu_hotplug(void)
mutex_unlock(&cpu_hotplug.lock);
}
-EXPORT_SYMBOL_GPL(unlock_cpu_hotplug);
+EXPORT_SYMBOL_GPL(put_online_cpus);
#endif /* CONFIG_HOTPLUG_CPU */
@@ -110,7 +110,7 @@ void cpu_maps_update_done(void)
* non zero and goes to sleep again.
*
* However, this is very difficult to achieve in practice since
- * lock_cpu_hotplug() not an api which is called all that often.
+ * get_online_cpus() not an api which is called all that often.
*
*/
static void cpu_hotplug_begin(void)
Index: linux-2.6.23/kernel/stop_machine.c
===
--- linux-2.6.23.orig/kernel/stop_machine.c
+++ linux-2.6.23/kernel/stop_machine.c
@@ -203,13 +203,13 @@ int stop_machine_run(int (*fn)(void *),
int ret;
/* No CPUs can come up or down during this. */
- lock_cpu_hotplug();
+ get_online_cpus();
p = __stop_machine_run(fn, data, cpu);
if (!IS_ERR(p))
ret = kthread_stop(p);
else
ret = PTR_ERR(p);
- unlock_cpu_hotplug();
+ put_online_cpus();
return ret;
}
Index: linux-2.6.23/arch/i386/kernel/cpu/mtrr/main.c
===
--- linux-2.6.23.orig/arch/i386/kernel/cpu/mtrr/main.c
+++ linux-2.6.23/arch/i386/kernel/cpu/mtrr/main.c
@@ -351,7 +351,7 @@ int mtrr_add_page(unsigned long base, un
replace = -1;
/* No CPU hotplug when we change MTRR entries */
- lock_cpu_hotplug();
+ get_online_cpus();
/* Search for existing MTRR */
mutex_lock(&mtrr_mutex);
for (i = 0; i < num_var_ranges; ++
Re: [PATCH 3/4]: [PCI]: Add quirk for devices which disable MSI when INTX_DISABLE is set.
From: Michael Ellerman <[EMAIL PROTECTED]> Date: Wed, 24 Oct 2007 15:30:21 +1000 > That looks like 6 hunks doing exactly the same thing? What about > creating a pci_intx_quirked() (or something) that checks the flag and > then does/or does not call pci_intx(). Good idea, I'll add that to the patch. - 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 PATCH 1/5] Refcount Based Cpu Hotplug implementation
This patch implements a Refcount + Waitqueue based model for
cpu-hotplug.
Now, a thread which wants to prevent cpu-hotplug, will bump up a
global refcount and the thread which wants to perform a cpu-hotplug
operation will block till the global refcount goes to zero.
The readers, if any, during an ongoing cpu-hotplug operation are blocked
until the cpu-hotplug operation is over.
Signed-off-by: Gautham R Shenoy <[EMAIL PROTECTED]>
Signed-off-by: Paul Jackson <[EMAIL PROTECTED]> [For !CONFIG_HOTPLUG_CPU ]
---
include/linux/cpu.h |3 +
init/main.c |1
kernel/cpu.c| 152 +---
3 files changed, 115 insertions(+), 41 deletions(-)
Index: linux-2.6.23/init/main.c
===
--- linux-2.6.23.orig/init/main.c
+++ linux-2.6.23/init/main.c
@@ -614,6 +614,7 @@ asmlinkage void __init start_kernel(void
vfs_caches_init_early();
cpuset_init_early();
mem_init();
+ cpu_hotplug_init();
kmem_cache_init();
setup_per_cpu_pageset();
numa_policy_init();
Index: linux-2.6.23/include/linux/cpu.h
===
--- linux-2.6.23.orig/include/linux/cpu.h
+++ linux-2.6.23/include/linux/cpu.h
@@ -83,6 +83,9 @@ static inline void unregister_cpu_notifi
#endif /* CONFIG_SMP */
extern struct sysdev_class cpu_sysdev_class;
+extern void cpu_hotplug_init(void);
+extern void cpu_maps_update_begin(void);
+extern void cpu_maps_update_done(void);
#ifdef CONFIG_HOTPLUG_CPU
/* Stop CPUs going up and down. */
Index: linux-2.6.23/kernel/cpu.c
===
--- linux-2.6.23.orig/kernel/cpu.c
+++ linux-2.6.23/kernel/cpu.c
@@ -15,9 +15,8 @@
#include
#include
-/* This protects CPUs going up and down... */
+/* Serializes the updates to cpu_online_map, cpu_present_map */
static DEFINE_MUTEX(cpu_add_remove_lock);
-static DEFINE_MUTEX(cpu_bitmask_lock);
static __cpuinitdata RAW_NOTIFIER_HEAD(cpu_chain);
@@ -26,52 +25,123 @@ static __cpuinitdata RAW_NOTIFIER_HEAD(c
*/
static int cpu_hotplug_disabled;
-#ifdef CONFIG_HOTPLUG_CPU
+static struct {
+ struct task_struct *active_writer;
+ struct mutex lock; /* Synchronizes accesses to refcount, */
+ /*
+* Also blocks the new readers during
+* an ongoing cpu hotplug operation.
+*/
+ int refcount;
+ wait_queue_head_t writer_queue;
+} cpu_hotplug;
+
+#define writer_exists() (cpu_hotplug.active_writer != NULL)
+
+void __init cpu_hotplug_init(void)
+{
+ cpu_hotplug.active_writer = NULL;
+ mutex_init(&cpu_hotplug.lock);
+ cpu_hotplug.refcount = 0;
+ init_waitqueue_head(&cpu_hotplug.writer_queue);
+}
-/* Crappy recursive lock-takers in cpufreq! Complain loudly about idiots */
-static struct task_struct *recursive;
-static int recursive_depth;
+#ifdef CONFIG_HOTPLUG_CPU
void lock_cpu_hotplug(void)
{
- struct task_struct *tsk = current;
-
- if (tsk == recursive) {
- static int warnings = 10;
- if (warnings) {
- printk(KERN_ERR "Lukewarm IQ detected in hotplug
locking\n");
- WARN_ON(1);
- warnings--;
- }
- recursive_depth++;
+ might_sleep();
+ if (cpu_hotplug.active_writer == current)
return;
- }
- mutex_lock(&cpu_bitmask_lock);
- recursive = tsk;
+ mutex_lock(&cpu_hotplug.lock);
+ cpu_hotplug.refcount++;
+ mutex_unlock(&cpu_hotplug.lock);
+
}
EXPORT_SYMBOL_GPL(lock_cpu_hotplug);
void unlock_cpu_hotplug(void)
{
- WARN_ON(recursive != current);
- if (recursive_depth) {
- recursive_depth--;
+ if (cpu_hotplug.active_writer == current)
return;
- }
- recursive = NULL;
- mutex_unlock(&cpu_bitmask_lock);
+ mutex_lock(&cpu_hotplug.lock);
+ cpu_hotplug.refcount--;
+
+ if (unlikely(writer_exists()) && !cpu_hotplug.refcount)
+ wake_up(&cpu_hotplug.writer_queue);
+
+ mutex_unlock(&cpu_hotplug.lock);
+
}
EXPORT_SYMBOL_GPL(unlock_cpu_hotplug);
#endif /* CONFIG_HOTPLUG_CPU */
+/*
+ * The following two API's must be used when attempting
+ * to serialize the updates to cpu_online_map, cpu_present_map.
+ */
+void cpu_maps_update_begin(void)
+{
+ mutex_lock(&cpu_add_remove_lock);
+}
+
+void cpu_maps_update_done(void)
+{
+ mutex_unlock(&cpu_add_remove_lock);
+}
+
+/*
+ * This ensures that the hotplug operation can begin only when the
+ * refcount goes to zero.
+ *
+ * Note that during a cpu-hotplug operation, the new readers, if any,
+ * will be blocked by the cpu_hotplug.lock
+ *
+ * Since cpu_maps_update_begin is always called after invoking
+ * cpu_maps_update_begin, we can be sure that only one writer is active.
+ *
+ * Note
Re: [PATCH 3/4]: [PCI]: Add quirk for devices which disable MSI when INTX_DISABLE is set.
On Tue, 2007-10-23 at 19:53 -0700, David Miller wrote:
> A reasonably common problem with some devices is that they will
> disable MSI generation when the INTX_DISABLE bit is set in the
> PCI_COMMAND register.
>
> Quirk this explicitly, guarding the pci_intx() calls in msi.c with
> this quirk indication.
>
> The first entries for this quirk are for 5714 and 5780 Tigon3 chips,
> and thus we can remove the workaround code from the tg3.c driver.
>
> Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 87e0161..a8dd18c 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -237,7 +237,8 @@ static void __pci_restore_msi_state(struct pci_dev *dev)
> entry = get_irq_msi(dev->irq);
> pos = entry->msi_attrib.pos;
>
> - pci_intx(dev, 0); /* disable intx */
> + if (!(dev->dev_flags & PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG))
> + pci_intx(dev, 0); /* disable intx */
> msi_set_enable(dev, 0);
> write_msi_msg(dev->irq, &entry->msg);
> if (entry->msi_attrib.maskbit)
> @@ -260,7 +261,8 @@ static void __pci_restore_msix_state(struct pci_dev *dev)
> return;
>
> /* route the table */
> - pci_intx(dev, 0); /* disable intx */
> + if (!(dev->dev_flags & PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG))
> + pci_intx(dev, 0); /* disable intx */
> msix_set_enable(dev, 0);
>
> list_for_each_entry(entry, &dev->msi_list, list) {
> @@ -343,7 +345,8 @@ static int msi_capability_init(struct pci_dev *dev)
> }
>
> /* Set MSI enabled bits */
> - pci_intx(dev, 0); /* disable intx */
> + if (!(dev->dev_flags & PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG))
> + pci_intx(dev, 0); /* disable intx */
> msi_set_enable(dev, 1);
> dev->msi_enabled = 1;
>
> @@ -433,7 +436,8 @@ static int msix_capability_init(struct pci_dev *dev,
> i++;
> }
> /* Set MSI-X enabled bits */
> - pci_intx(dev, 0); /* disable intx */
> + if (!(dev->dev_flags & PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG))
> + pci_intx(dev, 0); /* disable intx */
> msix_set_enable(dev, 1);
> dev->msix_enabled = 1;
>
> @@ -528,7 +532,8 @@ void pci_disable_msi(struct pci_dev* dev)
> return;
>
> msi_set_enable(dev, 0);
> - pci_intx(dev, 1); /* enable intx */
> + if (!(dev->dev_flags & PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG))
> + pci_intx(dev, 1); /* enable intx */
> dev->msi_enabled = 0;
>
> BUG_ON(list_empty(&dev->msi_list));
> @@ -640,7 +645,8 @@ void pci_disable_msix(struct pci_dev* dev)
> return;
>
> msix_set_enable(dev, 0);
> - pci_intx(dev, 1); /* enable intx */
> + if (!(dev->dev_flags & PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG))
> + pci_intx(dev, 1); /* enable intx */
> dev->msix_enabled = 0;
>
> msix_free_all_irqs(dev);
That looks like 6 hunks doing exactly the same thing? What about
creating a pci_intx_quirked() (or something) that checks the flag and
then does/or does not call pci_intx().
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
[PATCH] sg: add missing sg_init_table calls to zfcp
From: Heiko Carstens <[EMAIL PROTECTED]> CONFIG_DEBUG_SG reveals two missing sg_init_table calls. Add them. kernel BUG at include/linux/scatterlist.h:50! illegal operation: 0001 [#1] [...] Call Trace: ([<0026f184>] zfcp_ns_gid_pn_request+0x4c/0x2a0) [<00276dd4>] zfcp_erp_strategy_do_action+0x1410/0x1938 [<00278412>] zfcp_erp_thread+0x4fa/0x1430 [<0001990a>] kernel_thread_starter+0x6/0xc [<00019904>] kernel_thread_starter+0x0/0xc Cc: Swen Schillig <[EMAIL PROTECTED]> Cc: Christof Schmitt <[EMAIL PROTECTED]> Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]> --- Jens, could you please push this one via your tree? Thanks! drivers/s390/scsi/zfcp_aux.c |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6/drivers/s390/scsi/zfcp_aux.c === --- linux-2.6.orig/drivers/s390/scsi/zfcp_aux.c +++ linux-2.6/drivers/s390/scsi/zfcp_aux.c @@ -1518,6 +1518,8 @@ zfcp_gid_pn_buffers_alloc(struct zfcp_gi return -ENOMEM; memset(data, 0, sizeof(*data)); + sg_init_table(&data->req , 1); + sg_init_table(&data->resp , 1); data->ct.req = &data->req; data->ct.resp = &data->resp; data->ct.req_count = data->ct.resp_count = 1; - 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 PATCH 0/5] Refcount based Cpu Hotplug. V2
Hello everyone, This is the version 2 of the refcount based cpu-hotplug "locking" implementation. It incorporates the review comments from the first posting which can be found here --> http://lkml.org/lkml/2007/10/16/118. Changes since v1: - !CONFIG_HOTPLUG_CPU part is now handled correctly, thanks to the patch from Paul Jackson. - The cpu_hotplug_begin() uses a waitqueue instead of a completion struct where a writer can wait while there are active readers in the system. - Provided a new API's cpu_maps_update_begin(), cpu_maps_update_done() for serializing the updates to cpu_present_map and cpu_online_map. Thus threads which update the cpu_present_map should now call cpu_maps_update_begin instead of lock_cpu_hotplug(), since they play the role of writers. - pseries_processor_add() , pseries_processor_remove() now use cpu_maps_update_begin()/cpu_maps_update_done() in place of lock_cpu_hotplug()/unlock_cpu_hotplug(). - Replaced the workqueue_mutex with workqueue_lock, which is a spinlock and guards the workqueues list. - Updated Documentation/cpu-hotplug.txt to reflect get_online_cpus(), put_online_cpus() in place of the old lock_cpu_hotplug(), unlock_cpu_hotplug(). I'm Cc'ing the different subsystem maintainers who might be affected by the changes in the patchstack. Especially if they rely on lock_cpu_hotplug() to provide them protection for their local data structures as well. The patchstack which is based against 2.6.23-mm1 has behaved well when it was stress tested with kernbench running while continuously performing cpu-hotplug operations on i386, x86_64 and ppc64. Awaiting your feedback. Thanks and Regards gautham. -- Gautham R Shenoy Linux Technology Center IBM India. "Freedom comes with a price tag of responsibility, which is still a bargain, because Freedom is priceless!" - 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] mpc5200: psc-spi driver must not touch port_config or cdm registers
On 10/23/07, Domen Puncer <[EMAIL PROTECTED]> wrote: > On 23/10/07 21:39 -0600, Grant Likely wrote: > > From: Grant Likely <[EMAIL PROTECTED]> > > > > port_config and the cdm are the responsibility of firmware; and if > > firmware doesn't set it up correctly, it should be fixed up by > > platform code on a per-board basis because it's a property of the > > board. > > > > Drivers should never touch these registers. They are completely > > unprotected and the platform may do odd things with them that the > > driver must not interfere with. > > > > Signed-off-by: Grant Likely <[EMAIL PROTECTED]> > > --- > > > > Domen, Dragos; can you please check your usage of this driver. None of > > the in-tree board ports use it as-is, but they are of course just a > > device tree change away from being usable on the lite5200b. > > My test cases were just a jumper on RX-TX line. > > It's not even allowed to set mclken_div_pscX? > There can be different speed devices on same SPI > (spi_board_info->max_speed_hz). Nope; do it in the platform code or a cdm driver. Otherwise there is no protection against collisions on the cdm registers. The driver could call a platform hook to fiddle with clocking, but it must not touch it directly. (BTW, I don't intended to push this version of the patch; I just want to get everyone's brain juices flowing to figure out the best way to solve it.) Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 - 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] Add eeprom_bad_csum_allow module option to e1000.
Hello Auke, Kernel crew, > I realize that you need the patch to actually create it but the > danger is that people will start using it *without* troubleshooting the real > issue. Just write out a big fat kernel output with explanations of the override parameter, possible repercusionss of not fixing it and an email address to which you (or, better yet - Intel) want stuff "this and that" reported. I hadn't the slightest idea from the kernel messages or the skim of the driver source that anyone is wanting feedback on this issue... ps. Were there recently (2.6.22+) any known issues about e1000 refusing to send packets out / getting stuck upon jumbo-frames being enabled? ps2. I'm not following this list, sorry about the poor thread CC: quality -- Best regards, speedy mailto:[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] mpc5200: psc-spi driver must not touch port_config or cdm registers
On 23/10/07 21:39 -0600, Grant Likely wrote:
> From: Grant Likely <[EMAIL PROTECTED]>
>
> port_config and the cdm are the responsibility of firmware; and if
> firmware doesn't set it up correctly, it should be fixed up by
> platform code on a per-board basis because it's a property of the
> board.
>
> Drivers should never touch these registers. They are completely
> unprotected and the platform may do odd things with them that the
> driver must not interfere with.
>
> Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
> ---
>
> Domen, Dragos; can you please check your usage of this driver. None of
> the in-tree board ports use it as-is, but they are of course just a
> device tree change away from being usable on the lite5200b.
My test cases were just a jumper on RX-TX line.
It's not even allowed to set mclken_div_pscX?
There can be different speed devices on same SPI
(spi_board_info->max_speed_hz).
>
> Board ports that use it need to be modified to make the cdm/port_config
> changes in firmware (prefered) or in arch/powerpc/platforms/52xx/.c
>
> Cheers,
> g.
>
> drivers/spi/mpc52xx_psc_spi.c | 77
> +
> 1 files changed, 2 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
> index 7051e6c..ec3a618 100644
> --- a/drivers/spi/mpc52xx_psc_spi.c
> +++ b/drivers/spi/mpc52xx_psc_spi.c
> @@ -328,78 +328,15 @@ static void mpc52xx_psc_spi_cleanup(struct spi_device
> *spi)
> kfree(spi->controller_state);
> }
>
> -static int mpc52xx_psc_spi_port_config(int psc_id, struct mpc52xx_psc_spi
> *mps)
> +static void mpc52xx_psc_spi_config(int psc_id, struct mpc52xx_psc_spi *mps)
> {
> - struct mpc52xx_cdm __iomem *cdm;
> - struct mpc52xx_gpio __iomem *gpio;
> struct mpc52xx_psc __iomem *psc = mps->psc;
> - u32 ul;
> u32 mclken_div;
> - int ret = 0;
> -
> -#if defined(CONFIG_PPC_MERGE)
> - cdm = mpc52xx_find_and_map("mpc5200-cdm");
> - gpio = mpc52xx_find_and_map("mpc5200-gpio");
> -#else
> - cdm = ioremap(MPC52xx_PA(MPC52xx_CDM_OFFSET), MPC52xx_CDM_SIZE);
> - gpio = ioremap(MPC52xx_PA(MPC52xx_GPIO_OFFSET), MPC52xx_GPIO_SIZE);
> -#endif
> - if (!cdm || !gpio) {
> - printk(KERN_ERR "Error mapping CDM/GPIO\n");
> - ret = -EFAULT;
> - goto unmap_regs;
> - }
>
> /* default sysclk is 512MHz */
> mclken_div = 0x8000 |
> (((mps->sysclk ? mps->sysclk : 51200) / MCLK) & 0x1FF);
It's actually 528e6, and mclken_div doesn't seem to be used anywhere anymore.
>
> - switch (psc_id) {
> - case 1:
...
Domen
-
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 v2.6.24-rc1
Hi, build failed on my pc: arch/x86/kernel/built-in.o(.text+0x1b192): In function `smp_send_nmi_allbutself': : undefined reference to `genapic' Regards dave - 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: LSM conversion to static interface [revert patch]
On Tue, 23 Oct 2007 17:31:28 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > Chris Wright wrote: > > Yes, and I think we can still improve performance although I can't > > see anyway to help out the modular case, so I guess it will have to > > incur the hit that's always been there. > > Broaden the paravirt patching machinery? > so far I've something much simpler in mind, I have a first prototype and it shows code that is pretty much optimal on modern cpus. I hope to have something postable in a week or so - 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] Allow lazy unmapping by taking extra page references V2
David Chinner wrote: > Allow lazy unmapping of vmap()d regions be taking a reference > on each page in the region being vmap()ed. The page references > get released after the region is vunmap()ed, thereby ensuring > we don't leave stray mappings on freed pages that could lead to > problems pages being reallocated with incorrect mappings > associated with them. > > Tested with XFS filesystems with 64k directory blocks with > dirstress and XFSQA. > > Version 2: > - drop the release function stuff and just call put_page() > as it falls down to the same code in all calling cases. > This doesn't apply cleanly to the current git tree. J - 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] bitops kernel-doc: expand macro
From: Randy Dunlap <[EMAIL PROTECTED]> Can we expand this macro definition, or should I look for a way to fool^W teach kernel-doc about this? scripts/kernel-doc says: Error(linux-2.6.24-rc1//include/asm-x86/bitops_32.h:188): cannot understand prototype: 'test_and_set_bit_lock test_and_set_bit ' Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- include/asm-x86/bitops_32.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.24-rc1.orig/include/asm-x86/bitops_32.h +++ linux-2.6.24-rc1/include/asm-x86/bitops_32.h @@ -185,7 +185,7 @@ static inline int test_and_set_bit(int n * * This is the same as test_and_set_bit on x86 */ -#define test_and_set_bit_lock test_and_set_bit +#define test_and_set_bit_lock(nr, addr) test_and_set_bit(nr, addr) /** * __test_and_set_bit - Set a bit and return its old value --- ~Randy - 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 3/4]: [PCI]: Add quirk for devices which disable MSI when INTX_DISABLE is set.
From: "Michael Chan" <[EMAIL PROTECTED]> Date: Tue, 23 Oct 2007 21:59:39 -0700 > David Miller wrote: > > > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM, > > + PCI_DEVICE_ID_TIGON3_5780, > > + quirk_msi_intx_disable_bug); > > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM, > > + PCI_DEVICE_ID_TIGON3_5780S, > > + quirk_msi_intx_disable_bug); > > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM, > > + PCI_DEVICE_ID_TIGON3_5714, > > + quirk_msi_intx_disable_bug); > > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM, > > + PCI_DEVICE_ID_TIGON3_5714S, > > + quirk_msi_intx_disable_bug); > > + > > Please add PCI_DEVICE_ID_TIGON3_5715 and > PCI_DEVICE_ID_TIGON3_5715S as well. I will. > Other than that, > Acked-by: Michael Chan <[EMAIL PROTECTED]> Thanks for reviewing. - 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] 2.6.23-git19 - S390x: Kernel panic while bringing up the network interface
On Wed, Oct 24, 2007 at 08:59:06AM +0530, Kamalesh Babulal wrote: > Hi, > > Kernel panic's while bringing up the network interface with the 2.6.23-git19 > > Setting network parameters: Ý OK ¨ > Bringing up loopback interface: Ý OK ¨ > Bringing up interface eth0: > Ý<002e2f72>¨ inet_ioctl+0xd6/0x110 > Ý<0027cae2>¨ sock_ioctl+0x26e/0x2a0 > Ý<000b4c52>¨ do_ioctl+0x4a/0xac > Ý<000b5076>¨ vfs_ioctl+0x3c2/0x3d8 > Ý<000b50ec>¨ sys_ioctl+0x60/0x88 > Ý<00021b7e>¨ sysc_noemu+0x10/0x16 > Ý<021201ca>¨ 0x21201ca > > <0>Kernel panic - not syncing: Fatal exception in interrupt > 00: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop > from > CPU 01. > 02: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop > from > CPU 01. > 03: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop > from > CPU 01. > 01: HCPGIR450W CP entered; disabled wait PSW 00020001 8000 > 000164DE That should be fixed with this one: commit f1ecfd5d3b69d98b814435758c485e6fd0e112de Author: Ursula Braun <[EMAIL PROTECTED]> Date: Mon Oct 22 16:16:14 2007 +0200 remove header_ops bug in qeth driver Remove qeth bug caused by commit: [NET]: Move hardware header operations out of netdevice. This is the second part of the qeth header_ops patch, since first patch sent 10/19 has been insufficient. Nevertheless first patch is still valid and should be kept. Signed-off-by: Ursula Braun <[EMAIL PROTECTED]> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> Patch is in -rc1. Could you please pull and try again? 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 0/4]: Resolve MSI vs. INTX_DISABLE quirks.
From: Daniel Barkalow <[EMAIL PROTECTED]> Date: Wed, 24 Oct 2007 00:58:45 -0400 (EDT) > I'm not sure all of the pci_intx() calls in msi.c should be skipped when > the quirk applies; I think some of them might be there so that the legacy > interrupt won't be delivered while MSI is turned off (since the handler > isn't listening for the legacy interrupts). I'd guess this would cause > people to have their MSI-capable device kill their non-MSI-capable device > when they restore their laptop (and the shared interrupt fires and gets > stuck at just the wrong time). No idea if this is a real concern, but I'm > pretty sure that not all of those calls are recent. I don't think it's a real concern. > There's a couple of ATA drivers that look like they might be trying to > work around the same bug, but it's a bit hard to tell. It might be good to > have them use the quirk (or set the flag) because it's cleaner. I noticed these cases as well, and I would hope that Jeff would help out here using the infrastructure my patches created. - 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: LTP ustat01 test fails on NFSROOT
On Oct 23, 2007, at 8:21 PM, Trond Myklebust wrote:
On Tue, 2007-10-23 at 17:52 -0500, Kumar Gala wrote:
I'm looking into an issue with LTP's ustat01 & ustat02 tests in which
they report the following:
ustat01 1 FAIL : ustat(2) failed and setthe errno to 116 :
Stale NFS file handle
ustat02 2 FAIL : ustat(2) failed to produce expected error;
14, errno: EFAULT and got 116
It appears sometime between 2.6.21 and 2.6.22-rc1 some changes to NFS
got introduced that cause this.
was wondering about any ideas while I try to debug what's going on.
thanks
- k
I'm seeing zero problems with the latest checkouts from Linus' git
tree.
Mind giving us some more details?
I tried 2.6.24-rc1 w/the same result.
The system is a 32-bit PPC embedded board that we mounting the rootfs
over nfs on.
The defconfig is arch/powerpc/configs/mpc8641_hpcn_defconfig
'strace' output would be useful, as would the standard NFS list of
client mount options, server export options, details on how your
exported partition is set up on the server, etc...
strace:
stat64("/", {st_dev=makedev(0, 14), st_ino=58821800, st_mode=S_IFDIR|
0775, st_nlink=18, st_uid=500, st_gid=500, st_blksize=4096,
st_blocks=8, st_size=4096, st_atime=2007/10/23-22:43:30,
st_mtime=2007/10/18-19:51:19, st_ctime=2007/10/18-19:51:19}) = 0
ustat(0xe, 0x1001a008) = -1 ESTALE (Stale NFS file
handle)
fstat64(1, {st_dev=makedev(0, 14), st_ino=58821964, st_mode=S_IFCHR|
0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0,
st_rdev=makedev(4, 64), st_atime=2007/10/16-18:32:59,
st_mtime=2007/10/16-18:32:59, st_ctime=2007/10/24-05:03:34}) = 0
Info on the server:
[EMAIL PROTECTED] ~]# exportfs -v
/ (rw,async,wdelay,no_root_squash,no_subtree_check)
[EMAIL PROTECTED] ~]# uname -a
Linux ducky.am.freescale.net 2.6.22.5-76.fc7 #1 SMP Thu Aug 30
13:04:34 EDT 2007 ppc64 ppc64 ppc64 GNU/Linux
On the host system:
(not sure how to get client mount options, mount reports:
%root% on / type unknown (rw)
-sh-2.05b# cat /proc/cmdline
root=/dev/nfs rw nfsroot=192.168.1.15:/home/galak/ltib-joust-8572/
rootfs
ip=192.168.1.147:192.168.1.15:192.168.1.1:255.255.254.0:rocky:eth0:off c
onsole=ttyS0,115200
If there is some other info that would be useful please let me know.
-
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 3/4]: [PCI]: Add quirk for devices which disable MSI when INTX_DISABLE is set.
David Miller wrote: > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM, > + PCI_DEVICE_ID_TIGON3_5780, > + quirk_msi_intx_disable_bug); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM, > + PCI_DEVICE_ID_TIGON3_5780S, > + quirk_msi_intx_disable_bug); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM, > + PCI_DEVICE_ID_TIGON3_5714, > + quirk_msi_intx_disable_bug); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM, > + PCI_DEVICE_ID_TIGON3_5714S, > + quirk_msi_intx_disable_bug); > + Please add PCI_DEVICE_ID_TIGON3_5715 and PCI_DEVICE_ID_TIGON3_5715S as well. Other than that, Acked-by: Michael Chan <[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 0/4]: Resolve MSI vs. INTX_DISABLE quirks.
On Tue, 23 Oct 2007, David Miller wrote: > > The forthcoming patches are also available from: > > kernel.org:/pub/scm/linux/kernel/git/davem/msiquirk-2.6.git > > and clean up the handling of the common quirk wherein setting > INTX_DISABLE will mistakedly disable MSI generation for some > devices. > > For devices without that problem, we want to keep the pci_intx() calls > in drivers/pci/msi.c because those help protect against devices > with the opposite problem. Such devices always generate INTX > interrupts even when MSI is enabled, unless INTX_DISABLE is set. > > Michael, please pay special attention to patch #3. I think I > picked the correct PCI device IDs to match for the quirk > (5714* and 5780*) but it's possible we might need more elaborate > checks here. It at least worked properly for the chips in my > Niagara system. I'm not sure all of the pci_intx() calls in msi.c should be skipped when the quirk applies; I think some of them might be there so that the legacy interrupt won't be delivered while MSI is turned off (since the handler isn't listening for the legacy interrupts). I'd guess this would cause people to have their MSI-capable device kill their non-MSI-capable device when they restore their laptop (and the shared interrupt fires and gets stuck at just the wrong time). No idea if this is a real concern, but I'm pretty sure that not all of those calls are recent. > In addition to the Tigon3 cases, I added quirk entries for the > SB700/800 SATA chips and the IXP SB400 USB controllers. There's a couple of ATA drivers that look like they might be trying to work around the same bug, but it's a bit hard to tell. It might be good to have them use the quirk (or set the flag) because it's cleaner. -Daniel *This .sig left intentionally blank* - 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 v2.6.24-rc1
On Tue, Oct 23, 2007 at 09:19:16PM -0700, Linus Torvalds wrote: > Just for fun, I'd really encourage git users to just try the > > git shortlog v2.6.23.. > > thing, it really is quite impressive. Impressive, indeed! At least it's a great testimonial for GIT and the workflow it permits, but from a user's perspective, so many changes at once may look frightening! Regards, Willy - 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] Allow lazy unmapping by taking extra page references V2
Allow lazy unmapping of vmap()d regions be taking a reference
on each page in the region being vmap()ed. The page references
get released after the region is vunmap()ed, thereby ensuring
we don't leave stray mappings on freed pages that could lead to
problems pages being reallocated with incorrect mappings
associated with them.
Tested with XFS filesystems with 64k directory blocks with
dirstress and XFSQA.
Version 2:
- drop the release function stuff and just call put_page()
as it falls down to the same code in all calling cases.
Signed-Off-By: Dave Chinner <[EMAIL PROTECTED]>
---
fs/xfs/linux-2.6/xfs_buf.c | 21 +---
include/linux/vmalloc.h|4 +
mm/vmalloc.c | 118 +
3 files changed, 106 insertions(+), 37 deletions(-)
Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_buf.c
===
--- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_buf.c 2007-10-18
17:11:06.0 +1000
+++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_buf.c2007-10-24 09:16:26.930345566
+1000
@@ -187,19 +187,6 @@ free_address(
{
a_list_t*aentry;
-#ifdef CONFIG_XEN
- /*
-* Xen needs to be able to make sure it can get an exclusive
-* RO mapping of pages it wants to turn into a pagetable. If
-* a newly allocated page is also still being vmap()ed by xfs,
-* it will cause pagetable construction to fail. This is a
-* quick workaround to always eagerly unmap pages so that Xen
-* is happy.
-*/
- vunmap(addr);
- return;
-#endif
-
aentry = kmalloc(sizeof(a_list_t), GFP_NOWAIT);
if (likely(aentry)) {
spin_lock(&as_lock);
@@ -209,7 +196,7 @@ free_address(
as_list_len++;
spin_unlock(&as_lock);
} else {
- vunmap(addr);
+ vunmap_pages(addr);
}
}
@@ -228,7 +215,7 @@ purge_addresses(void)
spin_unlock(&as_lock);
while ((old = aentry) != NULL) {
- vunmap(aentry->vm_addr);
+ vunmap_pages(aentry->vm_addr);
aentry = aentry->next;
kfree(old);
}
@@ -456,8 +443,8 @@ _xfs_buf_map_pages(
} else if (flags & XBF_MAPPED) {
if (as_list_len > 64)
purge_addresses();
- bp->b_addr = vmap(bp->b_pages, bp->b_page_count,
- VM_MAP, PAGE_KERNEL);
+ bp->b_addr = vmap_pages(bp->b_pages, bp->b_page_count,
+ VM_MAP, PAGE_KERNEL, xb_to_gfp(flags));
if (unlikely(bp->b_addr == NULL))
return -ENOMEM;
bp->b_addr += bp->b_offset;
Index: 2.6.x-xfs-new/include/linux/vmalloc.h
===
--- 2.6.x-xfs-new.orig/include/linux/vmalloc.h 2007-09-12 15:41:41.0
+1000
+++ 2.6.x-xfs-new/include/linux/vmalloc.h 2007-10-24 09:16:55.194741855
+1000
@@ -51,6 +51,10 @@ extern void *vmap(struct page **pages, u
unsigned long flags, pgprot_t prot);
extern void vunmap(void *addr);
+extern void *vmap_pages(struct page **pages, unsigned int count,
+ unsigned long flags, pgprot_t prot, gfp_t gfp_mask);
+extern void vunmap_pages(void *addr);
+
extern int remap_vmalloc_range(struct vm_area_struct *vma, void *addr,
unsigned long pgoff);
void vmalloc_sync_all(void);
Index: 2.6.x-xfs-new/mm/vmalloc.c
===
--- 2.6.x-xfs-new.orig/mm/vmalloc.c 2007-09-12 15:41:48.0 +1000
+++ 2.6.x-xfs-new/mm/vmalloc.c 2007-10-24 09:30:53.447102103 +1000
@@ -318,6 +318,34 @@ struct vm_struct *remove_vm_area(void *a
return v;
}
+static int vm_area_alloc_pagearray(struct vm_struct *area, gfp_t gfp_mask,
+ unsigned int nr_pages, int node)
+{
+ struct page **pages;
+ unsigned int array_size;
+
+ array_size = (nr_pages * sizeof(struct page *));
+
+ area->nr_pages = nr_pages;
+ /* Please note that the recursion is strictly bounded. */
+ if (array_size > PAGE_SIZE) {
+ pages = __vmalloc_node(array_size, gfp_mask | __GFP_ZERO,
+ PAGE_KERNEL, node);
+ area->flags |= VM_VPAGES;
+ } else {
+ pages = kmalloc_node(array_size,
+ (gfp_mask & GFP_LEVEL_MASK) | __GFP_ZERO,
+ node);
+ }
+ area->pages = pages;
+ if (!area->pages) {
+ remove_vm_area(area->addr);
+ kfree(area);
+ return -ENOMEM;
+ }
+ return 0;
+}
+
static void __vunmap(void *addr, int deallocate_pages)
{
struct vm_s
Re: [PATCH 1/2] CFS CGroup: Code cleanup
On Tue, Oct 23, 2007 at 07:32:27PM -0700, Paul Menage wrote: > Clean up some CFS CGroup code > > - replace "cont" with "cgrp" in a few places in the CFS cgroup code, > - use write_uint rather than write for cpu.shares write function > > Signed-off-by: Paul Menage <[EMAIL PROTECTED]> Acked-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]> -- Regards, vatsa - 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/
[patchlet] Re: [Git pull] x86 updates
On Tue, 2007-10-23 at 23:02 +0200, Thomas Gleixner wrote:
> Linus,
>
> please pull from:
>
> ssh://master.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
>
> This contains a couple of bug fixes and a large cleanup and
> unification section from various authors.
X86_32 build fix to commit 62a31a03b3d2a9d20e7a073e2cd9b27bfb7d6a3f
Signed-off-by: Mike Galbraith <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index af0253f..8bb482f 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -25,7 +25,7 @@
#include
#include
-#ifdef X86_32
+#ifdef CONFIG_X86_32
#include
#else
#include
@@ -41,7 +41,7 @@ static int crash_nmi_callback(struct notifier_block *self,
unsigned long val, void *data)
{
struct pt_regs *regs;
-#ifdef X86_32
+#ifdef CONFIG_X86_32
struct pt_regs fixed_regs;
#endif
int cpu;
@@ -60,7 +60,7 @@ static int crash_nmi_callback(struct notifier_block *self,
return NOTIFY_STOP;
local_irq_disable();
-#ifdef X86_32
+#ifdef CONFIG_X86_32
if (!user_mode_vm(regs)) {
crash_fixup_ss_esp(&fixed_regs, regs);
regs = &fixed_regs;
-
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 2/2] CFS CGroup: Report usage
On Tue, Oct 23, 2007 at 07:28:22PM -0700, Paul Menage wrote: > > Good point. I think we need to subtract out the time it was waiting on > > runqueue > > when calculating idle time. > > > > |--- . . . . . . -...---| > > t0 t1t2 t3 t4 t5 t6 > > > > > > -> Running time > > -> Waiting time (to get on the cpu) > > -> Sleeping time (when it didnt want to run because of > >lack of tasks) > > > > So, in this case, > > > > idle time = (t4 - t3) / [ (t6 - t1) - (t2-t1) - (t5-t4) > > > > Do you mean (t6 - t0) where you have (t6 - t1)? Ah ..yes. > > ? > > > > This idle time will be a per-cpu stat for every cgroup and needs to be > > consolidated across cpus into a single idle-stat number, just like how > > top does it. > > This would be an idle fraction, not an idle time. (seconds divided by seconds) agreed, we need to be reporting idle time in (milli)seconds, although the requirement we had was to report it back in percentage. I guess the percentage figure can be derived from the raw idle time number. How about: idle time = t4-t3 (effectively sleep time) in the above example? > It doesn't seem quite right to me that a cgroup's idle time metric be > affected by the activity of other cgroups on the machine, I don't see how the idle time metric defined above (t4-t3) can be affected by other cgroup activity, unless the execution pattern of one cgroup is dependent on the others. However the minute you tranlsate this idle time into a percentage wrt wall-clock time, then yes a cgroup's idle percentage can be affected by others. For idle percentage to be meaningfull, I would imagine that user-space tools will need to calculate it after discarding a group's wait time. > but it's > hard to come up with a way of measuring it that doesn't have this > behaviour - which is why, in the absence of hard CPU partitioning, > it's not clear to me how much use this would be. > > What would people be planning to use it for? I think primarily for systems management tools to report back various statistics about a OpenVZ/VServer-like container (just like top reports stats for a OS currently). Let me check if there are other uses envisoned for it. -- Regards, vatsa - 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/
Linux v2.6.24-rc1
This may count as one of the biggest -rc releases ever. It's humongous. Usually the compressed -rc1 diffs are in the 3-5MB range, with occasional smaller ones, and the occasional ones that top 6M, but this one is *eleven* megs. I'd blame the x86 renames (and the watchdog ones), but the thing is, it's absolutely huge even when I generate the diff with git turning all those renames into relatively small rename diffs (which I don't do for the public diffs, since I expect that git people use git to get the changes, and non-git people won't have tools that understand a diff that involves renames). In short, we just had an unusually large amount of not just x86 merges, but also tons of new drivers (wireless networking stands out, but is by no means the only thing - we've got dvb, regular wired network, mmc etc all joining in), and a fair amount or architecture stuff, filesystems, networking etc too. So there's just lots of new stuff. The diffstat is ten thousand lines long, and weighing in at comfortably over half a megabyte it is way over the limits of this - or any sane - mailing list. The shortlog is barely shorter, weighing in at "just" 8461 lines and almost 400k. The full changelog (which I'm still producing for y'all, since people told me they actually care last time I asked) is 4 megs. In other words, I don't even know where to start. The big noticeable thing is the x86 merge, and I think we all fervently hope that it won't cause any issues. So far it's been pretty smooth sailing. Knock wood. Less smooth has the scatter-gather changes to the block layer been, but they are hopefully all in reasonable shape by now too. And the VM changes? I honestly hope nobody even notices. Same goes for some of the VFS layer changes that affected basically every filesystem (although in mostly very straightforward ways). Just for fun, I'd really encourage git users to just try the git shortlog v2.6.23.. thing, it really is quite impressive. Linus - 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: New version of Elantech touchpad driver for kernel 2.6.23.1
On Tuesday 23 October 2007, Arjan Opmeer wrote:
> @@ -88,6 +88,7 @@ enum psmouse_type {
> PSMOUSE_LIFEBOOK,
> PSMOUSE_TRACKPOINT,
> PSMOUSE_TOUCHKIT_PS2,
> + PSMOUSE_ELANTECH,
> PSMOUSE_CORTRON,
> PSMOUSE_AUTO/* This one should always be last */
> };
Do not move protocol constants around as they are exported to
userspace. New protocols should go to the end of the list
(right in front of PSMOUSE_AUTO).
Thanks.
--
Dmitry
-
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 5/5] NET: Remove unneeded implicit type case when calling tcp_minshall_update()
From: Chuck Lever <[EMAIL PROTECTED]> Date: Tue, 23 Oct 2007 11:44:33 -0400 > The tcp_minshall_update() function is called in exactly one place, and is > passed an unsigned integer for the mss_len argument. Make the sign of the > argument match the sign of the passed variable in order to eliminate an > unneeded implicit type cast and a mixed sign comparison in > tcp_minshall_update(). > > Signed-off-by: Chuck Lever <[EMAIL PROTECTED]> Applied, thanks. > Cc: <[EMAIL PROTECTED]> Actually, you only CC:'d linux-kernel on these 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 3/5] NET: Treat the sign of the result of skb_headroom() consistently
From: Chuck Lever <[EMAIL PROTECTED]> Date: Tue, 23 Oct 2007 11:44:23 -0400 > In some places, the result of skb_headroom() is compared to an unsigned > integer, and in others, the result is compared to a signed integer. Make > the comparisons consistent and correct. > > Signed-off-by: Chuck Lever <[EMAIL PROTECTED]> This looks good, applied. 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 2/12] X86: fix nvidia HPET warning
Jeff Garzik wrote:
> arch/x86/kernel/early-quirks.c:40: warning: ‘nvidia_hpet_check’ defined but
> not used
>
> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
> ---
>
> diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
> index dc34acb..639e632 100644
> --- a/arch/x86/kernel/early-quirks.c
> +++ b/arch/x86/kernel/early-quirks.c
> @@ -35,12 +35,14 @@ static void __init via_bugs(void)
> }
>
> #ifdef CONFIG_ACPI
> +#ifdef CONFIG_X86_IO_APIC
>
Why not #if defined(CONFIG_ACPI) && defined(CONFIG_X86_IO_APIC)? Saves
a line and a layer of #if(def).
>
> static int __init nvidia_hpet_check(struct acpi_table_header *header)
> {
> return 0;
> }
> -#endif
> +#endif /* CONFIG_X86_IO_APIC */
> +#endif /* CONFIG_ACPI */
>
J
-
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 1/12] X86: fix !CONFIG_SMP warning in processor.c
Jeff Garzik wrote:
> Fix !CONFIG_SMP warning:
>
> arch/x86/kernel/acpi/processor.c: In function ‘arch_acpi_processor_init_pdc’:
> arch/x86/kernel/acpi/processor.c:65: warning: unused variable ‘cpu’
>
> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
> ---
> Ideally this warning should be hidden inside a wrapper or somesuch, to
> camouflage the unneeded argument in !SMP case.
>
> diff --git a/arch/x86/kernel/acpi/processor.c
> b/arch/x86/kernel/acpi/processor.c
> index 2ed0a4c..45e262a 100644
> --- a/arch/x86/kernel/acpi/processor.c
> +++ b/arch/x86/kernel/acpi/processor.c
> @@ -62,7 +62,9 @@ static void init_intel_pdc(struct acpi_processor *pr,
> struct cpuinfo_x86 *c)
> /* Initialize _PDC data based on the CPU vendor */
> void arch_acpi_processor_init_pdc(struct acpi_processor *pr)
> {
> +#ifdef CONFIG_SMP
> unsigned int cpu = pr->id;
> +#endif
> struct cpuinfo_x86 *c = &cpu_data(cpu);
>
Surely just replace cpu with pr->id? That's the only use.
J
-
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/5] NET: Make ts_recent_stamp unsigned
From: Chuck Lever <[EMAIL PROTECTED]>
Date: Tue, 23 Oct 2007 11:44:28 -0400
> The get_seconds() function returns an unsigned long. To prevent incorrect
> comparison results between values saved in ts_recent_stamp and later
> invocations of get_seconds(), change the type of ts_recent_stamp to match
> the return type of get_seconds().
>
> Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
I see two potential problems with this patch:
1) If you update struct tcp_options_received you should also
update struct tcp_timewait_sock similarly.
The fact that you missed this suggests that you didn't
grep the tree to see how else this variable is used and
this makes me extra concerned about this patch's correctness.
2) There are computations in the TCP stack using this member that
probably care about the signedness, such as:
net/ipv4/tcp_ipv4.c: get_seconds() -
tcptw->tw_ts_recent_stamp > 1))) {
include/net/tcp.h: if (get_seconds() >= rx_opt->ts_recent_stamp +
TCP_PAWS_24DAYS)
include/net/tcp.h: if (get_seconds() >= rx_opt->ts_recent_stamp +
TCP_PAWS_24DAYS)
We should make sure we understand what is expected here, and
why it would still be correct after making both ts_recent_stamp
members unsigned.
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/
[PATCH] Elantech touchpad driver update for kernel 2.6.23-mm1
>From Arjan Opmeer <[EMAIL PROTECTED]> Update to the Elantech touchpad driver. Changes include: - Absolute mode reporting is now working on my laptop. - Fixed the use of a wrong constant in the Synaptics Identify query - Added Synaptics Modes query as newer versions of the Windows Elantech driver seem to try that query too. - Make an educated guess bases on the Synaptics Capabilities query whether middle mouse button reporting works and how finger taps are reported. - Added a debug option. Signed-off-by: Arjan Opmeer <[EMAIL PROTECTED]> --- diff -purN -X linux-2.6.23-mm1.vanilla/Documentation/dontdiff linux-2.6.23-mm1.vanilla/Documentation/input/elantech.txt linux-2.6.23-mm1.elantech/Documentation/input/elantech.txt --- linux-2.6.23-mm1.vanilla/Documentation/input/elantech.txt 2007-10-22 05:24:20.0 +0200 +++ linux-2.6.23-mm1.elantech/Documentation/input/elantech.txt 2007-10-22 05:24:55.0 +0200 @@ -1,68 +1,75 @@ Elantech Touchpad Driver - Copyright (C) 2007 Arjan Opmeer <[EMAIL PROTECTED]> +Copyright (C) 2007 Arjan Opmeer <[EMAIL PROTECTED]> +Extra information found and provided by Steve Havelka -Configuration of the touchpad is performed by writing register values to the -corresponding sysfs entries found under /sys/bus/serio/drivers/psmouse/serioX +Configuration of the touchpad is performed by writing values to registers +found under sysfs entries /sys/bus/serio/drivers/psmouse/serio?/reg_*. + +E.g. to disable tapping while leaving the other settings to the default +Windows driver value one would: + + echo -n 0x32 > reg_10 Registers -- +~ -* reg_10 (Windows driver default value 0x12) +* reg_10(Windows driver default value 0x12) bit 7 6 5 4 3 2 1 0 - 0 C T D L R S E + B C T D L A S E E: 1 = enable smart edges in other cases S: 1 = enable smart edges only when dragging - R: 1 = raw mode (needs 4 byte packets, see reg_11) + A: 1 = absolute mode (needs 4 byte packets, see reg_11) L: 1 = enable drag lock (see reg_22) D: 1 = disable dynamic resolution T: 1 = disable tapping C: 1 = enable corner tap + B: 1 = swap left and right button -* reg_11 (Windows driver default value 0x8f) +* reg_11(Windows driver default value 0x8f) bit 7 6 5 4 3 2 1 0 - 1 0 0 H V 1 P N + 1 0 0 H V 1 F P - N: 1 = bit 4 or 5 of byte 0 is 1 (non null top nibble ?) - P: 1 = enable native 4 byte packet mode (forced on by driver) + P: 1 = enable parity checking for relative mode + F: 1 = enable native 4 byte packet mode V: 1 = enable vertical scroll area H: 1 = enable horizonal scroll area -* reg_20 (Windows driver default value 0x0a) +* reg_20(Windows driver default value 0x0a) single finger width? -* reg_21 (Windows driver default value 0x60) +* reg_21(Windows driver default value 0x60) scroll area width (small: 0x40 ... wide: 0xff) -* reg_22 (Windows driver default value 0xff) +* reg_22(Windows driver default value 0xff) drag lock time out (short: 0x14 ... long: 0xfe; 0xff =never) -* reg_23 (Windows driver default value 0x10) +* reg_23(Windows driver default value 0x10) tap make timeout? Note: the Windows driver does not write this register -* reg_24 (Windows driver default value 0x10) +* reg_24(Windows driver default value 0x10) tap release timeout? Note: the Windows driver does not write this register -* reg_25 (Windows driver default value 0x03) +* reg_25(Windows driver default value 0x03) smart edge cursor speed (0x02 = slow, 0x03 = medium, 0x04 = fast) -* reg_26 (Windows driver default value 0x00 ?? ) +* reg_26(Windows driver default value 0x00 ?? ) smart edge activation area width? @@ -77,18 +84,22 @@ Registers Initially the Elantouch Touchpad is in emulation mode and reports 3 byte standard PS/2 packets and hence works with a standard mouse driver. -However, it can be configured to talk its native 4 byte mode and a raw 4 +However, it can be configured to talk its native 4 byte relative mode and 4 byte absolute mode both for which a dedicated driver is needed. Native 4 byte relative mode packet format -- +~ byte 0: bit 7 6 5 4 3 2 1 0 - c c ? ? 1 M R L + c c p2 p1 1 M R L L, R, M = 1 when Left, Right, Middle mouse button pressed +some models have M as byte 3 odd parity + when parity checking is enabled (P = 1): +p1
Re: [PATCH] Unlock before return in p9_mux_poll_start
From: Roel Kluin <[EMAIL PROTECTED]> Date: Tue, 23 Oct 2007 03:16:41 +0200 > commit 9f822afc65cc094c905901f9d92bf25042f9ed22 > Author: Roel Kluin <[EMAIL PROTECTED]> > Date: Tue Oct 23 03:15:55 2007 +0200 > > Unlock before return in p9_mux_poll_start > > Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> Applied, 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/
New version of Elantech touchpad driver for kernel 2.6.23.1
I updated my driver for the Elantech touchpad. Changes include: - Absolute mode reporting is now working on my laptop. - Fixed the use of a wrong constant in the Synaptics Identify query - Added Synaptics Modes query as newer versions of the Windows Elantech driver seem to try that query too. - Make an educated guess bases on the Synaptics Capabilities query whether middle mouse button reporting works and how finger taps are reported. - Added a debug option. Testers are still very much wanted and encouraged to give feedback. For people that are reading the mailing list via a web interface: I've made the patches available for download and provided some extra information at http://arjan.opmeer.net/elantech Arjan --- diff -purN -X linux-2.6.23.1.vanilla/Documentation/dontdiff linux-2.6.23.1.vanilla/Documentation/input/elantech.txt linux-2.6.23.1.elantech/Documentation/input/elantech.txt --- linux-2.6.23.1.vanilla/Documentation/input/elantech.txt 1970-01-01 01:00:00.0 +0100 +++ linux-2.6.23.1.elantech/Documentation/input/elantech.txt2007-10-22 04:56:15.0 +0200 @@ -0,0 +1,172 @@ +Elantech Touchpad Driver + +Copyright (C) 2007 Arjan Opmeer <[EMAIL PROTECTED]> + +Extra information found and provided by Steve Havelka + +Configuration of the touchpad is performed by writing values to registers +found under sysfs entries /sys/bus/serio/drivers/psmouse/serio?/reg_*. + +E.g. to disable tapping while leaving the other settings to the default +Windows driver value one would: + + echo -n 0x32 > reg_10 + + +Registers +~ + +* reg_10(Windows driver default value 0x12) + + bit 7 6 5 4 3 2 1 0 + B C T D L A S E + + E: 1 = enable smart edges in other cases + S: 1 = enable smart edges only when dragging + A: 1 = absolute mode (needs 4 byte packets, see reg_11) + L: 1 = enable drag lock (see reg_22) + D: 1 = disable dynamic resolution + T: 1 = disable tapping + C: 1 = enable corner tap + B: 1 = swap left and right button + +* reg_11(Windows driver default value 0x8f) + + bit 7 6 5 4 3 2 1 0 + 1 0 0 H V 1 F P + + P: 1 = enable parity checking for relative mode + F: 1 = enable native 4 byte packet mode + V: 1 = enable vertical scroll area + H: 1 = enable horizonal scroll area + + +* reg_20(Windows driver default value 0x0a) + + single finger width? + +* reg_21(Windows driver default value 0x60) + + scroll area width (small: 0x40 ... wide: 0xff) + +* reg_22(Windows driver default value 0xff) + + drag lock time out (short: 0x14 ... long: 0xfe; 0xff =never) + +* reg_23(Windows driver default value 0x10) + + tap make timeout? + + Note: the Windows driver does not write this register + +* reg_24(Windows driver default value 0x10) + + tap release timeout? + + Note: the Windows driver does not write this register + +* reg_25(Windows driver default value 0x03) + + smart edge cursor speed (0x02 = slow, 0x03 = medium, 0x04 = fast) + +* reg_26(Windows driver default value 0x00 ?? ) + + smart edge activation area width? + + Note: the Windows driver does not write this register + Note: the Windows driver default value of 0x00 disables smart edges + when it would get written + Note: the Windows driver sets bit 0 of the registry value to disable + tapping when typing, but never actually writes the register. + Only used as an internal driver flag? + + + +Initially the Elantouch Touchpad is in emulation mode and reports 3 byte +standard PS/2 packets and hence works with a standard mouse driver. +However, it can be configured to talk its native 4 byte relative mode and 4 +byte absolute mode both for which a dedicated driver is needed. + + +Native 4 byte relative mode packet format +~ + +byte 0: + bit 7 6 5 4 3 2 1 0 + c c p2 p1 1 M R L + + L, R, M = 1 when Left, Right, Middle mouse button pressed +some models have M as byte 3 odd parity + when parity checking is enabled (P = 1): +p1 = byte 1 odd parity +p2 = byte 2 odd parity + c = 1 when corner tap detected + +byte 1: + bit 7 6 5 4 3 2 1 0 +dx7 dx6 dx5 dx4 dx3 dx2 dx1 dx0 + + dx7..dx0 = x movement; positive = right, negative = left + byte 1 = 0xf0 when corner tap detected + +byte 2: + bit 7 6 5 4 3 2 1 0 +dy7 dy6 dy5 dy4 dy3 dy2 dy1 dy0 + + dy7..dy0 = y movement; positive = up,negative = down + +byte 3: + bit 7 6 5 4 3 2 1 0 + w h n1 n0 d3 d2 d1 d0 + + when parity checking
[PATCH] mpc5200: psc-spi driver must not touch port_config or cdm registers
From: Grant Likely <[EMAIL PROTECTED]>
port_config and the cdm are the responsibility of firmware; and if
firmware doesn't set it up correctly, it should be fixed up by
platform code on a per-board basis because it's a property of the
board.
Drivers should never touch these registers. They are completely
unprotected and the platform may do odd things with them that the
driver must not interfere with.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
Domen, Dragos; can you please check your usage of this driver. None of
the in-tree board ports use it as-is, but they are of course just a
device tree change away from being usable on the lite5200b.
Board ports that use it need to be modified to make the cdm/port_config
changes in firmware (prefered) or in arch/powerpc/platforms/52xx/.c
Cheers,
g.
drivers/spi/mpc52xx_psc_spi.c | 77 +
1 files changed, 2 insertions(+), 75 deletions(-)
diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
index 7051e6c..ec3a618 100644
--- a/drivers/spi/mpc52xx_psc_spi.c
+++ b/drivers/spi/mpc52xx_psc_spi.c
@@ -328,78 +328,15 @@ static void mpc52xx_psc_spi_cleanup(struct spi_device
*spi)
kfree(spi->controller_state);
}
-static int mpc52xx_psc_spi_port_config(int psc_id, struct mpc52xx_psc_spi *mps)
+static void mpc52xx_psc_spi_config(int psc_id, struct mpc52xx_psc_spi *mps)
{
- struct mpc52xx_cdm __iomem *cdm;
- struct mpc52xx_gpio __iomem *gpio;
struct mpc52xx_psc __iomem *psc = mps->psc;
- u32 ul;
u32 mclken_div;
- int ret = 0;
-
-#if defined(CONFIG_PPC_MERGE)
- cdm = mpc52xx_find_and_map("mpc5200-cdm");
- gpio = mpc52xx_find_and_map("mpc5200-gpio");
-#else
- cdm = ioremap(MPC52xx_PA(MPC52xx_CDM_OFFSET), MPC52xx_CDM_SIZE);
- gpio = ioremap(MPC52xx_PA(MPC52xx_GPIO_OFFSET), MPC52xx_GPIO_SIZE);
-#endif
- if (!cdm || !gpio) {
- printk(KERN_ERR "Error mapping CDM/GPIO\n");
- ret = -EFAULT;
- goto unmap_regs;
- }
/* default sysclk is 512MHz */
mclken_div = 0x8000 |
(((mps->sysclk ? mps->sysclk : 51200) / MCLK) & 0x1FF);
- switch (psc_id) {
- case 1:
- ul = in_be32(&gpio->port_config);
- ul &= 0xFFF8;
- ul |= 0x0006;
- out_be32(&gpio->port_config, ul);
- out_be16(&cdm->mclken_div_psc1, mclken_div);
- ul = in_be32(&cdm->clk_enables);
- ul |= 0x0020;
- out_be32(&cdm->clk_enables, ul);
- break;
- case 2:
- ul = in_be32(&gpio->port_config);
- ul &= 0xFF8F;
- ul |= 0x0060;
- out_be32(&gpio->port_config, ul);
- out_be16(&cdm->mclken_div_psc2, mclken_div);
- ul = in_be32(&cdm->clk_enables);
- ul |= 0x0040;
- out_be32(&cdm->clk_enables, ul);
- break;
- case 3:
- ul = in_be32(&gpio->port_config);
- ul &= 0xF0FF;
- ul |= 0x0600;
- out_be32(&gpio->port_config, ul);
- out_be16(&cdm->mclken_div_psc3, mclken_div);
- ul = in_be32(&cdm->clk_enables);
- ul |= 0x0080;
- out_be32(&cdm->clk_enables, ul);
- break;
- case 6:
- ul = in_be32(&gpio->port_config);
- ul &= 0xFF8F;
- ul |= 0x0070;
- out_be32(&gpio->port_config, ul);
- out_be16(&cdm->mclken_div_psc6, mclken_div);
- ul = in_be32(&cdm->clk_enables);
- ul |= 0x0010;
- out_be32(&cdm->clk_enables, ul);
- break;
- default:
- ret = -EINVAL;
- goto unmap_regs;
- }
-
/* Reset the PSC into a known state */
out_8(&psc->command, MPC52xx_PSC_RST_RX);
out_8(&psc->command, MPC52xx_PSC_RST_TX);
@@ -421,14 +358,6 @@ static int mpc52xx_psc_spi_port_config(int psc_id, struct
mpc52xx_psc_spi *mps)
out_8(&psc->ctlr, 0x84);
mps->bits_per_word = 8;
-
-unmap_regs:
- if (cdm)
- iounmap(cdm);
- if (gpio)
- iounmap(gpio);
-
- return ret;
}
static irqreturn_t mpc52xx_psc_spi_isr(int irq, void *dev_id)
@@ -493,9 +422,7 @@ static int __init mpc52xx_psc_spi_do_probe(struct device
*dev, u32 regaddr,
if (ret)
goto free_master;
- ret = mpc52xx_psc_spi_port_config(master->bus_num, mps);
- if (ret < 0)
- goto free_irq;
+ mpc52xx_psc_spi_config(master->bus_num, mps);
spin_lock_init(&mps->lock);
init_completion(&mps->done);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: LSM conversion to static interface
On Tue, Oct 23, 2007 at 12:12:11AM -0700, Crispin Cowan wrote: > * Some people are not comfortable building kernels from source. It > doesn't matter how easy *you* think it is, it is a significant > barrier to entry for a lot of people. Especially if their day job > is systems or security administration, and not kernel hacking. That's why I wrote a whole book about how to do just that. And it's free, print it out and give it to all your friends! www.kroah.com/lkn/ 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: const vs __{dev}initdata
On Tue, Oct 23, 2007 at 11:35:56PM +0200, Bartlomiej Zolnierkiewicz wrote: > > [ BTW Greg: this doesn't seem to be mentioned in LDD3. ] _lots_ of things aren't mentioned in LDD3, and it's quite out of date now, and we really don't have a plan to update it anytime soon :( 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: [PATCH] Input: Support for a less exclusive grab.
On Tuesday 23 October 2007, Ryan Lortie wrote: > On Tue, 2007-23-10 at 14:10 -0400, Dmitry Torokhov wrote: > > No, rfkill want to see keypresses, period. It does not care if there > > are other applications also seeing the same keypresses, it just does > > not want keypresses stolen from it. > > Right. This is exactly the problem. The current grab API exists to > prevent keys from being delivered to normal users, but rfkill still > wants to see them. > > No matter how you slice it, if both of these desires are to be satisfied > then there needs to be some sort of a system to differentiate between > rfkill and "normal users". That's what the priority is here. > And the solution is pretty simple - do not use grab. -- Dmitry - 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 00/13] Use struct path in struct nameidata
On Tue, Oct 23, 2007 at 10:43:05AM +0200, Jan Blunck wrote: > > The thing is: how do we keep going from here? Do you want to send my patches > in the future or are you going to ask me before sending things out? We don't > need to duplicate the work here. I already put my quilt stack into a public > place for you to work on them but I don't like the way this is going on at the > moment. My intention was to help speed up the Union Mount effort by ensuring that patches don't rot waiting for developer's attention. Going by the past interactions, I got a feeling that you have lot of other work besides this, while I have time to spare on this. Hence wanted to do my bit to get patches moving as quickly as possible. As I have conveyed to you many times, I would still like you to maintain the patches and send out as timely as possible on lkml. If you can't do this because of your other commitments, then I would more than willing to maintain these and give them maximum attention. And thanks for making available the patches publicly, I have been asking this for months now. Regards, Bharata. - 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/
[BUG] 2.6.23-git19 - S390x: Kernel panic while bringing up the network interface
Hi, Kernel panic's while bringing up the network interface with the 2.6.23-git19 Setting network parameters: Ý OK ¨ Bringing up loopback interface: Ý OK ¨ Bringing up interface eth0: Ý<002e2f72>¨ inet_ioctl+0xd6/0x110 Ý<0027cae2>¨ sock_ioctl+0x26e/0x2a0 Ý<000b4c52>¨ do_ioctl+0x4a/0xac Ý<000b5076>¨ vfs_ioctl+0x3c2/0x3d8 Ý<000b50ec>¨ sys_ioctl+0x60/0x88 Ý<00021b7e>¨ sysc_noemu+0x10/0x16 Ý<021201ca>¨ 0x21201ca <0>Kernel panic - not syncing: Fatal exception in interrupt 00: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from CPU 01. 02: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from CPU 01. 03: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from CPU 01. 01: HCPGIR450W CP entered; disabled wait PSW 00020001 8000 000164DE -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. - 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 13/13] RT: Cache cpus_allowed weight for optimizing migration
On Wed, 2007-10-24 at 02:19 +0200, Ingo Oeser wrote: > Why not make it a task flag, since according to your code, you are only > interested whether this is <= 1 or > 1. Since !(x <= 1) <=> (x > 1) > for any given unsigned integer x, the required data structure is > a "boolean" or a flag. Hi Ingo, You are correct that the data is in fact interpreted as a boolean. I also had considered using a more boolean-like notation at one point. However, I then figured I went through the expense of computing it, I might as well store the actual value as an integer in case it can be used in another way. But to be honest, I cannot really think of any other potential uses, so perhaps we would be best to follow your suggestion. It could always be changed if such a need ever arises. Thank you for the feedback! Regards, -Greg signature.asc Description: This is a digitally signed message part
Re: How do I get my aic94xx to see sata drives?
Jeff Garzik wrote: > Wakko Warner wrote: > >Please CC me. > > Please don't use > > Mail-Followup-To: linux-kernel@vger.kernel.org > > in your emails then :) I'm not sending out that header. Maybe I should with my address? > >I've looked around and the only thing I can find was a git repository for > >it. I don't know anything about git. I just want to get the driver so I > >can use the sata drives I have on this controller. > > > >I'm currently using 2.6.22. > > hum, it should be working in 2.6.22. There were some minor fixes and > changes in 2.6.23 that you might want to try, but overall, we are > interested in your bug report. Dmesg says: [ 335.12] aic94xx: Adaptec aic94xx SAS/SATA driver version 1.0.3 loaded [ 335.12] ACPI: PCI Interrupt :07:02.0[A] -> GSI 30 (level, low) -> IRQ 20 [ 335.12] aic94xx: found Adaptec AIC-9410W SAS/SATA Host Adapter, device :07:02.0 [ 335.12] scsi12 : aic94xx [ 337.748000] aic94xx: Found sequencer Firmware version 1.1 (V17/10c6) [ 337.792000] aic94xx: device :07:02.0: SAS addr 5003048000509c60, PCBA SN ORG, 8 phys, 8 enabled phys, flash present, BIOS build 1822 [ 337.836000] ERROR: Unidentified device type 5 [ 337.836000] ERROR: Unidentified device type 5 [ 337.836000] ERROR: Unidentified device type 5 [ 337.836000] ERROR: Unidentified device type 5 [ 337.836000] ERROR: Unidentified device type 5 [ 337.836000] ERROR: Unidentified device type 5 I currently have 6 sata devices attached to ports 0-2 and 4-6. The controller's bios sees them properly. libata is also loaded. I'll give 2.6.23 a try tomorrow, I didn't realise it was available already. -- Lab tests show that use of micro$oft causes cancer in lab animals Got Gas??? - 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] bluetooth: hidp_process_hid_control remove unnecessary parameter dealing
According to the bluetooth HID spec v1.0 chapter 7.4.2
"This code requests a major state change in a BT-HID device. A HID_CONTROL
request does not generate a HANDSHAKE response."
"A HID_CONTROL packet with a parameter of VIRTUAL_CABLE_UNPLUG is the only
HID_CONTROL packet a device can send to a host. A host will ignore all other
packets."
So in the hidp_precess_hid_control function, we just need to deal with the
UNLUG packet.
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
net/bluetooth/hidp/core.c | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff -upr linux/net/bluetooth/hidp/core.c linux.new/net/bluetooth/hidp/core.c
--- linux/net/bluetooth/hidp/core.c 2007-10-15 14:05:23.0 +0800
+++ linux.new/net/bluetooth/hidp/core.c 2007-10-24 11:01:07.0 +0800
@@ -369,30 +369,13 @@ static inline void hidp_process_hid_cont
{
BT_DBG("session %p param 0x%02x", session, param);
- switch (param) {
- case HIDP_CTRL_NOP:
- break;
-
- case HIDP_CTRL_VIRTUAL_CABLE_UNPLUG:
+ if (param == HIDP_CTRL_VIRTUAL_CABLE_UNPLUG) {
/* Flush the transmit queues */
skb_queue_purge(&session->ctrl_transmit);
skb_queue_purge(&session->intr_transmit);
/* Kill session thread */
atomic_inc(&session->terminate);
- break;
-
- case HIDP_CTRL_HARD_RESET:
- case HIDP_CTRL_SOFT_RESET:
- case HIDP_CTRL_SUSPEND:
- case HIDP_CTRL_EXIT_SUSPEND:
- /* FIXME: We have to parse these and return no error */
- break;
-
- default:
- __hidp_send_ctrl_message(session,
- HIDP_TRANS_HANDSHAKE | HIDP_HSHK_ERR_INVALID_PARAMETER,
NULL, 0);
- 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/
Kconfig: conf segfault (with invalid kconfig contents)
Hi, Sorry, no patch, just a bugreport. :) I did a mistake in some Kconfig changes (locally) and got a segfault from conf: #0 0x10005fe0 in sym_check_deps () #1 0x10005f40 in sym_check_expr_deps () #2 0x1000605c in sym_check_deps () #3 0x1000f3f4 in conf_parse () #4 0x10003824 in main () The way to reproduce is simple. I just added the equivalent of this to arch/powerpc/Kconfig: --- config TEST1 bool depends on TEST2 && PCI select TEST2 config TEST2 bool --- Neither TEST1 nor TEST2 exists in the existing .config when I run make oldconfig to reproduce. It's clearly invalid in that it depends on what it selects, but it should just abort instead. -Olof - 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 -v7 1/3] x86 boot: setup data
On Tue, 2007-10-23 at 16:55 -0700, H. Peter Anvin wrote: > Andi Kleen wrote: > > > > With the early reserve code in > > ftp://firstfloor.org/pub/ak/x86_64/quilt/patches/early-reserve > > and > > ftp://firstfloor.org/pub/ak/x86_64/quilt/patches/early-alloc > > this could be likely done cleaner. > > > > Indeed it could. For i386, the equivalent code would have another > significant benefit: reserving memory and then mapping and accessing it > later would (at least eventually) allow accesses > 4 GB on PAE kernels > (or with a PSE36 hack, on non-PAE kernels.) For i386, the bootmem allocator covers at most 0~796M memory area. So some early reserve memory area can not be revered with bootmem allocator later. Should we fix bootmem allocator firstly? Best Regards, Huang Ying - 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: [RFC] what the hell is going on with /proc/self?
Al Viro <[EMAIL PROTECTED]> writes:
> On Tue, Oct 23, 2007 at 03:20:39PM -0500, Matt Mackall wrote:
>> On Tue, Oct 23, 2007 at 03:03:36AM +0100, Al Viro wrote:
>> >What is the proc_base_stuff[] nonsense about? AFAICS, that
>> > went in with no reason whatsoever in
>> > commit 801199ce805a2412bbcd9bfe213092ec656013dd
>> > Author: Eric W. Biederman <[EMAIL PROTECTED]>
>> > Date: Mon Oct 2 02:18:48 2006 -0700
>> >
>> >Rationale is very weak and patch adds considerable complexity
>> > for no good reason. Besides, it's obfuscated just for the hell of it:
>> >if (!IS_ERR(result) || PTR_ERR(result) != -ENOENT)
>> > instead of
>> >if (result != ERR_PTR(-ENOENT))
>> > etc.
>> >
>> >Unless there are _real_ plans that would justify that animal,
>> > I'm going to get rid of it in the pending patch series (/proc/self
>> > cleanups, saner dentry retention for non-process parts, etc.).
>>
>> Seems obvious to cc: Eric.
>
> Doh... Sorry, thought I'd done that. Eric, my apologies.
No problem.
It has been a while so let me see if I can dredge up what goes
on there, partly I ran out of steam when working on that.
One useful aspect of that change to use common infrastructure was in
removing the hard coded inode numbers from /proc. By going through
proc_fill_cache I was able to ensure the inode numbers matched
up for /proc/self no matter what they were.
Another aspect of the change that I didn't feel comfortable using
to justify it then and but I do now think is important now is that if
the pid namespace goes away (aka a secondary init and all their
children exit) /proc/self disappears.
I believe that my original patch was smaller and had a bunch more
code reuse until I discovered that the I would goof up the
security modules if I called security_task_to_inode on /proc/self.
So it is my desire (and I think it a reasonable one) that if all
of the tasks in a pid namespace that correspond to a mount of proc
exit then all of the files associated with the pid namespace itself
should disappear.
Getting all of the files that are process related into the
infrastructure of fs/proc/base.c is one way to achieve the process
related files disappear. Especially as it seemed well connected with
something the concept of splitting proc up into it's constituent
filesystems. /proc/ /proc/sys and /proc/{generic}.
The more I look at that the amount of /proc that doesn't become
namespace related and thus desirable to be show per process is getting
quite small, so a different technique then using the infrastructure
in fs/proc/base.c may be desirable.
When eventually we get to the device namespace (bleh) we get
things like /proc/scsi/ /proc/tty/ /proc/ide/ and /proc/devices
that should become per namespace as well. Which probably means
at least half of the existing of the existing /proc/{generic}
stuff looks to become per namespace.
So in practice the things that I see needing to happen with /proc
right now.
- Figure out how to move /proc/net into /proc//net leaving
behind a /proc/net symlink to /proc/self/net.
- Fix proc_kill_inodes to cope with multiple super blocks.
- /proc/self I still think needs to get the pid and not the tgid
as sometimes I think we get incorrect behavior when coming from
a thread.
- /proc/sysvipc should really become a /proc/self/sysvipc symlink.
- /proc/sys needs to become /proc/self/sys/ and the work pushed
down in that direction.
For the stuff that isn't per namespace enhancing the caching does
have the challenge that we are likely to hit the current bug in
proc_kill_inodes because the inodes will stay around longer.
Although ideally if this could be it's own filesystem we would
only have a single instance of those dentries.
Similarly it would be nice if per namespace things like
/proc//mounts, /proc//net, /proc//sys,
/proc//sysvipc could share the same dentry trees,
across different /proc/ instances. Especially as that
would allow using stat to detect if two processes were sharing
the same namespace. The only thing that suggests itself is making
kernel mounts that are per namespace, for these things. Which is one
of the reasons I'm interested in splitting /proc up into separate
filesystems.
So in summary. I really don't care how the internals of /proc look,
or which path we take. As long as we do improve /proc and ultimately
sort through the per namespace details.
Eric
-
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 4/4]: [PCI]: Add MSI INTX_DISABLE quirks for ATI SB700/800 SATA and IXP SB400 USB
Signed-off-by: David S. Miller <[EMAIL PROTECTED]> --- drivers/pci/quirks.c | 20 1 files changed, 20 insertions(+), 0 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 591eaa4..5795a3d 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1725,4 +1725,24 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5714S, quirk_msi_intx_disable_bug); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4390, + quirk_msi_intx_disable_bug); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4391, + quirk_msi_intx_disable_bug); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4392, + quirk_msi_intx_disable_bug); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4393, + quirk_msi_intx_disable_bug); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4394, + quirk_msi_intx_disable_bug); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4395, + quirk_msi_intx_disable_bug); + +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4373, + quirk_msi_intx_disable_bug); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4374, + quirk_msi_intx_disable_bug); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4375, + quirk_msi_intx_disable_bug); + #endif /* CONFIG_PCI_MSI */ -- 1.5.3.4 - 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 3/4]: [PCI]: Add quirk for devices which disable MSI when INTX_DISABLE is set.
A reasonably common problem with some devices is that they will
disable MSI generation when the INTX_DISABLE bit is set in the
PCI_COMMAND register.
Quirk this explicitly, guarding the pci_intx() calls in msi.c with
this quirk indication.
The first entries for this quirk are for 5714 and 5780 Tigon3 chips,
and thus we can remove the workaround code from the tg3.c driver.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
---
drivers/net/tg3.c|9 -
drivers/pci/msi.c| 18 --
drivers/pci/quirks.c | 18 ++
include/linux/pci.h |9 +
4 files changed, 39 insertions(+), 15 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 09440d7..cad5199 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -7365,10 +7365,6 @@ static int tg3_open(struct net_device *dev)
} else if (pci_enable_msi(tp->pdev) == 0) {
u32 msi_mode;
- /* Hardware bug - MSI won't work if INTX disabled. */
- if (tp->tg3_flags2 & TG3_FLG2_5780_CLASS)
- pci_intx(tp->pdev, 1);
-
msi_mode = tr32(MSGINT_MODE);
tw32(MSGINT_MODE, msi_mode | MSGINT_MODE_ENABLE);
tp->tg3_flags2 |= TG3_FLG2_USING_MSI;
@@ -12681,11 +12677,6 @@ static int tg3_resume(struct pci_dev *pdev)
if (err)
return err;
- /* Hardware bug - MSI won't work if INTX disabled. */
- if ((tp->tg3_flags2 & TG3_FLG2_5780_CLASS) &&
- (tp->tg3_flags2 & TG3_FLG2_USING_MSI))
- pci_intx(tp->pdev, 1);
-
netif_device_attach(dev);
tg3_full_lock(tp, 0);
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 87e0161..a8dd18c 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -237,7 +237,8 @@ static void __pci_restore_msi_state(struct pci_dev *dev)
entry = get_irq_msi(dev->irq);
pos = entry->msi_attrib.pos;
- pci_intx(dev, 0); /* disable intx */
+ if (!(dev->dev_flags & PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG))
+ pci_intx(dev, 0); /* disable intx */
msi_set_enable(dev, 0);
write_msi_msg(dev->irq, &entry->msg);
if (entry->msi_attrib.maskbit)
@@ -260,7 +261,8 @@ static void __pci_restore_msix_state(struct pci_dev *dev)
return;
/* route the table */
- pci_intx(dev, 0); /* disable intx */
+ if (!(dev->dev_flags & PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG))
+ pci_intx(dev, 0); /* disable intx */
msix_set_enable(dev, 0);
list_for_each_entry(entry, &dev->msi_list, list) {
@@ -343,7 +345,8 @@ static int msi_capability_init(struct pci_dev *dev)
}
/* Set MSI enabled bits */
- pci_intx(dev, 0); /* disable intx */
+ if (!(dev->dev_flags & PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG))
+ pci_intx(dev, 0); /* disable intx */
msi_set_enable(dev, 1);
dev->msi_enabled = 1;
@@ -433,7 +436,8 @@ static int msix_capability_init(struct pci_dev *dev,
i++;
}
/* Set MSI-X enabled bits */
- pci_intx(dev, 0); /* disable intx */
+ if (!(dev->dev_flags & PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG))
+ pci_intx(dev, 0); /* disable intx */
msix_set_enable(dev, 1);
dev->msix_enabled = 1;
@@ -528,7 +532,8 @@ void pci_disable_msi(struct pci_dev* dev)
return;
msi_set_enable(dev, 0);
- pci_intx(dev, 1); /* enable intx */
+ if (!(dev->dev_flags & PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG))
+ pci_intx(dev, 1); /* enable intx */
dev->msi_enabled = 0;
BUG_ON(list_empty(&dev->msi_list));
@@ -640,7 +645,8 @@ void pci_disable_msix(struct pci_dev* dev)
return;
msix_set_enable(dev, 0);
- pci_intx(dev, 1); /* enable intx */
+ if (!(dev->dev_flags & PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG))
+ pci_intx(dev, 1); /* enable intx */
dev->msix_enabled = 0;
msix_free_all_irqs(dev);
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index e588988..591eaa4 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -1707,4 +1707,22 @@ static void __devinit
quirk_nvidia_ck804_msi_ht_cap(struct pci_dev *dev)
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_CK804_PCIE,
quirk_nvidia_ck804_msi_ht_cap);
+
+static void __devinit quirk_msi_intx_disable_bug(struct pci_dev *dev)
+{
+ dev->dev_flags |= PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG;
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM,
+ PCI_DEVICE_ID_TIGON3_5780,
+ quirk_msi_intx_disable_bug);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM,
+ PCI_DEVICE_ID_TIGON3_5780S,
+
[PATCH 2/4]: [PCI]: Add MSI quirk for ServerWorks HT1000 PCIX bridge.
This is the fix for the following problem: https://bugzilla.redhat.com/show_bug.cgi?id=227657 The bnx2 device 5706 complains about MSI not working behind a ServerWorks HT1000 PCIX bridge. An earlier commit to fix the problem: e3008dedff4bdc96a5f67224cd3d8d12237082a0: "PCI: disable MSI by default on systems with Serverworks HT1000 chips" was not entirely correct, and has been reverted. MSI does not work on the PCIX bus because the BIOS did not set the HT_MSI_FLAGS_ENABLE bit in the HyperTransport MSI capability on the bridge. We use the existing quirk_msi_ht_cap() to detect the problem and disable MSI in all buses behind it. Signed-off-by: Michael Chan <[EMAIL PROTECTED]> Cc: Anantha Subramanyam <[EMAIL PROTECTED]> Cc: Naren Sankar <[EMAIL PROTECTED]> Signed-off-by: David S. Miller <[EMAIL PROTECTED]> --- drivers/pci/quirks.c|3 +++ include/linux/pci_ids.h |1 + 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 1f1ee67..e588988 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1677,6 +1677,9 @@ static void __devinit quirk_msi_ht_cap(struct pci_dev *dev) } DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_HT2000_PCIE, quirk_msi_ht_cap); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, + PCI_DEVICE_ID_SERVERWORKS_HT1000_PXB, + quirk_msi_ht_cap); /* The nVidia CK804 chipset may have 2 HT MSI mappings. * MSI are supported if the MSI capability set in any of these mappings. diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 0571d6a..c64bb89 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -1432,6 +1432,7 @@ #define PCI_DEVICE_ID_SERVERWORKS_HE 0x0008 #define PCI_DEVICE_ID_SERVERWORKS_LE 0x0009 #define PCI_DEVICE_ID_SERVERWORKS_GCNB_LE 0x0017 +#define PCI_DEVICE_ID_SERVERWORKS_HT1000_PXB 0x0036 #define PCI_DEVICE_ID_SERVERWORKS_EPB0x0103 #define PCI_DEVICE_ID_SERVERWORKS_HT2000_PCIE 0x0132 #define PCI_DEVICE_ID_SERVERWORKS_OSB4 0x0200 -- 1.5.3.4 - 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 1/4]: Revert "PCI: disable MSI by default on systems with Serverworks HT1000 chips"
This reverts commit e3008dedff4bdc96a5f67224cd3d8d12237082a0. The real bug was an INTX issue in the tg3 ethernet chip, and cured by commit c129d962a66c76964954a98b38586ada82cf9381 Signed-off-by: David S. Miller <[EMAIL PROTECTED]> --- drivers/pci/quirks.c|1 - include/linux/pci_ids.h |1 - 2 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 59d4da2..1f1ee67 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1621,7 +1621,6 @@ static void __init quirk_disable_all_msi(struct pci_dev *dev) printk(KERN_WARNING "PCI: MSI quirk detected. MSI deactivated.\n"); } DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_GCNB_LE, quirk_disable_all_msi); -DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_HT1000_PCIX, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS400_200, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS480, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RD580, quirk_disable_all_msi); diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 4e10a07..0571d6a 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -1433,7 +1433,6 @@ #define PCI_DEVICE_ID_SERVERWORKS_LE 0x0009 #define PCI_DEVICE_ID_SERVERWORKS_GCNB_LE 0x0017 #define PCI_DEVICE_ID_SERVERWORKS_EPB0x0103 -#define PCI_DEVICE_ID_SERVERWORKS_HT1000_PCIX 0x0104 #define PCI_DEVICE_ID_SERVERWORKS_HT2000_PCIE 0x0132 #define PCI_DEVICE_ID_SERVERWORKS_OSB4 0x0200 #define PCI_DEVICE_ID_SERVERWORKS_CSB5 0x0201 -- 1.5.3.4 - 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 0/4]: Resolve MSI vs. INTX_DISABLE quirks.
The forthcoming patches are also available from: kernel.org:/pub/scm/linux/kernel/git/davem/msiquirk-2.6.git and clean up the handling of the common quirk wherein setting INTX_DISABLE will mistakedly disable MSI generation for some devices. For devices without that problem, we want to keep the pci_intx() calls in drivers/pci/msi.c because those help protect against devices with the opposite problem. Such devices always generate INTX interrupts even when MSI is enabled, unless INTX_DISABLE is set. Michael, please pay special attention to patch #3. I think I picked the correct PCI device IDs to match for the quirk (5714* and 5780*) but it's possible we might need more elaborate checks here. It at least worked properly for the chips in my Niagara system. In addition to the Tigon3 cases, I added quirk entries for the SB700/800 SATA chips and the IXP SB400 USB controllers. Signed-off-by: David S. Miller <[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 1/4] stringbuf: A string buffer implementation
On Tue, 2007-10-23 at 20:35 -0600, Matthew Wilcox wrote: [...] > > Multiple string objects can share the same data, by increasing the nrefs > > count, a new data is allocated if the string is modified and nrefs > 1. > > If we were trying to get rid of char * throughout the kernel, that might > make some sense; stringbufs have a more limited target though. > [...] No contest, my suggestions only make sense for a general uses string library. I suspect most in-kernel string manipulations are limited to prepare buffers to be copied to (and read from) user-space. - Eric - 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] pcie: utilize pcie transaction pending bit
PCIE has a mechanism to wait for Non-Posted request to complete. I think
pci_disable_device is a good place to do this.
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
---
drivers/pci/pci.c | 21 +
include/linux/pci.h |2 ++
2 files changed, 23 insertions(+)
Index: linux/drivers/pci/pci.c
===
--- linux.orig/drivers/pci/pci.c2007-10-17 10:33:48.0 +0800
+++ linux/drivers/pci/pci.c 2007-10-22 14:22:53.0 +0800
@@ -314,6 +314,24 @@ int pci_find_ht_capability(struct pci_de
}
EXPORT_SYMBOL_GPL(pci_find_ht_capability);
+void pcie_wait_pending_transaction(struct pci_dev *dev)
+{
+ int pos;
+ u16 reg16;
+
+ pos = pci_find_capability(dev, PCI_CAP_ID_EXP);
+ if (!pos)
+ return;
+ while (1) {
+ pci_read_config_word(dev, pos + PCI_EXP_DEVSTA, ®16);
+ if (!(reg16 & PCI_EXP_DEVSTA_TRPND))
+ break;
+ cpu_relax();
+ }
+
+}
+EXPORT_SYMBOL_GPL(pcie_wait_pending_transaction);
+
/**
* pci_find_parent_resource - return resource region of parent bus of given
region
* @dev: PCI device structure contains resources to be searched
@@ -884,6 +902,9 @@ pci_disable_device(struct pci_dev *dev)
if (atomic_sub_return(1, &dev->enable_cnt) != 0)
return;
+ /* Wait for all transactions are finished before disabling the device */
+ pcie_wait_pending_transaction(dev);
+
pci_read_config_word(dev, PCI_COMMAND, &pci_command);
if (pci_command & PCI_COMMAND_MASTER) {
pci_command &= ~PCI_COMMAND_MASTER;
Index: linux/include/linux/pci.h
===
--- linux.orig/include/linux/pci.h 2007-10-17 10:33:52.0 +0800
+++ linux/include/linux/pci.h 2007-10-22 14:19:56.0 +0800
@@ -484,6 +484,7 @@ int pci_find_next_capability (struct pci
int pci_find_ext_capability (struct pci_dev *dev, int cap);
int pci_find_ht_capability (struct pci_dev *dev, int ht_cap);
int pci_find_next_ht_capability (struct pci_dev *dev, int pos, int ht_cap);
+void pcie_wait_pending_transaction(struct pci_dev *dev);
struct pci_bus *pci_find_next_bus(const struct pci_bus *from);
struct pci_dev *pci_get_device(unsigned int vendor, unsigned int device,
@@ -749,6 +750,7 @@ static inline void pci_unregister_driver
static inline int pci_find_capability (struct pci_dev *dev, int cap) {return
0; }
static inline int pci_find_next_capability (struct pci_dev *dev, u8 post, int
cap) { return 0; }
static inline int pci_find_ext_capability (struct pci_dev *dev, int cap)
{return 0; }
+static inline void pcie_wait_pending_transaction(struct pci_dev *dev) {}
static inline const struct pci_device_id *pci_match_device(const struct
pci_device_id *ids, const struct pci_dev *dev) { return NULL; }
/* Power management related routines */
-
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] PCI: disable MSI on more ATI NorthBridges
From: David Miller <[EMAIL PROTECTED]> Date: Tue, 23 Oct 2007 03:06:22 -0700 (PDT) > Ok, it seems I've sort-of self-nominated myself to implement > this so I'll try to work on it tomorrow :-) I have a working implementation, fully tested on a machine with Tigon3 ethernet chips that have the quirk in question. Patch set coming up next. - 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] pcie port driver: fix something inconsist with spec
The port driver interrupt assignment has two issues for MSI-X:
1. PME and HP share an interrupt, VC hasn't interrupt and only root port and
event collector has interrupt for AER.
2. For each capability, its interrupt should be read from specific PCI config
register per spec.
This is true for multiple vector MSI, but as we didn't support it so far, I
just ignore it.
Note, this is just passed compiling, I can't find a root port which supports
MSI-X.
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
---
drivers/pci/pcie/portdrv_core.c | 70 +---
1 file changed, 58 insertions(+), 12 deletions(-)
Index: linux/drivers/pci/pcie/portdrv_core.c
===
--- linux.orig/drivers/pci/pcie/portdrv_core.c 2007-10-22 09:41:25.0
+0800
+++ linux/drivers/pci/pcie/portdrv_core.c 2007-10-22 14:54:36.0
+0800
@@ -128,7 +128,62 @@ static int is_msi_quirked(struct pci_dev
}
return quirk;
}
-
+
+static int assign_msix_interrupt_mode(struct pci_dev *dev, int *vectors, int
mask)
+{
+ struct msix_entry msix_entries[2] = {{0, 0}, {0, 1}};
+ int nvec = 0;
+ int status;
+ int pos = pci_find_capability(dev, PCI_CAP_ID_EXP);
+ u16 reg;
+ int i;
+
+ pci_read_config_word(dev, pos + PCIE_CAPABILITIES_REG, ®);
+ /*
+* PME and HP share an interrupt, VC hasn't interrupt, so we needs 2
+* interrupts at most
+*/
+ if (mask & (PCIE_PORT_SERVICE_PME|PCIE_PORT_SERVICE_HP))
+ nvec ++;
+ /* root port needs interrupt */
+ if ((mask & PCIE_PORT_SERVICE_AER)
+&& ((reg >> 4) & PORT_TYPE_MASK) == PCIE_RC_PORT)
+ nvec ++;
+
+ status = pci_enable_msix(dev, msix_entries, nvec);
+ if (status)
+ return status;
+
+ for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++) {
+ if (!(mask & (1 << i)))
+ continue;
+ if (mask & (PCIE_PORT_SERVICE_PME|PCIE_PORT_SERVICE_HP)) {
+ u16 reg16;
+
+ pci_read_config_word(dev,
+ pos + PCIE_CAPABILITIES_REG, ®16);
+ reg16 = (reg16 & PCI_EXP_FLAGS_IRQ) >> 9;
+ BUG_ON(reg16 >= nvec);
+ vectors[i] = msix_entries[reg16].vector;
+ printk("Capability %d uses %d MSI-X entry\n", i, reg16);
+ }
+ if ((mask & PCIE_PORT_SERVICE_AER)
+ && ((reg >> 4) & PORT_TYPE_MASK) == PCIE_RC_PORT) {
+ u32 reg32;
+ int aer_pos = pci_find_ext_capability(dev,
+ PCI_EXT_CAP_ID_ERR);
+
+ pci_read_config_dword(dev,
+ aer_pos + PCI_ERR_ROOT_STATUS, ®32);
+ reg32 >>= 27;
+ BUG_ON(reg32 >= nvec);
+ vectors[i] = msix_entries[reg32].vector;
+ printk("Capability %d uses %d MSI-X entry\n", i, reg32);
+ }
+ }
+ return 0;
+}
+
static int assign_interrupt_mode(struct pci_dev *dev, int *vectors, int mask)
{
int i, pos, nvec, status = -EINVAL;
@@ -148,19 +203,10 @@ static int assign_interrupt_mode(struct
/* Select MSI-X over MSI if supported */
pos = pci_find_capability(dev, PCI_CAP_ID_MSIX);
if (pos) {
- struct msix_entry msix_entries[PCIE_PORT_DEVICE_MAXSERVICES] =
- {{0, 0}, {0, 1}, {0, 2}, {0, 3}};
printk("%s Found MSIX capability\n", __FUNCTION__);
- status = pci_enable_msix(dev, msix_entries, nvec);
- if (!status) {
- int j = 0;
-
+ status = assign_msix_interrupt_mode(dev, vectors, mask);
+ if (!status)
interrupt_mode = PCIE_PORT_MSIX_MODE;
- for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++) {
- if (mask & (1 << i))
- vectors[i] = msix_entries[j++].vector;
- }
- }
}
if (status) {
pos = pci_find_capability(dev, PCI_CAP_ID_MSI);
-
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 1/4] stringbuf: A string buffer implementation
On Tue, 23 Oct 2007 20:30:35 -0600 Matthew Wilcox <[EMAIL PROTECTED]> wrote: > It's a matter of taste ... some people prefer to use accessors for > everything, other people prefer to expose the underlying structure > directly. Experience tells us that when you use accessors you end up thanking yourself later on. Especially when diddling struct page ;) Although one really should make a best-effort guess at "how likely is this to change in the future". If the implementation-to-be-copied has been out there for a while then "not very" is a good answer. But hey, don't listen to me - I like C++, and approve of Java. - 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] pcie port driver: correctly detect native PME feature
Native PME is capability of root port or root complex event collector. It's not determined by PCI PME capability. Signed-off-by: Shaohua Li <[EMAIL PROTECTED]> --- drivers/pci/pcie/portdrv_core.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) Index: linux/drivers/pci/pcie/portdrv_core.c === --- linux.orig/drivers/pci/pcie/portdrv_core.c 2007-10-22 09:36:05.0 +0800 +++ linux/drivers/pci/pcie/portdrv_core.c 2007-10-22 09:41:25.0 +0800 @@ -192,9 +192,8 @@ static int get_port_device_capability(st if (reg32 & SLOT_HP_CAPABLE_MASK) services |= PCIE_PORT_SERVICE_HP; } - /* PME Capable */ - pos = pci_find_capability(dev, PCI_CAP_ID_PME); - if (pos) + /* PME Capable - root port capability */ + if (((reg16 >> 4) & PORT_TYPE_MASK) == PCIE_RC_PORT) services |= PCIE_PORT_SERVICE_PME; pos = PCI_CFG_SPACE_SIZE; - 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] PCI: disable MSI on more ATI NorthBridges
From: "Shane Huang" <[EMAIL PROTECTED]> Date: Tue, 23 Oct 2007 18:56:03 +0800 > Also I wonder why the USB MSI patch is not added into kernel at last? > Will it lead to other bugs? Probably someone just needs to be more vocal and active in pushing it to the USB subsystem maintainer(s). I've even had trouble getting even simple bug fixes integrated recently, so perhaps it will take a few retransmits and some patience to get it included. Anyways, thanks for bringing it to our attention. Greg, can you at least devote a few minutes to going over that USB MSI patch, giving it any obvious things it needs (perhaps some pci_msi_enable() return value checks, for example, but may not be needed at all in this case) and then stash it somewhere so it doesn't get lost in the void? 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: How do I get my aic94xx to see sata drives?
Wakko Warner wrote: Please CC me. Please don't use Mail-Followup-To: linux-kernel@vger.kernel.org in your emails then :) I've looked around and the only thing I can find was a git repository for it. I don't know anything about git. I just want to get the driver so I can use the sata drives I have on this controller. I'm currently using 2.6.22. hum, it should be working in 2.6.22. There were some minor fixes and changes in 2.6.23 that you might want to try, but overall, we are interested in your bug report. 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/
How do I get my aic94xx to see sata drives?
Please CC me. I've looked around and the only thing I can find was a git repository for it. I don't know anything about git. I just want to get the driver so I can use the sata drives I have on this controller. I'm currently using 2.6.22. -- Lab tests show that use of micro$oft causes cancer in lab animals Got Gas??? - 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 1/4] stringbuf: A string buffer implementation
On Tue, Oct 23, 2007 at 10:19:06PM -0400, Eric St-Laurent wrote: > I don't know if copy-on-write semantics are really useful for current > in-kernel uses, but I've coded and used a C++ string class like this in > the past: CoW isn't in the slightest bit helpful. The point of these is to provide an accumulator, therefore the majority of accesses to these stringbufs are writes. > Multiple string objects can share the same data, by increasing the nrefs > count, a new data is allocated if the string is modified and nrefs > 1. If we were trying to get rid of char * throughout the kernel, that might make some sense; stringbufs have a more limited target though. > Even without copy-on-write semantics and reference counting, I think > this approach is better because it uses 1 less "object" and allocation: > > struct string - "handle" (pointer really) to string data > struct string_data - string data > > versus: > > struct stringbuf *sb - pointer to string object > struct stringbuf - string object > char *s (member of stringbuf) - string data I think you missed the part of the patch where I said that the stringbuf is normally allocated on the stack or as part of some other structure. The only thing that should be allocated is the string itself. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - 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 1/2] CFS CGroup: Code cleanup
Clean up some CFS CGroup code
- replace "cont" with "cgrp" in a few places in the CFS cgroup code,
- use write_uint rather than write for cpu.shares write function
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
This is a resend of yesterday's mail with the same subject; the final hunk was
missing from yesterday's patch. The second patch in the series was unaffected
by this.
kernel/sched.c | 53 ++---
1 file changed, 18 insertions(+), 35 deletions(-)
Index: container-2.6.23-mm1/kernel/sched.c
===
--- container-2.6.23-mm1.orig/kernel/sched.c
+++ container-2.6.23-mm1/kernel/sched.c
@@ -6936,25 +6936,25 @@ unsigned long sched_group_shares(struct
#ifdef CONFIG_FAIR_CGROUP_SCHED
/* return corresponding task_group object of a cgroup */
-static inline struct task_group *cgroup_tg(struct cgroup *cont)
+static inline struct task_group *cgroup_tg(struct cgroup *cgrp)
{
- return container_of(cgroup_subsys_state(cont, cpu_cgroup_subsys_id),
-struct task_group, css);
+ return container_of(cgroup_subsys_state(cgrp, cpu_cgroup_subsys_id),
+ struct task_group, css);
}
static struct cgroup_subsys_state *
-cpu_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont)
+cpu_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cgrp)
{
struct task_group *tg;
- if (!cont->parent) {
+ if (!cgrp->parent) {
/* This is early initialization for the top cgroup */
- init_task_group.css.cgroup = cont;
+ init_task_group.css.cgroup = cgrp;
return &init_task_group.css;
}
/* we support only 1-level deep hierarchical scheduler atm */
- if (cont->parent->parent)
+ if (cgrp->parent->parent)
return ERR_PTR(-EINVAL);
tg = sched_create_group();
@@ -6962,21 +6962,21 @@ cpu_cgroup_create(struct cgroup_subsys *
return ERR_PTR(-ENOMEM);
/* Bind the cgroup to task_group object we just created */
- tg->css.cgroup = cont;
+ tg->css.cgroup = cgrp;
return &tg->css;
}
static void cpu_cgroup_destroy(struct cgroup_subsys *ss,
- struct cgroup *cont)
+ struct cgroup *cgrp)
{
- struct task_group *tg = cgroup_tg(cont);
+ struct task_group *tg = cgroup_tg(cgrp);
sched_destroy_group(tg);
}
static int cpu_cgroup_can_attach(struct cgroup_subsys *ss,
-struct cgroup *cont, struct task_struct *tsk)
+struct cgroup *cgrp, struct task_struct *tsk)
{
/* We don't support RT-tasks being in separate groups */
if (tsk->sched_class != &fair_sched_class)
@@ -6986,38 +6986,21 @@ static int cpu_cgroup_can_attach(struct
}
static void
-cpu_cgroup_attach(struct cgroup_subsys *ss, struct cgroup *cont,
+cpu_cgroup_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
struct cgroup *old_cont, struct task_struct *tsk)
{
sched_move_task(tsk);
}
-static ssize_t cpu_shares_write(struct cgroup *cont, struct cftype *cftype,
- struct file *file, const char __user *userbuf,
- size_t nbytes, loff_t *ppos)
+static int cpu_shares_write_uint(struct cgroup *cgrp, struct cftype *cftype,
+ u64 shareval)
{
- unsigned long shareval;
- struct task_group *tg = cgroup_tg(cont);
- char buffer[2*sizeof(unsigned long) + 1];
- int rc;
-
- if (nbytes > 2*sizeof(unsigned long))/* safety check */
- return -E2BIG;
-
- if (copy_from_user(buffer, userbuf, nbytes))
- return -EFAULT;
-
- buffer[nbytes] = 0; /* nul-terminate */
- shareval = simple_strtoul(buffer, NULL, 10);
-
- rc = sched_group_set_shares(tg, shareval);
-
- return (rc < 0 ? rc : nbytes);
+ return sched_group_set_shares(cgroup_tg(cgrp), shareval);
}
-static u64 cpu_shares_read_uint(struct cgroup *cont, struct cftype *cft)
+static u64 cpu_shares_read_uint(struct cgroup *cgrp, struct cftype *cft)
{
- struct task_group *tg = cgroup_tg(cont);
+ struct task_group *tg = cgroup_tg(cgrp);
return (u64) tg->shares;
}
@@ -7025,7 +7008,7 @@ static u64 cpu_shares_read_uint(struct c
static struct cftype cpu_shares = {
.name = "shares",
.read_uint = cpu_shares_read_uint,
- .write = cpu_shares_write,
+ .write_uint = cpu_shares_write_uint,
};
static int cpu_cgroup_populate(struct cgroup_subsys *ss, struct cgroup *cont)
-
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/
Re: [PATCH] watchdog: add Nano 7240 driver
On Wed, 24 Oct 2007 12:11:59 +1000 Gilles Gigan <[EMAIL PROTECTED]> wrote:
> + case WDIOC_SETOPTIONS:{
> + int retval = -EINVAL;
> +
> + if (arg & WDIOS_DISABLECARD) {
> + wdt_disable();
> + retval = 0;
> + }
> +
> + if (arg & WDIOS_ENABLECARD) {
> + wdt_enable();
> + retval = 0;
> + }
> +
> + return retval;
hrm. So if userspace does ioctl(..., WDIOS_DISABLECARD|WDIOS_ENABLECARD,
that happens to be equivalent to WDIOS_ENABLECARD?
Do all watchdog drivers do it exactly the same way, or are we offering
inconsistent interfaces between different drivers?
An exceedingly minor point, but fun nonetheless.
(And hey, I had to say _something_)
(apart from directing your attention to scripts/checkpatch.pl)
-
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 1/4] stringbuf: A string buffer implementation
On Tue, Oct 23, 2007 at 04:43:53PM -0700, Linus Torvalds wrote: > On Tue, 23 Oct 2007, Matthew Wilcox wrote: > > This is a generic string buffer which can also be used for non-printk > > purposes. There is no sb_scanf implementation yet as I haven't identified > > a user for it. > > Hmm. Have you looked at the git "strbuf" code? I hadn't. It's quite spookily similar in some ways. There's a lot of things you've added because you presumably have use for them in git that could easily be added once we had users for them in the kernel. There's a few things stringbufs do that strbufs don't need to because they're in userspace. I can easily change the API at this point, so if renaming things will make you happier, just say so. > And stuff like "sb_string()" are just evil. The string is there. Just call > it something better than "s", and let people just use "sb->buf" or > something. Why make the interface harder to use than necessary? It's a matter of taste ... some people prefer to use accessors for everything, other people prefer to expose the underlying structure directly. I have to confess to being influenced by Java in 1998-99, so possibly I tend to go for accessors too often. Or possibly it's just my experience of restructuring things in Linux where diffs would be smaller if we only had used accessors for something. In any case, I don't care to fight about this; if you want it to be called buf, then buf it shall be called, and I'll get rid of sb_string. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - 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 2/2] CFS CGroup: Report usage
On 10/23/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote: > > Suppose you have two cgroups that would each want to use, say, 55% of > > a CPU - technically they should each be regarded as having 45% idle > > time, but if they run on a the same CPU the chances are that they will > > both always have some processes on their runqueue due to contention > > with the other group. So how would you measure the difference between > > this and a cgroup that really is trying to use 100%? > > Good point. I think we need to subtract out the time it was waiting on > runqueue > when calculating idle time. > > |--- . . . . . . -...---| > t0 t1t2 t3 t4 t5 t6 > > > -> Running time > -> Waiting time (to get on the cpu) > -> Sleeping time (when it didnt want to run because of >lack of tasks) > > So, in this case, > > idle time = (t4 - t3) / [ (t6 - t1) - (t2-t1) - (t5-t4) > Do you mean (t6 - t0) where you have (t6 - t1)? > ? > > This idle time will be a per-cpu stat for every cgroup and needs to be > consolidated across cpus into a single idle-stat number, just like how > top does it. This would be an idle fraction, not an idle time. (seconds divided by seconds) It doesn't seem quite right to me that a cgroup's idle time metric be affected by the activity of other cgroups on the machine, but it's hard to come up with a way of measuring it that doesn't have this behaviour - which is why, in the absence of hard CPU partitioning, it's not clear to me how much use this would be. What would people be planning to use it for? Paul - 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/
nmi loop in 2.6.23-g0895e91d with nmi watchdog = 1
FYI -- i had an unknown NMI loop once while booting a recent git kernel on a core2 system with nmi_watchdog=1. Unfortunately I couldn't reproduce it later; so it's likely some race. This is the first time this happened so I presume it's a new problem. -Andi Console: colour VGA+ 80x60 console [tty0] enabled Linux version 2.6.23-g0895e91d ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #2 SMP Tue Oct 23 22:51:10 CEST 2007 Command line: ip=dhcp nfsroot=:/home/nfsroot/gaston root=/dev/nfs debug vga=0x0f07 rw pci=noacpi earlyprintk=serial,ttyS0,115200 kst ack=512 console=tty0 console=ttyS0,115200 earlyprintk=serial,ttyS0,115200 nmi_watchdog=1 BOOT_IMAGE=bzImage BIOS-provided physical RAM map: ... ACPI: PM-Timer IO Port: 0x408 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1]) ACPI: HPET id: 0x8086a201 base: 0xfed0 Using ACPI for processor (LAPIC) configuration information Intel MultiProcessor Specification v1.4 MPTABLE: OEM ID: MPTABLE: Product ID: MPTABLE: APIC at: 0xFEE0 Setting APIC routing to flat BIOS bug, no explicit IRQ entries, using default mptable. (tell your hw vendor) Processors: 2 ... Memory: 2034512k/2071552k available (3433k kernel code, 35572k reserved, 1958k data, 332k init) Calibrating delay using timer specific routine.. 4803.42 BogoMIPS (lpj=9606841) Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Mount-cache hash table entries: 256 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 4096K CPU 0/0 -> Node 0 using mwait in idle threads. CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 CPU0: Thermal monitoring enabled (TM2) SMP alternatives: switching to UP code ACPI: Core revision 20070126 Using local APIC timer interrupts. APIC timer calibration result 16667236 Detected 16.667 MHz APIC timer. APIC timer registered as dummy, due to nmi_watchdog=1! SMP alternatives: switching to SMP code Booting processor 1/2 APIC 0x1 Initializing CPU#1 Calibrating delay using timer specific routine.. 4800.16 BogoMIPS (lpj=9600338) CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 4096K CPU 1/1 -> Node 0 CPU: Physical Processor ID: 0 CPU: Processor Core ID: 1 CPU1: Thermal monitoring enabled (TM2) Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping 06 checking TSC synchronization [CPU#0 -> CPU#1]: passed. Brought up 2 CPUs testing NMI watchdog ... CPU#0: NMI appears to be stuck (0->0)! OK. net_namespace: 120 bytes NET: Registered protocol family 16 ACPI: bus type pci registered PCI: BIOS Bug: MCFG area at f000 is not E820-reserved PCI: Not using MMCONFIG. PCI: Using configuration type 1 ACPI: EC: Look up EC in DSDT ACPI: Interpreter enabled Uhhuh. NMI received for unknown reason 2d. Do you have a strange power saving mode enabled? Dazed and confused, but trying to continue Uhhuh. NMI received for unknown reason 3d. Do you have a strange power saving mode enabled? Dazed and confused, but trying to continue Uhhuh. NMI received for unknown reason 3d. Do you have a strange power saving mode enabled? Dazed and confused, but trying to continue Uhhuh. NMI received for unknown reason 2d. Do you have a strange power saving mode enabled? Dazed and confused, but trying to continue ... messages continue forever ... -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: [PATCH] e1000, e1000e valid-addr fixes
From: Jeff Garzik <[EMAIL PROTECTED]> Date: Tue, 23 Oct 2007 22:20:30 -0400 > David Miller wrote: > > From: Jeff Garzik <[EMAIL PROTECTED]> > > Date: Tue, 23 Oct 2007 21:03:36 -0400 > > > >> I'm wondering if there is a way to avoid adding > >> > >>if (!is_valid_ether_addr(dev->dev_addr)) > >>return -EINVAL; > >> > >> to every ethernet driver's ->open() hook. > > > > The first idea I get is: > > > > 1) Create netdev->validate_dev_addr(). > > > > 2) If it exists, invoke it before ->open(), abort > >and return if any errors signaled. > > > > etherdev init hooks up a function that does the above > > check, which allows us to avoid editing every ethernet > > driver > > > > What do you think? > > Seems sane to me. Something like this (attached)? Looks great: Acked-by: David S. Miller <[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] e1000, e1000e valid-addr fixes
David Miller wrote:
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Tue, 23 Oct 2007 21:03:36 -0400
I'm wondering if there is a way to avoid adding
if (!is_valid_ether_addr(dev->dev_addr))
return -EINVAL;
to every ethernet driver's ->open() hook.
The first idea I get is:
1) Create netdev->validate_dev_addr().
2) If it exists, invoke it before ->open(), abort
and return if any errors signaled.
etherdev init hooks up a function that does the above
check, which allows us to avoid editing every ethernet
driver
What do you think?
Seems sane to me. Something like this (attached)?
Jeff
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 4a3f54e..962d1de 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -669,6 +669,8 @@ struct net_device
#define HAVE_SET_MAC_ADDR
int (*set_mac_address)(struct net_device *dev,
void *addr);
+#define HAVE_VALIDATE_ADDR
+ int (*validate_addr)(struct net_device *dev);
#define HAVE_PRIVATE_IOCTL
int (*do_ioctl)(struct net_device *dev,
struct ifreq *ifr, int cmd);
diff --git a/net/core/dev.c b/net/core/dev.c
index 8726589..f861555 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1007,17 +1007,20 @@ int dev_open(struct net_device *dev)
* Call device private open method
*/
set_bit(__LINK_STATE_START, &dev->state);
- if (dev->open) {
+
+ if (dev->validate_addr)
+ ret = dev->validate_addr(dev);
+
+ if (!ret && dev->open)
ret = dev->open(dev);
- if (ret)
- clear_bit(__LINK_STATE_START, &dev->state);
- }
/*
* If it went open OK then:
*/
- if (!ret) {
+ if (ret)
+ clear_bit(__LINK_STATE_START, &dev->state);
+ else {
/*
* Set the flags.
*/
@@ -1038,6 +1041,7 @@ int dev_open(struct net_device *dev)
*/
call_netdevice_notifiers(NETDEV_UP, dev);
}
+
return ret;
}
diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index ed8a3d4..5471cd2 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -298,6 +298,14 @@ static int eth_change_mtu(struct net_device *dev, int
new_mtu)
return 0;
}
+static int eth_validate_addr(struct net_device *dev)
+{
+ if (!is_valid_ether_addr(dev->dev_addr))
+ return -EINVAL;
+
+ return 0;
+}
+
const struct header_ops eth_header_ops cacheline_aligned = {
.create = eth_header,
.parse = eth_header_parse,
@@ -317,6 +325,7 @@ void ether_setup(struct net_device *dev)
dev->change_mtu = eth_change_mtu;
dev->set_mac_address= eth_mac_addr;
+ dev->validate_addr = eth_validate_addr;
dev->type = ARPHRD_ETHER;
dev->hard_header_len= ETH_HLEN;
Re: [PATCH 1/4] stringbuf: A string buffer implementation
On Tue, 2007-10-23 at 17:12 -0400, Matthew Wilcox wrote:
> Consecutive calls to printk are non-atomic, which leads to various
> implementations for accumulating strings which can be printed in one call.
> This is a generic string buffer which can also be used for non-printk
> purposes. There is no sb_scanf implementation yet as I haven't identified
> a user for it.
>
> +
> +struct stringbuf {
> + char *s;
> + int alloc;
> + int len;
> +};
> +
I don't know if copy-on-write semantics are really useful for current
in-kernel uses, but I've coded and used a C++ string class like this in
the past:
struct string_data
{
int nrefs;
unsigned len;
unsigned capacity;
//char data[capacity]; /* allocated along string_data */
};
struct string /* or typedef in C... */
{
struct string *data;
};
[ struct string_data is a hidden implementation detail, only struct
string is exposed ]
Multiple string objects can share the same data, by increasing the nrefs
count, a new data is allocated if the string is modified and nrefs > 1.
Not having to iterate over the string to calculate it's length,
allocating a larger buffer to eliminate re-allocation and copy-on-write
semantics make a string like this a vast performance improvement over a
normal C string for a minimal (about 3 ints per data buffer) memory
cost.
By using it correctly it can prevents buffer overflows.
You still always null terminate the string stored in data to directly
use it a normal C string.
You also statically allocate an empty string which is shared by all
"uninitialized" or empty strings.
Even without copy-on-write semantics and reference counting, I think
this approach is better because it uses 1 less "object" and allocation:
struct string - "handle" (pointer really) to string data
struct string_data - string data
versus:
struct stringbuf *sb - pointer to string object
struct stringbuf - string object
char *s (member of stringbuf) - string data
Best regards,
- Eric
-
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 -v2] x86 boot: document for 32 bit boot protocol
This patch documents the 32-bit boot protocol of x86. It has been used by Kexec and LinuxBIOS. This patch is based on the proposal of Peter Anvin. Signed-off-by: Huang Ying <[EMAIL PROTECTED]> v2: - Fixes a bug about which registers should be set to zero. --- boot.txt | 38 zero-page.txt | 130 +- 2 files changed, 69 insertions(+), 99 deletions(-) Index: linux-2.6/Documentation/i386/boot.txt === --- linux-2.6.orig/Documentation/i386/boot.txt 2007-10-24 09:21:57.0 +0800 +++ linux-2.6/Documentation/i386/boot.txt 2007-10-24 10:01:42.0 +0800 @@ -785,3 +785,41 @@ After completing your hook, you should jump to the address that was in this field before your boot loader overwrote it (relocated, if appropriate.) + + + 32-bit BOOT PROTOCOL + +For machine with some new BIOS other than legacy BIOS, such as EFI, +LinuxBIOS, etc, and kexec, the 16-bit real mode setup code in kernel +based on legacy BIOS can not be used, so a 32-bit boot protocol needs +to be defined. + +In 32-bit boot protocol, the first step in loading a Linux kernel +should be to setup the boot parameters (struct boot_params, +traditionally known as "zero page"). The memory for struct boot_params +should be allocated and initialized to all zero. Then the setup header +from offset 0x01f1 of kernel image on should be loaded into struct +boot_params and examined. The end of setup header can be calculated as +follow: + + 0x0202 + byte value at offset 0x0201 + +In addition to read/modify/write the setup header of the struct +boot_params as that of 16-bit boot protocol, the boot loader should +also fill the additional fields of the struct boot_params as that +described in zero-page.txt. + +After setupping the struct boot_params, the boot loader can load the +32/64-bit kernel in the same way as that of 16-bit boot protocol. + +In 32-bit boot protocol, the kernel is started by jumping to the +32-bit kernel entry point, which is the start address of loaded +32/64-bit kernel. + +At entry, the CPU must be in 32-bit protected mode with paging +disabled; a GDT must be loaded with the descriptors for selectors +__BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat +segment; __BOOS_CS must have execute/read permission, and __BOOT_DS +must have read/write permission; CS must be __BOOT_CS and DS, ES, SS +must be __BOOT_DS; interrupt must be disabled; %esi must hold the base +address of the struct boot_params; %ebp, %edi and %ebx must be zero. Index: linux-2.6/Documentation/i386/zero-page.txt === --- linux-2.6.orig/Documentation/i386/zero-page.txt 2007-10-24 09:21:57.0 +0800 +++ linux-2.6/Documentation/i386/zero-page.txt 2007-10-24 09:31:52.0 +0800 @@ -1,99 +1,31 @@ -!!!WARNING -The zero page is a kernel internal data structure, not a stable ABI. It might change -without warning and the kernel has no way to detect old version of it. -If you're writing some external code like a boot loader you should only use -the stable versioned real mode boot protocol described in boot.txt. Otherwise the kernel -might break you at any time. -!WARNING!!! - - -Summary of boot_params layout (kernel point of view) - ( collected by Hans Lermen and Martin Mares ) - -The contents of boot_params are used to pass parameters from the -16-bit realmode code of the kernel to the 32-bit part. References/settings -to it mainly are in: - - arch/i386/boot/setup.S - arch/i386/boot/video.S - arch/i386/kernel/head.S - arch/i386/kernel/setup.c - - -Offset TypeDescription --- --- -0 32 bytesstruct screen_info, SCREEN_INFO - ATTENTION, overlaps the following !!! -2 unsigned short EXT_MEM_K, extended memory size in Kb (from int 0x15) - 0x20 unsigned short CL_MAGIC, commandline magic number (=0xA33F) - 0x22 unsigned short CL_OFFSET, commandline offset - Address of commandline is calculated: - 0x9 + contents of CL_OFFSET - (only taken, when CL_MAGIC = 0xA33F) - 0x40 20 bytesstruct apm_bios_info, APM_BIOS_INFO - 0x60 16 bytesIntel SpeedStep (IST) BIOS support information - 0x80 16 byteshd0-disk-parameter from intvector 0x41 - 0x90 16 byteshd1-disk-parameter from intvector 0x46 - - 0xa0 16 bytesSystem description table truncated to 16 bytes. - ( struct sys_desc_table_struct ) - 0xb0 - 0x13f Free. Add more parameters here if you really need them. - 0x140- 0x1be E
Re: [PATCH 1/2] irq_flags_t: intro and core annotations
Herbert Xu wrote: Jeff Garzik <[EMAIL PROTECTED]> wrote: Let me add to the chorus of voices: I continually see two cases where real bugs crop up: 1) hacker uses spin_lock_irq() in incorrect context (where it is not safe to do a blind enable/disable) 2) hacker uses spin_lock_irq() correctly, but the surrounding code changes, thus invalidating prior assumptions. I would even go so far as to support the drastic measure of deleting spin_lock_irq(). spin_lock_irqsave() generates fewer bugs, is more future-proof, and by virtue of 'flags' permits architectures a bit more flexibility. Could we add a debug option that warned if spin_lock_irq is executed with IRQs turned off already? Seems reasonable but perhaps arch-specific? Also, I think someone (akpm?) mentioned an effort had been made before, and run into some problems. I don't have details... 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/
[PATCH] watchdog: add Nano 7240 driver
From: Gilles Gigan<[EMAIL PROTECTED]>
Adds support for the built-in watchdog on EPIC Nano 7240 boards from IEI.
Tested on Nano-7240RS.
Hardware documentation of the platform (including watchdog) can be found
on the IEI website: http://www.ieiworld.com
Signed-off-by: Gilles Gigan <[EMAIL PROTECTED]>
---
drivers/char/watchdog/sbc7240_wdt.c | 303 +++
drivers/watchdog/Kconfig| 13 ++
drivers/watchdog/Makefile |1
3 files changed, 317 insertions(+), 0 deletions(-)
diff --git a/drivers/char/watchdog/sbc7240_wdt.c
b/drivers/char/watchdog/sbc7240_wdt.c
new file mode 100644
index 000..9f065e1
--- /dev/null
+++ b/drivers/char/watchdog/sbc7240_wdt.c
@@ -0,0 +1,303 @@
+/*
+ * NANO7240 SBC Watchdog device driver
+ *
+ * Based on w83877f.c by Scott Jennings,
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation;
+ *
+ * Software distributed under the License is distributed on an "AS IS"
+ * basis, WITHOUT WARRANTY OF ANY KIND, either express or
+ * implied. See the License for the specific language governing
+ * rights and limitations under the License.
+ *
+ * (c) Copyright 2007 Gilles GIGAN <[EMAIL PROTECTED]>
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SBC7240_PREFIX "sbc7240_wdt: "
+
+#define SBC7240_ENABLE_PORT0x443
+#define SBC7240_DISABLE_PORT 0x043
+#define SBC7240_SET_TIMEOUT_PORT SBC7240_ENABLE_PORT
+#define SBC7240_MAGIC_CHAR 'V'
+
+#define SBC7240_TIMEOUT30
+#define SBC7240_MAX_TIMEOUT255
+static int timeout = SBC7240_TIMEOUT; /* in seconds */
+module_param(timeout, int, 0);
+MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds. (1<=timeout<="
+ __MODULE_STRING(SBC7240_MAX_TIMEOUT) ", default="
+ __MODULE_STRING(SBC7240_TIMEOUT) ")");
+
+static int nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, int, 0);
+MODULE_PARM_DESC(nowayout, "Disable watchdog when closing device file");
+
+#define OPEN_STATUS_BIT0
+#define ENABLED_STATUS_BIT 1
+static unsigned long wdt_status;
+
+/*
+ * Utility routines
+ */
+
+static void wdt_disable(void)
+{
+ /* disable the watchdog */
+ if (test_and_clear_bit(ENABLED_STATUS_BIT, &wdt_status)) {
+ inb_p(SBC7240_DISABLE_PORT);
+ printk(KERN_INFO SBC7240_PREFIX
+ "Watchdog timer is now disabled.\n");
+ }
+}
+
+static void wdt_enable(void)
+{
+ /* enable the watchdog */
+ if (!test_and_set_bit(ENABLED_STATUS_BIT, &wdt_status)) {
+ inb_p(SBC7240_ENABLE_PORT);
+ printk(KERN_INFO SBC7240_PREFIX
+ "Watchdog timer is now enabled.\n");
+ }
+}
+
+static int wdt_set_timeout(int t)
+{
+ if (t < 1 || t > SBC7240_MAX_TIMEOUT) {
+ printk(KERN_ERR SBC7240_PREFIX
+ "timeout value must be 1<=x<=%d\n",
+ SBC7240_MAX_TIMEOUT);
+ return -1;
+ }
+ /* set the timeout */
+ outb_p((unsigned)t, SBC7240_SET_TIMEOUT_PORT);
+ printk(KERN_INFO SBC7240_PREFIX "timeout set to %d seconds\n", t);
+ return 0;
+}
+
+/* Whack the dog */
+static inline void wdt_keepalive(void)
+{
+ if (test_bit(ENABLED_STATUS_BIT, &wdt_status))
+ inb_p(SBC7240_ENABLE_PORT);
+}
+
+/*
+ * /dev/watchdog handling
+ */
+static ssize_t fop_write(struct file *file, const char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ size_t i;
+ char c;
+ int got_magic_char = 0;
+
+ /* is there a magic char ? */
+ for (i = 0; i != count; i++) {
+ if (get_user(c, buf + i))
+ return -EFAULT;
+ if (c == SBC7240_MAGIC_CHAR) {
+ got_magic_char = 1;
+ break;
+ }
+ }
+
+ if (got_magic_char)
+ wdt_disable();
+ else
+ wdt_keepalive();
+
+ return count;
+}
+
+static int fop_open(struct inode *inode, struct file *file)
+{
+ if (test_and_set_bit(OPEN_STATUS_BIT, &wdt_status))
+ return -EBUSY;
+
+ return nonseekable_open(inode, file);
+}
+
+static int fop_close(struct inode *inode, struct file *file)
+{
+ if (!nowayout)
+ wdt_disable();
+
+ clear_bit(OPEN_STATUS_BIT, &wdt_status);
+ return 0;
+}
+
+static struct watchdog_info ident = {
+ .options = WDIOF_KEEPALIVEPING |WDIOF_SETTIMEOUT |
+ WDIOF_MAGICCLOSE,
+ .firmware_version = 1,
+ .identity = "SBC7240",
+};
+
+
+static int fop_ioct
