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
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
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
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:
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
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
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
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
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>]
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,
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
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
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
>
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
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);
> >
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>¨
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
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
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,
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
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
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
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
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
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
> ---
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
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
>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
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
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
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
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.
>
>
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
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
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
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
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 ()
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
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
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
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
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:
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
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
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
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:
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
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
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
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
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
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
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
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
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()
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
Add a port type definition for the Freescale UART driver ports (mcf.c).
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23-git19/include/linux/serial_core.h
linux-2.6.23-git19.hacked/include/linux/serial_core.h
--- linux-2.6.23-git19/include/linux/serial_core.h
Mark the m68knommu memory init functions as __init.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23-git19/arch/m68knommu/mm/init.c
linux-2.6.23-git19.hacked/arch/m68knommu/mm/init.c
--- linux-2.6.23-git19/arch/m68knommu/mm/init.c 2007-10-10 06:31:38.0
+1000
Create definition for DMA channels on the ColdFire 532x family.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/include/asm-m68knommu/dma.h
linux-2.6.23-uc0/include/asm-m68knommu/dma.h
--- linux-2.6.23/include/asm-m68knommu/dma.h2007-10-19 10:21:30.0
Remove old definitions of the timer function pointers.
Add definitions of the common hardware timer functions.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/include/asm-m68knommu/machdep.h
linux-2.6.23-uc0/include/asm-m68knommu/machdep.h
---
Add platform support structure for use with new ColdFire UART driver.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/include/asm-m68knommu/mcfuart.h
linux-2.6.23-uc0/include/asm-m68knommu/mcfuart.h
--- linux-2.6.23/include/asm-m68knommu/mcfuart.h2007-10-19
Mark the m68knommu setup_arch() function as __init.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23-git19/arch/m68knommu/kernel/setup.c
linux-2.6.23-git19.hacked/arch/m68knommu/kernel/setup.c
--- linux-2.6.23-git19/arch/m68knommu/kernel/setup.c2007-10-24
Clean up 68EZ328 timer support code. Removed header includes not needed.
Remove use of old m68knommu timer function pointers.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/arch/m68knommu/platform/68EZ328/config.c
Removed header includes not needed.
Remove use of old m68knommu timer function pointers.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/arch/m68knommu/platform/68VZ328/config.c
linux-2.6.23-uc0/arch/m68knommu/platform/68VZ328/config.c
---
Clean up 68360 timer support code. Removed header includes not needed.
Remove use of old m68knommu timer function pointers. Use common function
naming for 68328 timer functions.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/arch/m68knommu/platform/68360/config.c
Use common function naming for 68328 timer functions to make them
consistent with the various other hardware m68knommu timers.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/arch/m68knommu/platform/68328/timers.c
Remove unused variables from setup.c code.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/arch/m68knommu/kernel/setup.c
linux-2.6.23-uc0/arch/m68knommu/kernel/setup.c
--- linux-2.6.23/arch/m68knommu/kernel/setup.c 2007-10-19 10:30:54.0
+1000
+++
Clean up 68328 timer support code. Removed header includes not needed.
Remove use of old m68knommu timer function pointers.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/arch/m68knommu/platform/68328/config.c
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
Huang, Ying wrote:
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.
+At entry, the CPU must be in 32-bit protected mode with paging
+disabled; a GDT must be loaded with the descriptors for
Two main issues fixed here are:
- An improper use of in-struct lock to protect an open count
- Use of urb status for -EINPROGRESS
Also, along the way:
- Change usb_unlink_urb to usb_kill_urb. Apparently there's no need
to use usb_unlink_urb whatsoever in this driver, and the old use of
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]>
---
boot.txt | 38
zero-page.txt | 130
On Tue, Oct 23, 2007 at 05:11:16PM -0500, Matt Mackall wrote:
> You might want to consider growing the buffer by no less than a small
> constant factor like 1.3x. This will keep things that do short concats
> in a loop from degrading to O(n^2) performance due to realloc and
> memcpy.
I looked at
On Tue, Oct 23, 2007 at 08:10:54PM +0200, Andi Kleen wrote:
> I think his goal was to get an prefix that describes the module
> uniquely. gart_* clearly does not fulfill that criteria.
>
> So basically he's replacing an
> ambigious-with-other-IOMMU-implementations prefix with an
>
The cgroup change was ack'd by the maintainer. The drivers/net/ were of
course self-ack'd.
Please pull from 'warnings' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git warnings
to receive the following updates:
drivers/net/eexpress.c |2 +-
drivers/net/ni5010.c
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ahci.c | 26 +++---
drivers/ata/ata_piix.c | 29 +++---
drivers/ata/libata-acpi.c | 16 ++--
On Tue, Oct 23, 2007 at 07:41:32PM +0200, Joerg Roedel wrote:
> This patch makes some functions and variables static in pci-gart_64.c which
> are
> not used somewhere else.
>
> Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Cheers,
Muli
--
SYSTOR
1 - 100 of 1096 matches
Mail list logo
