Re: PATCH: Fix VMI and COMPAT_VDSO for 2.6.21

Zachary Amsden wrote: VMI is broken under COMPAT_VDSO, as Xen and other non hardware assisted hypervisors will be. I have been working on a fix for this which works for older glibcs that panic when the new relocatable VDSO is used. However, I believe at this time that the fix is going to be

Re: 2.6.20-rc4-mm1: PCI=n: drivers/net/3c59x.c compile error

Hello, Randy Dunlap wrote: >> Erm, before I do that, could somebody explain what >> >> #define HAVE_PCI_REQ_REGIONS 2 >> >> accompanying their declaration is for? I have't found any references to it >> in >> the source. Should I duplicate it for CONFIG_PCI=n case (I guess not)? > > I wouldn

Re: [PATCH 1/2] NET: Multiple queue network device support

* Kok, Auke <[EMAIL PROTECTED]> 2007-02-08 16:09 > diff --git a/net/core/dev.c b/net/core/dev.c > index 455d589..42b635c 100644 > --- a/net/core/dev.c > +++ b/net/core/dev.c > @@ -1477,6 +1477,49 @@ gso: > skb->tc_verd = SET_TC_AT(skb->tc_verd,AT_EGRESS); > #endif > if (q->enqueue) { >

Re: [PATCH 2/2] e1000: Implement the new kernel API for multiqueue TX support.

* Kok, Auke <[EMAIL PROTECTED]> 2007-02-08 16:09 > > From: Peter Waskiewicz Jr. <[EMAIL PROTECTED]> > > Several newer e1000 chipsets support multiple RX and TX queues. Most > commonly, 82571's and ESB2LAN support 2 rx and 2 rx queues. > > Signed-off-by: Peter Waskiewicz Jr. <[EMAIL PROTECTED]> >

Re: 2.6.21-rc2-mm2: drivers/net/wireless/libertas/debugfs.c addr bogosity

Probably should copy me and [EMAIL PROTECTED] Other than that, this looks fine to me. I'll queue it up shortly. John On Fri, Mar 09, 2007 at 01:11:46PM +1100, Tony Breeds wrote: > On Wed, Mar 07, 2007 at 03:00:57PM -0800, Andrew Morton wrote: > > On Wed, 7 Mar 2007 23:41:16 +0100 > > Adrian Bun

Re: [PATCH 1/3] e1000: FIX: be ready for incoming irq at pci_request_irq

Auke Kok wrote: From: Auke Kok <[EMAIL PROTECTED]> DEBUG_SHIRQ code exposed that e1000 was not ready for incoming interrupts after having called pci_request_irq. This obviously requires us to finish our software setup which assigns the irq handler before we request the irq. Signed-off-by: Auke

Re: [PATCH] Allow pktgen to work with loopback devices.

Josh Triplett wrote: pktgen currently only works on network devices with type ARPHRD_ETHER. Add support for the loopback device, type ARPHRD_LOOPBACK. I've tested this on my system, using a modified pktgen.conf-1-1 with s/eth1/lo/g, and it works fine; the network device statistics confirm packe

Re: [PATCH 1/3] e1000: FIX: be ready for incoming irq at pci_request_irq

Jeff Garzik wrote: Auke Kok wrote: From: Auke Kok <[EMAIL PROTECTED]> DEBUG_SHIRQ code exposed that e1000 was not ready for incoming interrupts after having called pci_request_irq. This obviously requires us to finish our software setup which assigns the irq handler before we request the irq.

Re: 2.6.21-rc2-mm2: drivers/net/wireless/libertas/debugfs.c addr bogosity

On Fri, 9 Mar 2007 09:19:07 -0500 John W. Linville wrote: > Probably should copy me and [EMAIL PROTECTED] Other than > that, this looks fine to me. I'll queue it up shortly. > > John > > On Fri, Mar 09, 2007 at 01:11:46PM +1100, Tony Breeds wrote: > > On Wed, Mar 07, 2007 at 03:00:57PM -0800,

[git patches] net driver fixes

Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus to receive the following updates: drivers/net/3c59x.c | 28 - drivers/net/mv643xx_eth.c | 10 -- drive

Re: [PATCH 1/3] e1000: FIX: be ready for incoming irq at pci_request_irq

Kok, Auke wrote: Personally, I think this is really really needed. I'm surprised that you already didn't push this considering Andrew pulled this into -mm immediately. Since it affects a fragile area of e1000 for all [e1000] users, I much prefer to err on the side of caution. I have a histo

