> Ping! Tony, can you let me know your plans for this patch? I'd
> like to get it into a distro release, and of course, it's best if
> you accept it first.
I'll put it in soon. My only vague concern is whether it should be more
accessible for other OEMs who want to do the SAL/ACPI sharing thing
> If you don't object to the two patches, can you incorporate them
> as originally posted? If you'd prefer a different approach, I'd
> be happy to rework them, of course.
I think that adding 4K to the kernel (about 0.04% increase looking
at a recent build ... or 0.0001% of total memory on a 4G sy
> -#define ACPI_ID_LEN 9
> +#define ACPI_ID_LEN 16 /* only 9 bytes needed here, 16 bytes are used */
What will happen if someone uses more than 9 bytes? With the old
limit there would be a compile time error it someone initialized
with:
{"PNP0C0ABCDEFGH", 0},
But if we change ACPI_ID_
>>> struct acpi_device_id {
>>> __u8 id[ACPI_ID_LEN];
>>> + __u8 dummy[FILLUP_LEN];
>>> kernel_ulong_t driver_data;
>>> };
>>
>> What's so special about this structure that we get an error?
>
> It's special because it's a device_id structure, and those structures
> must come out identic
> Adrian Bunk: scripts/mod/file2alias.c is compiled with HOSTCC and ensures that
> kernel_ulong_t is correct, but it can't cope with different padding on
> different architectures.
Surely this is the root cause ... you can't expect that the alignment
rules of HOSTCC to make any sense for an arbitr
> Tony, it looks like the patch has not hit Linus tree yet:
Huh? I can see it in his tree via gitweb. Here's the patch:
http://tinyurl.com/3csnu6
and the raw "blob" for sba_iommu.c:
http://tinyurl.com/397cy6
[Scroll down to line 2018 and you'll see the new code in place].
S
> commit 8c8eb78f673c07b60f31751e1e47ac367c60c6b7
Oops. I cut & pasted the wrong commit id. The fix went in as
commit 7091138fb762aed22317b4ff91eb211e7da3865c.
> FYI, I did a git pull yesterday just before I hit this issue so I should
> have had the latest stuff.
So this confuses me. Linus pu
Last of the "Section mismatch" errors from ia64 builds! acpi_map_pxm_to_node()
is defined with attribute __cpuinit, but is called by "normal" kernel functions
acpi_getnode() and acpi_map_cpu2node().
Commit f363d16fbb9374c0bd7f2757d412c287169094c9 moved the data structures on
which this routine ope
> This seems to make it through my evil config script that tries everything --
> by making the two failing configs I sent you simply impossible.
Passes through my regular build regression script (which doesn't try everything,
but does hit eleven different configs) too.
Thanks
-Tony
-
To unsubscr
> Some of the IA64 code assumes that ACPI is optional,
> and some assumes that it is not.
The situation now is that the simulator doesn't want ACPI, and everything
else needs it (even "allnoconfig" ends up with CONFIG_ACPI=y!). So the
solution that you suggest near the end of your mail of making
> I'm working on the alignment issue also, should be a fix this week.
With Bjorn's tip on using console=uart,mmio,0x{address} I can now
get a complete trace from boot using acpi_dbg_level = 0xff ...
well in theory I can, I started the boot two days ago and have
2.2 million lines of output so f
> This only contains the output of stores to the ACPI "debug" object,
> not the full trace output. However, "_CRS 0" may help
So ignoring ACPI_DEBUG=y for the moment, I put in a WARN_ON() in the
unaligned trap handler to get some stack traces when the unaligned
access happened.
Here's the boot lo
> This only contains the output of stores to the ACPI "debug"
> object, not the full trace output. However, "_CRS 0" may help
Ah yes. I'd dropped the acpi_dbg_level = 0xff; while trying
to figure out what was going wrong with CONFIG_ACPI_DEBUG=y.
Putting it back in, 16MB is not enough for lo
A 16MB log_buf was enough.
Here is the initial trace up until the unaligned access messages:
Linux version 2.6.16-rc2-zx1-smp ([EMAIL PROTECTED]) (gcc version 3.4.3
20050227 (Red Hat 3.4.3-22.1)) #7 SMP Fri Feb 10 15:17:06 PST 2006
EFI v1.10 by HP: SALsystab=0x3fefa000 ACPI 2.0=0x3fd5e000
SMBIOS=
> That looks good. You'll probably need to increase your dmesg buffer
> or send the output to a serial port, since you will get megabytes
> of info.
I only have a serial port on this machine ... but all the interesting
output happens before it is enabled ... i.e. is buffered up in log_buf
until th
>Does any debug info come out?
Perhaps I was too impatient ... I just assumed it was hung
because it hadn't said anything for a minute after the
"Loading initrd" message. When I came back to the console
all sorts of messages were streaming past.
I restarted ... the delay is ~10 minutes, the the
> Enabling debugging in the ACPI subsystem will certainly give this
> information. AcpiDebugLevel = 0x00FF works nicely, although
> a lot of trace info is produced.
There is no AcpiDebugLevel in the Linux kernel. I did find a
variable "acpidbg_level" ... so I set CONFIG_ACPI_DEBUG=y and
added
But I goofed and muddled up my two problems. I tried
booting on my zx1 ... which was broken altogether by
recent acpi changes.
Getting back to the rx2620 ... deleting those lines makes
no difference. I still boot ok, I still see the unaligned
access messages.
/proc/acpi/dsdt for that system att
> The alignment stuff is based upon __IA64__ or __ia64__, make sure one
of these is set.
__ia64__ is set
-Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
> You might try removing this code from actypes.h:
>
> /*
> * If possible, pack the following structures to byte alignment
> */
> #ifndef ACPI_MISALIGNMENT_NOT_SUPPORTED
> #pragma pack(1)
> #endif
Either this made things worse, or other changes in the base since
my last test made things worse .
> - if the node is already online.- If the node is offline,
> (It means new node is comming!) then the memory will belongs
> to node 0 yet.
What is the long term plan to address this? Can you make sure
that the new node is always brought online before you get to
this code? Or will you have to
Booting a snapshot of Linus' tree this morning I saw a few (new?)
kernel unaligned access warnings:
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using IOSAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (:00)
kernel unaligned access to 0xe0407ec5a204, ip=0xa
22 matches
Mail list logo
