Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu
On Dec 7, 2007 9:58 AM, Neil Horman <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 07, 2007 at 09:21:44AM -0500, Neil Horman wrote:
> > On Fri, Dec 07, 2007 at 01:22:04AM -0800, Yinghai Lu wrote:
> > > On Dec 7, 2007 12:50 AM, Yinghai Lu <[EMAIL PROTECTED]> wrote:
> > > >
> > > > On Dec 6, 2007 4:33 PM, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> > > ...
> > > > >
> > > > > My feel is that if it is for legacy interrupts only it should not be
> > > > > a problem.
> > > > > Let's investigate and see if we can unconditionally enable this quirk
> > > > > for all opteron systems.
> > > >
> > > > i checked that bit
> > > >
> > > > http://www.openbios.org/viewvc/trunk/LinuxBIOSv2/src/northbridge/amd/amdk8/coherent_ht.c?revision=2596=markup
>
> > >
> > > it should be bit 18 (HTTC_APIC_EXT_ID)
> > >
> > >
> > > YH
> >
> > this seems reasonable, I can reroll the patch for this. As I think about
> > it I'm
> > also going to update the patch to make this check occur for any pci class
> > 0600
> > device from vendor AMD, since its possible that more than just nvidia
> > chipsets
> > can be affected.
> >
> > I'll repost as soon as I've tested, thanks!
> > Neil
>
>
> Ok, New patch attached. It preforms the same function as previously
> described,
> but is more restricted in its application. As Yinghai pointed out, the
> broadcast mask bit (bit 17 in the htcfg register) should only be enabled, if
> the
> extened apic id bit (bit 18 in the same register) is also set. So this patch
> now check for that bit to be turned on first. Also, this patch now adds an
> independent quirk check for all AMD hypertransport host controllers, since its
> possible for this misconfiguration to be present in systems other than
> nvidias.
> The net effect of these changes is, that its now applicable to all AMD systems
> containing hypertransport busses, and is only activated if extended apic ids
> are
> in use, meaning that this quirk guarantees that all processors in a system are
> elligible to receive interrupts from the ioapic, even if their apicid extends
> beyond the nominal 4 bit limitation. Tested successfully by me.
>
> Thanks & Regards
> Neil
>
> Signed-off-by: Neil Horman <[EMAIL PROTECTED]>
>
>
> early-quirks.c | 83
> -
> 1 file changed, 76 insertions(+), 7 deletions(-)
>
>
>
> diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
> index 88bb83e..d5a7b30 100644
> --- a/arch/x86/kernel/early-quirks.c
> +++ b/arch/x86/kernel/early-quirks.c
> @@ -44,6 +44,50 @@ static int __init nvidia_hpet_check(struct
> acpi_table_header *header)
> #endif /* CONFIG_X86_IO_APIC */
> #endif /* CONFIG_ACPI */
>
> +static void __init fix_hypertransport_config(int num, int slot, int func)
> +{
> + u32 htcfg;
> + /*
> +*we found a hypertransport bus
> +*make sure that are broadcasting
> +*interrupts to all cpus on the ht bus
> +*if we're using extended apic ids
> +*/
> + htcfg = read_pci_config(num, slot, func, 0x68);
> + if ((htcfg & (1 << 18)) == 1) {
> + printk(KERN_INFO "Detected use of extended apic ids on
> hypertransport bus\n");
> + if ((htcfg & (1 << 17)) == 0) {
> + printk(KERN_INFO "Enabling hypertransport extended
> apic interrupt broadcast\n");
> + htcfg |= (1 << 17);
> + write_pci_config(num, slot, func, 0x68, htcfg);
> + }
> + }
> +
> +}
> +
> +static void __init check_hypertransport_config()
> +{
> + int num, slot, func;
> + u32 device, vendor;
> + func = 0;
> + for (num = 0; num < 32; num++) {
> + for (slot = 0; slot < 32; slot++) {
> + vendor = read_pci_config(num,slot,func,
> + PCI_VENDOR_ID);
> + device = read_pci_config(num,slot,func,
> + PCI_DEVICE_ID);
> + vendor &= 0x;
> + device >>= 16;
> + if ((vendor == PCI_VENDOR_ID_AMD) &&
> + (device == PCI_DEVICE_ID_AMD_K8_NB))
> + fix_hypertransport_config(num,slot,func);
> + }
> + }
> +
> + return;
> +
> +}
> +
> static void __init nvidia_bugs(void)
> {
> #ifdef CONFIG_ACPI
> @@ -83,6 +127,12 @@ static void __init ati_bugs(void)
> #endif
> }
>
> +static void __init amd_host_bugs(void)
> +{
> + printk(KERN_CRIT "IN AMD_HOST_BUGS\n");
> + check_hypertransport_config();
> +}
> +
> struct chipset {
> u16 vendor;
> void (*f)(void);
> @@ -95,9 +145,16 @@ static struct chipset early_qrk[] __initdata = {
> {}
> };
>
> +static struct chipset early_host_qrk[] __initdata = {
> + { PCI_VENDOR_ID_AMD, amd_host_bugs},
> + {}
> +};
> +
> void __init
Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu
On Dec 7, 2007 9:58 AM, Neil Horman [EMAIL PROTECTED] wrote:
On Fri, Dec 07, 2007 at 09:21:44AM -0500, Neil Horman wrote:
On Fri, Dec 07, 2007 at 01:22:04AM -0800, Yinghai Lu wrote:
On Dec 7, 2007 12:50 AM, Yinghai Lu [EMAIL PROTECTED] wrote:
On Dec 6, 2007 4:33 PM, Eric W. Biederman [EMAIL PROTECTED] wrote:
...
My feel is that if it is for legacy interrupts only it should not be
a problem.
Let's investigate and see if we can unconditionally enable this quirk
for all opteron systems.
i checked that bit
http://www.openbios.org/viewvc/trunk/LinuxBIOSv2/src/northbridge/amd/amdk8/coherent_ht.c?revision=2596view=markup
snip
it should be bit 18 (HTTC_APIC_EXT_ID)
YH
this seems reasonable, I can reroll the patch for this. As I think about
it I'm
also going to update the patch to make this check occur for any pci class
0600
device from vendor AMD, since its possible that more than just nvidia
chipsets
can be affected.
I'll repost as soon as I've tested, thanks!
Neil
Ok, New patch attached. It preforms the same function as previously
described,
but is more restricted in its application. As Yinghai pointed out, the
broadcast mask bit (bit 17 in the htcfg register) should only be enabled, if
the
extened apic id bit (bit 18 in the same register) is also set. So this patch
now check for that bit to be turned on first. Also, this patch now adds an
independent quirk check for all AMD hypertransport host controllers, since its
possible for this misconfiguration to be present in systems other than
nvidias.
The net effect of these changes is, that its now applicable to all AMD systems
containing hypertransport busses, and is only activated if extended apic ids
are
in use, meaning that this quirk guarantees that all processors in a system are
elligible to receive interrupts from the ioapic, even if their apicid extends
beyond the nominal 4 bit limitation. Tested successfully by me.
Thanks Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
early-quirks.c | 83
-
1 file changed, 76 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 88bb83e..d5a7b30 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -44,6 +44,50 @@ static int __init nvidia_hpet_check(struct
acpi_table_header *header)
#endif /* CONFIG_X86_IO_APIC */
#endif /* CONFIG_ACPI */
+static void __init fix_hypertransport_config(int num, int slot, int func)
+{
+ u32 htcfg;
+ /*
+*we found a hypertransport bus
+*make sure that are broadcasting
+*interrupts to all cpus on the ht bus
+*if we're using extended apic ids
+*/
+ htcfg = read_pci_config(num, slot, func, 0x68);
+ if ((htcfg (1 18)) == 1) {
+ printk(KERN_INFO Detected use of extended apic ids on
hypertransport bus\n);
+ if ((htcfg (1 17)) == 0) {
+ printk(KERN_INFO Enabling hypertransport extended
apic interrupt broadcast\n);
+ htcfg |= (1 17);
+ write_pci_config(num, slot, func, 0x68, htcfg);
+ }
+ }
+
+}
+
+static void __init check_hypertransport_config()
+{
+ int num, slot, func;
+ u32 device, vendor;
+ func = 0;
+ for (num = 0; num 32; num++) {
+ for (slot = 0; slot 32; slot++) {
+ vendor = read_pci_config(num,slot,func,
+ PCI_VENDOR_ID);
+ device = read_pci_config(num,slot,func,
+ PCI_DEVICE_ID);
+ vendor = 0x;
+ device = 16;
+ if ((vendor == PCI_VENDOR_ID_AMD)
+ (device == PCI_DEVICE_ID_AMD_K8_NB))
+ fix_hypertransport_config(num,slot,func);
+ }
+ }
+
+ return;
+
+}
+
static void __init nvidia_bugs(void)
{
#ifdef CONFIG_ACPI
@@ -83,6 +127,12 @@ static void __init ati_bugs(void)
#endif
}
+static void __init amd_host_bugs(void)
+{
+ printk(KERN_CRIT IN AMD_HOST_BUGS\n);
+ check_hypertransport_config();
+}
+
struct chipset {
u16 vendor;
void (*f)(void);
@@ -95,9 +145,16 @@ static struct chipset early_qrk[] __initdata = {
{}
};
+static struct chipset early_host_qrk[] __initdata = {
+ { PCI_VENDOR_ID_AMD, amd_host_bugs},
+ {}
+};
+
void __init early_quirks(void)
{
int num, slot, func;
+ u8 found_bridge = 0;
+ u8 found_host = 0;
if (!early_pci_allowed())
return;
@@ -115,18 +172,30 @@ void __init early_quirks(void)
Re: kexec: Cannot determine the file type of arch/x86/boot/bzImage
On 10/16/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: > On Tue, 16 Oct 2007 21:51:13 +0200 Thomas Meyer wrote: > > [adding kexec mailing list] > > > > Hi. > > > > Look at this: > > > > $ file arch/x86/boot/bzImage (tree 821f3eff7cdb9d6c7076effabd46c96c322daed1) > > arch/x86/boot/bzImage: Linux kernel x86 boot executable zImage, version > > 2.6.23 ([EMAIL PROTECTED]) #39, RO-rootFS, root_dev 0x803, swap_dev > > 0x1, Prompt for Videomode > > > > $ file /boot/bzImage-2.6.23 > > /boot/bzImage-2.6.23: Linux kernel x86 boot executable RO-rootFS, > > root_dev 0x803, swap_dev 0x1, Normal VGA > > > > and this: > > > > # kexec -l arch/x86/boot/bzImage > > Cannot determine the file type of arch/x86/boot/bzImage > > > > How to solve this error? #!/bin/bash KERNEL_VER=2.6.24_k8.2 CONSOLE=console=uart8250,io,0x3f8,9600n8 ./kexec -t bzImage -l bzImage_"$KERNEL_VER" --command-line="apic=debug acpi.debug_level=0x000F pci=routeirq nmi_watchdog=2 ramdisk_size=65536 root=/dev/ram0 rw ip=dhcp $CONSOLE" --ramdisk=mydisk8_x86_64.gz YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kexec: Cannot determine the file type of arch/x86/boot/bzImage
On 10/16/07, Randy Dunlap [EMAIL PROTECTED] wrote: On Tue, 16 Oct 2007 21:51:13 +0200 Thomas Meyer wrote: [adding kexec mailing list] Hi. Look at this: $ file arch/x86/boot/bzImage (tree 821f3eff7cdb9d6c7076effabd46c96c322daed1) arch/x86/boot/bzImage: Linux kernel x86 boot executable zImage, version 2.6.23 ([EMAIL PROTECTED]) #39, RO-rootFS, root_dev 0x803, swap_dev 0x1, Prompt for Videomode $ file /boot/bzImage-2.6.23 /boot/bzImage-2.6.23: Linux kernel x86 boot executable RO-rootFS, root_dev 0x803, swap_dev 0x1, Normal VGA and this: # kexec -l arch/x86/boot/bzImage Cannot determine the file type of arch/x86/boot/bzImage How to solve this error? #!/bin/bash KERNEL_VER=2.6.24_k8.2 CONSOLE=console=uart8250,io,0x3f8,9600n8 ./kexec -t bzImage -l bzImage_$KERNEL_VER --command-line=apic=debug acpi.debug_level=0x000F pci=routeirq nmi_watchdog=2 ramdisk_size=65536 root=/dev/ram0 rw ip=dhcp $CONSOLE --ramdisk=mydisk8_x86_64.gz YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] restoring x86 BIOS state before reboot
On 5/11/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote: Pavel Machek wrote: > > I do not think OLPC is using linuxBIOS these days. What they have > certainly looks like Sun's ROM monitor. > That would be OpenFirmware, then. current kernel for x86 support OFW boot patch? YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] restoring x86 BIOS state before reboot
On 5/11/07, H. Peter Anvin [EMAIL PROTECTED] wrote: Pavel Machek wrote: I do not think OLPC is using linuxBIOS these days. What they have certainly looks like Sun's ROM monitor. That would be OpenFirmware, then. current kernel for x86 support OFW boot patch? YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/9/07, Gerd Hoffmann <[EMAIL PROTECTED]> wrote: Refine SCREEN_INFO sanity check for vgacon initialization. Checking video mode field only to see whenever SCREEN_INFO is initialized is not enougth, in some cases it is zero although a vga card is present. Lets additionally check cols and lines. Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]> Cc: Rusty Russell <[EMAIL PROTECTED]> Cc: Andi Kleen <[EMAIL PROTECTED]> Cc: Alan <[EMAIL PROTECTED]> Cc: Ingo Molnar <[EMAIL PROTECTED]> Cc: Eric W. Biederman <[EMAIL PROTECTED]> --- drivers/video/console/vgacon.c |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) Index: vanilla-2.6.21-git11/drivers/video/console/vgacon.c === --- vanilla-2.6.21-git11.orig/drivers/video/console/vgacon.c +++ vanilla-2.6.21-git11/drivers/video/console/vgacon.c @@ -368,9 +368,14 @@ static const char *vgacon_startup(void) #endif } + /* SCREEN_INFO initialized? */ + if ((ORIG_VIDEO_MODE == 0) && + (ORIG_VIDEO_LINES == 0) && + (ORIG_VIDEO_COLS == 0)) + goto no_vga; + /* VGA16 modes are not handled by VGACON */ - if ((ORIG_VIDEO_MODE == 0x00) ||/* SCREEN_INFO not initialized */ - (ORIG_VIDEO_MODE == 0x0D) ||/* 320x200/4 */ + if ((ORIG_VIDEO_MODE == 0x0D) ||/* 320x200/4 */ (ORIG_VIDEO_MODE == 0x0E) ||/* 640x200/4 */ (ORIG_VIDEO_MODE == 0x10) ||/* 640x350/4 */ (ORIG_VIDEO_MODE == 0x12) ||/* 640x480/4 */ it works. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/9/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote: "H. Peter Anvin" <[EMAIL PROTECTED]> writes: We can look in /proc/ioports and see what has reserved the video resources. That should give us a reasonable estimate of the video adapter. We can do an ioctl to the console and see how many lines and columns we have. Reusing boot_params could be nice but if we have the information available in other ways digging it out that way is quite possibly better. Another path: LiuxBIOS+elfboot+payload, and payload is compressed elf (vmlinux+initrd) via lzma. and use kexec to boot final production kernel. We don't need to use boot_params from the first tiny kernel. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/9/07, Eric W. Biederman [EMAIL PROTECTED] wrote: H. Peter Anvin [EMAIL PROTECTED] writes: We can look in /proc/ioports and see what has reserved the video resources. That should give us a reasonable estimate of the video adapter. We can do an ioctl to the console and see how many lines and columns we have. Reusing boot_params could be nice but if we have the information available in other ways digging it out that way is quite possibly better. Another path: LiuxBIOS+elfboot+payload, and payload is compressed elf (vmlinux+initrd) via lzma. and use kexec to boot final production kernel. We don't need to use boot_params from the first tiny kernel. YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/9/07, Gerd Hoffmann [EMAIL PROTECTED] wrote: Refine SCREEN_INFO sanity check for vgacon initialization. Checking video mode field only to see whenever SCREEN_INFO is initialized is not enougth, in some cases it is zero although a vga card is present. Lets additionally check cols and lines. Signed-off-by: Gerd Hoffmann [EMAIL PROTECTED] Cc: Rusty Russell [EMAIL PROTECTED] Cc: Andi Kleen [EMAIL PROTECTED] Cc: Alan [EMAIL PROTECTED] Cc: Ingo Molnar [EMAIL PROTECTED] Cc: Eric W. Biederman [EMAIL PROTECTED] --- drivers/video/console/vgacon.c |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) Index: vanilla-2.6.21-git11/drivers/video/console/vgacon.c === --- vanilla-2.6.21-git11.orig/drivers/video/console/vgacon.c +++ vanilla-2.6.21-git11/drivers/video/console/vgacon.c @@ -368,9 +368,14 @@ static const char *vgacon_startup(void) #endif } + /* SCREEN_INFO initialized? */ + if ((ORIG_VIDEO_MODE == 0) + (ORIG_VIDEO_LINES == 0) + (ORIG_VIDEO_COLS == 0)) + goto no_vga; + /* VGA16 modes are not handled by VGACON */ - if ((ORIG_VIDEO_MODE == 0x00) ||/* SCREEN_INFO not initialized */ - (ORIG_VIDEO_MODE == 0x0D) ||/* 320x200/4 */ + if ((ORIG_VIDEO_MODE == 0x0D) ||/* 320x200/4 */ (ORIG_VIDEO_MODE == 0x0E) ||/* 640x200/4 */ (ORIG_VIDEO_MODE == 0x10) ||/* 640x350/4 */ (ORIG_VIDEO_MODE == 0x12) ||/* 640x480/4 */ it works. YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/8/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote: H. Peter Anvin wrote: Of course, one could argue that since all of those were obsolete by the time Linux was first created, that it probably doesn't matter and that isVGA == 0 pretty much means the more obvious thing. MDA/HGC stuck around for quite a while for debugging, since it was non-conflicting with VGA, but even if it is, the reason people put it in their system is to have something that the OS doesn't readily see. so the kexec tools need to scan the pci devices list, and find out how to set real_mode.isVGA and orig_video_mode, also need to parse the comand line about vga console. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote: Since the whole point is to detect the case where we don't have a screen at all it makes sense to check several additional variables and make certain that they are all 0. Agreed? need one good way to find if there is support vga console. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/8/07, Vivek Goyal <[EMAIL PROTECTED]> wrote: On Tue, May 08, 2007 at 11:51:35AM -0700, yhlu wrote: This message generally appears if you did not specify --args-linux on kexec command line while loading vmlinux. besides elf-x86_64, still need --args-linux to pass sth? but how to let it load ramdisk? YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote: "H. Peter Anvin" <[EMAIL PROTECTED]> writes: I believe YH is asking how we setup real_mode_data in /sbin/kexec. pxelinux: SCREEN_INFO.orig_video_mode = 3 SCREEN_INFO.orig_x = 0 SCREEN_INFO.orig_y = 24 x86_boot_params[] : : 00 18 ff ff 08 00 03 50 8c c8 03 00 8e c0 19 01 0010: 10 00 7c fb fc be 31 00 ac 20 c0 74 09 b4 0e bb 0020: 07 00 cd 10 eb f2 31 c0 cd 16 cd 19 ea f0 ff 00 0030: f0 44 69 72 65 63 74 20 62 6f 6f 74 15 00 10 00 current kexec: SCREEN_INFO.orig_video_mode = 0 SCREEN_INFO.orig_x = 0 SCREEN_INFO.orig_y = 3 x86_boot_params[] : : 00 03 00 fc 00 00 00 50 8c c8 00 00 8e c0 19 01 0010: 10 00 7c fb fc be 31 00 ac 20 c0 74 09 b4 0e bb 0020: 3f a3 00 16 eb f2 31 c0 cd 16 cd 19 ea f0 ff 00 0030: f0 44 69 72 65 63 74 20 62 6f 6f 74 15 00 20 00 YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/8/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote: Jeremy Fitzhardinge wrote: Specifically boot_params.screen_info isn't being properly set up by the caller. will setup real_mode_data in kexec path? YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote: You might try a git-bisect, or if it is just these patches walking through them one-by-one. f82af20e1a028e16b9bb11da081fa1148d40fa6a is first bad commit commit f82af20e1a028e16b9bb11da081fa1148d40fa6a Author: Gerd Hoffmann <[EMAIL PROTECTED]> Date: Wed May 2 19:27:19 2007 +0200 [PATCH] x86-64: ignore vgacon if hardware not present Avoid trying to set up vgacon if there's no vga hardware present. Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> Cc: Alan <[EMAIL PROTECTED]> Acked-by: Ingo Molnar <[EMAIL PROTECTED]> YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
the mkelfImage 2.7 patch is at https://lists.linux-foundation.org/pipermail/fastboot/attachments/20061108/009064a6/mkelfImage_2.7_amd64_1108-0001.obj YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
Eric, i tried to load vmlinux with kexec and got Ramdisks not supported with generic elf arguments So i use mkelfImage with my patch ( convert elf64 to elf32) to make another elf32. and loaded with kexec and can not get vga console too. ---serial console works well. the mkelfImage 2.7 patch is at http://72.14.253.104/search?q=cache:fuxOvFw3ZIIJ:lists.osdl.org/pipermail/fastboot/attachments/20061108/009064a6/attachment.obj+mkelfImage+2.7+patch=en=clnk=4=us So the problem is not bzImage related, but in somewhere in vmlinux. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/8/07, Vivek Goyal <[EMAIL PROTECTED]> wrote: setup.S is never executed while doing kexec (unless somebody chooses to do a real mode entry) and these patches don't change this beahviour. Tomorrow I will test VGA behaviour on my machine. Are you using some special frame buffer mode etc? I disabled the FB in the kernel. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote: Yes. setup.S has always been skipped by bzImage via the kexec path unless you explicitly tell /sbin/kexec to use the 16bit entry point. Is not having a VGA console a new thing, or it something you just noticed? Eric before the changes, it works well. with --real-mode, it will reset the machine. with --reset-vga, i will get Kernel alive kernel direct mapping tables up to 1 @ 8000-d000 on VGA monitor. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/2/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote: Vivek Goyal <[EMAIL PROTECTED]> writes: > On Wed, May 02, 2007 at 02:59:11PM -0700, H. Peter Anvin wrote: >> Jeremy Fitzhardinge wrote: >> > >> > So the bzImage structure is currently: >> > >> >1. old-style boot sector >> >2. old-style boot info, followed by 0xaa55 at the end of the sector >> >3. the HdrS boot param block >> >4. setup.S boot code >> >5. the self-decompressing kernel >> > Eric, With the latest change that make vmlinux to be elf64 and make bzImage do switch to 64bit long mode, the kernel started via kexec can not get VGA console. but the serial console works well. I wonder if the setup.S is skipped in bzImage via kexec path. or i missed sth? #!/bin/bash ./kexec -t bzImage -l bzImage_2.6.22_k8.1 --command-line="apic=debug acpi_dbg_level=0x0007 pci=routeirq snd-hda-intel.enable_msi=1 ramdisk_size=65536 root=/dev/ram0 rw ip=dhcp console=tty0 console=ttyS0,9600n8" --ramdisk=mydisk8_x86_64.gz YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/2/07, Eric W. Biederman [EMAIL PROTECTED] wrote: Vivek Goyal [EMAIL PROTECTED] writes: On Wed, May 02, 2007 at 02:59:11PM -0700, H. Peter Anvin wrote: Jeremy Fitzhardinge wrote: So the bzImage structure is currently: 1. old-style boot sector 2. old-style boot info, followed by 0xaa55 at the end of the sector 3. the HdrS boot param block 4. setup.S boot code 5. the self-decompressing kernel Eric, With the latest change that make vmlinux to be elf64 and make bzImage do switch to 64bit long mode, the kernel started via kexec can not get VGA console. but the serial console works well. I wonder if the setup.S is skipped in bzImage via kexec path. or i missed sth? #!/bin/bash ./kexec -t bzImage -l bzImage_2.6.22_k8.1 --command-line=apic=debug acpi_dbg_level=0x0007 pci=routeirq snd-hda-intel.enable_msi=1 ramdisk_size=65536 root=/dev/ram0 rw ip=dhcp console=tty0 console=ttyS0,9600n8 --ramdisk=mydisk8_x86_64.gz YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/8/07, Eric W. Biederman [EMAIL PROTECTED] wrote: Yes. setup.S has always been skipped by bzImage via the kexec path unless you explicitly tell /sbin/kexec to use the 16bit entry point. Is not having a VGA console a new thing, or it something you just noticed? Eric before the changes, it works well. with --real-mode, it will reset the machine. with --reset-vga, i will get Kernel alive kernel direct mapping tables up to 1 @ 8000-d000 on VGA monitor. YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/8/07, Vivek Goyal [EMAIL PROTECTED] wrote: setup.S is never executed while doing kexec (unless somebody chooses to do a real mode entry) and these patches don't change this beahviour. Tomorrow I will test VGA behaviour on my machine. Are you using some special frame buffer mode etc? I disabled the FB in the kernel. YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
Eric, i tried to load vmlinux with kexec and got Ramdisks not supported with generic elf arguments So i use mkelfImage with my patch ( convert elf64 to elf32) to make another elf32. and loaded with kexec and can not get vga console too. ---serial console works well. the mkelfImage 2.7 patch is at http://72.14.253.104/search?q=cache:fuxOvFw3ZIIJ:lists.osdl.org/pipermail/fastboot/attachments/20061108/009064a6/attachment.obj+mkelfImage+2.7+patchhl=enct=clnkcd=4gl=us So the problem is not bzImage related, but in somewhere in vmlinux. YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
the mkelfImage 2.7 patch is at https://lists.linux-foundation.org/pipermail/fastboot/attachments/20061108/009064a6/mkelfImage_2.7_amd64_1108-0001.obj YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/8/07, Eric W. Biederman [EMAIL PROTECTED] wrote: You might try a git-bisect, or if it is just these patches walking through them one-by-one. f82af20e1a028e16b9bb11da081fa1148d40fa6a is first bad commit commit f82af20e1a028e16b9bb11da081fa1148d40fa6a Author: Gerd Hoffmann [EMAIL PROTECTED] Date: Wed May 2 19:27:19 2007 +0200 [PATCH] x86-64: ignore vgacon if hardware not present Avoid trying to set up vgacon if there's no vga hardware present. Signed-off-by: Jeremy Fitzhardinge [EMAIL PROTECTED] Signed-off-by: Rusty Russell [EMAIL PROTECTED] Signed-off-by: Andi Kleen [EMAIL PROTECTED] Cc: Alan [EMAIL PROTECTED] Acked-by: Ingo Molnar [EMAIL PROTECTED] YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/8/07, H. Peter Anvin [EMAIL PROTECTED] wrote: Jeremy Fitzhardinge wrote: Specifically boot_params.screen_info isn't being properly set up by the caller. will setup real_mode_data in kexec path? YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/8/07, Eric W. Biederman [EMAIL PROTECTED] wrote: H. Peter Anvin [EMAIL PROTECTED] writes: I believe YH is asking how we setup real_mode_data in /sbin/kexec. pxelinux: SCREEN_INFO.orig_video_mode = 3 SCREEN_INFO.orig_x = 0 SCREEN_INFO.orig_y = 24 x86_boot_params[] : : 00 18 ff ff 08 00 03 50 8c c8 03 00 8e c0 19 01 0010: 10 00 7c fb fc be 31 00 ac 20 c0 74 09 b4 0e bb 0020: 07 00 cd 10 eb f2 31 c0 cd 16 cd 19 ea f0 ff 00 0030: f0 44 69 72 65 63 74 20 62 6f 6f 74 15 00 10 00 current kexec: SCREEN_INFO.orig_video_mode = 0 SCREEN_INFO.orig_x = 0 SCREEN_INFO.orig_y = 3 x86_boot_params[] : : 00 03 00 fc 00 00 00 50 8c c8 00 00 8e c0 19 01 0010: 10 00 7c fb fc be 31 00 ac 20 c0 74 09 b4 0e bb 0020: 3f a3 00 16 eb f2 31 c0 cd 16 cd 19 ea f0 ff 00 0030: f0 44 69 72 65 63 74 20 62 6f 6f 74 15 00 20 00 YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/8/07, Vivek Goyal [EMAIL PROTECTED] wrote: On Tue, May 08, 2007 at 11:51:35AM -0700, yhlu wrote: This message generally appears if you did not specify --args-linux on kexec command line while loading vmlinux. besides elf-x86_64, still need --args-linux to pass sth? but how to let it load ramdisk? YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/8/07, Eric W. Biederman [EMAIL PROTECTED] wrote: Since the whole point is to detect the case where we don't have a screen at all it makes sense to check several additional variables and make certain that they are all 0. Agreed? need one good way to find if there is support vga console. YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/8/07, H. Peter Anvin [EMAIL PROTECTED] wrote: H. Peter Anvin wrote: Of course, one could argue that since all of those were obsolete by the time Linux was first created, that it probably doesn't matter and that isVGA == 0 pretty much means the more obvious thing. MDA/HGC stuck around for quite a while for debugging, since it was non-conflicting with VGA, but even if it is, the reason people put it in their system is to have something that the OS doesn't readily see. so the kexec tools need to scan the pci devices list, and find out how to set real_mode.isVGA and orig_video_mode, also need to parse the comand line about vga console. YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device
On 12/2/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote: Please yank the direct out of the filename if you are making something like this out of it. That was my note I was going direct to hardware which is pretty much assumed if you are in LinuxBIOS. Yes, I adapted the code to used in LinuxBIOS, including CAR stage code and RAM satge code. I didn't have debug cable plugged yet. BTW in kernel earlyprintk or prink, you could use read_pci_config/write_pci_config before PCI system is loaded. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device
On 12/2/06, Eric W. Biederman [EMAIL PROTECTED] wrote: Please yank the direct out of the filename if you are making something like this out of it. That was my note I was going direct to hardware which is pretty much assumed if you are in LinuxBIOS. Yes, I adapted the code to used in LinuxBIOS, including CAR stage code and RAM satge code. I didn't have debug cable plugged yet. BTW in kernel earlyprintk or prink, you could use read_pci_config/write_pci_config before PCI system is loaded. YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12.3 clock drifting twice too fast (amd64)
thanks
YH
On 8/17/05, Jeff Mahoney <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> fyhlu wrote:
> > Me too. If use latest kernel mouse is dead.
> >
> > By the way, did you solve the battery problem in Linux. "Can not read
> > battery status"
>
> Yes. It's a problem with the DSDT. Install pmtools (for iasl - the acpi
> compiler) and grab
> ftp://ftp.suse.com/pub/people/jeffm/acpi/Acer_Ferrari_4000.DSDT.asl
>
> You'll need to enable ACPI_CUSTOM_DSDT to do use it, or if you're on a
> SUSE system (sorry, I don't know if/which other systems support this),
> you can enable a new DSDT by including it in the init{rd,ramfs}. (See
> the -a option to mkinitrd)
>
> The attached script will turn your AML file into a character array for
> use with ACPI_CUSTOM_DSDT.
>
> There are other issues that need to be worked out in the DSDT, and since
> I'm not an ACPI guru (or even anything beyond a casual observer), this
> may take some time. Specifically, I get this ...
> nsxfeval-0251 [06] acpi_evaluate_object : Handle is NULL and Pathname
> is relative
> ... for several paths, which a bit of debugging tells me is _PR[0-3]
> from the root node. Unfortunately, there is no instance of _PR[0-3] in
> the DSDT asl file.
>
> - -Jeff
>
> - --
> Jeff Mahoney
> SuSE Labs
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.0 (GNU/Linux)
>
> iD8DBQFDAzmpLPWxlyuTD7IRAhupAJ9rAXNZAX3tzHxCzwYuPUE1LO/ivwCghvTT
> 8uaZtso9gnu9FGk8Imjk94k=
> =Iesw
> -END PGP SIGNATURE-
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12.3 clock drifting twice too fast (amd64)
Me too. If use latest kernel mouse is dead. By the way, did you solve the battery problem in Linux. "Can not read battery status" YH On 8/16/05, Jeff Mahoney <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Christoph Lameter wrote: > > On Tue, 16 Aug 2005, jerome lacoste wrote: > > > >>Installed stock 2.6.12.3 on a brand new amd64 box with an Asus extreme > >>AX 300 SE/t mainboard. > >> > >>I remember seeing a message in the boot saying something along: > >> > >> "cannot connect to hardware clock." > >> > >>And now I see that the time is changing too fast (about 2 seconds each > >>second). > > > > The timer interrupt is probably called twice for some reason and therefore > > time runs twice as fast. Try using HPET for interrupt timing. > > > >>I don't have visual on the boot sequence anymore (only remote access). > > > > Use serial console or netconsole. The boot information is logged. Try > > dmesg. > > I am seeing similar results on my Acer Ferrari 4000 (Turion64 ML-37). It > does appear that time is running 2x normal time. > > Booting with noapictimer cleared up the timing issues, though it did > introduce some IRQ badness. > > - -Jeff > > - -- > Jeff Mahoney > SuSE Labs > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.0 (GNU/Linux) > > iD8DBQFDAnPzLPWxlyuTD7IRAuQ+AKCoK4Bvj9YaSxK1cYzK/LQUGcj2pQCgmBKK > hGeSfGE+CvdNzqW3pN5LQq8= > =wtra > -END PGP SIGNATURE- > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12.3 clock drifting twice too fast (amd64)
Me too. If use latest kernel mouse is dead. By the way, did you solve the battery problem in Linux. Can not read battery status YH On 8/16/05, Jeff Mahoney [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph Lameter wrote: On Tue, 16 Aug 2005, jerome lacoste wrote: Installed stock 2.6.12.3 on a brand new amd64 box with an Asus extreme AX 300 SE/t mainboard. I remember seeing a message in the boot saying something along: cannot connect to hardware clock. And now I see that the time is changing too fast (about 2 seconds each second). The timer interrupt is probably called twice for some reason and therefore time runs twice as fast. Try using HPET for interrupt timing. I don't have visual on the boot sequence anymore (only remote access). Use serial console or netconsole. The boot information is logged. Try dmesg. I am seeing similar results on my Acer Ferrari 4000 (Turion64 ML-37). It does appear that time is running 2x normal time. Booting with noapictimer cleared up the timing issues, though it did introduce some IRQ badness. - -Jeff - -- Jeff Mahoney SuSE Labs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDAnPzLPWxlyuTD7IRAuQ+AKCoK4Bvj9YaSxK1cYzK/LQUGcj2pQCgmBKK hGeSfGE+CvdNzqW3pN5LQq8= =wtra -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12.3 clock drifting twice too fast (amd64)
thanks
YH
On 8/17/05, Jeff Mahoney [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
fyhlu wrote:
Me too. If use latest kernel mouse is dead.
By the way, did you solve the battery problem in Linux. Can not read
battery status
Yes. It's a problem with the DSDT. Install pmtools (for iasl - the acpi
compiler) and grab
ftp://ftp.suse.com/pub/people/jeffm/acpi/Acer_Ferrari_4000.DSDT.asl
You'll need to enable ACPI_CUSTOM_DSDT to do use it, or if you're on a
SUSE system (sorry, I don't know if/which other systems support this),
you can enable a new DSDT by including it in the init{rd,ramfs}. (See
the -a option to mkinitrd)
The attached script will turn your AML file into a character array for
use with ACPI_CUSTOM_DSDT.
There are other issues that need to be worked out in the DSDT, and since
I'm not an ACPI guru (or even anything beyond a casual observer), this
may take some time. Specifically, I get this ...
nsxfeval-0251 [06] acpi_evaluate_object : Handle is NULL and Pathname
is relative
... for several paths, which a bit of debugging tells me is _PR[0-3]
from the root node. Unfortunately, there is no instance of _PR[0-3] in
the DSDT asl file.
- -Jeff
- --
Jeff Mahoney
SuSE Labs
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFDAzmpLPWxlyuTD7IRAhupAJ9rAXNZAX3tzHxCzwYuPUE1LO/ivwCghvTT
8uaZtso9gnu9FGk8Imjk94k=
=Iesw
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Atyfb questions and issues
last year some time, I have manually the patch from 2.4 to 2.6. my patch result is the same as 2.4. It only works when bios doesn't do the init. Then if the BIOS do the init, it will hang there. I assume something only can be done once. YH On 8/15/05, James Simmons <[EMAIL PROTECTED]> wrote: > > > james, > > > > I remember that xlinit in 2.6 kernel only works when BIOS option-rom > > really init fb. > > It can not work if the BIOS option rom is not executed. > > > > For 2.4, it reversed, it can not work if BIOS opton-rom is executed. > > Only work if BIOS don't excute the option rom. > > You are right. The init_from_bios is called on x86 in aty_setup_generic > before aty_init which calls the biosless initialization. The question is > what needs to be done to properly fix it? > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Atyfb questions and issues
last year some time, I have manually the patch from 2.4 to 2.6. my patch result is the same as 2.4. It only works when bios doesn't do the init. Then if the BIOS do the init, it will hang there. I assume something only can be done once. YH On 8/15/05, James Simmons [EMAIL PROTECTED] wrote: james, I remember that xlinit in 2.6 kernel only works when BIOS option-rom really init fb. It can not work if the BIOS option rom is not executed. For 2.4, it reversed, it can not work if BIOS opton-rom is executed. Only work if BIOS don't excute the option rom. You are right. The init_from_bios is called on x86 in aty_setup_generic before aty_init which calls the biosless initialization. The question is what needs to be done to properly fix it? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Atyfb questions and issues
james, I remember that xlinit in 2.6 kernel only works when BIOS option-rom really init fb. It can not work if the BIOS option rom is not executed. For 2.4, it reversed, it can not work if BIOS opton-rom is executed. Only work if BIOS don't excute the option rom. YH On 8/12/05, James Simmons <[EMAIL PROTECTED]> wrote: > > > > I have the following issue. I am trying to get an ATI Rage XL chip > > > working on a MIPS-based processor, with a 2.6.11-based kernel from > > > linux-mips.org. Now, I know that this was working with a 2.4.25-based > > > kernel previously. > > > > Okay, the 2.4 driver is more intrusive, it programs the chip from start as > > much as possible, while the 2.6 driver tries to depend on Bios settings. I > > haven't checked out the 2.6 driver enough to see if it is still possible > > to program from scratch. > > The code is there to program the chip from scratch. Just select > > "Rage XL No-BIOS Init support" > > The last time I tried it it didn't work. If we could get it working that > would be great. > > > Yes, according to my register data sheet a 7 means the memory clock > > frequency is derived from DLLCLK. Unfortunately I don't know what this > > DLLCLK is. I think it means the chip isn't properly initialized yet and it > > clocks the memory from a safe clock source to allow the computer to start. > > > > However, we most likely have no way to find out the speed of this DLLCLK. > > > > The memory clock frequency is important for the driver to be able to set a > > display mode; it needs to program a memory reload frequency into the chip > > which depends on the memory frequency. > > Their is code in xlint.c that should properly set this. Have to debug that > code. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Atyfb questions and issues
I played a while with atyfb in LinuxBIOS. move the xl_init.c into LinuxBIOS. there is one patch call xlinit.c that can be used even ati fb is not inited in BIOS to make kernel still can use atyfb. I wonder if James put that in mainstream, he already sent one patch for 2.6.5 please refer to http://www.linuxbios.org/pipermail/linuxbios/2004-May/007734.html I guess the mips fw already execute the ati option rom via x86 emulator... YH On 8/12/05, Daniël Mantione <[EMAIL PROTECTED]> wrote: > > > Op Fri, 12 Aug 2005, schreef Jim Ramsay: > > > I have the following issue. I am trying to get an ATI Rage XL chip > > working on a MIPS-based processor, with a 2.6.11-based kernel from > > linux-mips.org. Now, I know that this was working with a 2.4.25-based > > kernel previously. > > Okay, the 2.4 driver is more intrusive, it programs the chip from start as > much as possible, while the 2.6 driver tries to depend on Bios settings. I > haven't checked out the 2.6 driver enough to see if it is still possible > to program from scratch. > > > I seem to get intermittent strange issues, such as the machine > > freezing from time to time, but in general I get the following in my > > dmesg when I load the atyfb module: > > > > atyfb: using auxiliary register aperture > > atyfb: 3D RAGE XL (Mach64 GR, PCI-33MHz) [0x4752 rev 0x27] > > atyfb(aty_valid_pll_ct): pllvclk=50 MHz, vclk=25 MHz > > atyfb(aty_dsp_gt): dsp_config 0x307c0001, dsp_on_off 0x14f0 > > < Sometimes it will hang here > > > atyfb: 512K RESV, 29.498928 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 63 MHz XCLK > > atyfb: Unsupported xclk source: 7. > > > I'm assuming that most of my issues are due to the "Unsupported xclk > > source" message. Any ideas what I can do about this, or where I can > > go to learn more about how to make this thing work? > > Yes, according to my register data sheet a 7 means the memory clock > frequency is derived from DLLCLK. Unfortunately I don't know what this > DLLCLK is. I think it means the chip isn't properly initialized yet and it > clocks the memory from a safe clock source to allow the computer to start. > > However, we most likely have no way to find out the speed of this DLLCLK. > > The memory clock frequency is important for the driver to be able to set a > display mode; it needs to program a memory reload frequency into the chip > which depends on the memory frequency. > > Daniël > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: APIC version and 8-bit APIC IDs
why matrin need to make apic id to be greater than 0x10 when system is only 2way? too much io-apic in system? YH On 8/12/05, Andi Kleen <[EMAIL PROTECTED]> wrote: > On Fri, Aug 12, 2005 at 09:37:11AM -0700, yhlu wrote: > > So MPTABLE do not have problem with it, only acpi related...? > > It's only a cosmetic problem I think with the printk being > wrong. The actual decision in the code should all use the true > value. > > Another way would be to just remove the printk output. > > -Andi > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] Re: 2.6.13-rc2 with dual way dual core ck804 MB
Oh. On 8/12/05, Andi Kleen <[EMAIL PROTECTED]> wrote: > On Fri, Aug 12, 2005 at 09:18:07AM -0700, yhlu wrote: > > good, I will produce one patch next week. > > I already did it in my tree. > > -Andi > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: APIC version and 8-bit APIC IDs
So MPTABLE do not have problem with it, only acpi related...? YH On 8/12/05, Andi Kleen <[EMAIL PROTECTED]> wrote: > On Fri, Aug 12, 2005 at 04:55:40PM +0200, Martin Wilck wrote: > > I wrote: > > > > >>How so? The XAPIC version check should work there. > > > > > >ACPI: LAPIC (acpi_id[0x11] lapic_id[0x21] enabled) > > >Processor #33 15:4 APIC version 16 > > >ACPI: LAPIC (acpi_id[0x12] lapic_id[0x26] enabled) > > >Processor #38 15:4 APIC version 16 > > > > Forget it. I have fallen prey to this line: > > > > processor.mpc_apicver = 0x10; /* TBD: lapic version */ > > > > in arch/x86_64/kernel/mpparse.c. > > I am used to get correct answers from Linux :-) > > Heh. Should probably fix that. Can you file a bug with the ACPI > people on http://bugzilla.kernel.org ? (or do a patch?) > > -Andi > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] Re: 2.6.13-rc2 with dual way dual core ck804 MB
good, I will produce one patch next week.
YH
On 8/12/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 11, 2005 at 11:59:21PM -0700, yhlu wrote:
> > andi,
> >
> > is it possible for
> > after the AP1 call_in is done and before AP1 get in tsc_sync_wait
> > The AP2 call_in done. and then AP1 get in tsc_sync_wait and before it
> > done, AP2 get in tsc_sync_wait too.
> >
> > sync_master can not figure out from AP1 or AP2 because only have
> > go[MASTER] and go{SLAVE].
>
> Ok, you're right. It's better to move it to before callin map.
>
> -Andi
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] Re: 2.6.13-rc2 with dual way dual core ck804 MB
andi,
it seems ia64 is after done with the tsc_sync then set the callin_map.
YH
if (!(sal_platform_features & IA64_SAL_PLATFORM_FEATURE_ITC_DRIFT)) {
/*
* Synchronize the ITC with the BP. Need to do this
after irqs are
* enabled because ia64_sync_itc() calls
smp_call_function_single(), which
* calls spin_unlock_bh(), which calls
spin_unlock_bh(), which calls
* local_bh_enable(), which bugs out if irqs are not enabled...
*/
Dprintk("Going to syncup ITC with BP.\n");
ia64_sync_itc(0);
}
/*
* Get our bogomips.
*/
ia64_init_itm();
calibrate_delay();
local_cpu_data->loops_per_jiffy = loops_per_jiffy;
#ifdef CONFIG_IA32_SUPPORT
ia32_gdt_init();
#endif
/*
* Allow the master to continue.
*/
cpu_set(cpuid, cpu_callin_map);
On 8/11/05, yhlu <[EMAIL PROTECTED]> wrote:
> andi,
>
> is it possible for
> after the AP1 call_in is done and before AP1 get in tsc_sync_wait
> The AP2 call_in done. and then AP1 get in tsc_sync_wait and before it
> done, AP2 get in tsc_sync_wait too.
>
> sync_master can not figure out from AP1 or AP2 because only have
> go[MASTER] and go{SLAVE].
>
> YH
>
> On 8/10/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > On Wed, Aug 10, 2005 at 05:43:23PM -0700, yhlu wrote:
> > > Yes, I mean more aggressive
> > >
> > > static void __init smp_init(void)
> > > {
> > > unsigned int i;
> > >
> > > /* FIXME: This should be done in userspace --RR */
> > > for_each_present_cpu(i) {
> > > if (num_online_cpus() >= max_cpus)
> > > break;
> > > if (!cpu_online(i))
> > > cpu_up(i);
> > > }
> > >
> > >
> > > let cpu_up take one array instead of one int.
> >
> > It can be done already by just not starting the CPUs and
> > then do it multithreaded from user space using sysfs with
> > the CPU hotplug infrastructure. Unfortunately cpu_up
> > right now has a global semaphore, so it won't save you any
> > time. However it could be done in parallel with other
> > startup jobs.
> >
> > -Andi
> >
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] Re: 2.6.13-rc2 with dual way dual core ck804 MB
andi,
is it possible for
after the AP1 call_in is done and before AP1 get in tsc_sync_wait
The AP2 call_in done. and then AP1 get in tsc_sync_wait and before it
done, AP2 get in tsc_sync_wait too.
sync_master can not figure out from AP1 or AP2 because only have
go[MASTER] and go{SLAVE].
YH
On 8/10/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 10, 2005 at 05:43:23PM -0700, yhlu wrote:
> > Yes, I mean more aggressive
> >
> > static void __init smp_init(void)
> > {
> > unsigned int i;
> >
> > /* FIXME: This should be done in userspace --RR */
> > for_each_present_cpu(i) {
> > if (num_online_cpus() >= max_cpus)
> > break;
> > if (!cpu_online(i))
> > cpu_up(i);
> > }
> >
> >
> > let cpu_up take one array instead of one int.
>
> It can be done already by just not starting the CPUs and
> then do it multithreaded from user space using sysfs with
> the CPU hotplug infrastructure. Unfortunately cpu_up
> right now has a global semaphore, so it won't save you any
> time. However it could be done in parallel with other
> startup jobs.
>
> -Andi
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] Re: 2.6.13-rc2 with dual way dual core ck804 MB
andi,
is it possible for
after the AP1 call_in is done and before AP1 get in tsc_sync_wait
The AP2 call_in done. and then AP1 get in tsc_sync_wait and before it
done, AP2 get in tsc_sync_wait too.
sync_master can not figure out from AP1 or AP2 because only have
go[MASTER] and go{SLAVE].
YH
On 8/10/05, Andi Kleen [EMAIL PROTECTED] wrote:
On Wed, Aug 10, 2005 at 05:43:23PM -0700, yhlu wrote:
Yes, I mean more aggressive
static void __init smp_init(void)
{
unsigned int i;
/* FIXME: This should be done in userspace --RR */
for_each_present_cpu(i) {
if (num_online_cpus() = max_cpus)
break;
if (!cpu_online(i))
cpu_up(i);
}
let cpu_up take one array instead of one int.
It can be done already by just not starting the CPUs and
then do it multithreaded from user space using sysfs with
the CPU hotplug infrastructure. Unfortunately cpu_up
right now has a global semaphore, so it won't save you any
time. However it could be done in parallel with other
startup jobs.
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] Re: 2.6.13-rc2 with dual way dual core ck804 MB
andi,
it seems ia64 is after done with the tsc_sync then set the callin_map.
YH
if (!(sal_platform_features IA64_SAL_PLATFORM_FEATURE_ITC_DRIFT)) {
/*
* Synchronize the ITC with the BP. Need to do this
after irqs are
* enabled because ia64_sync_itc() calls
smp_call_function_single(), which
* calls spin_unlock_bh(), which calls
spin_unlock_bh(), which calls
* local_bh_enable(), which bugs out if irqs are not enabled...
*/
Dprintk(Going to syncup ITC with BP.\n);
ia64_sync_itc(0);
}
/*
* Get our bogomips.
*/
ia64_init_itm();
calibrate_delay();
local_cpu_data-loops_per_jiffy = loops_per_jiffy;
#ifdef CONFIG_IA32_SUPPORT
ia32_gdt_init();
#endif
/*
* Allow the master to continue.
*/
cpu_set(cpuid, cpu_callin_map);
On 8/11/05, yhlu [EMAIL PROTECTED] wrote:
andi,
is it possible for
after the AP1 call_in is done and before AP1 get in tsc_sync_wait
The AP2 call_in done. and then AP1 get in tsc_sync_wait and before it
done, AP2 get in tsc_sync_wait too.
sync_master can not figure out from AP1 or AP2 because only have
go[MASTER] and go{SLAVE].
YH
On 8/10/05, Andi Kleen [EMAIL PROTECTED] wrote:
On Wed, Aug 10, 2005 at 05:43:23PM -0700, yhlu wrote:
Yes, I mean more aggressive
static void __init smp_init(void)
{
unsigned int i;
/* FIXME: This should be done in userspace --RR */
for_each_present_cpu(i) {
if (num_online_cpus() = max_cpus)
break;
if (!cpu_online(i))
cpu_up(i);
}
let cpu_up take one array instead of one int.
It can be done already by just not starting the CPUs and
then do it multithreaded from user space using sysfs with
the CPU hotplug infrastructure. Unfortunately cpu_up
right now has a global semaphore, so it won't save you any
time. However it could be done in parallel with other
startup jobs.
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] Re: 2.6.13-rc2 with dual way dual core ck804 MB
good, I will produce one patch next week.
YH
On 8/12/05, Andi Kleen [EMAIL PROTECTED] wrote:
On Thu, Aug 11, 2005 at 11:59:21PM -0700, yhlu wrote:
andi,
is it possible for
after the AP1 call_in is done and before AP1 get in tsc_sync_wait
The AP2 call_in done. and then AP1 get in tsc_sync_wait and before it
done, AP2 get in tsc_sync_wait too.
sync_master can not figure out from AP1 or AP2 because only have
go[MASTER] and go{SLAVE].
Ok, you're right. It's better to move it to before callin map.
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: APIC version and 8-bit APIC IDs
So MPTABLE do not have problem with it, only acpi related...? YH On 8/12/05, Andi Kleen [EMAIL PROTECTED] wrote: On Fri, Aug 12, 2005 at 04:55:40PM +0200, Martin Wilck wrote: I wrote: How so? The XAPIC version check should work there. ACPI: LAPIC (acpi_id[0x11] lapic_id[0x21] enabled) Processor #33 15:4 APIC version 16 ACPI: LAPIC (acpi_id[0x12] lapic_id[0x26] enabled) Processor #38 15:4 APIC version 16 Forget it. I have fallen prey to this line: processor.mpc_apicver = 0x10; /* TBD: lapic version */ in arch/x86_64/kernel/mpparse.c. I am used to get correct answers from Linux :-) Heh. Should probably fix that. Can you file a bug with the ACPI people on http://bugzilla.kernel.org ? (or do a patch?) -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] Re: 2.6.13-rc2 with dual way dual core ck804 MB
Oh. On 8/12/05, Andi Kleen [EMAIL PROTECTED] wrote: On Fri, Aug 12, 2005 at 09:18:07AM -0700, yhlu wrote: good, I will produce one patch next week. I already did it in my tree. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: APIC version and 8-bit APIC IDs
why matrin need to make apic id to be greater than 0x10 when system is only 2way? too much io-apic in system? YH On 8/12/05, Andi Kleen [EMAIL PROTECTED] wrote: On Fri, Aug 12, 2005 at 09:37:11AM -0700, yhlu wrote: So MPTABLE do not have problem with it, only acpi related...? It's only a cosmetic problem I think with the printk being wrong. The actual decision in the code should all use the true value. Another way would be to just remove the printk output. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Atyfb questions and issues
I played a while with atyfb in LinuxBIOS. move the xl_init.c into LinuxBIOS. there is one patch call xlinit.c that can be used even ati fb is not inited in BIOS to make kernel still can use atyfb. I wonder if James put that in mainstream, he already sent one patch for 2.6.5 please refer to http://www.linuxbios.org/pipermail/linuxbios/2004-May/007734.html I guess the mips fw already execute the ati option rom via x86 emulator... YH On 8/12/05, Daniël Mantione [EMAIL PROTECTED] wrote: Op Fri, 12 Aug 2005, schreef Jim Ramsay: I have the following issue. I am trying to get an ATI Rage XL chip working on a MIPS-based processor, with a 2.6.11-based kernel from linux-mips.org. Now, I know that this was working with a 2.4.25-based kernel previously. Okay, the 2.4 driver is more intrusive, it programs the chip from start as much as possible, while the 2.6 driver tries to depend on Bios settings. I haven't checked out the 2.6 driver enough to see if it is still possible to program from scratch. I seem to get intermittent strange issues, such as the machine freezing from time to time, but in general I get the following in my dmesg when I load the atyfb module: atyfb: using auxiliary register aperture atyfb: 3D RAGE XL (Mach64 GR, PCI-33MHz) [0x4752 rev 0x27] atyfb(aty_valid_pll_ct): pllvclk=50 MHz, vclk=25 MHz atyfb(aty_dsp_gt): dsp_config 0x307c0001, dsp_on_off 0x14f0 Sometimes it will hang here atyfb: 512K RESV, 29.498928 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 63 MHz XCLK atyfb: Unsupported xclk source: 7. I'm assuming that most of my issues are due to the Unsupported xclk source message. Any ideas what I can do about this, or where I can go to learn more about how to make this thing work? Yes, according to my register data sheet a 7 means the memory clock frequency is derived from DLLCLK. Unfortunately I don't know what this DLLCLK is. I think it means the chip isn't properly initialized yet and it clocks the memory from a safe clock source to allow the computer to start. However, we most likely have no way to find out the speed of this DLLCLK. The memory clock frequency is important for the driver to be able to set a display mode; it needs to program a memory reload frequency into the chip which depends on the memory frequency. Daniël - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Atyfb questions and issues
james, I remember that xlinit in 2.6 kernel only works when BIOS option-rom really init fb. It can not work if the BIOS option rom is not executed. For 2.4, it reversed, it can not work if BIOS opton-rom is executed. Only work if BIOS don't excute the option rom. YH On 8/12/05, James Simmons [EMAIL PROTECTED] wrote: I have the following issue. I am trying to get an ATI Rage XL chip working on a MIPS-based processor, with a 2.6.11-based kernel from linux-mips.org. Now, I know that this was working with a 2.4.25-based kernel previously. Okay, the 2.4 driver is more intrusive, it programs the chip from start as much as possible, while the 2.6 driver tries to depend on Bios settings. I haven't checked out the 2.6 driver enough to see if it is still possible to program from scratch. The code is there to program the chip from scratch. Just select Rage XL No-BIOS Init support The last time I tried it it didn't work. If we could get it working that would be great. Yes, according to my register data sheet a 7 means the memory clock frequency is derived from DLLCLK. Unfortunately I don't know what this DLLCLK is. I think it means the chip isn't properly initialized yet and it clocks the memory from a safe clock source to allow the computer to start. However, we most likely have no way to find out the speed of this DLLCLK. The memory clock frequency is important for the driver to be able to set a display mode; it needs to program a memory reload frequency into the chip which depends on the memory frequency. Their is code in xlint.c that should properly set this. Have to debug that code. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: Fix apicid versus cpu# confusion.
So boot_cpu_id is apic id of BSP.
Anyway sync_tsc(...) there is master and MASTER..., but value are all 0.
YH
On 8/11/05, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Ok being impatient not wanting this tiny bug to be forgotten for
> 2.6.13. Linus please apply this micro patch.
>
> > > static void __cpuinit tsc_sync_wait(void)
> > > {
> > > if (notscsync || !cpu_has_tsc)
> > > return;
> > > - printk(KERN_INFO "CPU %d: Syncing TSC to CPU %u.\n", smp_processor_id(),
> > > - boot_cpu_id);
> > > - sync_tsc();
> > > + sync_tsc(boot_cpu_id);
> >
> > I actually found a bug in this today. This should be sync_tsc(0), not
> > sync_tsc(boot_cpu_id)
> > Can you just fix it in your tree or should I submit a new patch?
> >
> > -Andi
>
> Oops. I knew I didn't have the physical versus logical cpu identifiers right
> when I generated that patch. It's not nearly as bad as I feared at the time
> though.
>
> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
> ---
>
> arch/x86_64/kernel/smpboot.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> 5192895f71c7eff7e1335cd9d6a775dda2bb5d52
> diff --git a/arch/x86_64/kernel/smpboot.c b/arch/x86_64/kernel/smpboot.c
> --- a/arch/x86_64/kernel/smpboot.c
> +++ b/arch/x86_64/kernel/smpboot.c
> @@ -334,7 +334,7 @@ static void __cpuinit tsc_sync_wait(void
> {
> if (notscsync || !cpu_has_tsc)
> return;
> - sync_tsc(boot_cpu_id);
> + sync_tsc(0);
> }
>
> static __init int notscsync_setup(char *s)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: Fix apicid versus cpu# confusion.
So boot_cpu_id is apic id of BSP.
Anyway sync_tsc(...) there is master and MASTER..., but value are all 0.
YH
On 8/11/05, Eric W. Biederman [EMAIL PROTECTED] wrote:
Ok being impatient not wanting this tiny bug to be forgotten for
2.6.13. Linus please apply this micro patch.
static void __cpuinit tsc_sync_wait(void)
{
if (notscsync || !cpu_has_tsc)
return;
- printk(KERN_INFO CPU %d: Syncing TSC to CPU %u.\n, smp_processor_id(),
- boot_cpu_id);
- sync_tsc();
+ sync_tsc(boot_cpu_id);
I actually found a bug in this today. This should be sync_tsc(0), not
sync_tsc(boot_cpu_id)
Can you just fix it in your tree or should I submit a new patch?
-Andi
Oops. I knew I didn't have the physical versus logical cpu identifiers right
when I generated that patch. It's not nearly as bad as I feared at the time
though.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
arch/x86_64/kernel/smpboot.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
5192895f71c7eff7e1335cd9d6a775dda2bb5d52
diff --git a/arch/x86_64/kernel/smpboot.c b/arch/x86_64/kernel/smpboot.c
--- a/arch/x86_64/kernel/smpboot.c
+++ b/arch/x86_64/kernel/smpboot.c
@@ -334,7 +334,7 @@ static void __cpuinit tsc_sync_wait(void
{
if (notscsync || !cpu_has_tsc)
return;
- sync_tsc(boot_cpu_id);
+ sync_tsc(0);
}
static __init int notscsync_setup(char *s)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] Re: 2.6.13-rc2 with dual way dual core ck804 MB
Yes, I mean more aggressive
static void __init smp_init(void)
{
unsigned int i;
/* FIXME: This should be done in userspace --RR */
for_each_present_cpu(i) {
if (num_online_cpus() >= max_cpus)
break;
if (!cpu_online(i))
cpu_up(i);
}
let cpu_up take one array instead of one int.
So in do_boot_cpu() of smpboot.c
/*
* Wait 5s total for a response
*/
for (timeout = 0; timeout < 5; timeout++) {
if (cpu_isset(cpu, cpu_callin_map))
break; /* It has booted */
udelay(100);
}
could wait all be cpu_callin_map is set.
then we can spare more time.
YH
On 8/10/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 10, 2005 at 05:23:31PM -0700, yhlu wrote:
> > I wonder if you can make the bsp can start the APs callin in the same
> > time, and make it asynchronous, So you make spare 2s or more.
>
> The setting of cpu_callin_map in the AP could be moved earlier yes.
> But it's not entirely trivial because there are some races to consider.
>
> And the 1s quiet period on the AP could be probably also reduced
> on modern systems. I doubt it is needed on Xeons or Opterons.
>
> -Andi
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] Re: 2.6.13-rc2 with dual way dual core ck804 MB
I wonder if you can make the bsp can start the APs callin in the same time, and make it asynchronous, So you make spare 2s or more. YH On 8/10/05, yhlu <[EMAIL PROTECTED]> wrote: > In LinuxBIOS, we could init_ecc asynchronous and the time reduced from > 8x to 2.1x for 8 ways system. 1x mean 5s for 4G in one cpu. If 16G > will take 20s. > > for TSC_SYNC asynchronous maybe you can get back 0.1s... > > YH > > On 8/10/05, Andi Kleen <[EMAIL PROTECTED]> wrote: > > > So my patch still can be used with Eric's, It just serialize the > > > TSC_SYNC between cpu. > > > > > > I wonder it you can refine to make TSC_SYNC serialize that beteen CPU. > > > That will make > > > CPU X:synchronized TSC ... > > > in fixed postion and timming. > > > > Why would we want that? > > > > Boot time is critical so it's better to do things asynchronous. > > > > -Andi > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] Re: 2.6.13-rc2 with dual way dual core ck804 MB
In LinuxBIOS, we could init_ecc asynchronous and the time reduced from 8x to 2.1x for 8 ways system. 1x mean 5s for 4G in one cpu. If 16G will take 20s. for TSC_SYNC asynchronous maybe you can get back 0.1s... YH On 8/10/05, Andi Kleen <[EMAIL PROTECTED]> wrote: > > So my patch still can be used with Eric's, It just serialize the > > TSC_SYNC between cpu. > > > > I wonder it you can refine to make TSC_SYNC serialize that beteen CPU. > > That will make > > CPU X:synchronized TSC ... > > in fixed postion and timming. > > Why would we want that? > > Boot time is critical so it's better to do things asynchronous. > > -Andi > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] Re: 2.6.13-rc2 with dual way dual core ck804 MB
andi, you can see the difference with the patch Booting processor 1/1 rip 6000 rsp 810181c61f58 Initializing CPU#1 masked ExtINT on CPU#1 Calibrating delay using timer specific routine.. 4000.31 BogoMIPS (lpj=8000624) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) stepping 0a CPU 1: Syncing TSC to CPU 0. CPU 1: synchronized TSC with CPU 0 (last diff 0 cycles, maxerr 886 cycles) Booting processor 2/2 rip 6000 rsp 81017ffa3f58 Initializing CPU#2 masked ExtINT on CPU#2 Calibrating delay using timer specific routine.. 4000.30 BogoMIPS (lpj=8000605) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) stepping 0a CPU 2: Syncing TSC to CPU 0. CPU 2: synchronized TSC with CPU 0 (last diff 1 cycles, maxerr 901 cycles) Booting processor 3/3 rip 6000 rsp 8101fffa9f58 Initializing CPU#3 masked ExtINT on CPU#3 Calibrating delay using timer specific routine.. 4000.31 BogoMIPS (lpj=8000622) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) stepping 0a CPU 3: Syncing TSC to CPU 0. CPU 3: synchronized TSC with CPU 0 (last diff -3 cycles, maxerr 1504 cycles) Brought up 4 CPUs without the patch Booting processor 1/4 APIC 0x1 Initializing CPU#1 masked ExtINT on CPU#1 Calibrating delay using timer specific routine.. 4000.30 BogoMIPS (lpj=8000608) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 1(1) -> Node 1 -> Core 0 stepping 0a CPU 1: Syncing TSC to CPU 0. Booting processor 2/4 APIC 0x2 Initializing CPU#2 masked ExtINT on CPU#2 CPU 1: synchronized TSC with CPU 0 (last diff 1 cycles, maxerr 893 cycles) Calibrating delay using timer specific routine.. 4000.36 BogoMIPS (lpj=8000724) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 2(1) -> Node 2 -> Core 0 stepping 0a CPU 2: Syncing TSC to CPU 0. Booting processor 3/4 APIC 0x3 Initializing CPU#3 masked ExtINT on CPU#3 CPU 2: synchronized TSC with CPU 0 (last diff 0 cycles, maxerr 904 cycles) Calibrating delay using timer specific routine.. 4000.16 BogoMIPS (lpj=8000335) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 3(1) -> Node 3 -> Core 0 stepping 0a CPU 3: Syncing TSC to CPU 0. Brought up 4 CPUs time.c: Using PIT/TSC based timekeeping. testing NMI watchdog ... OK. checking if image is initramfs...<6>CPU 3: synchronized TSC with CPU 0 (last diff -18 cycles, maxerr 1504 cycles) it isn't (no cpio magic); looks like an initrd So my patch still can be used with Eric's, It just serialize the TSC_SYNC between cpu. I wonder it you can refine to make TSC_SYNC serialize that beteen CPU. That will make CPU X:synchronized TSC ... in fixed postion and timming. YH On 8/10/05, Andi Kleen <[EMAIL PROTECTED]> wrote: > On Wed, Aug 10, 2005 at 04:14:19PM -0700, Mike Waychison wrote: > > YhLu wrote: > > >andi, > > > > > >please refer the patch, it will move cpu_set(, cpu_callin_map) from > > >smi_callin to start_secondary. > > > > > > This patch fixes an apparent race / lockup on our 2-way dual cores (when > > applied against 2.6.12.3). The machine was locking up after > > "Initializing CPU#2". > > The real solution for this issue is the smp_call_function_single patch from > Eric > that I reposted yesterday. Yh's patch just changed the timing slightly. > > > -Andi > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] Re: 2.6.13-rc2 with dual way dual core ck804 MB
andi, you can see the difference with the patch Booting processor 1/1 rip 6000 rsp 810181c61f58 Initializing CPU#1 masked ExtINT on CPU#1 Calibrating delay using timer specific routine.. 4000.31 BogoMIPS (lpj=8000624) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) stepping 0a CPU 1: Syncing TSC to CPU 0. CPU 1: synchronized TSC with CPU 0 (last diff 0 cycles, maxerr 886 cycles) Booting processor 2/2 rip 6000 rsp 81017ffa3f58 Initializing CPU#2 masked ExtINT on CPU#2 Calibrating delay using timer specific routine.. 4000.30 BogoMIPS (lpj=8000605) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) stepping 0a CPU 2: Syncing TSC to CPU 0. CPU 2: synchronized TSC with CPU 0 (last diff 1 cycles, maxerr 901 cycles) Booting processor 3/3 rip 6000 rsp 8101fffa9f58 Initializing CPU#3 masked ExtINT on CPU#3 Calibrating delay using timer specific routine.. 4000.31 BogoMIPS (lpj=8000622) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) stepping 0a CPU 3: Syncing TSC to CPU 0. CPU 3: synchronized TSC with CPU 0 (last diff -3 cycles, maxerr 1504 cycles) Brought up 4 CPUs without the patch Booting processor 1/4 APIC 0x1 Initializing CPU#1 masked ExtINT on CPU#1 Calibrating delay using timer specific routine.. 4000.30 BogoMIPS (lpj=8000608) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 1(1) - Node 1 - Core 0 stepping 0a CPU 1: Syncing TSC to CPU 0. Booting processor 2/4 APIC 0x2 Initializing CPU#2 masked ExtINT on CPU#2 CPU 1: synchronized TSC with CPU 0 (last diff 1 cycles, maxerr 893 cycles) Calibrating delay using timer specific routine.. 4000.36 BogoMIPS (lpj=8000724) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 2(1) - Node 2 - Core 0 stepping 0a CPU 2: Syncing TSC to CPU 0. Booting processor 3/4 APIC 0x3 Initializing CPU#3 masked ExtINT on CPU#3 CPU 2: synchronized TSC with CPU 0 (last diff 0 cycles, maxerr 904 cycles) Calibrating delay using timer specific routine.. 4000.16 BogoMIPS (lpj=8000335) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 3(1) - Node 3 - Core 0 stepping 0a CPU 3: Syncing TSC to CPU 0. Brought up 4 CPUs time.c: Using PIT/TSC based timekeeping. testing NMI watchdog ... OK. checking if image is initramfs...6CPU 3: synchronized TSC with CPU 0 (last diff -18 cycles, maxerr 1504 cycles) it isn't (no cpio magic); looks like an initrd So my patch still can be used with Eric's, It just serialize the TSC_SYNC between cpu. I wonder it you can refine to make TSC_SYNC serialize that beteen CPU. That will make CPU X:synchronized TSC ... in fixed postion and timming. YH On 8/10/05, Andi Kleen [EMAIL PROTECTED] wrote: On Wed, Aug 10, 2005 at 04:14:19PM -0700, Mike Waychison wrote: YhLu wrote: andi, please refer the patch, it will move cpu_set(, cpu_callin_map) from smi_callin to start_secondary. This patch fixes an apparent race / lockup on our 2-way dual cores (when applied against 2.6.12.3). The machine was locking up after Initializing CPU#2. The real solution for this issue is the smp_call_function_single patch from Eric that I reposted yesterday. Yh's patch just changed the timing slightly. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] Re: 2.6.13-rc2 with dual way dual core ck804 MB
In LinuxBIOS, we could init_ecc asynchronous and the time reduced from 8x to 2.1x for 8 ways system. 1x mean 5s for 4G in one cpu. If 16G will take 20s. for TSC_SYNC asynchronous maybe you can get back 0.1s... YH On 8/10/05, Andi Kleen [EMAIL PROTECTED] wrote: So my patch still can be used with Eric's, It just serialize the TSC_SYNC between cpu. I wonder it you can refine to make TSC_SYNC serialize that beteen CPU. That will make CPU X:synchronized TSC ... in fixed postion and timming. Why would we want that? Boot time is critical so it's better to do things asynchronous. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] Re: 2.6.13-rc2 with dual way dual core ck804 MB
I wonder if you can make the bsp can start the APs callin in the same time, and make it asynchronous, So you make spare 2s or more. YH On 8/10/05, yhlu [EMAIL PROTECTED] wrote: In LinuxBIOS, we could init_ecc asynchronous and the time reduced from 8x to 2.1x for 8 ways system. 1x mean 5s for 4G in one cpu. If 16G will take 20s. for TSC_SYNC asynchronous maybe you can get back 0.1s... YH On 8/10/05, Andi Kleen [EMAIL PROTECTED] wrote: So my patch still can be used with Eric's, It just serialize the TSC_SYNC between cpu. I wonder it you can refine to make TSC_SYNC serialize that beteen CPU. That will make CPU X:synchronized TSC ... in fixed postion and timming. Why would we want that? Boot time is critical so it's better to do things asynchronous. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] Re: 2.6.13-rc2 with dual way dual core ck804 MB
Yes, I mean more aggressive
static void __init smp_init(void)
{
unsigned int i;
/* FIXME: This should be done in userspace --RR */
for_each_present_cpu(i) {
if (num_online_cpus() = max_cpus)
break;
if (!cpu_online(i))
cpu_up(i);
}
let cpu_up take one array instead of one int.
So in do_boot_cpu() of smpboot.c
/*
* Wait 5s total for a response
*/
for (timeout = 0; timeout 5; timeout++) {
if (cpu_isset(cpu, cpu_callin_map))
break; /* It has booted */
udelay(100);
}
could wait all be cpu_callin_map is set.
then we can spare more time.
YH
On 8/10/05, Andi Kleen [EMAIL PROTECTED] wrote:
On Wed, Aug 10, 2005 at 05:23:31PM -0700, yhlu wrote:
I wonder if you can make the bsp can start the APs callin in the same
time, and make it asynchronous, So you make spare 2s or more.
The setting of cpu_callin_map in the AP could be moved earlier yes.
But it's not entirely trivial because there are some races to consider.
And the 1s quiet period on the AP could be probably also reduced
on modern systems. I doubt it is needed on Xeons or Opterons.
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: smbus driver for ati xpress 200m
yhlunb:/proc/acpi/battery/BAT1 # cat info present: yes design capacity: 4800 mAh last full capacity: 4435 mAh battery technology: rechargeable design voltage: 14800 mV design capacity warning: 300 mAh design capacity low: 132 mAh capacity granularity 1: 32 mAh capacity granularity 2: 32 mAh model number:ZF02 serial number: 836 battery type:LION OEM info:SIMPLO yhlunb:/proc/acpi/battery/BAT1 # cat state present: yes ERROR: Unable to read battery status On 8/9/05, Andi Kleen <[EMAIL PROTECTED]> wrote: > On Tue, Aug 09, 2005 at 11:50:53AM -0700, yhlu wrote: > > anyone is working on add driver for ati xpress 200m? > > > > without that My turion notebook, can not work read the battery status. > > Normally this should be done in ACPI battery.c > > -Andi > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
smbus driver for ati xpress 200m
anyone is working on add driver for ati xpress 200m? without that My turion notebook, can not work read the battery status. I guess sbs-cm need that driver in kernel. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: smbus driver for ati xpress 200m
yhlunb:/proc/acpi/battery/BAT1 # cat info present: yes design capacity: 4800 mAh last full capacity: 4435 mAh battery technology: rechargeable design voltage: 14800 mV design capacity warning: 300 mAh design capacity low: 132 mAh capacity granularity 1: 32 mAh capacity granularity 2: 32 mAh model number:ZF02 serial number: 836 battery type:LION OEM info:SIMPLO yhlunb:/proc/acpi/battery/BAT1 # cat state present: yes ERROR: Unable to read battery status On 8/9/05, Andi Kleen [EMAIL PROTECTED] wrote: On Tue, Aug 09, 2005 at 11:50:53AM -0700, yhlu wrote: anyone is working on add driver for ati xpress 200m? without that My turion notebook, can not work read the battery status. Normally this should be done in ACPI battery.c -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
smbus driver for ati xpress 200m
anyone is working on add driver for ati xpress 200m? without that My turion notebook, can not work read the battery status. I guess sbs-cm need that driver in kernel. YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [openib-general] Re: mthca and LinuxBIOS
In LinuxBIOS internal structure for resource, We have index member in resource.
So the resource will be count from 0, 7 or etc, but index member
will point to real BAR position.
I would like to see Kernel has simmliar definintion.
in LinuxBIOS
typedef uint64_t resource_t;
struct resource {
resource_t base;/* Base address of the resource */
resource_t size;/* Size of the resource */
resource_t limit; /* Largest valid value base + size -1 */
unsigned long flags;/* Descriptions of the kind of resource */
unsigned long index;/* Bus specific per device resource id */
unsigned char align;/* Required alignment (log 2) of the resource */
unsigned char gran; /* Granularity (log 2) of the resource */
/* Alignment must be >= the granularity of the resource */
};
YH
On 8/5/05, Grant Grundler <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 05, 2005 at 04:59:37PM -0700, Grant Grundler wrote:
> > ISTR making comments before about the offending patch on linux-pci mailing
> > list. Is this the same patch that assumes pci_dev->resource[i] == BAR[i] ?
>
> I meant the patch assume 1:1 for pci_dev->resource[i] and BAR[i].
> not that the two are equivalent.
>
> grant
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [openib-general] Re: mthca and LinuxBIOS
In LinuxBIOS internal structure for resource, We have index member in resource.
So the resource will be count from 0, 7 or etc, but index member
will point to real BAR position.
I would like to see Kernel has simmliar definintion.
in LinuxBIOS
typedef uint64_t resource_t;
struct resource {
resource_t base;/* Base address of the resource */
resource_t size;/* Size of the resource */
resource_t limit; /* Largest valid value base + size -1 */
unsigned long flags;/* Descriptions of the kind of resource */
unsigned long index;/* Bus specific per device resource id */
unsigned char align;/* Required alignment (log 2) of the resource */
unsigned char gran; /* Granularity (log 2) of the resource */
/* Alignment must be = the granularity of the resource */
};
YH
On 8/5/05, Grant Grundler [EMAIL PROTECTED] wrote:
On Fri, Aug 05, 2005 at 04:59:37PM -0700, Grant Grundler wrote:
ISTR making comments before about the offending patch on linux-pci mailing
list. Is this the same patch that assumes pci_dev-resource[i] == BAR[i] ?
I meant the patch assume 1:1 for pci_dev-resource[i] and BAR[i].
not that the two are equivalent.
grant
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
I remember last year when I used IBGOLD 0.5 with PCI-X IB card, it seems that it could support 64 bit pref mem. I will try IBGOLD 1.7 . YH On 8/5/05, Roland Dreier <[EMAIL PROTECTED]> wrote: >yhlu> Roland, what is the -16 mean? > >yhlu> is it /* Attempt to modify a QP/EE which is not in the >yhlu> presumed state: */ MTHCA_CMD_STAT_BAD_QPEE_STATE = 0x10, > > No, -16 is just -EBUSY. You could put a printk in event_timeout() in > mthca_cmd.c to make sure, but I'm pretty sure that's where it's coming > from. In other words we issue the CONF_SPECIAL_QP firmware command > and don't ever get a response back from the HCA. > > - R. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
Roland, what is the -16 mean? is it /* Attempt to modify a QP/EE which is not in the presumed state: */ MTHCA_CMD_STAT_BAD_QPEE_STATE = 0x10, YH On 8/5/05, yhlu <[EMAIL PROTECTED]> wrote: > You are right. CONG_SPECIAL_QP > > ib_mthca: Mellanox InfiniBand HCA driver v0.06 (June 23, 2005) > ib_mthca: Initializing Mellanox Technologies MT25208 InfiniHost III Ex > (Tavor compatibility mode) (:04:00.0) > ib_mthca :04:00.0: FW version 000400060002, max commands 64 > ib_mthca :04:00.0: FW size 6143 KB (start fcefa0, end fcefff) > ib_mthca :04:00.0: HCA memory size 262143 KB (start fce000, > end fcefff) > ib_mthca :04:00.0: Max QPs: 16777216, reserved QPs: 1024, entry size: 256 > ib_mthca :04:00.0: Max CQs: 16777216, reserved CQs: 128, entry size: 64 > ib_mthca :04:00.0: Max EQs: 64, reserved EQs: 1, entry size: 64 > ib_mthca :04:00.0: reserved MPTs: 16, reserved MTTs: 16 > ib_mthca :04:00.0: Max PDs: 16777216, reserved PDs: 0, reserved UARs: 1 > ib_mthca :04:00.0: Max QP/MCG: 16777216, reserved MGMs: 0 > ib_mthca :04:00.0: Flags: 00370347 > ib_mthca :04:00.0: profile[ 0]--10/20 @ 0x fce000 (size 0x > 400) > ib_mthca :04:00.0: profile[ 1]-- 0/16 @ 0x fce400 (size 0x > 100) > ib_mthca :04:00.0: profile[ 2]-- 7/18 @ 0x fce500 (size 0x > 80) > ib_mthca :04:00.0: profile[ 3]-- 9/17 @ 0x fce580 (size 0x > 80) > ib_mthca :04:00.0: profile[ 4]-- 3/16 @ 0x fce600 (size 0x > 40) > ib_mthca :04:00.0: profile[ 5]-- 4/16 @ 0x fce640 (size 0x > 20) > ib_mthca :04:00.0: profile[ 6]--12/15 @ 0x fce660 (size 0x > 10) > ib_mthca :04:00.0: profile[ 7]-- 8/13 @ 0x fce670 (size 0x > 8) > ib_mthca :04:00.0: profile[ 8]--11/11 @ 0x fce678 (size 0x > 1) > ib_mthca :04:00.0: profile[ 9]-- 6/ 5 @ 0x fce679 (size 0x > 800) > ib_mthca :04:00.0: HCA memory: allocated 106050 KB/256000 KB > (149950 KB free) > ib_mthca :04:00.0: Allocated EQ 1 with 65536 entries > ib_mthca :04:00.0: Allocated EQ 2 with 128 entries > ib_mthca :04:00.0: Allocated EQ 3 with 128 entries > ib_mthca :04:00.0: Setting mask 000f43fe for eqn 2 > ib_mthca :04:00.0: Setting mask 0400 for eqn 3 > ib_mthca :04:00.0: NOP command IRQ test passed > ib_mthca :04:00.0: mthca_init_qp_table: mthca_CONF_SPECIAL_QP > failed for 0/1024 (-16) > ib_mthca :04:00.0: Failed to initialize queue pair table, aborting. > ib_mthca :04:00.0: Clearing mask 000f43fe for eqn 2 > ib_mthca :04:00.0: Clearing mask 0400 for eqn 3 > ib_mthca: probe of :04:00.0 failed with error -16 > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
In LinuxBIOS, We can allocate 64 bit region ( 0xfc000) to the
mellanox Infiniband card. Some range above 4G. So the mmio below 4G
is some smaller only 128M, Otherwise need 512M. If 4 IB cards are
used, the mmio will be 2G. For new opteron E stepping, We could use
hareware memhole support. But if the CPU is before opteron E, We only
can use SW mem mapping ( will lose some performance) or lose (2G RAM).
at such case We need 64bit pref mem. We only lose 128M even four IB
card are installed.
yesterday, someone add pci_restore_bars, that will call
pci_update_resource, and it will overwirte upper 32 bit of BAR2 and
BAR4 of IB card.
So the patch make pci_restore_resource
1. don't touch BAR3, and BAR5, if BAR2, and BAR4 are 64 bit MEM IO
2. not assume BAR2 and BAR4 upper 32bit is 0 if if BAR2, and BAR4 are
64 bit MEM IO
YH
On 8/5/05, Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 05, 2005 at 01:38:37PM -0700, Linus Torvalds wrote:
> >
> > Hmm.. This looks half-way sane, but too ugly for words.
> >
> > I'd much rather see that when we detect a 64-bit resource, we always mark
> > the next resource as being reserved some way, and then we just make
> > pci_update_resource() ignore such reserved resources.
> >
> > The
> >
> > if((resno & 1)==1) {
> > /* check if previous reg is 64 mem */
> > ..
> >
> > stuff is really too ugly.
>
> Yeah, that's not nice.
>
> But what's the real problem we are trying to fix here? I seem to have
> missed that in the email thread somehow.
>
> > Greg? Ivan?
>
> Ivan's the pci resource guru, any thoughts as to how to do this in a
> nicer way?
>
> thanks,
>
> greg k-h
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
please check the patch for fix overwrite upper 32bit
YH
--- drivers/pci/setup-res.c.orig2005-08-05 10:08:45.0 -0700
+++ drivers/pci/setup-res.c 2005-08-05 13:25:06.0 -0700
@@ -33,6 +33,18 @@
u32 new, check, mask;
int reg;
+if (resno < 6) {
+reg = PCI_BASE_ADDRESS_0 + 4 * resno;
+if((resno & 1)==1) {
+/* check if previous reg is 64 mem */
+pci_read_config_dword(dev, reg-4, );
+if ((check &
(PCI_BASE_ADDRESS_SPACE|PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
+
(PCI_BASE_ADDRESS_SPACE_MEMORY|PCI_BASE_ADDRESS_MEM_TYPE_64))
+return;
+}
+
+}
+
pcibios_resource_to_bus(dev, , res);
pr_debug(" got res [%lx:%lx] bus [%lx:%lx] flags %lx for "
@@ -67,7 +79,7 @@
if ((new & (PCI_BASE_ADDRESS_SPACE|PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
(PCI_BASE_ADDRESS_SPACE_MEMORY|PCI_BASE_ADDRESS_MEM_TYPE_64)) {
- new = 0; /* currently everyone zeros the high address */
+ new = region.start >> 32 ;
pci_write_config_dword(dev, reg + 4, new);
pci_read_config_dword(dev, reg + 4, );
if (check != new) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
in drivers/pci/setup-res.c: pci_update_resource()
why
new = 0; /* currently everyone zeros the high address */
if ((new & (PCI_BASE_ADDRESS_SPACE|PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
(PCI_BASE_ADDRESS_SPACE_MEMORY|PCI_BASE_ADDRESS_MEM_TYPE_64)) {
new = 0; /* currently everyone zeros the high address */
pci_write_config_dword(dev, reg + 4, new);
pci_read_config_dword(dev, reg + 4, );
if (check != new) {
printk(KERN_ERR "PCI: Error updating region "
"%s/%d (high %08x != %08x)\n",
pci_name(dev), resno, new, check);
}
}
On 8/5/05, yhlu <[EMAIL PROTECTED]> wrote:
> pci_restore_bars cause that.
> it didn't restore that according to if resource is 64 bit or not. So
> it overwirte upper 32 bit with 0.
>
> YH
>
> file:1b34fc56067ed8ae0ba9b32f46679e13068bb86c ->
> file:65ea7d25f6911d7396e19afbf4bb2738906376f7
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -222,6 +222,37 @@ pci_find_parent_resource(const struct pc
> }
> /**
> + * pci_restore_bars - restore a devices BAR values (e.g. after wake-up)
> + * @dev: PCI device to have its BARs restored
> + *
> + * Restore the BAR values for a given device, so as to make it
> + * accessible by its driver.
> + */
> +void
> +pci_restore_bars(struct pci_dev *dev)
> +{
> + int i, numres;
> +
> + switch (dev->hdr_type) {
> + case PCI_HEADER_TYPE_NORMAL:
> + numres = 6;
> + break;
> + case PCI_HEADER_TYPE_BRIDGE:
> + numres = 2;
> + break;
> + case PCI_HEADER_TYPE_CARDBUS:
> + numres = 1;
> + break;
> + default:
> + /* Should never get here, but just in case... */
> + return;
> + }
> +
> + for (i = 0; i < numres; i ++)
> + pci_update_resource(dev, >resource[i], i);
> +}
> +
> +/**
>
> On 8/5/05, yhlu <[EMAIL PROTECTED]> wrote:
> > before I do the cg-update this morning, it didn't mask out the upper 8 bit.
> >
> > YH
> >
> > On 8/5/05, Roland Dreier <[EMAIL PROTECTED]> wrote:
> > > yhlu> ps. some kernel pci code patch broke sth yesterday night.
> > > yhlu> it mask out bit [32-39]
> > >
> > > Is it possible that all your problems are coming from the PCI setup
> > > code incorrectly assigning BARs?
> > >
> > > - R.
> > >
> >
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
pci_restore_bars cause that.
it didn't restore that according to if resource is 64 bit or not. So
it overwirte upper 32 bit with 0.
YH
file:1b34fc56067ed8ae0ba9b32f46679e13068bb86c ->
file:65ea7d25f6911d7396e19afbf4bb2738906376f7
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -222,6 +222,37 @@ pci_find_parent_resource(const struct pc
}
/**
+ * pci_restore_bars - restore a devices BAR values (e.g. after wake-up)
+ * @dev: PCI device to have its BARs restored
+ *
+ * Restore the BAR values for a given device, so as to make it
+ * accessible by its driver.
+ */
+void
+pci_restore_bars(struct pci_dev *dev)
+{
+ int i, numres;
+
+ switch (dev->hdr_type) {
+ case PCI_HEADER_TYPE_NORMAL:
+ numres = 6;
+ break;
+ case PCI_HEADER_TYPE_BRIDGE:
+ numres = 2;
+ break;
+ case PCI_HEADER_TYPE_CARDBUS:
+ numres = 1;
+ break;
+ default:
+ /* Should never get here, but just in case... */
+ return;
+ }
+
+ for (i = 0; i < numres; i ++)
+ pci_update_resource(dev, >resource[i], i);
+}
+
+/**
On 8/5/05, yhlu <[EMAIL PROTECTED]> wrote:
> before I do the cg-update this morning, it didn't mask out the upper 8 bit.
>
> YH
>
> On 8/5/05, Roland Dreier <[EMAIL PROTECTED]> wrote:
> > yhlu> ps. some kernel pci code patch broke sth yesterday night.
> > yhlu> it mask out bit [32-39]
> >
> > Is it possible that all your problems are coming from the PCI setup
> > code incorrectly assigning BARs?
> >
> > - R.
> >
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
before I do the cg-update this morning, it didn't mask out the upper 8 bit. YH On 8/5/05, Roland Dreier <[EMAIL PROTECTED]> wrote: > yhlu> ps. some kernel pci code patch broke sth yesterday night. > yhlu> it mask out bit [32-39] > > Is it possible that all your problems are coming from the PCI setup > code incorrectly assigning BARs? > > - R. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
ps. some kernel pci code patch broke sth yesterday night. it mask out bit [32-39] ib_mthca :04:00.0: profile[ 0]--10/20 @ 0xe000 (size 0x 400) ib_mthca :04:00.0: profile[ 1]-- 0/16 @ 0xe400 (size 0x 100) ib_mthca :04:00.0: profile[ 2]-- 7/18 @ 0xe500 (size 0x 80) ib_mthca :04:00.0: profile[ 3]-- 9/17 @ 0xe580 (size 0x 80) ib_mthca :04:00.0: profile[ 4]-- 3/16 @ 0xe600 (size 0x 40) ib_mthca :04:00.0: profile[ 5]-- 4/16 @ 0xe640 (size 0x 20) ib_mthca :04:00.0: profile[ 6]--12/15 @ 0xe660 (size 0x 10) ib_mthca :04:00.0: profile[ 7]-- 8/13 @ 0xe670 (size 0x 8) ib_mthca :04:00.0: profile[ 8]--11/11 @ 0xe678 (size 0x 1) ib_mthca :04:00.0: profile[ 9]-- 6/ 5 @ 0xe679 (size 0x 800) YH On 8/5/05, yhlu <[EMAIL PROTECTED]> wrote: > You are right. CONG_SPECIAL_QP > > ib_mthca: Mellanox InfiniBand HCA driver v0.06 (June 23, 2005) > ib_mthca: Initializing Mellanox Technologies MT25208 InfiniHost III Ex > (Tavor compatibility mode) (:04:00.0) > ib_mthca :04:00.0: FW version 000400060002, max commands 64 > ib_mthca :04:00.0: FW size 6143 KB (start fcefa0, end fcefff) > ib_mthca :04:00.0: HCA memory size 262143 KB (start fce000, > end fcefff) > ib_mthca :04:00.0: Max QPs: 16777216, reserved QPs: 1024, entry size: 256 > ib_mthca :04:00.0: Max CQs: 16777216, reserved CQs: 128, entry size: 64 > ib_mthca :04:00.0: Max EQs: 64, reserved EQs: 1, entry size: 64 > ib_mthca :04:00.0: reserved MPTs: 16, reserved MTTs: 16 > ib_mthca :04:00.0: Max PDs: 16777216, reserved PDs: 0, reserved UARs: 1 > ib_mthca :04:00.0: Max QP/MCG: 16777216, reserved MGMs: 0 > ib_mthca :04:00.0: Flags: 00370347 > ib_mthca :04:00.0: profile[ 0]--10/20 @ 0x fce000 (size 0x > 400) > ib_mthca :04:00.0: profile[ 1]-- 0/16 @ 0x fce400 (size 0x > 100) > ib_mthca :04:00.0: profile[ 2]-- 7/18 @ 0x fce500 (size 0x > 80) > ib_mthca :04:00.0: profile[ 3]-- 9/17 @ 0x fce580 (size 0x > 80) > ib_mthca :04:00.0: profile[ 4]-- 3/16 @ 0x fce600 (size 0x > 40) > ib_mthca :04:00.0: profile[ 5]-- 4/16 @ 0x fce640 (size 0x > 20) > ib_mthca :04:00.0: profile[ 6]--12/15 @ 0x fce660 (size 0x > 10) > ib_mthca :04:00.0: profile[ 7]-- 8/13 @ 0x fce670 (size 0x > 8) > ib_mthca :04:00.0: profile[ 8]--11/11 @ 0x fce678 (size 0x > 1) > ib_mthca :04:00.0: profile[ 9]-- 6/ 5 @ 0x fce679 (size 0x > 800) > ib_mthca :04:00.0: HCA memory: allocated 106050 KB/256000 KB > (149950 KB free) > ib_mthca :04:00.0: Allocated EQ 1 with 65536 entries > ib_mthca :04:00.0: Allocated EQ 2 with 128 entries > ib_mthca :04:00.0: Allocated EQ 3 with 128 entries > ib_mthca :04:00.0: Setting mask 000f43fe for eqn 2 > ib_mthca :04:00.0: Setting mask 0400 for eqn 3 > ib_mthca :04:00.0: NOP command IRQ test passed > ib_mthca :04:00.0: mthca_init_qp_table: mthca_CONF_SPECIAL_QP > failed for 0/1024 (-16) > ib_mthca :04:00.0: Failed to initialize queue pair table, aborting. > ib_mthca :04:00.0: Clearing mask 000f43fe for eqn 2 > ib_mthca :04:00.0: Clearing mask 0400 for eqn 3 > ib_mthca: probe of :04:00.0 failed with error -16 > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
You are right. CONG_SPECIAL_QP ib_mthca: Mellanox InfiniBand HCA driver v0.06 (June 23, 2005) ib_mthca: Initializing Mellanox Technologies MT25208 InfiniHost III Ex (Tavor compatibility mode) (:04:00.0) ib_mthca :04:00.0: FW version 000400060002, max commands 64 ib_mthca :04:00.0: FW size 6143 KB (start fcefa0, end fcefff) ib_mthca :04:00.0: HCA memory size 262143 KB (start fce000, end fcefff) ib_mthca :04:00.0: Max QPs: 16777216, reserved QPs: 1024, entry size: 256 ib_mthca :04:00.0: Max CQs: 16777216, reserved CQs: 128, entry size: 64 ib_mthca :04:00.0: Max EQs: 64, reserved EQs: 1, entry size: 64 ib_mthca :04:00.0: reserved MPTs: 16, reserved MTTs: 16 ib_mthca :04:00.0: Max PDs: 16777216, reserved PDs: 0, reserved UARs: 1 ib_mthca :04:00.0: Max QP/MCG: 16777216, reserved MGMs: 0 ib_mthca :04:00.0: Flags: 00370347 ib_mthca :04:00.0: profile[ 0]--10/20 @ 0x fce000 (size 0x 400) ib_mthca :04:00.0: profile[ 1]-- 0/16 @ 0x fce400 (size 0x 100) ib_mthca :04:00.0: profile[ 2]-- 7/18 @ 0x fce500 (size 0x 80) ib_mthca :04:00.0: profile[ 3]-- 9/17 @ 0x fce580 (size 0x 80) ib_mthca :04:00.0: profile[ 4]-- 3/16 @ 0x fce600 (size 0x 40) ib_mthca :04:00.0: profile[ 5]-- 4/16 @ 0x fce640 (size 0x 20) ib_mthca :04:00.0: profile[ 6]--12/15 @ 0x fce660 (size 0x 10) ib_mthca :04:00.0: profile[ 7]-- 8/13 @ 0x fce670 (size 0x 8) ib_mthca :04:00.0: profile[ 8]--11/11 @ 0x fce678 (size 0x 1) ib_mthca :04:00.0: profile[ 9]-- 6/ 5 @ 0x fce679 (size 0x 800) ib_mthca :04:00.0: HCA memory: allocated 106050 KB/256000 KB (149950 KB free) ib_mthca :04:00.0: Allocated EQ 1 with 65536 entries ib_mthca :04:00.0: Allocated EQ 2 with 128 entries ib_mthca :04:00.0: Allocated EQ 3 with 128 entries ib_mthca :04:00.0: Setting mask 000f43fe for eqn 2 ib_mthca :04:00.0: Setting mask 0400 for eqn 3 ib_mthca :04:00.0: NOP command IRQ test passed ib_mthca :04:00.0: mthca_init_qp_table: mthca_CONF_SPECIAL_QP failed for 0/1024 (-16) ib_mthca :04:00.0: Failed to initialize queue pair table, aborting. ib_mthca :04:00.0: Clearing mask 000f43fe for eqn 2 ib_mthca :04:00.0: Clearing mask 0400 for eqn 3 ib_mthca: probe of :04:00.0 failed with error -16 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
You are right. CONG_SPECIAL_QP ib_mthca: Mellanox InfiniBand HCA driver v0.06 (June 23, 2005) ib_mthca: Initializing Mellanox Technologies MT25208 InfiniHost III Ex (Tavor compatibility mode) (:04:00.0) ib_mthca :04:00.0: FW version 000400060002, max commands 64 ib_mthca :04:00.0: FW size 6143 KB (start fcefa0, end fcefff) ib_mthca :04:00.0: HCA memory size 262143 KB (start fce000, end fcefff) ib_mthca :04:00.0: Max QPs: 16777216, reserved QPs: 1024, entry size: 256 ib_mthca :04:00.0: Max CQs: 16777216, reserved CQs: 128, entry size: 64 ib_mthca :04:00.0: Max EQs: 64, reserved EQs: 1, entry size: 64 ib_mthca :04:00.0: reserved MPTs: 16, reserved MTTs: 16 ib_mthca :04:00.0: Max PDs: 16777216, reserved PDs: 0, reserved UARs: 1 ib_mthca :04:00.0: Max QP/MCG: 16777216, reserved MGMs: 0 ib_mthca :04:00.0: Flags: 00370347 ib_mthca :04:00.0: profile[ 0]--10/20 @ 0x fce000 (size 0x 400) ib_mthca :04:00.0: profile[ 1]-- 0/16 @ 0x fce400 (size 0x 100) ib_mthca :04:00.0: profile[ 2]-- 7/18 @ 0x fce500 (size 0x 80) ib_mthca :04:00.0: profile[ 3]-- 9/17 @ 0x fce580 (size 0x 80) ib_mthca :04:00.0: profile[ 4]-- 3/16 @ 0x fce600 (size 0x 40) ib_mthca :04:00.0: profile[ 5]-- 4/16 @ 0x fce640 (size 0x 20) ib_mthca :04:00.0: profile[ 6]--12/15 @ 0x fce660 (size 0x 10) ib_mthca :04:00.0: profile[ 7]-- 8/13 @ 0x fce670 (size 0x 8) ib_mthca :04:00.0: profile[ 8]--11/11 @ 0x fce678 (size 0x 1) ib_mthca :04:00.0: profile[ 9]-- 6/ 5 @ 0x fce679 (size 0x 800) ib_mthca :04:00.0: HCA memory: allocated 106050 KB/256000 KB (149950 KB free) ib_mthca :04:00.0: Allocated EQ 1 with 65536 entries ib_mthca :04:00.0: Allocated EQ 2 with 128 entries ib_mthca :04:00.0: Allocated EQ 3 with 128 entries ib_mthca :04:00.0: Setting mask 000f43fe for eqn 2 ib_mthca :04:00.0: Setting mask 0400 for eqn 3 ib_mthca :04:00.0: NOP command IRQ test passed ib_mthca :04:00.0: mthca_init_qp_table: mthca_CONF_SPECIAL_QP failed for 0/1024 (-16) ib_mthca :04:00.0: Failed to initialize queue pair table, aborting. ib_mthca :04:00.0: Clearing mask 000f43fe for eqn 2 ib_mthca :04:00.0: Clearing mask 0400 for eqn 3 ib_mthca: probe of :04:00.0 failed with error -16 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
ps. some kernel pci code patch broke sth yesterday night. it mask out bit [32-39] ib_mthca :04:00.0: profile[ 0]--10/20 @ 0xe000 (size 0x 400) ib_mthca :04:00.0: profile[ 1]-- 0/16 @ 0xe400 (size 0x 100) ib_mthca :04:00.0: profile[ 2]-- 7/18 @ 0xe500 (size 0x 80) ib_mthca :04:00.0: profile[ 3]-- 9/17 @ 0xe580 (size 0x 80) ib_mthca :04:00.0: profile[ 4]-- 3/16 @ 0xe600 (size 0x 40) ib_mthca :04:00.0: profile[ 5]-- 4/16 @ 0xe640 (size 0x 20) ib_mthca :04:00.0: profile[ 6]--12/15 @ 0xe660 (size 0x 10) ib_mthca :04:00.0: profile[ 7]-- 8/13 @ 0xe670 (size 0x 8) ib_mthca :04:00.0: profile[ 8]--11/11 @ 0xe678 (size 0x 1) ib_mthca :04:00.0: profile[ 9]-- 6/ 5 @ 0xe679 (size 0x 800) YH On 8/5/05, yhlu [EMAIL PROTECTED] wrote: You are right. CONG_SPECIAL_QP ib_mthca: Mellanox InfiniBand HCA driver v0.06 (June 23, 2005) ib_mthca: Initializing Mellanox Technologies MT25208 InfiniHost III Ex (Tavor compatibility mode) (:04:00.0) ib_mthca :04:00.0: FW version 000400060002, max commands 64 ib_mthca :04:00.0: FW size 6143 KB (start fcefa0, end fcefff) ib_mthca :04:00.0: HCA memory size 262143 KB (start fce000, end fcefff) ib_mthca :04:00.0: Max QPs: 16777216, reserved QPs: 1024, entry size: 256 ib_mthca :04:00.0: Max CQs: 16777216, reserved CQs: 128, entry size: 64 ib_mthca :04:00.0: Max EQs: 64, reserved EQs: 1, entry size: 64 ib_mthca :04:00.0: reserved MPTs: 16, reserved MTTs: 16 ib_mthca :04:00.0: Max PDs: 16777216, reserved PDs: 0, reserved UARs: 1 ib_mthca :04:00.0: Max QP/MCG: 16777216, reserved MGMs: 0 ib_mthca :04:00.0: Flags: 00370347 ib_mthca :04:00.0: profile[ 0]--10/20 @ 0x fce000 (size 0x 400) ib_mthca :04:00.0: profile[ 1]-- 0/16 @ 0x fce400 (size 0x 100) ib_mthca :04:00.0: profile[ 2]-- 7/18 @ 0x fce500 (size 0x 80) ib_mthca :04:00.0: profile[ 3]-- 9/17 @ 0x fce580 (size 0x 80) ib_mthca :04:00.0: profile[ 4]-- 3/16 @ 0x fce600 (size 0x 40) ib_mthca :04:00.0: profile[ 5]-- 4/16 @ 0x fce640 (size 0x 20) ib_mthca :04:00.0: profile[ 6]--12/15 @ 0x fce660 (size 0x 10) ib_mthca :04:00.0: profile[ 7]-- 8/13 @ 0x fce670 (size 0x 8) ib_mthca :04:00.0: profile[ 8]--11/11 @ 0x fce678 (size 0x 1) ib_mthca :04:00.0: profile[ 9]-- 6/ 5 @ 0x fce679 (size 0x 800) ib_mthca :04:00.0: HCA memory: allocated 106050 KB/256000 KB (149950 KB free) ib_mthca :04:00.0: Allocated EQ 1 with 65536 entries ib_mthca :04:00.0: Allocated EQ 2 with 128 entries ib_mthca :04:00.0: Allocated EQ 3 with 128 entries ib_mthca :04:00.0: Setting mask 000f43fe for eqn 2 ib_mthca :04:00.0: Setting mask 0400 for eqn 3 ib_mthca :04:00.0: NOP command IRQ test passed ib_mthca :04:00.0: mthca_init_qp_table: mthca_CONF_SPECIAL_QP failed for 0/1024 (-16) ib_mthca :04:00.0: Failed to initialize queue pair table, aborting. ib_mthca :04:00.0: Clearing mask 000f43fe for eqn 2 ib_mthca :04:00.0: Clearing mask 0400 for eqn 3 ib_mthca: probe of :04:00.0 failed with error -16 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
before I do the cg-update this morning, it didn't mask out the upper 8 bit. YH On 8/5/05, Roland Dreier [EMAIL PROTECTED] wrote: yhlu ps. some kernel pci code patch broke sth yesterday night. yhlu it mask out bit [32-39] Is it possible that all your problems are coming from the PCI setup code incorrectly assigning BARs? - R. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
pci_restore_bars cause that.
it didn't restore that according to if resource is 64 bit or not. So
it overwirte upper 32 bit with 0.
YH
file:1b34fc56067ed8ae0ba9b32f46679e13068bb86c -
file:65ea7d25f6911d7396e19afbf4bb2738906376f7
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -222,6 +222,37 @@ pci_find_parent_resource(const struct pc
}
/**
+ * pci_restore_bars - restore a devices BAR values (e.g. after wake-up)
+ * @dev: PCI device to have its BARs restored
+ *
+ * Restore the BAR values for a given device, so as to make it
+ * accessible by its driver.
+ */
+void
+pci_restore_bars(struct pci_dev *dev)
+{
+ int i, numres;
+
+ switch (dev-hdr_type) {
+ case PCI_HEADER_TYPE_NORMAL:
+ numres = 6;
+ break;
+ case PCI_HEADER_TYPE_BRIDGE:
+ numres = 2;
+ break;
+ case PCI_HEADER_TYPE_CARDBUS:
+ numres = 1;
+ break;
+ default:
+ /* Should never get here, but just in case... */
+ return;
+ }
+
+ for (i = 0; i numres; i ++)
+ pci_update_resource(dev, dev-resource[i], i);
+}
+
+/**
On 8/5/05, yhlu [EMAIL PROTECTED] wrote:
before I do the cg-update this morning, it didn't mask out the upper 8 bit.
YH
On 8/5/05, Roland Dreier [EMAIL PROTECTED] wrote:
yhlu ps. some kernel pci code patch broke sth yesterday night.
yhlu it mask out bit [32-39]
Is it possible that all your problems are coming from the PCI setup
code incorrectly assigning BARs?
- R.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
in drivers/pci/setup-res.c: pci_update_resource()
why
new = 0; /* currently everyone zeros the high address */
if ((new (PCI_BASE_ADDRESS_SPACE|PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
(PCI_BASE_ADDRESS_SPACE_MEMORY|PCI_BASE_ADDRESS_MEM_TYPE_64)) {
new = 0; /* currently everyone zeros the high address */
pci_write_config_dword(dev, reg + 4, new);
pci_read_config_dword(dev, reg + 4, check);
if (check != new) {
printk(KERN_ERR PCI: Error updating region
%s/%d (high %08x != %08x)\n,
pci_name(dev), resno, new, check);
}
}
On 8/5/05, yhlu [EMAIL PROTECTED] wrote:
pci_restore_bars cause that.
it didn't restore that according to if resource is 64 bit or not. So
it overwirte upper 32 bit with 0.
YH
file:1b34fc56067ed8ae0ba9b32f46679e13068bb86c -
file:65ea7d25f6911d7396e19afbf4bb2738906376f7
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -222,6 +222,37 @@ pci_find_parent_resource(const struct pc
}
/**
+ * pci_restore_bars - restore a devices BAR values (e.g. after wake-up)
+ * @dev: PCI device to have its BARs restored
+ *
+ * Restore the BAR values for a given device, so as to make it
+ * accessible by its driver.
+ */
+void
+pci_restore_bars(struct pci_dev *dev)
+{
+ int i, numres;
+
+ switch (dev-hdr_type) {
+ case PCI_HEADER_TYPE_NORMAL:
+ numres = 6;
+ break;
+ case PCI_HEADER_TYPE_BRIDGE:
+ numres = 2;
+ break;
+ case PCI_HEADER_TYPE_CARDBUS:
+ numres = 1;
+ break;
+ default:
+ /* Should never get here, but just in case... */
+ return;
+ }
+
+ for (i = 0; i numres; i ++)
+ pci_update_resource(dev, dev-resource[i], i);
+}
+
+/**
On 8/5/05, yhlu [EMAIL PROTECTED] wrote:
before I do the cg-update this morning, it didn't mask out the upper 8 bit.
YH
On 8/5/05, Roland Dreier [EMAIL PROTECTED] wrote:
yhlu ps. some kernel pci code patch broke sth yesterday night.
yhlu it mask out bit [32-39]
Is it possible that all your problems are coming from the PCI setup
code incorrectly assigning BARs?
- R.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
please check the patch for fix overwrite upper 32bit
YH
--- drivers/pci/setup-res.c.orig2005-08-05 10:08:45.0 -0700
+++ drivers/pci/setup-res.c 2005-08-05 13:25:06.0 -0700
@@ -33,6 +33,18 @@
u32 new, check, mask;
int reg;
+if (resno 6) {
+reg = PCI_BASE_ADDRESS_0 + 4 * resno;
+if((resno 1)==1) {
+/* check if previous reg is 64 mem */
+pci_read_config_dword(dev, reg-4, check );
+if ((check
(PCI_BASE_ADDRESS_SPACE|PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
+
(PCI_BASE_ADDRESS_SPACE_MEMORY|PCI_BASE_ADDRESS_MEM_TYPE_64))
+return;
+}
+
+}
+
pcibios_resource_to_bus(dev, region, res);
pr_debug( got res [%lx:%lx] bus [%lx:%lx] flags %lx for
@@ -67,7 +79,7 @@
if ((new (PCI_BASE_ADDRESS_SPACE|PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
(PCI_BASE_ADDRESS_SPACE_MEMORY|PCI_BASE_ADDRESS_MEM_TYPE_64)) {
- new = 0; /* currently everyone zeros the high address */
+ new = region.start 32 ;
pci_write_config_dword(dev, reg + 4, new);
pci_read_config_dword(dev, reg + 4, check);
if (check != new) {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
In LinuxBIOS, We can allocate 64 bit region ( 0xfc000) to the
mellanox Infiniband card. Some range above 4G. So the mmio below 4G
is some smaller only 128M, Otherwise need 512M. If 4 IB cards are
used, the mmio will be 2G. For new opteron E stepping, We could use
hareware memhole support. But if the CPU is before opteron E, We only
can use SW mem mapping ( will lose some performance) or lose (2G RAM).
at such case We need 64bit pref mem. We only lose 128M even four IB
card are installed.
yesterday, someone add pci_restore_bars, that will call
pci_update_resource, and it will overwirte upper 32 bit of BAR2 and
BAR4 of IB card.
So the patch make pci_restore_resource
1. don't touch BAR3, and BAR5, if BAR2, and BAR4 are 64 bit MEM IO
2. not assume BAR2 and BAR4 upper 32bit is 0 if if BAR2, and BAR4 are
64 bit MEM IO
YH
On 8/5/05, Greg KH [EMAIL PROTECTED] wrote:
On Fri, Aug 05, 2005 at 01:38:37PM -0700, Linus Torvalds wrote:
Hmm.. This looks half-way sane, but too ugly for words.
I'd much rather see that when we detect a 64-bit resource, we always mark
the next resource as being reserved some way, and then we just make
pci_update_resource() ignore such reserved resources.
The
if((resno 1)==1) {
/* check if previous reg is 64 mem */
..
stuff is really too ugly.
Yeah, that's not nice.
But what's the real problem we are trying to fix here? I seem to have
missed that in the email thread somehow.
Greg? Ivan?
Ivan's the pci resource guru, any thoughts as to how to do this in a
nicer way?
thanks,
greg k-h
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
Roland, what is the -16 mean? is it /* Attempt to modify a QP/EE which is not in the presumed state: */ MTHCA_CMD_STAT_BAD_QPEE_STATE = 0x10, YH On 8/5/05, yhlu [EMAIL PROTECTED] wrote: You are right. CONG_SPECIAL_QP ib_mthca: Mellanox InfiniBand HCA driver v0.06 (June 23, 2005) ib_mthca: Initializing Mellanox Technologies MT25208 InfiniHost III Ex (Tavor compatibility mode) (:04:00.0) ib_mthca :04:00.0: FW version 000400060002, max commands 64 ib_mthca :04:00.0: FW size 6143 KB (start fcefa0, end fcefff) ib_mthca :04:00.0: HCA memory size 262143 KB (start fce000, end fcefff) ib_mthca :04:00.0: Max QPs: 16777216, reserved QPs: 1024, entry size: 256 ib_mthca :04:00.0: Max CQs: 16777216, reserved CQs: 128, entry size: 64 ib_mthca :04:00.0: Max EQs: 64, reserved EQs: 1, entry size: 64 ib_mthca :04:00.0: reserved MPTs: 16, reserved MTTs: 16 ib_mthca :04:00.0: Max PDs: 16777216, reserved PDs: 0, reserved UARs: 1 ib_mthca :04:00.0: Max QP/MCG: 16777216, reserved MGMs: 0 ib_mthca :04:00.0: Flags: 00370347 ib_mthca :04:00.0: profile[ 0]--10/20 @ 0x fce000 (size 0x 400) ib_mthca :04:00.0: profile[ 1]-- 0/16 @ 0x fce400 (size 0x 100) ib_mthca :04:00.0: profile[ 2]-- 7/18 @ 0x fce500 (size 0x 80) ib_mthca :04:00.0: profile[ 3]-- 9/17 @ 0x fce580 (size 0x 80) ib_mthca :04:00.0: profile[ 4]-- 3/16 @ 0x fce600 (size 0x 40) ib_mthca :04:00.0: profile[ 5]-- 4/16 @ 0x fce640 (size 0x 20) ib_mthca :04:00.0: profile[ 6]--12/15 @ 0x fce660 (size 0x 10) ib_mthca :04:00.0: profile[ 7]-- 8/13 @ 0x fce670 (size 0x 8) ib_mthca :04:00.0: profile[ 8]--11/11 @ 0x fce678 (size 0x 1) ib_mthca :04:00.0: profile[ 9]-- 6/ 5 @ 0x fce679 (size 0x 800) ib_mthca :04:00.0: HCA memory: allocated 106050 KB/256000 KB (149950 KB free) ib_mthca :04:00.0: Allocated EQ 1 with 65536 entries ib_mthca :04:00.0: Allocated EQ 2 with 128 entries ib_mthca :04:00.0: Allocated EQ 3 with 128 entries ib_mthca :04:00.0: Setting mask 000f43fe for eqn 2 ib_mthca :04:00.0: Setting mask 0400 for eqn 3 ib_mthca :04:00.0: NOP command IRQ test passed ib_mthca :04:00.0: mthca_init_qp_table: mthca_CONF_SPECIAL_QP failed for 0/1024 (-16) ib_mthca :04:00.0: Failed to initialize queue pair table, aborting. ib_mthca :04:00.0: Clearing mask 000f43fe for eqn 2 ib_mthca :04:00.0: Clearing mask 0400 for eqn 3 ib_mthca: probe of :04:00.0 failed with error -16 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
I remember last year when I used IBGOLD 0.5 with PCI-X IB card, it seems that it could support 64 bit pref mem. I will try IBGOLD 1.7 . YH On 8/5/05, Roland Dreier [EMAIL PROTECTED] wrote: yhlu Roland, what is the -16 mean? yhlu is it /* Attempt to modify a QP/EE which is not in the yhlu presumed state: */ MTHCA_CMD_STAT_BAD_QPEE_STATE = 0x10, No, -16 is just -EBUSY. You could put a printk in event_timeout() in mthca_cmd.c to make sure, but I'm pretty sure that's where it's coming from. In other words we issue the CONF_SPECIAL_QP firmware command and don't ever get a response back from the HCA. - R. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
ib_mthca: Mellanox InfiniBand HCA driver v0.06 (June 23, 2005) ib_mthca: Initializing Mellanox Technologies MT25208 InfiniHost III Ex (Tavor compatibility mode) (:04:00.0) ib_mthca :04:00.0: FW version 000400060002, max commands 64 ib_mthca :04:00.0: FW size 6143 KB (start fcefa0, end fcefff) ib_mthca :04:00.0: HCA memory size 262143 KB (start fce000, end fcefff) ib_mthca :04:00.0: Max QPs: 16777216, reserved QPs: 1024, entry size: 256 ib_mthca :04:00.0: Max CQs: 16777216, reserved CQs: 128, entry size: 64 ib_mthca :04:00.0: Max EQs: 64, reserved EQs: 1, entry size: 64 ib_mthca :04:00.0: reserved MPTs: 16, reserved MTTs: 16 ib_mthca :04:00.0: Max PDs: 16777216, reserved PDs: 0, reserved UARs: 1 ib_mthca :04:00.0: Max QP/MCG: 16777216, reserved MGMs: 0 ib_mthca :04:00.0: Flags: 00370347 ib_mthca :04:00.0: profile[ 0]--10/20 @ 0x fce000 (size 0x 400) ib_mthca :04:00.0: profile[ 1]-- 0/16 @ 0x fce400 (size 0x 100) ib_mthca :04:00.0: profile[ 2]-- 7/18 @ 0x fce500 (size 0x 80) ib_mthca :04:00.0: profile[ 3]-- 9/17 @ 0x fce580 (size 0x 80) ib_mthca :04:00.0: profile[ 4]-- 3/16 @ 0x fce600 (size 0x 40) ib_mthca :04:00.0: profile[ 5]-- 4/16 @ 0x fce640 (size 0x 20) ib_mthca :04:00.0: profile[ 6]--12/15 @ 0x fce660 (size 0x 10) ib_mthca :04:00.0: profile[ 7]-- 8/13 @ 0x fce670 (size 0x 8) ib_mthca :04:00.0: profile[ 8]--11/11 @ 0x fce678 (size 0x 1) ib_mthca :04:00.0: profile[ 9]-- 6/ 5 @ 0x fce679 (size 0x 800) ib_mthca :04:00.0: HCA memory: allocated 106050 KB/256000 KB (149950 KB free) ib_mthca :04:00.0: Allocated EQ 1 with 65536 entries ib_mthca :04:00.0: Allocated EQ 2 with 128 entries ib_mthca :04:00.0: Allocated EQ 3 with 128 entries ib_mthca :04:00.0: Setting mask 000f43fe for eqn 2 ib_mthca :04:00.0: Setting mask 0400 for eqn 3 ib_mthca :04:00.0: NOP command IRQ test passed <--stuck 30s ib_mthca :04:00.0: Failed to initialize queue pair table, aborting. ib_mthca :04:00.0: Clearing mask 000f43fe for eqn 2 ib_mthca :04:00.0: Clearing mask 0400 for eqn 3 ib_mthca: probe of :04:00.0 failed with error -16 On 8/4/05, Roland Dreier <[EMAIL PROTECTED]> wrote: > yhlu> i enable CCONFIG_INFINIBAND_MTHCA_DEBUG=y I didn't get any > yhlu> more debug info, is that depend other setting? > > It shouldn't depend on anything. mthca_dbg() gets turned into > dev_dbg(), which just does dev_printk(KERN_DEBUG,...). Perhaps you > have to change your console level to see KERN_DEBUG messages? > > Since you're getting to the call to mthca_init_qp_table(), there are > mthca_dbg() calls that you should definitely be getting output from. > > - R. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] [IB/cm]: Correct CM port redirect reject codes
Yes. On 8/3/05, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote: > Quoting r. yhlu <[EMAIL PROTECTED]>: > > Subject: Re: [PATCH 1/2] [IB/cm]: Correct CM port redirect reject codes > > > > Roland, > > > > In LinuxBIOS, If I enable the prefmem64 to use real 64 range. the IB > > driver in Kernel can not be loaded. > > Are you using the latest firmware on the HCA card? > > -- > MST > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
i enable CCONFIG_INFINIBAND_MTHCA_DEBUG=y I didn't get any more debug info, is that depend other setting? YH On 8/4/05, yhlu <[EMAIL PROTECTED]> wrote: > The mellanox can use prefmem64, but the BIOS could only allocate the > some range below 4G, So 32 bit OS still can use the IB cards. > but for 64bit OS, We could allocate range above 4G (0xfc), So > the mmio below 4G can be smaller. ( for example from 512M to 128M, the > user can get back some RAM back if Opteron don't have hardware memhole > support). > > YH > > > > On 8/4/05, Roland Dreier <[EMAIL PROTECTED]> wrote: > > >>>>> "yhlu" == yhlu <[EMAIL PROTECTED]> writes: > > > > yhlu> YES. I will send you the output message later about > > yhlu> "CONFIG_INFINIBAND_MTHCA_DEBUG=y" > > > > Thanks. In the meantime, can you explain what it means to "enable the > > prefmem64 to use real 64 range"? What is the difference between this > > and the configuration that works? > > > > - R. > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS (was: [PATCH 1/2] [IB/cm]: Correct CM port redirect reject codes)
YES. I will send you the output message later about "CONFIG_INFINIBAND_MTHCA_DEBUG=y" YH On 8/3/05, Roland Dreier <[EMAIL PROTECTED]> wrote: > yhlu> In LinuxBIOS, If I enable the prefmem64 to use real 64 > yhlu> range. the IB driver in Kernel can not be loaded. > > What does it mean to "enable the prefmem64 to use real 64 range"? > > Does the driver work if you don't do this? > > yhlu> ib_mthca :04:00.0: Failed to initialize queue pair table, > aborting. > > Can you add printk()s to mthca_qp.c::mthca_init_qp_table() to find out > how far the function gets before it fails? > > It would also be useful for you to build with CONFIG_INFINIBAND_MTHCA_DEBUG=y > and send the kernel output you get with that. > > - Roland > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
The mellanox can use prefmem64, but the BIOS could only allocate the some range below 4G, So 32 bit OS still can use the IB cards. but for 64bit OS, We could allocate range above 4G (0xfc), So the mmio below 4G can be smaller. ( for example from 512M to 128M, the user can get back some RAM back if Opteron don't have hardware memhole support). YH On 8/4/05, Roland Dreier <[EMAIL PROTECTED]> wrote: > >>>>> "yhlu" == yhlu <[EMAIL PROTECTED]> writes: > > yhlu> YES. I will send you the output message later about > yhlu> "CONFIG_INFINIBAND_MTHCA_DEBUG=y" > > Thanks. In the meantime, can you explain what it means to "enable the > prefmem64 to use real 64 range"? What is the difference between this > and the configuration that works? > > - R. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
The mellanox can use prefmem64, but the BIOS could only allocate the some range below 4G, So 32 bit OS still can use the IB cards. but for 64bit OS, We could allocate range above 4G (0xfc), So the mmio below 4G can be smaller. ( for example from 512M to 128M, the user can get back some RAM back if Opteron don't have hardware memhole support). YH On 8/4/05, Roland Dreier [EMAIL PROTECTED] wrote: yhlu == yhlu [EMAIL PROTECTED] writes: yhlu YES. I will send you the output message later about yhlu CONFIG_INFINIBAND_MTHCA_DEBUG=y Thanks. In the meantime, can you explain what it means to enable the prefmem64 to use real 64 range? What is the difference between this and the configuration that works? - R. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS (was: [PATCH 1/2] [IB/cm]: Correct CM port redirect reject codes)
YES. I will send you the output message later about CONFIG_INFINIBAND_MTHCA_DEBUG=y YH On 8/3/05, Roland Dreier [EMAIL PROTECTED] wrote: yhlu In LinuxBIOS, If I enable the prefmem64 to use real 64 yhlu range. the IB driver in Kernel can not be loaded. What does it mean to enable the prefmem64 to use real 64 range? Does the driver work if you don't do this? yhlu ib_mthca :04:00.0: Failed to initialize queue pair table, aborting. Can you add printk()s to mthca_qp.c::mthca_init_qp_table() to find out how far the function gets before it fails? It would also be useful for you to build with CONFIG_INFINIBAND_MTHCA_DEBUG=y and send the kernel output you get with that. - Roland - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
i enable CCONFIG_INFINIBAND_MTHCA_DEBUG=y I didn't get any more debug info, is that depend other setting? YH On 8/4/05, yhlu [EMAIL PROTECTED] wrote: The mellanox can use prefmem64, but the BIOS could only allocate the some range below 4G, So 32 bit OS still can use the IB cards. but for 64bit OS, We could allocate range above 4G (0xfc), So the mmio below 4G can be smaller. ( for example from 512M to 128M, the user can get back some RAM back if Opteron don't have hardware memhole support). YH On 8/4/05, Roland Dreier [EMAIL PROTECTED] wrote: yhlu == yhlu [EMAIL PROTECTED] writes: yhlu YES. I will send you the output message later about yhlu CONFIG_INFINIBAND_MTHCA_DEBUG=y Thanks. In the meantime, can you explain what it means to enable the prefmem64 to use real 64 range? What is the difference between this and the configuration that works? - R. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] [IB/cm]: Correct CM port redirect reject codes
Yes. On 8/3/05, Michael S. Tsirkin [EMAIL PROTECTED] wrote: Quoting r. yhlu [EMAIL PROTECTED]: Subject: Re: [PATCH 1/2] [IB/cm]: Correct CM port redirect reject codes Roland, In LinuxBIOS, If I enable the prefmem64 to use real 64 range. the IB driver in Kernel can not be loaded. Are you using the latest firmware on the HCA card? -- MST - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mthca and LinuxBIOS
ib_mthca: Mellanox InfiniBand HCA driver v0.06 (June 23, 2005) ib_mthca: Initializing Mellanox Technologies MT25208 InfiniHost III Ex (Tavor compatibility mode) (:04:00.0) ib_mthca :04:00.0: FW version 000400060002, max commands 64 ib_mthca :04:00.0: FW size 6143 KB (start fcefa0, end fcefff) ib_mthca :04:00.0: HCA memory size 262143 KB (start fce000, end fcefff) ib_mthca :04:00.0: Max QPs: 16777216, reserved QPs: 1024, entry size: 256 ib_mthca :04:00.0: Max CQs: 16777216, reserved CQs: 128, entry size: 64 ib_mthca :04:00.0: Max EQs: 64, reserved EQs: 1, entry size: 64 ib_mthca :04:00.0: reserved MPTs: 16, reserved MTTs: 16 ib_mthca :04:00.0: Max PDs: 16777216, reserved PDs: 0, reserved UARs: 1 ib_mthca :04:00.0: Max QP/MCG: 16777216, reserved MGMs: 0 ib_mthca :04:00.0: Flags: 00370347 ib_mthca :04:00.0: profile[ 0]--10/20 @ 0x fce000 (size 0x 400) ib_mthca :04:00.0: profile[ 1]-- 0/16 @ 0x fce400 (size 0x 100) ib_mthca :04:00.0: profile[ 2]-- 7/18 @ 0x fce500 (size 0x 80) ib_mthca :04:00.0: profile[ 3]-- 9/17 @ 0x fce580 (size 0x 80) ib_mthca :04:00.0: profile[ 4]-- 3/16 @ 0x fce600 (size 0x 40) ib_mthca :04:00.0: profile[ 5]-- 4/16 @ 0x fce640 (size 0x 20) ib_mthca :04:00.0: profile[ 6]--12/15 @ 0x fce660 (size 0x 10) ib_mthca :04:00.0: profile[ 7]-- 8/13 @ 0x fce670 (size 0x 8) ib_mthca :04:00.0: profile[ 8]--11/11 @ 0x fce678 (size 0x 1) ib_mthca :04:00.0: profile[ 9]-- 6/ 5 @ 0x fce679 (size 0x 800) ib_mthca :04:00.0: HCA memory: allocated 106050 KB/256000 KB (149950 KB free) ib_mthca :04:00.0: Allocated EQ 1 with 65536 entries ib_mthca :04:00.0: Allocated EQ 2 with 128 entries ib_mthca :04:00.0: Allocated EQ 3 with 128 entries ib_mthca :04:00.0: Setting mask 000f43fe for eqn 2 ib_mthca :04:00.0: Setting mask 0400 for eqn 3 ib_mthca :04:00.0: NOP command IRQ test passed --stuck 30s ib_mthca :04:00.0: Failed to initialize queue pair table, aborting. ib_mthca :04:00.0: Clearing mask 000f43fe for eqn 2 ib_mthca :04:00.0: Clearing mask 0400 for eqn 3 ib_mthca: probe of :04:00.0 failed with error -16 On 8/4/05, Roland Dreier [EMAIL PROTECTED] wrote: yhlu i enable CCONFIG_INFINIBAND_MTHCA_DEBUG=y I didn't get any yhlu more debug info, is that depend other setting? It shouldn't depend on anything. mthca_dbg() gets turned into dev_dbg(), which just does dev_printk(KERN_DEBUG,...). Perhaps you have to change your console level to see KERN_DEBUG messages? Since you're getting to the call to mthca_init_qp_table(), there are mthca_dbg() calls that you should definitely be getting output from. - R. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