RE: [PATCH 1/2] NET: Multiple queue network device support

> -Original Message- > From: Thomas Graf [mailto:[EMAIL PROTECTED] > Sent: Friday, March 09, 2007 5:41 AM > To: Kok, Auke-jan H > Cc: David Miller; Garzik, Jeff; netdev@vger.kernel.org; > linux-kernel@vger.kernel.org; Waskiewicz Jr, Peter P; > Brandeburg, Jesse; Kok, Auke; Ronciak, John

netconsole system freeze when cable unplugged

When I unplug the cable the system just stops responding to anything, at all. No message is printed to the console when the cable is plugged back in. [0.00] Linux version 2.6.21-rc3 ([EMAIL PROTECTED]) (gcc version 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)) #3 SMP Fri Mar 9 18:

Re: netconsole system freeze when cable unplugged

Simon Arlott <[EMAIL PROTECTED]> : > When I unplug the cable the system just stops responding to anything, > at all. No message is printed to the console when the cable is plugged > back in. rtl8139_interrupt (spin_lock(&tp->lock)) -> rtl8139_weird_interrupt -> rtl_check_media -> mii_ch

Re: [PATCH 1/2] NET: Multiple queue network device support

* Waskiewicz Jr, Peter P <[EMAIL PROTECTED]> 2007-03-09 11:25 > > > + } > > > + } else { > > > + /* We're not a multi-queue device. */ > > > + spin_lock(&dev->queue_lock); > > > + q = dev->qdisc; > > > + if (q->

RE: [PATCH 1/2] NET: Multiple queue network device support

> * Waskiewicz Jr, Peter P <[EMAIL PROTECTED]> > 2007-03-09 11:25 > > > > + } > > > > + } else { > > > > + /* We're not a multi-queue device. */ > > > > + spin_lock(&dev->queue_lock); > > > > + q

Re: netconsole system freeze when cable unplugged

On 09/03/07 20:42, Francois Romieu wrote: Simon Arlott <[EMAIL PROTECTED]> : When I unplug the cable the system just stops responding to anything, at all. No message is printed to the console when the cable is plugged back in. rtl8139_interrupt (spin_lock(&tp->lock)) -> rtl8139_weird_interrup

Re: [PATCH 1/2] NET: Multiple queue network device support

* Waskiewicz Jr, Peter P <[EMAIL PROTECTED]> 2007-03-09 15:27 > That's the entire point of this extra locking. enqueue() is going to > put an skb into a band somewhere that maps to some queue, and there is > no way to guarantee the skb I retrieve from dequeue() is headed for the > same queue. The

Re: [3/6] 2.6.21-rc2: known regressions

Jeff Garzik a écrit : > Adrian Bunk wrote: >> Subject: NCQ problem with ahci and Hitachi drive >> References : http://lkml.org/lkml/2007/3/4/178 >> Submitter : Mathieu Bérard <[EMAIL PROTECTED]> >> Status : unknown > > according to the last message in that thread, it sounds like ACPI and >

and try remove another quirk on this computers Re: [3/6] 2.6.21-rc2: known regressions

On Sat, 2007-03-10 at 02:09 +0100, Mathieu Bérard wrote: > Jeff Garzik a écrit : > > Adrian Bunk wrote: > >> Subject: NCQ problem with ahci and Hitachi drive > >> References : http://lkml.org/lkml/2007/3/4/178 > >> Submitter : Mathieu Bérard <[EMAIL PROTECTED]> > >> Status : unknown > > >

Re: and try remove another quirk on this computers Re: [3/6] 2.6.21-rc2: known regressions

On Sat, 10 Mar 2007, Sergio Monteiro Basto wrote: > > With this quirk I got this oops on hibernate (but computer still > working) Well, strictly speaking it's a warning, not an oops per se. What happens is that the quirk wants to do an "ioremap_nocache()", which allocates memory, and that h

[RFC PATCH 0/3] Fix module information when symbol_get is used

Hi Rusty, DVB code uses symbol_get/symbol_put functions at module.c to allow dynamically add frontend modules (responsible for tuning and demodulating the digital signal). The problem is that symbol_get doesn't properly mark the module that requested it. Trent worked on a fix for this, by using 3

Re: [2/6] 2.6.21-rc2: known regressions

Hi! > > You're better off using the VGA console, and lettign X re-initialize the > > graphics device. That generally at least has a reasonably good chance of > > working. > > > > Re-initializing graphics modes really is very hard. You can try with the > > BIOS video hack (I forget the kernel c

<    1   2   3   4   5   6