2.6.25-mm1 - Kernel

This is a discussion on 2.6.25-mm1 - Kernel ; Yinghai Lu wrote: >> ... > > geode is using SMI to simulate the pci conf space, wonder that could be problem. > On the current OLPC system, we don't use the SMI-based PCI config space simulator. The code for ...

+ Reply to Thread
Page 3 of 6 FirstFirst 1 2 3 4 5 ... LastLast
Results 41 to 60 of 105

Thread: 2.6.25-mm1

  1. Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware



    Yinghai Lu wrote:
    >> ...

    >
    > geode is using SMI to simulate the pci conf space, wonder that could be problem.
    >


    On the current OLPC system, we don't use the SMI-based PCI config space
    simulator. The code for that "VSA" module is only partially open
    sourced (some of it is open, and some of it is just not available). The
    parts of it for which we do have source can only be compiled with an old
    proprietary toolchain that is no longer available.

    Instead of using the SMI-based simulation, we have added a PCI
    configuration access method in the kernel that supplies the necessary
    information from a table. The code for that hardware-specific access
    method is roughly 40 lines of code plus a few data tables.

    In the past few weeks, I have developed a rather complete Open
    Firmware-based reimplementation of the SMI PCI config hardware
    emulator. All-told, it requires over 1000 lines. It remains to be
    seen whether the complicated version will ultimately be deployed.
    Personally, I find it distasteful to use a lot of code to make the
    hardware pretend that it is something other than what it really is, when
    a much smaller driver works just as well. The SMI-based emulator is
    quite difficult to understand and maintain, because the Geode SMI
    handling mechanism is complex, incompletely documented, and suffers from
    many of the multiple-mode-switches problems as real-mode to
    protected-mode gateway code.

    > later you have 64 runtime service for 64 platform like UEFI?
    >


    Possibly. 64-bit systems are not a problem per se - there have been
    64-bit OFW implementations for 64-bit architectures like SPARC and Alpha
    dating back to a long time ago. The main issue from my point of view is
    whether or not there is a customer to motivate the work.
    > YH
    >
    >

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware



    Yinghai Lu wrote:
    >
    >> path" for kernel builds.
    >>
    >> b) OFW loads the bzimage kernel at 0x100000 and the ramdisk image, if any,
    >> at 0x800000.
    >>

    >
    > so you are assuming that your uncompressed vmlinux only use less 8M space?
    >
    > you are supposed to check the bzImage to get uncompressed vmlinux size.
    >


    The 0x800000 ramdisk load address is an OLPC-specific firmware
    implementation detail that could easily be changed without affecting
    anything else. I probably shouldn't have mentioned it because it isn't
    really an integral part of the interface "contract".

    I certainly hope that the OLPC kernel never gets anywhere near that
    size. The OLPC hardware has limited configurability, so it's not
    plausible that the kernel would grow that large to include a huge kit of
    drivers. If the kernel file becomes large as a result of including the
    initramfs in the same file, the 0x800000 ramdisk load address won't
    apply (because there won't be a separate load of the initramfs file), so
    the kernel could be extend way past that boundary with no problems.

    If we get to the point where we do need huge kernels on OLPC, we can
    release a firmware upgrade along with the new OS. We have mechanisms
    for coordinating firmware and OS upgrades.

    If a new customer for OFW on x86 appears, I'll remember to float the
    boundary above the bzImage uncompressed size (assuming that the bzimage
    format is still applicable when that happens).
    > YH
    >
    >

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. [Was: 2.6.25-mm1]

    On 04/18/2008 10:47 AM, Andrew Morton wrote:
    > ftp://ftp.kernel.org/pub/linux/kerne...25/2.6.25-mm1/


    Hi,

    $ ls /usr/share/man/cat3readlin
    Segmentation fault

    [the file doesn't exist.]
    This is probably the same bug as in -rc8-mm2 I reported here:
    http://www.opensubscriber.com/messag...g/9008289.html

    general protection fault: 0000 [1] SMP
    last sysfs file: /sys/devices/pci0000:00/0000:00:19.0/net/eth0/statistics/collisions
    CPU 0
    Modules linked in: test ipv6 tun bitrev arc4 ecb crypto_blkcipher cryptomgr
    crypto_algapi ath5k mac80211 crc32 sr_mod usbhid ohci1394 rtc_cmos hid rtc_core
    cfg80211 ieee1394 cdrom ehci_hcd rtc_lib ff_memless floppy evdev
    Pid: 24838, comm: man Not tainted 2.6.25-mm1_64 #403
    RIP: 0010:[] [] __d_lookup+0x97/0x160
    RSP: 0018:ffff8100337d1b98 EFLAGS: 00010206
    RAX: 00f0000000000000 RBX: 00f0000000000000 RCX: 0000000000000012
    RDX: ffff8100200830e0 RSI: ffff8100337d1ca8 RDI: ffff810079195708
    RBP: ffff8100337d1bf8 R08: ffff8100337d1ca8 R09: 0000000000000000
    R10: 000000000000013d R11: 0000000000000246 R12: ffff8100200830c8
    R13: 00000000198eaed5 R14: ffff810079195708 R15: ffff8100337d1bc8
    FS: 00007f447b5c06f0(0000) GS:ffffffff80664000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 0000000001484f88 CR3: 000000005fac4000 CR4: 00000000000006e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process man (pid: 24838, threadinfo ffff8100337d0000, task ffff810034418000)
    Stack: ffff8100337d1ca8 000000000000000b ffff810079195710 0000000b792561a0
    ffff81003136600f ffffffff802f9073 00f0000000000000 0000000000000001
    ffff8100337d1e48 ffff8100337d1e48 ffff8100337d1ca8 ffff8100337d1cb8
    Call Trace:
    [] ? ext3_lookup+0xc3/0x100
    [] do_lookup+0x35/0x220
    [] __link_path_walk+0x252/0x1010
    [] ? mntput_no_expire+0x2a/0x140
    [] path_walk+0x6e/0xe0
    [] do_path_lookup+0xa2/0x240
    [] __path_lookup_intent_open+0x67/0xd0
    [] path_lookup_open+0xc/0x10
    [] do_filp_open+0xaa/0x990
    [] ? up+0x34/0x50
    [] ? unlock_kernel+0x29/0x30
    [] ? mntput_no_expire+0x2a/0x140
    [] ? get_unused_fd_flags+0x8c/0x140
    [] do_sys_open+0x76/0x110
    [] sys_open+0x1b/0x20
    [] system_call_after_swapgs+0x7b/0x80


    Code: 48 89 c3 48 8b 55 d0 8b 45 bc 48 85 d2 48 89 45 a8 75 18 eb 5f 0f 1f 80 00
    00 00 00 48 8b 1b 48 89 5d d0 49 8b 07 48 85 c0 74 49 <48> 8b 03 4c 8d 63 e8 0f
    18 08 45 39 6c 24 30 75 e0 4d 39 74 24
    RIP [] __d_lookup+0x97/0x160
    RSP
    ---[ end trace cb4ec4895332b217 ]---
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [Was: 2.6.25-mm1]

    On Mon, Apr 21, 2008 at 10:31:40AM +0200, Jiri Slaby wrote:

    hlist_for_each_entry_rcu(dentry, node, head, d_hash) {
    struct qstr *qstr;

    if (dentry->d_name.hash != hash)
    continue;

    walking into node == (struct hlist_node *)0x00f0000000000000...

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. fault in __d_lookup [Was: 2.6.25-mm1]

    On 04/21/2008 11:06 AM, Al Viro wrote:
    > On Mon, Apr 21, 2008 at 10:31:40AM +0200, Jiri Slaby wrote:
    >
    > hlist_for_each_entry_rcu(dentry, node, head, d_hash) {
    > struct qstr *qstr;
    >
    > if (dentry->d_name.hash != hash)
    > continue;
    >
    > walking into node == (struct hlist_node *)0x00f0000000000000...


    Yup, true, In the last oops I stuck on memcmp few lines below.

    BTW. it's 100% reproducible after it happens once, but fixable by reboot. Any
    tests I should run (memtest, some printks sticked anywhere)?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: fault in __d_lookup [Was: 2.6.25-mm1]

    On Mon, Apr 21, 2008 at 11:37:40AM +0200, Jiri Slaby wrote:
    > On 04/21/2008 11:06 AM, Al Viro wrote:
    > >On Mon, Apr 21, 2008 at 10:31:40AM +0200, Jiri Slaby wrote:
    > >
    > > hlist_for_each_entry_rcu(dentry, node, head, d_hash) {
    > > struct qstr *qstr;
    > >
    > > if (dentry->d_name.hash != hash)
    > > continue;
    > >
    > >walking into node == (struct hlist_node *)0x00f0000000000000...

    >
    > Yup, true, In the last oops I stuck on memcmp few lines below.
    >
    > BTW. it's 100% reproducible after it happens once, but fixable by reboot.
    > Any tests I should run (memtest, some printks sticked anywhere)?


    Well, if list has such turd in it, you'll certainly hit it every time
    you walk that list, so 100% reproducible is not surprising.

    How well is it reproducible from fresh boot?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: fault in __d_lookup [Was: 2.6.25-mm1]

    On 04/21/2008 11:45 AM, Al Viro wrote:
    > On Mon, Apr 21, 2008 at 11:37:40AM +0200, Jiri Slaby wrote:
    >> On 04/21/2008 11:06 AM, Al Viro wrote:
    >>> On Mon, Apr 21, 2008 at 10:31:40AM +0200, Jiri Slaby wrote:
    >>>
    >>> hlist_for_each_entry_rcu(dentry, node, head, d_hash) {
    >>> struct qstr *qstr;
    >>>
    >>> if (dentry->d_name.hash != hash)
    >>> continue;
    >>>
    >>> walking into node == (struct hlist_node *)0x00f0000000000000...

    >> Yup, true, In the last oops I stuck on memcmp few lines below.
    >>
    >> BTW. it's 100% reproducible after it happens once, but fixable by reboot.
    >> Any tests I should run (memtest, some printks sticked anywhere)?

    >
    > Well, if list has such turd in it, you'll certainly hit it every time
    > you walk that list, so 100% reproducible is not surprising.
    >
    > How well is it reproducible from fresh boot?


    Few days with suspend/resume cycles. This one was booted 12 hours ago, one
    suspend/resume. Will keep an eye on it and keep you informed.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: 2.6.25-mm1

    [Added snd-pcsp author to Cc]

    At Fri, 18 Apr 2008 21:29:34 -0700,
    Andrew Morton wrote:
    >
    > On Sat, 19 Apr 2008 00:14:29 -0400 Dmitry Torokhov wrote:
    >
    > > On Fri, Apr 18, 2008 at 08:02:37PM -0700, Andrew Morton wrote:
    > > > On Fri, 18 Apr 2008 22:13:43 -0400 Joseph Fannin wrote:
    > > >
    > > > > On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
    > > > > >
    > > > > > ftp://ftp.kernel.org/pub/linux/kerne...25/2.6.25-mm1/
    > > > >
    > > > > I've been seeing the following backtraces since 2.6.25-rc8-mm1 -- at
    > > > > least, since that's the earliest -mm I've built in a while. I don't
    > > > > get the same in mainline.
    > > > >
    > > > > No idea who to CC:
    > > >
    > > > I have a few ideas.
    > > >
    > > > > I've sat on this report long enough.
    > > >
    > > > Thanks for the report.
    > > >
    > > > > I'm going to send a few different reports in separate mails, so I'll
    > > > > put my dmesg and .config up on a server:
    > > > >
    > > > > http://home.columbus.rr.com/jfannin3/dmesg.txt
    > > > > http://home.columbus.rr.com/jfannin3...2.6.25-mm1.txt
    > > > >
    > > > > [ 451.915553] sysfs: duplicate filename 'pcspkr' can not be created
    > > > > [ 451.915731] ------------[ cut here ]------------
    > > > > [ 451.915851] WARNING: at fs/sysfs/dir.c:427 sysfs_add_one+0x85/0xe0()
    > > > > [ 451.915981] Modules linked in: snd_pcsp(+) ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_mpu401_uart snd_seq_dummy snd_seq_oss snd_seq_midi psmouse snd_rawmidi serio_raw snd_seq_midi_event snd_seq button i2c_viapro snd_timer snd_seq_device pcspkr i2c_core snd snd_page_alloc via686a shpchp pci_hotplug parport_pc parport via_agp agpgart soundcore evdev sg sr_mod cdrom sd_mod 8139cp aic7xxx scsi_transport_spi scsi_mod 8139too mii uhci_hcd usbcore raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 multipath linear md_mod thermal processor fan fuse ext4dev mbcache jbd2 crc16
    > > > > [ 451.918960] Pid: 2740, comm: modprobe Tainted: G W 2.6.25-mm1 #7
    > > > > [ 451.929271] [] warn_on_slowpath+0x59/0x80
    > > > > [ 451.929500] [] ? vprintk+0x2f0/0x4a0
    > > > > [ 451.929723] [] ? _spin_unlock+0x2c/0x50
    > > > > [ 451.929918] [] ? ifind+0x4a/0xa0
    > > > > [ 451.930126] [] ? trace_hardirqs_on_caller+0x16/0x150
    > > > > [ 451.930334] [] ? trace_hardirqs_on+0xb/0x10
    > > > > [ 451.930534] [] ? printk+0x20/0x30
    > > > > [ 451.930727] [] sysfs_add_one+0x85/0xe0
    > > > > [ 451.930900] [] create_dir+0x4e/0xb0
    > > > > [ 451.931064] [] sysfs_create_dir+0x30/0x50
    > > > > [ 451.931291] [] ? _spin_unlock+0x2c/0x50
    > > > > [ 451.931485] [] kobject_add_internal+0xb6/0x190
    > > > > [ 451.931656] [] ? kobject_set_name_vargs+0x32/0x40
    > > > > [ 451.931857] [] kobject_add_varg+0x5a/0x60
    > > > > [ 451.932022] [] kobject_init_and_add+0x2f/0x40
    > > > > [ 451.932188] [] bus_add_driver+0x94/0x250
    > > > > [ 451.932364] [] driver_register+0x42/0xf0
    > > > > [ 451.932533] [] platform_driver_register+0x66/0x70
    > > > > [ 451.932702] [] pcsp_init+0x2a/0x2c [snd_pcsp]
    > > > > [ 451.932877] [] sys_init_module+0x87/0x1a0
    > > > > [ 451.933043] [] ? trace_hardirqs_on_caller+0x16/0x150
    > > > > [ 451.933246] [] ? trace_hardirqs_on_thunk+0xc/0x10
    > > > > [ 451.933453] [] sysenter_past_esp+0x78/0xc5


    Seems that snd-pcsp registers as "pcspkr", which is identical with
    input pc-speaker driver. Does the patch below fix the problem?


    Takashi

    ---
    diff -r e8f61dd0b153 sound/drivers/pcsp/pcsp.c
    --- a/sound/drivers/pcsp/pcsp.c Thu Apr 17 17:58:34 2008 +0200
    +++ b/sound/drivers/pcsp/pcsp.c Mon Apr 21 13:06:35 2008 +0200
    @@ -21,7 +21,7 @@
    MODULE_DESCRIPTION("PC-Speaker driver");
    MODULE_LICENSE("GPL");
    MODULE_SUPPORTED_DEVICE("{{PC-Speaker, pcsp}}");
    -MODULE_ALIAS("platformcspkr");
    +MODULE_ALIAS("platform:snd_pcsp");

    static int index = SNDRV_DEFAULT_IDX1; /* Index 0-MAX */
    static char *id = SNDRV_DEFAULT_STR1; /* ID for this card */
    @@ -214,7 +214,7 @@

    static struct platform_driver pcsp_platform_driver = {
    .driver = {
    - .name = "pcspkr",
    + .name = "snd_pcsp",
    .owner = THIS_MODULE,
    },
    .probe = pcsp_probe,
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware

    Mitch Bradley wrote:
    >
    > d) OFW itself lives at the top of the virtual address space, just below
    > the ROM. (The ROM is mapped virtual=physical for convenience) OFW
    > uses RAM allocated from the top of physical memory, mapped at the
    > aforementioned high virtual addresses. One page directory entry - the
    > next to last one - is used for that RAM mapping and also for mapping
    > additional miscellaneous I/O devices. The 8MB frame buffer requires 2
    > additional PDEs, just below. When Linux takes over the display, OFW no
    > longer needs the frame buffer mapping, but it is convenient to preserve
    > that mapping temporarily while using OFW as a debugger.
    >


    So let me see here... you want the virtual address range [0xffc00000,
    0xfff00000) to be reserved for OFW, and you are prohibiting the kernel
    from using PAE?

    > e) Low memory - everything except the ~1Meg that OFW lives in - is
    > mapped virtual=physical.


    Are you making this assumption when called from the kernel, too?

    > j) Linux must save the following information during early startup:
    > 1) The callback function address - either from the initial value of eax
    > or from the OFW info block.
    > 2) The the next-to-last page directory entry - just the pointer to the
    > page table. The page table itself lives in OFW's reserved memory.
    >
    > k) When calling back into OFW, Linux must:
    > 1) Establish a page directory that contains OFW's PDE (saved in j2
    > above) and that maps the client interface argument array, including any
    > buffer pointers.
    > 2) Call callback_function with the address of the argument array in
    > eax. (Ordinary 32-bit near call).
    >
    > For all of the OLPC kernel's current callbacks into OFW, the
    > requirements (j2) and (k1) are easily satisfied by "priming"
    > swapper_pg_dir with the contents of the current page directory (as
    > pointed to by the CR3 register).


    I do not like it, simply because it amounts to "initialize this
    otherwise zero-initialized piece of data without making any kind of
    reservations and blindly hope nothing else overwrites it."

    I'm also troubled with the assumption that the kernel doesn't use PAE.
    I realize that this is not an issue for OLPC, but it certainly makes
    this a less-than-generic solution.

    Having mapped page table entries which are not under kernel control is a
    very serious problem for PAT - PAT requires, by hardware specification,
    the kernel to eliminate all potential aliases with different mappings.

    One way to deal with this, of course, is to save the firmware-provided
    PGD and only use it for OFW calls. On the other hand, perhaps a better
    questions is to what extent it is needed at all.

    Furthermore, since you're using a nonstandard OFW interface (not
    compliant with the x86 OFW binding document), all of this should be
    called something like OLPC_OFW to make it clear that it's the OLPC variant.

    If I had designed this, I would probably have used an SMI; since you
    have control over the firmware you can do that. SMI saves the entire
    machine state including all the modes, cleans them all up for you, and
    puts it all back together at RSM time. It is slow, of course, but it
    completely decouples the firmware and the OS, which is why it's used.

    -hpa

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware

    Okay, stepping back a few steps, it's pretty clear that most of my
    objections aren't really an issue for Geode/OLPC; however, I *really*
    don't want others to pick it up as being "the" Open Firmware interface.

    Within those constraints it makes sense to set up the PDEs in
    swapper_pg_dir and let them propagate using the normal mechanisms.

    ** This is assuming that your OF interface does not rely on a 1:1
    mapping of low memory being present at the time it makes a call. If it
    *does*, then a separate page directory needs to be maintained for the OF
    class. **


    Thus, I'm willing to accept this with these changes:

    - Please name things specific to the interface (as opposed to Open
    Firmware in general, like the device tree) olpc_ofw or olpcfw, to denote
    that this is an OLPC-specific interface. Thus,
    CONFIG_OLPC_OPEN_FIRMWARE or something along those lines.

    - Make it explicit in Kconfig that OLPC_OPEN_FIRMWARE conflicts with
    X86_PAE, 64BIT, or X86_PAT.

    - Change VMALLOC_END in include/asm-x86/pgtable_32.h so the kernel will
    know to avoid this virtual memory range.

    - Add a memory region to arch/x86/mm/dump_tabletables.c.

    -hpa
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware

    Okay, stepping back a few steps, it's pretty clear that most of my
    objections aren't really an issue for Geode/OLPC; however, I *really*
    don't want others to pick it up as being "the" Open Firmware interface.

    Within those constraints it makes sense to set up the PDEs in
    swapper_pg_dir and let them propagate using the normal mechanisms.

    ** This is assuming that your OF interface does not rely on a 1:1
    mapping of low memory being present at the time it makes a call. If it
    *does*, then a separate page directory needs to be maintained for the OF
    class. **


    Thus, I'm willing to accept this with these changes:

    - Please name things specific to the interface (as opposed to Open
    Firmware in general, like the device tree) olpc_ofw or olpcfw, to denote
    that this is an OLPC-specific interface. Thus,
    CONFIG_OLPC_OPEN_FIRMWARE or something along those lines.

    - Make it explicit in Kconfig that OLPC_OPEN_FIRMWARE conflicts with
    X86_PAE, 64BIT, or X86_PAT.

    - Change VMALLOC_END in include/asm-x86/pgtable_32.h so the kernel will
    know to avoid this virtual memory range.

    - Add a memory region to arch/x86/mm/dump_tabletables.c.

    -hpa
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware

    Okay, stepping back a few steps, it's pretty clear that most of my
    objections aren't really an issue for Geode/OLPC; however, I *really*
    don't want others to pick it up as being "the" Open Firmware interface.

    Within those constraints it makes sense to set up the PDEs in
    swapper_pg_dir and let them propagate using the normal mechanisms.

    ** This is assuming that your OF interface does not rely on a 1:1
    mapping of low memory being present at the time it makes a call. If it
    *does*, then a separate page directory needs to be maintained for the OF
    class. **


    Thus, I'm willing to accept this with these changes:

    - Please name things specific to the interface (as opposed to Open
    Firmware in general, like the device tree) olpc_ofw or olpcfw, to denote
    that this is an OLPC-specific interface. Thus,
    CONFIG_OLPC_OPEN_FIRMWARE or something along those lines.

    - Make it explicit in Kconfig that OLPC_OPEN_FIRMWARE conflicts with
    X86_PAE, 64BIT, or X86_PAT.

    - Change VMALLOC_END in include/asm-x86/pgtable_32.h so the kernel will
    know to avoid this virtual memory range.

    - Add a memory region to arch/x86/mm/dump_tabletables.c.

    -hpa
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: fault in __d_lookup [Was: 2.6.25-mm1]

    On Monday, 21 of April 2008, Jiri Slaby wrote:
    > On 04/21/2008 11:45 AM, Al Viro wrote:
    > > On Mon, Apr 21, 2008 at 11:37:40AM +0200, Jiri Slaby wrote:
    > >> On 04/21/2008 11:06 AM, Al Viro wrote:
    > >>> On Mon, Apr 21, 2008 at 10:31:40AM +0200, Jiri Slaby wrote:
    > >>>
    > >>> hlist_for_each_entry_rcu(dentry, node, head, d_hash) {
    > >>> struct qstr *qstr;
    > >>>
    > >>> if (dentry->d_name.hash != hash)
    > >>> continue;
    > >>>
    > >>> walking into node == (struct hlist_node *)0x00f0000000000000...
    > >> Yup, true, In the last oops I stuck on memcmp few lines below.
    > >>
    > >> BTW. it's 100% reproducible after it happens once, but fixable by reboot.
    > >> Any tests I should run (memtest, some printks sticked anywhere)?

    > >
    > > Well, if list has such turd in it, you'll certainly hit it every time
    > > you walk that list, so 100% reproducible is not surprising.
    > >
    > > How well is it reproducible from fresh boot?

    >
    > Few days with suspend/resume cycles. This one was booted 12 hours ago, one
    > suspend/resume. Will keep an eye on it and keep you informed.


    I think that's exactly the same problem I reported here:
    http://lkml.org/lkml/2008/4/20/182
    for 2.6.25-git2, so it hit the mainline and seems to be related to RCU.

    Thanks,
    Rafael
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: 2.6.25-mm1

    At Fri, 18 Apr 2008 21:29:34 -0700,
    Andrew Morton wrote:
    >
    > >
    > > Cool things there:
    > >
    > > +#ifdef CONFIG_DEBUG_PAGEALLOC
    > > + /* Well, CONFIG_DEBUG_PAGEALLOC makes the sound horrible. Lets
    > > alert */
    > > + printk(KERN_WARNING
    > > + "PCSP: Warning, CONFIG_DEBUG_PAGEALLOC is enabled!\n"
    > > + "You have to disable it if you want to use the PC-Speaker
    > > "
    > > + "driver.\n"
    > > + "Unless it is disabled, enjoy the horrible, distorted "
    > > + "and crackling noise.\n");
    > > +#endif

    >
    > heh.
    >
    > CONFIG_DEBUG_PAGEALLOC is a very heavy consumer of CPU cycles. I'm not
    > surprised that it would whack what I presume to be a very latency-sensitive
    > driver.


    We can add simply a dependncy to Kconfig if this really matters.


    Takashi

    ---

    diff -r e8f61dd0b153 sound/drivers/Kconfig
    --- a/sound/drivers/Kconfig Thu Apr 17 17:58:34 2008 +0200
    +++ b/sound/drivers/Kconfig Mon Apr 21 16:06:09 2008 +0200
    @@ -7,6 +7,7 @@
    config SND_PCSP
    tristate "Internal PC speaker support"
    depends on X86_PC && HIGH_RES_TIMERS
    + depends on !DEBUG_PAGEALLOC
    help
    If you don't have a sound card in your computer, you can include a
    driver for the PC speaker which allows it to act like a primitive
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware

    On Sun, 20 Apr 2008 18:05:26 -1000
    Mitch Bradley wrote:

    >
    >
    > Yinghai Lu wrote:
    > > On Sun, Apr 20, 2008 at 8:09 PM, Mitch Bradley wrote:
    > >
    > >>
    > >> Yinghai Lu wrote:
    > >>
    > >>
    > >>> how about changing to ofw_32.c?
    > >>>
    > >>> YH
    > >>>
    > >>>
    > >>>
    > >> Is your suggestion to change the filename from "ofw.c" to "ofw_32.c"? That
    > >> seems like a good idea to me.
    > >>

    > >
    > > Yes.
    > >
    > > BTW, why olpc need OFW runtime service?
    > > why not just put the info in in ram with some signiture, so
    > > kernel/util just need to loot at the table if needed?
    > >

    >
    > In SPARC land, at least on SunOS and Solaris, it was very convenient for
    > debugging to interrupt the OS with Stop-A and use OFW to inspect the
    > system state. That was especially handy for live crash analysis. Dumps
    > are useful as far as they go, but they often fail to capture detailed
    > I/O device state.
    >
    > I was hoping to do that on x86 too. So far we (OLPC) haven't
    > implemented a sysrq hook to enter OFW, but I haven't given up hope yet.
    > It doesn't cost much to leave OFW around, but once you decide to eject
    > it, you can't easily get it back.
    >


    I'm not actually convinced that we *do* want to keep OFW resident in memory,
    especially given the memory tricks we need to play. I also don't actually
    like the OFW interface that we. The debugging aspect of it was a
    compelling argument up until a week ago (when kernel debuggers started
    finally finding their way into the kernel).

    However, until we clean up the promfs stuff, there's no chance of getting
    an OFW device tree upstream.


    > Apple made the early decision to eject OFW and just keep a device tree
    > table. That decision was probably due to several factors, including the
    > rather lame state of Apple's first OFW implementation and the complexity
    > of their OS startup process at the time (which included "trampolining"
    > to a 68000 emulator to run their legacy code). Once they went down that
    > path, the die was cast, and the PowerPC community got used to the "OFW
    > ends up as just a table" idea.
    >
    > >



    --
    Need a kernel or Debian developer? Contact me, I'm looking for contracts.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: 2.6.25-mm1

    On 19/04/08 13:50 -0400, Andres Salomon wrote:
    > On Sat, 19 Apr 2008 10:38:33 -0700
    > Andrew Morton wrote:
    >
    > > > On Sat, 19 Apr 2008 09:25:44 -0400 Andres Salomon wrote:
    > > > On Fri, 18 Apr 2008 20:29:25 -0700
    > > > Andrew Morton wrote:
    > > >
    > > > > On Fri, 18 Apr 2008 23:10:24 -0400 Joseph Fannin wrote:
    > > > >
    > > > > > On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:

    > [...]
    > > > >
    > > > > which we probably just shouldn't do this at all unless we're running on the
    > > > > OLPC hardware. But we need to do this to find out if we're running on the OLPC
    > > > > hardware! Perhaps the warning should just be removed.
    > > >
    > > > Hm. We could either protect that code with an:
    > > >
    > > > if (!is_geode())
    > > > return;
    > > >
    > > > Or I could add the OpenFirmware patches which would allow us to get
    > > > rid of this code, and instead check for the existence of OFW using
    > > > that.
    > > >
    > > > The former is quick and easy; the latter is (imo) nicer, so long as
    > > > people don't have problems w/ the OFW code.
    > > >

    > >
    > > Do both
    > >
    > > The quick-n-easy version sounds suitable for now.

    >
    > Heh, I already had sent the nicer version. If people have some fundamental
    > problem w/ it, I can send the quick-n-easy version.


    I prefer the nicer version. It is not a good policy IMHO to wrap OLPC
    specfic code with is_geode() and friends. Even by Geode standards, we've
    abused the code greatly for the benefit of the Geode, and few of those
    abuses would translate very well even to the general Geode community. I
    would prefer that we use the is_olpc() and #ifdef wrappers to ensure
    that the code that is exclusively OLPC stays exclusively OLPC.

    Thanks,
    Jordan

    --
    Jordan Crouse
    Systems Software Development Engineer
    Advanced Micro Devices, Inc.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: OLPC: Add support for calling into Open Firmware

    On 20/04/08 17:39 -1000, Mitch Bradley wrote:
    > H. Peter Anvin wrote:
    >> Mitch Bradley wrote:
    >>>
    >>> The x86 architecture doesn't make this problem easy.
    >>>

    >>
    >> [long rant about the x86 architecture]
    >>
    >> It would be more useful if you described the actual defined entry
    >> conditions from OpenFirmware look like, including if they are well-defined
    >> for all OF implementations or only for OLPC.
    >>
    >> -hpa

    >
    > Fair enough...
    >
    > To get the second subquestion out of the way: At the present time, on the
    > x86 architecture, "all OF implementations" and "OLPC" are effectively the
    > same. I am unaware of any other x86 OFW deployments in current use. There
    > have been some in the past, on bespoke systems such as Network Appliance
    > servers and at least one settop box, but those have fallen by the wayside
    > as those companies have shifted over to commodity PC hardware. The current
    > market status quo is that x86 boards are primarily designed for Windows,
    > and thus must run legacy BIOS, with some recent migration to EFI, neither
    > of which are open source in the strong sense. While I would like to see
    > more OFW penetration into the larger x86 market, I don't really expect it.
    > x86 motherboard manufacturing is becoming more and more difficult as signal
    > speeds increase, leading to a decline in the number of manufacturers. The
    > existing manufacturers depend on Windows for sales volume and their
    > internal procedures and working knowledge are based on legacy BIOS.


    /me puts on his coreboot hat

    This is off topic slightly, but let it be known that the coreboot project
    considers OFW a very valid option for x86 platforms. A kernel that
    worked happily with OFW would greatly encourage people to adopt it in
    lieu of other BIOS / firmware solutions.

    I return you to your previously scheduled debate.

    Jordan

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: 2.6.25-mm1

    On 21/04/08 11:05 -0400, Andres Salomon wrote:
    > On Mon, 21 Apr 2008 08:56:19 -0600
    > Jordan Crouse wrote:
    >
    > > On 19/04/08 13:50 -0400, Andres Salomon wrote:
    > > > On Sat, 19 Apr 2008 10:38:33 -0700
    > > > Andrew Morton wrote:
    > > >
    > > > > > On Sat, 19 Apr 2008 09:25:44 -0400 Andres Salomon wrote:
    > > > > > On Fri, 18 Apr 2008 20:29:25 -0700
    > > > > > Andrew Morton wrote:
    > > > > >
    > > > > > > On Fri, 18 Apr 2008 23:10:24 -0400 Joseph Fannin wrote:
    > > > > > >
    > > > > > > > On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
    > > > [...]
    > > > > > >
    > > > > > > which we probably just shouldn't do this at all unless we're running on the
    > > > > > > OLPC hardware. But we need to do this to find out if we're running on the OLPC
    > > > > > > hardware! Perhaps the warning should just be removed.
    > > > > >
    > > > > > Hm. We could either protect that code with an:
    > > > > >
    > > > > > if (!is_geode())
    > > > > > return;
    > > > > >
    > > > > > Or I could add the OpenFirmware patches which would allow us to get
    > > > > > rid of this code, and instead check for the existence of OFW using
    > > > > > that.
    > > > > >
    > > > > > The former is quick and easy; the latter is (imo) nicer, so long as
    > > > > > people don't have problems w/ the OFW code.
    > > > > >
    > > > >
    > > > > Do both
    > > > >
    > > > > The quick-n-easy version sounds suitable for now.
    > > >
    > > > Heh, I already had sent the nicer version. If people have some fundamental
    > > > problem w/ it, I can send the quick-n-easy version.

    > >
    > > I prefer the nicer version. It is not a good policy IMHO to wrap OLPC
    > > specfic code with is_geode() and friends. Even by Geode standards, we've
    > > abused the code greatly for the benefit of the Geode, and few of those
    > > abuses would translate very well even to the general Geode community. I
    > > would prefer that we use the is_olpc() and #ifdef wrappers to ensure
    > > that the code that is exclusively OLPC stays exclusively OLPC.
    > >
    > > Thanks,
    > > Jordan
    > >

    >
    > Yeah, like I said; the nicer version is the _correct_ way to do things. I
    > just fear that the OFW code isn't ready for merging (see hpa's concerns).
    >
    > The code is already #ifdef'd (the original reporter had enabled
    > CONFIG_OLPC), and the code in question is what determines what is_olpc()
    > should return. is_geode() is just to narrow the scope of what hardware
    > the check runs on.


    My bad, I missed the key points. This still is dangerous on a generic
    Geode, but at least if they encounter the problem, we can loudly proclaim
    "Don't do that".

    Jordan

    --
    Jordan Crouse
    Systems Software Development Engineer
    Advanced Micro Devices, Inc.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: OLPC: Add support for calling into Open Firmware

    Jordan Crouse wrote:
    >
    > This is off topic slightly, but let it be known that the coreboot project
    > considers OFW a very valid option for x86 platforms. A kernel that
    > worked happily with OFW would greatly encourage people to adopt it in
    > lieu of other BIOS / firmware solutions.
    >
    > I return you to your previously scheduled debate.
    >


    The interface they are proposing is definitely not suitable for upward
    extension, for the reasons already mentioned. However, they have units
    in the field, and the amount of changes required to support another
    interface should be relatively minor.

    Hence my insistence that we don't promote it as *the* OFW interface, but
    *a* OFW interface.

    -hpa
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: StackProtector Oopses - Re: 2.6.25-mm1


    * Reuben Farrelly wrote:

    >> hm, does it boot up fine with the attached patch and stackprotector
    >> enabled? It appears that your system got to the self-test so
    >> stackprotector is working mostly - it's just that the self-test went
    >> wrong.

    >
    > It boots up fine with that patch below and:
    >
    > tornado boot # grep STACKPROTECT /boot/config-2.6.25-mm1-wip
    > CONFIG_CC_STACKPROTECTOR_ALL=y
    > CONFIG_CC_STACKPROTECTOR=y
    >
    > In fact I'm running with it applied right now and it all seems good so
    > far, so I guess that's confirmation that it is just the test itself
    > which is problematic?


    yeah. Arjan - any new patches to try that might fix the bootup test?

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 3 of 6 FirstFirst 1 2 3 4 5 ... LastLast