Re: trouble loading self compiled vanilla kernel
On 8 Jan 2007 at 9:40, Vadim Lobanov wrote: > In my experience on openSUSE, the following sequence of commands > installs both the kernel and the initrd: > make *config* > make > make modules_install > make install > However, if the order of the last two make invocations is switched, then > the initrd does not get generated (correctly or at all). Although > unlikely to be the problem, it's a simple thing to eliminate from the > list of possible borkages. > > -- Vadim Lobanov Thank you for your advice. It's been a while and I have been some testing. I can compile and boot these kernels: 2.6.10, 2.6.16.37 and 2.6.17.14. But I have not been able to boot any of these: 2.6.18, 2.6.18.6 nor 2.6.19.1. Guess I will have to read the changelog for 2.6.18 really careful. /Jonas - 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: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
Tomasz Chmielewski wrote: Al Borchers wrote: Thomas Chmielewski wrote: These all unpleasant tasks could be avoided if it was possible to have a "fallback" device. For example, consider this hypothetical command line: root=/dev/sdb1,/dev/sda1 Here is a patch to do this, though it sounds like you might have other solutions. This patch is for 2.6.18.1--thanks to Ed Falk for updating my original 2.6.11 patch. If people are interested I can update and test this on the current kernel. It was tested on 2.6.11. Yes, I'd be interested in a patch against a 2.6.19. It is way simpler to do it this way than to do it with initramfs (although not as flexible). I tried your patch against 2.6.19, with some minor changes (as it wouldn't apply), but it didn't work for me (perhaps I just screwed something). I just might want to point this as an example on the fact that as long as the in-kernel mounting code (as opposed to integrated klibc) exists, it will want to grow features... -hpa - 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/
REQ: advice on tuning via-velocity parameters
I have a GBe Via Velocity NIC on an Abit AV8 motherboard, with 1GB DDR and a 3700+ CPU, running kernel 2.6.19. When I push a lot of data via TCP-mounted NFS, I get a lot of these messages in the system log and the machine is briefly slow to respond: eth0: excessive work at interrupt. I am guessing the system becomes slow when it is 'catching up' with all the interrupts. There are a lot of parameters associated with the via-velocity driver. Is there a reference online detailing how to adjust them, or a more general network-card kernel parameter tuning FAQ? I have txcsum_offload enabled. rx_copybreak Copy breakpoint for copy-only-tiny-frames (int) int_works Number of packets per interrupt services (array of int) txcsum_offload Enable transmit packet checksum offload (array of int) IP_byte_align Enable IP header dword aligned (array of int) DMA_length DMA length (array of int) rx_thresh Receive fifo threshold (array of int) TxDescriptors Number of transmit descriptors (array of int) parm RxDescriptors Number of receive descriptors (array of int) -- Brian Hall http://pcisys.net/~brihall - 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/
[PATCH] Documentation/rbtree.txt
Signed-off-by: Rob Landley <[EMAIL PROTECTED]>
Documentation for lib/rbtree.c.
--
I'm not an expert on this but I was asked to write up some documentation
for rbtree in the Linux kernel, and as long as it's there...
I'm sure if I screwed something up somebody will point it out to me, loudly.
:)
--- /dev/null 2006-05-30 21:33:22.0 -0400
+++ linux-2.6.19.2/Documentation/rbtree.txt 2007-01-18 11:57:50.0
-0500
@@ -0,0 +1,186 @@
+Red-black Trees (rbtree) in Linux
+January 18, 2007
+Rob Landley <[EMAIL PROTECTED]>
+=
+
+What are red-black trees, and what are they for?
+
+
+Red-black trees are a type of self-balancing binary search tree, used for
+storing sortable key/value data pairs. This differs from radix trees (which
+are used to efficiently store sparse arrays and thus use long integer indexes
+to insert/access/delete nodes) and hash tables (which are not kept sorted to
+be easily traversed in order, and must be tuned for a specific size and
+hash function where rbtrees scale gracefully storing arbitrary keys).
+
+Red-black trees are similar to AVL trees, but provide faster realtime bounded
+worst case performance for insertion and deletion (at most two rotations and
+three rotations, respectively, to balance the tree), with slightly slower
+(but still O(log n)) lookup time.
+
+To quote Linux Weekly News:
+
+There are a number of red-black trees in use in the kernel.
+The anticipatory, deadline, and CFQ I/O schedulers all employ
+rbtrees to track requests; the packet CD/DVD driver does the same.
+The high-resolution timer code uses an rbtree to organize outstanding
+timer requests. The ext3 filesystem tracks directory entries in a
+red-black tree. Virtual memory areas (VMAs) are tracked with red-black
+trees, as are epoll file descriptors, cryptographic keys, and network
+packets in the "hierarchical token bucket" scheduler.
+
+This document covers use of the Linux rbtree implementation. For more
+information on the nature and implementation of Red Black Trees, see:
+
+ Linux Weekly News article on red-black trees
+http://lwn.net/Articles/184495/
+
+ Wikipedia entry on red-black trees
+http://en.wikipedia.org/wiki/Red-black_tree
+
+Linux implementation of red-black trees
+---
+
+Linux's rbtree implementation lives in the file "lib/rbtree.c". To use it,
+"#include ".
+
+The Linux rbtree implementation is optimized for speed, and thus has one
+less layer of indirection (and better cache locality) than more traditional
+tree implementations. Instead of using pointers to separate rb_node and data
+structures, each instance of struct rb_node is embedded in the data structure
+it organizes. And instead of using a comparison callback function pointer,
+users are expected to write their own tree search and insert functions
+which call the provided rbtree functions. Locking is also left up to the
+user of the rbtree code.
+
+Creating a new rbtree
+-
+
+Data nodes in an rbtree tree are structures containing a struct rb_node member:
+
+ struct mytype {
+ struct rb_node node;
+ char *keystring;
+ };
+
+When dealing with a pointer to the embedded struct rb_node, the containing data
+structure may be accessed with the standard container_of() macro. In addition,
+individual members may be accessed directly via rb_entry(node, type, member).
+
+At the root of each rbtree is a rb_root structure, which is initialized to be
+empty via:
+
+ struct rb_root mytree = RB_ROOT;
+
+Searching for a value in an rbtree
+--
+
+Writing a search function for your tree is fairly straightforward: start at the
+root, compare each value, and follow the left or right branch as necessary.
+
+Example:
+
+ struct mytype *my_search(struct rb_root *root, char *string)
+ {
+ struct rb_node *node = root->rb_node;
+
+ while (node) {
+ struct mytype *data = container_of(node, struct mytype, node);
+ int result;
+
+ result = strcmp(string, data->keystring);
+
+ if (result < 0) node = node->rb_left;
+ else if (result > 0) node = node->rb_right;
+ else return data;
+ }
+ return NULL;
+ }
+
+Inserting data into an rbtree
+-
+
+Inserting data in the tree involves first searching for the place to insert the
+new node, then inserting the node and rebalancing ("recoloring") the tree.
+
+The search for insertion differs from the previous search by finding the
+location of the pointer on which to graft the new node. The new node also
+needs a link to its' parent node for rebalancing purposes.
+
+Example:
+
+ int my_insert(struct rb_root *root, struct mytype *data)
+ {
+ struct rb_node **new = &(root->rb_node), *parent = NULL;
+
+ // Figure out where to put
Re: 2.6.20-rc2: kernel BUG at include/asm/dma-mapping.h:110!
I wrote on 2007-01-02: > Kyuma Ohta wrote: > ... >> Now,I'm testing 2.6.20-rc3 for x86_64, submitted patch for this issue; >> "Fault has happened in 'cleanuped' sbp2/1394 module in *not 32bit* >> architecture hardwares ." >> >> As result of, sbp2 driver in 2.6.20-rc3 is seems to running >> w/o any faults,but communication both host and harddrive(s) >> was seems to be unstable yet :-( >> Sometimes confuse packets,such as *very* older 1394 driver :-( > > That is, sbp2 on 2.6.20-rc3 works less stable for you than on 2.6.19? Or > which previous kernel is the basis of your comparison? Are there any log > messages or other diagnostics? And what hardware do you have? > > If you can tell which kernel was good for you, I could create a set of > patches for you which allows to revert sbp2 while keeping the rest of > the kernel at the level of 2.6.20-rc3, so that you could find the > destabilizing change (if it happened in sbp2, not somewhere else). [...] So, how about it? Is there an actual regression? If so, we should find the cause and fix before 2.6.20 is released. Note, sbp2's optional parameter serialize_io=0 does not work correctly yet with some devices (it never did), therefore use sbp2 with anything than default parameters if there are problems. -- Stefan Richter -=-=-=== ---= =--=- http://arcgraph.de/sr/ - 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/
[RESEND][PATCH] 9p: fix bogus return code checks during initialization
There is a simple logic error in init_v9fs - the return code checks are
reversed. This patch fixes the return code and adds some messages to
prevent module initialization from failing silently.
Signed-off-by: Eric Van Hensbergen <[EMAIL PROTECTED]>
---
fs/9p/mux.c |4 +++-
fs/9p/v9fs.c | 11 ---
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/fs/9p/mux.c b/fs/9p/mux.c
index 944273c..147ceef 100644
--- a/fs/9p/mux.c
+++ b/fs/9p/mux.c
@@ -132,8 +132,10 @@ int v9fs_mux_global_init(void)
v9fs_mux_poll_tasks[i].task = NULL;
v9fs_mux_wq = create_workqueue("v9fs");
- if (!v9fs_mux_wq)
+ if (!v9fs_mux_wq) {
+ printk(KERN_WARNING "v9fs: mux: creating workqueue failed\n");
return -ENOMEM;
+ }
return 0;
}
diff --git a/fs/9p/v9fs.c b/fs/9p/v9fs.c
index 0b96fae..d9b561b 100644
--- a/fs/9p/v9fs.c
+++ b/fs/9p/v9fs.c
@@ -457,14 +457,19 @@ static int __init init_v9fs(void)
v9fs_error_init();
- printk(KERN_INFO "Installing v9fs 9P2000 file system support\n");
+ printk(KERN_INFO "Installing v9fs 9p2000 file system support\n");
ret = v9fs_mux_global_init();
- if (!ret)
+ if (ret) {
+ printk(KERN_WARNING "v9fs: starting mux failed\n");
return ret;
+ }
ret = register_filesystem(&v9fs_fs_type);
- if (!ret)
+ if (ret) {
+ printk(KERN_WARNING "v9fs: registering file system failed\n");
v9fs_mux_global_exit();
+ }
+
return ret;
}
--
1.5.0.rc1.gdf1b-dirty
-
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/
Data corruption with raid5/dm-crypt/lvm/reiserfs on 2.6.19.2
Hi! I'm experiencing data corruption in the following setup: 1. mdadm --create /dev/md0 -n3 -lraid5 /dev/hda1 /dev/hdc1 /dev/hde1 2. cryptsetup -c aes-cbc-essiva:sha256 luksFormat /dev/md0 mykey 3. cryptsetup -d mykey luksOpen /dev/md0 cryptvol 4. pvcreate /dev/mapper/cryptvol 5. vgcreate vg0 /dev/cryptvol 6. lvcreate -n root -L10G vg0 7. mkreiserfs -q /dev/vg0/root 8. mkdir /.newroot; mount /dev/vg0/root /.newroot 9. mkdir /.realroot; mount -o bind / /.realroot 10. tar cf - -C /.realroot|tar xvpf - -C /.newroot With Linux 2.6.18 (it's broken, OK, but there's still something wrong even in 2.6.19.2 so keep on reading) I started getting warnings from ReiserFS indicating severe data corruptions. Reiserfsck confirms this. It usually happened while extracting the Linux source tree. So after asking around I found out dm-crypt had a bug[1] fixed in early December. It got fixed in 2.6.19 and the fix was backported and included in 2.6.18.6[2]. Fine, so I upgraded to 2.6.18.6, rebuilt the array from scratch and did the whole procedure again. No messages from reiserfs in dmesg this time, but reiserfsck still revealed severe data corruption. I also found compressed archives and ISO-images for which I had md5sums to be corrupt. I then upgraded to 2.6.19.2 with the exact same result as with 2.6.18.6. I even verified this on a fairly new computer with different hardware (Intel CPU and chipset). Figured it maybe was some kind of race condition so on my second try on 2.6.19.2, when recreating the array, I let md finish resyncing it before copying over the files. This time, reiserfsck didn't complain. Just for the sake of fun, I did the whole thing again, rebuilding the array from scratch, let md resync the third drive and then I started to copy over all files again. Thinking the cause of the problem was heavy disk I/O I tried to stress the other LVM volumes residing on md0 using tar during the copy. Everything seemed fine; no problems arose. Did a few reboots and confirmed that reiserfsck didn't have any complaints on any of the filesystems residing on the LVM volumes on md0. Started using the machine as normal, and half a day later I unmounted the filesystems and ran reiserfsck just to make sure everything still was OK. Unfortunately, it wasn't. The drives in the array are three brand new drives, 2x250GB and one 200GB, all three IDE drives. According to SMART there's no problems with them. And they worked fine in my previous RAID1 setup with dm-crypt and LVM, by the way. The computer itself is an Athlon XP with less than 1GB of RAM on a M/B with nForce2 chipset FWIW. No memory errors were detected with memtest86+ (I completed the full test). I haven't tried using another filesystem as I've got quite a lot of faith in reiserfs's stability. Is anybody else experiencing these problems? Unfortunately I'm only able to do limited testing due to busy days, but I'd love to help if I can. [1] Here's a thread on the recently fixed data corruption bug in dm-crypt http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/1974 [2] The backport of the dm-crypt fix for 2.6.18.6 is here http://uwsg.iu.edu/hypermail/linux/kernel/0612.1/2299.html - 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 03/26] Dynamic kernel command-line - arm
Alon Bar-Lev <[EMAIL PROTECTED]> wrote: > On 1/18/07, Russell King <[EMAIL PROTECTED]> wrote: >> On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote: >> > 2. Set command_line as __initdata. >> You can't. >> >> > -static char command_line[COMMAND_LINE_SIZE]; >> > +static char __initdata command_line[COMMAND_LINE_SIZE]; >> >> Uninitialised data is placed in the BSS. Adding __initdata to BSS >> data causes grief. > There are many places in kernel that uses __initdata for uninitialized > variables. > > For example: > static int __initdata is_chipset_set[MAX_HWIFS]; > > So all these current places are wrong? > If I initialize the data will it be OK. objdump -t vmlinux |grep -3 is_chipset_set suggests that it's placed into .init.data here, not into .bss. -- Top 100 things you don't want the sysadmin to say: 92. What software license? Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] - 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.20-rc5: known regressions with patches (v2)
This email lists some known regressions in 2.6.20-rc5 compared to 2.6.19 with patches available If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: does not pickup ipv6 addresses References : http://bugzilla.kernel.org/show_bug.cgi?id=7817 http://lkml.org/lkml/2007/1/14/146 Submitter : Michael Gernoth <[EMAIL PROTECTED]> Daniel Drake <[EMAIL PROTECTED]> Caused-By : David L Stevens <[EMAIL PROTECTED]> commit 30c4cf577fb5b68c16e5750d6bdbd7072e42b279 Handled-By : YOSHIFUJI Hideaki <[EMAIL PROTECTED]> Patch : http://bugzilla.kernel.org/show_bug.cgi?id=7817 Status : patch available Subject: ACPI: fix cpufreq regression References : http://lkml.org/lkml/2007/1/16/120 Submitter : Ingo Molnar <[EMAIL PROTECTED]> Caused-By : Dave Jones <[EMAIL PROTECTED]> commit 0916bd3ebb7cefdd0f432e8491abe24f4b5a101e Handled-By : Ingo Molnar <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/1/16/120 Status : patch available Subject: CONFIG_JFFS2_FS_DEBUG=2 compile error References : http://lkml.org/lkml/2007/1/12/161 Submitter : Russell King <[EMAIL PROTECTED]> Caused-By : Al Viro <[EMAIL PROTECTED]> commit 914e26379decf1fd984b22e51fd2e4209b7a7f1b Handled-By : David Woodhouse <[EMAIL PROTECTED]> Status : patch available Subject: WARNING: "profile_hits" [drivers/kvm/kvm-intel.ko] undefined! References : http://lkml.org/lkml/2007/1/12/16 Submitter : Miles Lane <[EMAIL PROTECTED]> Caused-By : Ingo Molnar <[EMAIL PROTECTED]> commit 07031e14c1127fc7e1a5b98dfcc59f434e025104 Handled-By : Andrew Morton <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/1/12/18 Status : patch available Subject: KVM: guest crash References : http://lkml.org/lkml/2007/1/8/163 Submitter : Roland Dreier <[EMAIL PROTECTED]> Handled-By : Avi Kivity <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/1/9/280 Status : patch available Subject: compile error: USB_HID must depend on INPUT References : http://lkml.org/lkml/2007/1/12/157 Submitter : Russell King <[EMAIL PROTECTED]> Handled-By : Russell King <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/1/12/177 Status : patch available - 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/RFC 2.6.21] ehca: ehca_uverbs.c: refactor ehca_mmap() for better readability
No problem. Will resend the full patch set for 2.6.21. Thanks Nam [EMAIL PROTECTED] wrote on 18.01.2007 13:56:01: > I've kind of lost the plot here. How does this patch fit in with the > previous series of patches you posted? Does it replace them or go on > top of them? > > Can please you resend me the full series of patch that remove the use > of do_mmap(), with all cleanups and bug fixes included? And please > roll up the fixes, I don't want one patch that adds a yield() inside a > spinlock and then a later patch to fix it -- there's no sense in > adding landmines for people potentially doing git bisect in the > future. > > And also please try to split the patches so that they don't mix > together two things -- please try to make the "remove obsolete > prototypes" patch separate from the mmap fixes. > > Thanks... > ___ > Linuxppc-dev mailing list > [EMAIL PROTECTED] > https://ozlabs.org/mailman/listinfo/linuxppc-dev - 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: [RFC 7/8] Exclude unreclaimable pages from dirty ration calculation
On Thu, 18 Jan 2007, Nikita Danilov wrote:
> I think that simpler solution of this problem is to use only potentially
> reclaimable pages (that is, active, inactive, and free pages) to
> calculate writeout threshold. This way there is no need to maintain
> counters for unreclaimable pages. Below is a patch implementing this
> idea, it got some testing.
Hmmm... the problem is that it is expensive to calculate these numbers on
larger systems. In order to calculate active and inactive pages we
have to first go through all the zones of the system. In a NUMA system
there could be many zones.
> +/* Maximal number of pages that can be consumed by pageable caches. */
> +static unsigned long total_pageable_pages(void)
> +{
> + unsigned long active;
> + unsigned long inactive;
> + unsigned long free;
> +
> + get_zone_counts(&active, &inactive, &free);
> + /* +1 to never return 0. */
> + return active + inactive + free + 1;
> +}
An expensive function. And we need to call it whenever we calculate dirty
limits.
Maybe could create ZVC counters that allow an inexpensive determination of
these numbers? Then we first need to make sure that the counters are not
assumed to be accurate at all times.
-
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.20-rc5: knwon unfixed regressions (v2) (part2)
This email lists some known regressions in 2.6.20-rc5 compared to 2.6.19. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: BUG: at fs/inotify.c:172 set_dentry_child_flags() References : http://bugzilla.kernel.org/show_bug.cgi?id=7785 Submitter : Cijoml Cijomlovic Cijomlov <[EMAIL PROTECTED]> Handled-By : Nick Piggin <[EMAIL PROTECTED]> Status : problem is being debugged Subject: BUG: at mm/truncate.c:60 cancel_dirty_page() (reiserfs) References : http://lkml.org/lkml/2007/1/7/117 http://lkml.org/lkml/2007/1/10/202 Submitter : Malte Schröder <[EMAIL PROTECTED]> Handled-By : Vladimir V. Saveliev <[EMAIL PROTECTED]> Nick Piggin <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/1/10/202 Status : problem is being discussed Subject: BUG: at mm/truncate.c:60 cancel_dirty_page() (XFS) References : http://lkml.org/lkml/2007/1/5/308 http://lkml.org/lkml/2007/1/16/15 Submitter : Sami Farin <[EMAIL PROTECTED]> Handled-By : David Chinner <[EMAIL PROTECTED]> Status : problem is being discussed Subject: NFS triggers WARN_ON() in invalidate_inode_pages2_range() References : http://bugzilla.kernel.org/show_bug.cgi?id=7826 Submitter : Andrew Clayton <[EMAIL PROTECTED]> Caused-By : Andrew Morton <[EMAIL PROTECTED]> commit 8258d4a574d3a8c01f0ef68aa26b969398a0e140 Handled-By : Trond Myklebust <[EMAIL PROTECTED]> Status : Trond: the WARN_ON() needs to be thrown out - 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.20-rc5: knwon unfixed regressions (v2) (part1)
This email lists some known regressions in 2.6.20-rc5 compared to 2.6.19. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: ext3 with data=journal hangs when running fsx-linux since -rc2 References : http://bugzilla.kernel.org/show_bug.cgi?id=7844 Submitter : Randy Dunlap <[EMAIL PROTECTED]> Status : unknown Subject: reboot instead of powerdown (CONFIG_USB_SUSPEND) References : http://lkml.org/lkml/2006/12/25/40 http://bugzilla.kernel.org/show_bug.cgi?id=7828 Submitter : Berthold Cogel <[EMAIL PROTECTED]> François Valenduc <[EMAIL PROTECTED]> Handled-By : Alexey Starikovskiy <[EMAIL PROTECTED]> Status : problem is being debugged Subject: usb somehow broken (CONFIG_USB_SUSPEND) References : http://lkml.org/lkml/2007/1/11/146 Submitter : Prakash Punnoor <[EMAIL PROTECTED]> Handled-By : Oliver Neukum <[EMAIL PROTECTED]> Status : problem is being debugged Subject: RAID-6 chunk_aligned_read problem References : http://bugzilla.kernel.org/show_bug.cgi?id=7835 Submitter : Duncan <[EMAIL PROTECTED]> Status : unknown Subject: pktcdvd fails with pata_amd References : http://bugzilla.kernel.org/show_bug.cgi?id=7810 Submitter : [EMAIL PROTECTED] Status : unknown Subject: problems with CD burning References : http://www.spinics.net/lists/linux-ide/msg06545.html Submitter : Uwe Bugla <[EMAIL PROTECTED]> Status : unknown Subject: sata_nv: SATA exceptions References : http://lkml.org/lkml/2007/1/14/108 Submitter : Björn Steinbrink <[EMAIL PROTECTED]> Caused-By : Robert Hancock <[EMAIL PROTECTED]> commit 2dec7555e6bf2772749113ea0ad454fcdb8cf861 Handled-By : Robert Hancock <[EMAIL PROTECTED]> Status : problem is being debugged - 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/
Questions on PCI express AER support in HBA driver
Hi,
I've got some questions on supporting PCI Express AER in Linux HBA drivers.
BTW, I'm developing SCSI HBA driver.
What are the expected changes on SCSI LLD driver in regards to PCIE
AER supporting? I understood that the driver need to call following
API during probing,
---
if (pci_find_aer_capability(dev)) {
pci_enable_pcie_error_reporting(dev);
}
---
What else does SCSI LLD driver need to changed?
Thanks in advance.
Allexio
-
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/
[ANNOUNCE] System Inactivity Monitor v1.0
Hi all,
this is a new 2.6.20 module implementing a user inactivity trigger. Basically
it acts as an event sniffer, issuing an ACPI event when no user activity is
detected for more than a certain amount of time. This event can be successively
grabbed and managed by an user-level daemon such as acpid, blanking the screen,
dimming the lcd-panel light à la mac, etc...
For the interested guys I have included a bash configuration helper (called
gentable) that covers the details.
Best,
diff -uN SIN/Makefile SIN.new/Makefile
--- SIN/Makefile 1970-01-01 01:00:00.0 +0100
+++ SIN.new/Makefile 2007-01-18 19:20:59.0 +0100
@@ -0,0 +1,41 @@
+MODLPATH = kernel/drivers/char
+
+MODL = sinmod
+OBJS = sin.o procfs.o table.o input_enumerator.o acpi_enumerator.o
+
+SRCS := $(patsubst %.o,%.c,$(OBJS))
+HDRS := $(patsubst %.o,%.h,$(OBJS))
+CMDS := $(patsubst %.o,.%.o.cmd,$(OBJS))
+
+ifneq ($(KERNELRELEASE),)
+ EXTRA_CFLAGS := $(DEBUG)
+ obj-m := $(MODL).o
+ $(MODL)-objs := $(OBJS)
+else
+ KDIR := /lib/modules/$(shell uname -r)/build
+ PWD := $(shell pwd)
+
+all: $(MODL).ko
+
+$(MODL).ko: $(SRCS) $(HDRS)
+ @$(MAKE) -C $(KDIR) M=$(PWD) modules
+
+im: $(MODL).ko
+ @sudo insmod $(MODL).ko
+
+rm:
+ @sudo rmmod $(MODL)
+
+rmf:
+ @sudo rmmod -f $(MODL)
+
+install:
+ @sudo $(MAKE) INSTALL_MOD_DIR=$(MODLPATH) -C $(KDIR) M=$(PWD) modules_install
+
+modules_install:
+ @$(MAKE) INSTALL_MOD_DIR=$(MODLPATH) -C $(KDIR) M=$(PWD) modules_install
+
+clean:
+ @$(MAKE) -C $(KDIR) M=$(PWD) clean
+ @rm -f Module.symvers
+endif
diff -uN SIN/acpi_enumerator.c SIN.new/acpi_enumerator.c
--- SIN/acpi_enumerator.c 1970-01-01 01:00:00.0 +0100
+++ SIN.new/acpi_enumerator.c 2007-01-18 19:20:53.0 +0100
@@ -0,0 +1,114 @@
+/*
+ * Copyright (C) 2007 Alessandro Di Marco
+ */
+
+/*
+ * This file is part of SIN.
+ *
+ * SIN is free software; you can redistribute it and/or modify it under the
+ * terms of the GNU General Public License as published by the Free Software
+ * Foundation; version 2 of the License.
+ *
+ * SIN is distributed in the hope that it will be useful, but WITHOUT ANY
+ * WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
+ * FOR A PARTICULAR PURPOSE. See the GNU General Public License for more
+ * details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with SIN; if not, write to the Free Software Foundation, Inc., 51 Franklin
+ * St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+
+#include "acpi_enumerator.h"
+
+static struct acpi_handlers *ah;
+static int ahsize;
+
+static char *page;
+static size_t size;
+
+int get_handlers(void)
+{
+ return ahsize;
+}
+
+char *get_hardware_id(int handle)
+{
+ return ah[handle].hardware_id;
+}
+
+static int acpi_store(struct acpi_device *device, struct acpi_driver *driver)
+{
+ if (device->flags.hardware_id) {
+ strcpy(ah[ahsize++].hardware_id,
+ acpi_device_hid(device));
+ }
+
+ return -ENOENT;
+}
+
+static int acpi_show(struct acpi_device *device, struct acpi_driver *driver)
+{
+ if (device->flags.hardware_id && size < PAGE_SIZE) {
+ int err;
+
+ err = snprintf(&page[size],
+ PAGE_SIZE - size,
+ "%d: %s [%s, %lx]\n",
+ ahsize++,
+ acpi_device_hid(device),
+ acpi_device_bid(device),
+ acpi_device_adr(device));
+
+ if (err >= PAGE_SIZE - size) {
+ err = PAGE_SIZE - size;
+ }
+
+ if (err > 0) {
+ size += err;
+ }
+ }
+
+ return -ENOENT;
+}
+
+int acpi_enum(char *buf)
+{
+ struct acpi_driver ad;
+
+ page = buf;
+
+ ad.ops.match = acpi_show;
+ (void) acpi_bus_register_driver(&ad);
+ acpi_bus_unregister_driver(&ad);
+
+ if (!ahsize) {
+ printk(KERN_NOTICE "no acpi handlers found\n");
+ return -ENODEV;
+ }
+
+ ah = kmalloc(ahsize * sizeof (struct acpi_handlers), GFP_KERNEL);
+
+ ahsize = 0;
+
+ if (!ah) {
+ return -ENOMEM;
+ }
+
+ ad.ops.match = acpi_store;
+ (void) acpi_bus_register_driver(&ad);
+ acpi_bus_unregister_driver(&ad);
+
+ return size;
+}
+
+void free_acpi_enum(void)
+{
+ if (ahsize) {
+ ahsize = 0;
+ kfree(ah);
+ }
+}
diff -uN SIN/acpi_enumerator.h SIN.new/acpi_enumerator.h
--- SIN/acpi_enumerator.h 1970-01-01 01:00:00.0 +0100
+++ SIN.new/acpi_enumerator.h 2007-01-18 19:20:53.0 +0100
@@ -0,0 +1,36 @@
+/*
+ * Copyright (C) 2007 Alessandro Di Marco
+ */
+
+/*
+ * This file is part of SIN.
+ *
+ * SIN is free software; you can redistribute it and/or modify it under the
+ * terms of the GNU General Public License as published by the Free Software
+ * Foundation; version 2 of the License.
+ *
+ * SIN is distributed in the hope that it will be useful, but WITHOUT ANY
+ * WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
+ * FOR A PARTICULAR PURPOSE. See the GNU General Public License for more
+ * details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with SIN; if not, write to the Free Software Foundation, Inc., 51
Re: PATCH: Update disable_IO_APIC to use 8-bit destination field (X86_64)
On Thu, 2007-01-18 at 11:14 -0700, Eric W. Biederman wrote:
> Benjamin Romer <[EMAIL PROTECTED]> writes:
>
> > On Thu, 2007-01-18 at 13:30 +0530, Vivek Goyal wrote:
> >> On Thu, Jan 18, 2007 at 12:10:55AM -0700, Eric W. Biederman wrote:
> >> > Vivek Goyal <[EMAIL PROTECTED]> writes:
> >> > >
> >> > > Or how about making physical_dest field also 8bit like logical_dest
> >> > > field.
> >> > > This will work both for 4bit and 8bit physical apic ids at the same
> >> > > time
> >> > > code becomes more intutive and it is easier to know whether IOAPIC is
> > being
> >> > > put in physical or destination logical mode.
> >> >
> >> > Exactly what I was trying to suggest.
> >> >
> >> > Looking closer at the code I think it makes sense to just kill the union
> >> > and
> >> > stop the discrimination between physical and logical modes and just have
> >> > a
> >> > dest field in the structure. Roughly as you were suggesting at first.
> >> >
> >> > The reason we aren't bitten by this on a regular basis is the normal code
> >> > path uses logical.logical_dest in both logical and physical modes.
> >> > Which is a little confusing.
> >> >
> >> > Since there really isn't a distinction to be made we should just stop
> >> > trying, which will make maintenance easier :)
> >> >
> >> > Currently there are several non-common case users of physical_dest
> >> > that are probably bitten by this problem under the right
> >> > circumstances.
> >> >
> >> > So I think we should just make the structure:
> >> >
> >> > struct IO_APIC_route_entry {
> >> > __u32 vector : 8,
> >> > delivery_mode : 3, /* 000: FIXED
> >> > * 001: lowest prio
> >> > * 111: ExtINT
> >> > */
> >> > dest_mode : 1, /* 0: physical, 1: logical */
> >> > delivery_status : 1,
> >> > polarity: 1,
> >> > irr : 1,
> >> > trigger : 1, /* 0: edge, 1: level */
> >> > mask: 1, /* 0: enabled, 1: disabled */
> >> > __reserved_2: 15;
> >> >
> >> > __u32 __reserved_3: 24,
> >> > __dest : 8;
> >> > } __attribute__ ((packed));
> >> >
> >> > And fixup the users. This should keep us from getting bit by this bug
> >> > in the future. Like when people start introducing support for more
> >> > than 256 cores and the low 24bits start getting used.
> >> >
> >> > Or when someone new starts working on the code and thinks the fact
> >> > the field name says logical we are actually using the apic in logical
> >> > mode.
> >>
> >> This makes perfect sense to me. Ben, interested in providing a patch
> >> for this?
> >>
> >> Thanks
> >> Vivek
> >
> > OK, here's the updated patch that uses the new definition and fixes up
> > the other places that use it. I built and tested this on the ES7000/ONE
> > and it works well. :)
>
> Cool.
>
> I hate to pick nits by why the double underscore on dest?
>
It was defined that way in the updated structure definition you sent in
a previous mail, so I figured you wanted it that way. Here's another
revision with the double underscores removed. :)
-- Ben
diff -ru linux-2.6.19.2-orig/arch/x86_64/kernel/io_apic.c
linux-2.6.19.2/arch/x86_64/kernel/io_apic.c
--- linux-2.6.19.2-orig/arch/x86_64/kernel/io_apic.c2007-03-18
12:29:52.0 -0400
+++ linux-2.6.19.2/arch/x86_64/kernel/io_apic.c 2007-03-18
13:15:26.0 -0400
@@ -814,7 +814,7 @@
entry.delivery_mode = INT_DELIVERY_MODE;
entry.dest_mode = INT_DEST_MODE;
entry.mask = 0; /* enable IRQ */
- entry.dest.logical.logical_dest =
cpu_mask_to_apicid(TARGET_CPUS);
+ entry.dest = cpu_mask_to_apicid(TARGET_CPUS);
idx = find_irq_entry(apic,pin,mp_INT);
if (idx == -1) {
@@ -832,7 +832,7 @@
if (irq_trigger(idx)) {
entry.trigger = 1;
entry.mask = 1;
- entry.dest.logical.logical_dest =
cpu_mask_to_apicid(TARGET_CPUS);
+ entry.dest = cpu_mask_to_apicid(TARGET_CPUS);
}
irq = pin_2_irq(idx, apic, pin);
@@ -847,7 +847,7 @@
if (vector < 0)
continue;
- entry.dest.logical.logical_dest =
cpu_mask_to_apicid(mask);
+ entry.dest = cpu_mask_to_apicid(mask);
entry.vector = vector;
ioapic_register_intr(irq, vector, IOAPIC_AUTO);
@@ -888,7 +888,7 @@
*/
entry.dest_mode = INT_DEST_MODE;
entry.mask = 0; /* unmask IRQ now */
- entry.dest.logical.logical_dest = cpu_mask_to_apicid(TARGET_CPUS);
+ entry.dest = cpu_mask_to_apicid(TARGET_CPUS);
Re: kernel 2.6.19 bug report --> "atkbd.c:spurious ACK on isa...." when boot from SATA hd, no way to start system
On Thu, 18 Jan 2007 14:50:24 +0100, "Daniel Gonzalez Schiller" <[EMAIL PROTECTED]> said: > When boot with SATA HD --> "atkbd.c:spurious ACK on > isa0060/serio0. Some program might be trying access hardware > directly." > When booting with normal hd no problem. The problems are almost certainly to do with the driver (or lack of driver) for your hard disc interface. There will be earlier messages (and more importantly a lack of messages showing hardware being detected) that end with failure to mount your root partition. The configuration options for SATA moved in 2.6.19. They are now under Device Drivers -> Serial ATA (prod) and Parallel ATA (experimental) drivers > I've searched in changelog but nothing found. The error messages are as a result of the keyboard LEDs being flashed. Have a look at: http://groups.google.co.uk/group/linux.kernel/msg/197ddf90dd6e5058 http://groups.google.com/group/fa.linux.kernel/msg/660c4d2dc419ee44 Try booting with i8042.panicblink=0 -- Alan J. Wylie http://www.wylie.me.uk/ "Perfection [in design] is achieved not when there is nothing left to add, but rather when there is nothing left to take away." -- Antoine de Saint-Exupery - 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] IDE Driver for Delkin/Lexar/etc.. cardbus CF adapter
On 1/13/07, Mark Lord <[EMAIL PROTECTED]> wrote: On Thursday 11 January 2007 23:17, Bartlomiej Zolnierkiewicz wrote: > > My working IDE tree (against Linus' tree) now resides here: > > http://kernel.org/pub/linux/kernel/people/bart/pata-2.6/patches/ Bart, here's a driver I've been keeping out-of-tree for the past couple of years. This is for the Delking/Lexar/ASKA/etc.. 32-bit cardbus IDE CompactFlash adapter card. It's probably way out of sync with the latest driver model (??), but it still builds/works. I'm not interested in doing much of a rewrite, other than for libata someday, as I no longer use the card myself. But lots of other people do seem to use it, so it might be nice to see it "in-tree". Signed-off-by: Mark Lord <[EMAIL PROTECTED]> Thanks, I applied it to IDE tree. [ I must have been really somehow fixated on IDE unregistering/ordering mess not to merge it earlier. Sorry for that. ] - 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/RFC 2.6.21] ehca: ehca_uverbs.c: refactor ehca_mmap() for better readability
I've kind of lost the plot here. How does this patch fit in with the previous series of patches you posted? Does it replace them or go on top of them? Can please you resend me the full series of patch that remove the use of do_mmap(), with all cleanups and bug fixes included? And please roll up the fixes, I don't want one patch that adds a yield() inside a spinlock and then a later patch to fix it -- there's no sense in adding landmines for people potentially doing git bisect in the future. And also please try to split the patches so that they don't mix together two things -- please try to make the "remove obsolete prototypes" patch separate from the mmap fixes. Thanks... - 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 2.6.20-rc3]: 8139cp: Don't blindly enable interrupts
Jeff Garzik wrote: > Chris Lalancette wrote: > >> Francois Romieu wrote: >> >>> Chris Lalancette <[EMAIL PROTECTED]> : >>> [...] >>> >>> Thanks for the comments. While the patch you sent will help, there are still other places that will have problems. For example, in netpoll_send_skb, we call local_irq_save(flags), then call dev->hard_start_xmit(), and then call local_irq_restore(flags). This is a similar situation to what I described above; we will re-enable interrupts in cp_start_xmit(), when netpoll_send_skb doesn't expect that, and will probably run into issues. Is there a problem with changing cp_start_xmit to use the spin_lock_irqsave(), besides the extra instructions it needs? >>> >>> No. Given the history of locking in netpoll and the content of >>> Documentation/networking/netdevices.txt, asking Herbert which rule(s) >>> the code is supposed to follow seemed safer to me. >>> >>> You can forget my patch. >>> >>> Please resend your patch inlined to Jeff as described in >>> http://linux.yyz.us/patch-format.html. >>> >>> >>> >> Francois, >> Great. Resending mail, shortening subject to < 65 characters and >> inlining the patch. >> >> Thanks, >> Chris Lalancette >> >> Similar to this commit: >> >> http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d15e9c4d9a75702b30e00cdf95c71c88e3f3f51e >> >> >> It's not safe in cp_start_xmit to blindly call spin_lock_irq and then >> spin_unlock_irq, since it may very well be the case that cp_start_xmit >> was called with interrupts already disabled (I came across this bug in >> the context of netdump in RedHat kernels, but the same issue holds, for >> example, in netconsole). Therefore, replace all instances of >> spin_lock_irq and spin_unlock_irq with spin_lock_irqsave and >> spin_unlock_irqrestore, respectively, in cp_start_xmit(). I tested this >> against a fully-virtualized Xen guest using netdump, which happens to >> use the 8139cp driver to talk to the emulated hardware. I don't have a >> real piece of 8139cp hardware to test on, so someone else will have to >> do that. >> >> Signed-off-by: Chris Lalancette <[EMAIL PROTECTED]> > > > applied. > > In the future, please remove the quoted emails stuff, and anything > else that does not belong in the kernel changelog. It must be > hand-edited out, before using git-am to merge your patch into the > kernel tree. > > Jeff > > > Jeff, Ah, I see. Noted. Thanks. Chris Lalancette - 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: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
Tomasz Chmielewski wrote: I managed to compile a "Testing" 1.4.31 version (in fact, version 1.4 didn't compile because I didn't have a "linux" link pointing to kernel sources; version 1.4.31 tells that it's missing - so both versions compile fine). At this point, 1.4.31 is probably what you should be using. The problem is... I'm not sure how to start with it. The package doesn't have much documentation (other than "read the source"), does it? On the other hand, I see it comes with a couple of useful tools, like sh (dash)... They are also pretty small, so everything should fit into 300 kB (dash=70kB, kinit=70kB, mount=12kB). With kinit you don't even need dash/mount... kinit is a monolithic binary for everything. In other words, you'd typically use *either* dash+mount, *or* kinit... -hpa - 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: Possible ways of dealing with OOM conditions.
On Thu, Jan 18, 2007 at 06:31:53PM +0100, Peter Zijlstra ([EMAIL PROTECTED]) wrote: > > skbs are the most extensively used path. > > Actually the same is applied to route - dst_entries and rtable are > > allocated through own wrappers. > > Still, edit all places and perhaps forget one and make sure all new code > doesn't forget about it, or pick a solution that covers everything. There is _one_ place for allocation of any kind of object. skb path has two places. > > With power-of-two allocation SLAB wastes 500 bytes for each 1500 MTU > > packet (roughly), it is actaly one ACK packet - and I hear it from > > person who develops a system, which is aimed to guarantee ACK > > allocation in OOM :) > > I need full data traffic during OOM, not just a single ACK. But your code exactly limit codepath to several allocaions, which must be ACK. You do not have enough reserve to support whole traffic. So the right solution, IMO, is to _prevent_ such situation, which means that allocation is not allowed to depend on external conditions like VFS. Actually my above sentences were about the case, when anly having different allocator, it is possible to dramatically change memory usage model, which supffers greatly from power-of-two allocations. OOM condition is one of the results which has big SLAB overhead among other roots. Actually all pathes which work with kmem_cache are safe against it, since kernel cache packs objects, but thos who uses raw kmalloc has problems. > > SLAB overhead is _very_ expensive for network - what if jumbo frame is > > used? It becomes incredible in that case, although modern NICs allows > > scatter-gather, which is aimed to fix the problem. > > Jumbo frames are fine if the hardware can do SG-DMA.. Notice word _IF_ in you sentence. e1000 for example can not (or it can, but driver is not developed for such scenario). > > Cache misses for small packet flow due to the fact, that the same data > > is allocated and freed and accessed on different CPUs will become an > > issue soon, not right now, since two-four core CPUs are not yet to be > > very popular and price for the cache miss is not _that_ high. > > SGI does networking too, right? Yep, Cristoph Lameter developed own allocator too. I agreee with you, that if that price is too high already, then it is a dditional sign to look into network tree allocator (yep, name is bad) again. > > That is wrong definition just because no one developed different system. > > Defragmentation is a result of broken system. > > > > Existing design _does_not_ allow to have the situation when whole page > > belongs to the same cache after it was actively used, the same is > > applied to the situation when several pages, which create contiguous > > region, are used by different users, so people start develop VM tricks > > to move pages around so they would be placed near in address space. > > > > Do not fix the result, fix the reason. > > *plonk* 30+yrs of research ignored. 30 years to develop SLAB allocator? In what universe that is all about? > > > > The whole pool of pages becomes reserve, since no one (and mainly VFS) > > > > can consume that reserve. > > > > > > Ah, but there you violate my requirement, any network allocation can > > > claim the last bit of memory. The whole idea was that the reserve is > > > explicitly managed. > > > > > > It not only needs protection from other users but also from itself. > > > > Specifying some users as good and others as bad generally tends to very > > bad behaviour. Your appwoach only covers some users, mine does not > > differentiate between users, > > The kernel is special, right? It has priority over whatever user-land > does. Kernel only does ACK generation and allocation for userspace. Kernel does not know that some of users are potentially good or bad, and if you will export this socket option to the userspace, everyone will think that his application is good enough to use reserve. So, for kernel-only side you just need to preallocate pool of packets and use them when system is in OOM (reclaim). For the long direction, new approach of memory allocaiton should be developed, and there are different works in that direction - NTA is one of them and not the only one, for the best resutlts it must be combined with vm-tricks defragmentation too. > > but prevents system from such situation at all. > > I'm not seeing that, with your approach nobody stops the kernel from > filling up the memory with user-space network traffic. > > swapping is not some random user process, its a fundamental kernel task, > if this fails the machine is history. You completely misses the point. The main goal is to 1. reduce fragmentation and/or enable self defragmentation (which is done in NTA), this also reduces memory usage. 2. perform correct recover steps in OOM - reduce memory usage, use different allocator and/or reserve (which is the case, where NTA can be used) 3. do not allow OOM condition - unfortunately it
Re: [RFC] pci_bus conversion to struct device
On Thursday, January 18, 2007 1:00 am, Greg KH wrote: > On Thu, Jan 18, 2007 at 09:14:06AM +0100, Martin Mares wrote: > > Hello! > > > > > I recommend we just delete the pci_bus class. I don't think it > > > serves any useful purpose. The bridge can be inferred frmo the > > > sysfs hierarchy (not to mention lspci will tell you). The > > > cpuaffinity file should be moved from the bus to the device -- it > > > really doesn't make any sense to talk about which cpu a bus is > > > affine to, only a device. > > > > It doesn't seem to serve any useful purpose other than the affinity > > now, but I still think that it conceptually belongs there, because > > it makes sense to have per-bus attributes. For example, in the > > future we could show data width and signalling speed. > > So, if it were to stay, where in the tree should it be? Hanging off > of the pci device that is the bridge? Or just placing these files > within the pci device directory itself, as it is the bridge. > > There are also some "legacy io" binary sysfs files in these > directories for those platforms that support it (#ifdef > HAVE_PCI_LEGACY), and I'm guessing that there is some user for them > out there, otherwise they would not have been added... > > Hm, only ia64 enables that option. Matthew, do you care about those > files? Those interfaces could be supported on other platforms (iirc benh has been planning to add legacy_* support to ppc for awhile). It would be great if they were supported everywhere to provide userspace with a fairly sane way to get at this stuff on all Linux systems... Should be trivial on i386 I think. Jesse - 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: Update disable_IO_APIC to use 8-bit destination field (X86_64)
Benjamin Romer <[EMAIL PROTECTED]> writes:
> On Thu, 2007-01-18 at 13:30 +0530, Vivek Goyal wrote:
>> On Thu, Jan 18, 2007 at 12:10:55AM -0700, Eric W. Biederman wrote:
>> > Vivek Goyal <[EMAIL PROTECTED]> writes:
>> > >
>> > > Or how about making physical_dest field also 8bit like logical_dest
>> > > field.
>> > > This will work both for 4bit and 8bit physical apic ids at the same time
>> > > code becomes more intutive and it is easier to know whether IOAPIC is
> being
>> > > put in physical or destination logical mode.
>> >
>> > Exactly what I was trying to suggest.
>> >
>> > Looking closer at the code I think it makes sense to just kill the union
>> > and
>> > stop the discrimination between physical and logical modes and just have a
>> > dest field in the structure. Roughly as you were suggesting at first.
>> >
>> > The reason we aren't bitten by this on a regular basis is the normal code
>> > path uses logical.logical_dest in both logical and physical modes.
>> > Which is a little confusing.
>> >
>> > Since there really isn't a distinction to be made we should just stop
>> > trying, which will make maintenance easier :)
>> >
>> > Currently there are several non-common case users of physical_dest
>> > that are probably bitten by this problem under the right
>> > circumstances.
>> >
>> > So I think we should just make the structure:
>> >
>> > struct IO_APIC_route_entry {
>> >__u32 vector : 8,
>> >delivery_mode : 3, /* 000: FIXED
>> > * 001: lowest prio
>> > * 111: ExtINT
>> > */
>> >dest_mode : 1, /* 0: physical, 1: logical */
>> >delivery_status : 1,
>> >polarity: 1,
>> >irr : 1,
>> >trigger : 1, /* 0: edge, 1: level */
>> >mask: 1, /* 0: enabled, 1: disabled */
>> >__reserved_2: 15;
>> >
>> >__u32 __reserved_3: 24,
>> >__dest : 8;
>> > } __attribute__ ((packed));
>> >
>> > And fixup the users. This should keep us from getting bit by this bug
>> > in the future. Like when people start introducing support for more
>> > than 256 cores and the low 24bits start getting used.
>> >
>> > Or when someone new starts working on the code and thinks the fact
>> > the field name says logical we are actually using the apic in logical
>> > mode.
>>
>> This makes perfect sense to me. Ben, interested in providing a patch
>> for this?
>>
>> Thanks
>> Vivek
>
> OK, here's the updated patch that uses the new definition and fixes up
> the other places that use it. I built and tested this on the ES7000/ONE
> and it works well. :)
Cool.
I hate to pick nits by why the double underscore on dest?
> struct IO_APIC_route_entry {
> - __u32 vector : 8,
> - delivery_mode : 3, /* 000: FIXED
> - * 001: lowest prio
> - * 111: ExtINT
> - */
> - dest_mode : 1, /* 0: physical, 1: logical */
> - delivery_status : 1,
> - polarity: 1,
> - irr : 1,
> - trigger : 1, /* 0: edge, 1: level */
> - mask: 1, /* 0: enabled, 1: disabled */
> - __reserved_2: 15;
> -
> - union { struct { __u32
> - __reserved_1: 24,
> - physical_dest : 4,
> - __reserved_2: 4;
> - } physical;
> -
> - struct { __u32
> - __reserved_1: 24,
> - logical_dest: 8;
> - } logical;
> - } dest;
> +__u32 vector : 8,
> +delivery_mode : 3, /* 000: FIXED
> + * 001: lowest prio
> + * 111: ExtINT
> + */
> +dest_mode : 1, /* 0: physical, 1: logical */
> +delivery_status : 1,
> +polarity: 1,
> +irr : 1,
> +trigger : 1, /* 0: edge, 1: level */
> +mask: 1, /* 0: enabled, 1: disabled */
> +__reserved_2: 15;
>
> +__u32 __reserved_3: 24,
> +__dest : 8;
> } __attribute__ ((packed));
>
> /*
-
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: unable to mmap /dev/kmem
On Thu, 18 Jan 2007, Nadia Derbey wrote:
>
> Trying to mmap /dev/kmem with an offset I take from /boot/System.map,
> I get an EIO error on a 2.6.20-rc4.
> This is something that used to work on older kernels.
>
> Had a look at mmap_kmem() in drivers/char/mem.c, and I'm wondering whether
> pfn is correctly computed there: shouldn't we have something like
>
> pfn = PFN_DOWN(virt_to_phys((void *)PAGE_OFFSET)) +
> __pa(vma->vm_pgoff << PAGE_SHIFT);
>
> instead of
>
> pfn = PFN_DOWN(virt_to_phys((void *)PAGE_OFFSET)) + vma->vm_pgoff;
>
> Or may be should I substract PAGE_OFFSET from the value I get from System.map
> before mmapping /dev/kmem?
Sigh, you're right, 2.6.19 messed that up completely.
No, you never had to subtract PAGE_OFFSET from that address
in the past, and you shouldn't have to do so now.
Please revert the offending patch below, and then maybe Franck
can come up with a patch which preserves the original behaviour
on architectures which used to work (e.g. i386), while fixing
it for those architectures (which are they?) that did not.
I guess it's reassuring to know that not many are actually
using mmap of /dev/kmem, so you're the first to notice: thanks.
Hugh
From: Franck Bui-Huu <[EMAIL PROTECTED]>
Date: Thu, 12 Oct 2006 19:06:33 + (+0200)
Subject: [PATCH] Fix up mmap_kmem
X-Git-Tag: v2.6.19-rc2^0~6
X-Git-Url:
http://127.0.0.1:1234/?p=.git;a=commitdiff_plain;h=99a10a60ba9bedcf5d70ef81414d3e03816afa3f;hp=a5344a9555fffd045218aced89afd6ca0f884e10
[PATCH] Fix up mmap_kmem
vma->vm_pgoff is an pfn _offset_ relatif to the begining
of the memory start. The previous code was doing at first:
vma->vm_pgoff << PAGE_SHIFT
which results into a wrong physical address since some
platforms have a physical mem start that can be different
from 0. After that the previous call __pa() on this
wrong physical address, however __pa() is used to convert
a _virtual_ address into a physical one.
This patch rewrites this convertion. It calculates the
pfn of PAGE_OFFSET which is the pfn of the mem start
then it adds the vma->vm_pgoff to it.
It also uses virt_to_phys() instead of __pa() since the
latter shouldn't be used by drivers.
Signed-off-by: Franck Bui-Huu <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 6511012..a89cb52 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -292,8 +292,8 @@ static int mmap_kmem(struct file * file,
{
unsigned long pfn;
- /* Turn a kernel-virtual address into a physical page frame */
- pfn = __pa((u64)vma->vm_pgoff << PAGE_SHIFT) >> PAGE_SHIFT;
+ /* Turn a pfn offset into an absolute pfn */
+ pfn = PFN_DOWN(virt_to_phys((void *)PAGE_OFFSET)) + vma->vm_pgoff;
/*
* RED-PEN: on some architectures there is more mapped memory
-
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] extend the set of "__attribute__" shortcut macros
On Thu, Jan 18, 2007 at 12:35:18PM -0500, Robert P. J. Day wrote: > Extend the set of "__attribute__" shortcut macros, and remove > identical (and now superfluous) definitions from a couple of source > files. > > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> Nice clenaup, thanks! Acked-by: Ralf Baechle <[EMAIL PROTECTED]> Ralf - 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] Print number of oopses in Sysrq-P output
On Thu, Jan 18, 2007 at 08:05:22PM +0300, Alexey Dobriyan wrote: > From: Pavel Emelianov <[EMAIL PROTECTED]> > > Useful in deciding whether said output should be ignored > in absence of other info. :) > > Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]> > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> > --- > > arch/i386/kernel/process.c |4 +++- > arch/i386/kernel/traps.c |2 +- > arch/x86_64/kernel/process.c |6 -- > arch/x86_64/kernel/traps.c |3 ++- > 4 files changed, 10 insertions(+), 5 deletions(-) What about the other architectures? > --- a/arch/i386/kernel/traps.c > +++ b/arch/i386/kernel/traps.c > @@ -366,6 +366,7 @@ int is_valid_bugaddr(unsigned long eip) > return ud2 == 0x0b0f; > } > > +int die_counter = 0; Global variables don't have to be initialised at 0. They live in the .bss segment so they will automatically initialised at 0 and not take space in the kernel image. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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/
[PATCH] extend the set of "__attribute__" shortcut macros
Extend the set of "__attribute__" shortcut macros, and remove
identical (and now superfluous) definitions from a couple of source
files.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
based on a page at robert love's blog:
http://rlove.org/log/2005102601
extend the set of shortcut macros defined in compiler-gcc.h with the
following:
#define __packed __attribute__((packed))
#define __weak __attribute__((weak))
#define __naked__attribute__((naked))
#define __noreturn __attribute__((noreturn))
#define __pure __attribute__((pure))
#define __aligned(x) __attribute__((aligned(x)))
#define __printf(a,b) __attribute__((format(printf,a,b)))
once these are in place, it's up to subsystem maintainers to decide
if they want to take advantage of them. there is already a strong
precedent for using shortcuts like this in the source tree.
the ones that might give people pause are "__aligned" and
"__printf", but shortcuts for both of those are already in use, and in
some ways very confusingly. note the two very different definitions
for a macro named "ALIGNED":
drivers/net/sgiseeq.c:#define ALIGNED(x) unsigned long)(x)) + 0xf) &
~(0xf))
drivers/scsi/ultrastor.c:#define ALIGNED(x) __attribute__((aligned(x)))
also:
include/acpi/platform/acgcc.h:
#define ACPI_PRINTF_LIKE(c) __attribute__ ((__format__ (__printf__, c,
c+1)))
given the precedent, then, it seems logical to at least standardize on
a consistent set of these macros.
arch/mips/mm/cache.c |2 --
fs/hfs/hfs.h |2 --
fs/hfsplus/hfsplus_raw.h |2 --
include/linux/compiler-gcc.h |7 +++
4 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/mips/mm/cache.c b/arch/mips/mm/cache.c
index 1f954a2..31819c5 100644
--- a/arch/mips/mm/cache.c
+++ b/arch/mips/mm/cache.c
@@ -107,8 +107,6 @@ void __update_cache(struct vm_area_struct *vma, unsigned
long address,
}
}
-#define __weak __attribute__((weak))
-
static char cache_panic[] __initdata = "Yeee, unsupported cache architecture.";
void __init cpu_cache_init(void)
diff --git a/fs/hfs/hfs.h b/fs/hfs/hfs.h
index 88099ab..1445e3a 100644
--- a/fs/hfs/hfs.h
+++ b/fs/hfs/hfs.h
@@ -83,8 +83,6 @@
/* HFS structures as they appear on the disk */
-#define __packed __attribute__ ((packed))
-
/* Pascal-style string of up to 31 characters */
struct hfs_name {
u8 len;
diff --git a/fs/hfsplus/hfsplus_raw.h b/fs/hfsplus/hfsplus_raw.h
index 4920553..fe99fe8 100644
--- a/fs/hfsplus/hfsplus_raw.h
+++ b/fs/hfsplus/hfsplus_raw.h
@@ -15,8 +15,6 @@
#include
-#define __packed __attribute__ ((packed))
-
/* Some constants */
#define HFSPLUS_SECTOR_SIZE512
#define HFSPLUS_SECTOR_SHIFT 9
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 6e1c44a..9008eab 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -27,6 +27,13 @@
#define __inline__ __inline__ __attribute__((always_inline))
#define __inline __inline__attribute__((always_inline))
#define __deprecated __attribute__((deprecated))
+#define __packed __attribute__((packed))
+#define __weak __attribute__((weak))
+#define __naked__attribute__((naked))
+#define __noreturn __attribute__((noreturn))
+#define __pure __attribute__((pure))
+#define __aligned(x) __attribute__((aligned(x)))
+#define __printf(a,b) __attribute__((format(printf,a,b)))
#define noinline __attribute__((noinline))
#define __attribute_pure__ __attribute__((pure))
#define __attribute_const____attribute__((__const__))
-
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: Possible ways of dealing with OOM conditions.
On Thu, 2007-01-18 at 18:50 +0300, Evgeniy Polyakov wrote: > On Thu, Jan 18, 2007 at 04:10:52PM +0100, Peter Zijlstra ([EMAIL PROTECTED]) > wrote: > > On Thu, 2007-01-18 at 16:58 +0300, Evgeniy Polyakov wrote: > > > > > Network is special in this regard, since it only has one allocation path > > > (actually it has one cache for skb, and usual kmalloc, but they are > > > called from only two functions). > > > > > > So it would become > > > ptr = network_alloc(); > > > and network_alloc() would be usual kmalloc or call for own allocator in > > > case of deadlock. > > > > There is more to networking that skbs only, what about route cache, > > there is quite a lot of allocs in this fib_* stuff, IGMP etc... > > skbs are the most extensively used path. > Actually the same is applied to route - dst_entries and rtable are > allocated through own wrappers. Still, edit all places and perhaps forget one and make sure all new code doesn't forget about it, or pick a solution that covers everything. > With power-of-two allocation SLAB wastes 500 bytes for each 1500 MTU > packet (roughly), it is actaly one ACK packet - and I hear it from > person who develops a system, which is aimed to guarantee ACK > allocation in OOM :) I need full data traffic during OOM, not just a single ACK. > SLAB overhead is _very_ expensive for network - what if jumbo frame is > used? It becomes incredible in that case, although modern NICs allows > scatter-gather, which is aimed to fix the problem. Jumbo frames are fine if the hardware can do SG-DMA.. > Cache misses for small packet flow due to the fact, that the same data > is allocated and freed and accessed on different CPUs will become an > issue soon, not right now, since two-four core CPUs are not yet to be > very popular and price for the cache miss is not _that_ high. SGI does networking too, right? > > > > > performs self-defragmentation of the memeory, > > > > > > > > Does it move memory about? > > > > > > It works in a page, not as pages - when neighbour regions are freed, > > > they are combined into single one with bigger size > > > > Yeah, that is not defragmentation, defragmentation is moving active > > regions about to create contiguous free space. What you do is free space > > coalescence. > > That is wrong definition just because no one developed different system. > Defragmentation is a result of broken system. > > Existing design _does_not_ allow to have the situation when whole page > belongs to the same cache after it was actively used, the same is > applied to the situation when several pages, which create contiguous > region, are used by different users, so people start develop VM tricks > to move pages around so they would be placed near in address space. > > Do not fix the result, fix the reason. *plonk* 30+yrs of research ignored. > > > The whole pool of pages becomes reserve, since no one (and mainly VFS) > > > can consume that reserve. > > > > Ah, but there you violate my requirement, any network allocation can > > claim the last bit of memory. The whole idea was that the reserve is > > explicitly managed. > > > > It not only needs protection from other users but also from itself. > > Specifying some users as good and others as bad generally tends to very > bad behaviour. Your appwoach only covers some users, mine does not > differentiate between users, The kernel is special, right? It has priority over whatever user-land does. > but prevents system from such situation at all. I'm not seeing that, with your approach nobody stops the kernel from filling up the memory with user-space network traffic. swapping is not some random user process, its a fundamental kernel task, if this fails the machine is history. - 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: Update disable_IO_APIC to use 8-bit destination field (X86_64)
On Thu, 2007-01-18 at 13:30 +0530, Vivek Goyal wrote:
> On Thu, Jan 18, 2007 at 12:10:55AM -0700, Eric W. Biederman wrote:
> > Vivek Goyal <[EMAIL PROTECTED]> writes:
> > >
> > > Or how about making physical_dest field also 8bit like logical_dest field.
> > > This will work both for 4bit and 8bit physical apic ids at the same time
> > > code becomes more intutive and it is easier to know whether IOAPIC is
> > > being
> > > put in physical or destination logical mode.
> >
> > Exactly what I was trying to suggest.
> >
> > Looking closer at the code I think it makes sense to just kill the union and
> > stop the discrimination between physical and logical modes and just have a
> > dest field in the structure. Roughly as you were suggesting at first.
> >
> > The reason we aren't bitten by this on a regular basis is the normal code
> > path uses logical.logical_dest in both logical and physical modes.
> > Which is a little confusing.
> >
> > Since there really isn't a distinction to be made we should just stop
> > trying, which will make maintenance easier :)
> >
> > Currently there are several non-common case users of physical_dest
> > that are probably bitten by this problem under the right
> > circumstances.
> >
> > So I think we should just make the structure:
> >
> > struct IO_APIC_route_entry {
> > __u32 vector : 8,
> > delivery_mode : 3, /* 000: FIXED
> > * 001: lowest prio
> > * 111: ExtINT
> > */
> > dest_mode : 1, /* 0: physical, 1: logical */
> > delivery_status : 1,
> > polarity: 1,
> > irr : 1,
> > trigger : 1, /* 0: edge, 1: level */
> > mask: 1, /* 0: enabled, 1: disabled */
> > __reserved_2: 15;
> >
> > __u32 __reserved_3: 24,
> > __dest : 8;
> > } __attribute__ ((packed));
> >
> > And fixup the users. This should keep us from getting bit by this bug
> > in the future. Like when people start introducing support for more
> > than 256 cores and the low 24bits start getting used.
> >
> > Or when someone new starts working on the code and thinks the fact
> > the field name says logical we are actually using the apic in logical
> > mode.
>
> This makes perfect sense to me. Ben, interested in providing a patch
> for this?
>
> Thanks
> Vivek
OK, here's the updated patch that uses the new definition and fixes up
the other places that use it. I built and tested this on the ES7000/ONE
and it works well. :)
-- Ben
diff -ru linux-2.6.19.2-orig/arch/x86_64/kernel/io_apic.c
linux-2.6.19.2/arch/x86_64/kernel/io_apic.c
--- linux-2.6.19.2-orig/arch/x86_64/kernel/io_apic.c2007-03-18
12:29:52.0 -0400
+++ linux-2.6.19.2/arch/x86_64/kernel/io_apic.c 2007-03-18
13:15:26.0 -0400
@@ -814,7 +814,7 @@
entry.delivery_mode = INT_DELIVERY_MODE;
entry.dest_mode = INT_DEST_MODE;
entry.mask = 0; /* enable IRQ */
- entry.dest.logical.logical_dest =
cpu_mask_to_apicid(TARGET_CPUS);
+ entry.__dest = cpu_mask_to_apicid(TARGET_CPUS);
idx = find_irq_entry(apic,pin,mp_INT);
if (idx == -1) {
@@ -832,7 +832,7 @@
if (irq_trigger(idx)) {
entry.trigger = 1;
entry.mask = 1;
- entry.dest.logical.logical_dest =
cpu_mask_to_apicid(TARGET_CPUS);
+ entry.__dest = cpu_mask_to_apicid(TARGET_CPUS);
}
irq = pin_2_irq(idx, apic, pin);
@@ -847,7 +847,7 @@
if (vector < 0)
continue;
- entry.dest.logical.logical_dest =
cpu_mask_to_apicid(mask);
+ entry.__dest = cpu_mask_to_apicid(mask);
entry.vector = vector;
ioapic_register_intr(irq, vector, IOAPIC_AUTO);
@@ -888,7 +888,7 @@
*/
entry.dest_mode = INT_DEST_MODE;
entry.mask = 0; /* unmask IRQ now */
- entry.dest.logical.logical_dest = cpu_mask_to_apicid(TARGET_CPUS);
+ entry.__dest = cpu_mask_to_apicid(TARGET_CPUS);
entry.delivery_mode = INT_DELIVERY_MODE;
entry.polarity = 0;
entry.trigger = 0;
@@ -988,18 +988,17 @@
printk(KERN_DEBUG " IRQ redirection table:\n");
- printk(KERN_DEBUG " NR Log Phy Mask Trig IRR Pol"
- " Stat Dest Deli Vect: \n");
+ printk(KERN_DEBUG " NR Dst Mask Trig IRR Pol"
+ " Stat Dmod Deli Vect: \n");
for (i = 0; i <= reg_01.bits.entries; i++) {
struct IO_APIC_route_entry entry;
entry = ioapic_r
Re: [PATCH] Centralize the macro definition of "__packed".
On Thu, 18 Jan 2007, Tim Schmielau wrote: > On Thu, 18 Jan 2007, Robert P. J. Day wrote: > > > actually, it *appears* that the standard works this way. the macro > > "__deprecated" is defined in compiler-gcc.h with: > > > > #define __deprecated __attribute__((deprecated)) > > > > while the more generic compiler.h handles whether or not it was > > defined: > > > > #ifndef __deprecated > > # define __deprecated /* unimplemented */ > > #endif > > > > so i'm guessing that's how any new attribute shortcut macros should be > > handled, yes? > > Well, since the definitions lived well in compiler-generic land for > quite some time, I'd guess it should be ok not to #ifndef - guard > them. likely() and unlikely() are currently handled like that. If > the need ever arises to make them compiler specific, whoever does > that can still add the #ifndef then. as it is, i believe the only two compilers that are officially supported for building the kernel are gcc and icc, and icc identifies itself as a GNU compiler anyway, so adding to compiler-gcc.h should be safe until the situation changes. and, as you say, if the situation changes, fixing compiler.h would be easy. rday - 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: A question about break and sysrq on a serial console (2.6.19.1)
On Thu, Jan 18, 2007 at 08:52:49AM -0800, Brian Beattie wrote: > On Thu, 2007-01-18 at 16:47 +, Russell King wrote: > > On Thu, Jan 18, 2007 at 08:19:47AM -0800, Brian Beattie wrote: > > > On Thu, 2007-01-18 at 09:13 +, Russell King wrote: > > > > On Wed, Jan 17, 2007 at 03:56:54PM -0800, Brian Beattie wrote: > > > > > I'm trying to do a SYSRQ over a serial console. As I understand it a > > > > > break will do that, but I'm not seeing the SYSRQ. In looking at > > > > > uart_handle_break() in drivers/serial/8250.c it looks like the code > > > > > will > > > > > toggle port->sysrq, rather than just setting it when the port is a > > > > > console. I think the correct code would be to move the "port->sysrq = > > > > > 0;" to follow the closing brace on the next line, or am I missing > > > > > something. > > > > > > > > Thereby preventing the action of (which may be to cause a SAK > > > > event, which would be rather important on a console to ensure that > > > > you're really logging in rather than typing your password into another > > > > users program which just looks like a login program.) > > > > > > > > Note that the sequence for sysrq is: > > > > > > > > (non-break characters or nothing) > > > > > > > well the code as is, is not working. Printk's tell me that > > > uart_handle_break() is called repeatedly while the break condition is > > > active, toggling port->sysrq so that it's a 50/50 chance on whether > > > port->sysrq will be set or cleared when the break condition ends. On > > > the other hand the 8250 break condition handling code is not working > > > anyway, so the problem may be that the 8250 code is not calling > > > uart_handle_break() correctly. > > > > Please learn to use the "reply to all" button when using mailing lists. > I don't post much to LKML, I realized after I hit send I needed to reply > all. > > > > Works fine here. Which UART are you actually using? At a guess, it's > > probably a bad clone which does not have a correct break implementation. > > it's the built-in mpc8349 powerpc uart. Well, it looks like this UART has a differing behaviour to proper 16xxx UARTs - it says that the BI will be cleared when a stop bit is received in addition to when the LSR is read. That means that unless you check the LSR while the break condition is present, you may never know one existed. Standard 8250-compatible UARTs only clear the BI when the LSR is read. As for the rest of the description, it's quite loose. It doesn't really say under what conditions the BI bit is set, but I suggest that your UART repeatedly (and incorrectly) sets the BI bit when no *new* break condition exists. That would certainly explain your behaviour. Again, standard 8250-compatible UARTs don't do this. Not sure how to fix this without other people seeing a behavioural change. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - 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] Centralize the macro definition of "__packed".
On Thu, 18 Jan 2007, Robert P. J. Day wrote: > actually, it *appears* that the standard works this way. the macro > "__deprecated" is defined in compiler-gcc.h with: > > #define __deprecated __attribute__((deprecated)) > > while the more generic compiler.h handles whether or not it was > defined: > > #ifndef __deprecated > # define __deprecated /* unimplemented */ > #endif > > so i'm guessing that's how any new attribute shortcut macros should be > handled, yes? Well, since the definitions lived well in compiler-generic land for quite some time, I'd guess it should be ok not to #ifndef - guard them. likely() and unlikely() are currently handled like that. If the need ever arises to make them compiler specific, whoever does that can still add the #ifndef then. Tim - 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] Centralize the macro definition of "__packed".
On Thu, 18 Jan 2007, Tim Schmielau wrote: > On Thu, 18 Jan 2007, Robert P. J. Day wrote: > > > Centralize the attribute macro definition of "__packed" so no > > subsystem has to do that explicitly. > > > > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> > > > > --- > > > > compile tested to make sure the HFS subsystem still builds. now > > there's just 50 gazillion usages of "__attribute__((packed))" that can > > be tightened up. > > > > > > fs/hfs/hfs.h |2 -- > > fs/hfsplus/hfsplus_raw.h |2 -- > > include/linux/compiler-gcc.h |1 + > > 3 files changed, 1 insertion(+), 4 deletions(-) > > Moving definitions into compiler-gcc.h only will screw non-gcc > compilers like icc. They should probably go into the generic section > of compiler.h instead. actually, it *appears* that the standard works this way. the macro "__deprecated" is defined in compiler-gcc.h with: #define __deprecated __attribute__((deprecated)) while the more generic compiler.h handles whether or not it was defined: #ifndef __deprecated # define __deprecated /* unimplemented */ #endif so i'm guessing that's how any new attribute shortcut macros should be handled, yes? rday - 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/
[PATCH] Print number of oopses in Sysrq-P output
From: Pavel Emelianov <[EMAIL PROTECTED]>
Useful in deciding whether said output should be ignored
in absence of other info. :)
Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]>
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
arch/i386/kernel/process.c |4 +++-
arch/i386/kernel/traps.c |2 +-
arch/x86_64/kernel/process.c |6 --
arch/x86_64/kernel/traps.c |3 ++-
4 files changed, 10 insertions(+), 5 deletions(-)
--- a/arch/i386/kernel/process.c
+++ b/arch/i386/kernel/process.c
@@ -292,9 +292,11 @@ __setup("idle=", idle_setup);
void show_regs(struct pt_regs * regs)
{
unsigned long cr0 = 0L, cr2 = 0L, cr3 = 0L, cr4 = 0L;
+ extern int die_counter;
printk("\n");
- printk("Pid: %d, comm: %20s\n", current->pid, current->comm);
+ printk("Pid: %d, comm: %20s, oopses: %d\n",
+ current->pid, current->comm, die_counter);
printk("EIP: %04x:[<%08lx>] CPU: %d\n",0x & regs->xcs,regs->eip,
smp_processor_id());
print_symbol("EIP is at %s\n", regs->eip);
--- a/arch/i386/kernel/traps.c
+++ b/arch/i386/kernel/traps.c
@@ -366,6 +366,7 @@ int is_valid_bugaddr(unsigned long eip)
return ud2 == 0x0b0f;
}
+int die_counter = 0;
/*
* This is gone through when something in the kernel has done something bad and
* is about to be terminated.
@@ -381,7 +382,6 @@ void die(const char * str, struct pt_reg
.lock_owner = -1,
.lock_owner_depth = 0
};
- static int die_counter;
unsigned long flags;
oops_enter();
--- a/arch/x86_64/kernel/process.c
+++ b/arch/x86_64/kernel/process.c
@@ -305,14 +305,16 @@ void __show_regs(struct pt_regs * regs)
unsigned long cr0 = 0L, cr2 = 0L, cr3 = 0L, cr4 = 0L, fs, gs, shadowgs;
unsigned int fsindex,gsindex;
unsigned int ds,cs,es;
+ extern int die_counter;
printk("\n");
print_modules();
- printk("Pid: %d, comm: %.20s %s %s %.*s\n",
+ printk("Pid: %d, comm: %.20s %s %s %.*s oopses: %d\n",
current->pid, current->comm, print_tainted(),
init_utsname()->release,
(int)strcspn(init_utsname()->version, " "),
- init_utsname()->version);
+ init_utsname()->version,
+ die_counter);
printk("RIP: %04lx:[<%016lx>] ", regs->cs & 0x, regs->rip);
printk_address(regs->rip);
printk("RSP: %04lx:%016lx EFLAGS: %08lx\n", regs->ss, regs->rsp,
--- a/arch/x86_64/kernel/traps.c
+++ b/arch/x86_64/kernel/traps.c
@@ -519,9 +519,10 @@ void __kprobes oops_end(unsigned long fl
oops_exit();
}
+int die_counter = 0;
+
void __kprobes __die(const char * str, struct pt_regs * regs, long err)
{
- static int die_counter;
printk(KERN_EMERG "%s: %04lx [%u] ", str, err & 0x,++die_counter);
#ifdef CONFIG_PREEMPT
printk("PREEMPT ");
-
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: A question about break and sysrq on a serial console (2.6.19.1)
On Thu, 2007-01-18 at 16:47 +, Russell King wrote: > On Thu, Jan 18, 2007 at 08:19:47AM -0800, Brian Beattie wrote: > > On Thu, 2007-01-18 at 09:13 +, Russell King wrote: > > > On Wed, Jan 17, 2007 at 03:56:54PM -0800, Brian Beattie wrote: > > > > I'm trying to do a SYSRQ over a serial console. As I understand it a > > > > break will do that, but I'm not seeing the SYSRQ. In looking at > > > > uart_handle_break() in drivers/serial/8250.c it looks like the code will > > > > toggle port->sysrq, rather than just setting it when the port is a > > > > console. I think the correct code would be to move the "port->sysrq = > > > > 0;" to follow the closing brace on the next line, or am I missing > > > > something. > > > > > > Thereby preventing the action of (which may be to cause a SAK > > > event, which would be rather important on a console to ensure that > > > you're really logging in rather than typing your password into another > > > users program which just looks like a login program.) > > > > > > Note that the sequence for sysrq is: > > > > > > (non-break characters or nothing) > > > > > well the code as is, is not working. Printk's tell me that > > uart_handle_break() is called repeatedly while the break condition is > > active, toggling port->sysrq so that it's a 50/50 chance on whether > > port->sysrq will be set or cleared when the break condition ends. On > > the other hand the 8250 break condition handling code is not working > > anyway, so the problem may be that the 8250 code is not calling > > uart_handle_break() correctly. > > Please learn to use the "reply to all" button when using mailing lists. I don't post much to LKML, I realized after I hit send I needed to reply all. > > Works fine here. Which UART are you actually using? At a guess, it's > probably a bad clone which does not have a correct break implementation. it's the built-in mpc8349 powerpc uart. > -- Brian Beattie Firmware Engineer APCON, Inc. [EMAIL PROTECTED] - 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] Centralize the macro definition of "__packed".
On Thu, 18 Jan 2007, Robert P. J. Day wrote: > Centralize the attribute macro definition of "__packed" so no > subsystem has to do that explicitly. > > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> > > --- > > compile tested to make sure the HFS subsystem still builds. now > there's just 50 gazillion usages of "__attribute__((packed))" that can > be tightened up. > > > fs/hfs/hfs.h |2 -- > fs/hfsplus/hfsplus_raw.h |2 -- > include/linux/compiler-gcc.h |1 + > 3 files changed, 1 insertion(+), 4 deletions(-) Moving definitions into compiler-gcc.h only will screw non-gcc compilers like icc. They should probably go into the generic section of compiler.h instead. Tim - 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 2.6.20-rc3]: 8139cp: Don't blindly enable interrupts
Chris Lalancette wrote: Francois Romieu wrote: Chris Lalancette <[EMAIL PROTECTED]> : [...] Thanks for the comments. While the patch you sent will help, there are still other places that will have problems. For example, in netpoll_send_skb, we call local_irq_save(flags), then call dev->hard_start_xmit(), and then call local_irq_restore(flags). This is a similar situation to what I described above; we will re-enable interrupts in cp_start_xmit(), when netpoll_send_skb doesn't expect that, and will probably run into issues. Is there a problem with changing cp_start_xmit to use the spin_lock_irqsave(), besides the extra instructions it needs? No. Given the history of locking in netpoll and the content of Documentation/networking/netdevices.txt, asking Herbert which rule(s) the code is supposed to follow seemed safer to me. You can forget my patch. Please resend your patch inlined to Jeff as described in http://linux.yyz.us/patch-format.html. Francois, Great. Resending mail, shortening subject to < 65 characters and inlining the patch. Thanks, Chris Lalancette Similar to this commit: http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d15e9c4d9a75702b30e00cdf95c71c88e3f3f51e It's not safe in cp_start_xmit to blindly call spin_lock_irq and then spin_unlock_irq, since it may very well be the case that cp_start_xmit was called with interrupts already disabled (I came across this bug in the context of netdump in RedHat kernels, but the same issue holds, for example, in netconsole). Therefore, replace all instances of spin_lock_irq and spin_unlock_irq with spin_lock_irqsave and spin_unlock_irqrestore, respectively, in cp_start_xmit(). I tested this against a fully-virtualized Xen guest using netdump, which happens to use the 8139cp driver to talk to the emulated hardware. I don't have a real piece of 8139cp hardware to test on, so someone else will have to do that. Signed-off-by: Chris Lalancette <[EMAIL PROTECTED]> applied. In the future, please remove the quoted emails stuff, and anything else that does not belong in the kernel changelog. It must be hand-edited out, before using git-am to merge your patch into the kernel tree. Jeff - 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/
unable to mmap /dev/kmem
Hi there, Trying to mmap /dev/kmem with an offset I take from /boot/System.map, I get an EIO error on a 2.6.20-rc4. This is something that used to work on older kernels. Had a look at mmap_kmem() in drivers/char/mem.c, and I'm wondering whether pfn is correctly computed there: shouldn't we have something like pfn = PFN_DOWN(virt_to_phys((void *)PAGE_OFFSET)) + __pa(vma->vm_pgoff << PAGE_SHIFT); instead of pfn = PFN_DOWN(virt_to_phys((void *)PAGE_OFFSET)) + vma->vm_pgoff; Or may be should I substract PAGE_OFFSET from the value I get from System.map before mmapping /dev/kmem? Thanks for your help Regards, Nadia - 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Thu, Jan 18, 2007 at 10:29:14AM +0100, joachim wrote: > Not only has it only been on Nvidia chipsets but we have only seen > reports on the Nvidia CK804 SATA controller. People have reported problems with other controllers. I have one here I can test given a day or so. I don't think it's SATA related, it just happens that it shows up well there, for networking you would end up with the odd corrupted packet probably and end up just dropping those so it might not be noticeable. - 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Thu, Jan 18, 2007 at 04:00:28AM -0700, Erik Andersen wrote: > I just tried again and while using iommu=soft does avoid the > corruption problem, as with previous kernels with 2.6.20-rc5 using > iommu=soft still makes my pcHDTV HD5500 DVB cards not work. i would file a separate bug about that, presumably it won't work in intel based machines too if the driver has dma api bugs - 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] Centralize the macro definition of "__packed".
On Thu, 18 Jan 2007, Robert P. J. Day wrote: > Centralize the attribute macro definition of "__packed" so no > subsystem has to do that explicitly. ummm ... might want to ignore this submission, i want to do some tweaking first. sorry. rday - 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] Consolidate bust_spinlocks()
On Thu, Jan 18, 2007 at 12:39:25PM +0100, Martin Schwidefsky wrote:
> NACK for the s390 part. lib/bust_spinlocks.c does an unblank_screen if
> CONFIG_VT is defined. That is not good enough for s390 because we do not
> have CONFIG_VT nor unblank_screen but still require that console_unblank
> is called.
Martin, are you OK with comments tweaking in s390 code?
-
[PATCH 1/2] Consolidate bust_spinlocks()
From: Kirill Korotaev <[EMAIL PROTECTED]>
Part of long forgotten patch
http://groups.google.com/group/fa.linux.kernel/msg/e98e941ce1cf29f6?dmode=source
Since then, m32r grabbed two copies.
Leave s390 copy because of important absence of CONFIG_VT, but remove
references to non-existent timerlist_lock. ia64 also loses timerlist_lock.
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
arch/i386/mm/fault.c | 26 --
arch/ia64/kernel/traps.c | 30 --
arch/m32r/mm/fault-nommu.c | 26 --
arch/m32r/mm/fault.c | 26 --
arch/s390/mm/fault.c |4 +---
arch/x86_64/mm/fault.c | 21 -
lib/Makefile |4 ++--
lib/bust_spinlocks.c |2 +-
8 files changed, 4 insertions(+), 135 deletions(-)
--- a/arch/i386/mm/fault.c
+++ b/arch/i386/mm/fault.c
@@ -60,32 +60,6 @@ static inline int notify_page_fault(enum
}
/*
- * Unlock any spinlocks which will prevent us from getting the
- * message out
- */
-void bust_spinlocks(int yes)
-{
- int loglevel_save = console_loglevel;
-
- if (yes) {
- oops_in_progress = 1;
- return;
- }
-#ifdef CONFIG_VT
- unblank_screen();
-#endif
- oops_in_progress = 0;
- /*
-* OK, the message is on the console. Now we call printk()
-* without oops_in_progress set so that printk will give klogd
-* a poke. Hold onto your hats...
-*/
- console_loglevel = 15; /* NMI oopser may have shut the console
up */
- printk(" ");
- console_loglevel = loglevel_save;
-}
-
-/*
* Return EIP plus the CS segment base. The segment limit is also
* adjusted, clamped to the kernel/user address space (whichever is
* appropriate), and returned in *eip_limit.
--- a/arch/ia64/kernel/traps.c
+++ b/arch/ia64/kernel/traps.c
@@ -24,8 +24,6 @@ #include
#include
#include
-extern spinlock_t timerlist_lock;
-
fpswa_interface_t *fpswa_interface;
EXPORT_SYMBOL(fpswa_interface);
@@ -53,34 +51,6 @@ trap_init (void)
fpswa_interface = __va(ia64_boot_param->fpswa);
}
-/*
- * Unlock any spinlocks which will prevent us from getting the message out
(timerlist_lock
- * is acquired through the console unblank code)
- */
-void
-bust_spinlocks (int yes)
-{
- int loglevel_save = console_loglevel;
-
- if (yes) {
- oops_in_progress = 1;
- return;
- }
-
-#ifdef CONFIG_VT
- unblank_screen();
-#endif
- oops_in_progress = 0;
- /*
-* OK, the message is on the console. Now we call printk() without
-* oops_in_progress set so that printk will give klogd a poke. Hold
onto
-* your hats...
-*/
- console_loglevel = 15; /* NMI oopser may have shut the console
up */
- printk(" ");
- console_loglevel = loglevel_save;
-}
-
void
die (const char *str, struct pt_regs *regs, long err)
{
--- a/arch/m32r/mm/fault-nommu.c
+++ b/arch/m32r/mm/fault-nommu.c
@@ -46,32 +46,6 @@ #define tlb_entry_i tlb_entry_i_dat[smp_
#define tlb_entry_d tlb_entry_d_dat[smp_processor_id()]
#endif
-/*
- * Unlock any spinlocks which will prevent us from getting the
- * message out
- */
-void bust_spinlocks(int yes)
-{
- int loglevel_save = console_loglevel;
-
- if (yes) {
- oops_in_progress = 1;
- return;
- }
-#ifdef CONFIG_VT
- unblank_screen();
-#endif
- oops_in_progress = 0;
- /*
-* OK, the message is on the console. Now we call printk()
-* without oops_in_progress set so that printk will give klogd
-* a poke. Hold onto your hats...
-*/
- console_loglevel = 15; /* NMI oopser may have shut the console
up */
- printk(" ");
- console_loglevel = loglevel_save;
-}
-
void do_BUG(const char *file, int line)
{
bust_spinlocks(1);
--- a/arch/m32r/mm/fault.c
+++ b/arch/m32r/mm/fault.c
@@ -49,32 +49,6 @@ #endif
extern void init_tlb(void);
-/*
- * Unlock any spinlocks which will prevent us from getting the
- * message out
- */
-void bust_spinlocks(int yes)
-{
- int loglevel_save = console_loglevel;
-
- if (yes) {
- oops_in_progress = 1;
- return;
- }
-#ifdef CONFIG_VT
- unblank_screen();
-#endif
- oops_in_progress = 0;
- /*
-* OK, the message is on the console. Now we call printk()
-
Re: [PATCH] Make CARDBUS_MEM_SIZE and CARDBUS_IO_SIZE customizable
On Thu, 18 Jan 2007, Ralf Baechle wrote: > On Fri, Jan 19, 2007 at 12:23:46AM +0900, Atsushi Nemoto wrote: > > > CARDBUS_MEM_SIZE was increased to 64MB on 2.6.20-rc2, but larger size > > might result in allocation failure for the reserving itself on some > > platforms (for example typical 32bit MIPS). Make it (and > > CARDBUS_IO_SIZE too) customizable for such platforms. > > Patch looks technically ok to me, so feel free to add my Acked-by: > line. > > The grief I have with this sort of patch is that this kind of > detailed technical knowledge should not be required by a mortal > configuring the Linux kernel. that's why help info for options like that should always have a "If you're unsure about what to say here ..." paragraph. i'm big on stuff like that. :-) rday - 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] Make CARDBUS_MEM_SIZE and CARDBUS_IO_SIZE customizable
On Fri, Jan 19, 2007 at 12:23:46AM +0900, Atsushi Nemoto wrote: > CARDBUS_MEM_SIZE was increased to 64MB on 2.6.20-rc2, but larger size > might result in allocation failure for the reserving itself on some > platforms (for example typical 32bit MIPS). Make it (and > CARDBUS_IO_SIZE too) customizable for such platforms. Patch looks technically ok to me, so feel free to add my Acked-by: line. The grief I have with this sort of patch is that this kind of detailed technical knowledge should not be required by a mortal configuring the Linux kernel. Ralf - 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/
Linux kernel - TI 2430 does not boot in nand
Hi, Im using Linux 2.6.14-omap-2430ONLY linux which i downloaded for linux.omap.com (This kernel is a TI specific kernel maintained internally by TI) Im using a TI 2430 SDP board. This kernel, im able to boot in NOR flash, but not in NAND flash. However, im able to boot 2.6.19 in NOR and NAND without any problem. So, i presume, there is no problem with u-boot bootloader. I dont understand why the same kernel with the same bootargs boots in NOR, but not in NAND. All i get is -- OMAP243X SDP # bootm ## Booting image at 8000 ... Image Name: Linux Kernel Image Image Type: ARM Linux Kernel Image (gzip compressed) Data Size:1404634 Bytes = 1.3 MB Load Address: 80c08000 Entry Point: 80c08000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Starting kernel ... Uncompressing Linux.. done, booting the kernel. I dont know how to debug - since, immediately after i get 'booting the kernel' it hangs. how does one debug? Do i need to check any specific configuration option?. Should i need to enable a few options in make menuconfig for nand booting? Any advices, Regards, sriram - 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: Possible ways of dealing with OOM conditions.
On Thu, Jan 18, 2007 at 04:10:52PM +0100, Peter Zijlstra ([EMAIL PROTECTED]) wrote: > On Thu, 2007-01-18 at 16:58 +0300, Evgeniy Polyakov wrote: > > > Network is special in this regard, since it only has one allocation path > > (actually it has one cache for skb, and usual kmalloc, but they are > > called from only two functions). > > > > So it would become > > ptr = network_alloc(); > > and network_alloc() would be usual kmalloc or call for own allocator in > > case of deadlock. > > There is more to networking that skbs only, what about route cache, > there is quite a lot of allocs in this fib_* stuff, IGMP etc... skbs are the most extensively used path. Actually the same is applied to route - dst_entries and rtable are allocated through own wrappers. > > > very high order pages, no? > > > > > > This means that you have to either allocate at boot time and cannot > > > resize/add pools; which means you waste all that memory if the network > > > load never comes near using the reserved amount. > > > > > > Or, you get into all the same trouble the hugepages folks are trying so > > > very hard to solve. > > > > It is configurable - by default it takes pool of 32k pages for allocations > > for > > jumbo-frames (e1000 requires such allocations for 9k frames > > unfortunately), without jumbo-frame support it works with pool of 0-order > > pages, which grows dynamically when needed. > > With 0-order pages, you can only fit 2 1500 byte packets in there, you > could perhaps stick some small skb heads in there as well, but why > bother, the waste isn't _that_ high. > > Esp if you would make a slab for 1500 mtu packets (5*1638 < 2*4096; and > 1638 should be enough, right?) > > It would make sense to pack related objects into a page so you could > free all together. With power-of-two allocation SLAB wastes 500 bytes for each 1500 MTU packet (roughly), it is actaly one ACK packet - and I hear it from person who develops a system, which is aimed to guarantee ACK allocation in OOM :) SLAB overhead is _very_ expensive for network - what if jumbo frame is used? It becomes incredible in that case, although modern NICs allows scatter-gather, which is aimed to fix the problem. Cache misses for small packet flow due to the fact, that the same data is allocated and freed and accessed on different CPUs will become an issue soon, not right now, since two-four core CPUs are not yet to be very popular and price for the cache miss is not _that_ high. > > > > performs self-defragmentation of the memeory, > > > > > > Does it move memory about? > > > > It works in a page, not as pages - when neighbour regions are freed, > > they are combined into single one with bigger size > > Yeah, that is not defragmentation, defragmentation is moving active > regions about to create contiguous free space. What you do is free space > coalescence. That is wrong definition just because no one developed different system. Defragmentation is a result of broken system. Existing design _does_not_ allow to have the situation when whole page belongs to the same cache after it was actively used, the same is applied to the situation when several pages, which create contiguous region, are used by different users, so people start develop VM tricks to move pages around so they would be placed near in address space. Do not fix the result, fix the reason. > > but network stack requires high-order allocations in extremely rare > > cases of broken design (Intel folks, sorry, but your hardware sucks in > > that regard - jumbo frame of 9k should not require 16k of mem plu > > network overhead). > > Well, if you have such hardware its not rare at all, But yeah that > sucks. They do a good jop developing different approaches to workaround that hardware 'feature', but this is still wrong situation. > > NTA also does not align buffers to the power of two - extremely significant > > win of that approach can be found on project's homepage with graps of > > failed allocations and state of the mem for different sizes of > > allocaions. Power-of-two overhead of SLAB is extremely high. > > Sure you can pack the page a little better(*), but I thought the main > advantage was a speed increase. > > (*) memory is generally cheaper than engineering efforts, esp on this > scale. The only advantage in the manual packing is that (with the fancy > hardware stream engine mentioned below) you could ensure they are > grouped together (then again, the hardware stream engine would, together > with a SG-DMA engine, take care of that). Extensoin way of doing things. That is wrong. > > > All it does is try to avoid fragmentation by policy - a problem > > > impossible to solve in general; but can achieve good results in view of > > > practical limitations on program behaviour. > > > > > > Does your policy work for the given workload? we'll see. > > > > > > Also, on what level, each level has both internal and external > > > fragmentation. I can argue that havi
Re: [PATCH] nfs: fix congestion control
On Thu, 2007-01-18 at 14:27 +0100, Peter Zijlstra wrote: > On Wed, 2007-01-17 at 16:54 -0500, Trond Myklebust wrote: > > On Wed, 2007-01-17 at 22:52 +0100, Peter Zijlstra wrote: > > > > > > > > > > > Index: linux-2.6-git/fs/inode.c > > > > > === > > > > > --- linux-2.6-git.orig/fs/inode.c 2007-01-12 08:03:47.0 > > > > > +0100 > > > > > +++ linux-2.6-git/fs/inode.c 2007-01-12 08:53:26.0 +0100 > > > > > @@ -81,6 +81,7 @@ static struct hlist_head *inode_hashtabl > > > > > * the i_state of an inode while it is in use.. > > > > > */ > > > > > DEFINE_SPINLOCK(inode_lock); > > > > > +EXPORT_SYMBOL_GPL(inode_lock); > > > > > > > > Hmmm... Commits to all NFS servers will be globally serialized via the > > > > inode_lock? > > > > > > Hmm, right, thats not good indeed, I can pull the call to > > > nfs_commit_list() out of that loop. > > > > There is no reason to modify any of the commit stuff. Please just drop > > that code. > > I though you agreed to flushing commit pages when hitting the dirty page > limit. After the dirty page has been written to unstable storage, it marks the inode using I_DIRTY_DATASYNC, which should then ensure that the VFS calls write_inode() on the next pass through __sync_single_inode. > Or would you rather see a notifier chain from congestion_wait() calling > into the various NFS mounts? I'd rather like to see fs/fs-writeback.c do this correctly (assuming that it is incorrect now). Trond - 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: [RFC 7/8] Exclude unreclaimable pages from dirty ration calculation
Christoph Lameter writes:
> Consider unreclaimable pages during dirty limit calculation
>
> Tracking unreclaimable pages helps us to calculate the dirty ratio
> the right way. If a large number of unreclaimable pages are allocated
> (through the slab or through huge pages) then write throttling will
> no longer work since the limit cannot be reached anymore.
>
> So we simply subtract the number of unreclaimable pages from the pages
> considered for writeout threshold calculation.
>
> Other code that allocates significant amounts of memory for device
> drivers etc could also be modified to take advantage of this functionality.
I think that simpler solution of this problem is to use only potentially
reclaimable pages (that is, active, inactive, and free pages) to
calculate writeout threshold. This way there is no need to maintain
counters for unreclaimable pages. Below is a patch implementing this
idea, it got some testing.
Nikita.
Fix write throttling to calculate its thresholds from amount of memory that
can be consumed by file system and swap caches, rather than from the total
amount of physical memory. This avoids situations (among other things) when
memory consumed by kernel slab allocator prevents write throttling from ever
happening.
Signed-off-by: Nikita Danilov <[EMAIL PROTECTED]>
mm/page-writeback.c | 33 -
1 files changed, 24 insertions(+), 9 deletions(-)
Index: git-linux/mm/page-writeback.c
===
--- git-linux.orig/mm/page-writeback.c
+++ git-linux/mm/page-writeback.c
@@ -101,6 +101,18 @@ EXPORT_SYMBOL(laptop_mode);
static void background_writeout(unsigned long _min_pages);
+/* Maximal number of pages that can be consumed by pageable caches. */
+static unsigned long total_pageable_pages(void)
+{
+ unsigned long active;
+ unsigned long inactive;
+ unsigned long free;
+
+ get_zone_counts(&active, &inactive, &free);
+ /* +1 to never return 0. */
+ return active + inactive + free + 1;
+}
+
/*
* Work out the current dirty-memory clamping and background writeout
* thresholds.
@@ -127,22 +139,31 @@ get_dirty_limits(long *pbackground, long
int unmapped_ratio;
long background;
long dirty;
- unsigned long available_memory = vm_total_pages;
+ unsigned long total_pages;
+ unsigned long available_memory;
struct task_struct *tsk;
+ available_memory = total_pages = total_pageable_pages();
+
#ifdef CONFIG_HIGHMEM
/*
* If this mapping can only allocate from low memory,
* we exclude high memory from our count.
*/
- if (mapping && !(mapping_gfp_mask(mapping) & __GFP_HIGHMEM))
+ if (mapping && !(mapping_gfp_mask(mapping) & __GFP_HIGHMEM)) {
+ if (available_memory > totalhigh_pages)
available_memory -= totalhigh_pages;
+ else
+ available_memory = 1;
+ }
#endif
unmapped_ratio = 100 - ((global_page_state(NR_FILE_MAPPED) +
global_page_state(NR_ANON_PAGES)) * 100) /
- vm_total_pages;
+ total_pages;
+ if (unmapped_ratio < 0)
+ unmapped_ratio = 0;
dirty_ratio = vm_dirty_ratio;
if (dirty_ratio > unmapped_ratio / 2)
@@ -513,7 +534,7 @@ void laptop_sync_completion(void)
void writeback_set_ratelimit(void)
{
- ratelimit_pages = vm_total_pages / (num_online_cpus() * 32);
+ ratelimit_pages = total_pageable_pages() / (num_online_cpus() * 32);
if (ratelimit_pages < 16)
ratelimit_pages = 16;
if (ratelimit_pages * PAGE_CACHE_SIZE > 4096 * 1024)
@@ -542,7 +563,7 @@ void __init page_writeback_init(void)
long buffer_pages = nr_free_buffer_pages();
long correction;
- correction = (100 * 4 * buffer_pages) / vm_total_pages;
+ correction = (100 * 4 * buffer_pages) / total_pageable_pages();
if (correction < 100) {
dirty_background_ratio *= correction;
-
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] Kwatch: kernel watchpoints using CPU debug registers
On Thu, 18 Jan 2007, Ingo Molnar wrote: > > * Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > > > I'll be happy to move this over to the utrace setting, once it is > > > merged. Do you think it would be better to include the current > > > version of kwatch now or to wait for utrace? > > > > > > Roland, is there a schedule for when you plan to get utrace into > > > -mm? > > > > Even if it goes into mainline soon we'll need a lot of time for all > > architectures to catch up, so I think kwatch should definitely comes > > first. > > i disagree. Utrace is a once-in-a-lifetime opportunity to clean up the > /huge/ ptrace mess. Ptrace has been a very large PITA, for many, many > years, precisely because it was done in the 'oh, lets get this feature > added first, think about it later' manner. Roland's work is a large > logistical undertaking and we should not make it more complex than it > is. Once it's in we can add debugging features ontop of that. To me work > that cleans up existing mess takes precedence before work that adds to > the mess. Interestingly, the current version of utrace makes no special provision for watchpoints, either in kernel or user space. Instead it relies on the legacy ptrace mechanism for setting debug registers in the target process's user area. Perhaps an explicit watchpoint implementation should be added to utrace, but that's beyond the scope of this discussion. Furthermore, utrace is explicitly intended for tracing user programs, not for tracing the kernel. Kwatch, however, is just the opposite: It is intended for setting up watchpoints in kernel space. In that sense it is pretty much orthogonal to utrace. Although it would affect the utrace patches, the changes would be basically transparent (i.e., move the new code from one ptrace handler to another instead of moving the old code). If Kwatch is to be subsumed anywhere, I think it should be under the Kprobes/Systemtap project. Again, that's a separate question -- so far they have avoided data watchpoints. Alan Stern - 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 03/26] Dynamic kernel command-line - arm
On 1/18/07, Russell King <[EMAIL PROTECTED]> wrote: If you want to place a variable in a specific section, it must be explicitly initialised. Eg, static char __initdata command_line[COMMAND_LINE_SIZE] = ""; However, there is a bigger question here: that is the tradeoff between making this variable part of the on-disk kernel image, but throw away the memory at runtime, or to leave it in the BSS where it will not be part of the on-disk kernel image, but will not be thrown away at runtime. This patch is a result of trying to extend the kernel command-line size on x86 to more than 256 bytes. People requested to not allocate a larger buffers for small systems. I don't know who should decide the tradeoff... So what you basically say is that many modules need to be fixed... ./arch/avr32/boards/atstk1000/setup.c ./arch/frv/kernel/setup.c ./arch/i386/kernel/acpi/boot.c ./arch/i386/kernel/mpparse.c ./arch/i386/kernel/setup.c ./arch/ia64/kernel/setup.c Best Regards, Alon Bar-Lev. - 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/
[PATCH] Make CARDBUS_MEM_SIZE and CARDBUS_IO_SIZE customizable
CARDBUS_MEM_SIZE was increased to 64MB on 2.6.20-rc2, but larger size might result in allocation failure for the reserving itself on some platforms (for example typical 32bit MIPS). Make it (and CARDBUS_IO_SIZE too) customizable for such platforms. Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]> --- diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index 3cfb0a3..6085d3d 100644 --- a/drivers/pci/Kconfig +++ b/drivers/pci/Kconfig @@ -60,3 +60,19 @@ config HT_IRQ This allows native hypertransport devices to use interrupts. If unsure say Y. + +config PCI_CARDBUS_IO_SIZE + int "CardBus IO window size (bytes)" + depends on PCI + default "256" + help + A fixed amount of bus space is reserved for CardBus bridges. + The default value is 256 bytes. + +config PCI_CARDBUS_MEM_SIZE + int "CardBus Memory window size (megabytes)" + depends on PCI + default "64" + help + A fixed amount of bus space is reserved for CardBus bridges. + The default value is 64 megabytes. diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index 89f3036..046c87b 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -40,8 +40,8 @@ * FIXME: IO should be max 256 bytes. However, since we may * have a P2P bridge below a cardbus bridge, we need 4K. */ -#define CARDBUS_IO_SIZE(256) -#define CARDBUS_MEM_SIZE (64*1024*1024) +#define CARDBUS_IO_SIZECONFIG_PCI_CARDBUS_IO_SIZE +#define CARDBUS_MEM_SIZE (CONFIG_PCI_CARDBUS_MEM_SIZE * 1024 * 1024) static void __devinit pbus_assign_resources_sorted(struct pci_bus *bus) - 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 03/26] Dynamic kernel command-line - arm
On Thu, Jan 18, 2007 at 04:31:51PM +0100, Tomas Carnecky wrote: > Russell King wrote: > > On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote: > >> -static char command_line[COMMAND_LINE_SIZE]; > >> +static char __initdata command_line[COMMAND_LINE_SIZE]; > > > > Uninitialised data is placed in the BSS. Adding __initdata to BSS > > data causes grief. > > > > Static variables are implicitly initialized to zero. Does that also > count as initialization? No. As I say, they're placed in the BSS. The BSS is zeroed as part of the C runtime initialisation. If you want to place a variable in a specific section, it must be explicitly initialised. Eg, static char __initdata command_line[COMMAND_LINE_SIZE] = ""; However, there is a bigger question here: that is the tradeoff between making this variable part of the on-disk kernel image, but throw away the memory at runtime, or to leave it in the BSS where it will not be part of the on-disk kernel image, but will not be thrown away at runtime. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - 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 03/26] Dynamic kernel command-line - arm
Russell King wrote: > On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote: >> -static char command_line[COMMAND_LINE_SIZE]; >> +static char __initdata command_line[COMMAND_LINE_SIZE]; > > Uninitialised data is placed in the BSS. Adding __initdata to BSS > data causes grief. > Static variables are implicitly initialized to zero. Does that also count as initialization? tom - 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: Possible ways of dealing with OOM conditions.
On Thu, 2007-01-18 at 16:58 +0300, Evgeniy Polyakov wrote: > Network is special in this regard, since it only has one allocation path > (actually it has one cache for skb, and usual kmalloc, but they are > called from only two functions). > > So it would become > ptr = network_alloc(); > and network_alloc() would be usual kmalloc or call for own allocator in > case of deadlock. There is more to networking that skbs only, what about route cache, there is quite a lot of allocs in this fib_* stuff, IGMP etc... > > very high order pages, no? > > > > This means that you have to either allocate at boot time and cannot > > resize/add pools; which means you waste all that memory if the network > > load never comes near using the reserved amount. > > > > Or, you get into all the same trouble the hugepages folks are trying so > > very hard to solve. > > It is configurable - by default it takes pool of 32k pages for allocations for > jumbo-frames (e1000 requires such allocations for 9k frames > unfortunately), without jumbo-frame support it works with pool of 0-order > pages, which grows dynamically when needed. With 0-order pages, you can only fit 2 1500 byte packets in there, you could perhaps stick some small skb heads in there as well, but why bother, the waste isn't _that_ high. Esp if you would make a slab for 1500 mtu packets (5*1638 < 2*4096; and 1638 should be enough, right?) It would make sense to pack related objects into a page so you could free all together. > > > performs self-defragmentation of the memeory, > > > > Does it move memory about? > > It works in a page, not as pages - when neighbour regions are freed, > they are combined into single one with bigger size Yeah, that is not defragmentation, defragmentation is moving active regions about to create contiguous free space. What you do is free space coalescence. > but network stack requires high-order allocations in extremely rare > cases of broken design (Intel folks, sorry, but your hardware sucks in > that regard - jumbo frame of 9k should not require 16k of mem plu > network overhead). Well, if you have such hardware its not rare at all, But yeah that sucks. > NTA also does not align buffers to the power of two - extremely significant > win of that approach can be found on project's homepage with graps of > failed allocations and state of the mem for different sizes of > allocaions. Power-of-two overhead of SLAB is extremely high. Sure you can pack the page a little better(*), but I thought the main advantage was a speed increase. (*) memory is generally cheaper than engineering efforts, esp on this scale. The only advantage in the manual packing is that (with the fancy hardware stream engine mentioned below) you could ensure they are grouped together (then again, the hardware stream engine would, together with a SG-DMA engine, take care of that). > > > All it does is try to avoid fragmentation by policy - a problem > > impossible to solve in general; but can achieve good results in view of > > practical limitations on program behaviour. > > > > Does your policy work for the given workload? we'll see. > > > > Also, on what level, each level has both internal and external > > fragmentation. I can argue that having large immovable objects in memory > > adds to the fragmentation issues on the page-allocator level. > > NTA works with pages, not with contiguous memory, it reduces > fragmentation inside pages, which can not be solved in SLAB, where > objects from the same page can live in different caches and thus _never_ > can be combined. Thus, the only soultuin for SLAB is copy, which is not a > good one for big sizes and is just wrong for big pages. By allocating, and never returning the page to the page-allocator you've increased the fragmentation on the page-allocator level significantly. It will avoid a super page ever forming around that page. > It is not about page moving and VM tricks, which are generally described > as fragmentation avoidance technique, but about how fragmentation > problem is solved in one page. Short of defragmentation (move active regions about) fragmentation is an unsolved problem. For any heuristic there is a pattern that will defeat it. Luckily program allocation behaviour is usually very regular (or decomposable in well behaved groups). > > > is very SMP > > > friendly in that regard that it is per-cpu like slab and never free > > > objects on different CPUs, so they always stay in the same cache. > > > > This makes it very hard to guarantee a reserve limit. (Not impossible, > > just more difficult) > > The whole pool of pages becomes reserve, since no one (and mainly VFS) > can consume that reserve. Ah, but there you violate my requirement, any network allocation can claim the last bit of memory. The whole idea was that the reserve is explicitly managed. It not only needs protection from other users but also from itself. > > > Among other goodies it allows to have full sending/
[PATCH] Centralize the macro definition of "__packed".
Centralize the attribute macro definition of "__packed" so no
subsystem has to do that explicitly.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
compile tested to make sure the HFS subsystem still builds. now
there's just 50 gazillion usages of "__attribute__((packed))" that can
be tightened up.
fs/hfs/hfs.h |2 --
fs/hfsplus/hfsplus_raw.h |2 --
include/linux/compiler-gcc.h |1 +
3 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/fs/hfs/hfs.h b/fs/hfs/hfs.h
index 88099ab..1445e3a 100644
--- a/fs/hfs/hfs.h
+++ b/fs/hfs/hfs.h
@@ -83,8 +83,6 @@
/* HFS structures as they appear on the disk */
-#define __packed __attribute__ ((packed))
-
/* Pascal-style string of up to 31 characters */
struct hfs_name {
u8 len;
diff --git a/fs/hfsplus/hfsplus_raw.h b/fs/hfsplus/hfsplus_raw.h
index 4920553..fe99fe8 100644
--- a/fs/hfsplus/hfsplus_raw.h
+++ b/fs/hfsplus/hfsplus_raw.h
@@ -15,8 +15,6 @@
#include
-#define __packed __attribute__ ((packed))
-
/* Some constants */
#define HFSPLUS_SECTOR_SIZE512
#define HFSPLUS_SECTOR_SHIFT 9
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 6e1c44a..b6e39f5 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -27,6 +27,7 @@
#define __inline__ __inline__ __attribute__((always_inline))
#define __inline __inline__attribute__((always_inline))
#define __deprecated __attribute__((deprecated))
+#define __packed __attribute__((packed))
#define noinline __attribute__((noinline))
#define __attribute_pure__ __attribute__((pure))
#define __attribute_const____attribute__((__const__))
-
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: PROBLEM: writting files > 100 MB in FAT32
"Condor" <[EMAIL PROTECTED]> writes: > I no longer can make tests because i remove my fat32 from my usb stick and > i put it in to FAT16 and i make the exact tests and file is worked but on > fat16 not in fat32. I just report the problem, to be investigate from > kernel developers. Could you send the log of kernel? I'd like to see what the fat driver said. And if you still have the log of dosfsck, please it too. -- OGAWA Hirofumi <[EMAIL PROTECTED]> - 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: Update disable_IO_APIC to use 8-bit destination field (X86_64)
On Thu, 2007-01-18 at 13:30 +0530, Vivek Goyal wrote:
> On Thu, Jan 18, 2007 at 12:10:55AM -0700, Eric W. Biederman wrote:
> > Vivek Goyal <[EMAIL PROTECTED]> writes:
> > >
> > > Or how about making physical_dest field also 8bit like logical_dest field.
> > > This will work both for 4bit and 8bit physical apic ids at the same time
> > > code becomes more intutive and it is easier to know whether IOAPIC is
> > > being
> > > put in physical or destination logical mode.
> >
> > Exactly what I was trying to suggest.
> >
> > Looking closer at the code I think it makes sense to just kill the union and
> > stop the discrimination between physical and logical modes and just have a
> > dest field in the structure. Roughly as you were suggesting at first.
> >
> > The reason we aren't bitten by this on a regular basis is the normal code
> > path uses logical.logical_dest in both logical and physical modes.
> > Which is a little confusing.
> >
> > Since there really isn't a distinction to be made we should just stop
> > trying, which will make maintenance easier :)
> >
> > Currently there are several non-common case users of physical_dest
> > that are probably bitten by this problem under the right
> > circumstances.
> >
> > So I think we should just make the structure:
> >
> > struct IO_APIC_route_entry {
> > __u32 vector : 8,
> > delivery_mode : 3, /* 000: FIXED
> > * 001: lowest prio
> > * 111: ExtINT
> > */
> > dest_mode : 1, /* 0: physical, 1: logical */
> > delivery_status : 1,
> > polarity: 1,
> > irr : 1,
> > trigger : 1, /* 0: edge, 1: level */
> > mask: 1, /* 0: enabled, 1: disabled */
> > __reserved_2: 15;
> >
> > __u32 __reserved_3: 24,
> > __dest : 8;
> > } __attribute__ ((packed));
> >
> > And fixup the users. This should keep us from getting bit by this bug
> > in the future. Like when people start introducing support for more
> > than 256 cores and the low 24bits start getting used.
> >
> > Or when someone new starts working on the code and thinks the fact
> > the field name says logical we are actually using the apic in logical
> > mode.
>
> This makes perfect sense to me. Ben, interested in providing a patch
> for this?
>
> Thanks
> Vivek
Sure! I'll fix it up and get a revised patch out as soon as I can. :)
-- Ben
-
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 03/26] Dynamic kernel command-line - arm
On 1/18/07, Russell King <[EMAIL PROTECTED]> wrote: On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote: > 2. Set command_line as __initdata. You can't. > -static char command_line[COMMAND_LINE_SIZE]; > +static char __initdata command_line[COMMAND_LINE_SIZE]; Uninitialised data is placed in the BSS. Adding __initdata to BSS data causes grief. Thanks for the reply! There are many places in kernel that uses __initdata for uninitialized variables. For example: ./drivers/ide/ide.c:static int __initdata probe_ali14xx; ./drivers/ide/ide.c:static int __initdata probe_umc8672; ./drivers/ide/ide.c:static int __initdata probe_dtc2278; ./drivers/ide/ide.c:static int __initdata probe_ht6560b; ./drivers/ide/ide.c:static int __initdata probe_qd65xx; static int __initdata is_chipset_set[MAX_HWIFS]; So all these current places are wrong? If I initialize the data will it be OK. Best Regards, Alon Bar-Lev. - 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
Erik Andersen wrote: > I just tried again and while using iommu=soft does avoid the > corruption problem, as with previous kernels with 2.6.20-rc5 > using iommu=soft still makes my pcHDTV HD5500 DVB cards not work. > I still have to disable memhole and lose 1 GB. :-( Please add this to the bugreport (http://bugzilla.kernel.org/show_bug.cgi?id=7768) Chris. begin:vcard fn:Mitterer, Christoph Anton n:Mitterer;Christoph Anton email;internet:[EMAIL PROTECTED] x-mozilla-html:TRUE version:2.1 end:vcard
Re: PROBLEM: writting files > 100 MB in FAT32
> On Thu, 2007-01-18 at 11:22 +0200, Condor wrote: >> Hello, >> >> [1.] Files if > 100 MB saving in USB memory stick 4 GB with FAT32. While >> saving all files is broken. > im sorry, i do not understand this. > > you are saying that if you copy files larger than 100mb into drive, all > files die? No, only file when i copy is die. > >> [2.] I have USB memory stick A-DATA 4 GB with FAT32. When i trying to >> save >> files in my USB and files is > of 100 MB, all files that i save is >> broken. >> I put my USB in my laptop and mount it as: mount /dev/sda1 /mnt/usb-win >> While i mount it, i got in my local disk and copy one file that is 520 >> MB. >> The file is copying very slow (10 min). and after i see again my console >> i >> wait light to my usb is off and i unmount it as: umount /mnt/usb-win >> I get my USB stick and when i return to home i trying to copy file from >> my >> USB to my windows and linux. Both OS unable to read file. >> After some tryings i format my USB in FAT16 and now every thing is work >> fine. I copy files to my USB and back to my hard drive and all files >> work >> fine. > > okay, i think thats what you are saying, could you please try to run > dosfsck on it so we can see 100% whats wrong? > Yes, i run and it found error, i also run in windows scan drive, also found errors. I't correct them and i make test again. After copy file (unmount, sync ... ) i insert adapter again in windows and again unable to copy file from usb to windows (linux say may be missing sectors, mount it with read-only), run scan drive from windows and windows again found lost sectors. > also, try to do this: > mount, copy, run command 'sync', unmount, pull out, and see if it works. > Yes this is that i make. > finally, one more question. you said it does not work when you take it > home, can you try this: mount, copy, unmount, mount, check to see if > file works. > Yes i try one of the times and linux say may be sda1 have missing sectors mount it with read-only. > >> [3.] lsmod >> # lsmod > >> nvidia 4709172 22 > ohh, tainted ;P naughty. Though i dont think this affects vfat. > > >> Regards, >> Condor >> >> - >> 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/ >> > > I no longer can make tests because i remove my fat32 from my usb stick and i put it in to FAT16 and i make the exact tests and file is worked but on fat16 not in fat32. I just report the problem, to be investigate from kernel developers. Regards, Condor - 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/
[PATCH] rdmsr_on_cpu, wrmsr_on_cpu
There was OpenVZ specific bug rendering some cpufreq drivers unusable
on SMP. In short, when cpufreq code thinks it confined itself to
needed cpu by means of set_cpus_allowed() to execute rdmsr, some
"virtual cpu" feature can migrate process to anywhere. This triggers
bugons and does wrong things in general.
This got fixed by introducing rdmsr_on_cpu and wrmsr_on_cpu executing
rdmsr and wrmsr on given physical cpu by means of
smp_call_function_single().
Dave Jones mentioned cpufreq might be not only user of rdmsr_on_cpu()
and wrmsr_on_cpu(), so I'm going to put them into arch/i386/lib/
(after patch gets some more testing othen than compile and UP run)
Does this looks OK?
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c | 30 ++--
arch/i386/lib/Makefile |2
arch/i386/lib/msr-on-cpu.c | 70 +
include/asm-i386/msr.h |3 +
4 files changed, 81 insertions(+), 24 deletions(-)
--- a/arch/i386/lib/Makefile
+++ b/arch/i386/lib/Makefile
@@ -7,3 +7,5 @@ lib-y = checksum.o delay.o usercopy.o ge
bitops.o semaphore.o
lib-$(CONFIG_X86_USE_3DNOW) += mmx.o
+
+obj-y = msr-on-cpu.o
--- /dev/null
+++ b/arch/i386/lib/msr-on-cpu.c
@@ -0,0 +1,70 @@
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_SMP
+struct msr_info {
+ u32 msr_no;
+ u32 l, h;
+};
+
+static void __rdmsr_on_cpu(void *info)
+{
+ struct msr_info *rv = info;
+
+ rdmsr(rv->msr_no, rv->l, rv->h);
+}
+
+void rdmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 *l, u32 *h)
+{
+ preempt_disable();
+ if (smp_processor_id() == cpu)
+ rdmsr(msr_no, *l, *h);
+ else {
+ struct msr_info rv;
+
+ rv.msr_no = msr_no;
+ smp_call_function_single(cpu, __rdmsr_on_cpu, &rv, 0, 1);
+ *l = rv.l;
+ *h = rv.h;
+ }
+ preempt_enable();
+}
+
+static void __wrmsr_on_cpu(void *info)
+{
+ struct msr_info *rv = info;
+
+ wrmsr(rv->msr_no, rv->l, rv->h);
+}
+
+void wrmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 l, u32 h)
+{
+ preempt_disable();
+ if (smp_processor_id() == cpu)
+ wrmsr(msr_no, l, h);
+ else {
+ struct msr_info rv;
+
+ rv.msr_no = msr_no;
+ rv.l = l;
+ rv.h = h;
+ smp_call_function_single(cpu, __wrmsr_on_cpu, &rv, 0, 1);
+ }
+ preempt_enable();
+}
+#else
+void rdmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 *l, u32 *h)
+{
+ rdmsr(msr_no, *l, *h);
+}
+
+void wrmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 l, u32 h)
+{
+ wrmsr(msr_no, l, h);
+}
+#endif
+
+EXPORT_SYMBOL(rdmsr_on_cpu);
+EXPORT_SYMBOL(wrmsr_on_cpu);
--- a/include/asm-i386/msr.h
+++ b/include/asm-i386/msr.h
@@ -83,6 +83,9 @@ #define rdpmc(counter,low,high) \
: "c" (counter))
#endif /* !CONFIG_PARAVIRT */
+void rdmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 *l, u32 *h);
+void wrmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 l, u32 h);
+
/* symbolic names for some interesting MSRs */
/* Intel defined MSRs. */
#define MSR_IA32_P5_MC_ADDR0
--- a/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c
+++ b/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c
@@ -63,7 +63,7 @@ static int cpufreq_p4_setdc(unsigned int
if (!cpu_online(cpu) || (newstate > DC_DISABLE) || (newstate ==
DC_RESV))
return -EINVAL;
- rdmsr(MSR_IA32_THERM_STATUS, l, h);
+ rdmsr_on_cpu(cpu, MSR_IA32_THERM_STATUS, &l, &h);
if (l & 0x01)
dprintk("CPU#%d currently thermal throttled\n", cpu);
@@ -71,10 +71,10 @@ static int cpufreq_p4_setdc(unsigned int
if (has_N44_O17_errata[cpu] && (newstate == DC_25PT || newstate ==
DC_DFLT))
newstate = DC_38PT;
- rdmsr(MSR_IA32_THERM_CONTROL, l, h);
+ rdmsr_on_cpu(cpu, MSR_IA32_THERM_CONTROL, &l, &h);
if (newstate == DC_DISABLE) {
dprintk("CPU#%d disabling modulation\n", cpu);
- wrmsr(MSR_IA32_THERM_CONTROL, l & ~(1<<4), h);
+ wrmsr_on_cpu(cpu, MSR_IA32_THERM_CONTROL, l & ~(1<<4), h);
} else {
dprintk("CPU#%d setting duty cycle to %d%%\n",
cpu, ((125 * newstate) / 10));
@@ -85,7 +85,7 @@ static int cpufreq_p4_setdc(unsigned int
*/
l = (l & ~14);
l = l | (1<<4) | ((newstate & 0x7)<<1);
- wrmsr(MSR_IA32_THERM_CONTROL, l, h);
+ wrmsr_on_cpu(cpu, MSR_IA32_THERM_CONTROL, l, h);
}
return 0;
@@ -112,7 +112,6 @@ static int cpufreq_p4_target(struct cpuf
{
unsigned intnewstate = DC_RESV;
struct cpufreq_freqs freqs;
- cpumask_t cpus_allowed;
int i;
if (cpufreq_frequency_table_target(policy, &p4clockmod_table[0],
target_freq, relation, &newstate))
@@ -133,17 +132,8 @@ static int cpufreq_p
Re: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
joachim wrote: > Not only has it only been on Nvidia chipsets but we have only seen > reports on the Nvidia CK804 SATA controller. Please write in or add > yourself to the bugzilla entry [1] and tell us which hardware you have > if you get 4kB pagesize corruption and it goes away with "iommu=soft". How do I find out if I get a 4kB pagesize corruption (or is this the same as "our corruption"? Chris. btw: Should we only post the controller, or other hardware details, too? begin:vcard fn:Mitterer, Christoph Anton n:Mitterer;Christoph Anton email;internet:[EMAIL PROTECTED] x-mozilla-html:TRUE version:2.1 end:vcard
Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
Al Borchers wrote: Thomas Chmielewski wrote: These all unpleasant tasks could be avoided if it was possible to have a "fallback" device. For example, consider this hypothetical command line: root=/dev/sdb1,/dev/sda1 Here is a patch to do this, though it sounds like you might have other solutions. This patch is for 2.6.18.1--thanks to Ed Falk for updating my original 2.6.11 patch. If people are interested I can update and test this on the current kernel. It was tested on 2.6.11. Yes, I'd be interested in a patch against a 2.6.19. It is way simpler to do it this way than to do it with initramfs (although not as flexible). I tried your patch against 2.6.19, with some minor changes (as it wouldn't apply), but it didn't work for me (perhaps I just screwed something). -- Tomasz Chmielewski http://wpkg.org - 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: 2.6.20-rc4-mm1] JFS: Avoid deadlock introduced by explicit I/O plugging
On Thu, 2007-01-18 at 01:30 -0500, Josef Sipek wrote:
> On Wed, Jan 17, 2007 at 04:55:49PM -0600, Dave Kleikamp wrote:
> > /*
> > * jfs_lock.h
> > @@ -42,6 +43,7 @@ do {
> > \
> > if (cond) \
> > break; \
> > unlock_cmd; \
> > + blk_replug_current_nested();\
> > schedule(); \
> > lock_cmd; \
> > } \
>
> Is {,un}lock_cmd a macro? ...
They are the commands passed into this macro (as arguments) to
release/take a lock. This is a home-grown wait_on_event type macro
where the condition must be checked while holding a lock. And the
commands passed in are themselves macros. The jfs code could probably
be cleaned up a bit as far as excessive use of macros for locking, but
it's been working for a few years with few problems.
--
David Kleikamp
IBM Linux Technology Center
-
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 03/26] Dynamic kernel command-line - arm
On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote: > 2. Set command_line as __initdata. You can't. > -static char command_line[COMMAND_LINE_SIZE]; > +static char __initdata command_line[COMMAND_LINE_SIZE]; Uninitialised data is placed in the BSS. Adding __initdata to BSS data causes grief. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - 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/
long disable of Softirqs in br_forward_delay_timer_expired()
Hi I had problems in my implementation of Profibus-protocol, because my FDL-State machine is implemented in tasklets and sometimes there were situations, where Soft-Irqs were disabled for 20-40mS (Coldfire 5485 / 96MHz). After inserting some testpoints in kernels source, doing dump_stack(), when the jiffie-time get longer then 20mS, i detected the place of the long Soft-Irq disable in function static void br_forward_delay_timer_expired(..) inside file "net/bridge/br_stp_timer.c" It does a spin_lock_bh(..); ... some functionality; spin_unlock_bh(..); Does anybody know, why the functionality inbetween lock/unlock takes so long (2-4 jiffies @ HZ=100) Thank You Juergen Pfeiffer, Seskion GmbH Karlsruher Str. 11/1 70771 Leinfelden-Echterdingen Germany [EMAIL PROTECTED] www.seskion.de - 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: What does this scsi error mean ?
On Mon, Jan 15, 2007 at 11:14:52PM +, Alan wrote: > > Both smart and the internal blade diagnostics say "everything is a-ok > > with the drive, there hasn't been any error ever except a bunch of > > corrected ECC ones, and no more than with a similar drive in another > > working blade". Hence my initial post. "Hardware error" is kinda > > imprecise, so I was wondering whether it was unexpected controller > > answer, detected transmission error, block write error, sector not > > found... Is there a way to have more information? > > Well the right place to look would indeed have been the SMART data > providing the drive didn't get into a state it couldn't update it. > Hardware error comes from the drive deciding something is wrong (or a > raid card faking it I guess). That covers everything from power > fluctuations and overheating through firmware consistency failures and > more. > > If you pull the drive and test it in another box does it show the same ? Ok, inverted the disks, got a crash of the same blade with the new disk, so the problem is not the drive itself. Gonna try inverting two blades to check if it's the power supply connector/rail. OG. - 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] Provide an interface to limit total page cache.
Hi! > A patch provide a interface to limit total page cache in > /proc/sys/vm/pagecache_ratio. The default value is 90 > percent. Any > feedback is appreciated. Are you sure percentage is right thing to use? 1% of 200GB machine is 2GB... granularity seems too big here. KB? parts per million? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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/
Possible ways of dealing with OOM conditions.
On Thu, Jan 18, 2007 at 01:18:44PM +0100, Peter Zijlstra ([EMAIL PROTECTED]) wrote: > > > How would that end up being different, I would have to replace all > > > allocations done in the full network processing path. > > > > > > This seems a much less invasive method, all the (allocation) code can > > > stay the way it is and use the normal allocation functions. > > > And acutally we are starting to talk about different approach - having > > separated allocator for network, which will be turned on on OOM (reclaim > > or at any other time). > > I think we might be, I'm more talking about requirements on the > allocator, while you seem to talk about implementations. > > Replacing the allocator, or splitting it in two based on a condition are > all fine as long as they observe the requirements. > > The requirement I add is that there is a reserve nobody touches unless > given express permission. > > You could implement this by modifying each reachable allocator call site > and stick a branch in and use an alternate allocator when the normal > route fails and we do have permission; much like: > >foo = kmalloc(size, gfp_mask); > + if (!foo && special) > +foo = my_alloc(size) Network is special in this regard, since it only has one allocation path (actually it has one cache for skb, and usual kmalloc, but they are called from only two functions). So it would become ptr = network_alloc(); and network_alloc() would be usual kmalloc or call for own allocator in case of deadlock. > And earlier versions of this work did something like that. But it > litters the code quite badly and its quite easy to miss spots. There can > be quite a few allocations in processing network data. > > Hence my work on integrating this into the regular memory allocators. > > FYI; 'special' evaluates to something like: > !(gfp_mask & __GFP_NOMEMALLOC) && > ((gfp_mask & __GFP_EMERGENCY) || >(!in_irq() && (current->flags & PF_MEMALLOC))) > > > > If you do not mind, I would likw to refresh a > > discussion about network tree allocator, > > > which utilizes own pool of > > pages, > > very high order pages, no? > > This means that you have to either allocate at boot time and cannot > resize/add pools; which means you waste all that memory if the network > load never comes near using the reserved amount. > > Or, you get into all the same trouble the hugepages folks are trying so > very hard to solve. It is configurable - by default it takes pool of 32k pages for allocations for jumbo-frames (e1000 requires such allocations for 9k frames unfortunately), without jumbo-frame support it works with pool of 0-order pages, which grows dynamically when needed. > > performs self-defragmentation of the memeory, > > Does it move memory about? It works in a page, not as pages - when neighbour regions are freed, they are combined into single one with bigger size - it would be extended to move pages around to combied them into bigger one though too, but network stack requires high-order allocations in extremely rare cases of broken design (Intel folks, sorry, but your hardware sucks in that regard - jumbo frame of 9k should not require 16k of mem plu network overhead). NTA also does not align buffers to the power of two - extremely significant win of that approach can be found on project's homepage with graps of failed allocations and state of the mem for different sizes of allocaions. Power-of-two overhead of SLAB is extremely high. > All it does is try to avoid fragmentation by policy - a problem > impossible to solve in general; but can achieve good results in view of > practical limitations on program behaviour. > > Does your policy work for the given workload? we'll see. > > Also, on what level, each level has both internal and external > fragmentation. I can argue that having large immovable objects in memory > adds to the fragmentation issues on the page-allocator level. NTA works with pages, not with contiguous memory, it reduces fragmentation inside pages, which can not be solved in SLAB, where objects from the same page can live in different caches and thus _never_ can be combined. Thus, the only soultuin for SLAB is copy, which is not a good one for big sizes and is just wrong for big pages. It is not about page moving and VM tricks, which are generally described as fragmentation avoidance technique, but about how fragmentation problem is solved in one page. > > is very SMP > > friendly in that regard that it is per-cpu like slab and never free > > objects on different CPUs, so they always stay in the same cache. > > This makes it very hard to guarantee a reserve limit. (Not impossible, > just more difficult) The whole pool of pages becomes reserve, since no one (and mainly VFS) can consume that reserve. > > Among other goodies it allows to have full sending/receiving zero-copy. > > That won't ever work unless you have page aligned objects, otherwise you > cannot map them into user-space. Whic
kernel 2.6.19 bug report --> "atkbd.c:spurious ACK on isa...." when boot from SATA hd, no way to start system
When boot with SATA HD --> "atkbd.c:spurious ACK on isa0060/serio0. Some program might be trying access hardware directly." When booting with normal hd no problem. I've searched in changelog but nothing found. more people with this problem: http://iansblog.jandi.co.nz/2006/10/catching-upbleeding-edge.html http://www.linuxquestions.org/questions/showthread.php?t=507224 I use: Debian unstable linux Kernel 2.6.19 on a duron1200 with ata drives and one sata-hd I have got ATA DEVICE SUPPORT AS A MODULE IN the Kernel .CONFIG my system: K7VT4A Pro SATA: 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) Modules: sata_via libsata cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 7 model name : AMD Duron(tm) stepping: 1 cpu MHz : 1198.859 cache size : 64 KB no patches, no fixes in kernel - 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] nfs: fix congestion control
On Wed, 2007-01-17 at 16:54 -0500, Trond Myklebust wrote: > On Wed, 2007-01-17 at 22:52 +0100, Peter Zijlstra wrote: > > > > > > > > Index: linux-2.6-git/fs/inode.c > > > > === > > > > --- linux-2.6-git.orig/fs/inode.c 2007-01-12 08:03:47.0 > > > > +0100 > > > > +++ linux-2.6-git/fs/inode.c2007-01-12 08:53:26.0 +0100 > > > > @@ -81,6 +81,7 @@ static struct hlist_head *inode_hashtabl > > > > * the i_state of an inode while it is in use.. > > > > */ > > > > DEFINE_SPINLOCK(inode_lock); > > > > +EXPORT_SYMBOL_GPL(inode_lock); > > > > > > Hmmm... Commits to all NFS servers will be globally serialized via the > > > inode_lock? > > > > Hmm, right, thats not good indeed, I can pull the call to > > nfs_commit_list() out of that loop. > > There is no reason to modify any of the commit stuff. Please just drop > that code. I though you agreed to flushing commit pages when hitting the dirty page limit. Or would you rather see a notifier chain from congestion_wait() calling into the various NFS mounts? - 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/
[patch 15/26] Dynamic kernel command-line - parisc
1. Rename saved_command_line into boot_command_line.
2. Set command_line as __initdata.
Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]>
---
arch/parisc/kernel/setup.c |8
arch/parisc/mm/init.c |4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
Index: linux-2.6.20-rc4-mm1/arch/parisc/kernel/setup.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/parisc/kernel/setup.c
+++ linux-2.6.20-rc4-mm1/arch/parisc/kernel/setup.c
@@ -45,7 +45,7 @@
#include
#include
-char command_line[COMMAND_LINE_SIZE] __read_mostly;
+char __initdata command_line[COMMAND_LINE_SIZE] __read_mostly;
/* Intended for ccio/sba/cpu statistics under /proc/bus/{runway|gsc} */
struct proc_dir_entry * proc_runway_root __read_mostly = NULL;
@@ -71,9 +71,9 @@ void __init setup_cmdline(char **cmdline
/* boot_args[0] is free-mem start, boot_args[1] is ptr to command line
*/
if (boot_args[0] < 64) {
/* called from hpux boot loader */
- saved_command_line[0] = '\0';
+ boot_command_line[0] = '\0';
} else {
- strcpy(saved_command_line, (char *)__va(boot_args[1]));
+ strcpy(boot_command_line, (char *)__va(boot_args[1]));
#ifdef CONFIG_BLK_DEV_INITRD
if (boot_args[2] != 0) /* did palo pass us a ramdisk? */
@@ -84,7 +84,7 @@ void __init setup_cmdline(char **cmdline
#endif
}
- strcpy(command_line, saved_command_line);
+ strcpy(command_line, boot_command_line);
*cmdline_p = command_line;
}
Index: linux-2.6.20-rc4-mm1/arch/parisc/mm/init.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/parisc/mm/init.c
+++ linux-2.6.20-rc4-mm1/arch/parisc/mm/init.c
@@ -77,12 +77,12 @@ static void __init mem_limit_func(void)
{
char *cp, *end;
unsigned long limit;
- extern char saved_command_line[];
+ extern char __initdata boot_command_line[];
/* We need this before __setup() functions are called */
limit = MAX_MEM;
- for (cp = saved_command_line; *cp; ) {
+ for (cp = boot_command_line; *cp; ) {
if (memcmp(cp, "mem=", 4) == 0) {
cp += 4;
limit = memparse(cp, &end);
--
-
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] futex null pointer timeout
* Pierre Peiffer <[EMAIL PROTECTED]> wrote: > Ingo Molnar a écrit : > >* Daniel Walker <[EMAIL PROTECTED]> wrote: > > > [...] > >>The patch reworks do_futex, and futex_wait* so a NULL pointer in the > >>timeout position is infinite, and anything else is evaluated as a real > >>timeout. > > > >thanks, applied. > > > > On top of this patch, you will need the following patch: futex_lock_pi > is also involved. thanks, applied. (FYI, your mailer added an extra space to every context line in the patch and thus corrupted it, i fixed it up by hand.) Ingo - 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/
[patch 20/26] Dynamic kernel command-line - sh64
1. Rename saved_command_line into boot_command_line.
2. Set command_line as __initdata.
Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]>
Acked-by: Paul Mundt <[EMAIL PROTECTED]>
---
arch/sh64/kernel/setup.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.20-rc4-mm1/arch/sh64/kernel/setup.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/sh64/kernel/setup.c
+++ linux-2.6.20-rc4-mm1/arch/sh64/kernel/setup.c
@@ -83,7 +83,7 @@ extern int sh64_tlb_init(void);
#define RAMDISK_PROMPT_FLAG0x8000
#define RAMDISK_LOAD_FLAG 0x4000
-static char command_line[COMMAND_LINE_SIZE] = { 0, };
+static char __initdata command_line[COMMAND_LINE_SIZE] = { 0, };
unsigned long long memory_start = CONFIG_MEMORY_START;
unsigned long long memory_end = CONFIG_MEMORY_START +
(CONFIG_MEMORY_SIZE_IN_MB * 1024 * 1024);
@@ -95,8 +95,8 @@ static inline void parse_mem_cmdline (ch
int len = 0;
/* Save unparsed command line copy for /proc/cmdline */
- memcpy(saved_command_line, COMMAND_LINE, COMMAND_LINE_SIZE);
- saved_command_line[COMMAND_LINE_SIZE-1] = '\0';
+ memcpy(boot_command_line, COMMAND_LINE, COMMAND_LINE_SIZE);
+ boot_command_line[COMMAND_LINE_SIZE-1] = '\0';
for (;;) {
/*
--
-
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/
[patch 22/26] Dynamic kernel command-line - sparc64
Rename saved_command_line into boot_command_line.
Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]>
---
arch/sparc64/kernel/setup.c |2 +-
arch/sparc64/kernel/sparc64_ksyms.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.20-rc4-mm1/arch/sparc64/kernel/setup.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/sparc64/kernel/setup.c
+++ linux-2.6.20-rc4-mm1/arch/sparc64/kernel/setup.c
@@ -315,7 +315,7 @@ void __init setup_arch(char **cmdline_p)
{
/* Initialize PROM console and command line. */
*cmdline_p = prom_getbootargs();
- strcpy(saved_command_line, *cmdline_p);
+ strcpy(boot_command_line, *cmdline_p);
if (tlb_type == hypervisor)
printk("ARCH: SUN4V\n");
Index: linux-2.6.20-rc4-mm1/arch/sparc64/kernel/sparc64_ksyms.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/sparc64/kernel/sparc64_ksyms.c
+++ linux-2.6.20-rc4-mm1/arch/sparc64/kernel/sparc64_ksyms.c
@@ -253,7 +253,7 @@ EXPORT_SYMBOL(prom_getproplen);
EXPORT_SYMBOL(prom_getproperty);
EXPORT_SYMBOL(prom_node_has_property);
EXPORT_SYMBOL(prom_setprop);
-EXPORT_SYMBOL(saved_command_line);
+EXPORT_SYMBOL(boot_command_line);
EXPORT_SYMBOL(prom_finddevice);
EXPORT_SYMBOL(prom_feval);
EXPORT_SYMBOL(prom_getbool);
--
-
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/
[patch 21/26] Dynamic kernel command-line - sparc
Rename saved_command_line into boot_command_line. Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]> --- arch/sparc/kernel/setup.c |2 +- arch/sparc/kernel/sparc_ksyms.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Index: linux-2.6.20-rc4-mm1/arch/sparc/kernel/setup.c === --- linux-2.6.20-rc4-mm1.orig/arch/sparc/kernel/setup.c +++ linux-2.6.20-rc4-mm1/arch/sparc/kernel/setup.c @@ -246,7 +246,7 @@ void __init setup_arch(char **cmdline_p) /* Initialize PROM console and command line. */ *cmdline_p = prom_getbootargs(); - strcpy(saved_command_line, *cmdline_p); + strcpy(boot_command_line, *cmdline_p); /* Set sparc_cpu_model */ sparc_cpu_model = sun_unknown; Index: linux-2.6.20-rc4-mm1/arch/sparc/kernel/sparc_ksyms.c === --- linux-2.6.20-rc4-mm1.orig/arch/sparc/kernel/sparc_ksyms.c +++ linux-2.6.20-rc4-mm1/arch/sparc/kernel/sparc_ksyms.c @@ -229,7 +229,7 @@ EXPORT_SYMBOL(prom_getproplen); EXPORT_SYMBOL(prom_getproperty); EXPORT_SYMBOL(prom_node_has_property); EXPORT_SYMBOL(prom_setprop); -EXPORT_SYMBOL(saved_command_line); +EXPORT_SYMBOL(boot_command_line); EXPORT_SYMBOL(prom_apply_obio_ranges); EXPORT_SYMBOL(prom_feval); EXPORT_SYMBOL(prom_getbool); -- - 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/
[patch 23/26] Dynamic kernel command-line - um
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]> --- --- arch/um/include/user_util.h |2 +- arch/um/kernel/um_arch.c|2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Index: linux-2.6.20-rc4-mm1/arch/um/include/user_util.h === --- linux-2.6.20-rc4-mm1.orig/arch/um/include/user_util.h +++ linux-2.6.20-rc4-mm1/arch/um/include/user_util.h @@ -38,7 +38,7 @@ extern unsigned long long highmem; extern char host_info[]; -extern char saved_command_line[]; +extern char __initdata boot_command_line[]; extern unsigned long _stext, _etext, _sdata, _edata, __bss_start, _end; extern unsigned long _unprotected_end; Index: linux-2.6.20-rc4-mm1/arch/um/kernel/um_arch.c === --- linux-2.6.20-rc4-mm1.orig/arch/um/kernel/um_arch.c +++ linux-2.6.20-rc4-mm1/arch/um/kernel/um_arch.c @@ -482,7 +482,7 @@ void __init setup_arch(char **cmdline_p) atomic_notifier_chain_register(&panic_notifier_list, &panic_exit_notifier); paging_init(); -strlcpy(saved_command_line, command_line, COMMAND_LINE_SIZE); + strlcpy(boot_command_line, command_line, COMMAND_LINE_SIZE); *cmdline_p = command_line; setup_hostinfo(); } -- - 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/
[patch 10/26] Dynamic kernel command-line - ia64
1. Rename saved_command_line into boot_command_line.
2. Set command_line as __initdata.
Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]>
---
arch/ia64/kernel/efi.c |4 ++--
arch/ia64/kernel/sal.c |4 ++--
arch/ia64/kernel/setup.c |2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
Index: linux-2.6.20-rc4-mm1/arch/ia64/kernel/efi.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/ia64/kernel/efi.c
+++ linux-2.6.20-rc4-mm1/arch/ia64/kernel/efi.c
@@ -413,11 +413,11 @@ efi_init (void)
efi_char16_t *c16;
u64 efi_desc_size;
char *cp, vendor[100] = "unknown";
- extern char saved_command_line[];
+ extern char __initdata boot_command_line[];
int i;
/* it's too early to be able to use the standard kernel command line
support... */
- for (cp = saved_command_line; *cp; ) {
+ for (cp = boot_command_line; *cp; ) {
if (memcmp(cp, "mem=", 4) == 0) {
mem_limit = memparse(cp + 4, &cp);
} else if (memcmp(cp, "max_addr=", 9) == 0) {
Index: linux-2.6.20-rc4-mm1/arch/ia64/kernel/sal.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/ia64/kernel/sal.c
+++ linux-2.6.20-rc4-mm1/arch/ia64/kernel/sal.c
@@ -194,9 +194,9 @@ static void __init
chk_nointroute_opt(void)
{
char *cp;
- extern char saved_command_line[];
+ extern char __initdata boot_command_line[];
- for (cp = saved_command_line; *cp; ) {
+ for (cp = boot_command_line; *cp; ) {
if (memcmp(cp, "nointroute", 10) == 0) {
no_int_routing = 1;
printk ("no_int_routing on\n");
Index: linux-2.6.20-rc4-mm1/arch/ia64/kernel/setup.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/ia64/kernel/setup.c
+++ linux-2.6.20-rc4-mm1/arch/ia64/kernel/setup.c
@@ -463,7 +463,7 @@ setup_arch (char **cmdline_p)
ia64_patch_vtop((u64) __start___vtop_patchlist, (u64)
__end___vtop_patchlist);
*cmdline_p = __va(ia64_boot_param->command_line);
- strlcpy(saved_command_line, *cmdline_p, COMMAND_LINE_SIZE);
+ strlcpy(boot_command_line, *cmdline_p, COMMAND_LINE_SIZE);
efi_init();
io_port_init();
--
-
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/
[patch 24/26] Dynamic kernel command-line - v850
1. Rename saved_command_line into boot_command_line.
2. Set command_line as __initdata.
Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]>
---
---
arch/v850/kernel/setup.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.20-rc4-mm1/arch/v850/kernel/setup.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/v850/kernel/setup.c
+++ linux-2.6.20-rc4-mm1/arch/v850/kernel/setup.c
@@ -42,7 +42,7 @@ extern char _root_fs_image_start __attri
extern char _root_fs_image_end __attribute__ ((__weak__));
-char command_line[COMMAND_LINE_SIZE];
+char __initdata command_line[COMMAND_LINE_SIZE];
/* Memory not used by the kernel. */
static unsigned long total_ram_pages;
@@ -64,8 +64,8 @@ void __init setup_arch (char **cmdline)
{
/* Keep a copy of command line */
*cmdline = command_line;
- memcpy (saved_command_line, command_line, COMMAND_LINE_SIZE);
- saved_command_line[COMMAND_LINE_SIZE - 1] = '\0';
+ memcpy (boot_command_line, command_line, COMMAND_LINE_SIZE);
+ boot_command_line[COMMAND_LINE_SIZE - 1] = '\0';
console_verbose ();
--
-
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/
[patch 04/26] Dynamic kernel command-line - arm26
1. Rename saved_command_line into boot_command_line.
2. Set command_line as __initdata.
Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]>
---
arch/arm26/kernel/setup.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.20-rc4-mm1/arch/arm26/kernel/setup.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/arm26/kernel/setup.c
+++ linux-2.6.20-rc4-mm1/arch/arm26/kernel/setup.c
@@ -80,7 +80,7 @@ unsigned long phys_initrd_size __initdat
static struct meminfo meminfo __initdata = { 0, };
static struct proc_info_item proc_info;
static const char *machine_name;
-static char command_line[COMMAND_LINE_SIZE];
+static char __initdata command_line[COMMAND_LINE_SIZE];
static char default_command_line[COMMAND_LINE_SIZE] __initdata =
CONFIG_CMDLINE;
@@ -492,8 +492,8 @@ void __init setup_arch(char **cmdline_p)
init_mm.end_data = (unsigned long) &_edata;
init_mm.brk= (unsigned long) &_end;
- memcpy(saved_command_line, from, COMMAND_LINE_SIZE);
- saved_command_line[COMMAND_LINE_SIZE-1] = '\0';
+ memcpy(boot_command_line, from, COMMAND_LINE_SIZE);
+ boot_command_line[COMMAND_LINE_SIZE-1] = '\0';
parse_cmdline(&meminfo, cmdline_p, from);
bootmem_init(&meminfo);
paging_init(&meminfo);
--
-
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/
[patch 06/26] Dynamic kernel command-line - cris
1. Rename saved_command_line into boot_command_line.
2. Set cris_command_line as __initdata.
Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]>
---
arch/cris/kernel/setup.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.20-rc4-mm1/arch/cris/kernel/setup.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/cris/kernel/setup.c
+++ linux-2.6.20-rc4-mm1/arch/cris/kernel/setup.c
@@ -29,7 +29,7 @@ struct screen_info screen_info;
extern int root_mountflags;
extern char _etext, _edata, _end;
-char cris_command_line[COMMAND_LINE_SIZE] = { 0, };
+char __initdata cris_command_line[COMMAND_LINE_SIZE] = { 0, };
extern const unsigned long text_start, edata; /* set by the linker script */
extern unsigned long dram_start, dram_end;
@@ -153,8 +153,8 @@ setup_arch(char **cmdline_p)
#endif
/* Save command line for future references. */
- memcpy(saved_command_line, cris_command_line, COMMAND_LINE_SIZE);
- saved_command_line[COMMAND_LINE_SIZE - 1] = '\0';
+ memcpy(boot_command_line, cris_command_line, COMMAND_LINE_SIZE);
+ boot_command_line[COMMAND_LINE_SIZE - 1] = '\0';
/* give credit for the CRIS port */
show_etrax_copyright();
--
-
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/
[patch 19/26] Dynamic kernel command-line - sh
1. Rename saved_command_line into boot_command_line.
2. Set command_line as __initdata.
Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]>
Acked-by: Paul Mundt <[EMAIL PROTECTED]>
---
arch/sh/kernel/setup.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.20-rc4-mm1/arch/sh/kernel/setup.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/sh/kernel/setup.c
+++ linux-2.6.20-rc4-mm1/arch/sh/kernel/setup.c
@@ -75,7 +75,7 @@ static struct sh_machine_vector* __init
#define RAMDISK_PROMPT_FLAG0x8000
#define RAMDISK_LOAD_FLAG 0x4000
-static char command_line[COMMAND_LINE_SIZE] = { 0, };
+static char __initdata command_line[COMMAND_LINE_SIZE] = { 0, };
static struct resource code_resource = { .name = "Kernel code", };
static struct resource data_resource = { .name = "Kernel data", };
@@ -90,8 +90,8 @@ static inline void parse_cmdline (char *
int len = 0;
/* Save unparsed command line copy for /proc/cmdline */
- memcpy(saved_command_line, COMMAND_LINE, COMMAND_LINE_SIZE);
- saved_command_line[COMMAND_LINE_SIZE-1] = '\0';
+ memcpy(boot_command_line, COMMAND_LINE, COMMAND_LINE_SIZE);
+ boot_command_line[COMMAND_LINE_SIZE-1] = '\0';
memory_start = (unsigned long)PAGE_OFFSET+__MEMORY_START;
memory_end = memory_start + __MEMORY_SIZE;
--
-
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/
[patch 01/26] Dynamic kernel command-line - common
1. Rename saved_command_line into boot_command_line, mark
as init disposable.
2. Add dynamic allocated saved_command_line.
3. Add dynamic allocated static_command_line.
4. During startup copy:
boot_command_line into saved_command_line.
arch command_line into static_command_line.
5. Parse static_command_line and not
arch command_line, so arch command_line may
be freed.
Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]>
---
include/linux/init.h |5 +++--
init/main.c | 29 -
2 files changed, 27 insertions(+), 7 deletions(-)
Index: linux-2.6.20-rc4-mm1/include/linux/init.h
===
--- linux-2.6.20-rc4-mm1.orig/include/linux/init.h
+++ linux-2.6.20-rc4-mm1/include/linux/init.h
@@ -67,7 +67,8 @@ extern initcall_t __con_initcall_start[]
extern initcall_t __security_initcall_start[], __security_initcall_end[];
/* Defined in init/main.c */
-extern char saved_command_line[];
+extern char __initdata boot_command_line[];
+extern char *saved_command_line;
extern unsigned int reset_devices;
/* used by init/main.c */
@@ -164,7 +165,7 @@ struct obs_kernel_param {
#define early_param(str, fn) \
__setup_param(str, fn, fn, 1)
-/* Relies on saved_command_line being set */
+/* Relies on boot_command_line being set */
void __init parse_early_param(void);
#endif /* __ASSEMBLY__ */
Index: linux-2.6.20-rc4-mm1/init/main.c
===
--- linux-2.6.20-rc4-mm1.orig/init/main.c
+++ linux-2.6.20-rc4-mm1/init/main.c
@@ -122,8 +122,12 @@ extern void time_init(void);
void (*late_time_init)(void);
extern void softirq_init(void);
-/* Untouched command line (eg. for /proc) saved by arch-specific code. */
-char saved_command_line[COMMAND_LINE_SIZE];
+/* Untouched command line saved by arch-specific code. */
+char __initdata boot_command_line[COMMAND_LINE_SIZE];
+/* Untouched saved command line (eg. for /proc) */
+char *saved_command_line;
+/* Command line for parameter parsing */
+static char *static_command_line;
static char *execute_command;
static char *ramdisk_execute_command;
@@ -406,6 +410,20 @@ static void __init smp_init(void)
#endif
/*
+ * We need to store the untouched command line for future reference.
+ * We also need to store the touched command line since the parameter
+ * parsing is performed in place, and we should allow a component to
+ * store reference of name/value for future reference.
+ */
+static void __init setup_command_line(char *command_line)
+{
+ saved_command_line = alloc_bootmem(strlen (boot_command_line)+1);
+ static_command_line = alloc_bootmem(strlen (command_line)+1);
+ strcpy (saved_command_line, boot_command_line);
+ strcpy (static_command_line, command_line);
+}
+
+/*
* We need to finalize in a non-__init function or else race conditions
* between the root thread and the init thread may cause start_kernel to
* be reaped by free_initmem before the root thread has proceeded to
@@ -459,7 +477,7 @@ void __init parse_early_param(void)
return;
/* All fall through to do_early_param. */
- strlcpy(tmp_cmdline, saved_command_line, COMMAND_LINE_SIZE);
+ strlcpy(tmp_cmdline, boot_command_line, COMMAND_LINE_SIZE);
parse_args("early options", tmp_cmdline, NULL, 0, do_early_param);
done = 1;
}
@@ -509,6 +527,7 @@ asmlinkage void __init start_kernel(void
printk(KERN_NOTICE);
printk(linux_banner);
setup_arch(&command_line);
+ setup_command_line(command_line);
unwind_setup();
setup_per_cpu_areas();
smp_prepare_boot_cpu(); /* arch-specific boot-cpu hooks */
@@ -526,9 +545,9 @@ asmlinkage void __init start_kernel(void
preempt_disable();
build_all_zonelists();
page_alloc_init();
- printk(KERN_NOTICE "Kernel command line: %s\n", saved_command_line);
+ printk(KERN_NOTICE "Kernel command line: %s\n", boot_command_line);
parse_early_param();
- parse_args("Booting kernel", command_line, __start___param,
+ parse_args("Booting kernel", static_command_line, __start___param,
__stop___param - __start___param,
&unknown_bootoption);
if (!irqs_disabled()) {
--
-
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/
[patch 16/26] Dynamic kernel command-line - powerpc
Rename saved_command_line into boot_command_line.
Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/legacy_serial.c |2 +-
arch/powerpc/kernel/prom.c |2 +-
arch/powerpc/kernel/udbg.c |2 +-
arch/powerpc/platforms/powermac/setup.c |4 ++--
4 files changed, 5 insertions(+), 5 deletions(-)
Index: linux-2.6.20-rc4-mm1/arch/powerpc/kernel/legacy_serial.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/powerpc/kernel/legacy_serial.c
+++ linux-2.6.20-rc4-mm1/arch/powerpc/kernel/legacy_serial.c
@@ -498,7 +498,7 @@ static int __init check_legacy_serial_co
DBG(" -> check_legacy_serial_console()\n");
/* The user has requested a console so this is already set up. */
- if (strstr(saved_command_line, "console=")) {
+ if (strstr(boot_command_line, "console=")) {
DBG(" console was specified !\n");
return -EBUSY;
}
Index: linux-2.6.20-rc4-mm1/arch/powerpc/kernel/prom.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/powerpc/kernel/prom.c
+++ linux-2.6.20-rc4-mm1/arch/powerpc/kernel/prom.c
@@ -991,7 +991,7 @@ void __init early_init_devtree(void *par
of_scan_flat_dt(early_init_dt_scan_memory, NULL);
/* Save command line for /proc/cmdline and then parse parameters */
- strlcpy(saved_command_line, cmd_line, COMMAND_LINE_SIZE);
+ strlcpy(boot_command_line, cmd_line, COMMAND_LINE_SIZE);
parse_early_param();
/* Reserve LMB regions used by kernel, initrd, dt, etc... */
Index: linux-2.6.20-rc4-mm1/arch/powerpc/kernel/udbg.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/powerpc/kernel/udbg.c
+++ linux-2.6.20-rc4-mm1/arch/powerpc/kernel/udbg.c
@@ -146,7 +146,7 @@ void __init disable_early_printk(void)
{
if (!early_console_initialized)
return;
- if (strstr(saved_command_line, "udbg-immortal")) {
+ if (strstr(boot_command_line, "udbg-immortal")) {
printk(KERN_INFO "early console immortal !\n");
return;
}
Index: linux-2.6.20-rc4-mm1/arch/powerpc/platforms/powermac/setup.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/powerpc/platforms/powermac/setup.c
+++ linux-2.6.20-rc4-mm1/arch/powerpc/platforms/powermac/setup.c
@@ -506,8 +506,8 @@ void note_bootable_part(dev_t dev, int p
if ((goodness <= current_root_goodness) &&
ROOT_DEV != DEFAULT_ROOT_DEVICE)
return;
- p = strstr(saved_command_line, "root=");
- if (p != NULL && (p == saved_command_line || p[-1] == ' '))
+ p = strstr(boot_command_line, "root=");
+ if (p != NULL && (p == boot_command_line || p[-1] == ' '))
return;
if (!found_boot) {
--
-
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/
[patch 17/26] Dynamic kernel command-line - ppc
Rename saved_command_line into boot_command_line.
Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]>
---
arch/ppc/kernel/setup.c |2 +-
arch/ppc/platforms/lopec.c |2 +-
arch/ppc/platforms/pplus.c |2 +-
arch/ppc/platforms/prep_setup.c |4 ++--
4 files changed, 5 insertions(+), 5 deletions(-)
Index: linux-2.6.20-rc4-mm1/arch/ppc/kernel/setup.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/ppc/kernel/setup.c
+++ linux-2.6.20-rc4-mm1/arch/ppc/kernel/setup.c
@@ -543,7 +543,7 @@ void __init setup_arch(char **cmdline_p)
init_mm.brk = (unsigned long) klimit;
/* Save unparsed command line copy for /proc/cmdline */
- strlcpy(saved_command_line, cmd_line, COMMAND_LINE_SIZE);
+ strlcpy(boot_command_line, cmd_line, COMMAND_LINE_SIZE);
*cmdline_p = cmd_line;
parse_early_param();
Index: linux-2.6.20-rc4-mm1/arch/ppc/platforms/lopec.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/ppc/platforms/lopec.c
+++ linux-2.6.20-rc4-mm1/arch/ppc/platforms/lopec.c
@@ -344,7 +344,7 @@ lopec_setup_arch(void)
if (bootargs != NULL) {
strcpy(cmd_line, bootargs);
/* again.. */
-strcpy(saved_command_line, cmd_line);
+strcpy(boot_command_line, cmd_line);
}
}
#endif
Index: linux-2.6.20-rc4-mm1/arch/ppc/platforms/pplus.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/ppc/platforms/pplus.c
+++ linux-2.6.20-rc4-mm1/arch/ppc/platforms/pplus.c
@@ -592,7 +592,7 @@ static void __init pplus_setup_arch(void
if (bootargs != NULL) {
strcpy(cmd_line, bootargs);
/* again.. */
- strcpy(saved_command_line, cmd_line);
+ strcpy(boot_command_line, cmd_line);
}
}
#endif
Index: linux-2.6.20-rc4-mm1/arch/ppc/platforms/prep_setup.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/ppc/platforms/prep_setup.c
+++ linux-2.6.20-rc4-mm1/arch/ppc/platforms/prep_setup.c
@@ -634,7 +634,7 @@ static void __init prep_init_sound(void)
/*
* Find a way to push these informations to the cs4232 driver
* Give it out with printk, when not in cmd_line?
-* Append it to cmd_line and saved_command_line?
+* Append it to cmd_line and boot_command_line?
* Format is cs4232=io,irq,dma,dma2
*/
}
@@ -897,7 +897,7 @@ prep_setup_arch(void)
if (bootargs != NULL) {
strcpy(cmd_line, bootargs);
/* again.. */
-strcpy(saved_command_line, cmd_line);
+strcpy(boot_command_line, cmd_line);
}
}
--
-
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/
[patch 08/26] Dynamic kernel command-line - h8300
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]> --- arch/h8300/kernel/setup.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Index: linux-2.6.20-rc4-mm1/arch/h8300/kernel/setup.c === --- linux-2.6.20-rc4-mm1.orig/arch/h8300/kernel/setup.c +++ linux-2.6.20-rc4-mm1/arch/h8300/kernel/setup.c @@ -54,7 +54,7 @@ unsigned long rom_length; unsigned long memory_start; unsigned long memory_end; -char command_line[COMMAND_LINE_SIZE]; +char __initdata command_line[COMMAND_LINE_SIZE]; extern int _stext, _etext, _sdata, _edata, _sbss, _ebss, _end; extern int _ramstart, _ramend; @@ -154,8 +154,8 @@ void __init setup_arch(char **cmdline_p) #endif /* Keep a copy of command line */ *cmdline_p = &command_line[0]; - memcpy(saved_command_line, command_line, COMMAND_LINE_SIZE); - saved_command_line[COMMAND_LINE_SIZE-1] = 0; + memcpy(boot_command_line, command_line, COMMAND_LINE_SIZE); + boot_command_line[COMMAND_LINE_SIZE-1] = 0; #ifdef DEBUG if (strlen(*cmdline_p)) -- - 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/
[patch 18/26] Dynamic kernel command-line - s390
Rename saved_command_line into boot_command_line. Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]> --- arch/s390/kernel/setup.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.20-rc4-mm1/arch/s390/kernel/setup.c === --- linux-2.6.20-rc4-mm1.orig/arch/s390/kernel/setup.c +++ linux-2.6.20-rc4-mm1/arch/s390/kernel/setup.c @@ -625,7 +625,7 @@ setup_arch(char **cmdline_p) #endif /* CONFIG_64BIT */ /* Save unparsed command line copy for /proc/cmdline */ - strlcpy(saved_command_line, COMMAND_LINE, COMMAND_LINE_SIZE); + strlcpy(boot_command_line, COMMAND_LINE, COMMAND_LINE_SIZE); *cmdline_p = COMMAND_LINE; *(*cmdline_p + COMMAND_LINE_SIZE - 1) = '\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/
[patch 11/26] Dynamic kernel command-line - m32r
1. Rename saved_command_line into boot_command_line.
2. Set command_line as __initdata.
Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]>
---
arch/m32r/kernel/setup.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.20-rc4-mm1/arch/m32r/kernel/setup.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/m32r/kernel/setup.c
+++ linux-2.6.20-rc4-mm1/arch/m32r/kernel/setup.c
@@ -64,7 +64,7 @@ struct screen_info screen_info = {
extern int root_mountflags;
-static char command_line[COMMAND_LINE_SIZE];
+static char __initdata command_line[COMMAND_LINE_SIZE];
static struct resource data_resource = {
.name = "Kernel data",
@@ -95,8 +95,8 @@ static __inline__ void parse_mem_cmdline
int usermem = 0;
/* Save unparsed command line copy for /proc/cmdline */
- memcpy(saved_command_line, COMMAND_LINE, COMMAND_LINE_SIZE);
- saved_command_line[COMMAND_LINE_SIZE-1] = '\0';
+ memcpy(boot_command_line, COMMAND_LINE, COMMAND_LINE_SIZE);
+ boot_command_line[COMMAND_LINE_SIZE-1] = '\0';
memory_start = (unsigned long)CONFIG_MEMORY_START+PAGE_OFFSET;
memory_end = memory_start+(unsigned long)CONFIG_MEMORY_SIZE;
--
-
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/
[patch 14/26] Dynamic kernel command-line - mips
Rename saved_command_line into boot_command_line. Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]> --- arch/mips/kernel/setup.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.20-rc4-mm1/arch/mips/kernel/setup.c === --- linux-2.6.20-rc4-mm1.orig/arch/mips/kernel/setup.c +++ linux-2.6.20-rc4-mm1/arch/mips/kernel/setup.c @@ -452,7 +452,7 @@ static void __init arch_mem_init(char ** print_memory_map(); strlcpy(command_line, arcs_cmdline, sizeof(command_line)); - strlcpy(saved_command_line, command_line, COMMAND_LINE_SIZE); + strlcpy(boot_command_line, command_line, COMMAND_LINE_SIZE); *cmdline_p = command_line; -- - 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/
[patch 12/26] Dynamic kernel command-line - m68k
Rename saved_command_line into boot_command_line. Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]> --- arch/m68k/kernel/setup.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.20-rc4-mm1/arch/m68k/kernel/setup.c === --- linux-2.6.20-rc4-mm1.orig/arch/m68k/kernel/setup.c +++ linux-2.6.20-rc4-mm1/arch/m68k/kernel/setup.c @@ -256,7 +256,7 @@ void __init setup_arch(char **cmdline_p) init_mm.brk = (unsigned long) &_end; *cmdline_p = m68k_command_line; - memcpy(saved_command_line, *cmdline_p, CL_SIZE); + memcpy(boot_command_line, *cmdline_p, CL_SIZE); /* Parse the command line for arch-specific options. * For the m68k, this is currently only "debug=xxx" to enable printing -- - 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/
[patch 07/26] Dynamic kernel command-line - frv
1. Rename saved_command_line into boot_command_line.
2. Set command_line as __initdata.
Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]>
---
arch/frv/kernel/setup.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.20-rc4-mm1/arch/frv/kernel/setup.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/frv/kernel/setup.c
+++ linux-2.6.20-rc4-mm1/arch/frv/kernel/setup.c
@@ -110,7 +110,7 @@ unsigned long __initdata num_mappedpages
struct cpuinfo_frv __nongprelbss boot_cpu_data;
-char command_line[COMMAND_LINE_SIZE];
+char __initdata command_line[COMMAND_LINE_SIZE];
char __initdata redboot_command_line[COMMAND_LINE_SIZE];
#ifdef CONFIG_PM
@@ -762,7 +762,7 @@ void __init setup_arch(char **cmdline_p)
printk("uClinux FR-V port done by Red Hat Inc <[EMAIL PROTECTED]>\n");
#endif
- memcpy(saved_command_line, redboot_command_line, COMMAND_LINE_SIZE);
+ memcpy(boot_command_line, redboot_command_line, COMMAND_LINE_SIZE);
determine_cpu();
determine_clocks(1);
@@ -803,7 +803,7 @@ void __init setup_arch(char **cmdline_p)
#endif
/* deal with the command line - RedBoot may have passed one to the
kernel */
- memcpy(command_line, saved_command_line, sizeof(command_line));
+ memcpy(command_line, boot_command_line, sizeof(command_line));
*cmdline_p = &command_line[0];
parse_cmdline_early(command_line);
--
-
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/
[patch 13/26] Dynamic kernel command-line - m68knommu
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]> --- arch/m68knommu/kernel/setup.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Index: linux-2.6.20-rc4-mm1/arch/m68knommu/kernel/setup.c === --- linux-2.6.20-rc4-mm1.orig/arch/m68knommu/kernel/setup.c +++ linux-2.6.20-rc4-mm1/arch/m68knommu/kernel/setup.c @@ -44,7 +44,7 @@ unsigned long memory_end; EXPORT_SYMBOL(memory_start); EXPORT_SYMBOL(memory_end); -char command_line[COMMAND_LINE_SIZE]; +char __initdata command_line[COMMAND_LINE_SIZE]; /* setup some dummy routines */ static void dummy_waitbut(void) @@ -231,8 +231,8 @@ void setup_arch(char **cmdline_p) /* Keep a copy of command line */ *cmdline_p = &command_line[0]; - memcpy(saved_command_line, command_line, COMMAND_LINE_SIZE); - saved_command_line[COMMAND_LINE_SIZE-1] = 0; + memcpy(boot_command_line, command_line, COMMAND_LINE_SIZE); + boot_command_line[COMMAND_LINE_SIZE-1] = 0; #ifdef DEBUG if (strlen(*cmdline_p)) -- - 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/
[patch 09/26] Dynamic kernel command-line - i386
1. Rename saved_command_line into boot_command_line.
2. Set command_line as __initdata.
Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]>
---
arch/i386/kernel/head.S |2 +-
arch/i386/kernel/setup.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.20-rc4-mm1/arch/i386/kernel/head.S
===
--- linux-2.6.20-rc4-mm1.orig/arch/i386/kernel/head.S
+++ linux-2.6.20-rc4-mm1/arch/i386/kernel/head.S
@@ -104,7 +104,7 @@ ENTRY(startup_32)
movzwl OLD_CL_OFFSET,%esi
addl $(OLD_CL_BASE_ADDR),%esi
2:
- movl $(saved_command_line - __PAGE_OFFSET),%edi
+ movl $(boot_command_line - __PAGE_OFFSET),%edi
movl $(COMMAND_LINE_SIZE/4),%ecx
rep
movsl
Index: linux-2.6.20-rc4-mm1/arch/i386/kernel/setup.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/i386/kernel/setup.c
+++ linux-2.6.20-rc4-mm1/arch/i386/kernel/setup.c
@@ -133,7 +133,7 @@ unsigned long saved_videomode;
#define RAMDISK_PROMPT_FLAG0x8000
#define RAMDISK_LOAD_FLAG 0x4000
-static char command_line[COMMAND_LINE_SIZE];
+static char __initdata command_line[COMMAND_LINE_SIZE];
unsigned char __initdata boot_params[PARAM_SIZE];
@@ -577,7 +577,7 @@ void __init setup_arch(char **cmdline_p)
print_memory_map("user");
}
- strlcpy(command_line, saved_command_line, COMMAND_LINE_SIZE);
+ strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
*cmdline_p = command_line;
max_low_pfn = setup_memory();
--
-
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/
[patch 25/26] Dynamic kernel command-line - x86_64
1. Rename saved_command_line into boot_command_line.
2. Set command_line as __initdata.
Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]>
---
---
arch/x86_64/kernel/head64.c|4 ++--
arch/x86_64/kernel/setup.c |6 +++---
include/asm-x86_64/bootsetup.h |2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
Index: linux-2.6.20-rc4-mm1/include/asm-x86_64/bootsetup.h
===
--- linux-2.6.20-rc4-mm1.orig/include/asm-x86_64/bootsetup.h
+++ linux-2.6.20-rc4-mm1/include/asm-x86_64/bootsetup.h
@@ -31,7 +31,7 @@ extern char x86_boot_params[BOOT_PARAM_S
#define EDD_MBR_SIG_NR (*(unsigned char *) (PARAM+EDD_MBR_SIG_NR_BUF))
#define EDD_MBR_SIGNATURE ((unsigned int *) (PARAM+EDD_MBR_SIG_BUF))
#define EDD_BUF ((struct edd_info *) (PARAM+EDDBUF))
-#define COMMAND_LINE saved_command_line
+#define COMMAND_LINE boot_command_line
#define RAMDISK_IMAGE_START_MASK 0x07FF
#define RAMDISK_PROMPT_FLAG0x8000
Index: linux-2.6.20-rc4-mm1/arch/x86_64/kernel/head64.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/x86_64/kernel/head64.c
+++ linux-2.6.20-rc4-mm1/arch/x86_64/kernel/head64.c
@@ -34,7 +34,7 @@ static void __init clear_bss(void)
#define OLD_CL_BASE_ADDR0x9
#define OLD_CL_OFFSET 0x90022
-extern char saved_command_line[];
+extern char __initdata boot_command_line[];
static void __init copy_bootdata(char *real_mode_data)
{
@@ -50,7 +50,7 @@ static void __init copy_bootdata(char *r
new_data = OLD_CL_BASE_ADDR + * (u16 *) OLD_CL_OFFSET;
}
command_line = (char *) ((u64)(new_data));
- memcpy(saved_command_line, command_line, COMMAND_LINE_SIZE);
+ memcpy(boot_command_line, command_line, COMMAND_LINE_SIZE);
}
void __init x86_64_start_kernel(char * real_mode_data)
Index: linux-2.6.20-rc4-mm1/arch/x86_64/kernel/setup.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/x86_64/kernel/setup.c
+++ linux-2.6.20-rc4-mm1/arch/x86_64/kernel/setup.c
@@ -100,7 +100,7 @@ EXPORT_SYMBOL_GPL(edid_info);
extern int root_mountflags;
-char command_line[COMMAND_LINE_SIZE];
+char __initdata command_line[COMMAND_LINE_SIZE];
struct resource standard_io_resources[] = {
{ .name = "dma1", .start = 0x00, .end = 0x1f,
@@ -343,7 +343,7 @@ static void discover_ebda(void)
void __init setup_arch(char **cmdline_p)
{
- printk(KERN_INFO "Command line: %s\n", saved_command_line);
+ printk(KERN_INFO "Command line: %s\n", boot_command_line);
ROOT_DEV = old_decode_dev(ORIG_ROOT_DEV);
screen_info = SCREEN_INFO;
@@ -373,7 +373,7 @@ void __init setup_arch(char **cmdline_p)
early_identify_cpu(&boot_cpu_data);
- strlcpy(command_line, saved_command_line, COMMAND_LINE_SIZE);
+ strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
*cmdline_p = command_line;
parse_early_param();
--
-
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/
[patch 05/26] Dynamic kernel command-line - avr32
1. Rename saved_command_line into boot_command_line.
2. Set command_line as __initdata.
Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]>
Acked-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
arch/avr32/kernel/setup.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.20-rc4-mm1/arch/avr32/kernel/setup.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/avr32/kernel/setup.c
+++ linux-2.6.20-rc4-mm1/arch/avr32/kernel/setup.c
@@ -44,7 +44,7 @@ struct avr32_cpuinfo boot_cpu_data = {
};
EXPORT_SYMBOL(boot_cpu_data);
-static char command_line[COMMAND_LINE_SIZE];
+static char __initdata command_line[COMMAND_LINE_SIZE];
/*
* Should be more than enough, but if you have a _really_ complex
@@ -202,7 +202,7 @@ __tagtable(ATAG_MEM, parse_tag_mem);
static int __init parse_tag_cmdline(struct tag *tag)
{
- strlcpy(saved_command_line, tag->u.cmdline.cmdline, COMMAND_LINE_SIZE);
+ strlcpy(boot_command_line, tag->u.cmdline.cmdline, COMMAND_LINE_SIZE);
return 0;
}
__tagtable(ATAG_CMDLINE, parse_tag_cmdline);
@@ -294,7 +294,7 @@ void __init setup_arch (char **cmdline_p
init_mm.end_data = (unsigned long) &_edata;
init_mm.brk = (unsigned long) &_end;
- strlcpy(command_line, saved_command_line, COMMAND_LINE_SIZE);
+ strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
*cmdline_p = command_line;
parse_early_param();
--
-
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/
[patch 26/26] Dynamic kernel command-line - xtensa
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]> --- --- arch/xtensa/kernel/setup.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Index: linux-2.6.20-rc4-mm1/arch/xtensa/kernel/setup.c === --- linux-2.6.20-rc4-mm1.orig/arch/xtensa/kernel/setup.c +++ linux-2.6.20-rc4-mm1/arch/xtensa/kernel/setup.c @@ -78,7 +78,7 @@ extern unsigned long loops_per_jiffy; /* Command line specified as configuration option. */ -static char command_line[COMMAND_LINE_SIZE]; +static char __initdata command_line[COMMAND_LINE_SIZE]; #ifdef CONFIG_CMDLINE_BOOL static char default_command_line[COMMAND_LINE_SIZE] __initdata = CONFIG_CMDLINE; @@ -253,8 +253,8 @@ void __init setup_arch(char **cmdline_p) extern int mem_reserve(unsigned long, unsigned long, int); extern void bootmem_init(void); - memcpy(saved_command_line, command_line, COMMAND_LINE_SIZE); - saved_command_line[COMMAND_LINE_SIZE-1] = '\0'; + memcpy(boot_command_line, command_line, COMMAND_LINE_SIZE); + boot_command_line[COMMAND_LINE_SIZE-1] = '\0'; *cmdline_p = command_line; /* Reserve some memory regions */ -- - 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/
[patch 00/26] Dynamic kernel command-line
This patch has already been posted by Alon Bar-Lev <[EMAIL PROTECTED]> in 2nd Dec 2006. He didn't get any response. Because I think that this patch would be really useful being able to increase the command line, I post this patch again to get some response. This patches are against 2.6.20-rc4-mm1. Current implementation stores a static command-line buffer allocated to COMMAND_LINE_SIZE size. Most architectures stores two copies of this buffer, one for future reference and one for parameter parsing. Current kernel command-line size for most architecture is much too small for module parameters, video settings, initramfs parameters and much more. The problem is that setting COMMAND_LINE_SIZE to a grater value, allocates static buffers. In order to allow a greater command-line size, these buffers should be dynamically allocated or marked as init disposable buffers, so unused memory can be released. This patch renames the static saved_command_line variable into boot_command_line adding __initdata attribute, so that it can be disposed after initialization. This rename is required so applications that use saved_command_line will not be affected by this change. It reintroduces saved_command_line as dynamically allocated buffer to match the data in boot_command_line. It also mark secondary command-line buffer as __initdata, and copies it to dynamically allocated static_command_line buffer components may hold reference to it after initialization. This patch is for linux-2.6.19 and is divided to target each architecture. I could not check this in any architecture so please forgive me if I got it wrong. The per-architecture modification is very simple, use boot_command_line in place of saved_command_line. The common code is the change into dynamic command-line. Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]> - 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/
[patch 03/26] Dynamic kernel command-line - arm
1. Rename saved_command_line into boot_command_line.
2. Set command_line as __initdata.
Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]>
---
arch/arm/kernel/setup.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.20-rc4-mm1/arch/arm/kernel/setup.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/arm/kernel/setup.c
+++ linux-2.6.20-rc4-mm1/arch/arm/kernel/setup.c
@@ -106,7 +106,7 @@ unsigned long phys_initrd_size __initdat
static struct meminfo meminfo __initdata = { 0, };
static const char *cpu_name;
static const char *machine_name;
-static char command_line[COMMAND_LINE_SIZE];
+static char __initdata command_line[COMMAND_LINE_SIZE];
static char default_command_line[COMMAND_LINE_SIZE] __initdata =
CONFIG_CMDLINE;
static union { char c[4]; unsigned long l; } endian_test __initdata = { { 'l',
'?', '?', 'b' } };
@@ -803,8 +803,8 @@ void __init setup_arch(char **cmdline_p)
init_mm.end_data = (unsigned long) &_edata;
init_mm.brk= (unsigned long) &_end;
- memcpy(saved_command_line, from, COMMAND_LINE_SIZE);
- saved_command_line[COMMAND_LINE_SIZE-1] = '\0';
+ memcpy(boot_command_line, from, COMMAND_LINE_SIZE);
+ boot_command_line[COMMAND_LINE_SIZE-1] = '\0';
parse_cmdline(cmdline_p, from);
paging_init(&meminfo, mdesc);
request_standard_resources(&meminfo, mdesc);
--
-
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/
[patch 02/26] Dynamic kernel command-line - alpha
1. Rename saved_command_line into boot_command_line.
2. Set command_line as __initdata.
Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]>
---
arch/alpha/kernel/setup.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.20-rc4-mm1/arch/alpha/kernel/setup.c
===
--- linux-2.6.20-rc4-mm1.orig/arch/alpha/kernel/setup.c
+++ linux-2.6.20-rc4-mm1/arch/alpha/kernel/setup.c
@@ -122,7 +122,7 @@ static void get_sysnames(unsigned long,
char **, char **);
static void determine_cpu_caches (unsigned int);
-static char command_line[COMMAND_LINE_SIZE];
+static char __initdata command_line[COMMAND_LINE_SIZE];
/*
* The format of "screen_info" is strange, and due to early
@@ -547,7 +547,7 @@ setup_arch(char **cmdline_p)
} else {
strlcpy(command_line, COMMAND_LINE, sizeof command_line);
}
- strcpy(saved_command_line, command_line);
+ strcpy(boot_command_line, command_line);
*cmdline_p = command_line;
/*
@@ -589,7 +589,7 @@ setup_arch(char **cmdline_p)
}
/* Replace the command line, now that we've killed it with strsep. */
- strcpy(command_line, saved_command_line);
+ strcpy(command_line, boot_command_line);
/* If we want SRM console printk echoing early, do it now. */
if (alpha_using_srm && srmcons_output) {
--
-
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/
