by William Lee Irwin III

[permalink] [raw]

Subject: Re: 2.6.10-mm1

On Mon, Jan 03, 2005 at 01:11:13AM -0800, Andrew Morton wrote:
> +m32r-fix-not-to-execute-noexec-pages-0-3.patch

This patch appears to be empty. Also, quilt barfs on such things.
The patch as it appeared in broken-out/ is attached.

-- wli

Attachments:

(No filename) (242.00 B)
m32r-fix-not-to-execute-noexec-pages-0-3.patch (1.11 kB)
m32r-fix-not-to-execute-noexec-pages-0-3.patch Download all attachments

2005-01-03 17:17:50

by Jesse Barnes

[permalink] [raw]

Subject: Re: 2.6.10-mm1

On Monday, January 3, 2005 1:11 am, you wrote:
> +replace-numnodes-with-node_online_map-ia64.patch

Here are some compile fixes for this patch. Looks like simple typos. Note
that the kernel won't boot even with these fixes, I'm debugging that now
(suspect nodemask related stuff is causing the hang too).

Signed-off-by: Jesse Barnes <[email protected]>

Jesse

Attachments:

(No filename) (363.00 B)
for-each-node-ia64-fixes.patch (1.12 kB)
Download all attachments

2005-01-03 17:19:57

On Monday, 3 of January 2005 18:19, Jesse Barnes wrote:
> On Monday, January 3, 2005 2:07 am, Christoph Hellwig wrote:
> > > add-page-becoming-writable-notification.patch
> > > Add page becoming writable notification
> >
> > David, this still has the bogus address_space operation in addition to
> > the vm_operation. page_mkwrite only fits into the vm_operations scheme,
> > so please remove the address_space op. Also the code will be smaller
> > and faster witout that indirection..
>
> And apparently it's broken on NUMA. I couldn't find
> generic_file_get/set_policy in my tree, which builds with CONFIG_NUMA
> enabled.

On a dual-Opteron w/ NUMA I had to apply the Jesse's patch to compile the
kernel, but it does not boot. It only prints this to the serial console:

Bootdata ok (command line is root=/dev/sdb3 vga=792 earlyprintk=ttyS0,57600
console=ttyS0,57600 console=tty0)
Linux version 2.6.10-mm1 (rafael@chimera) (gcc version 3.3.4 (pre 3.3.5
20040809)) #1 SMP Mon Jan 3 23:09:30 CET 2005
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
BIOS-e820: 000000003fff0000 - 000000003ffff000 (ACPI data)
BIOS-e820: 000000003ffff000 - 0000000040000000 (ACPI NVS)
BIOS-e820: 00000000ff7c0000 - 0000000100000000 (reserved)
kernel direct mapping tables upto ffff810100000000 @ 8000-c000
Scanning NUMA topology in Northbridge 24
Number of nodes 2 (10010)
Node 0 already present. Skipping
Node 1 already present. Skipping
No NUMA configuration found
Faking a node at 0000000000000000-000000003fff0000
Bootmem setup node 0 0000000000000000-000000003fff0000
No mptable found.
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:5 APIC version 16
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:5 APIC version 16
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x03] address[0xfc9fe000] gsi_base[24])
IOAPIC[1]: apic_id 3, version 17, address 0xfc9fe000, GSI 24-27
ACPI: IOAPIC (id[0x04] address[0xfc9ff000] gsi_base[28])
IOAPIC[2]: apic_id 4, version 17, address 0xfc9ff000, GSI 28-31
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Checking aperture...
CPU 0: aperture @ f0000000 size 128 MB
CPU 1: aperture @ f0000000 size 128 MB

and then it goes into an infinite loop that writes some garbage to the
framebuffer (yellow lines on top of the screen).

On a UP AMD64 it boots, but then it does not work appropriately (eg. at KDE
startup the box hangs for a while and I get the message like "The process for
the file protocol has terminated unexpectedly" and desktop icons are not
displayed, and I get a "cpu overload" message from arts etc.).

