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 developi
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.
Fixe
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
117636092a87a28a01
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
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 vo
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 t
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
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
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, becaus
* 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
> >
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 al
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:
> >> > > F
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_p
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;
>
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
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://vge
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 pa
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-x8
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
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_cgrou
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
---
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 secon
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 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 e
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/Doc
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 th
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++)
-
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
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 o
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 patc
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
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 indi
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
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, t
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 c
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 fi
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.
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
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.
>
>
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 be
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 '
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_VEND
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
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 (sin
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
us
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,
> +
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
>
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, bu
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
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 :
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
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
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 i
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 las
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 eliminat
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 Leve
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/ker
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 insi
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 matc
>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
driv
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 <
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.
-
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 c
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
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 u
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.
>
> R
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
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
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
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 rep
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
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 ()
T
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.
>
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 801199ce805a2412
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
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 Ti
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 defau
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 |
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 k
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
>
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: linu
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
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 mul
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
yo
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_
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
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 s
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
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 a
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 wa
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
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
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 hav
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 [
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))
> >>
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:
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 n
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 ++
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
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 PROTEC
1 - 100 of 553 matches
Mail list logo
