Manfred:
If you want to access values 65535 from your app you have 2 options:
1) use the new msqid64_ds structure. You must pass IPC_64 to the msgctl
call. This is the only option if you need correct 32-bit uids.
glibc 2.2 will support this natively without needing any changes to your
On Tue, 5 Apr 2005, Andi Kleen wrote:
Alternatively you can try to boot with noapic. Does that help?
Yes, with 'noapic' the system boots normally and the clock runs at normal
speed.
dmesg of 2.6.11.6 without any command line options. (default: ACPI
enabled, APIC enabled):
I booted with 'apic=debug' in case this is useful to find out what's
wrong.
dmesg of 2.6.11.6 with ACPI enabled, APIC enabled, 'apic=debug':
http://www-personal.engin.umich.edu/~wingc/apictimer/dmesg/dmesg-2.6.11.6-acpi-apicdebug
(clock runs at double speed)
dmesg of 2.6.11.6
here's the patch for x86_64
The kernel is compiling... I'll try it when it finishes.
-Chris
--- linux-2.6.11.6/arch/x86_64/kernel/setup.c.orig 2005-03-25
22:28:14.0 -0500
+++ linux-2.6.11.6/arch/x86_64/kernel/setup.c 2005-04-05 15:05:47.656886736
-0400
@@ -333,6 +333,12 @@
On Tue, 5 Apr 2005, Andi Kleen wrote:
Some more debugging first might be good. Perhaps it is the same issue
many Nvidia boards have with the APIC timer override being wrong;
although in this case it should more not tick at all, but might
be still worth a try.
Try booting with
On Tue, 5 Apr 2005, Andi Kleen wrote:
Try booting with acpi_skip_timer_override
Nope, this doesn't fix the problem. Here's the dmesg of 2.6.11.6 with
'acpi_skip_timer_override apic=debug':
I noticed that the x86_64 kernel has 4 different ways of configuring the
timer interrupt in APIC mode:
arch/x86_64/kernel/io_apic.c :
/* style 1 */
if (pin1 != -1) {
/*
* Ok, does IRQ0 through the IOAPIC work?
*/
/* style 2 */
The attached patch gets the clock to work normally for me without
disabling APIC mode entirely. But I'm still not sure what's going on.
dmesg of 2.6.11.6 with default options (ACPI, APIC, 'apic=debug'):
On Thu, 7 Apr 2005, Andi Kleen wrote:
I'm still seeing 'APIC error on CPU0: 00(40)' messages from time to time.
Thanks for the analysis. The clear_IO_APIC_pin looks quite hackish,
I am not sure I want to put that into the mainline kernel.
Of course. The patch was a simplification, the
Marco:
FWIW, the Red Hat kernel RPMs effectively do the following when they
package kernel modules:
strip -g module.ko
This is done via the script:
/usr/lib/rpm/brp-strip
which is implicitly run on all executable files packaged in the RPM.
If you ensure that the module
I'm testing a system based on a ATI Radeon Xpress 200 motherboard.
(host bridge PCI device 1002:5950)
Something is causing the timer interrupt to be received twice as often as
desired; this makes the clock run at double normal speed.
I first noticed the problem when testing Red Hat 2.4 and 2.6
On Sat, 2 Apr 2005, Mikael Pettersson wrote:
APIC error on CPU0: 00(40)
APIC error on CPU0: 40(40)
Those are received illegal vector errors, and they
typically indicate hardware flakiness or BIOS issues.
Could be inadequate power supply, inadequate cooling,
a BIOS bug (please
On Sun, 3 Apr 2005, Mikael Pettersson wrote:
Well, first step is to try w/o ACPI. ACPI is inherently fragile
and bugs there can easily explain your timer problems. Either
recompile with CONFIG_ACPI=n, or boot with acpi=off pci=noacpi.
When I boot without ACPI (I used 'acpi=off pci=noacpi')
On Mon, 4 Apr 2005, Mikael Pettersson wrote:
In principle ACPI shouldn't be needed, but in its absence the
BIOS must provide an MP table and the x86-64 kernel must still
have code to parse it -- otherwise I/O APIC mode won't work.
I don't know if that's the case or not.
Thanks. What I
2.4 does indeed use 32-bit integers for uid and gid in all places, with
the exception of BSD process accounting (for now). Quota should work fine
with UIDs >65535; however, you can not use the full 32 bits of UID due to
the format of the quota file. (you should be fine with hundreds of
thousands
Manfred:
> If you want to access values > 65535 from your app you have 2 options:
>
> 1) use the new msqid64_ds structure. You must pass IPC_64 to the msgctl
> call. This is the only option if you need correct 32-bit uids.
glibc 2.2 will support this natively without needing any changes to
I'm testing a system based on a ATI Radeon Xpress 200 motherboard.
(host bridge PCI device 1002:5950)
Something is causing the timer interrupt to be received twice as often as
desired; this makes the clock run at double normal speed.
I first noticed the problem when testing Red Hat 2.4 and 2.6
On Sat, 2 Apr 2005, Mikael Pettersson wrote:
> > APIC error on CPU0: 00(40)
> > APIC error on CPU0: 40(40)
>
> Those are "received illegal vector" errors, and they
> typically indicate hardware flakiness or BIOS issues.
>
> Could be inadequate power supply, inadequate cooling,
> a BIOS
On Sun, 3 Apr 2005, Mikael Pettersson wrote:
> Well, first step is to try w/o ACPI. ACPI is inherently fragile
> and bugs there can easily explain your timer problems. Either
> recompile with CONFIG_ACPI=n, or boot with "acpi=off pci=noacpi".
When I boot without ACPI (I used 'acpi=off
On Mon, 4 Apr 2005, Mikael Pettersson wrote:
> In principle ACPI shouldn't be needed, but in its absence the
> BIOS must provide an MP table and the x86-64 kernel must still
> have code to parse it -- otherwise I/O APIC mode won't work.
> I don't know if that's the case or not.
Thanks. What I
On Tue, 5 Apr 2005, Andi Kleen wrote:
> Alternatively you can try to boot with noapic. Does that help?
Yes, with 'noapic' the system boots normally and the clock runs at normal
speed.
dmesg of 2.6.11.6 without any command line options. (default: ACPI
enabled, APIC enabled):
I booted with 'apic=debug' in case this is useful to find out what's
wrong.
dmesg of 2.6.11.6 with ACPI enabled, APIC enabled, 'apic=debug':
http://www-personal.engin.umich.edu/~wingc/apictimer/dmesg/dmesg-2.6.11.6-acpi-apicdebug
(clock runs at double speed)
dmesg of 2.6.11.6
here's the patch for x86_64
The kernel is compiling... I'll try it when it finishes.
-Chris
--- linux-2.6.11.6/arch/x86_64/kernel/setup.c.orig 2005-03-25
22:28:14.0 -0500
+++ linux-2.6.11.6/arch/x86_64/kernel/setup.c 2005-04-05 15:05:47.656886736
-0400
@@ -333,6 +333,12 @@
On Tue, 5 Apr 2005, Andi Kleen wrote:
> Some more debugging first might be good. Perhaps it is the same issue
> many Nvidia boards have with the APIC timer override being wrong;
> although in this case it should more not tick at all, but might
> be still worth a try.
> Try booting with
On Tue, 5 Apr 2005, Andi Kleen wrote:
> Try booting with acpi_skip_timer_override
Nope, this doesn't fix the problem. Here's the dmesg of 2.6.11.6 with
'acpi_skip_timer_override apic=debug':
I noticed that the x86_64 kernel has 4 different ways of configuring the
timer interrupt in APIC mode:
arch/x86_64/kernel/io_apic.c :
/* style 1 */
if (pin1 != -1) {
/*
* Ok, does IRQ0 through the IOAPIC work?
*/
/* style 2 */
The attached patch gets the clock to work normally for me without
disabling APIC mode entirely. But I'm still not sure what's going on.
dmesg of 2.6.11.6 with default options (ACPI, APIC, 'apic=debug'):
On Thu, 7 Apr 2005, Andi Kleen wrote:
> >
> > I'm still seeing 'APIC error on CPU0: 00(40)' messages from time to time.
>
> Thanks for the analysis. The clear_IO_APIC_pin looks quite hackish,
> I am not sure I want to put that into the mainline kernel.
Of course. The patch was a
Marco:
FWIW, the Red Hat kernel RPMs effectively do the following when they
package kernel modules:
strip -g
This is done via the script:
/usr/lib/rpm/brp-strip
which is implicitly run on all executable files packaged in the RPM.
If you ensure that the module .ko file
29 matches
Mail list logo