Please let me know if you need more information.

Greets,
RJW

--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"

2005-01-04 00:24:47

by Adrian Bunk

[permalink] [raw]

Some ACPI error msgs show on dmesg:

DMI 2.3 present.
__iounmap: bad address c00f0000

ACPI: Subsystem revision 20041210
ACPI-1138: *** Error: Method execution failed [\STRC] (Node
c18eb1c0), AE_AML_BUFFER_LIMIT
ACPI-1138: *** Error: Method execution failed [\_SB_.PCI0._INI]
(Node c18f4f60), AE_AML_BUFFER_LIMIT

dmesg & .config attached

Thanks,

Paul
--
FreeBSD the Power to Serve!

Attachments:

(No filename) (394.00 B)
dmsg_2.6.10-mm1 (16.63 kB)
.config (31.19 kB)
Download all attachments

2005-01-04 20:31:11

[permalink] [raw]

On Thu, Jan 06, 2005 at 10:22:21AM -0500, Lee Revell wrote:
> > p.s. droppe alsa-devel from Cc because of the braindead moderation policy.
> >
>
> Um, alsa-devel is not moderated, we accept posts from non subscribers.
> Where do you think all the spam in our archive comes from?

See the attached mail I got. Btw, where are the current alsa-devel
archives? I tried to look things up a few times lately, but all archives
linked off the websiste are either dead or totally outdated.

Attachments:

(No filename) (486.00 B)
alsa-mod (2.33 kB)
Download all attachments

2005-01-06 15:38:14

by Andi Kleen

[permalink] [raw]

On Dunnersdag 06 Januar 2005 18:53, Andi Kleen wrote:

> > * USB. usbfs API is written in a way which does not allow you to safely wrap
> > it in "generic" 32->64 layer, and attempts to do it in non-generic way in usbfs
> > code itself did not look feasible year ago. Even on current 64bit kernels it is not
> > possible to issue raw USB operations from 32bit apps, and I do not believe that
> > it is going to change - after all, just issuing ioctl through 64bit path from application
> > which is aware of 64bit kernel is quite simple, much simpler than any attempt to
> > make kernel dual-interface.
>
> Agree that's a problem. We just need an alternative interface here
> or I try to come up with an x86-64 specific hack (I think it's possible
> to do the compatibility x86-64 specific, just not in compat code for
> all architectures who have truly separated user/kernel address spaces)
>
> I hope the USB people will eventually add a better interface here.
> Greg?

As a quick fix, wouldn't it be easy enough to just mark USBDEVFS_IOCTL as
COMPATIBLE_IOCTL()? The number is actually different for 32 and 64 bit kernels,
so a 32 bit application that knows about this could use 64 bit data structures
and then just call ioctl(fd, USBDEVFS_IOCTL64, data) instead of using a weird
hack to achieve exactly the same.
Applications trying to call the 32 bit USBDEVFS_IOCTL would still see -EINVAL
because there is no wrapper for this.
Maybe the same can be done for some of the other ioctl calls. It effectively
means moving part of the compat layer to user space from fs/compat_ioctl.c,
but it appears that applications are already doing this.

Arnd <><

Attachments:

(No filename) (1.62 kB)
(No filename) (189.00 B)
signature Download all attachments

2005-01-07 12:31:46

by Andi Kleen

[permalink] [raw]

Subject: Re: [discuss] Re: [PATCH] macros to detect existance of unlocked_ioctl and ioctl_compat

> As a quick fix, wouldn't it be easy enough to just mark USBDEVFS_IOCTL as
> COMPATIBLE_IOCTL()? The number is actually different for 32 and 64 bit kernels,
> so a 32 bit application that knows about this could use 64 bit data structures
> and then just call ioctl(fd, USBDEVFS_IOCTL64, data) instead of using a weird
> hack to achieve exactly the same.
> Applications trying to call the 32 bit USBDEVFS_IOCTL would still see -EINVAL
> because there is no wrapper for this.
> Maybe the same can be done for some of the other ioctl calls. It effectively
> means moving part of the compat layer to user space from fs/compat_ioctl.c,
> but it appears that applications are already doing this.

