* RE: process starvation with 2.6 scheduler
From: Mike Galbraith @ 2006-06-07 5:27 UTC (permalink / raw)
To: Kallol Biswas; +Cc: Stephen Hemminger, linux-kernel
In-Reply-To: <478F19F21671F04298A2116393EEC3D527431D@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca>
On Tue, 2006-06-06 at 14:58 -0700, Kallol Biswas wrote:
> Thanks for help. We do not see the issue if every netserver's priority is set to 19 with setpriority() call.
FYI, there have been changes to the scheduler since 2.6.11 days that
reduce the likelihood of this scenario somewhat.
-Mike
^ permalink raw reply
* [PATCH] http-fetch: fix possible segfault
From: Nick Hengeveld @ 2006-06-07 5:22 UTC (permalink / raw)
To: git
Initialize an object request's slot to a safe value. A non-NULL value
can cause a segfault if the request is aborted before it starts.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-fetch.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/http-fetch.c b/http-fetch.c
index 661c909..d3602b7 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -399,6 +399,7 @@ void prefetch(unsigned char *sha1)
snprintf(newreq->filename, sizeof(newreq->filename), "%s", filename);
snprintf(newreq->tmpfile, sizeof(newreq->tmpfile),
"%s.temp", filename);
+ newreq->slot = NULL;
newreq->next = NULL;
if (object_queue_head == NULL) {
--
1.4.0.rc1.gf75c7-dirty
^ permalink raw reply related
* Re: Re[2]: Socket buffer allocation outside DMA-able memory
From: ashley jones @ 2006-06-07 5:17 UTC (permalink / raw)
To: art; +Cc: linux-mips
In-Reply-To: <15450.060607@sigrand.ru>
[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]
art <art@sigrand.ru> wrote: Hello ashley,
Tuesday, June 06, 2006, 7:37:35 PM, you wrote:
aj> I guess your 25 bit dma address field will be word alligned, so ur dma engine will be able to index up to 64 MB( 25+2 = 27 bits).
Address not aligned - if I don't do anything driver work incorrect!
*** what do you mean by Address not aligned ??
*** What address you r passing to dma ? u should pass (skb->data >> 2) (if word alligned address is required for dma engine.)
aj> * dont give whole 64 MB to linux, give only Lower 32 MB.
You mean with command line kernel option? If so - I already did so to
get all work!
*** when you do add_memory_region(), give only first 32 MB to linux, so all the skbs will be in lower 32 MB range.
aj> * Give only upper 32 MB to linux, and give memory to ur dma engine from lower 32 MB, and once you recv any data you copy to skb and submit to linux. ( ofcourse your performance will get hit
aj> in this case.)
How can I do this? I have variant that if addres is upper than 32Mb then copy skbuffer to
previously allocated memory that lower than 32Mb, but perfomance is wery Important. Maybe
you mean this??
A'Jones.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[-- Attachment #2: Type: text/html, Size: 1659 bytes --]
^ permalink raw reply
* [U-Boot-Users] IXP4XX NPE Support
From: Michael Sprauve @ 2006-06-07 5:11 UTC (permalink / raw)
To: u-boot
Hello,
I am trying to use the latest build, that includes support for the Intel NPE ethenet driver. But I am getting build errors occuring in the include file IxEthDB.h. I am wondering if anyone else has attempted and been successful in using this new feature.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20060606/fde79ff4/attachment.htm
^ permalink raw reply
* Re: [PATCH 3/4] Make Intel e1000 driver legacy I/O port free
From: Auke Kok @ 2006-06-07 5:10 UTC (permalink / raw)
To: Kenji Kaneshige
Cc: Greg KH, akpm, Rajesh Shah, Grant Grundler, bibo,mao,
linux-kernel, linux-pci, netdev, Jesse Brandeburg, Ronciak, John
In-Reply-To: <448644A2.7000208@jp.fujitsu.com>
Kenji Kaneshige wrote:
> This patch makes Intel e1000 driver legacy I/O port free.
>
> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
(adding netdev and the other e1000 maintainers to cc:)
without sending this to any of the listed e1000 maintainers???? *and* not even
including netdev???
I'm going to take a look at it first, and have some other colleagues look at
this and the impact, which is unclear to me at the moment. Please don't commit
this like this.
Auke
>
> ---
> drivers/net/e1000/e1000.h | 6 +
> drivers/net/e1000/e1000_main.c | 130 ++++++++++++++++++++++-------------------
> 2 files changed, 75 insertions(+), 61 deletions(-)
>
> Index: linux-2.6.17-rc6/drivers/net/e1000/e1000.h
> ===================================================================
> --- linux-2.6.17-rc6.orig/drivers/net/e1000/e1000.h 2006-06-06 21:39:11.000000000 +0900
> +++ linux-2.6.17-rc6/drivers/net/e1000/e1000.h 2006-06-06 21:56:41.000000000 +0900
> @@ -77,8 +77,9 @@
> #define BAR_1 1
> #define BAR_5 5
>
> -#define INTEL_E1000_ETHERNET_DEVICE(device_id) {\
> - PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id)}
> +#define E1000_NO_IOPORT (1 << 0)
> +#define INTEL_E1000_ETHERNET_DEVICE(device_id, flags) {\
> + PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id), .driver_data = flags}
>
> struct e1000_adapter;
>
> @@ -338,6 +339,7 @@
> #ifdef NETIF_F_TSO
> boolean_t tso_force;
> #endif
> + int bars; /* BARs to be enabled */
> };
>
>
> Index: linux-2.6.17-rc6/drivers/net/e1000/e1000_main.c
> ===================================================================
> --- linux-2.6.17-rc6.orig/drivers/net/e1000/e1000_main.c 2006-06-06 21:39:11.000000000 +0900
> +++ linux-2.6.17-rc6/drivers/net/e1000/e1000_main.c 2006-06-06 21:56:41.000000000 +0900
> @@ -86,54 +86,54 @@
> * {PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id)}
> */
> static struct pci_device_id e1000_pci_tbl[] = {
> - INTEL_E1000_ETHERNET_DEVICE(0x1000),
> - INTEL_E1000_ETHERNET_DEVICE(0x1001),
> - INTEL_E1000_ETHERNET_DEVICE(0x1004),
> - INTEL_E1000_ETHERNET_DEVICE(0x1008),
> - INTEL_E1000_ETHERNET_DEVICE(0x1009),
> - INTEL_E1000_ETHERNET_DEVICE(0x100C),
> - INTEL_E1000_ETHERNET_DEVICE(0x100D),
> - INTEL_E1000_ETHERNET_DEVICE(0x100E),
> - INTEL_E1000_ETHERNET_DEVICE(0x100F),
> - INTEL_E1000_ETHERNET_DEVICE(0x1010),
> - INTEL_E1000_ETHERNET_DEVICE(0x1011),
> - INTEL_E1000_ETHERNET_DEVICE(0x1012),
> - INTEL_E1000_ETHERNET_DEVICE(0x1013),
> - INTEL_E1000_ETHERNET_DEVICE(0x1014),
> - INTEL_E1000_ETHERNET_DEVICE(0x1015),
> - INTEL_E1000_ETHERNET_DEVICE(0x1016),
> - INTEL_E1000_ETHERNET_DEVICE(0x1017),
> - INTEL_E1000_ETHERNET_DEVICE(0x1018),
> - INTEL_E1000_ETHERNET_DEVICE(0x1019),
> - INTEL_E1000_ETHERNET_DEVICE(0x101A),
> - INTEL_E1000_ETHERNET_DEVICE(0x101D),
> - INTEL_E1000_ETHERNET_DEVICE(0x101E),
> - INTEL_E1000_ETHERNET_DEVICE(0x1026),
> - INTEL_E1000_ETHERNET_DEVICE(0x1027),
> - INTEL_E1000_ETHERNET_DEVICE(0x1028),
> - INTEL_E1000_ETHERNET_DEVICE(0x105E),
> - INTEL_E1000_ETHERNET_DEVICE(0x105F),
> - INTEL_E1000_ETHERNET_DEVICE(0x1060),
> - INTEL_E1000_ETHERNET_DEVICE(0x1075),
> - INTEL_E1000_ETHERNET_DEVICE(0x1076),
> - INTEL_E1000_ETHERNET_DEVICE(0x1077),
> - INTEL_E1000_ETHERNET_DEVICE(0x1078),
> - INTEL_E1000_ETHERNET_DEVICE(0x1079),
> - INTEL_E1000_ETHERNET_DEVICE(0x107A),
> - INTEL_E1000_ETHERNET_DEVICE(0x107B),
> - INTEL_E1000_ETHERNET_DEVICE(0x107C),
> - INTEL_E1000_ETHERNET_DEVICE(0x107D),
> - INTEL_E1000_ETHERNET_DEVICE(0x107E),
> - INTEL_E1000_ETHERNET_DEVICE(0x107F),
> - INTEL_E1000_ETHERNET_DEVICE(0x108A),
> - INTEL_E1000_ETHERNET_DEVICE(0x108B),
> - INTEL_E1000_ETHERNET_DEVICE(0x108C),
> - INTEL_E1000_ETHERNET_DEVICE(0x1096),
> - INTEL_E1000_ETHERNET_DEVICE(0x1098),
> - INTEL_E1000_ETHERNET_DEVICE(0x1099),
> - INTEL_E1000_ETHERNET_DEVICE(0x109A),
> - INTEL_E1000_ETHERNET_DEVICE(0x10B5),
> - INTEL_E1000_ETHERNET_DEVICE(0x10B9),
> + INTEL_E1000_ETHERNET_DEVICE(0x1000, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x1001, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x1004, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x1008, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x1009, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x100C, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x100D, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x100E, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x100F, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x1010, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x1011, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x1012, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x1013, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x1014, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x1015, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x1016, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x1017, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x1018, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x1019, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x101A, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x101D, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x101E, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x1026, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x1027, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x1028, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x105E, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x105F, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x1060, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x1075, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x1076, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x1077, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x1078, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x1079, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x107A, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x107B, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x107C, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x107D, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x107E, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x107F, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x108A, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x108B, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x108C, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x1096, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x1098, 0),
> + INTEL_E1000_ETHERNET_DEVICE(0x1099, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x109A, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x10B5, E1000_NO_IOPORT),
> + INTEL_E1000_ETHERNET_DEVICE(0x10B9, 0),
> /* required last entry */
> {0,}
> };
> @@ -621,7 +621,14 @@
> int i, err, pci_using_dac;
> uint16_t eeprom_data;
> uint16_t eeprom_apme_mask = E1000_EEPROM_APME;
> - if ((err = pci_enable_device(pdev)))
> + int bars;
> +
> + if (ent->driver_data & E1000_NO_IOPORT)
> + bars = pci_select_bars(pdev, IORESOURCE_MEM);
> + else
> + bars = pci_select_bars(pdev, IORESOURCE_MEM | IORESOURCE_IO);
> +
> + if ((err = pci_enable_device_bars(pdev, bars)))
> return err;
>
> if (!(err = pci_set_dma_mask(pdev, DMA_64BIT_MASK))) {
> @@ -634,7 +641,8 @@
> pci_using_dac = 0;
> }
>
> - if ((err = pci_request_regions(pdev, e1000_driver_name)))
> + err = pci_request_selected_regions(pdev, bars, e1000_driver_name);
> + if (err)
> return err;
>
> pci_set_master(pdev);
> @@ -654,6 +662,7 @@
> adapter->pdev = pdev;
> adapter->hw.back = adapter;
> adapter->msg_enable = (1 << debug) - 1;
> + adapter->bars = bars;
>
> mmio_start = pci_resource_start(pdev, BAR_0);
> mmio_len = pci_resource_len(pdev, BAR_0);
> @@ -664,12 +673,15 @@
> goto err_ioremap;
> }
>
> - for (i = BAR_1; i <= BAR_5; i++) {
> - if (pci_resource_len(pdev, i) == 0)
> - continue;
> - if (pci_resource_flags(pdev, i) & IORESOURCE_IO) {
> - adapter->hw.io_base = pci_resource_start(pdev, i);
> - break;
> + if (!(ent->driver_data & E1000_NO_IOPORT)) {
> + for (i = BAR_1; i <= BAR_5; i++) {
> + if (pci_resource_len(pdev, i) == 0)
> + continue;
> + if (pci_resource_flags(pdev, i) & IORESOURCE_IO) {
> + adapter->hw.io_base =
> + pci_resource_start(pdev, i);
> + break;
> + }
> }
> }
>
> @@ -880,7 +892,7 @@
> err_ioremap:
> free_netdev(netdev);
> err_alloc_etherdev:
> - pci_release_regions(pdev);
> + pci_release_selected_regions(pdev, bars);
> return err;
> }
>
> @@ -935,7 +947,7 @@
> #endif
>
> iounmap(adapter->hw.hw_addr);
> - pci_release_regions(pdev);
> + pci_release_selected_regions(pdev, adapter->bars);
>
> free_netdev(netdev);
>
> @@ -4577,7 +4589,7 @@
> if (retval)
> DPRINTK(PROBE, ERR, "Error in setting power state\n");
> e1000_pci_restore_state(adapter);
> - ret_val = pci_enable_device(pdev);
> + ret_val = pci_enable_device_bars(pdev, adapter->bars);
> pci_set_master(pdev);
>
> retval = pci_enable_wake(pdev, PCI_D3hot, 0);
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: sparsemem panic in 2.6.17-rc5-mm1 and -mm2
From: Andrew Morton @ 2006-06-07 4:58 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: y-goto, mbligh, apw, linux-kernel, 76306.1226, Ingo Molnar,
Arjan van de Ven, Gerd Hoffmann, Rusty Russell, Zachary Amsden
In-Reply-To: <20060607094355.b77ed883.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, 7 Jun 2006 09:43:55 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> On Tue, 6 Jun 2006 00:27:58 -0700
> Andrew Morton <akpm@osdl.org> wrote:
>
> >
> > I tried sparsemem on my little x86 box here. Boots OK, after fixing up the
> > kswapd_init() patch (below).
> >
> > I'm wondering why I have 4k of highmem:
> >
>
> Could you show /proc/iomem of your 4k HIGHMEM box ?
> Does 4k HIGHMEM exist only when SPARSEMEM is selected ?
Turns out that my 4 kbyte highmem zone (at least, as reported in
/proc/meminfo) is due to
vdso-randomize-the-i386-vdso-by-moving-it-into-a-vma.patch
vdso-randomize-the-i386-vdso-by-moving-it-into-a-vma-tidy.patch
vdso-randomize-the-i386-vdso-by-moving-it-into-a-vma-arch_vma_name-fix.patch
vdso-randomize-the-i386-vdso-by-moving-it-into-a-vma-vs-x86_64-mm-reliable-stack-trace-support-i386.patch
vdso-randomize-the-i386-vdso-by-moving-it-into-a-vma-vs-x86_64-mm-reliable-stack-trace-support-i386-2.patch
I don't think that was intended.
It'll be a screwup in the handling of MAXMEM. That patch is doing strange
things with MAXMEM. They are unchangelogged, uncommented and
possibly-hacky-looking things too, so I have no intention of fixing it.
^ permalink raw reply
* Re: mutex vs. local irqs (Was: 2.6.18 -mm merge plans)
From: Benjamin Herrenschmidt @ 2006-06-07 5:04 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, mingo, Paul Mackerras
In-Reply-To: <20060606212930.364b43fa.akpm@osdl.org>
> A couple of cycles repeated a zillion times per second for the entire
> uptime, just because we cannot get our act together in the first few
> seconds of booting. How much does that suc
I don't follow you... what would you call "getting our act together"
then ? Being able to initialize half of the kernel data structures
without ever going near a mutex ?
The current stuff is just crap.
> And how much does it suck that we require that an attempt to take a
> sleeping lock must keep local interrupts disabled if the lock wasn't
> contended?
That is a more interesting point :)
> Fortunately, it only happens (or at least, is only _known_ to happen) when
> mutex debugging is enabled, so the performance loss is moot.
>
> I do not know where the offending mutex_lock()s are occuring (although it
> would be super-simple to find out).
And even if we fix those, we'll ultimately get more.
> By far the best solution to this would be to remove this requirement that
> local interrupts remain disabled for impractical amounts of time during boot.
That is not possible in any remotely sane way accross the board.
> Either whack the PIC in setup_arch() or reorganise start_kernel() in some
> appropriate manner.
Neither would be satisfactory. Whacking the PIC means accessing
hardware, which for a lot of architectures means having page tables up,
some kind of ioremap, etc... Hence the bunch of workarounds done by
various archs like having their PTE allocation function do horrors like
if (mem_init_done) kmalloc() else alloc_bootmem().
It's just too ugly for words.
As you said, we need to get our act together. That means having basic
kernel services that do _not_ rely on any hardware (interrupts, timer,
whatever...) be initialized first before we start needing ioremap's and
friends. That means having things like init_IRQ() which has to handle
allocating and initializing PICs all over the range and all sorts of
data structures that are related to interrupt handling, be able to use
said kernel services instead of having dodgy things like do half init
now, and another half later from a hook somewhere or an initcall while
hopeing that nobody will get in the middle.
It would make so much more sense to have the init code do something
like:
setup_arch();
init_basic_kernel_services(); <--- that's the blob you spotted with mem
init, slab init, ...
init_arch(); <--- new arch hook
and later on, as part of the various inits, you get init_IRQ() and so
on...
In my example, init_arch() would be where the arch code moves the bits
currently in setup_arch() that do things like ioremap system devices and
do things that may want to use the slab etc... thus leaving setup_arch()
to very basic initialisations.
Not being able to do all of those because we have this
hyper-optimized-mutex-blah thing that hard enables interrupt all over
the place seems like a stupid thing to me. In fact, as you mentioned, it
only affects a debug code path which thus could perfectly take the
performance hit.
> But I'll be merging
> work-around-ppc64-bootup-bug-by-making-mutex-debugging-save-restore-irqs.patch
> so we'll just continue to suck I guess.
How so ? Can you tell me how making the mutex debug code path do
something sane makes it 'suck' ? Don't argue about the couple of cycles
benefit, as you mentionned yourself, it's a debug code path.
Ben.
^ permalink raw reply
* RE: [PATCH][HVMLOADER][DISCUSS] 8 way default rombios
From: Wang, Winston L @ 2006-06-07 4:55 UTC (permalink / raw)
To: xen-devel-bounces; +Cc: xen-devel
Tom,
On latest xen-unstable, when installing Windows XP, it'll loop forever
at Windows setup. Then we found this is caused by your
'xen-8-way-bios.patch' in changset 10191, your patch added an 8 vcpu MPS
table (pnp mode) to the HVM BIOS, This is probably fine for Linux SMP
Guest but is screwing up Windows because Windows do not understand what
kind of platform it is and then install the wrong HAL for it.
Here is my suggestion for you:
If you want to add SMP support for MPS table, you need to check HVM
guest configuration file for the switches for acpi and vcpu =number:
if (vcpu !=1 &acpi=0)
build xen-(vcpu number)-way-bios
...
Just as Jun pointed out MPS table is used for old guest OS (plug and
play mode +APM) mode, not for ACPI,
Here is a method how to install guest Windows XP (using you patch) by
telling Windows what kind of platform at Windows setup (this is true for
Win2k, 2003 and XP):
After passing the 1st screen of windows setup of install XP, the first
thing you'll see at the bottom of the screen is the option to press F6
if you need to install a SCSI or RAID controller. Don't press F6. Press
F5 instead. This will take you to a separate menu of Hardware
Abstraction Layer's where you can choose an appropriate HAL .The choices
are:
ACPI Multiprocessor PC
ACPI Uniprocessor PC
Advanced Configuration and Power Interface (ACPI) PC
Compaq SystemPro Multiprocessor or 100% Compatible PC
MPS Uniprocessor PC
MPS Multiprocessor PC
Standard PC
Standard PC with C-Step i486
Other
Select "Standard PC". This will allow the installation to complete in
about 20 minutes.
If we revert your patch, we don't need the above press F5 to get guest
Windows installed.
Regards,
Winston,
>>> -----Original Message-----
>>> From: xen-devel-bounces@lists.xensource.com
>>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of
>>> Nakajima, Jun Sent: Tuesday, May 30, 2006 4:01 PM
>>> To: Woller, Thomas; xen-devel@lists.xensource.com
>>> Subject: RE: [Xen-devel] [PATCH][HVMLOADER][DISCUSS] 8 way default
>>> rombios
>>>
>>> ACPI MADT is sufficient for getting >1 vcpus (just add vcpus=N at xm
>>> create time) for modern OSes, but the mp config table would be
>>> required for old guests. So I think the patch is sensible.
>>>
>>> Jun
>>> ---
>>> Intel Open Source Technology Center
>>>
>>> -----Original Message-----
>>> From: xen-devel-bounces@lists.xensource.com
>>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Woller,
>>> Thomas Sent: Tuesday, May 30, 2006 3:01 PM
>>> To: xen-devel@lists.xensource.com
>>> Subject: [Xen-devel] [PATCH][HVMLOADER][DISCUSS] 8 way default
>>> rombios
>>>
>>> Attached simple patch modifies the rombios and hvmloader Makefiles
>>> to default to an 8-way bochs bios for the hvmloader.
>>>
>>> Is there a reason to not define the mp config table by default for
>>> >1 processors (8), in the repository?
>>>
>>> Seems like using the hvm guest config file can the methodolody to
>>> describe a UP guest regardless of the mptables.
>>> Defaulting the rombios to MP would allow users to experiment with
>>> SMP guests, while allowing UP guests to work.
>>>
>>> Thanks
>>> Tom
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [PATCH] Refactor git_tcp_connect() functions a little.
From: Junio C Hamano @ 2006-06-07 4:53 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1FnpBp-00043u-Uc@jdl.com>
Jon Loeliger <jdl@jdl.com> writes:
> Add client side sending of "\0host=%s\0" extended
> arg for git native protocol, backwards compatibly.
>
> Signed-off-by: Jon Loeliger <jdl@jdl.com>
> ---
> connect.c | 42 ++++++++++++++++++++++++++++++++----------
> 1 files changed, 32 insertions(+), 10 deletions(-)
>
> I've tested this against an "old" daemon, and my new daemon
> running on jdl.com that understands the new host=%s parameter.
> Both appear to work still.
Thanks.
> However, I don't have a setup to test a proxy connection,
> and I left FIXME: down there asking the question if it is
> even needed in this case as well. I _think_ so, but I am
> just not sure. (It should be a straight pass-through to
> another git: native protocol, right?)
I think so.
> And if it is needed there too, do you want to refactor
> these two packet_writes() for commonality again?
Let me munge that part and push it out. I've tested it lightly
both with and without proxy. My proxy was a single liner shell
script:
nc -o /var/tmp/nc.log localhost 9418
whose dump started with this nice request packet:
> 00000000 30 30 35 62 67 69 74 2d 75 70 6c 6f 61 64 2d 70 # 005bgit-upload-p
> 00000010 61 63 6b 20 2f 6f 70 74 2f 70 61 63 6b 72 61 74 # ack /opt/packrat
> 00000020 2f 70 6c 61 79 70 65 6e 2f 70 75 62 6c 69 63 2f # /playpen/public/
> 00000030 69 6e 2d 70 6c 61 63 65 2f 67 69 74 2f 67 69 74 # in-place/git/git
> 00000040 2e 6a 75 6e 69 6f 00 68 6f 73 74 3d 6c 6f 63 61 # .junio.host=loca
> 00000050 6c 68 6f 73 74 3a 34 34 33 33 00 # lhost:4433.
for a request "peek-remote git://localhost:4433/opt/.../git.junio".
I suspect that a real git proxy, if somebody ever writes one,
would read the first outgoing packet reads the request
(including this host= stuff) and connect to the true destination
intelligently after sending out a modified request packet.
Takers?
^ permalink raw reply
* Re: NMI problems with Dell SMP Xeons
From: Keith Owens @ 2006-06-07 4:49 UTC (permalink / raw)
To: linux-kernel; +Cc: ak, Brendan Trotter
In-Reply-To: <8303.1148360619@kao2.melbourne.sgi.com>
Following a suggestion by Brendan Trotter, I ran some more tests to
track down the problem with sending NMI IPI on Dell Xeons.
BIOS Logical OS ACPI Cpus IPI 2 NMI IPI
Processor BIOS OS (APIC_DM_NMI)
Enabled Enabled 4 4 Not delivered Delivered as NMI
Enabled Disabled 4 2 Machine reset Machine reset
Disabled Enabled 2 2 Not delivered Delivered as NMI
Disabled Disabled 2 2 Not delivered Delivered as NMI
So the killer combination with this motherboard is when the BIOS knows
about logical processors but the OS does not. Sending IPI 2 or NMI IPI
with that combination kills the machine. Brendan suggested that the
BIOS is seeing the broadcast NMI on the logical processors which are
not under OS control and that the BIOS cannot cope.
Should we change the x86_64 send_IPI_allbutself() so it is only
delivered to cpus that the OS knows about, instead of doing a general
broadcast. That would prevent offline or hidden cpus being sent an
interrupt that they are not expecting. The failing case is
__send_IPI_shortcut, with a cfg of 0xc0c00.
^ permalink raw reply
* Re: mutex vs. local irqs (Was: 2.6.18 -mm merge plans)
From: Andrew Morton @ 2006-06-07 4:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-kernel, mingo
In-Reply-To: <1149652378.27572.109.camel@localhost.localdomain>
On Wed, 07 Jun 2006 13:52:58 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > work-around-ppc64-bootup-bug-by-making-mutex-debugging-save-restore-irqs.patch
> > kernel-kernel-cpuc-to-mutexes.patch
> >
> > ug. We cannot convert the cpu.c semaphore into a mutex until we work out
> > why power4 goes titsup if you enable local interrupts during boot.
>
> What is the exact problem ? Some mutex is forcing local irqs enabled
> before init_IRQ() ? (Before the normal enabling of IRQ done by
> init/main.c just after init_IRQ() more precisely ?)
Any code which does mutex_lock() will have interrupts reenabled if the
mutex code was compiled in debug mode.
> This is bad for any architecture. Basically, at this point, the
> interrupt controller can be in _any_ state, with possible pending
> interrupts for whatever sources, etc...
>
> As we discussed before, that problem should really be fixed in the mutex
> code by not hard-enabling.
>
> There is an incredible amount of crap that could be cleaned up for
> example by re-ordering a bit the init code and making things like slab
> available before init_IRQ/time_init etc... but all of those will break
> because of that.
>
> In addition, even without that re-ordering, I'm pretty sure we are
> hitting semaphores/mutexes early, before init_IRQ(), already and if not
> in generic code, in arch code somewhere down the call stacks.
>
> I don't think that whole pile of problems lurking around the corner is
> worth the couple of cycles saved by hard-enabling irq in the mutex
> instead of doing a save/restore.
A couple of cycles repeated a zillion times per second for the entire
uptime, just because we cannot get our act together in the first few
seconds of booting. How much does that suck?
And how much does it suck that we require that an attempt to take a
sleeping lock must keep local interrupts disabled if the lock wasn't
contended?
Fortunately, it only happens (or at least, is only _known_ to happen) when
mutex debugging is enabled, so the performance loss is moot.
I do not know where the offending mutex_lock()s are occuring (although it
would be super-simple to find out).
By far the best solution to this would be to remove this requirement that
local interrupts remain disabled for impractical amounts of time during boot.
Either whack the PIC in setup_arch() or reorganise start_kernel() in some
appropriate manner.
But I'll be merging
work-around-ppc64-bootup-bug-by-making-mutex-debugging-save-restore-irqs.patch
so we'll just continue to suck I guess.
^ permalink raw reply
* Re: klibc
From: H. Peter Anvin @ 2006-06-07 4:26 UTC (permalink / raw)
To: Nigel Cunningham; +Cc: linux-kernel
In-Reply-To: <200606071425.35802.ncunningham@linuxmail.org>
Nigel Cunningham wrote:
>
> Ok. Ta. I guess I should put some time into learning this prior to 2.6.18
> then, so I can help others through the transition.
>
I've been meaning to write up some proper documentation, but obviously
my #1 priority has been to fix problems as they crop up. If you would
be willing to help in that area, I'd be more than willing to spend some
time giving you a mind dump.
-hpa
^ permalink raw reply
* Re: [2.6.17-rc5-mm2] crash when doing second suspend: BUG in arch/i386/kernel/nmi.c:174
From: Jeremy Fitzhardinge @ 2006-06-07 0:56 UTC (permalink / raw)
To: Nigel Cunningham
Cc: Andrew Morton, Don Zickus, ak, shaohua.li, miles.lane,
linux-kernel
In-Reply-To: <200606071034.03228.ncunningham@linuxmail.org>
Nigel Cunningham wrote:
> In general, you're right because we don't have perfect hardware hotplugging
> yet. But cpu hotplugging is one area we do have, so it should work.
Well, it seems to me the general problem is generating the proper
hotplug events. If you actually pull, say, a USB device, the usb
subsystem will tell you about it as it happens. But if you can suspend
the machine and then arbitrarily rearrange the hardware, then on resume
you'd have to go over the current hardware state and compare it to the
pre-suspend state and generate all those events. Or I guess you could
just generate unplug events for everything at suspend and re-plug
anything you find on resume. Sounds pretty heavyweight though.
J
^ permalink raw reply
* Re: klibc (was: 2.6.18 -mm merge plans)
From: Nigel Cunningham @ 2006-06-07 4:25 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: linux-kernel
In-Reply-To: <e65jj9$m9p$1@terminus.zytor.com>
[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]
Hi.
On Wednesday 07 June 2006 14:10, H. Peter Anvin wrote:
> Followup to: <200606071400.49980.ncunningham@linuxmail.org>
> By author: Nigel Cunningham <ncunningham@linuxmail.org>
> In newsgroup: linux.dev.kernel
>
> > Hi.
> >
> > Sorry for coming in late. I've only just resubscribed after my move.
> >
> > Not sure who originally said this...
> >
> > > > > problems it entails.) The initial code to have removed
> > > > > is the root-mounting code, with all the various ugly
> > > > > mutations of that (ramdisk loading, NFS root, initrd...)
> >
> > Could I get more explanation of what this means and its implications? I'm
> > thinking in particular about the implications for suspending to disk.
> > Will it imply that everyone will _have_ to have an initramfs with some
> > userspace program that sets up device nodes and so on, even if at the
> > moment all you have is root=/dev/hda1 resume2=swap:/dev/hda2?
>
> Yes. That initramfs is embedded in the kernel image.
>
> > Along similar lines, I had been considering eventually including support
> > for putting an image in place of the initrd (for embedded).
>
> You can still override the default buildin initramfs. Then you get
> the benefit of not carrying a bunch of code with you that can never be
> executed.
Ok. Ta. I guess I should put some time into learning this prior to 2.6.18
then, so I can help others through the transition.
Regards,
Nigel
--
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* ASRock K7Upgrade-880 with S3
From: Anish Mistry @ 2006-06-07 4:20 UTC (permalink / raw)
To: linux-acpi
[-- Attachment #1: Type: text/plain, Size: 3070 bytes --]
I'm prefacing my question with email to the FreeBSD ACPI list as this
problem is to ultimately debug an ACPI problem in FreeBSD.
-- START FreeBSD Email --
I'm trying to get my desktop to STR (S3) and can't even get S3 to
semi-powered down state. 6.1-RELEASE-p1
I've updated the BIOS to the latest version. When I do an acpiconf -s
3 the suspend get all the way into the AcpiEnterSleepState function
and begins to write registers. The last line I see (with full ACPI
debugging enabled):
heregs-0708 HwRegisterWrite : ----Entry
Then the power light on the case starts to blink seeming to indicate
that it is in suspend, except I can still see output on the monitor
and the fans and harddrives are still running. Then when I press
the power button to try to bring the system back up it then displays:
heregs-0708 HwRegisterWrite : ----Exit
and then continues with a few more HwRegisterWrite and then exits the
AcpiEnterSleepState function and then does nothing. The system shows
no life of coming back. I then need to perform a cold boot, because
if I just hit the reset button the system doesn't restart to the
point where it gets to the BIOS screen.
My acpidump output is at:
http://am-productions.biz/docs/bigguy.asl
I've fixed the errors in the asl and tried using that, but it showed
the same problem.
http://am-productions.biz/docs/bigguy-fix.asl
dmesg:
http://am-productions.biz/docs/bigguy.dmesg
When I do an "acpidump -dt" I see the following message displayed:
acpidump: RSDT entry 2 (sig OEMB) is corrupt
Windows isn't installed on this system so I can't compare it with
that. I tried suspending with Knoppix (2006-06-01) and that worked a
bit better. It successfully shuts off the disks on suspend, but the
case fans and video card/monitor were still on. When you press the
power button again in knoppix it successfully brought the system back
to life. Getting it to the point of Knoppix would be a good start.
S1 in FreeBSD does work, but it doesn't shut anything down, so it's
not really useful.
hw.acpi.supported_sleep_state: S1 S3 S4 S5
hw.acpi.power_button_state: S5
hw.acpi.sleep_button_state: S1
hw.acpi.lid_switch_state: S3
hw.acpi.standby_state: S1
hw.acpi.suspend_state: S3
hw.acpi.sleep_delay: 5
hw.acpi.s4bios: 0
hw.acpi.verbose: 1
hw.acpi.reset_video: 0
hw.acpi.cpu.cx_supported: C1/0
hw.acpi.cpu.cx_lowest: C1
hw.acpi.cpu.cx_usage: 100.00%
debug.acpi.acpi_ca_version: 0x20041119
I've also tried CURRENT with ACPI-CA 20051021 with the same results.
-- END FreeBSD Email --
Now for the Linux part. Since Linux (Knoppix with kernel 2.6.17)
seems to get at least some of the suspend/resume right I'm trying to
figure out how to get it to display the full debug information to
compare with FreeBSD. I'm looking for how to do the following in
Linux:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html
Specifically the ACPI layer and level debugging mention at the end of
the page.
Thanks,
--
Anish Mistry
[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Add udbg-immortal kernel option
From: Benjamin Herrenschmidt @ 2006-06-07 4:19 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <20060607022412.GA5661@pb15.lixom.net>
On Tue, 2006-06-06 at 19:24 -0700, Olof Johansson wrote:
> On Wed, Jun 07, 2006 at 12:06:20PM +1000, Benjamin Herrenschmidt wrote:
> > return;
> > + if (strstr(saved_command_line, "udbg-immortal")) {
> > + printk(KERN_INFO "early console immortal !\n");
> > + return;
> > + }
>
> So it's YOU who add spaces before punctuation all over arch/powerpc!
> Please fix. ;-)
No way :) Besides, that's how it should be done in french :)
Ben.
^ permalink raw reply
* Re: what is MCFG area ?
From: Pavel Troller @ 2006-06-07 4:15 UTC (permalink / raw)
To: Sergio Monteiro Basto; +Cc: linux-acpi
In-Reply-To: <1149637549.3057.4.camel@localhost.portugal>
> On my buggy computer i get
> cat dmesg09 | grep "MM\|MCFG"
> ACPI: MCFG (v001 A M I OEMMCFG 0x05000602 MSFT 0x00000097) @ 0x000000003ffb0410
> PCI: BIOS Bug: MCFG area is not E820-reserved
> PCI: Not using MMCONFIG.
> PCI-DMA: Disabling IOMMU.
I'm getting exactly the same messages, just the numbers in the MCFG line are
different:
root@arcus:~# dmesg | grep "MM\|MCFG"
ACPI: MCFG (v001 A M I OEMMCFG 0x11000524 MSFT 0x00000097) @ 0x000000003f7d03f0
PCI: BIOS Bug: MCFG area is not E820-reserved
PCI: Not using MMCONFIG.
PCI-DMA: Disabling IOMMU.
It's on a MSI motherboard with Intel 945 chipset (MS-7210). The machine
otherwise works very well.
The "Disabling IOMMU" message I'm getting also on another, Nvidia NF4/Opteron
based board, without this MCFG bug. I think it's unrelated and because Linux
properly detected the BIOS bug and probably fixed it, I think the MCFG message
is harmless.
With regards, Pavel Troller
^ permalink raw reply
* Re: Socket buffer allocation outside DMA-able memory
From: Mark.Zhan @ 2006-06-07 4:11 UTC (permalink / raw)
To: art; +Cc: linux-mips
In-Reply-To: <10452.060607@sigrand.ru>
Hi art,
I think maybe my first noise is more easy to go.
As you know, sk_buff is made of a skb header and the packet data
container. The skb header is allocated from the slab cache, while the
packet data container is allocated via kmalloc().
So if you can add your low 32MB memory into ZONE_DMA, then your can call
__dev_alloc_skb() with __GFP_DMA flag in your driver, which should make
sure that the packet data container is in ZONE_DMA.
Best Regards,
Mark.Zhan
art wrote:
> Hello Rongkai,
>
> Thanks! Good idea!
>
>
> ZR> After having a look at the latest 2.6.17-rc6 codes, __dev_alloc_skb is defined like this:
>
> ZR> #ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB
> ZR> /**
> ZR> * __dev_alloc_skb - allocate an skbuff for sending
> ZR> * @length: length to allocate
> ZR> * @gfp_mask: get_free_pages mask, passed to alloc_skb
> ZR> *
> ZR> * Allocate a new &sk_buff and assign it a usage count of one. The
> ZR> * buffer has unspecified headroom built in. Users should allocate
> ZR> * the headroom they think they need without accounting for the
> ZR> * built in space. The built in space is used for optimisations.
> ZR> *
> ZR> * %NULL is returned in there is no free memory.
> ZR> */
> ZR> static inline struct sk_buff *__dev_alloc_skb(unsigned int length,
> ZR> gfp_t gfp_mask)
> ZR> {
> ZR> struct sk_buff *skb = alloc_skb(length + NET_SKB_PAD, gfp_mask);
> ZR> if (likely(skb))
> ZR> skb_reserve(skb, NET_SKB_PAD);
> ZR> return skb;
> ZR> }
> ZR> #else
> ZR> extern struct sk_buff *__dev_alloc_skb(unsigned int length, int gfp_mask);
> ZR> #endif
>
>
> ZR> Therefore, you also can consider to implement your machine-specific __dev_alloc_skb() function, and force the skb is allocated from your low 32MB memory zone.
>
>
>
>
^ permalink raw reply
* Re: klibc (was: 2.6.18 -mm merge plans)
From: H. Peter Anvin @ 2006-06-07 4:10 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <200606071400.49980.ncunningham@linuxmail.org>
Followup to: <200606071400.49980.ncunningham@linuxmail.org>
By author: Nigel Cunningham <ncunningham@linuxmail.org>
In newsgroup: linux.dev.kernel
>
> Hi.
>
> Sorry for coming in late. I've only just resubscribed after my move.
>
> Not sure who originally said this...
>
> > > > problems it entails.) The initial code to have removed
> > > > is the root-mounting code, with all the various ugly
> > > > mutations of that (ramdisk loading, NFS root, initrd...)
>
> Could I get more explanation of what this means and its implications? I'm
> thinking in particular about the implications for suspending to disk. Will it
> imply that everyone will _have_ to have an initramfs with some userspace
> program that sets up device nodes and so on, even if at the moment all you
> have is root=/dev/hda1 resume2=swap:/dev/hda2?
>
Yes. That initramfs is embedded in the kernel image.
> Along similar lines, I had been considering eventually including support for
> putting an image in place of the initrd (for embedded).
You can still override the default buildin initramfs. Then you get
the benefit of not carrying a bunch of code with you that can never be
executed.
-hpa
^ permalink raw reply
* Re: [PATCH 6/9] PCI PM: call platform helpers properly
From: Benjamin Herrenschmidt @ 2006-06-07 4:09 UTC (permalink / raw)
To: Adam Belay; +Cc: Greg KH, Andrew Morton, linux-kernel, linux-pci, Len Brown
In-Reply-To: <1149648774.7831.217.camel@localhost.localdomain>
On Tue, 2006-06-06 at 22:52 -0400, Adam Belay wrote:
> Hmm, do you know of any example firmware scenarios that make the entire
> state transition? We might need a separate callback. I think the
> changes in this patch are at least an improvement over the current
> behavior, especially for ACPI PM functions.
Well, do we know precisely what ACPI does/needs for example here ?
Ben.
^ permalink raw reply
* Re: [parisc-linux] User space locks -- what's wrong
From: John David Anglin @ 2006-06-07 4:09 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux
In-Reply-To: <119aab440606061830peac8e3ah7030b831881e6f76@mail.gmail.com>
> > Thoughts?
>
> You've implemented almost exactly what glibc does for pthreads.
> However, glibc uses nanosleep without any adverse effects.
> Have you tried other syscalls instead of select?
I've also tried nanosleep and sched_yield. I would say that
nanosleep and select have similar behavior under linux. I need
a little testing under hpux but I currently have the impression
that the patch with either nanosleep or select works under hpux.
I've had a coupled of failures that seemed to indicate a problem
with nanosleep, but I don't have hard data on this. Oh, I remember.
These were unkillable java tasks. strace indicated a nanosleep
call to the kernel that never returned. I couldn't find a signal
to get rid of the task. Haven't seen one of these for a few days.
Sometimes they are left over from the libjava testsuite run.
My initial testing with the program from the paper modified to
8 threads seemed to indicate somewhat poorer performance using
sched_yield (don't know why). I also found that pre-checks
of the lock using "ldw" or trying to create a dirty cache-line
prior to the ldcw didn't help overall performance. Using stby,e
to the high byte of the lock was definitely detrimental.
I think I can understand the later. I believe most PA 2.0 machines
are fully coherent (except V class and possibly superdome). Thus,
the ldcw instruction runs in cache on these machines and specifying
the ",co" completer doesn't matter. Also, stby,e is just an unnecessary
operation that occurs normally with ldcw if necessary. There might
be some effect on early PA 1.x machines which don't support executing
ldcw in cache.
There are some subtle cache issues in all this. I believe that
machines using the PA7200 through to the PA8700 only utilize an
L1 cache, but it has an assist buffer. It appears using the ",sl"
completer bypasses the L1 cache. Michael Zick thought using this
to reset the lock and in lock tests was a good idea, but think
it's better to use the L1. The effect of ",sl" on cacheline states
is rather poorly document. Michael has looked at some of HP's
patents and a bunch of other papers, but I'm not convinced. The
PDC_CACHE command may be able to change the coherency state and
write-back/write-through state of the data caches on some machines.
The cache design was changed on the PA8800 and PA8900. The L1
is now on-chip and there is a large L2. The cacheline length
also increased from 64 to 128 bytes. These changes could be
part of the reason linux still doesn't run on these machines.
Some of the papers talk about sharing and false sharing. These
can potentially cause failure of ldcw (race condition in bus logic?).
It is best is semaphores are cacheline aligned and don't share the line.
Currently, non of the locks used in arch/parisc are cacheline aligned.
Joel ran a test kernel with a patch to align statically allocated
locks. It might have run a bit longer than average but there was
still a softlockup after a few days. So, I don't think the lockup
is due to the spinlock design per say, although I could easily
be wrong. I think it's more likely to be something to do with
interrupt handling. This is suggested by the stack traces which
often seem to occur in the interrupt return path.
I've looked at the locking in hpux a bit. As far as I can tell,
the kernel never really spins. It has code to do pre-arbitration
and keeps track of tasks and priorities. When a lock is released,
the code calls into suwaiters to see if the lock should be handed
over to another task or released. When we just spin, we are relying
on the bus arbitration to select a winner. So, when we have a
highly contended lock, it might be possible for a cpu to get locked
out for sufficient time to cause a softlockup.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply
* Re: AMD64: 64 bit kernel 32 bit userland - some pending questions
From: H. Peter Anvin @ 2006-06-07 4:08 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <787b0d920606062011j21083e80v659228a7565ecfab@mail.gmail.com>
Followup to: <787b0d920606062011j21083e80v659228a7565ecfab@mail.gmail.com>
By author: "Albert Cahalan" <acahalan@gmail.com>
In newsgroup: linux.dev.kernel
>
> The bigger problem is that 32-bit code has fewer CPU registers.
> (nobody has done an ILP32 ABI for long mode) This is slow.
>
The issue isn't the ABI, the issue is that the processor doesn't
support it, since some of the opcodes mean different things in 16-,
32- and 64-bit mode. The opcodes which access the high half of the
register sets (REX prefixes) in 64-bit mode are INC and DEC
instructions in 16- and 32-bit mode.
AMD was apparently considering adding a "REX32" mode at some point,
but rather predictably noone was interested enough to make it
worthwhile.
-hpa
^ permalink raw reply
* Re: klibc (was: 2.6.18 -mm merge plans)
From: Nigel Cunningham @ 2006-06-07 4:00 UTC (permalink / raw)
To: linux-kernel
Cc: Rafael J. Wysocki, Pavel Machek, H. Peter Anvin, Andrew Morton
In-Reply-To: <200606062256.55472.rjw@sisk.pl>
[-- Attachment #1: Type: text/plain, Size: 823 bytes --]
Hi.
Sorry for coming in late. I've only just resubscribed after my move.
Not sure who originally said this...
> > > problems it entails.) The initial code to have removed
> > > is the root-mounting code, with all the various ugly
> > > mutations of that (ramdisk loading, NFS root, initrd...)
Could I get more explanation of what this means and its implications? I'm
thinking in particular about the implications for suspending to disk. Will it
imply that everyone will _have_ to have an initramfs with some userspace
program that sets up device nodes and so on, even if at the moment all you
have is root=/dev/hda1 resume2=swap:/dev/hda2?
Along similar lines, I had been considering eventually including support for
putting an image in place of the initrd (for embedded).
Regards,
Nigel
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Refactor git_tcp_connect() functions a little.
From: Jon Loeliger @ 2006-06-07 3:58 UTC (permalink / raw)
To: git
Add client side sending of "\0host=%s\0" extended
arg for git native protocol, backwards compatibly.
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
connect.c | 42 ++++++++++++++++++++++++++++++++----------
1 files changed, 32 insertions(+), 10 deletions(-)
I've tested this against an "old" daemon, and my new daemon
running on jdl.com that understands the new host=%s parameter.
Both appear to work still.
However, I don't have a setup to test a proxy connection,
and I left FIXME: down there asking the question if it is
even needed in this case as well. I _think_ so, but I am
just not sure. (It should be a straight pass-through to
another git: native protocol, right?)
And if it is needed there too, do you want to refactor
these two packet_writes() for commonality again?
diff --git a/connect.c b/connect.c
index 54f7bf7..3fa890d 100644
--- a/connect.c
+++ b/connect.c
@@ -322,7 +322,10 @@ #define STR(s) STR_(s)
#ifndef NO_IPV6
-static int git_tcp_connect(int fd[2], const char *prog, char *host, char *path)
+/*
+ * Returns a connected socket() fd, or else die()s.
+ */
+static int git_tcp_connect_sock(char *host)
{
int sockfd = -1;
char *colon, *end;
@@ -356,7 +359,8 @@ static int git_tcp_connect(int fd[2], co
die("Unable to look up %s (%s)", host, gai_strerror(gai));
for (ai0 = ai; ai; ai = ai->ai_next) {
- sockfd = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol);
+ sockfd = socket(ai->ai_family,
+ ai->ai_socktype, ai->ai_protocol);
if (sockfd < 0)
continue;
if (connect(sockfd, ai->ai_addr, ai->ai_addrlen) < 0) {
@@ -372,15 +376,15 @@ static int git_tcp_connect(int fd[2], co
if (sockfd < 0)
die("unable to connect a socket (%s)", strerror(errno));
- fd[0] = sockfd;
- fd[1] = sockfd;
- packet_write(sockfd, "%s %s\n", prog, path);
- return 0;
+ return sockfd;
}
#else /* NO_IPV6 */
-static int git_tcp_connect(int fd[2], const char *prog, char *host, char *path)
+/*
+ * Returns a connected socket() fd, or else die()s.
+ */
+static int git_tcp_connect_sock(char *host)
{
int sockfd = -1;
char *colon, *end;
@@ -407,7 +411,6 @@ static int git_tcp_connect(int fd[2], co
port = colon + 1;
}
-
he = gethostbyname(host);
if (!he)
die("Unable to look up %s (%s)", host, hstrerror(h_errno));
@@ -441,13 +444,29 @@ static int git_tcp_connect(int fd[2], co
if (sockfd < 0)
die("unable to connect a socket (%s)", strerror(errno));
+ return sockfd;
+}
+
+#endif /* NO_IPV6 */
+
+
+static int git_tcp_connect(int fd[2],
+ const char *prog, char *host, char *path)
+{
+ int sockfd = git_tcp_connect_sock(host);
+
fd[0] = sockfd;
fd[1] = sockfd;
- packet_write(sockfd, "%s %s\n", prog, path);
+
+ /*
+ * Separate original protocol components prog and path
+ * from extended components with a NUL byte.
+ */
+ packet_write(sockfd, "%s %s%chost=%s%c", prog, path, 0, host, 0);
+
return 0;
}
-#endif /* NO_IPV6 */
static char *git_proxy_command = NULL;
static const char *rhost_name = NULL;
@@ -551,7 +570,10 @@ static int git_proxy_connect(int fd[2],
fd[1] = pipefd[1][1];
close(pipefd[0][1]);
close(pipefd[1][0]);
+
+ /* FIXME: Does this need %chost=%s%c tacked on here too? */
packet_write(fd[1], "%s %s\n", prog, path);
+
return pid;
}
--
1.4.0.rc1.ga6a5-dirty
^ permalink raw reply related
* Re: Transparent proxy setup with apache on the nat gateway
From: R. DuFresne @ 2006-06-07 3:58 UTC (permalink / raw)
To: Nicolas Mailhot; +Cc: netfilter, Pascal Hambourg
In-Reply-To: <1149506463.6397.27.camel@rousalka.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1190 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 5 Jun 2006, Nicolas Mailhot wrote:
> Le lundi 05 juin 2006 à 13:10 +0200, Pascal Hambourg a écrit :
>
>> The question is : are you sure that Apache can act as a _transparent_
>> proxy, like Squid ?
>
> I don't know.
> There is a ton of pages on mod_proxy and transparent proxying, but most
> of the times transparent seems to be used in another context. And this
> makes googling absolutely useless.
>
> Where is this mod_tproxy so I can take a look at it ?
>
> Regards,
>
>
You may also want to try the apache users lists.
Thanks,
Ron DuFresne
- --
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
admin & senior security consultant: sysinfo.com
http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A E838 B2DF AFCC 94B0 6629
...We waste time looking for the perfect lover
instead of creating the perfect love.
-Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEhk7Pst+vzJSwZikRAvqDAKDgoel7yQEd0PJjXllJ+XlfVpc7ZwCdEggZ
HYN8nZ3S9FaM0qofFM/Z8gE=
=2X2f
-----END PGP SIGNATURE-----
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.