headers
Randy.Dunlap | 1 Sep 2006 01:05

Re: prevent swsusp with PAE

On Fri, 1 Sep 2006 00:52:34 +0200 Pavel Machek wrote:

> On Thu 2006-08-31 15:48:28, Andrew Morton wrote:
> > On Fri, 1 Sep 2006 00:35:21 +0200
> > Pavel Machek <pavel <at> ucw.cz> wrote:
> > 
> > > > > diff --git a/include/asm-i386/suspend.h b/include/asm-i386/suspend.h
> > > > > index 08be1e5..01cd812 100644
> > > > > --- a/include/asm-i386/suspend.h
> > > > > +++ b/include/asm-i386/suspend.h
> > > > >  <at>  <at>  -16,6 +16,15  <at>  <at>  arch_prepare_suspend(void)
> > > > >  		printk(KERN_ERR "PSE is required for swsusp.\n");
> > > > >  		return -EPERM;
> > > > >  	}
> > > > > +
> > > > > +#ifdef CONFIG_X86_PAE
> > > > > +	printk(KERN_ERR "swsusp is incompatible with PAE.\n");
> > > > > +	/* This is actually instance of the same problem. We need
> > > > > +	   identity mapping self-contained in swsusp_pg_dir, and PAE
> > > > > +	   prevents that. Solution could be copied from x86_64. */
> > > > > +	return -EPERM;
> > > > > +#endif
> > > > > +
> > > > >  	return 0;
> > > > >  }
> > > > 
> > > > Why not do this in Kconfig??
> > > 
> > > Well, Kconfig does not provide natural place for comments, and
> > > disappearing config option is sure to confuse people. But of course I
(Continue reading)

Permalink | Reply | 3 comments |
headers
adurbin | 1 Sep 2006 01:04
Picon
Favicon

[PATCH] x86_64: put GART into resource map


This patch places the GART into the resource map. This will allow for
the visibility of the GART region in /proc/iomem.

Signed-off-by: Aaron Durbin <adurbin <at> gmail.com>

---

diff --git a/arch/x86_64/kernel/aperture.c b/arch/x86_64/kernel/aperture.c
index 58af8e7..616cfac 100644
--- a/arch/x86_64/kernel/aperture.c
+++ b/arch/x86_64/kernel/aperture.c
 <at>  <at>  -17,6 +17,7  <at>  <at>  #include <linux/mmzone.h>
 #include <linux/pci_ids.h>
 #include <linux/pci.h>
 #include <linux/bitops.h>
+#include <linux/ioport.h>
 #include <asm/e820.h>
 #include <asm/io.h>
 #include <asm/proto.h>
 <at>  <at>  -33,6 +34,18  <at>  <at>  int fallback_aper_force __initdata = 0; 

 int fix_aperture __initdata = 1;

+static struct resource gart_resource = {
+	.name	= "GART",
+	.flags	= IORESOURCE_MEM,
+};
+
+static void __init insert_aperture_resource(u32 aper_base, u32 aper_size)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bjorn Helgaas | 1 Sep 2006 01:06
Picon
Favicon

Re: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