That's too ugly. We would end up with different ABIs.
I don't really want to do that, no.

-Andi

2005-01-07 14:46:48

by Christoph Hellwig

[permalink] [raw]

Subject: Re: 2.6.10-mm1

On Thu, Jan 06, 2005 at 04:52:01PM +0300, Vladimir Saveliev wrote:
> The work is in progress. Here is list of patches.

> reiser4-perthread-pages.patch

this one I don't particularly object, but I'm not sure it's really
the right thing to do. Can you post it with a detailed description
to linux-mm so we can kick off discussion?

The other thing I'm totally oposed to was the per-sb kobject patch,
but I can't find that in current -mm anymore.

2005-01-07 17:17:52

[permalink] [raw]

Subject: Re: reiser4 core patches: [Was: [RFC] per thread page reservation patch]

> So, currently, reiser4 depends on the core patches listed below. Would
> you please look over them and let us know which look reasonable and
> which are to be eliminated.

> reiser4-sb_sync_inodes.patch
> This patch adds new operation (sync_inodes) to struct super_operations.
> This operation allows a filesystem to writeout dirty pages not
> necessarily on per-inode basis. Default implementation of this operation
> is sync_sb_inodes.

ok.

> reiser4-allow-drop_inode-implementation.patch
> This EXPORT_SYMBOL-s inodes_stat, generic_forget_inode, destroy_inode
> and wake_up_inode which are needed to implement drop_inode.
> reiser4 implements function similar to generic_delete_inode to be able
> to truncate inode pages together with metadata destroying in
> reiser4_delete_inode whereas generic_delete_inode first truncates pages
> and then calls foofs_delete_inode.

Not okay. I though I explained you how to do it instead already?

> reiser4-truncate_inode_pages_range.patch
> This patch makes truncate_inode_pages_range from truncate_inode_pages.
> truncate_inode_pages_range can truncate only pages which fall into
> specified range. truncate_inode_pages which trucates all pages starting
> from specified offset is made a one liner which calls
> truncate_inode_pages_range.

Ok.

> reiser4-rcu-barrier.patch
> This patch introduces a new interface - rcu_barrier() which waits until
> all the RCUs queued until this call have been completed.
> This patch is by Dipankar Sarma <[email protected]>

No idea, but if Dipankar things it's okay it probably is.

> reiser4-reget-page-mapping.patch
> This patch allows to remove page from page cache in foofs_releasepage.

probably ok, Andrew?

> reiser4-radix_tree_lookup_slot.patch
> This patch extents radxi tree API with a function which returns pointer
> to found item within the tree.

Idea is okay, implementation needs work:

__lookup_slot should be called radix_tree_lookup_slot and exported direcly.

radix_tree_lookup should be an inlined wrapper in the header, and kill
the != NULL comparims, it's superflous:

static inline void *radix_tree_lookup(struct radix_tree_root *root,
unsigned long index)
{
void **slot = radix_tree_lookup_slot(root, index);
return slot ? *slot : NULL;
}

> reiser4-export-remove_from_page_cache.patch

Probably okay, but why do you need both remove_from_page_cache
and __remove_from_page_cache?

> reiser4-export-page_cache_readahead.patch

ok

> reiser4-export-pagevec-funcs.patch

ok

> reiser4-export-radix_tree_preload.patch

this one is nasty. not your fault though, but why do we even
have global radix-tree preloads instead of pools. What do you
need it for?

> reiser4-export-find_get_pages.patch

Why don't you use pagevecs instead?

> reiser4-export-generic_sync_sb_inodes.patch

Can't find this one in current -mm

> reiser4-export-inode_lock.patch
> Reiser4 used to manipulate with super block inode lists so it needs
> inode_lock exported.
> We are working now to not need this. But quite many things are based on
> it. Is there any chance to have it included?

No. Modules must not look at inode_lock, it's far too much of an
implementation detail.