NUMA support for dual core Opteron
Someone mentioned that NUMA support for dual core opteron need acpi support in LinuxBIOS. there may be some other solution for that. 1. PowerPC already support dual core and it should support NUMA, So the Open Firmware must have some NUMA entry definition. Can we make x86-64 kernel support OpenFirmware interface so we can use OpenBIOS as payload of LinuxBIOS. 2. enable acpi and add the NUMA entries into it, the Linux Kernel will be happy. 3. If we are trying to use ADLO to load Windows/Solaris/FreeBSD, We need to pass related acpi info to ADLO Solution 1 will be ideal one, and can make Solaris for X86-64 use OpenFirmware interface too. which one is better? 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] NUMA support for dual core Opteron
For S2895, with 1Gx8 Installed and E stepping dual core opteron with 1G mem hole emable, got Bootdata ok (command line is apic=debug ramdisk_size=65536 root=/dev/ram0 rw console=tty0 console=ttyS0,115200n8 ) Linux version 2.6.12-rc5 ([EMAIL PROTECTED]) (gcc version 3.3.3 (SuSE Linux)) #26 SMP Thu Jun 2 18:15:44 PDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 0dd0 (reserved) BIOS-e820: 0dd0 - 000a (usable) BIOS-e820: 000f - 000f0400 (reserved) BIOS-e820: 0010 - c000 (usable) BIOS-e820: 0001 - 00024000 (usable) ACPI: Unable to locate RSDP Scanning NUMA topology in Northbridge 24 Number of nodes 2 Node 0 MemBase Limit 00013fff Node 1 MemBase 00014000 Limit 00023fff node 1 shift 24 addr 14000 conflict 0 node 1 shift 25 addr 1fe00 conflict 0 Using node hash shift of 26 Bootmem setup node 0 -00013fff Bootmem setup node 1 00014000-00023fff ~ # cat /proc/mt~ # cat /proc/mtrr reg00: base=0x ( 0MB), size=8192MB: write-back, count=1 reg01: base=0x2 (8192MB), size=1024MB: write-back, count=1 reg02: base=0xc000 (3072MB), size=1024MB: uncachable, count=1 with suse kernel and LinuxBIOS + S2882 I can get linux:~ # cat /proc/meminfo total:used:free: shared: buffers: cached: Mem: 8131170304 145051648 79861186560 15220736 66543616 Swap: 21549793280 2154979328 MemTotal: 7940596 kB MemFree: 7798944 kB MemShared: 0 kB Buffers: 14864 kB Cached: 64984 kB SwapCached: 0 kB Active: 39056 kB Inactive:40844 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 7940596 kB LowFree: 7798944 kB SwapTotal: 2104472 kB SwapFree: 2104472 kB BigFree: 0 kB Node 0 MemTotal: 4194300 kB Node 0 MemFree: 3793788 kB Node 0 MemUsed: 400512 kB Node 0 HighTotal: 0 kB Node 0 HighFree:0 kB Node 0 LowTotal: 4194300 kB Node 0 LowFree: 3793788 kB Node 1 MemTotal: 4194300 kB Node 1 MemFree: 4005156 kB Node 1 MemUsed: 189144 kB Node 1 HighTotal: 0 kB Node 1 HighFree:0 kB Node 1 LowTotal: 4194300 kB Node 1 LowFree: 4005156 kB I wonder if suse kernel have some special code to show that. in Kernel.org, I can not Node0Node 1... YH On 7/14/05, Li-Ta Lo <[EMAIL PROTECTED]> wrote: > On Thu, 2005-07-14 at 10:58 -0700, yhlu wrote: > > Someone mentioned that NUMA support for dual core opteron need acpi > > support in LinuxBIOS. > > > > there may be some other solution for that. > > 1. PowerPC already support dual core and it should support NUMA, So > > the Open Firmware must have some NUMA entry definition. > > Can we make x86-64 kernel support OpenFirmware interface so we can use > > OpenBIOS as payload of LinuxBIOS. > > 2. enable acpi and add the NUMA entries into it, the Linux Kernel will be > > happy. > > 3. If we are trying to use ADLO to load Windows/Solaris/FreeBSD, We > > need to pass related acpi info to ADLO > > > > Solution 1 will be ideal one, and can make Solaris for X86-64 use > > OpenFirmware interface too. > > > > which one is better? > > > > > AFIAK, for x86_64 kernel, it will try to read NUMA configuration from > HW directory. We don't have to export any ACPI table. > > -- > Li-Ta Lo <[EMAIL PROTECTED]> > Los Alamos National Lab > > - 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: [LinuxBIOS] NUMA support for dual core Opteron
FYI in Tyan S4881 (8 ways dual core 875 cpu ) with LinuxBIOS I got also the 1G mem hole is enabled. So the kernel should be OK with read NUMA directly from HW. YH Firmware type: LinuxBIOS old bootloader convention, maybe loadlin? Bootdata ok (command line is apic=debug ramdisk_size=65536 root=/dev/ram0 rw console=tty0 console=ttyS0,115200n8 ) Linux version 2.6.12 ([EMAIL PROTECTED]) (gcc version 3.3.3 (SuSE Linux)) #8 SMP Fri Jun 24 12:41:43 PDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 0e48 (reserved) BIOS-e820: 0e48 - 000a (usable) BIOS-e820: 000f - 000f0400 (reserved) BIOS-e820: 0010 - c000 (usable) BIOS-e820: 0001 - 00084000 (usable) Scanning NUMA topology in Northbridge 24 Number of nodes 8 Node 0 MemBase Limit 00013fff Node 1 MemBase 00014000 Limit 00023fff Node 2 MemBase 00024000 Limit 00033fff Node 3 MemBase 00034000 Limit 00043fff Node 4 MemBase 00044000 Limit 00053fff Node 5 MemBase 00054000 Limit 00063fff Node 6 MemBase 00064000 Limit 00073fff Node 7 MemBase 00074000 Limit 00083fff node 1 shift 24 addr 14000 conflict 0 node 1 shift 25 addr 1fe00 conflict 0 node 3 shift 26 addr 3fc00 conflict 0 node 7 shift 27 addr 7f800 conflict 0 Using node hash shift of 28 Bootmem setup node 0 -00013fff Bootmem setup node 1 00014000-00023fff Bootmem setup node 2 00024000-00033fff Bootmem setup node 3 00034000-00043fff Bootmem setup node 4 00044000-00053fff Bootmem setup node 5 00054000-00063fff Bootmem setup node 6 00064000-00073fff Bootmem setup node 7 00074000-00083fff in LB Setting variable MTRR 0, base:0MB, range: 32768MB, type WB Setting variable MTRR 1, base: 32768MB, range: 1024MB, type WB Setting variable MTRR 2, base: 3072MB, range: 1024MB, type UC On 7/14/05, Andi Kleen <[EMAIL PROTECTED]> wrote: > > AFIAK, for x86_64 kernel, it will try to read NUMA configuration from > > HW directory. We don't have to export any ACPI table. > > It doesn't work for dual core or 8 sockets for some reason. Since the SRAT > code works fine and is in general more future proof we never tracked down > why. Patches welcome. > > However you'll likely need ACPI for other reasons anyways, e.g. for > better power saving. > > -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: NUMA support for dual core Opteron
I didn't see any problem about NUMA with LinuxBIOS + 8way dual core system. of couse the acpi support in Kernel is disabled. p.s. can you use powernow when acpi is disabled? p.s.s Is powerpc64 support ACPI? or ACPI is only can be used by x86? YH On 7/14/05, Andi Kleen <[EMAIL PROTECTED]> wrote: > [closed mailing list dropped. Sorry I have no plans to argue with > your mailbots] > > On Thu, Jul 14, 2005 at 01:00:01PM -0600, Ronald G. Minnich wrote: > > if there is any chance of getting along without ACPI entries that is best. > > Linux did do this once already, for SMP K8: K8 can boot and run NUMA > > without an SRAT table. What more is needed for dual core, and could Linux > > support in this area be extended? > > The dual core NUMA parsing problem could be probably fixed. I personally > have no plans to work on it though, since the ACPI method works fine. > > Feel free to submit patches. > > However with 90+W CPUs I would strongly recommend having support > for PowerNow! and the old style PST table doesn't support > dual core or SMP, so you need ACPI for that anyways. > > -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: NUMA support for dual core Opteron
Andi, How do yo think about make x86-64 kernel support openfirmware interface? Can we borrow some code from ppc64 arch? YH On 7/14/05, Andi Kleen <[EMAIL PROTECTED]> wrote: > On Thu, Jul 14, 2005 at 07:46:49PM -0700, yhlu wrote: > > p.s. can you use powernow when acpi is disabled? > > Only on uniprocessor machines. > > > p.s.s Is powerpc64 support ACPI? or ACPI is only can be used by x86? > > powerpc64 uses openfirmware, not ACPI. > > -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: NUMA support for dual core Opteron
EFI support in x86-64? Is EFI only support IA64? Is acpi in EFI? YH On 7/14/05, Andi Kleen <[EMAIL PROTECTED]> wrote: > On Thu, 14 Jul 2005 20:52:58 -0700 > yhlu <[EMAIL PROTECTED]> wrote: > > > Andi, > > > > How do yo think about make x86-64 kernel support openfirmware interface? > > I don't like it. We already have the old x86 BIOS interfaces and ACPI > and at some point EFI. No need for more. > > -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: 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, ®ion, 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: [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/
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/
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
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: [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
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: 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: 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/
x86-64 dual core mapping
Andi, I tried 2.6.12-rc3 with dual way dual cpus. It seems right mapping should be CPU 0(2) -> Node 0 -> Core 0 CPU 1(2) -> Node 0 -> Core 1 CPU 2(2) -> Node 1 -> Core 0 CPU 3(2) -> Node 1 -> Core 1 instead of CPU 0(2) -> Node 0 -> Core 0 CPU 1(2) -> Node 0 -> Core 0 CPU 2(2) -> Node 1 -> Core 1 CPU 3(2) -> Node 1 -> Core 1 YH CPU 0(2) -> Node 0 -> Core 0 Using local APIC NMI watchdog using perfctr0 enabled ExtINT on CPU#0 ENABLING IO-APIC IRQs Using IO-APIC 4 ...changing IO-APIC physical APIC ID to 4 ... ok. Using IO-APIC 5 ...changing IO-APIC physical APIC ID to 5 ... ok. Using IO-APIC 6 ...changing IO-APIC physical APIC ID to 6 ... ok. Using IO-APIC 7 ...changing IO-APIC physical APIC ID to 7 ... ok. Synchronizing Arb IDs. ..TIMER: vector=0x31 pin1=0 pin2=2 testing the IO APIC... done. Using local APIC timer interrupts. Detected 12.564 MHz APIC timer. Booting processor 1/1 rip 6000 rsp 81007ff99f58 Initializing CPU#1 masked ExtINT on CPU#1 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 1(2) -> Node 0 -> Core 0 stepping 00 Synced TSC of CPU 1 difference 30064769976 Booting processor 2/2 rip 6000 rsp 81013ffa3f58 Initializing CPU#2 masked ExtINT on CPU#2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 2(2) -> Node 1 -> Core 1 stepping 00 Synced TSC of CPU 2 difference 30064770021 Booting processor 3/3 rip 6000 rsp 81007ff49f58 Initializing CPU#3 masked ExtINT on CPU#3 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 3(2) -> Node 1 -> Core 1 stepping 00 Synced TSC of CPU 3 difference 30064770021 Brought up 4 CPUs - 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/
2.6.13-rc2 with dual way dual core ck804 MB
andi, the core1/node0 take a long while to get TSC synchronized. Is it normal? i guess "CPU 1: synchronized TSC with CPU 0" should be just after "CPU 1: Syncing TSC to CPU0" YH cpu 1: setting up apic clock cpu 1: enabling apic timer CPU 1: Syncing TSC to CPU 0. CPU has booted. waiting for cpu 1 cpu 2: setting up apic clock cpu 2: enabling apic timer CPU 2: Syncing TSC to CPU 0. CPU 2: synchronized TSC with CPU 0 (last diff -4 cycles, maxerr 1097 cycles) CPU has booted. waiting for cpu 2 cpu 3: setting up apic clock cpu 3: enabling apic timer CPU 3: Syncing TSC to CPU 0. CPU 3: synchronized TSC with CPU 0 (last diff 1 cycles, maxerr 1087 cycles) CPU has booted. waiting for cpu 3 testing NMI watchdog ... CPU#1: NMI appears to be stuck (1->1)! checking if image is initramfs...<6>CPU 1: synchronized TSC with CPU 0 (last diff 0 cycles, maxerr 595 cycles) it isn't (no cpio magic); looks like an initrd the - 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.13-rc2 with dual way dual core ck804 MB
andi,
please refer the patch, it will move cpu_set(, cpu_callin_map) from
smi_callin to start_secondary.
--- /home/yhlu/xx1/linux-2.6.13-rc2/arch/x86_64/kernel/smpboot.c.orig
2005-07-06 18:41:16.789767168 -0700
+++ /home/yhlu/xx1/linux-2.6.13-rc2/arch/x86_64/kernel/smpboot.c
2005-07-06 18:45:11.923021480 -0700
@@ -442,7 +442,7 @@
/*
* Allow the master to continue.
*/
- cpu_set(cpuid, cpu_callin_map);
+// cpu_set(cpuid, cpu_callin_map); // moved to start_secondary by yhlu
}
static inline void set_cpu_sibling_map(int cpu)
@@ -529,8 +529,11 @@
/* Wait for TSC sync to not schedule things before.
We still process interrupts, which could see an inconsistent
time in that window unfortunately. */
+
tsc_sync_wait();
+ cpu_set(smp_processor_id(), cpu_callin_map); // moved from
smp_callin by yhlu
+
cpu_idle();
}
the other solution will be change cpu_callin_map to cpu_online_map in
do_boot_cpu
/*
* allow APs to start initializing.
*/
Dprintk("Before Callout %d.\n", cpu);
cpu_set(cpu, cpu_callout_map);
Dprintk("After Callout %d.\n", cpu);
/*
* Wait 5s total for a response
*/
for (timeout = 0; timeout < 5; timeout++) {
if (cpu_isset(cpu, cpu_callin_map))
--> cpu_online_map
break; /* It has booted */
udelay(100);
}
if (cpu_isset(cpu, cpu_callin_map)) {
> cpu_online_map
/* number CPUs logically, starting from 1 (BSP is 0)
*/
Dprintk("CPU has booted.\n");
} else {
boot_error = 1;
if (*((volatile unsigned char
*)phys_to_virt(SMP_TRAMPOLINE_BASE))
== 0xA5)
/* trampoline started but...? */
printk("Stuck ??\n");
else
/* trampoline code not run */
printk("Not responding.\n");
#if APIC_DEBUG
inquire_remote_apic(apicid);
#endif
}
the result will be
Booting processor 1/1 rip 6000 rsp 81013ff89f58
Initializing CPU#1
masked ExtINT on CPU#1
Calibrating delay using timer specific routine.. 4422.98 BogoMIPS
(lpj=8845965)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 1(2) -> Node 0 -> Core 1
stepping 00
CPU 1: Syncing TSC to CPU 0.
sync_master: 1 smp_processor_id() = 00, boot_cpu_id= 00
sync_master: 2 smp_processor_id() = 00, boot_cpu_id= 00
CPU 1: synchronized TSC with CPU 0 (last diff 0 cycles, maxerr 595 cycles)
-> it is in right place.
Booting processor 2/2 rip 6000 rsp 81023ff1df58
Initializing CPU#2
masked ExtINT on CPU#2
Calibrating delay using timer specific routine.. 4422.99 BogoMIPS
(lpj=8845997)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 2(2) -> Node 1 -> Core 0
stepping 00
CPU 2: Syncing TSC to CPU 0.
sync_master: 1 smp_processor_id() = 00, boot_cpu_id= 00
sync_master: 1 smp_processor_id() = 01, boot_cpu_id= 00
sync_master: 2 smp_processor_id() = 00, boot_cpu_id= 00
CPU 2: synchronized TSC with CPU 0 (last diff -4 cycles, maxerr 1097 cycles)
Booting processor 3/3 rip 6000 rsp 81013ff53f58
Initializing CPU#3
masked ExtINT on CPU#3
Calibrating delay using timer specific routine.. 4423.03 BogoMIPS
(lpj=8846075)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 3(2) -> Node 1 -> Core 1
stepping 00
CPU 3: Syncing TSC to CPU 0.
sync_master: 1 smp_processor_id() = 00, boot_cpu_id= 00
sync_master: 1 smp_processor_id() = 01, boot_cpu_id= 00
sync_master: 1 smp_processor_id() = 02, boot_cpu_id= 00
sync_master: 2 smp_processor_id() = 00, boot_cpu_id= 00
CPU 3: synchronized TSC with CPU 0 (last diff -4 cycles, maxerr 1097 cycles)
Brought up 4 CPUs
> -Original Message-
> From: YhLu
> Sent: Wednesday, July 06, 2005 3:25 PM
> To: Andi Kleen
> Cc: Peter Buckingham; linux-kernel@vger.kernel.org
> Subject: 2.6.13-rc2 with dual way dual core ck804 MB
>
> andi,
>
> the core1/node0 take a long while to get TSC synchronized. Is
> it normal?
> i guess
> "CPU 1: synchronized TSC with CPU 0" should be just after
> "CPU 1: Syncing TSC to CPU0"
>
> YH
>
>
> cpu 1: setting up apic clock
> cpu 1: enabling apic timer
> CPU 1: Syncing TSC to CPU 0.
> CPU has booted.
> waiting for cpu
RE: 2.6.13-rc2 with dual way dual core ck804 MB
Andi,
Can you look at the patch? It could solve the timing problem.
I also move your ext_apic_id patch into 2.6.13 manaully.
YH
> -Original Message-
> From: YhLu
> Sent: Wednesday, July 06, 2005 5:51 PM
> To: Andi Kleen
> Cc: 'Peter Buckingham'; linux-kernel@vger.kernel.org;
> '[EMAIL PROTECTED]'
> Subject: RE: 2.6.13-rc2 with dual way dual core ck804 MB
>
> andi,
>
> please refer the patch, it will move cpu_set(,
> cpu_callin_map) from smi_callin to start_secondary.
>
> ---
> /home/yhlu/xx1/linux-2.6.13-rc2/arch/x86_64/kernel/smpboot.c.o
> rig 2005-07-06 18:41:16.789767168 -0700
> +++
> /home/yhlu/xx1/linux-2.6.13-rc2/arch/x86_64/kernel/smpboot.c
> 2005-07-06 18:45:11.923021480 -0700
> @@ -442,7 +442,7 @@
> /*
> * Allow the master to continue.
> */
> - cpu_set(cpuid, cpu_callin_map);
> +// cpu_set(cpuid, cpu_callin_map); // moved to
> start_secondary by yhlu
> }
>
> static inline void set_cpu_sibling_map(int cpu) @@ -529,8 +529,11 @@
> /* Wait for TSC sync to not schedule things before.
>We still process interrupts, which could see an
> inconsistent
>time in that window unfortunately. */
> +
> tsc_sync_wait();
>
> + cpu_set(smp_processor_id(), cpu_callin_map); // moved from
> + smp_callin by yhlu
> +
> cpu_idle();
> }
>
> the other solution will be change cpu_callin_map to
> cpu_online_map in do_boot_cpu
>
> /*
> * allow APs to start initializing.
> */
> Dprintk("Before Callout %d.\n", cpu);
> cpu_set(cpu, cpu_callout_map);
> Dprintk("After Callout %d.\n", cpu);
>
> /*
> * Wait 5s total for a response
> */
> for (timeout = 0; timeout < 5; timeout++) {
> if (cpu_isset(cpu, cpu_callin_map))
> --> cpu_online_map
> break; /* It has booted */
> udelay(100);
> }
>
> if (cpu_isset(cpu, cpu_callin_map)) {
> > cpu_online_map
> /* number CPUs logically, starting
> from 1 (BSP is 0) */
> Dprintk("CPU has booted.\n");
> } else {
> boot_error = 1;
> if (*((volatile unsigned char
> *)phys_to_virt(SMP_TRAMPOLINE_BASE))
> == 0xA5)
> /* trampoline started but...? */
> printk("Stuck ??\n");
> else
> /* trampoline code not run */
> printk("Not responding.\n");
> #if APIC_DEBUG
> inquire_remote_apic(apicid); #endif
> }
>
>
> the result will be
>
> Booting processor 1/1 rip 6000 rsp 81013ff89f58
> Initializing CPU#1 masked ExtINT on CPU#1 Calibrating delay
> using timer specific routine.. 4422.98 BogoMIPS (lpj=8845965)
> CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
> CPU: L2 Cache: 1024K (64 bytes/line)
> CPU 1(2) -> Node 0 -> Core 1
> stepping 00
> CPU 1: Syncing TSC to CPU 0.
> sync_master: 1 smp_processor_id() = 00, boot_cpu_id= 00
> sync_master: 2 smp_processor_id() = 00, boot_cpu_id= 00 CPU
> 1: synchronized TSC with CPU 0 (last diff 0 cycles, maxerr
> 595 cycles) -> it is in right place.
> Booting processor 2/2 rip 6000 rsp 81023ff1df58
> Initializing CPU#2 masked ExtINT on CPU#2 Calibrating delay
> using timer specific routine.. 4422.99 BogoMIPS (lpj=8845997)
> CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
> CPU: L2 Cache: 1024K (64 bytes/line)
> CPU 2(2) -> Node 1 -> Core 0
> stepping 00
> CPU 2: Syncing TSC to CPU 0.
> sync_master: 1 smp_processor_id() = 00, boot_cpu_id= 00
> sync_master: 1 smp_processor_id() = 01, boot_cpu_id= 00
> sync_master: 2 smp_processor_id() = 00, boot_cpu_id= 00 CPU
> 2: synchronized TSC with CPU 0 (last diff -4 cycles, maxerr
> 1097 cycles) Booting processor 3/3 rip 6000 rsp
> 81013ff53f58 Initializing CPU#3 masked ExtINT on CPU#3
> Calibrating delay using timer specific routine.. 4423.03
> BogoMIPS (lpj=8846075)
> CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
> CPU: L2 Cache: 1024K (64 bytes/line)
> CPU 3(2) -> Node 1 -> Core 1
> stepp
x86-64 timing patch after 2.6.12-rc5 with 2 cpu above system
Andi,
I verify the timing problem could happen with any x86-64 system with
more than 2 cpus. ( 2 way dual core, or four way single core).
please refer the patch, it will move cpu_set(, cpu_callin_map) from
smi_callin to start_secondary.
--- /home/yhlu/xx1/linux-2.6.13-rc2/arch/x86_64/kernel/smpboot.c.orig
2005-07-06 18:41:16.789767168 -0700
+++ /home/yhlu/xx1/linux-2.6.13-rc2/arch/x86_64/kernel/smpboot.c
2005-07-06 18:45:11.923021480 -0700
@@ -442,7 +442,7 @@
/*
* Allow the master to continue.
*/
- cpu_set(cpuid, cpu_callin_map);
+// cpu_set(cpuid, cpu_callin_map); // moved to start_secondary by yhlu
}
static inline void set_cpu_sibling_map(int cpu)
@@ -529,8 +529,11 @@
/* Wait for TSC sync to not schedule things before.
We still process interrupts, which could see an inconsistent
time in that window unfortunately. */
+
tsc_sync_wait();
+ cpu_set(smp_processor_id(), cpu_callin_map); // moved from smp_callin by yhlu
+
cpu_idle();
}
the other solution will be change cpu_callin_map to cpu_online_map in
do_boot_cpu
/*
* allow APs to start initializing.
*/
Dprintk("Before Callout %d.\n", cpu);
cpu_set(cpu, cpu_callout_map);
Dprintk("After Callout %d.\n", cpu);
/*
* Wait 5s total for a response
*/
for (timeout = 0; timeout < 5; timeout++) {
if (cpu_isset(cpu, cpu_callin_map))
--> cpu_online_map
break; /* It has booted */
udelay(100);
}
if (cpu_isset(cpu, cpu_callin_map)) {
> cpu_online_map
/* number CPUs logically, starting from 1 (BSP is 0)
*/
Dprintk("CPU has booted.\n");
} else {
boot_error = 1;
if (*((volatile unsigned char
*)phys_to_virt(SMP_TRAMPOLINE_BASE))
== 0xA5)
/* trampoline started but...? */
printk("Stuck ??\n");
else
/* trampoline code not run */
printk("Not responding.\n");
#if APIC_DEBUG
inquire_remote_apic(apicid);
#endif
}
the result will be
Booting processor 1/1 rip 6000 rsp 81013ff89f58
Initializing CPU#1
masked ExtINT on CPU#1
Calibrating delay using timer specific routine.. 4422.98 BogoMIPS
(lpj=8845965)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 1(2) -> Node 0 -> Core 1
stepping 00
CPU 1: Syncing TSC to CPU 0.
sync_master: 1 smp_processor_id() = 00, boot_cpu_id= 00
sync_master: 2 smp_processor_id() = 00, boot_cpu_id= 00
CPU 1: synchronized TSC with CPU 0 (last diff 0 cycles, maxerr 595 cycles)
-> it is in right place.
Booting processor 2/2 rip 6000 rsp 81023ff1df58
Initializing CPU#2
masked ExtINT on CPU#2
Calibrating delay using timer specific routine.. 4422.99 BogoMIPS
(lpj=8845997)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 2(2) -> Node 1 -> Core 0
stepping 00
CPU 2: Syncing TSC to CPU 0.
sync_master: 1 smp_processor_id() = 00, boot_cpu_id= 00
sync_master: 1 smp_processor_id() = 01, boot_cpu_id= 00
sync_master: 2 smp_processor_id() = 00, boot_cpu_id= 00
CPU 2: synchronized TSC with CPU 0 (last diff -4 cycles, maxerr 1097 cycles)
Booting processor 3/3 rip 6000 rsp 81013ff53f58
Initializing CPU#3
masked ExtINT on CPU#3
Calibrating delay using timer specific routine.. 4423.03 BogoMIPS
(lpj=8846075)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 3(2) -> Node 1 -> Core 1
stepping 00
CPU 3: Syncing TSC to CPU 0.
sync_master: 1 smp_processor_id() = 00, boot_cpu_id= 00
sync_master: 1 smp_processor_id() = 01, boot_cpu_id= 00
sync_master: 1 smp_processor_id() = 02, boot_cpu_id= 00
sync_master: 2 smp_processor_id() = 00, boot_cpu_id= 00
CPU 3: synchronized TSC with CPU 0 (last diff -4 cycles, maxerr 1097 cycles)
Brought up 4 CPUs
> -Original Message-
> From: YhLu
> Sent: Wednesday, July 06, 2005 3:25 PM
> To: Andi Kleen
> Cc: Peter Buckingham; linux-kernel_at_vger.kernel.org
> Subject: 2.6.13-rc2 with dual way dual core ck804 MB
>
> andi,
>
> the core1/node0 take a long while to get TSC synchronized. Is
> it normal?
> i guess
> "CPU 1: synchronized TSC with CPU 0" should be just after
> "CPU 1: Syncing TSC to CPU0"
>
> YH
>
>
> cpu 1: setting up apic clock
&g
Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)
Do you mean solve the timing problem for 2 way dual core or 4 way
single core above?
YH
On 7/27/05, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
> sync_tsc was using smp_call_function to ask the boot processor
> to report it's tsc value. smp_call_function performs an IPI_send_allbutself
> which is a broadcast ipi. There is a window during processor startup during
> which the target cpu has started and before it has initialized it's interrupt
> vectors so it can properly process an interrupt. Receveing an interrupt
> during that window will triple fault the cpu and do other nasty things.
>
> Why cli does not protect us from that is beyond me.
>
> The simple fix is to match ia64 and provide a smp_call_function_single.
> Which avoids the broadcast and is more efficient.
>
> This certainly fixes the problem of getting stuck on boot which was
> very easy to trigger on my SMP Hyperthreaded Xeon, and I think
> it fixes it for the right reasons.
>
> I believe this patch suffers from apicid versus logical cpu number confusion.
> I copied the basic logic from smp_send_reschedule and I can't find where
> that translates from the logical cpuid to apicid. So it isn't quite
> correct yet. It should be close enough that it shouldn't be too hard
> to finish it up.
>
> More bug fixes after I have slept but I figured I needed to get this
> one out for review.
>
> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
>
> ---
>
> arch/x86_64/kernel/smp.c | 65
> ++
> arch/x86_64/kernel/smpboot.c | 21 --
> include/asm-x86_64/smp.h |2 +
> 3 files changed, 79 insertions(+), 9 deletions(-)
>
> 571d8bdc5a935b85fb0ce5ff3fac9a59a86efe6e
> diff --git a/arch/x86_64/kernel/smp.c b/arch/x86_64/kernel/smp.c
> --- a/arch/x86_64/kernel/smp.c
> +++ b/arch/x86_64/kernel/smp.c
> @@ -294,6 +294,71 @@ void unlock_ipi_call_lock(void)
> }
>
> /*
> + * this function sends a 'generic call function' IPI to one other CPU
> + * in the system.
> + */
> +static void __smp_call_function_single (int cpu, void (*func) (void *info),
> void *info,
> + int nonatomic, int wait)
> +{
> + struct call_data_struct data;
> + int cpus = 1;
> +
> + data.func = func;
> + data.info = info;
> + atomic_set(&data.started, 0);
> + data.wait = wait;
> + if (wait)
> + atomic_set(&data.finished, 0);
> +
> + call_data = &data;
> + wmb();
> + /* Send a message to all other CPUs and wait for them to respond */
> + send_IPI_mask(cpumask_of_cpu(cpu), CALL_FUNCTION_VECTOR);
> +
> + /* Wait for response */
> + while (atomic_read(&data.started) != cpus)
> + cpu_relax();
> +
> + if (!wait)
> + return;
> +
> + while (atomic_read(&data.finished) != cpus)
> + cpu_relax();
> +}
> +
> +/*
> + * Run a function on another CPU
> + * The function to run. This must be fast and non-blocking.
> + * An arbitrary pointer to pass to the function.
> + * Currently unused.
> + * If true, wait until function has completed on other CPUs.
> + * [RETURNS] 0 on success, else a negative status code.
> + *
> + * Does not return until the remote CPU is nearly ready to execute
> + * or is or has executed.
> + */
> +
> +int smp_call_function_single (int cpu, void (*func) (void *info), void *info,
> + int nonatomic, int wait)
> +{
> +
> + int me = get_cpu(); /* prevent preemption and reschedule on another
> processor */
> +
> + if (cpu == me) {
> + printk("%s: trying to call self\n", __func__);
> + put_cpu();
> + return -EBUSY;
> + }
> + spin_lock_bh(&call_lock);
> +
> + __smp_call_function_single(cpu, func,info,nonatomic,wait);
> +
> + spin_unlock_bh(&call_lock);
> + put_cpu();
> + return 0;
> +}
> +
> +/*
> * this function sends a 'generic call function' IPI to all other CPUs
> * in the system.
> */
> 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
> @@ -229,9 +229,6 @@ static __cpuinit void sync_master(void *
> {
> unsigned long flags, i;
>
> - if (smp_processor_id() != boot_cpu_id)
> - return;
> -
> go[MASTER] = 0;
>
> local_irq_save(flags);
> @@ -280,7 +277,7 @@ get_delta(long *rt, long *master)
> return tcenter - best_tm;
> }
>
> -static __cpuinit void sync_tsc(void)
> +static __cpuinit void sync_tsc(unsigned int master)
> {
> int i, done = 0;
> long delta, adj, adjust_latency = 0;
> @@ -294,9 +291,17 @@ static __cpuinit void sync_tsc(void)
> } t[NUM_ROUNDS] __cpuinitdata;
> #endif
>
> + printk(KERN_INFO "CPU %d: Syncing TSC to CPU %u.\n",
> + smp_processor_id(), master);
> +
> go[MASTER] = 1;
>
> -
Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)
I have some problem with this patch.
YH
On 7/28/05, yhlu <[EMAIL PROTECTED]> wrote:
> Do you mean solve the timing problem for 2 way dual core or 4 way
> single core above?
>
> YH
>
> On 7/27/05, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> >
> > sync_tsc was using smp_call_function to ask the boot processor
> > to report it's tsc value. smp_call_function performs an IPI_send_allbutself
> > which is a broadcast ipi. There is a window during processor startup during
> > which the target cpu has started and before it has initialized it's
> > interrupt
> > vectors so it can properly process an interrupt. Receveing an interrupt
> > during that window will triple fault the cpu and do other nasty things.
> >
> > Why cli does not protect us from that is beyond me.
> >
> > The simple fix is to match ia64 and provide a smp_call_function_single.
> > Which avoids the broadcast and is more efficient.
> >
> > This certainly fixes the problem of getting stuck on boot which was
> > very easy to trigger on my SMP Hyperthreaded Xeon, and I think
> > it fixes it for the right reasons.
> >
> > I believe this patch suffers from apicid versus logical cpu number
> > confusion.
> > I copied the basic logic from smp_send_reschedule and I can't find where
> > that translates from the logical cpuid to apicid. So it isn't quite
> > correct yet. It should be close enough that it shouldn't be too hard
> > to finish it up.
> >
> > More bug fixes after I have slept but I figured I needed to get this
> > one out for review.
> >
> > Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
> >
> > ---
> >
> > arch/x86_64/kernel/smp.c | 65
> > ++
> > arch/x86_64/kernel/smpboot.c | 21 --
> > include/asm-x86_64/smp.h |2 +
> > 3 files changed, 79 insertions(+), 9 deletions(-)
> >
> > 571d8bdc5a935b85fb0ce5ff3fac9a59a86efe6e
> > diff --git a/arch/x86_64/kernel/smp.c b/arch/x86_64/kernel/smp.c
> > --- a/arch/x86_64/kernel/smp.c
> > +++ b/arch/x86_64/kernel/smp.c
> > @@ -294,6 +294,71 @@ void unlock_ipi_call_lock(void)
> > }
> >
> > /*
> > + * this function sends a 'generic call function' IPI to one other CPU
> > + * in the system.
> > + */
> > +static void __smp_call_function_single (int cpu, void (*func) (void
> > *info), void *info,
> > + int nonatomic, int wait)
> > +{
> > + struct call_data_struct data;
> > + int cpus = 1;
> > +
> > + data.func = func;
> > + data.info = info;
> > + atomic_set(&data.started, 0);
> > + data.wait = wait;
> > + if (wait)
> > + atomic_set(&data.finished, 0);
> > +
> > + call_data = &data;
> > + wmb();
> > + /* Send a message to all other CPUs and wait for them to respond */
> > + send_IPI_mask(cpumask_of_cpu(cpu), CALL_FUNCTION_VECTOR);
> > +
> > + /* Wait for response */
> > + while (atomic_read(&data.started) != cpus)
> > + cpu_relax();
> > +
> > + if (!wait)
> > + return;
> > +
> > + while (atomic_read(&data.finished) != cpus)
> > + cpu_relax();
> > +}
> > +
> > +/*
> > + * Run a function on another CPU
> > + * The function to run. This must be fast and non-blocking.
> > + * An arbitrary pointer to pass to the function.
> > + * Currently unused.
> > + * If true, wait until function has completed on other CPUs.
> > + * [RETURNS] 0 on success, else a negative status code.
> > + *
> > + * Does not return until the remote CPU is nearly ready to execute
> > + * or is or has executed.
> > + */
> > +
> > +int smp_call_function_single (int cpu, void (*func) (void *info), void
> > *info,
> > + int nonatomic, int wait)
> > +{
> > +
> > + int me = get_cpu(); /* prevent preemption and reschedule on another
> > processor */
> > +
> > + if (cpu == me) {
> > + printk("%s: trying to call self\n", __func__);
> > + put_cpu();
> > + return -EBUSY;
> > + }
> > + spin_lock_bh(&call_lock);
> > +
> > + __smp_call_function_single(cpu, func,info,nonatomic,wait);
> > +
> > + spin_unlock_bh(&call_lock);
>
Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)
if using you patch, the "synchronized TSC with CPU" never come out. then with your patch, I add back patch that moving set callin_map from smp_callin to start_secondary. It told me can not inquire the apic for the CPU 12 YH Initializing CPU#1 masked ExtINT on CPU#1 Calibrating delay using timer specific routine.. 3600.30 BogoMIPS (lpj=7200601) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 1(2) -> Node 0 -> Core 1 stepping 02 CPU 1: Syncing TSC to CPU 0. CPU 1: synchronized TSC with CPU 0 (last diff 0 cycles, maxerr 1415 cycles) On 7/28/05, Eric W. Biederman <[EMAIL PROTECTED]> wrote: > yhlu <[EMAIL PROTECTED]> writes: > > > I have some problem with this patch. > > > > YH > > > > On 7/28/05, yhlu <[EMAIL PROTECTED]> wrote: > >> Do you mean solve the timing problem for 2 way dual core or 4 way > >> single core above? > > As best as I can determine the problem is possible any time > you have more than 2 cpus (from the kernels perspective), > but you have ti hit a fairly narrow window in cpu start up. > > What problem do you have with this patch. > > Eric > - 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 io_apic.c: Memorize at bootup where the i8259 is connected
Is that for Nvidia CK804 stuff?
Actually in LinuxBIOS I swap the irq 0 and 2 entries in mptable to
solve the problem. and it could work well with current code.
YH
On 7/29/05, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
> Currently we attempt to restore virtual wire mode on reboot, which
> only works if we can figure out where the i8259 is connected. This
> is very useful when we kexec another kernel and likely helpful
> when dealing with a BIOS that make assumptions about how the system is setup.
>
> Since the acpi MADT table does not provide the location where the i8259
> is connected we have to look at the hardware to figure it out.
>
> Most systems have the i8259 connected to the local apic of the cpu so
> won't be affected but people running on Opteron and some serverworks chipsets
> should be able to use kexec now.
>
> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
> ---
>
> arch/x86_64/kernel/io_apic.c | 52
> ++
> 1 files changed, 47 insertions(+), 5 deletions(-)
>
> 96c59dd871b00735ef159ddf0d68f338958387fc
> diff --git a/arch/x86_64/kernel/io_apic.c b/arch/x86_64/kernel/io_apic.c
> --- a/arch/x86_64/kernel/io_apic.c
> +++ b/arch/x86_64/kernel/io_apic.c
> @@ -45,6 +45,9 @@ int sis_apic_bug; /* not actually suppor
>
> static int no_timer_check;
>
> +/* Where if anywhere is the i8259 connect in external int mode */
> +static int ioapic_i8259_pin = -1;
> +
> static DEFINE_SPINLOCK(ioapic_lock);
>
> /*
> @@ -330,7 +333,7 @@ static int find_irq_entry(int apic, int
> /*
> * Find the pin to which IRQ[irq] (ISA) is connected
> */
> -static int find_isa_irq_pin(int irq, int type)
> +static int __init find_isa_irq_pin(int irq, int type)
> {
> int i;
>
> @@ -1096,6 +1099,44 @@ void __apicdebuginit print_PIC(void)
>
> #endif /* 0 */
>
> +static void __init find_i8259_pin(void)
> +{
> + struct IO_APIC_route_entry entry;
> + unsigned long flags;
> + int pin, pins;
> +
> + ioapic_i8259_pin = -1;
> +
> + /* Find the number of pins on the primary ioapic */
> + spin_lock_irqsave(&ioapic_lock, flags);
> + pins = ((io_apic_read(0, 0x01) >> 16) & 0xff) + 1;
> + spin_unlock_irqrestore(&ioapic_lock, flags);
> +
> + /* See if any of the pins is in ExtINT mode */
> + for(pin = 0; pin < pins; pin++) {
> + spin_lock_irqsave(&ioapic_lock, flags);
> + *(((int *)&entry) + 0) = io_apic_read(0, 0x10 + 2 * pin);
> + *(((int *)&entry) + 1) = io_apic_read(0, 0x11 + 2 * pin);
> + spin_unlock_irqrestore(&ioapic_lock, flags);
> +
> + /* If the interrupt line is enabled and in ExtInt mode
> +* I have found the pin where the i8259 is connected.
> +*/
> + if ((entry.mask == 0) && (entry.delivery_mode ==
> dest_ExtINT)) {
> + ioapic_i8259_pin = pin;
> + break;
> + }
> + }
> +
> + /* If we could not find an appropriate pin by looking at the ioapic
> +* the i8259 probably isn't connected to the ioapic but give
> +* the mptable a chance anyway.
> +*/
> + if (ioapic_i8259_pin == -1) {
> + ioapic_i8259_pin = find_isa_irq_pin(0, mp_ExtINT);
> + }
> +}
> +
> static void __init enable_IO_APIC(void)
> {
> union IO_APIC_reg_01 reg_01;
> @@ -1138,11 +1179,11 @@ void disable_IO_APIC(void)
> clear_IO_APIC();
>
> /*
> -* If the i82559 is routed through an IOAPIC
> +* If the i8259 is routed through an IOAPIC
> * Put that IOAPIC in virtual wire mode
> * so legacy interrups can be delivered.
> */
> - pin = find_isa_irq_pin(0, mp_ExtINT);
> + pin = ioapic_i8259_pin;
> if (pin != -1) {
> struct IO_APIC_route_entry entry;
> unsigned long flags;
> @@ -1154,7 +1195,7 @@ void disable_IO_APIC(void)
> entry.polarity= 0; /* High */
> entry.delivery_status = 0;
> entry.dest_mode = 0; /* Physical */
> - entry.delivery_mode = 7; /* ExtInt */
> + entry.delivery_mode = dest_ExtINT; /* ExtInt */
> entry.vector = 0;
> entry.dest.physical.physical_dest = 0;
>
> @@ -1626,7 +1667,7 @@ static inline void check_timer(void)
> enable_8259A_irq(0);
>
> pin1 = find_isa_irq_pin(0, mp_INT);
> - pin2 = find_isa_irq_pin(0, mp_ExtINT);
> + pin2 = ioapic_i8259_pin;
>
> apic_printk(APIC_VERBOSE,KERN_INFO "..TIMER: vector=0x%02X pin1=%d
> pin2=%d\n", vector, pin1, pin2);
>
> @@ -1723,6 +1764,7 @@ __setup("no_timer_check", notimercheck);
>
> void __init setup_IO_APIC(void)
> {
> + find_i8259_pin();
> enable_IO_APIC();
>
> if (acpi_ioapic)
> -
> To unsubscribe from this list: send the line "uns
Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)
Can we put tsc_sync_wait() back to smp_callin? So that it will be executed serially and we can get "synchronized TSC with CPU"? 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: [PATCH] x86_64: sync_tsc fix the race (so we can boot)
I will use linus's latest tree to have a try. YH On 7/29/05, Eric W. Biederman <[EMAIL PROTECTED]> wrote: > yhlu <[EMAIL PROTECTED]> writes: > > > if using you patch, the > > "synchronized TSC with CPU" never come out. > > > > then with your patch, I add back patch that moving set callin_map from > > smp_callin to start_secondary. It told me can not inquire the apic for > > the CPU 12 > > Hmm. You didn't post enough of a boot log for me to see the problem. > Does it boot and you don't see the message or is it something > else. > > > Can we put tsc_sync_wait() back to smp_callin? > > > > So that it will be executed serially and we can get > > "synchronized TSC with CPU"? > > Currently that just seems silly. That code should be async > safe. > > But it sounds like you have some weird bug I don't understand. > > Eric > - 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: sync_tsc fix the race (so we can boot)
Eric, Latest tree works. YH Booting processor 1/4 APIC 0x1 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) 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 -4 cycles, maxerr 896 cycles) Calibrating delay using timer specific routine.. 4000.28 BogoMIPS (lpj=8000572) 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 -2 cycles, maxerr 909 cycles) Calibrating delay using timer specific routine.. 4000.15 BogoMIPS (lpj=8000317) 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 -16 cycles, maxerr 1496 cycles) - 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
Roland, In LinuxBIOS, If I enable the prefmem64 to use real 64 range. the IB driver in Kernel can not be loaded. YH PCI: 00:18.0 1c1 <- [0x001000 - 0x003fff] io PCI: 00:18.0 1b9 <- [0xfce000 - 0xfcf07f] prefmem PCI: 00:18.0 1b1 <- [0x00fc00 - 0x00fd2f] mem PCI: 01:0f.0 24 <- [0xfce000 - 0xfcf07f] bus 4 prefmem PCI: 01:0f.0 20 <- [0x00fd10 - 0x00fd1f] bus 4 mem PCI: 04:00.0 10 <- [0x00fd10 - 0x00fd1f] mem64 PCI: 04:00.0 18 <- [0xfcf000 - 0xfcf07f] prefmem64 PCI: 04:00.0 20 <- [0xfce000 - 0xfcefff] prefmem64 ib_mthca: Mellanox InfiniBand HCA driver v0.06 (June 23, 2005) ib_mthca: Initializing Mellanox Technologies MT25208 InfiniHost III Ex (Tavor c) ib_mthca :04:00.0: Failed to initialize queue pair table, aborting. 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
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/
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&view=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 __in
X86_64 kernel support MAX memory.
Andi, How much is max RAM 2.6.11 x86_64 support on AMD64? 64G or 128G? 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: X86_64 kernel support MAX memory.
I got a system with 8 way Opteron. Every CPU has 16G memory. 2.6 kernel x86_64, it will crash when it start the Fifth node. YH > -Original Message- > From: Andi Kleen [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 15, 2005 4:08 AM > To: YhLu > Cc: linux-kernel@vger.kernel.org > Subject: Re: X86_64 kernel support MAX memory. > > On Mon, Feb 14, 2005 at 07:32:42PM -0800, YhLu wrote: > > Andi, > > > > How much is max RAM 2.6.11 x86_64 support on AMD64? > > 64G or 128G? > > 46bits in theory (64TB), however current CPUs only support > upto 40bits (AMD) or 36bits (Intel). There is some other > code that is also limited to 40bits right now like AGP or > IOMMU or MTRR, that is all due to hardware limitations. > > -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: X86_64 kernel support MAX memory.
If only use 64G RAM, it works well. YH > -Original Message- > From: Andi Kleen [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 15, 2005 12:15 PM > To: YhLu > Cc: linux-kernel@vger.kernel.org > Subject: Re: X86_64 kernel support MAX memory. > > On Tue, Feb 15, 2005 at 10:49:05AM -0800, YhLu wrote: > > I got a system with 8 way Opteron. Every CPU has 16G memory. > > > > 2.6 kernel x86_64, it will crash when it start the Fifth node. > > The kernel has been successfully booted on 8 CPU Opteron > systems before. > Most likely it is something specific to your system. > > -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: X86_64 kernel support MAX memory.
It passed the memtest86+ 3.1a No oops dump, it just restart the system. YH > -Original Message- > From: Andi Kleen [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 15, 2005 2:42 PM > To: YhLu > Cc: linux-kernel@vger.kernel.org > Subject: Re: X86_64 kernel support MAX memory. > > On Tue, Feb 15, 2005 at 02:34:17PM -0800, YhLu wrote: > > If only use 64G RAM, it works well. > > Are you sure the RAM is not broken? The more you have of it > the more likely one DIMM is bad. > > Otherwise debug it. What's the oops dump? > > -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: X86_64 kernel support MAX memory.
Thanks. I will test 64G on node 4-7 only or 64G on node 0-3. YH > -Original Message- > From: Andi Kleen [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 15, 2005 2:55 PM > To: YhLu > Cc: linux-kernel@vger.kernel.org > Subject: Re: X86_64 kernel support MAX memory. > > On Tue, Feb 15, 2005 at 02:57:14PM -0800, YhLu wrote: > > It passed the memtest86+ 3.1a > > Are you sure it even tests the full 128GB? Traditionally PAE > only supports 64GB. > > > > > No oops dump, it just restart the system. > > At what point exactly? You probably have a serial console. > What are the last lines. > > That could well be an ECC error. You can see if mcelog logs > something after reboot (kernel should preserve machine check events) > > Or you could switch around the DIMMs of the CPUs for testing. > > -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/
node_to_cpumask x86_64 broken
I add some printk in k8_bus.c node id = 0, node_to_cpumask = f i= 0 ldtbus = 0 i= 1 ldtbus = 40100 i= 2 ldtbus = 0 node id = 1, node_to_cpumask = 0 i= 0 ldtbus = 0 i= 1 ldtbus = 0 i= 2 ldtbus = 70500 node id = 2, node_to_cpumask = 0 i= 0 ldtbus = 0 i= 1 ldtbus = 0 i= 2 ldtbus = 0 node id = 3, node_to_cpumask = 0 i= 0 ldtbus = 0 i= 1 ldtbus = 0 i= 2 ldtbus = 0 k8-bus.c: bus 5 has empty cpu mask k8-bus.c: bus 6 has empty cpu mask k8-bus.c: bus 7 has empty cpu mask it seems node_to_cpu_mask broken. I'm using 2.6.11-RC4. 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: node_to_cpumask x86_64 broken
forget about it. I found the reason: I only put node 0 has RAM installed. YH > -Original Message- > From: YhLu > Sent: Wednesday, February 16, 2005 9:40 PM > To: Andi Kleen > Cc: linux-kernel@vger.kernel.org > Subject: node_to_cpumask x86_64 broken > > I add some printk in k8_bus.c > > node id = 0, node_to_cpumask = f > i= 0 ldtbus = 0 > i= 1 ldtbus = 40100 > i= 2 ldtbus = 0 > node id = 1, node_to_cpumask = 0 > i= 0 ldtbus = 0 > i= 1 ldtbus = 0 > i= 2 ldtbus = 70500 > node id = 2, node_to_cpumask = 0 > i= 0 ldtbus = 0 > i= 1 ldtbus = 0 > i= 2 ldtbus = 0 > node id = 3, node_to_cpumask = 0 > i= 0 ldtbus = 0 > i= 1 ldtbus = 0 > i= 2 ldtbus = 0 > k8-bus.c: bus 5 has empty cpu mask > k8-bus.c: bus 6 has empty cpu mask > k8-bus.c: bus 7 has empty cpu mask > > it seems node_to_cpu_mask broken. > > I'm using 2.6.11-RC4. > > 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/ > - 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: node_to_cpumask x86_64 broken
Yes. should not use prink(ERR YH > -Original Message- > From: Andi Kleen [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 16, 2005 10:22 PM > To: YhLu > Cc: linux-kernel@vger.kernel.org > Subject: Re: node_to_cpumask x86_64 broken > > On Wed, Feb 16, 2005 at 10:30:51PM -0800, YhLu wrote: > > forget about it. I found the reason: I only put node 0 has > RAM installed. > > There is some problem with this code - it complains on a few machines. > However it's relatively harmless when this happens, so I > haven't looked it yet. Should perhaps take out the printk. > > -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/
interrupt
Interrupts always go to CPU 11. If dual core is diabled, it always go to CPU5. It is OK on 32bit mode. CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12 CPU13 CPU14 CPU15 0:409 0 0 0 0 0 0 0 0 0229 37399 0 0 0 0IO-APIC-edge timer 2: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 XT-PIC cascade 4: 0 0 0 0 0 0 0 0 0 0 0 4915 0 0 0 0IO-APIC-edge serial 8: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0IO-APIC-edge rtc 14: 0 0 0 0 0 0 0 0 0 0 0 10 0 0 0 0IO-APIC-edge ide0 19: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC-level ohci1394 20: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC-level libata 21: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC-level libata 22: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC-level ohci_hcd 23: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC-level ehci_hcd NMI: 1 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 LOC: 37688 37965 37965 37965 37965 37965 37965 37965 37965 37965 37965 37446 37965 37965 37965 37966 ERR:447 MIS: 0 - 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/
2.6.11-rc3 x86-64 compile err on suse 9.1
CC arch/x86_64/kernel/asm-offsets.s arch/x86_64/kernel/asm-offsets.c: In function `main': arch/x86_64/kernel/asm-offsets.c:65: error: invalid application of `sizeof' to an incomplete type arch/x86_64/kernel/asm-offsets.c:66: error: dereferencing pointer to incomplete type arch/x86_64/kernel/asm-offsets.c:67: error: dereferencing pointer to incomplete type make[1]: *** [arch/x86_64/kernel/asm-offsets.s] Error 1 make: *** [arch/x86_64/kernel/asm-offsets.s] Error 2 - 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: [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: [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/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+patch&hl=en&ct=clnk&cd=4&gl=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: [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/