On Thursday 31 August 2006 10:48, keith mannthey wrote:
> On Thu, 2006-08-31 at 02:48 -0400, Len Brown wrote:
> > On Tuesday 29 August 2006 16:04, Moore, Robert wrote:
> > > As far as the unknown exception,
> > > 
> > > >[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
> > > >[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b
> > > >[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31
> > > 
> > > I would guess that the callback routine for walk_resources is returning
> > > a non-zero status value which is causing an immediate abort of the walk
> > > with that value -- and the value is bogus.
> 
>   Before I put this check in acpi_motherboard_add always attached itself
> to any resource type. I simply changed it so if the type is not
> ACPI_RESOURCE_TYPE_IO or ACPI_RESOURCE_TYPE_FIXED_IO it doesn't attach
> and can continue to find the correct device to attach to.
> 
>   Perhaps the motherboard device needs to attach to more device types?  
> 
>   It was suggest by acpi folks to return -EINVAL.  Should something else
> be returned? 

Problem 1: acpi_reserve_io_ranges() needs to return an acpi_status
like AE_OK or AE_CTRL_TERMINATE, not a -EINVAL.

Problem 2: I don't understand how your patch works.  An ACPI device
has a list of resources it uses.  Are you saying that claiming all
the IO port resources of a PNP0C01 or PNP0C02 device causes the ACPI
memory hotplug driver to fail?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paolo | 1 Sep 2006 01:08

Re: Oops while reading netdev stats from /proc/

On Thu, Aug 31, 2006 at 10:00:49PM +0200, oopla wrote:
> ksymoops 2.4.11 on i686 2.4.33.2-i+isdn-k7.  Options used
...
> Aug 28 14:10:29 estero1 kernel: Unable to handle kernel paging request at virtual address 022d9222
> Aug 28 14:10:29 estero1 kernel: c01fb0c7
> Aug 28 14:10:29 estero1 kernel: *pde = 00000000
> Aug 28 14:10:29 estero1 kernel: Oops: 0002
> Aug 28 14:10:29 estero1 kernel: CPU:    0
> Aug 28 14:10:29 estero1 kernel: EIP:    0010:[sprintf_stats+103/176]    Not tainted
...

please keep it aside for a while, till I check the pc - just seen another
oops in the logs with latest 2.4.x kernel:

ksymoops 2.4.11 on i686 2.4.33.2-i+isdn-k7.  Options used
...
Aug 31 15:35:16 estero1 kernel: Unable to handle kernel paging request at virtua
l address 69772f91
Aug 31 15:35:16 estero1 kernel: c0117c71
Aug 31 15:35:16 estero1 kernel: *pde = 00000000
Aug 31 15:35:16 estero1 kernel: Oops: 0002
Aug 31 15:35:16 estero1 kernel: CPU:    0
Aug 31 15:35:16 estero1 kernel: EIP:    0010:[copy_mm+657/704]    Not tainted
Aug 31 15:35:16 estero1 kernel: EFLAGS: 00010202
Aug 31 15:35:16 estero1 kernel: eax: 00004111   ebx: daa20000   ecx: f7e34440   
edx: f748a000
...

and at this point I suspect RAM problems.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bjorn Helgaas | 1 Sep 2006 01:13
Picon
Favicon

Re: [RFC][PATCH 1/2] ACPI: Idle Processor PM Improvements

On Wednesday 30 August 2006 13:43, Matthew Garrett wrote:
> That would be helpful. For the One Laptop Per Child project (or whatever 
> it's called today), it would be advantageous to run without acpi.

Out of curiosity, what is the motivation for running without acpi?
It costs a lot to diverge from the mainstream in areas like that,
so there must be a big payoff.  But maybe if OLPC depends on acpi
being smarter about power or code size or whatever, those improvements
could be made and everybody would benefit.
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Eric Sesterhenn | 1 Sep 2006 01:13
Picon
Picon

[Patch] Uninitialized variable in drivers/net/wan/syncppp.c

hi,

this was spotted by coverity (id #891), when
len is equal to 4, we dont call sppp_lcp_conf_parse_options(),
to initialize rmagic.

Signed-off-by: Eric Sesterhenn <snakebyte <at> gmx.de>

--- linux-2.6.18-rc5/drivers/net/wan/syncppp.c.orig	2006-09-01 00:55:08.000000000 +0200
+++ linux-2.6.18-rc5/drivers/net/wan/syncppp.c	2006-09-01 00:55:45.000000000 +0200
 <at>  <at>  -505,14 +505,15  <at>  <at>  static void sppp_lcp_input (struct sppp 
 			skb->len, h);
 		break;
 	case LCP_CONF_REQ:
-		if (len < 4) {
+		if (len <= 4) {
 			if (sp->pp_flags & PP_DEBUG)
 				printk (KERN_DEBUG"%s: invalid lcp configure request packet length: %d bytes\n",
 					dev->name, len);
 			break;
 		}
-		if (len>4 && !sppp_lcp_conf_parse_options (sp, h, len, &rmagic))
+		if (!sppp_lcp_conf_parse_options (sp, h, len, &rmagic))
 			goto badreq;
+
 		if (rmagic == sp->lcp.magic) {
 			/* Local and remote magics equal -- loopback? */
 			if (sp->pp_loopcnt >= MAXALIVECNT*5) {
(Continue reading)

Permalink | Reply | 3 comments |
headers
Adrian Bunk | 1 Sep 2006 01:19
Picon

Re: dspam as an incoming message filter on LKML

On Thu, Aug 31, 2006 at 12:49:27PM +0100, Just Marc wrote:
> Hi,
> 
> I'm sure many of you have experience with lots of different of spam 
> filters, at least some of you will know how good and effective DSPAM is.
> 
> What I propose is simple, after we teach DSPAM what is ham and what is 
> spam (a quick process on LKML) have one person who will volunteer
> to weed out any false positives (if any) for a short period of time, 
> following that we can just let DSPAM do its magic and enjoy a totally 
> spam free
> LKML.  
> 
> The chance of false positives with the kind of highly specific topics 
> and keywords discussed on LKML is extremely small.
> 
> Comments?

If you think linux-kernel didn't have any spam filtering you should read 
the information linked from the text that is attached to _every_ email 
sent to linux-kernel.

The last spamfilter discussion on this list was less than one month ago.

Please read the list archives before restarting the same old discussion.

> Marc

cu
Adrian
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Garrett | 1 Sep 2006 01:27
Favicon

[OLPC-devel] Re: [RFC][PATCH 1/2] ACPI: Idle Processor PM Improvements

On Thu, Aug 31, 2006 at 05:13:20PM -0600, Bjorn Helgaas wrote:

> Out of curiosity, what is the motivation for running without acpi?
> It costs a lot to diverge from the mainstream in areas like that,
> so there must be a big payoff.  But maybe if OLPC depends on acpi
> being smarter about power or code size or whatever, those improvements
> could be made and everybody would benefit.

The current issues are probably the code size and the somewhat 
specialised needs of OLPC. The hardware is interesting in that the 
framebuffer is designed to carry on reading from memory even if the rest 
of the system is in S3. The aim here is to allow the machine to suspend 
when idle while still giving the impression of being alive. It's 
therefore important that the system come out of suspend as quickly as 
possible in order to avoid spoiling that impression, and suspend as 
quickly as possible in order to maximise the power savings. The 
assumption is that parsing AML is something that would add to these time 
periods without providing any significant extra benefit.

Of course, the other main issue is that providing an ACPI platform would 
require us to actually write a set of ACPI tables. The system is running 
Linuxbios, and every kilobyte that's not used by a static table in the 
BIOS is space that could be used for extra functionality.

I think the basic consensus was that ACPI bought us fairly little other 
than the ability to use the existing suspend/resume code, C state 
transitions and battery monitoring, and that replacing the first was 
probably desirable in any case.
--

-- 
Matthew Garrett | mjg59 <at> srcf.ucam.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Sesterhenn | 1 Sep 2006 01:29
Picon
Picon

[Patch] Uninitialized variable in drivers/scsi/ncr53c8xx.c

hi,

this was spotted by coverity (id #880).
We use simple_strtoul() earlier to initialize pe,
if the function fails, it also does not initialize it.
Therefore we should initialize it ourselves, so the check
in the OPT_TAGS case "if (pe && *pe == '/')" makes sense, and
actually makes the command line parsing more robust.

Signed-off-by: Eric Sesterhenn <snakebyte <at> gmx.de>

--- linux-2.6.18-rc5/drivers/scsi/ncr53c8xx.c.orig	2006-09-01 01:25:09.000000000 +0200
+++ linux-2.6.18-rc5/drivers/scsi/ncr53c8xx.c	2006-09-01 01:25:26.000000000 +0200
 <at>  <at>  -692,7 +692,7  <at>  <at>  static int __init sym53c8xx__setup(char 
 	int xi = 0;

 	while (cur != NULL && (pc = strchr(cur, ':')) != NULL) {
-		char *pe;
+		char *pe = NULL;

 		val = 0;
 		pv = pc;
Permalink | Reply | 2 comments |
headers
adurbin | 1 Sep 2006 01:33
Picon
Favicon

[PATCH] x86_64: insert IOAPIC(s) and Local APIC into resource map


This patch places the IOAPIC(s) and the Local APIC specified by ACPI
tables into the resource map. The APICs will then be visible within
/proc/iomem

Signed-off-by: Aaron Durbin <adurbin <at> google.com>

---

diff --git a/arch/x86_64/kernel/apic.c b/arch/x86_64/kernel/apic.c
index 2b8cef0..d9c677b 100644
--- a/arch/x86_64/kernel/apic.c
+++ b/arch/x86_64/kernel/apic.c
 <at>  <at>  -25,6 +25,7  <at>  <at>  #include <linux/mc146818rtc.h>
 #include <linux/kernel_stat.h>
 #include <linux/sysdev.h>
 #include <linux/module.h>
+#include <linux/ioport.h>

 #include <asm/atomic.h>
 #include <asm/smp.h>
 <at>  <at>  -43,6 +44,11  <at>  <at>  int apic_calibrate_pmtmr __initdata;

 int disable_apic_timer __initdata;

+static struct resource lapic_resource = {
+	.name = "Local APIC",
+	.flags = IORESOURCE_MEM | IORESOURCE_BUSY,
+};
+
(Continue reading)

Permalink | Reply | 1 comment |

Gmane