Re: Kernel SCM saga..
On Thu, 2005-04-07 at 16:27 -0700, Linus Torvalds wrote: On Thu, 7 Apr 2005, Martin Pool wrote: Importing the first snapshot (2004-01-01) took 41.77s user, 1:23.79 total. Each subsequent day takes about 10s user, 30s elapsed to commit into bzr. The speeds are comparable to CVS or a bit faster, and may be faster than other distributed systems. (This on a laptop with a 5400rpm disk.) Pulling out a complete copy of the tree as it was on a previous date takes about 14 user, 60s elapsed. If you have an exportable tree, can you just make it pseudo-public, tell me where to get a buildable system that works well enough, point me to some documentation, and maybe I can get some feel for it? Hi, There is a stable release here: http://www.bazaar-ng.org/pkg/bzr-0.0.3.tgz All you should need to do is unpack that and symlink bzr onto your path. You can get the current bzr development tree, stored in itself, by rsync: rsync -av ozlabs.org::mbp/bzr/dev ~/bzr.dev Inside that directory you can run 'bzr info', 'bzr status --all', 'bzr unknowns', 'bzr log', 'bzr ignored'. Repeated rsyncs will bring you up to date with what I've done -- and will of course overwrite any local changes. If someone was going to development on this then the method would typically be to have two copies of the tree, one tracking my version and another for your own work -- much as with bk. In your own tree, you can do 'bzr add', 'bzr remove', 'bzr diff', 'bzr commit'. At the moment all you can do is diff against the previous revision, or manually diff the two trees, or use quilt, so it is just an archival system not a full SCM system. In the near future there will be some code to extract the differences as changesets to be mailed off. I have done a rough-as-guts import from bkcvs into this, and I can advertise that when it's on a server that can handle the load. At a glance this looks very similar to git -- I can go into the differences and why I did them the other way if you want. -- Martin signature.asc Description: This is a digitally signed message part
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 08 Apr 2005 09:19:39 +0400 Evgeniy Polyakov [EMAIL PROTECTED] wrote: I know, the same thing holds for most architectures, including i386. However, this is not an issue for uni-processor kernels anywhere else, so what's so special about MIPS? Does i386 or ppc has cached and uncached memory? Yes, they do. No, i386, ppc and others do not require sync on uncached memory access, and only instruction not data cache sync on SMP. On MIPS, all the MIPS atomic operations will operate on cached memory. And as far as a uniprocessor cpu is concerned, updating the cache is all that matters. In fact, this SYNC instruction seems unnecessary even on SMP. If the cache is updated, it is part of the coherent memory space and thus MOESI main bus SMP cache coherency transactions will see the update value. When another processor does a read-to-share or read-to-own request on the main bus, the processor which did the atomic OP will provide the correct data from it's cache in response to that transaction. So what you have to do is show me an example where the MIPS kernel can do an atomic.h operation on uncached memory. I even think that is invalid, come to think of it. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 2005-04-08 at 09:19 +0400, Evgeniy Polyakov wrote: On Fri, 2005-04-08 at 15:08 +1000, Herbert Xu wrote: On Fri, Apr 08, 2005 at 09:11:56AM +0400, Evgeniy Polyakov wrote: Yes but what will go wrong on uni-processor MIPS when you don't do the sync in atomic_sub_return? Sync synchornizes cached mamory access, without it new value may be stored only into cache, but not into memory. I know, the same thing holds for most architectures, including i386. However, this is not an issue for uni-processor kernels anywhere else, so what's so special about MIPS? Does i386 or ppc has cached and uncached memory? No, i386, ppc and others do not require sync on uncached memory access, and only instruction not data cache sync on SMP. Ugh, now I see your point :) For UP we may have some nitpics with DMA, but I doubt anyone will use atomic pointer for DMA. sync will not be an issue in atomic ops. Cheers, -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
scancodes to X-Windows
hai all,
The following is the code snippet from drivers/char/keyboard.c
if ((raw_mode = (kbd-kbdmode == VC_RAW))) {
/*
* The following is a workaround for hardware
* which sometimes send the key release event twice
*/
unsigned char next_scancode = scancode|up_flag;
if (up_flag next_scancode==prev_scancode) {
/* unexpected 2nd release event */
} else {
prev_scancode=next_scancode;
put_queue(next_scancode);
}
/* we do not return yet, because we want to maintain
the key_down array, so that we have the correct
values when finishing RAW mode or when changing VT's */
}
I did so much googling, unable find
My doubts are,
1)Is in raw mode also the scancodes are send to tty buffer (as we are
using put_queue() here.
2) whether X will read from tty buffer are will it take scancodes
directly ,in this case where it will store those scancodes,if X is busy doing
some other work.
In the put_queue function
#ifdef CONFIG_FORWARD_KEYBOARD
extern int forward_chars;
void put_queue(int ch)
{
if (forward_chars == fg_console+1){
kbd_forward_char (ch);
} else {
if (tty) {
tty_insert_flip_char(tty, ch, 0);
con_schedule_flip(tty);
}
}
}
Where that kbd_forward_char is defined or what it will do.
what CONFIG_FORWARD_KEYBOARD signifies.
This is not present in my config file,(I am using RH linux 2.4.20)
I got confused of it , if you know about please mail me.
ThanksRegards,
P.Manohar,
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 SCM saga..
Hi, Jan Hudec schrub am Thu, 07 Apr 2005 09:44:08 +0200:
1) GNU Arch/Bazaar. They use the same archive format, simple, have the
concepts right. It may need some scripts or add ons. When Bazaar-NG is
ready, it will be able to read the GNU Arch/Bazaar archives so
switching should be easy.
Plus Bazaar has multiple implementations (C and Python). Plus arch can
trivially export single patches. Plus ... well, you get the idea. ;-)
Linus: Care to share your SCM feature requirement list?
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [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] Dynamic Tick version 050406-1
* Alexander Nyberg [EMAIL PROTECTED] [050407 02:31]: Here's an updated dyn-tick patch. Some minor fixes: Doesn't look so good here. I get this with 2.6.12-rc2 (plus a few other patches). Disabling Dynamic Tick makes everything happy again (it boots). [4294688.655000] Unable to handle kernel NULL pointer dereference at virtual address Thanks for trying it out. What kind of hardware do you have? Does it have HPET? It looks like no suitable timer for dyn-tick is found... Maybe the following patch helps? = arch/i386/kernel/Makefile 1.67 vs edited = --- 1.67/arch/i386/kernel/Makefile2005-01-26 06:21:13 +01:00 +++ edited/arch/i386/kernel/Makefile 2005-04-07 11:21:19 +02:00 @@ -32,6 +32,7 @@ obj-$(CONFIG_ACPI_SRAT) += srat.o obj-$(CONFIG_HPET_TIMER) += time_hpet.o obj-$(CONFIG_EFI)+= efi.o efi_stub.o obj-$(CONFIG_EARLY_PRINTK) += early_printk.o +obj-$(CONFIG_NO_IDLE_HZ) += dyn-tick.o EXTRA_AFLAGS := -traditional Ah, that explains :) Thanks! Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] Dynamic Tick version 050406-1
* Frank Sorenson [EMAIL PROTECTED] [050407 15:21]: Frank Sorenson wrote: Tony Lindgren wrote: Thanks for trying it out. What kind of hardware do you have? Does it have HPET? It looks like no suitable timer for dyn-tick is found... Maybe the following patch helps? Tony Does 'different crash' qualify as helping? :) Update: The patch does seem to fix the crash. This different crash I mentioned appears to be related to the netconsole I was using (serial console produces stairstepping text, netconsole seems to duplicate lines--go figure). Without netconsole, dynamic tick appears to be working, so I'm not sure whether this is a netconsole bug or a dynamic tick bug. This might be because time does not run correctly, see below. While dynamic tick no longer panics, with dynamic tick, my system slows to whatever is slower than a crawl. It now takes 6 minutes 50 seconds to boot all the way up, compared to 1 minute 35 seconds with my 2.6.12 kernel without the dynamic tick patch. I'm not sure where this slowdown is occurring yet. I think I have an idea on what's going on; Your system does not wake to APIC interrupt, and the system timer updates time only on other interrupts. I'm experiencing the same on a loaner ThinkPad T30. I'll try to do another patch today. Meanwhile it now should work without lapic in cmdline. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] Priority Lists for the RT mutex
* Daniel Walker [EMAIL PROTECTED] wrote: This patch adds the priority list data structure from Inaky Perez-Gonzalez to the Preempt Real-Time mutex. this one looks really clean. it makes me wonder, what is the current status of fusyn's? Such a light datastructure would be much more mergeable upstream than the former 100-queues approach. 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/
Re: Linux 2.6.12-rc2
FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, except that neither returns from suspend-to-ram with video restored on the LCD. I believe I was able to get video restored on an external CRT in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't restore (can verify later today, if you'd like). I had dumped out the radeontool regs values before after the sleep, in case they help. They are attached. Hmm... I have 2.6.12-rc2 on a T41 and suspend to ram works good (well except for a backtrace complaining about __might_sleep but otherwise ok). Apr 7 23:17:10 localhost kernel: Debug: sleeping function called from invalid context at mm/slab.c:2090 Apr 7 23:17:10 localhost kernel: in_atomic():0, irqs_disabled():1 Apr 7 23:17:10 localhost kernel: [c011d9e3] __might_sleep+0xa3/0xc0 Apr 7 23:17:10 localhost kernel: [c015beb0] kmem_cache_alloc+0x50/0x60 Apr 7 23:17:10 localhost kernel: [c0269750] acpi_pci_link_set+0x4a/0x1a2 Apr 7 23:17:10 localhost kernel: [c0269bc9] irqrouter_resume+0x1c/0x24 Apr 7 23:17:10 localhost kernel: [c02b70f6] sysdev_resume+0x66/0xc4 Apr 7 23:17:10 localhost kernel: [c02bbcc5] device_power_up+0x5/0xa Apr 7 23:17:10 localhost kernel: [c014a426] suspend_enter+0x36/0x60 Apr 7 23:17:10 localhost kernel: [c014a3a3] suspend_prepare+0x63/0xb0 Apr 7 23:17:10 localhost kernel: [c014a4ec] enter_state+0x5c/0x70 Apr 7 23:17:10 localhost kernel: [c014a639] state_store+0xa9/0xbc Apr 7 23:17:10 localhost kernel: [c014a590] state_store+0x0/0xbc Apr 7 23:17:10 localhost kernel: [c01d27c6] subsys_attr_store+0x36/0x50 Apr 7 23:17:10 localhost kernel: [c01d2a6e] flush_write_buffer+0x2e/0x40 Apr 7 23:17:10 localhost kernel: [c01d2ace] sysfs_write_file+0x4e/0x80 Apr 7 23:17:10 localhost kernel: [c017bdee] vfs_write+0x12e/0x130 Apr 7 23:17:10 localhost kernel: [c017bea1] sys_write+0x41/0x70 Apr 7 23:17:10 localhost kernel: [c01039ff] sysenter_past_esp+0x54/0x75 I posted these problems in the Call for help S3 thread, but no one responded. Thanks, Nish - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: VST and Sched Load Balance
Srivatsa Vaddagiri wrote: On Thu, Apr 07, 2005 at 05:10:24PM +0200, Ingo Molnar wrote: Interaction with VST is not a big issue right now because this only matters on SMP boxes which is a rare (but not unprecedented) target for embedded platforms. Well, I don't think VST is targetting just power management in embedded platforms. Even (virtualized) servers will benefit from this patch, by making use of the (virtual) CPU resources more efficiently. I still think looking at just using the rebalance backoff would be a good start. What would be really nice is to measure the power draw on your favourite SMP system with your current patches that *don't* schedule ticks to service rebalancing. Then measure again with the current rebalance backoff settings (which will likely be not very good, because some intervals are constrained to quite small values). Then we can aim for something like 80-90% of the first (ie perfect) efficiency rating. -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
accessing i2c-driver
Hi, i want to write an application to access the i2c-matroxfb driver. can anybody tell me how to start with ie if u r accessing a char driver similar to File ie first we have to opne the driver, then when we call read it call the driver specific read etc. Likewise how can i write one application to check what is happening in i2c-matroxfb module. if anybody got anyidea regarding this please mail me. Karthik - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: Linux 2.6.12-rc2
Err... never mind... I was not doing any radeon control. On Apr 8, 2005 11:58 AM, AsterixTheGaul [EMAIL PROTECTED] wrote: FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, except that neither returns from suspend-to-ram with video restored on the LCD. I believe I was able to get video restored on an external CRT in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't restore (can verify later today, if you'd like). I had dumped out the radeontool regs values before after the sleep, in case they help. They are attached. Hmm... I have 2.6.12-rc2 on a T41 and suspend to ram works good (well except for a backtrace complaining about __might_sleep but otherwise ok). Apr 7 23:17:10 localhost kernel: Debug: sleeping function called from invalid context at mm/slab.c:2090 Apr 7 23:17:10 localhost kernel: in_atomic():0, irqs_disabled():1 Apr 7 23:17:10 localhost kernel: [c011d9e3] __might_sleep+0xa3/0xc0 Apr 7 23:17:10 localhost kernel: [c015beb0] kmem_cache_alloc+0x50/0x60 Apr 7 23:17:10 localhost kernel: [c0269750] acpi_pci_link_set+0x4a/0x1a2 Apr 7 23:17:10 localhost kernel: [c0269bc9] irqrouter_resume+0x1c/0x24 Apr 7 23:17:10 localhost kernel: [c02b70f6] sysdev_resume+0x66/0xc4 Apr 7 23:17:10 localhost kernel: [c02bbcc5] device_power_up+0x5/0xa Apr 7 23:17:10 localhost kernel: [c014a426] suspend_enter+0x36/0x60 Apr 7 23:17:10 localhost kernel: [c014a3a3] suspend_prepare+0x63/0xb0 Apr 7 23:17:10 localhost kernel: [c014a4ec] enter_state+0x5c/0x70 Apr 7 23:17:10 localhost kernel: [c014a639] state_store+0xa9/0xbc Apr 7 23:17:10 localhost kernel: [c014a590] state_store+0x0/0xbc Apr 7 23:17:10 localhost kernel: [c01d27c6] subsys_attr_store+0x36/0x50 Apr 7 23:17:10 localhost kernel: [c01d2a6e] flush_write_buffer+0x2e/0x40 Apr 7 23:17:10 localhost kernel: [c01d2ace] sysfs_write_file+0x4e/0x80 Apr 7 23:17:10 localhost kernel: [c017bdee] vfs_write+0x12e/0x130 Apr 7 23:17:10 localhost kernel: [c017bea1] sys_write+0x41/0x70 Apr 7 23:17:10 localhost kernel: [c01039ff] sysenter_past_esp+0x54/0x75 I posted these problems in the Call for help S3 thread, but no one responded. Thanks, Nish - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 SCM saga..
On Fri, 8 Apr 2005, Martin Pool wrote: You can get the current bzr development tree, stored in itself, by rsync: I was thinking more of an exportable kernel tree in addition to the tool. The reason I mention that is just that I know several SCM's bog down under load horribly, so it actually matters what the size of the tree is. And I'm absolutely _not_ asking you for the 60,000 changesets that are in the BK tree, I'd be prfectly happy with a 2.6.12-rc2-based one for testing. I know I can import things myself, but the reason I ask is because I've got several SCM's I should check out _and_ I've been spending the last two days writing my own fallback system so that I don't get screwed if nothing out there works right now. Which is why I'd love to hear from people who have actually used various SCM's with the kernel. There's bound to be people who have already tried. I've gotten a lot of email of the kind I love XYZ, you should try it out, but so far I've not seen anybody say I've tracked the kernel with XYZ, and it does ... So, this is definitely not a Martin Pool should do this kind of issue: I'd like many people to test out many alternatives, to get a feel for where they are especially for a project the size of the kernel.. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 2005-04-08 at 01:55 -0400, James Morris wrote: On Fri, 8 Apr 2005, Evgeniy Polyakov wrote: Sure, but seems I need to ask again: What is the exact reason not to implement the muticast message multiplexing/subscription part of the connector as a generic part of netlink? That would be nice to have and useful for other subsystems too as an option to the current broadcast. This is a good point, in general, consider generically extending Netlink itself instead of creating these separate things. Connector requires it's own registration technique for 1. hide all transport [netlink] layer from higher protocols which use connector Why? User should not know about low-level transport - it is like socket layer - write only data and do not care about how it will be delivered. 2. create different group appointment for the given connector's ID [it was different, now new group which is eqal to idx field is appointed to the new callback] I don't understand. In the previous versions netlink group was assigned as incremented counter, that was not convenient, but now we have 2-way ID, which is better from users point of view - idx is supposed to be major id, val - some subsystem of that set. 3. provide more generic set of ids What do you mean by ids? Each connector message requires pair of u32 ids - idx and val. Idx is generic system id [which is equal to the appropriate netlink group in current implementation], while val is id of some subsytem inside idx. Using only group without it's own connector's id will heavily complex callback register/unregister notification [Jamal's suggested feature] for example. - James -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 09:06:58PM -0600, Eric W. Biederman wrote: Sven Luther [EMAIL PROTECTED] writes: It sounds like you are now looking at the question of are the huge string of hex characters the preferred form for making modifications to firmware. Personally I would be surprised but those hunks are small enough it could have been written in machine code. Yep, i also think it is in broadcom's best interest to modify the licencing text accordyingly, since i suppose someone could technicaly come after them legally to obtain said source code to this firmware. Unprobable though. Possibly. It sounds like that is what you want to do. No, i am making them aware of the possibility, and hoping they fix the issue, but we will see. If they fail to act on this, i don't understand why though, since it is just addition of a clarification. It is not as if i am asking for the release of all their chip specs or something such. since there should be at least some kind of executable code in it, independenlty of the fact that we claim that data is also software. Do you have any evidence that ``software'' was not written directly in machine code? Software is written directly in machine code when a programmer So what, i seriously doubt they where written using an vi in C, as the code currently stands, so we do need an additional level of source code, being it only some asm code or something. looks at the instruction set and writes down the binary representation of the instructions. I know ISC dhcpd has packet filter code that was written in that manner, so it is not a lost art. And it is done often enough when an assembler will not cooperate, and generate the correct instruction. But again, this is not the common assumption, so if this is so, they should write it down black on white in the copyright notice, and everyone would be happy. Without evidence that we don't have the preferred form of the software for making modifications I don't see how you can complain. No, it goes the other way around. Without evidence that all is clean, we have no right to distribute that code, and if what you describe was the case, a couple of lines telling us that fact would solve the issue, and not even need the involvement of their legal department. I would be somewhat suspisious though if all these guys came up and said they just wrote said firmware in binary directly though. Friendly, Sven Luther - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Dual Opteron / Kernel Panic
Hi all, today I got the following messages on one of our dual Opteron servers: Apr 8 08:40:21 dslxs01neu kernel: CPU 1: Machine Check Exception: 0007 Apr 8 08:40:21 dslxs01neu kernel: Bank 4: f47520009c080a13 at 0001e89ccdf0 Apr 8 08:40:21 dslxs01neu kernel: Kernel panic: Unable to continue Apr 8 08:40:21 dslxs01neu kernel: klogd 1.4.1, -- state change -- Apr 8 08:40:21 dslxs01neu kernel: Inspecting /boot/System.map-2.4.21-286-smp Apr 8 08:40:25 dslxs01neu kernel: Loaded 22027 symbols from /boot/System.map-2.4.21-286-smp. Apr 8 08:40:25 dslxs01neu kernel: Symbols match kernel version 2.4.21. Apr 8 08:40:25 dslxs01neu kernel: Loaded 588 symbols from 21 modules. The machine is still up and running, but 'Kernel panic' seems to be something serious ;-) Can some tell me what these messages mean ? Thanks a lot, Marco Schwarz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: /dev/random problem on 2.6.12-rc1
On Thu, 7 Apr 2005, Matt Mackall wrote: On Thu, Apr 07, 2005 at 05:36:59PM +0200, Simon Derr wrote: On Thu, 7 Apr 2005, Yura Pakhuchiy wrote: On Thu, 2005-04-07 at 14:40 +0200, Patrice Martinez wrote: When using a machine with a 2612-rc 1kernel, I encounter problems reading /dev/random: it simply nevers returns anything, and the process is blocked in the read... The easiest way to see it is to type: od /dev/random Any idea? Because, /dev/random use user input, mouse movements and other things to generate next random number. Use /dev/urandom if you want version that will never block your machine. Read man 4 random for details. Something changed since previous versions of the kernel, I guess. Running `find /usr | wc' on a ssh session generates both network and disk activity, and you should not expect any other kind of input on a networked server. Oops, the command is actually find /usr | xargs wc, witch causes lots of disk activity. FYI, network activity only generates entropy on a very small subset of NICs, and probably not the one you're using. This is good, as network activity is assumed passively observable/timable. Offtopic, but why isn't the policy the same for all NICs ? Anyway, still zero bytes coming from /dev/random, for the few minutes I waited. Are you and Patrice both experiencing this on the same machine? Both IA-64, but that's the only common point. What was the last kernel that was known to work for you? Do you see the contents of /proc/sys/kernel/random/entropy_avail change over time? Are there any other entropy consumers on your machine? None that I am aware of. I run: # dd if=/dev/random bs=1 count=1 | od Another shell: # lsof /dev/random COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME dd 1496 root0r CHR1,8 99952 /dev/random Now, find /usr | xargs wc running in background. About /proc/sys/kernel/random/entropy_avail: (5 second refresh interval) 0 0 0 0 [lots of 0] 0 0 0 6 0 8 2 0 0 [lots of 0] 0 0 0 3 1 0 0 [lots of 0] 0 0 0 ... After 10 minutes, dd is still running. This is on Linux 2.6.12-rc1-bk1, same results for 2.6.12-rc2. And /dev/random works fine on the same machine with Linux 2.6.11. (i.e when running find /usr | xargs wc, /dev/random spits out lots of bytes) Simon. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: Linux 2.6.12-rc2
Ok this time I did with radeontool and it works good :)) (2.6.12-rc2 on T41). 1. I have radeontool regs before susp to ram (presusp) 2. turn off LCD with radeontool light off 3. Suspend to RAM and wake up. (same backtrace) 4. LCD is back on (no problem) 5. regs in postsusp only diff is RADEON_CRTC_GEN_CNTL=03200600 --- RADEON_CRTC_GEN_CNTL=03000600 presusp --- RADEON_DAC_CNTL=ff002102 RADEON_DAC_CNTL2= RADEON_TV_DAC_CNTL=07680142 RADEON_DISP_OUTPUT_CNTL=1002 RADEON_CONFIG_MEMSIZE=0200 RADEON_AUX_SC_CNTL= RADEON_CRTC_EXT_CNTL=8048 RADEON_CRTC_GEN_CNTL=03200600 RADEON_CRTC2_GEN_CNTL=0080 RADEON_DEVICE_ID=4c66 RADEON_DISP_MISC_CNTL=5b300600 RADEON_GPIO_MONID= RADEON_GPIO_MONIDB=0300 RADEON_GPIO_CRT2_DDC=0300 RADEON_GPIO_DVI_DDC=0013 RADEON_GPIO_VGA_DDC=0003 RADEON_LVDS_GEN_CNTL=003dffa1 postsusp --- RADEON_DAC_CNTL=ff002102 RADEON_DAC_CNTL2= RADEON_TV_DAC_CNTL=07680142 RADEON_DISP_OUTPUT_CNTL=1002 RADEON_CONFIG_MEMSIZE=0200 RADEON_AUX_SC_CNTL= RADEON_CRTC_EXT_CNTL=8048 RADEON_CRTC_GEN_CNTL=03000600 RADEON_CRTC2_GEN_CNTL=0080 RADEON_DEVICE_ID=4c66 RADEON_DISP_MISC_CNTL=5b300600 RADEON_GPIO_MONID= RADEON_GPIO_MONIDB=0300 RADEON_GPIO_CRT2_DDC=0300 RADEON_GPIO_DVI_DDC=0013 RADEON_GPIO_VGA_DDC=0003 RADEON_LVDS_GEN_CNTL=003dffa1 On Apr 8, 2005 12:09 PM, AsterixTheGaul [EMAIL PROTECTED] wrote: Err... never mind... I was not doing any radeon control. On Apr 8, 2005 11:58 AM, AsterixTheGaul [EMAIL PROTECTED] wrote: FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, except that neither returns from suspend-to-ram with video restored on the LCD. I believe I was able to get video restored on an external CRT in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't restore (can verify later today, if you'd like). I had dumped out the radeontool regs values before after the sleep, in case they help. They are attached. Hmm... I have 2.6.12-rc2 on a T41 and suspend to ram works good (well except for a backtrace complaining about __might_sleep but otherwise ok). Apr 7 23:17:10 localhost kernel: Debug: sleeping function called from invalid context at mm/slab.c:2090 Apr 7 23:17:10 localhost kernel: in_atomic():0, irqs_disabled():1 Apr 7 23:17:10 localhost kernel: [c011d9e3] __might_sleep+0xa3/0xc0 Apr 7 23:17:10 localhost kernel: [c015beb0] kmem_cache_alloc+0x50/0x60 Apr 7 23:17:10 localhost kernel: [c0269750] acpi_pci_link_set+0x4a/0x1a2 Apr 7 23:17:10 localhost kernel: [c0269bc9] irqrouter_resume+0x1c/0x24 Apr 7 23:17:10 localhost kernel: [c02b70f6] sysdev_resume+0x66/0xc4 Apr 7 23:17:10 localhost kernel: [c02bbcc5] device_power_up+0x5/0xa Apr 7 23:17:10 localhost kernel: [c014a426] suspend_enter+0x36/0x60 Apr 7 23:17:10 localhost kernel: [c014a3a3] suspend_prepare+0x63/0xb0 Apr 7 23:17:10 localhost kernel: [c014a4ec] enter_state+0x5c/0x70 Apr 7 23:17:10 localhost kernel: [c014a639] state_store+0xa9/0xbc Apr 7 23:17:10 localhost kernel: [c014a590] state_store+0x0/0xbc Apr 7 23:17:10 localhost kernel: [c01d27c6] subsys_attr_store+0x36/0x50 Apr 7 23:17:10 localhost kernel: [c01d2a6e] flush_write_buffer+0x2e/0x40 Apr 7 23:17:10 localhost kernel: [c01d2ace] sysfs_write_file+0x4e/0x80 Apr 7 23:17:10 localhost kernel: [c017bdee] vfs_write+0x12e/0x130 Apr 7 23:17:10 localhost kernel: [c017bea1] sys_write+0x41/0x70 Apr 7 23:17:10 localhost kernel: [c01039ff] sysenter_past_esp+0x54/0x75 I posted these problems in the Call for help S3 thread, but no one responded. Thanks, Nish - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] PCI Hotplug: remove code duplication in drivers/pci/hotplug/ibmphp_pci.c
Greg KH wrote: On Sat, Apr 02, 2005 at 02:20:11PM +0200, Rolf Eike Beer wrote: Greg KH wrote: ChangeSet 1.2181.16.9, 2005/03/17 13:54:33-08:00, [EMAIL PROTECTED] [PATCH] PCI Hotplug: remove code duplication in drivers/pci/hotplug/ibmphp_pci.c This patch removes some code duplication where if and else have the same code at the beginning and the end of the branch. Greg, as you correctly pointed out this patch if broken. It could never reach the if branch and always uses the else branch. Please drop this one and review the patch I sent on March 21th to pcihp-discuss for inclusion. It removes much more duplication and handles this case correctly. Sorry, it looks like I forgot to CC you. I'll bounce this mail to you. Hm, care to send me a patch that backs the old one out? Or just one that fixes it properly, I can't really revert the old patch, now that I'm not using bitkeeper :) Yes, I'll prepare one at the weekend when I have access to my patches again. Mail will be sent out on monday. I'll send you two patches: first one to fix it properly and then one that cleans up a bit more. The second one will do the same things like the patch I forwarded you on April 2nd. It would be nice if you could have a look on this patch in the mean time so you maybe can apply the second one immediately. Eike pgp8m43YK6z84.pgp Description: PGP signature
Re: Kernel SCM saga..
H. Peter Anvin wrote: Followup to: [EMAIL PROTECTED] By author:Chris Wedgwood [EMAIL PROTECTED] In newsgroup: linux.dev.kernel On Thu, Apr 07, 2005 at 09:42:04PM -0700, Linus Torvalds wrote: Yes. The silly thing is, at least in my local tests it doesn't actually seem to be _doing_ anything while it's slow (there are no system calls except for a few memory allocations and de-allocations). It seems to have some exponential function on the number of pathnames involved etc. I see lots of brk calls changing the heap size, up, down, up, down, over and over. This smells a bit like c++ new/delete behavior to me. Hmmm... can glibc be clued in to do some hysteresis on the memory allocation? -hpa Take a look at http://www.linuxshowcase.org/2001/full_papers/ezolt/ezolt_html/ Abstract GNU libc's default setting for malloc can cause a significant performance penalty for applications that use it extensively, such as Compaq's high performance extended math library, CXML. The default malloc tuning can cause a significant number of minor page faults, and result in application performance of only half of the true potential. This paper describes how to remove the performance penalty using environmental variables and the method used to discover the cause of the malloc performance penalty. Regards, Rogan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, Apr 08, 2005 at 02:31:36AM +0200, Adrian Bunk wrote: On Thu, Apr 07, 2005 at 11:05:05PM +0200, Sven Luther wrote: On Thu, Apr 07, 2005 at 10:56:47PM +0200, Adrian Bunk wrote: ... If your statement was true that Debian must take more care regarding legal risks than commercial distributions, can you explain why Debian exposes the legal risks of distributing software capable of decoding MP3's to all of it's mirrors? I don't know and don't really care. I don't maintain any mp3 player (err, actually i do, i package quark, but use it mostly to play .oggs, maybe i should think twice about this now that you made me aware of it), but in any case, i am part of the debian kernel maintainer team, and as such have a responsability to get those packages uploaded and past the screening of the ftp-masters. I believe the planned solution is vastly superior to the current one of simply removing said firmware blobs from the drivers, which caused more harm than helped, which is why we are set to clarifying this for the post-sarge kernels. Debian doesn't seem to care much about the possible legal problems of patents. patents are problematic, and upto recently there where no software patents in europe, so i don't really care. I am not sure about the details of the above problem you mention, could you provide me some link to the problem at hand. I also believe that in the larger scheme restriction of this kind, as is the US restriction on distribution to cuba and everything else, is not-right and even immoral, and *I* personally would fight back if i was ever sued for such things, and there may be higher courts involved than just the US judicial system, which is for sale anyway, where redhat is dependent on. I cannot talk about the whole of debian on this though, and i feel it is for someone else to tackle and handle. If you feel strongly about this, you are free to go take it over with whoever handles this, post to debian-legal and debian-project about it, and help get the issue solved. (/me believes such restrictions of the above are a violation of the elemental human rights to go where one wants and run what operating system on wants). The firmware issues are an urgent real problem? It is a problem that concerns me and the debian kernel team, thus we are out to fix it. If you have a problem at hand, even if it is not as important as others, would you sit back and not do anything just because others didn't solve other problems ? Debian should define how much legal risk they are willing to impose on their mirrors and distributors and should act accordingly in all areas. That is for the ftp-masters to decide, i am not in best speaking term with them, so you are free to go ask the question directly. But ignoring some areas while being more religious than RMS in other areas is simply silly. Come on, i am just asking for a damn explicit declaration that the firmware is not something covered by the GPL, and that we should have explicit distribution licence for it. We all agree that these are not covered by the GPL for various reasons, so why not have the copyright holder state it explicitly ? I don't see how do you jump to more religious than RMS from that, given that my analysis making the firmware aggregate works are a wee bit different from what they explicitly write in their GPL FAQ. That said, i was under the understanding that after the SCO disaster, clarification of licencing issues and copyright attributions was a welcome thing here, but maybe i misunderstood those whole issues. SCO disaster? It is a disaster for SCO. Now, yes. but we did strengthen our admission of patches policy for more tracability, didn't we, and there where companies who paid SCO for fear of retribution, and they where project who post-poned their linux adoptions, and what not. If nothing else, be it only for all the time we all lost following that story over the past tree years. Friendly, Sven Luther - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 SCM saga..
On Thu, Apr 07, 2005 at 09:42:04PM -0700, Linus Torvalds wrote: In the meantime (and because monotone really _is_ that slow), here's a quick challenge for you, and any crazy hacker out there: if you want to play with something _really_ nasty (but also very _very_ fast), take a look at kernel.org:/pub/linux/kernel/people/torvalds/. Interesting. I like it, with one modification (see below). First one to send me the changelog tree of sparse-git (and a tool to commit and push/pull further changes) gets a gold star, and an honorable mention. I've put a hell of a lot of clues in there (*). Here's a partial solution. It does depend on a modified version of cat-file that behaves like cat. I found it easier to have cat-file just dump the object indicated on stdout. Trivial patch for that is included. Two scripts are included: 1) makechlog.sh takes an object and generates a ChangeLog file consisting of all the parents of the given object. It's probably breakable, but correctly outputs the sparse-git changes when run on HEAD. Handles multiple parents and breaks cycles. This adds a line to each object me sha1. This lets a change identify itself. It takes 35 seconds to produce all the change history on my box. It produces a single file named ChangeLog. 2) chkchlog.sh uses the me entries to verify that #1 didn't miss any parents. It's mostly to prove my solution reasonably correct ::-) The patch is below, the scripts are attached, and everything is available here: http://lug.udel.edu/~ross/git/ Now to see what I come up with for commit, push, and pull... -- Ross Vandegrift [EMAIL PROTECTED] The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell. --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 --- cat-file.orig.c 2005-04-08 01:53:54.0 -0400 +++ cat-file.c 2005-04-08 01:57:51.0 -0400 @@ -11,18 +11,11 @@ char type[20]; void *buf; unsigned long size; - char template[] = temp_git_file_XX; - int fd; if (argc != 2 || get_sha1_hex(argv[1], sha1)) usage(cat-file: cat-file sha1); buf = read_sha1_file(sha1, type, size); if (!buf) exit(1); - fd = mkstemp(template); - if (fd 0) - usage(unable to create tempfile); - if (write(fd, buf, size) != size) - strcpy(type, bad); - printf(%s: %s\n, template, type); + printf (%s, buf); } makechlog.sh Description: Bourne shell script chkchlog.sh Description: Bourne shell script
Re: Kernel SCM saga..
On Friday 08 April 2005 03:05, Rogan Dawes wrote: Take a look at http://www.linuxshowcase.org/2001/full_papers/ezolt/ezolt_html/ Abstract GNU libc's default setting for malloc can cause a significant performance penalty for applications that use it extensively, such as Compaq's high performance extended math library, CXML. The default malloc tuning can cause a significant number of minor page faults, and result in application performance of only half of the true potential. This does not smell like an n*2 suckage, more like n^something suckage. Finding the elephant under the rug should not be hard. Profile? Regards, Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 SCM saga..
On Thu, Apr 07, 2005 at 09:42:04PM -0700, Linus Torvalds wrote:
play with something _really_ nasty (but also very _very_ fast), take a
look at kernel.org:/pub/linux/kernel/people/torvalds/.
Why not to use sql as backend instead of the tree of directories? That solves
userland journaling too (really one still has to be careful to know the
read-committed semantics of sql, which is not obvious stuff, but 99% of
common cases like this one just works safe automatically since all
inserts/delete/update are always atomic).
You can keep the design of your db exactly the same and even the command line
of your script the same, except you won't have deal with the implementation of
it anymore, and the end result may run even faster with proper btrees and you
won't have scalability issues if the directory of hashes fills up, and it'll
get userland journaling, live backups, runtime analyses of your queries with
genetic algorithms (pgsql 8 seems to have it) etc...
I seem to recall there's a way to do delayed commits too, so you won't
be sychronous, but you'll still have journaling. You clearly don't care
to do synchronous writes, all you care about is that the commit is
either committed completely or not committed at all (i.e. not an half
write of the patch that leaves your db corrupt).
Example:
CREATE TABLE patches (
patch BIGSERIAL PRIMARY KEY,
commiter_name VARCHAR(32) NOT NULL CHECK(commiter_name !=
''),
commiter_email VARCHAR(32) NOT NULL CHECK(commiter_email
!= ''),
md5 CHAR(32)NOT NULL CHECK(md5 != ''),
len INTEGER NOT NULL CHECK(len 0),
UNIQUE(md5, len),
payload BYTEA NOT NULL,
timestamp TIMESTAMP NOT NULL
);
CREATE INDEX patches_md5_index ON patches (md5);
CREATE INDEX patches_timestamp_index ON patches (timestamp);
s/md5/sha1/, no difference.
This will automatically spawn fatal errors if there are hash collisions and it
enforces a bit of checking.
Then you need a few lines of python to insert/lookup. Example for psycopg2:
import pwd, os, socket
[..]
patch = {'commiter_name': pwd.getpwuid(os.getuid())[4],
'commiter_email': pwd.getpwuid(os.getuid())[0] + '@' +
socket.getfqdn(),
'md5' : md5.new(data).hexdigest(), 'len' : len(data),
payload : data, 'timestamp' : 'now'}
curs.execute(INSERT INTO patches
VALUES (%(committer_name)s, %(commiter_email)s,
%(md5)s, %(len)s, %(payload)s, %(timestamp)s), patch)
('now' will be evaluated by the sql server, who knows about the time too)
The speed I don't know for sure, but especially with lots of data the sql way
should at least not be significantly slower, pgsql scales with terabytes
without apparent problems (modulo the annoyance of running vacuum once per day
in cron, to avoid internal sequence number overflows after 4 giga
committs, and once per day the analyser too so it learns about your
usage patterns and can optimize the disk format for it).
For sure the python part isn't going to be noticeable, you can still write it
in C if you prefer (it'll clearly run faster if you want to run tons of
inserts for a benchmark), so then everything will run at bare-hardware
speed and there will be no time wasted interpreting bytecode (only the
sql commands have to be interpreted).
The backup should also be tiny (runtime size is going to be somewhat larger due
the more data structure it has, how much larger I don't know). I know for sure
this kind of setup works like a charm on ppc64 (32bit userland), and x86 (32bit
and 64bit userland).
monotone using sqlite sounds a good idea infact (IMHO they could use a real
dbms too, so that you also get parallelism and you could attach another app to
the backing store at the same time or you could run a live backup and to
get all other high end performance features).
If you feel this is too bloated feel free to ignore this email of course! If
instead you'd like to give this a spin, let me know and I can help to
set it up quick (either today or from Monday).
I also like quick dedicated solutions and I was about to write a backing
store with a tree of dirs + hashes similar to yours for a similar
problem, but I give it up while planning the userland journaling part
and even worse the userland fs locking with live backups, when a DBMS
gets everything right including live backups (and it provides async
interface too via sockets). OTOH for this usage journaling and locking
aren't a big issue since you may have the patch to hash by hand to find
any potentially half-corrupted bit after reboot and you probably run it
serially.
About your compression of the data, I don't think you want to do that.
The size of the live image isn't the issue, the issue is the size of the
_backups_ and you want to compress an huge thing (i.e. the tarball of
the cleartext,
Re: [PATCH] Use proper seq_file api for /proc/scsi/scsi
On Thu, Apr 07, 2005 at 12:24:12PM +0100, Christoph Hellwig wrote: On Thu, Apr 07, 2005 at 01:21:23PM +0200, Hannes Reinecke wrote: /proc/scsi/scsi is deprecated and even only compiled in if legacy /proc/scsi/ support is enabled. Please move over to lssci which is using sysfs ASAP. Ah. And that's enough reason for it not to work properly? Deprecated as it may be, but one could at least expect it to _work_. It works for those setups that already worked with 2.4.x, aka only a few luns. Even if it's deprecated, wouldn't it be good to fix it as long as it's there, unless it hurts something else? Or at least fix the out of memory error, even if it doesn't display all the luns? jeremy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Le jeudi 07 avril 2005 à 23:07 +0200, Adrian Bunk a écrit : You are mixing apples and oranges. The fact that the GFDL sucks has nothing to do with the firmware issue. With the current situation of firmwares in the kernel, it is illegal to redistribute binary images of the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still be willing to distribute such binary images, but it isn't our problem. It's a grey area. debian-legal did pick one of the possible opinions on this matter. When there are several possible interpretations, you have to pick up the more conservative one, as it's not up to us to make the interpretation, but to a court. Is it true, that the removal of much of the documentation in Debian is scheduled soon because it's covered by the GFDL, that this is called an editorial change, and that Debian doesn't actually care that this will e.g. remove all documentation about available options of the standard C compiler used by and shipped with Debian? The situation changed only in the mind of the person who was the release manager at that time. The old wording is Debian will remain 100% free software, and he understood that as 100% of software in Debian will remain free. The common interpretation is that this wording doesn't allow GFDL documentation either. The fact these documents are very useful is irrelevant: the GFDL is a real piece of crap, only a few fools at the FSF are really arguing it is a free license. Instead of babbling, some people have started to discuss this with upstream, and are trying to come up with a GPLed documentation for GCC. This is much more constructive than repeating again and again Bleh, Debian are a bunch of bigots who don't care of the compiler being documented. Is it true, that Debian will leave users with hardware affected by the firmware problem without a working installer in Debian 3.1? The case of hardware really needing a firwmare to work *and* needed at installation time is rare. I've only heard of some tg3-based cards. Most of them will work without the firmware, and for the few remaining ones, it only means network installation won't work. The point is simply, that Debian does more and more look dogmatic at it's definition of free software without caring about the effects to it's users. Being careless in the definition of free software is a real disservice to users. It makes them rely on e.g. non-free documentation for everyday use. As a contrast, read the discussion between Christoph and Arjan in a part of this thread how to move firmware out of kernel drivers without problems for the users. This might not happen today, but it's better for the users. Some Debian developers have been writing such patches so that we can still run Linux on this hardware, long before the topic was raised on the LKML. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 SCM saga..
git on sarge --- git-0.02/Makefile.orig 2005-04-07 23:06:19.0 +0200 +++ git-0.02/Makefile 2005-04-08 09:24:28.472672224 +0200 @@ -8,7 +8,7 @@ all: $(PROG) install: $(PROG) install $(PROG) $(HOME)/bin/ -LIBS= -lssl +LIBS= -lssl -lz init-db: init-db.o - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.11.3 slab error crash
Hi all,
yesterday our HP DL-585 quad opteron server running 2.6.11.3 crashed
with the attached messages. The main load is NFS serving and running
postfix as well as some other userland processes. The server uses XFS
on top of LVM for NFS-exported volumes. More details available at request.
Thanks,
-Yenya
Apr 7 16:25:11 opteron kernel: slab error in cache_free_debugcheck(): cache
`size-1024': double free, or memory outside object was overwritten
Apr 7 16:25:11 opteron kernel:
Apr 7 16:25:11 opteron kernel: Call
Trace:8015b493{cache_free_debugcheck+371}
8015c615{kfree+213}
Apr 7 16:25:11 opteron kernel:8021ec16{nlm4svc_callback+150}
8021e6f0{nlm4svc_proc_unlock_msg+112}
Apr 7 16:25:11 opteron kernel:
8021d7d0{nlm4svc_decode_unlockargs+48}
803ff445{svc_process+853}
Apr 7 16:25:11 opteron kernel:80218987{lockd+359}
80218820{lockd+0}
Apr 7 16:25:11 opteron kernel:8010ddbf{child_rip+8}
80218820{lockd+0}
Apr 7 16:25:11 opteron kernel:80218820{lockd+0}
8010ddb7{child_rip+0}
Apr 7 16:25:11 opteron kernel:
Apr 7 16:25:11 opteron kernel: 81050ffacae8: redzone 1: 0x5a2cf071,
redzone 2: 0x5a2cf071.
Apr 7 16:25:11 opteron kernel: --- [cut here ] - [please bite
here ] -
Apr 7 16:25:11 opteron kernel: Kernel BUG at host:250
Apr 7 16:25:11 opteron kernel: invalid operand: [1] SMP
Apr 7 16:25:11 opteron kernel: CPU 2
Apr 7 16:25:11 opteron kernel: Modules linked in: ide_cd cdrom
Apr 7 16:25:12 opteron kernel: Pid: 18003, comm: rpciod/2 Not tainted 2.6.11.3
Apr 7 16:25:12 opteron kernel: RIP: 0010:[8021841f]
8021841f{nlm_release_host+47}
Apr 7 16:25:12 opteron kernel: RSP: :810207177da8 EFLAGS: 00010286
Apr 7 16:25:12 opteron kernel: RAX: RBX: 8103cb093248
RCX: 810064b23470
Apr 7 16:25:12 opteron kernel: RDX: fffb RSI: 0296
RDI: 8103cb093248
Apr 7 16:25:12 opteron kernel: RBP: 810142def688 R08:
R09: 810142def9a8
Apr 7 16:25:12 opteron kernel: R10: 80582a80 R11: 2000
R12: 8100bfc33678
Apr 7 16:25:12 opteron kernel: R13: 80149380 R14:
R15: 80149380
Apr 7 16:25:12 opteron kernel: FS: 2ae054c0()
GS:80582b80() knlGS:556b7080
Apr 7 16:25:12 opteron kernel: CS: 0010 DS: 0018 ES: 0018 CR0:
8005003b
Apr 7 16:25:12 opteron kernel: CR2: 2b1a5970 CR3: 82e3
CR4: 06e0
Apr 7 16:25:12 opteron kernel: Process rpciod/2 (pid: 18003, threadinfo
810207176000, task 810207281210)
Apr 7 16:25:12 opteron kernel: Stack: 8101467b8658 8021ec79
803fcc47
Apr 7 16:25:12 opteron kernel:810207177e58 8040e71a
2000 007627d8
Apr 7 16:25:12 opteron kernel:0003 8100bfc336b8
Apr 7 16:25:12 opteron kernel: Call
Trace:8021ec79{nlm4svc_callback_exit+57}
803fcc47{__rpc_execute+855}
Apr 7 16:25:12 opteron kernel:8040e71a{thread_return+42}
8012f483{__wake_up+67}
Apr 7 16:25:12 opteron kernel:803fcd20{rpc_async_schedule+0}
8014477c{worker_thread+476}
Apr 7 16:25:12 opteron kernel:
8012f3c0{default_wake_function+0}
8012f3c0{default_wake_function+0}
Apr 7 16:25:12 opteron kernel:
80148d80{keventd_create_kthread+0}
801445a0{worker_thread+0}
Apr 7 16:25:12 opteron kernel:
80148d80{keventd_create_kthread+0} 80148d42{kthread+146}
Apr 7 16:25:12 opteron kernel:8010ddbf{child_rip+8}
80148d80{keventd_create_kthread+0}
Apr 7 16:25:12 opteron kernel:80148cb0{kthread+0}
8010ddb7{child_rip+0}
Apr 7 16:25:12 opteron kernel:
Apr 7 16:25:12 opteron kernel:
Apr 7 16:25:12 opteron kernel: Code: 0f 0b 7b 1d 45 80 ff ff ff ff fa 00 66 66
90 66 90 5b c3 66
--
| Jan Yenya Kasprzak kas at {fi.muni.cz - work | yenya.net - private} |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ |
Whatever the Java applications and desktop dances may lead to, Unix will
still be pushing the packets around for a quite a while. --Rob Pike
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 11:55:44PM -0400, Raul Miller wrote: Also, mere aggregation is a term from the GPL. You can read what it says there yourself. But basically it's there so that people make a distinction between the program itself and other stuff that isn't the program. On Thu, Apr 07, 2005 at 04:20:50PM -0700, David Schwartz wrote: It's also there because the GPL can only apply to either works placed under it by their authors and works that are legally classified as derivative. If you merely aggregate two works, there is no derivation. The GPL is making clear that it's not trying to exceed the scope of its authority (which is copyright law). The issue of whether or not the combined work is a derivative under copyright law is a copyright law issue. The GPL does concern itself with that issue, but not in the mere aggregation clause. The mere aggregation clause holds regardless of whether or not the combined work is a derivative under copyright law. [P.S. I've set the Reply-To: header on this message because I think this thread has drifted away from kernel issues.] Thanks. BTW, have any of you read the analysis i made, where i claim, rooted in the GPL FAQ and with examples, why i believe that the firmware can be considerated a non derivative of the linux kernel. The main points is that the firmware is not aimed to run in the same address space, even not the same cpu, as the rest of the linux kernel, and that there is a clearly defined communication channel between the GPLed driver and the target processor running the firmware. I further argumented that taking any different stance would bring us worlds of hurt as we would consider the bios as being a derivative work of the kernel they are running, or the bootloader, or the firmware present in proms on devices loaded into the system and so on. I think only the fact that if you consider firmware as being a derivative work, you should consider it a derivative work also when it is flashed on the prom of a pci card or what not, is decisive enough to make those firmware blobs not derivative works of the kernel they are under. Friendly, Sven Luther - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 SCM saga..
Daniel Phillips wrote: On Friday 08 April 2005 03:05, Rogan Dawes wrote: Take a look at http://www.linuxshowcase.org/2001/full_papers/ezolt/ezolt_html/ Abstract GNU libc's default setting for malloc can cause a significant performance penalty for applications that use it extensively, such as Compaq's high performance extended math library, CXML. The default malloc tuning can cause a significant number of minor page faults, and result in application performance of only half of the true potential. This does not smell like an n*2 suckage, more like n^something suckage. Finding the elephant under the rug should not be hard. Profile? Lack of hysteresis can do that, with large swats of memory constantly being claimed and returned to the system. One way to implement hysteresis would be based on a decaying peak-based threshold; unfortunately for optimal performance that requires the C runtime to have a notion of time, and in extreme cases even be able to do asynchronous deallocation, but in reality one can probably assume that the rate of malloc/free is roughly constant over time. -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/
[patch 1/8] fix lib/sort regression test
The regression test in lib/sort.c is currently worthless because the array that
is generated for sorting will be all zeros. This patch fixes things so
that the array that is generated will contain unsorted integers (that are not
all identical) as was probably intended.
Signed-off-by Daniel Dickman [EMAIL PROTECTED]
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
kj-domen/lib/sort.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN lib/sort.c~bug-lib_sort lib/sort.c
--- kj/lib/sort.c~bug-lib_sort 2005-04-05 12:57:40.0 +0200
+++ kj-domen/lib/sort.c 2005-04-05 12:57:40.0 +0200
@@ -90,7 +90,7 @@ int cmpint(const void *a, const void *b)
static int sort_test(void)
{
- int *a, i, r = 0;
+ int *a, i, r = 1;
a = kmalloc(1000 * sizeof(int), GFP_KERNEL);
BUG_ON(!a);
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 2/8] correctly name the Shell sort
As per http://www.nist.gov/dads/HTML/shellsort.html, this should be referred to
as a Shell sort. Shell-Metzner is a misnomer.
Signed-off-by: Daniel Dickman [EMAIL PROTECTED]
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
kj-domen/kernel/sys.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN kernel/sys.c~comment-kernel_sys kernel/sys.c
--- kj/kernel/sys.c~comment-kernel_sys 2005-04-05 12:57:41.0 +0200
+++ kj-domen/kernel/sys.c 2005-04-05 12:57:41.0 +0200
@@ -1194,7 +1194,7 @@ static int groups_from_user(struct group
return 0;
}
-/* a simple shell-metzner sort */
+/* a simple Shell sort */
static void groups_sort(struct group_info *group_info)
{
int base, max, stride;
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] Updated: Dynamic Tick version 050408-1
* Tony Lindgren [EMAIL PROTECTED] [050407 23:28]:
I think I have an idea on what's going on; Your system does not wake to
APIC interrupt, and the system timer updates time only on other interrupts.
I'm experiencing the same on a loaner ThinkPad T30.
I'll try to do another patch today. Meanwhile it now should work
without lapic in cmdline.
Following is an updated patch. Anybody having trouble, please try
disabling CONFIG_DYN_TICK_USE_APIC Kconfig option.
I'm hoping this might work on Pavel's machine too?
Tony
diff -Nru a/arch/i386/Kconfig b/arch/i386/Kconfig
--- a/arch/i386/Kconfig 2005-04-08 00:43:41 -07:00
+++ b/arch/i386/Kconfig 2005-04-08 00:43:41 -07:00
@@ -460,6 +460,26 @@
bool Provide RTC interrupt
depends on HPET_TIMER RTC=y
+config NO_IDLE_HZ
+ bool Dynamic Tick Timer - Skip timer ticks during idle
+ help
+ This option enables support for skipping timer ticks when the
+ processor is idle. During system load, timer is continuous.
+ This option saves power, as it allows the system to stay in
+ idle mode longer. Currently supported timers are ACPI PM
+ timer, local APIC timer, and TSC timer. HPET timer is currently
+ not supported.
+
+config DYN_TICK_USE_APIC
+ bool Use APIC timer instead of PIT timer
+ help
+ This option enables using APIC timer interrupt if your hardware
+ supports it. APIC timer allows longer sleep periods compared
+ to PIT timer. Note that on some hardware disabling PIT timer
+ also disables APIC timer interrupts, and system won't run
+ properly. Symptoms include slow system boot, and time running
+ slow. If unsure, don't enable this option.
+
config SMP
bool Symmetric multi-processing support
---help---
diff -Nru a/arch/i386/kernel/Makefile b/arch/i386/kernel/Makefile
--- a/arch/i386/kernel/Makefile 2005-04-08 00:43:41 -07:00
+++ b/arch/i386/kernel/Makefile 2005-04-08 00:43:41 -07:00
@@ -30,6 +30,7 @@
obj-y += sysenter.o vsyscall.o
obj-$(CONFIG_ACPI_SRAT)+= srat.o
obj-$(CONFIG_HPET_TIMER) += time_hpet.o
+obj-$(CONFIG_NO_IDLE_HZ) += dyn-tick.o
obj-$(CONFIG_EFI) += efi.o efi_stub.o
obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
diff -Nru a/arch/i386/kernel/apic.c b/arch/i386/kernel/apic.c
--- a/arch/i386/kernel/apic.c 2005-04-08 00:43:41 -07:00
+++ b/arch/i386/kernel/apic.c 2005-04-08 00:43:41 -07:00
@@ -26,6 +26,7 @@
#include linux/mc146818rtc.h
#include linux/kernel_stat.h
#include linux/sysdev.h
+#include linux/dyn-tick-timer.h
#include asm/atomic.h
#include asm/smp.h
@@ -909,6 +910,8 @@
#define APIC_DIVISOR 16
+static u32 apic_timer_val;
+
static void __setup_APIC_LVTT(unsigned int clocks)
{
unsigned int lvtt_value, tmp_value, ver;
@@ -927,7 +930,15 @@
~(APIC_TDR_DIV_1 | APIC_TDR_DIV_TMBASE))
| APIC_TDR_DIV_16);
- apic_write_around(APIC_TMICT, clocks/APIC_DIVISOR);
+ apic_timer_val = clocks/APIC_DIVISOR;
+
+#ifdef CONFIG_NO_IDLE_HZ
+ /* Local APIC timer is 24-bit */
+ if (apic_timer_val)
+ dyn_tick-max_skip = 0xff / apic_timer_val;
+#endif
+
+ apic_write_around(APIC_TMICT, apic_timer_val);
}
static void __init setup_APIC_timer(unsigned int clocks)
@@ -1040,6 +1051,13 @@
*/
setup_APIC_timer(calibration_result);
+#ifdef CONFIG_NO_IDLE_HZ
+ if (calibration_result)
+ dyn_tick-state |= DYN_TICK_USE_APIC;
+ else
+ printk(KERN_INFO dyn-tick: Cannot use local APIC\n);
+#endif
+
local_irq_enable();
}
@@ -1068,6 +1086,18 @@
}
}
+#if defined(CONFIG_NO_IDLE_HZ)
+void reprogram_apic_timer(unsigned int count)
+{
+ unsigned long flags;
+
+ count *= apic_timer_val;
+ local_irq_save(flags);
+ apic_write_around(APIC_TMICT, count);
+ local_irq_restore(flags);
+}
+#endif
+
/*
* the frequency of the profiling timer can be changed
* by writing a multiplier value into /proc/profile.
@@ -1160,6 +1190,7 @@
fastcall void smp_apic_timer_interrupt(struct pt_regs *regs)
{
+ unsigned long seq;
int cpu = smp_processor_id();
/*
@@ -1178,6 +1209,23 @@
* interrupt lock, which is the WrongThing (tm) to do.
*/
irq_enter();
+
+#ifdef CONFIG_NO_IDLE_HZ
+ /*
+* Check if we need to wake up PIT interrupt handler.
+* Otherwise just wake up local APIC timer.
+*/
+ do {
+ seq = read_seqbegin(xtime_lock);
+ if (dyn_tick-state (DYN_TICK_ENABLED | DYN_TICK_SKIPPING)) {
+ if (dyn_tick-skip_cpu == cpu dyn_tick-skip
DYN_TICK_MIN_SKIP)
+ dyn_tick-interrupt(99, NULL, regs);
+ else
+ reprogram_apic_timer(1);
+
[patch 4/8] serial/icom: Remove custom msescs_to_jiffies() macro
Remove the MSECS_TO_JIFFIES() macro because msescs_to_jiffies() from
jiffies.h should be used. The macro isn't referenced anywhere anyway.
Signed-off-by: Tobias Klauser [EMAIL PROTECTED]
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
kj-domen/drivers/serial/icom.h |2 --
1 files changed, 2 deletions(-)
diff -puN drivers/serial/icom.h~msecs_to_jiffies-drivers_serial_icom.h
drivers/serial/icom.h
--- kj/drivers/serial/icom.h~msecs_to_jiffies-drivers_serial_icom.h
2005-04-05 12:57:56.0 +0200
+++ kj-domen/drivers/serial/icom.h 2005-04-05 12:57:56.0 +0200
@@ -286,5 +286,3 @@ struct lookup_int_table {
u32 __iomem *global_int_mask;
unsigned long processor_id;
};
-
-#define MSECS_TO_JIFFIES(ms) (((ms)*HZ+999)/1000)
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 3/8] string.linux-2.6.10/lib/c: documentation strncpy()
this clarifys the documentation on the behavier of strncpy().
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
kj-domen/lib/string.c |4
1 files changed, 4 insertions(+)
diff -L lib/c.bak -puN /dev/null /dev/null
diff -puN lib/string.c~comment-lib_string lib/string.c
--- kj/lib/string.c~comment-lib_string 2005-04-05 12:57:42.0 +0200
+++ kj-domen/lib/string.c 2005-04-05 12:57:42.0 +0200
@@ -85,6 +85,10 @@ EXPORT_SYMBOL(strcpy);
*
* The result is not %NUL-terminated if the source exceeds
* @count bytes.
+ *
+ * In the case where the length of @src is less than that of
+ * count, the remainder of @dest will be padded with %NUL.
+ *
*/
char * strncpy(char * dest,const char *src,size_t count)
{
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: /dev/random problem on 2.6.12-rc1
On Fri, Apr 08, 2005 at 08:56:51AM +0200, Simon Derr wrote: On Thu, 7 Apr 2005, Matt Mackall wrote: On Thu, Apr 07, 2005 at 05:36:59PM +0200, Simon Derr wrote: On Thu, 7 Apr 2005, Yura Pakhuchiy wrote: On Thu, 2005-04-07 at 14:40 +0200, Patrice Martinez wrote: When using a machine with a 2612-rc 1kernel, I encounter problems reading /dev/random: it simply nevers returns anything, and the process is blocked in the read... The easiest way to see it is to type: od /dev/random Any idea? Because, /dev/random use user input, mouse movements and other things to generate next random number. Use /dev/urandom if you want version that will never block your machine. Read man 4 random for details. Something changed since previous versions of the kernel, I guess. Running `find /usr | wc' on a ssh session generates both network and disk activity, and you should not expect any other kind of input on a networked server. Oops, the command is actually find /usr | xargs wc, witch causes lots of disk activity. FYI, network activity only generates entropy on a very small subset of NICs, and probably not the one you're using. This is good, as network activity is assumed passively observable/timable. Offtopic, but why isn't the policy the same for all NICs ? The policy is the same, it just hasn't been implemented. SA_RANDOM is scheduled for abolishment. Anyway, still zero bytes coming from /dev/random, for the few minutes I waited. Are you and Patrice both experiencing this on the same machine? Both IA-64, but that's the only common point. What was the last kernel that was known to work for you? Do you see the contents of /proc/sys/kernel/random/entropy_avail change over time? Are there any other entropy consumers on your machine? None that I am aware of. I run: # dd if=/dev/random bs=1 count=1 | od strace the dd process, please. This works fine here. Another shell: # lsof /dev/random COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME dd 1496 root0r CHR1,8 99952 /dev/random Now, find /usr | xargs wc running in background. About /proc/sys/kernel/random/entropy_avail: (5 second refresh interval) That may not be sufficient resolution. The upper layers will pull from it whenever it rises above 64 and bash it back down to within 7 bits of 0. What does it do when no one is reading from it? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] Use proper seq_file api for /proc/scsi/scsi
On Fri, 2005-04-08 at 08:56 +0100, Christoph Hellwig wrote: On Fri, Apr 08, 2005 at 12:23:46AM -0700, Jeremy Higdon wrote: It works for those setups that already worked with 2.4.x, aka only a few luns. Even if it's deprecated, wouldn't it be good to fix it as long as it's there, unless it hurts something else? Or at least fix the out of memory error, even if it doesn't display all the luns? What other error would you return? I don't particularly care what exact error code to return, but putting in Hannes patch would be a bad idea because it a) poke deep into driver model internals, and we absolutely want to avoid that b) sets a bad precedence that we'll continue adding features to deprecated interface and thus encurage people to contiue using it. Note that /proc/scsi/* has been deprecated since mid-2.5.x. so how about starting to remove it? eg give it its final resting date, start defaulting the config option to n and such... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] Use proper seq_file api for /proc/scsi/scsi
On Fri, Apr 08, 2005 at 12:23:46AM -0700, Jeremy Higdon wrote: It works for those setups that already worked with 2.4.x, aka only a few luns. Even if it's deprecated, wouldn't it be good to fix it as long as it's there, unless it hurts something else? Or at least fix the out of memory error, even if it doesn't display all the luns? What other error would you return? I don't particularly care what exact error code to return, but putting in Hannes patch would be a bad idea because it a) poke deep into driver model internals, and we absolutely want to avoid that b) sets a bad precedence that we'll continue adding features to deprecated interface and thus encurage people to contiue using it. Note that /proc/scsi/* has been deprecated since mid-2.5.x. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] Use proper seq_file api for /proc/scsi/scsi
On Fri, Apr 08, 2005 at 08:56:43AM +0100, Christoph Hellwig wrote: On Fri, Apr 08, 2005 at 12:23:46AM -0700, Jeremy Higdon wrote: Even if it's deprecated, wouldn't it be good to fix it as long as it's there, unless it hurts something else? Or at least fix the out of memory error, even if it doesn't display all the luns? What other error would you return? I don't particularly care what exact Hmm. Well maybe you're right -- an error is probably better than no error if not printing all devices. error code to return, but putting in Hannes patch would be a bad idea because it a) poke deep into driver model internals, and we absolutely want to avoid that b) sets a bad precedence that we'll continue adding features to deprecated interface and thus encurage people to contiue using it. Note that /proc/scsi/* has been deprecated since mid-2.5.x. Just as a sanity check, you meant lsscsi and not lssci in your original reply, right? jeremy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, Apr 08, 2005 at 03:10:43AM +0100, Henning Makholm wrote: Scripsit Humberto Massa [EMAIL PROTECTED] After a *lot* of discussion, it was deliberated on d-l that this is not that tricky at all, and that the mere aggregation clause applies to the combination, for various reasons, with a great degree of safety. When was this alleged conclusion reached? I remember nothing like that. http://lists.debian.org/debian-legal/2005/03/msg00273.html and : http://lists.debian.org/debian-legal/2005/03/msg00283.html and the following thread. These where linked from the original mail in this thread. No-one is saying that the linker merely aggregates object code for the driver; what *is* being said is: in the case of firmware, especially if the firmware is neither a derivative work on the kernel (see above) nor the firmware includes part of the kernel (duh), it is *fairly* *safe* to consider the intermixing of firmware bytes with kernel binary image bytes in an ELF object file as mere aggregation. No, it is completely wrong to say that the object file is merely an aggregation. The two components are being coupled much more tightly than in the situation that the GPL discribes as mere aggregation. So read the analysis and comment on it if you disagree, but let's take it to debian-legal alone, ok ? Friendly, Sven Luther - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 09:15:07AM -0300, Humberto Massa wrote: This is where you are wrong IMMHO. All that is needed for you to distribute the hexdump blob under the GPL is a declaration from the copyright holder saying this, to me, is the preferred form for modification of the firmware and hence the source code under the GPL. I strongly disagree. This could be an open door to to anyone claiming that whatever binary is the prefered form of modification. Friendly, Sven Luther - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, Apr 08, 2005 at 04:56:50AM +0100, Henning Makholm wrote: Scripsit David Schwartz [EMAIL PROTECTED] [quoting me] No, it is completely wrong to say that the object file is merely an aggregation. The two components are being coupled much more tightly than in the situation that the GPL discribes as mere aggregation. Would you maintain this position even if the firmware is identical across operating systems and the Linux driver is identical across different firmware builds for different hardware implementations? Yes I would. Linking forms a tighter coupling than just placing the two parts side by side on a filesystem designed for general storage of byte streams. There is more to say about the situation than the naked So, why didn't you say it when i posted my analysis to debian-legal a month ago and asked for comments ? fact that that they are aggreated on the same medium; ergo the sutiation does not constitute *only* aggregation, and the mere aggregation language of the GPL does not apply. In particular, the end of GPL #2 does not provide a blanket exception for all forms of aggregation; it specifically speaks about aggregation on a volume of a storage or distribution medium. Read my argumentation, comment on it, and be prepared to consider the same copy of the firmware as a derived work if shipped on a prom on the device itself. Friendly, Sven Luther - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 05, 2005 at 11:50:54AM -0400, Richard B. Johnson wrote: On Tue, 5 Apr 2005, Humberto Massa wrote: Josselin Mouette wrote: You are mixing apples and oranges. The fact that the GFDL sucks has nothing to do with the firmware issue. With the current situation of firmwares in the kernel, it is illegal to redistribute binary images of the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still be willing to distribute such binary images, but it isn't our problem. Wrong! It is perfectly legal in the United States, and I'm pretty sure in your country, to distribute or redistribute copyrighted works. Otherwise there wouldn't be any bookstores or newspaper stands. Mmm, so you are claiming it is perfectly right to make copies of the windows installation CD, or for that matter to duplicate music CDs ? I would be rather interested in knowing how you came to that conclusion :) Friendly, Sven Luther - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 04:15:45PM +0200, Josselin Mouette wrote: Le jeudi 07 avril 2005 à 09:03 -0400, Richard B. Johnson a écrit : Well it doesn't make any difference. If GPL has degenerated to where one can't upload microcode to a device as part of its initialization, without having the source that generated that microcode, we are in a lot of hurt. Intel isn't going to give their designs away. The GPL doesn't forbid that. The GPL forbids to put this microcode directly in the same binary as the GPL code. Of course, nothing forbids some GPL'ed code to take a binary elsewhere and to upload it into the hardware. No, i am arguing, that we can consider here the binary as a media distribution, in the same way as we would clearly separate the compressor from the compressed data in a auto-uncompressing executable, or the firmware from the firmware flasher in a all-in-one firmware upgrade binary. At least that's my opinion; AIUI, Sven Luther believes it is possible if the firmware has a decent (but not necessarily free) license. Indeed, the sole problem is that the current copyright and licencing attributions de-facto sets those firmware blobs under the GPL, which of course makes them undistributable since the GPL clearly claims that we need source code for it, and if any condition of the GPL fails, the program becomes undistributable as a whole. Friendly, Sven Luther - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 6/8] printk : drivers/char/ftape/compressor/zftape-compress.c
printk() calls should include appropriate KERN_* constant. Signed-off-by: Christophe Lucas [EMAIL PROTECTED] Signed-off-by: Domen Puncer [EMAIL PROTECTED] --- kj-domen/drivers/char/ftape/compressor/zftape-compress.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN drivers/char/ftape/compressor/zftape-compress.c~printk-drivers_char_ftape_compressor_zftape-compress drivers/char/ftape/compressor/zftape-compress.c --- kj/drivers/char/ftape/compressor/zftape-compress.c~printk-drivers_char_ftape_compressor_zftape-compress 2005-04-05 12:58:03.0 +0200 +++ kj-domen/drivers/char/ftape/compressor/zftape-compress.c2005-04-05 12:58:03.0 +0200 @@ -1176,8 +1176,8 @@ KERN_INFO Compressor for zftape (lzrw3 } #else /* !MODULE */ /* print a short no-nonsense boot message */ - printk(zftape compressor v1.00a 970514\n); - printk(For use with FTAPE_VERSION \n); + printk(KERN_INFO zftape compressor v1.00a 970514\n); + printk(KERN_INFO For use with FTAPE_VERSION \n); #endif /* MODULE */ TRACE(ft_t_info, zft_compressor_init @ 0x%p, zft_compressor_init); TRACE(ft_t_info, installing compressor for zftape ...); _ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] Priority Lists for the RT mutex
On Fri, 2005-04-08 at 08:28 +0200, Ingo Molnar wrote: * Daniel Walker [EMAIL PROTECTED] wrote: This patch adds the priority list data structure from Inaky Perez-Gonzalez to the Preempt Real-Time mutex. this one looks really clean. it makes me wonder, what is the current status of fusyn's? Such a light datastructure would be much more mergeable upstream than the former 100-queues approach. Ingo, Joe Korty has been doing a lot of work on Fusyn recently. Fusyn is now a generic implementation, similar to the RT mutex. SMP scalability is somewhat better for decoupled locks on PI (last I checked). It has the extra bulk required to support user space. The major issue that concerns the Fusym and the real-time patch is that merging the kernel portion of Fusyn creates a collision of redundant PI implementations with respect to the RT mutex. The issues are outlined here: http://developer.osdl.org/dev/mutexes/ There are a few mistakes on the page, (RT mutex does not do priority ceiling), but for the most part the info is current. If the RT mutex could be exposed in non PREEMPT_RT configurations, the fulock portion could be superseded by the RT mutex, and the remaining pieces merged in. Or vice versa. We discussed the scenarios recently, any guidance you can offer to help us out would be greatly appreciated. http://lists.osdl.org/pipermail/robustmutexes/2005-April/000532.html Sven - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 7/8] lib/sha1.c: fix sparse warning
Fix lib/sha1.c:44:10: warning: cast to restricted type Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] Signed-off-by: Domen Puncer [EMAIL PROTECTED] --- kj-domen/lib/sha1.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN lib/sha1.c~sparse-lib_sha1 lib/sha1.c --- kj/lib/sha1.c~sparse-lib_sha1 2005-04-05 12:58:04.0 +0200 +++ kj-domen/lib/sha1.c 2005-04-05 12:58:04.0 +0200 @@ -41,7 +41,7 @@ void sha_transform(__u32 *digest, const __u32 a, b, c, d, e, t, i; for (i = 0; i 16; i++) - W[i] = be32_to_cpu(((const __u32 *)in)[i]); + W[i] = be32_to_cpu(((const __be32 *)in)[i]); for (i = 0; i 64; i++) W[i+16] = rol32(W[i+13] ^ W[i+8] ^ W[i+2] ^ W[i], 1); diff -L lib/sha1.c.orig -puN /dev/null /dev/null _ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 5/8] printk : drivers/char/applicom.c
printk() calls should include appropriate KERN_* constant.
Signed-off-by: Christophe Lucas [EMAIL PROTECTED]
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
kj-domen/drivers/char/applicom.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/char/applicom.c~printk-drivers_char_applicom
drivers/char/applicom.c
--- kj/drivers/char/applicom.c~printk-drivers_char_applicom 2005-04-05
12:58:02.0 +0200
+++ kj-domen/drivers/char/applicom.c2005-04-05 12:58:02.0 +0200
@@ -599,7 +599,7 @@ static ssize_t ac_read (struct file *fil
#ifdef DEBUG
if (loopcount++ 2) {
- printk(Looping in ac_read. loopcount %d\n, loopcount);
+ printk(KERN_DEBUG Looping in ac_read. loopcount %d\n,
loopcount);
}
#endif
}
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signing modules in Kernel 2.4
Hello, I found a patch for Kernels 2.6 that ensures kernel integrity by digitally signing kernel modules. Is something similar available for 2.4-Kernels? Kind regards Christoph - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 1/1] block/cpqarray: Use the DMA_32BIT_MASK constant
Use the DMA_32BIT_MASK constant from dma-mapping.h when calling
pci_set_dma_mask() or pci_set_consistent_dma_mask() instead of custom
macros.
This patch includes dma-mapping.h explicitly because it caused errors
on some architectures otherwise.
See http://marc.theaimsgroup.com/?t=10800199301r=1w=2 for details
Signed-off-by: Tobias Klauser [EMAIL PROTECTED]
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
kj-domen/drivers/block/cpqarray.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff -puN drivers/block/cpqarray.c~dma_mask-drivers_block_cpqarray
drivers/block/cpqarray.c
--- kj/drivers/block/cpqarray.c~dma_mask-drivers_block_cpqarray 2005-04-05
12:57:44.0 +0200
+++ kj-domen/drivers/block/cpqarray.c 2005-04-05 12:57:44.0 +0200
@@ -39,6 +39,7 @@
#include linux/spinlock.h
#include linux/blkdev.h
#include linux/genhd.h
+#include linux/dma-mapping.h
#include asm/uaccess.h
#include asm/io.h
@@ -65,8 +66,6 @@ MODULE_LICENSE(GPL);
#define MAX_CTLR 8
#define CTLR_SHIFT 8
-#define CPQARRAY_DMA_MASK 0x /* 32 bit DMA */
-
static int nr_ctlr;
static ctlr_info_t *hba[MAX_CTLR];
@@ -626,7 +625,7 @@ static int cpqarray_pci_init(ctlr_info_t
for(i=0; i6; i++)
addr[i] = pci_resource_start(pdev, i);
- if (pci_set_dma_mask(pdev, CPQARRAY_DMA_MASK) != 0)
+ if (pci_set_dma_mask(pdev, DMA_32BIT_MASK) != 0)
{
printk(KERN_ERR cpqarray: Unable to set DMA mask\n);
return -1;
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 1/1] printk : drivers/block/DAC960.c
printk() calls should include appropriate KERN_* constant.
Signed-off-by: Christophe Lucas [EMAIL PROTECTED]
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
kj-domen/drivers/block/DAC960.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff -puN drivers/block/DAC960.c~printk-drivers_block_DAC960
drivers/block/DAC960.c
--- kj/drivers/block/DAC960.c~printk-drivers_block_DAC960 2005-04-05
12:57:58.0 +0200
+++ kj-domen/drivers/block/DAC960.c 2005-04-05 12:57:58.0 +0200
@@ -2496,7 +2496,7 @@ static boolean DAC960_RegisterBlockDevic
/* for now, let all request queues share controller's lock */
RequestQueue =
blk_init_queue(DAC960_RequestFunction,Controller-queue_lock);
if (!RequestQueue) {
- printk(DAC960: failure to allocate request queue\n);
+ printk(KERN_WARNING DAC960: failure to allocate request
queue\n);
continue;
}
Controller-RequestQueue[n] = RequestQueue;
@@ -3534,7 +3534,7 @@ static void DAC960_V1_ProcessCompletedCo
#ifdef FORCE_RETRY_FAILURE_DEBUG
if (!(++retry_count % 1)) {
- printk(V1 error retry failure test\n);
+ printk(KERN_DEBUG V1 error retry failure test\n);
normal_completion = false;
DAC960_V1_ReadWriteError(Command);
}
@@ -4622,7 +4622,7 @@ static void DAC960_V2_ProcessCompletedCo
#ifdef FORCE_RETRY_FAILURE_DEBUG
if (!(++retry_count % 1)) {
- printk(V2 error retry failure test\n);
+ printk(KERN_DEBUG V2 error retry failure test\n);
normal_completion = false;
DAC960_V2_ReadWriteError(Command);
}
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 SCM saga..
On Thu, Apr 07, 2005 at 09:42:04PM -0700, Linus Torvalds wrote: On Thu, 7 Apr 2005, Chris Wedgwood wrote: I'm playing with monotone right now. Superficially it looks like it has tons of gee-whiz neato stuff... however, it's *agonizingly* slow. I mean glacial. A heavily sedated sloth with no legs is probably faster. Yes. The silly thing is, at least in my local tests it doesn't actually seem to be _doing_ anything while it's slow (there are no system calls except for a few memory allocations and de-allocations). It seems to have some exponential function on the number of pathnames involved etc. I'm hoping they can fix it, though. The basic notions do not sound wrong. That is indeed correct wrt pathnames. The current head of monotone is a lot better in this regard (the order of 2-3 minutes for monotone import on a 2.6 linux untar). The basic problem is that in the last release (0.17), a huge amount of sanity checking code was added to ensure that inconsistent or generally bad revisions can never be written/received/transmitted. The focus is now on speeding that up - there's a _lot_ of low hanging fruit for us to look at. Matt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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/1] reiserfs: make resize option auto-get new device size
Hi,
On Fri, Apr 08, 2005 at 06:55:50AM +0200, [EMAIL PROTECTED] wrote:
Cc: [EMAIL PROTECTED], reiserfs-list@namesys.com, [EMAIL PROTECTED]
It's trivial for the resize option to auto-get the underlying device size,
while
it's harder for the user. I've copied the code from jfs.
Since of the different reiserfs option parser (which does not use the superior
match_token used by almost every other filesystem), I've had to use the
resize=auto and not resize option to specify this behaviour. Changing the
option parser to the kernel one wouldn't be bad but I've no time to do this
cleanup in this moment.
do people really need it?
user-level utility reisize_reiserfs, being called w/o size argument,
calculates the device size and uses resize mount option with correct value.
Btw, the mount(8) man page should be updated to include this option. Cc the
relevant people, please (I hope I cc'ed the right people).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
---
linux-2.6.11-paolo/fs/reiserfs/super.c | 21 ++---
1 files changed, 14 insertions(+), 7 deletions(-)
diff -puN fs/reiserfs/super.c~reiserfs-resize-option-like-jfs-auto-get
fs/reiserfs/super.c
--- linux-2.6.11/fs/reiserfs/super.c~reiserfs-resize-option-like-jfs-auto-get
2005-04-07 20:37:58.0 +0200
+++ linux-2.6.11-paolo/fs/reiserfs/super.c2005-04-08 01:01:18.0
+0200
@@ -889,12 +889,18 @@ static int reiserfs_parse_options (struc
char * p;
p = NULL;
- /* resize=NNN */
- *blocks = simple_strtoul (arg, p, 0);
- if (*p != '\0') {
- /* NNN does not look like a number */
- reiserfs_warning (s, reiserfs_parse_options: bad value %s,
arg);
- return 0;
+ /* resize=NNN or resize=auto */
+
+ if (!strcmp(arg, auto)) {
+ /* From JFS code, to auto-get the size.*/
+ *blocks = s-s_bdev-bd_inode-i_size
s-s_blocksize_bits;
+ } else {
+ *blocks = simple_strtoul (arg, p, 0);
+ if (*p != '\0') {
+ /* NNN does not look like a number */
+ reiserfs_warning (s, reiserfs_parse_options: bad value
%s, arg);
+ return 0;
+ }
}
}
@@ -903,7 +909,8 @@ static int reiserfs_parse_options (struc
unsigned long val = simple_strtoul (arg, p, 0);
/* commit=NNN (time in seconds) */
if ( *p != '\0' || val = (unsigned int)-1) {
- reiserfs_warning (s, reiserfs_parse_options: bad value
%s, arg); return 0;
+ reiserfs_warning (s, reiserfs_parse_options: bad value
%s, arg);
+ return 0;
}
*commit_max_age = (unsigned int)val;
}
_
--
Alex.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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/1] reiserfs: make resize option auto-get new device size
On Friday 08 April 2005 10:10, Alex Zarochentsev wrote: Hi, On Fri, Apr 08, 2005 at 06:55:50AM +0200, [EMAIL PROTECTED] wrote: Cc: [EMAIL PROTECTED], reiserfs-list@namesys.com, [EMAIL PROTECTED] It's trivial for the resize option to auto-get the underlying device size, while it's harder for the user. I've copied the code from jfs. Since of the different reiserfs option parser (which does not use the superior match_token used by almost every other filesystem), I've had to use the resize=auto and not resize option to specify this behaviour. Changing the option parser to the kernel one wouldn't be bad but I've no time to do this cleanup in this moment. do people really need it? Note we are speaking of 2 lines of code. And there's no point in omitting this. user-level utility reisize_reiserfs, being called w/o size argument, calculates the device size and uses resize mount option with correct value. Yes, I know this. But the old versions (the one shipped on Mdk) didn't work for online resizing (this was verified by me with lots of warnings and a Oops on reiserfs code); in fact, this ability is so new that is not even documented in manpages. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 05, 2005 at 12:50:14PM -0600, Chris Friesen wrote: Josselin Mouette wrote: The fact is also that mixing them with a GPLed software gives an result you can't redistribute - although it seems many people disagree with that assertion now. This is only true if the result is considered a derivative work of the gpl'd code. The GPL states In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. Since the main cpu does not actually run the binary firmware, the fact that it lives in main memory with the code that the cpu *does* run is irrelevent. In this case, the Debian stance is that the kernel proper and the binary firmware are merely aggregated in a volume of storage ( ie. system memory). The problem is that you can only argue it is mere agregation, if the copyright notice doesn't de-facto put said firmware blobs under the GPL, thus making them undistributable by the selfsame definition of the GPL. Friendly, Sven Luther - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 SCM saga..
On Thu, Apr 07, 2005 at 11:41:29PM -0700, Linus Torvalds wrote: I know I can import things myself, but the reason I ask is because I've got several SCM's I should check out _and_ I've been spending the last two days writing my own fallback system so that I don't get screwed if nothing out there works right now. I tend to like bzr too (and I tend to like too many things ;), but even if the export of the data would be available it seems still too early in development to be able to help you this week, it seems to miss any form of network export too. I'd like many people to test out many alternatives, to get a feel for where they are especially for a project the size of the kernel.. The huge number of changesets is the crucial point, there are good distributed SCM already but they are apparently not efficient enough at handling 60k changesets. We'd need a regenerated coherent copy of BKCVS to pipe into those SCM to evaluate how well they scale. OTOH if your git project already allows storing the data in there, that looks nice ;). I don't yet fully understand how the algorithms of the trees are meant to work (I only understand well the backing store and I tend to prefer DBMS over tree of dirs with hashes). So I've no idea how it can plug in well for a SCM replacement or how you want to use it. It seems a kind of fully lockless thing where you can merge from one tree to the other without locks and where you can make quick diffs. It looks similar to a diff -ur of two hardlinked trees, except this one can save a lot of bandwidth to copy with rsync (i.e. hardlinks becomes worthless after using rsync in the network, but hashes not). Clearly the DBMS couldn't use the rsync binary to distribute the objects, but a network protocol could do the same thing rsync does. 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] Updated: Dynamic Tick version 050408-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tony Lindgren wrote: | * Tony Lindgren [EMAIL PROTECTED] [050407 23:28]: | |I think I have an idea on what's going on; Your system does not wake to |APIC interrupt, and the system timer updates time only on other interrupts. |I'm experiencing the same on a loaner ThinkPad T30. | |I'll try to do another patch today. Meanwhile it now should work |without lapic in cmdline. | | | Following is an updated patch. Anybody having trouble, please try | disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. | | I'm hoping this might work on Pavel's machine too? | | Tony This updated patch seems to work just fine on my machine with lapic on the cmdline and CONFIG_DYN_TICK_USE_APIC disabled. Also, you were correct that removing lapic from the cmdline allowed the previous version to run at full speed. Now, how can I tell if the patch is doing its thing? What should I be seeing? :) Functionally, it looks like it's working. There were a number of compiler warnings you might wish to fix before calling it good. Such as initialization from incompatible pointer type several times in dyn-tick-timer.c and a too many arguments for format in dyn_tick_late_init. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVkWDaI0dwg4A47wRAgzOAKCHcx8p59ZbihYtZJ84p62v2rMauQCfUuzz D7O98hHvjtTa/CvFHHtJe4c= =G2I/ -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ds1337 1/4
Hi Ladislav, Use i2c_transfer to send message, so we get proper bus locking. Looks all OK to me, let alone the lack of Signed-off-by line, as Greg underlined elsewhere. Please resent the patches with the Signed-off-by line after I finish reviewing them. Thanks, -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] ds1337 2/4
Hi Ladislav, Use correct macros to convert between bdc and bin. See linux/bcd.h Yes, this one is OK with me too. Thanks, -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] Updated: Dynamic Tick version 050408-1
* Frank Sorenson [EMAIL PROTECTED] [050408 01:49]: Tony Lindgren wrote: | * Tony Lindgren [EMAIL PROTECTED] [050407 23:28]: | |I think I have an idea on what's going on; Your system does not wake to |APIC interrupt, and the system timer updates time only on other interrupts. |I'm experiencing the same on a loaner ThinkPad T30. | |I'll try to do another patch today. Meanwhile it now should work |without lapic in cmdline. | | | Following is an updated patch. Anybody having trouble, please try | disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. | | I'm hoping this might work on Pavel's machine too? | | Tony This updated patch seems to work just fine on my machine with lapic on the cmdline and CONFIG_DYN_TICK_USE_APIC disabled. Also, you were correct that removing lapic from the cmdline allowed the previous version to run at full speed. Cool. Now, how can I tell if the patch is doing its thing? What should I be seeing? :) Download pmstats from http://www.muru.com/linux/dyntick/, you may need to edit it a bit for correct ACPI battery values. But it should show you HZ during idle and load. I believe idle still does not go to ACPI C3 with dyn-tick though... Then you might as well run timetest from same location too to make sure your clock keeps correct time. Functionally, it looks like it's working. There were a number of compiler warnings you might wish to fix before calling it good. Such as initialization from incompatible pointer type several times in dyn-tick-timer.c and a too many arguments for format in dyn_tick_late_init. Yeah, I'll fix those... Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 SCM saga..
On Fri, 8 Apr 2005, Marcel Lanz wrote:
git on sarge
--- git-0.02/Makefile.orig 2005-04-07 23:06:19.0 +0200
+++ git-0.02/Makefile 2005-04-08 09:24:28.472672224 +0200
@@ -8,7 +8,7 @@ all: $(PROG)
install: $(PROG)
install $(PROG) $(HOME)/bin/
-LIBS= -lssl
+LIBS= -lssl -lz
init-db: init-db.o
I found a few more `issues' after adding `-O3 -Wall'.
Most are cosmetic, but the missing return value in remove_file_from_cache() is
a real bug. Hmm, upon closer look the caller uses its return value in a weird
way, so another bug may be hiding in add_file_to_cache().
Caveat: everything is untested, besides compilation ;-)
diff -purN git-0.02.orig/Makefile git-0.02/Makefile
--- git-0.02.orig/Makefile 2005-04-07 23:06:19.0 +0200
+++ git-0.02/Makefile 2005-04-08 11:02:02.0 +0200
@@ -1,4 +1,4 @@
-CFLAGS=-g
+CFLAGS=-g -O3 -Wall
CC=gcc
PROG=update-cache show-diff init-db write-tree read-tree commit-tree cat-file
@@ -8,7 +8,7 @@ all: $(PROG)
install: $(PROG)
install $(PROG) $(HOME)/bin/
-LIBS= -lssl
+LIBS= -lssl -lz
init-db: init-db.o
diff -purN git-0.02.orig/cat-file.c git-0.02/cat-file.c
--- git-0.02.orig/cat-file.c2005-04-07 23:15:17.0 +0200
+++ git-0.02/cat-file.c 2005-04-08 11:07:28.0 +0200
@@ -5,6 +5,8 @@
*/
#include cache.h
+#include string.h
+
int main(int argc, char **argv)
{
unsigned char sha1[20];
@@ -25,4 +27,5 @@ int main(int argc, char **argv)
if (write(fd, buf, size) != size)
strcpy(type, bad);
printf(%s: %s\n, template, type);
+ exit(0);
}
diff -purN git-0.02.orig/commit-tree.c git-0.02/commit-tree.c
--- git-0.02.orig/commit-tree.c 2005-04-07 23:15:17.0 +0200
+++ git-0.02/commit-tree.c 2005-04-08 11:06:08.0 +0200
@@ -6,6 +6,7 @@
#include cache.h
#include pwd.h
+#include string.h
#include time.h
#define BLOCKING (1ul 14)
diff -purN git-0.02.orig/init-db.c git-0.02/init-db.c
--- git-0.02.orig/init-db.c 2005-04-07 23:15:17.0 +0200
+++ git-0.02/init-db.c 2005-04-08 11:07:33.0 +0200
@@ -5,10 +5,12 @@
*/
#include cache.h
+#include string.h
+
int main(int argc, char **argv)
{
char *sha1_dir = getenv(DB_ENVIRONMENT), *path;
- int len, i, fd;
+ int len, i;
if (mkdir(.dircache, 0700) 0) {
perror(unable to create .dircache);
@@ -25,7 +27,7 @@ int main(int argc, char **argv)
if (sha1_dir) {
struct stat st;
if (!stat(sha1_dir, st) 0 S_ISDIR(st.st_mode))
- return;
+ exit(1);
fprintf(stderr, DB_ENVIRONMENT set to bad directory %s: ,
sha1_dir);
}
diff -purN git-0.02.orig/read-cache.c git-0.02/read-cache.c
--- git-0.02.orig/read-cache.c 2005-04-07 23:23:43.0 +0200
+++ git-0.02/read-cache.c 2005-04-08 11:07:37.0 +0200
@@ -5,6 +5,8 @@
*/
#include cache.h
+#include string.h
+
const char *sha1_file_directory = NULL;
struct cache_entry **active_cache = NULL;
unsigned int active_nr = 0, active_alloc = 0;
@@ -89,7 +91,7 @@ void * read_sha1_file(unsigned char *sha
z_stream stream;
char buffer[8192];
struct stat st;
- int i, fd, ret, bytes;
+ int fd, ret, bytes;
void *map, *buf;
char *filename = sha1_file_name(sha1);
@@ -173,7 +175,7 @@ int write_sha1_file(char *buf, unsigned
int write_sha1_buffer(unsigned char *sha1, void *buf, unsigned int size)
{
char *filename = sha1_file_name(sha1);
- int i, fd;
+ int fd;
fd = open(filename, O_WRONLY | O_CREAT | O_EXCL, 0666);
if (fd 0)
diff -purN git-0.02.orig/read-tree.c git-0.02/read-tree.c
--- git-0.02.orig/read-tree.c 2005-04-08 04:58:44.0 +0200
+++ git-0.02/read-tree.c2005-04-08 11:07:41.0 +0200
@@ -5,6 +5,8 @@
*/
#include cache.h
+#include string.h
+
static void create_directories(const char *path)
{
int len = strlen(path);
@@ -72,7 +74,6 @@ static int unpack(unsigned char *sha1)
int main(int argc, char **argv)
{
- int fd;
unsigned char sha1[20];
if (argc != 2)
diff -purN git-0.02.orig/show-diff.c git-0.02/show-diff.c
--- git-0.02.orig/show-diff.c 2005-04-07 23:15:17.0 +0200
+++ git-0.02/show-diff.c2005-04-08 11:07:44.0 +0200
@@ -5,6 +5,8 @@
*/
#include cache.h
+#include string.h
+
#define MTIME_CHANGED 0x0001
#define CTIME_CHANGED 0x0002
#define OWNER_CHANGED 0x0004
@@ -60,7 +62,6 @@ int main(int argc, char **argv)
struct stat st;
struct cache_entry *ce = active_cache[i];
int n, changed;
- unsigned int mode;
unsigned long size;
char type[20];
void *new;
diff -purN git-0.02.orig/update-cache.c git-0.02/update-cache.c
--- git-0.02.orig/update-cache.c2005-04-07
Re: Signing modules in Kernel 2.4
On Fri, 2005-04-08 at 10:32 +0200, Christoph Pleger wrote: Hello, I found a patch for Kernels 2.6 that ensures kernel integrity by digitally signing kernel modules. Is something similar available for 2.4-Kernels? 2.4 kernels have a userspace insmod. so you would need to have a trusted insmod too. Forget it, just go to 2.6 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
question about init procedure in linux kernel
Hi, I would like to ask why nfs and devfs are initiated in the function filesystem_setup() rather than do in the function do_init_calls()? as i see other filesystem like ext2 are initiated there by init_ext2_fs(). Can anyone tell me why ? Regards, 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/
[PATCH 2.6.12-rc2 1/2] ppc32: fix for misreported SDRAM size on Radstone PPC7D platform
This patch fixes the SDRAM output from /proc/cpuinfo. The previous code assumed that there was only one bank of SDRAM, and that the size in the memory configuration register was the total size. Signed-off-by: Chris Elston [EMAIL PROTECTED] This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ppc7d_sdram_size.patch Description: ppc7d_sdram_size.patch
[PATCH 2.6.12-rc2 2/2] ppc32: add rtc hooks in PPC7D platform file
This patch adds the hooks into the PPC7D platforms file to support the DS1337 RTC device as the clock device for the PPC7D board. Signed-off-by: Chris Elston [EMAIL PROTECTED] This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ppc7d_rtc_hooks.patch Description: ppc7d_rtc_hooks.patch
Re: CCISS problems continue with 2.4.28
Mike, On Fri, 14 Jan 2005 15:07:50 -0600, you wrote: Sorry, I let this one drop though the cracks. Try booting with acpi=off. It appears the interrupt is not being detected properly. If acpi=off works try updating the system ROM. We have been known to have buggy acpi tables. acpi=off works, but the 09/15/2004 P29 flash update to the DL380 G3 (SP28809) doesn't make the problem go away. -- Atro Tossavainen (Mr.) / The Institute of Biotechnology at Systems Analyst, Techno-Amish / the University of Helsinki, Finland, +358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own. URL : http : / / www . helsinki . fi / %7E atossava / NO FILE ATTACHMENTS - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] use cheaper elv_queue_empty when unplug a device
On Wed, Mar 30 2005, Nick Piggin wrote: Nick Piggin wrote: Jens Axboe wrote: Looks good, I've been toying with something very similar for a long time myself. Here is another thing I just noticed that should further reduce the locking by at least 1, sometimes 2 lock/unlock pairs per request. At the cost of uglifying the code somewhat. Although it is pretty nicely contained, so Jens you might consider it acceptable as is, or we could investigate how to make it nicer if Kenneth reports some improvement. Note, this isn't runtime tested - it could easily have a bug. OK - I have booted this on a 4-way SMP with SCSI disks, and done some IO tests, and no hangs. So Kenneth if you could look into this one as well, to see if it is worthwhile, that would be great. For that to work, you have to change the get_io_context() allocation to be GFP_ATOMIC. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Hi, Humberto Massa wrote: First, there is *NOT* any requirement in the GPL at all that requires making compilers available. Otherwise it would not be possible, for instance, have a Visual Basic GPL'd application. And yes, it is possible. From section 3 of the GNU GPL, version 2: The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. I take that to mean the compiler's exempted if it's the normal one available on the platform, but if the software distributor had to modify gcc to produce the binaries it's distributing then you're entitled to the compiler too. So a Visual BASIC application uses a standard VB compiler, but that's not necessarily the case for a Linux kernel running on an embedded box. Cheers, Ralph. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] use cheaper elv_queue_empty when unplug a device
Jens Axboe wrote: On Wed, Mar 30 2005, Nick Piggin wrote: So Kenneth if you could look into this one as well, to see if it is worthwhile, that would be great. For that to work, you have to change the get_io_context() allocation to be GFP_ATOMIC. Yes of course, thanks for picking that up. I guess this isn't a problem, as io contexts should be allocated comparatively rarely. It would be possible to move it out of the lock though if we really want to. Thanks. -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 0/6] add generic round_up_pow2() macro
Andrew Morton wrote:
Nick Wilson [EMAIL PROTECTED] wrote:
The first patch adds a generic round_up_pow2() macro to kernel.h. The
remaining patches modify a few files to make use of the new macro.
We already have ALIGN() and roundup_pow_of_two().
cool. It doesn't handle x={0,1} though.
Maybe we should have:
static inline unsigned long __attribute_const__
__roundup_pow_of_two(unsigned long x)
{
return (1UL fls(x - 1));
}
static inline unsigned long __attribute_const__
roundup_pow_of_two(unsigned long x)
{
return (unlikely(x2)?2:__roundup_pow_of_two(x));
}
--
Pádraig Brady - http://www.pixelbeat.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] use cheaper elv_queue_empty when unplug a device
On Fri, Apr 08 2005, Nick Piggin wrote: Jens Axboe wrote: On Wed, Mar 30 2005, Nick Piggin wrote: So Kenneth if you could look into this one as well, to see if it is worthwhile, that would be great. For that to work, you have to change the get_io_context() allocation to be GFP_ATOMIC. Yes of course, thanks for picking that up. I guess this isn't a problem, as io contexts should be allocated comparatively rarely. It would be possible to move it out of the lock though if we really want to. Lets just keep it inside the lock, for the fast case it should just be an increment of the already existing io context. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] ds1337 3/4
Hi Ladislav,
dev_{dbg,err} functions should print client's device name. data-id can
be dropped from message, because device is determined by bus it hangs on
(it has fixed address).
Looks OK to me.
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ACPI/HT or Packet Scheduler BUG?
I am not subscribed to this list so please CC me if you post a reply, if you need additional info or if you suggest a patch (in which I would be very interested). Occurrence: - the kernels must be compiled with Hyper Threading support (and the CPU/MB must support it); - a (tc) process is reading statistics from the htb tree and another tries to delete or deletes the tree. The bug will not occur if the system is booted with acpi=off or if it's not SMP (HT) capable. I reproduced the bug on 2.6.10-1.770_FCsmp (Fedora Core update package) and vanilla 2.6.11, 2.6.11.5, 2.6.11.6, 2.6.12-rc1 and 2.6.12-rc2 compiled with SMP and ACPI support in order to enable Hyper Threading (with and without preempt, with or without SMT support). The compiler I used is GCC version 3.4.2 (from Fedora Core 3). Result: almost all the time the system hangs but still can execute SysRq commands. How I tested On a console I was running a script that initializes a htb tree on an interface (dummy0) in an endless loop: while /bin/true; do . htbdown.dummy0.sh; done ...and on another console I run tc -s also in an endless loop: while /bin/true; do tc -s class sh dev dummy0; done After a while (sometimes after 2 runs of the htbdown.dummy0.sh script, sometimes after 20) the system hangs. It still responds to SysRq commands and I was able to see the two tc processes running. Sometimes I still have ping replies from it and one time, just one time in 2 days I still was able to log in remotely. There are no printk messages, or no other warnings or errors printed in the system log or kernel log. It just hangs and it seems like something is wasting all the CPU power: when I still was able to log in I noticed that one of the two virtual CPUs was 100% with system interrupts and the other was 100% system. I wasn't able to strace any of the two running tc's. What I was able to paste with the mouse in my console, to catch in a typescript and also the script that initializes the htb tree on dummy0 can be found at ftp://blackblue.iasi.rdsnet.ro/pub/various/k/ . The test host is a 3.0GHz Intel Prescott and I first noticed the bug on a system with a 2.8GHz Intel Northwood, both having motherboards with Intel chipset (865GBF). I am not able to test it in other SMP environments (Intel Xeon or Itanium, AMD Opteron, Dual P3, etc), so I'm not able to tell if it's an ACPI bug, a SMP bug or a Packet Scheduler bug. -- Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise expressly stated. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] use cheaper elv_queue_empty when unplug a device
Jens Axboe wrote: On Fri, Apr 08 2005, Nick Piggin wrote: I guess this isn't a problem, as io contexts should be allocated comparatively rarely. It would be possible to move it out of the lock though if we really want to. Lets just keep it inside the lock, for the fast case it should just be an increment of the already existing io context. Sounds good. -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.12-rc1-mm4] fork_connector: add a fork connector
On Thu, 2005-04-07 at 15:47 -0700, Jay Lan wrote:
BTW, when it happened last time, my program listening to the socket
complained about duplicate messages received.
Unmatched seq. Rcvd=1824062, expected=1824061 ===
Unmatched seq. Rcvd=1824062, expected=1824063 ===
Unmatched seq. Rcvd=1824348, expected=1824307
When my program received 1824062 while expecting 1824061
it adjusted itself to expect the next one being 1824063. But instead
the message of 1824062 arrived the second time.
Thank you for your report.
Could you reproduce a bug with the attached patch?
- jay
* looking for [EMAIL PROTECTED]/connector--main--0--patch-38 to compare with
* comparing to [EMAIL PROTECTED]/connector--main--0--patch-38
M connector.c
* modified files
--- orig/drivers/connector/connector.c
+++ mod/drivers/connector/connector.c
@@ -121,7 +121,7 @@
NETLINK_CB(skb).dst_groups = groups;
uskb = skb_clone(skb, GFP_ATOMIC);
- if (uskb)
+ if (uskb 0)
netlink_unicast(dev-nls, uskb, 0, 0);
netlink_broadcast(dev-nls, skb, 0, groups, GFP_ATOMIC);
@@ -158,7 +158,7 @@
}
spin_unlock_bh(dev-cbdev-queue_lock);
- return found;
+ return (found)?0:-ENODEV;
}
/*
@@ -181,7 +181,6 @@
requested msg-len=%u[%u], nlh-nlmsg_len=%u,
skb-len=%u.\n,
msg-len, NLMSG_SPACE(msg-len + sizeof(*msg)),
nlh-nlmsg_len, skb-len);
- kfree_skb(skb);
return -EINVAL;
}
#if 0
@@ -215,17 +214,18 @@
skb-len, skb-data_len, skb-truesize, skb-protocol,
skb_cloned(skb), skb_shared(skb));
#endif
- while (skb-len = NLMSG_SPACE(0)) {
+ if (skb-len = NLMSG_SPACE(0)) {
nlh = (struct nlmsghdr *)skb-data;
+
if (nlh-nlmsg_len sizeof(struct cn_msg) ||
skb-len nlh-nlmsg_len ||
nlh-nlmsg_len CONNECTOR_MAX_MSG_SIZE) {
-#if 0
+#if 1
printk(KERN_INFO nlmsg_len=%u, sizeof(*nlh)=%u\n,
nlh-nlmsg_len, sizeof(*nlh));
#endif
kfree_skb(skb);
- break;
+ goto out;
}
len = NLMSG_ALIGN(nlh-nlmsg_len);
@@ -233,22 +233,11 @@
len = skb-len;
err = __cn_rx_skb(skb, nlh);
- if (err) {
-#if 0
- if (err 0 (nlh-nlmsg_flags NLM_F_ACK))
- netlink_ack(skb, nlh, -err);
-#endif
- break;
- } else {
-#if 0
- if (nlh-nlmsg_flags NLM_F_ACK)
- netlink_ack(skb, nlh, 0);
-#endif
- break;
- }
- skb_pull(skb, len);
+ if (err 0)
+ kfree_skb(skb);
}
-
+
+out:
kfree_skb(__skb);
}
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
signature.asc
Description: This is a digitally signed message part
Re: [linux-pm] Re: [RFC] Driver States
Hi! You have a few things here that can easily conflict, and that will be developed at different paces. I like the direction that it's going, but how do you intend to do it gradually. I.e. what to do first? I think the first step would be for us to all agree on a design, whether it be this one or another, so we can began planning for long term changes. My arguments for these changes are as follows: 0. I do not see how to gradually roll this in. 4. Having responsibilities at each driver level encourages a layered and object based design, reducing code duplication and complexity. Unfortunately, you'll be retrofiting this to existing drivers. AFAICS, trying to force existing driver to layered and object based design can only result in mess. Pavel Fair enough. How does this sound? I'd like to add *attach and *detach to struct device_driver. These functions would act as one time initializers and decontructors. Then we could rename *probe to *start, and *remove to *stop, which should be rather trivial to I do not think you'll find rename across all the drivers easy. You could get away with I create start, and if it does not exist, probe is called instead, but you need pretty good justification for that, too. Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] Updated: Dynamic Tick version 050408-1
Hi! I think I have an idea on what's going on; Your system does not wake to APIC interrupt, and the system timer updates time only on other interrupts. I'm experiencing the same on a loaner ThinkPad T30. I'll try to do another patch today. Meanwhile it now should work without lapic in cmdline. Following is an updated patch. Anybody having trouble, please try disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. I'm hoping this might work on Pavel's machine too? The volume hang was explained: I was using CPU frequency scaling, it probably did not like that. After disabling CPU frequency scaling, it seems to work ok: Pavel [EMAIL PROTECTED]:~$ cat /proc/interrupts ; sleep 1 ; cat /proc/interrupts CPU0 0: 33288 XT-PIC timer 1: 1021 XT-PIC i8042 2: 0 XT-PIC cascade 9: 2 XT-PIC acpi 10: 94036 XT-PIC yenta, yenta, ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4 11: 3941 XT-PIC Intel 82801DB-ICH4, eth0 12: 17 XT-PIC i8042 14: 5119 XT-PIC ide0 NMI: 0 LOC: 0 ERR: 0 MIS: 0 CPU0 0: 33568 XT-PIC timer 1: 1022 XT-PIC i8042 2: 0 XT-PIC cascade 9: 2 XT-PIC acpi 10: 94323 XT-PIC yenta, yenta, ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4 11: 3951 XT-PIC Intel 82801DB-ICH4, eth0 12: 17 XT-PIC i8042 14: 5192 XT-PIC ide0 NMI: 0 LOC: 0 ERR: 0 MIS: 0 [EMAIL PROTECTED]:~$ -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 0/6] add generic round_up_pow2() macro
[EMAIL PROTECTED] wrote:
Andrew Morton wrote:
Nick Wilson [EMAIL PROTECTED] wrote:
The first patch adds a generic round_up_pow2() macro to kernel.h. The
remaining patches modify a few files to make use of the new macro.
We already have ALIGN() and roundup_pow_of_two().
cool. It doesn't handle x={0,1} though.
Well I should clarify.
2^0==1 is a special case that you probably
don't want as a result from the macro?
--
Pádraig Brady - http://www.pixelbeat.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: 2.6.12-rc2-mm1
Hi! Ok, I've narrowed the problem down to one patch. In 2.6.11-mm3, the problem goes away if I remove this patch: swsusp-enable-resume-from-initrd.patch That really helps, thanks. You're welcome. The patch looks fairly innocent. I'll give up on this and cc the developers. Yeah, it *seemed* innocent enough -- that's why I had to do a binary search on the 2.6.11-mm3 series file in order to find it as the culprit... Do you have XFS compiled in, by chance? You are not actually resuming from initrd, right? Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.12-rc1-mm4] fork_connector: add a fork connector
Could you give attached patch a try instead of previous one.
It adds gfp mask into cn_netlink_send() call also.
If you need updated CBUS sources, feel free to ask,
I will send updated sources with Andrew's comments resolved too.
I do not know exactly your connector version,
so patch will probably be applied with fuzz.
feel free to contact if it does not apply, I will send
the whole sources.
Thank you.
* looking for [EMAIL PROTECTED]/connector--main--0--patch-38 to compare with
* comparing to [EMAIL PROTECTED]/connector--main--0--patch-38
M connector.c
M connector.h
M cbus.c
* modified files
--- orig/drivers/connector/connector.c
+++ mod/drivers/connector/connector.c
@@ -70,7 +70,7 @@
* then it is new message.
*
*/
-void cn_netlink_send(struct cn_msg *msg, u32 __groups)
+void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask)
{
struct cn_callback_entry *n, *__cbq;
unsigned int size;
@@ -102,7 +102,7 @@
size = NLMSG_SPACE(sizeof(*msg) + msg-len);
- skb = alloc_skb(size, GFP_ATOMIC);
+ skb = alloc_skb(size, gfp_mask);
if (!skb) {
printk(KERN_ERR Failed to allocate new skb with size=%u.\n,
size);
return;
@@ -119,11 +119,11 @@
#endif
NETLINK_CB(skb).dst_groups = groups;
-
- uskb = skb_clone(skb, GFP_ATOMIC);
- if (uskb)
+#if 0
+ uskb = skb_clone(skb, gfp_mask);
+ if (uskb 0)
netlink_unicast(dev-nls, uskb, 0, 0);
-
+#endif
netlink_broadcast(dev-nls, skb, 0, groups, GFP_ATOMIC);
return;
@@ -158,7 +158,7 @@
}
spin_unlock_bh(dev-cbdev-queue_lock);
- return found;
+ return (found)?0:-ENODEV;
}
/*
@@ -181,7 +181,6 @@
requested msg-len=%u[%u], nlh-nlmsg_len=%u,
skb-len=%u.\n,
msg-len, NLMSG_SPACE(msg-len + sizeof(*msg)),
nlh-nlmsg_len, skb-len);
- kfree_skb(skb);
return -EINVAL;
}
#if 0
@@ -215,17 +214,18 @@
skb-len, skb-data_len, skb-truesize, skb-protocol,
skb_cloned(skb), skb_shared(skb));
#endif
- while (skb-len = NLMSG_SPACE(0)) {
+ if (skb-len = NLMSG_SPACE(0)) {
nlh = (struct nlmsghdr *)skb-data;
+
if (nlh-nlmsg_len sizeof(struct cn_msg) ||
skb-len nlh-nlmsg_len ||
nlh-nlmsg_len CONNECTOR_MAX_MSG_SIZE) {
-#if 0
+#if 1
printk(KERN_INFO nlmsg_len=%u, sizeof(*nlh)=%u\n,
nlh-nlmsg_len, sizeof(*nlh));
#endif
kfree_skb(skb);
- break;
+ goto out;
}
len = NLMSG_ALIGN(nlh-nlmsg_len);
@@ -233,22 +233,11 @@
len = skb-len;
err = __cn_rx_skb(skb, nlh);
- if (err) {
-#if 0
- if (err 0 (nlh-nlmsg_flags NLM_F_ACK))
- netlink_ack(skb, nlh, -err);
-#endif
- break;
- } else {
-#if 0
- if (nlh-nlmsg_flags NLM_F_ACK)
- netlink_ack(skb, nlh, 0);
-#endif
- break;
- }
- skb_pull(skb, len);
+ if (err 0)
+ kfree_skb(skb);
}
-
+
+out:
kfree_skb(__skb);
}
@@ -310,7 +299,7 @@
m.ack = notify_event;
memcpy(m.id, id, sizeof(m.id));
- cn_netlink_send(m, ctl-group);
+ cn_netlink_send(m, ctl-group, GFP_ATOMIC);
}
}
spin_unlock_bh(notify_lock);
--- orig/include/linux/connector.h
+++ mod/include/linux/connector.h
@@ -148,7 +148,7 @@
int cn_add_callback(struct cb_id *, char *, void (* callback)(void *));
void cn_del_callback(struct cb_id *);
-void cn_netlink_send(struct cn_msg *, u32);
+void cn_netlink_send(struct cn_msg *, u32, int);
int cn_queue_add_callback(struct cn_queue_dev *dev, struct cn_callback *cb);
void cn_queue_del_callback(struct cn_queue_dev *dev, struct cb_id *id);
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] Updated: Dynamic Tick version 050408-1
* Pavel Machek [EMAIL PROTECTED] [050408 03:30]: Hi! I think I have an idea on what's going on; Your system does not wake to APIC interrupt, and the system timer updates time only on other interrupts. I'm experiencing the same on a loaner ThinkPad T30. I'll try to do another patch today. Meanwhile it now should work without lapic in cmdline. Following is an updated patch. Anybody having trouble, please try disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. I'm hoping this might work on Pavel's machine too? The volume hang was explained: I was using CPU frequency scaling, it probably did not like that. After disabling CPU frequency scaling, it seems to work ok: OK, good. I assume this was the same machine that did not work with any of the earlier patches? Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] ds1337 4/4
Hi Ladislav,
Add support for DS1339. The only difference against DS1337 is Trickle
Charge register at address 10h, which is used to enable battery or gold
cap charging. Please note that value may vary for different batteries,
so it should be made module parameter. 0xaa is sane default and also
matches my board ;-)
Sane default is a non-sense here. A sane default is that loading a
real-time clock driver should not affect the battery at all IMHO.
Can you tell us more on that battery thing? I admit I don't exatcly get
what it is. Which type of battery are we talking about? Are there
similar drivers in the kernel tree already?
Sounds weird to me that loading a driver would enable charging of a
battery, and removing it wouldn't disable it. And since the driver
might not be removed, it would possibly make more sense to have an entry
in /sys to enable and disable this thing.
Also, arbitrarily picking one of the 6 possible charging modes just
because it matches your board is a bad idea. It looks like a value which
should be set on a per-board basis, rather than picked randomly by the
user, so as to avoid accidental hardware breakage.
+static int ds1339_charge = 0xaa;
I see little reason why this would be a global variable rather than a
define (let alone the fact that this shouldn't be hardcoded at all
IMHO, as I just explained).
+/*
+ * DS1339 has Trickle Charge register at address 10h. During a multibyte
+ * access, when the address pointer reaches the end of the register space,
+ * it wraps around to location 00h.
+ * We read 17 bytes from device and compare first and last one. If they
+ * are same it is most likely DS1337 chip.
+ */
+static int ds1337_is_ds1339(struct i2c_client *client)
+{
+ char buf[17], addr = 0;
+ struct i2c_msg msg[2];
+ int result;
+
+ msg[0].addr = client-addr;
+ msg[0].flags = 0;
+ msg[0].len = 1;
+ msg[0].buf = addr;
+
+ msg[1].addr = client-addr;
+ msg[1].flags = I2C_M_RD;
+ msg[1].len = sizeof(buf);
+ msg[1].buf = buf;
+
+ result = i2c_transfer(client-adapter, msg, 2);
+ if (result 0) {
+ dev_err(client-dev, error reading data! %d\n, result);
+ return 0;
+ } else
+ return (buf[0] == buf[16]) ? 0 : 1;
+}
This will fail eventually. The first register is the seconds count, which
by definition is changing. I2C is slow, by the time you wrap over the
register range, the value could have changed. The datasheet explicitely
says that the register cache will refresh on address wrapping.
Also, 0x00 is a possible value for both the seconds count and the battery
register, so you could miss a DS1339 at times.
One possible check to start with would be on the value of the additional
register itself. It has only 7 possible values. But of course it would
be better if we could default to a DS1337 and find a way to identify the
DS1339, rather than the (unsafe) other way around. I also don't know
what a DS1337 will answer for this missing register. Maybe James can
help?
One possibility would be to start reading at 0x0E instead of 0x00,
because register 0x00 is the control register and is the only one which
will not change in our back as far as I can see. Oh, and the additional
battery register too. But this still doesn't sound like a bulletproof
method to me (we depend on the seconds and possibly minutes count
again). So it would be better to additionally perform the same tests
that were done on the non-wrapped registers for the regular DS1337
detection, but on the wrapped area.
The problem here is that all this will significantly increase the
detection delay.
Yet another method would be to write a non-significant value to the
battery register, such as 0x80. If we can read it back then it has to be
a DS1339. But what effect will it have on the DS1337? I'd hope none,
but this better be verified. And in general I don't much like using
register writes in detection methods.
Could you please provide the output of i2cdump in b and c modes for your
DS1339 chip? This might help finding an detection method. A similar dump
for the DS1337 would help too.
- const char *name = ;
+ const char *name;
(...)
+ default:
+ name = ;
+ }
This is noise.
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, 8 April 2005 09:22:00 +0200, Josselin Mouette wrote: Le jeudi 07 avril 2005 à 23:07 +0200, Adrian Bunk a écrit : As a contrast, read the discussion between Christoph and Arjan in a part of this thread how to move firmware out of kernel drivers without problems for the users. This might not happen today, but it's better for the users. Some Debian developers have been writing such patches so that we can still run Linux on this hardware, long before the topic was raised on the LKML. I can point you to dozens of patches I have written that were never merged. Not because Linus is a d*ckhead (he's not), but because they were not good enough then and I didn't spend the time to improve them, so far. Someone's written some patches is a long way from we have a good solution. Jörn -- You cannot suppose that Moliere ever troubled himself to be original in the matter of ideas. You cannot suppose that the stories he tells in his plays have never been told before. They were culled, as you very well know. -- Andre-Louis Moreau in Scarabouche - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] Updated: Dynamic Tick version 050408-1
Frank Sorenson wrote: Tony Lindgren wrote: | * Tony Lindgren [EMAIL PROTECTED] [050407 23:28]: | |I think I have an idea on what's going on; Your system does not wake to |APIC interrupt, and the system timer updates time only on other interrupts. |I'm experiencing the same on a loaner ThinkPad T30. | |I'll try to do another patch today. Meanwhile it now should work |without lapic in cmdline. | | | Following is an updated patch. Anybody having trouble, please try | disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. | | I'm hoping this might work on Pavel's machine too? | | Tony This updated patch seems to work just fine on my machine with lapic on the cmdline and CONFIG_DYN_TICK_USE_APIC disabled. Also, you were correct that removing lapic from the cmdline allowed the previous version to run at full speed. Now, how can I tell if the patch is doing its thing? What should I be seeing? :) Functionally, it looks like it's working. There were a number of compiler warnings you might wish to fix before calling it good. Such as initialization from incompatible pointer type several times in dyn-tick-timer.c and a too many arguments for format in dyn_tick_late_init. Here are some figures about idle/C-states: Passing bm_history=0xF to processor module makes it going into C3 and deeper. Passing lower values, deeper states are reached more often, but system could freeze: bm_activity=0x4 bus master activity: fefd states: C1: type[C1] promotion[C2] demotion[--] latency[001] usage[0010] *C2: type[C2] promotion[C3] demotion[C1] latency[001] usage[7183] C3: type[C3] promotion[C4] demotion[C2] latency[085] usage[0515] C4: type[C3] promotion[--] demotion[C3] latency[185] usage[0330] bm_activity=0x1 bus master activity: 7ffd states: C1: type[C1] promotion[C2] demotion[--] latency[001] usage[0010] *C2: type[C2] promotion[C3] demotion[C1] latency[001] usage[5495] C3: type[C3] promotion[C4] demotion[C2] latency[085] usage[0537] C4: type[C3] promotion[--] demotion[C3] latency[185] usage[0472] Figures NO_IDLE_HZ disabled, HZ=1000 (max sleep 1ms) (Don't trust the figures too much, there probably are little bugs...): Active C0/C1 state: Total(ms):145 Usage:20205 Failures: 0 Maximum(us): 1967 Average(us): 7 Sleep C2 state: Total(ms):19306 Usage:20074 Failures: 0 Maximum(us): 1275(- strange max should be 1000us) Average(us): 961 Sleep C3 state: Total(ms):34 Usage:131 Failures: 0 Maximum(us): 984 Average(us): 259 Measures based on ACPI PM timer reads Total switches between C-states: 20205 Switches between C-states per second: 1063 per second Total measure time (s): 19 Total measure time (based on starting measures) (s): 20 Figures NO_IDLE_HZ enabled, processor.bm_history=0xF HZ=1000: (Don't trust the figures too much, there probably are little bugs...): Active C0/C1 state: Total(ms):81 Usage:4659 Failures: 0 Maximum(us): 1608 Average(us): 17 Sleep C2 state: Total(ms):71108 Usage:4241 Failures: 0 Maximum(us): 49921 Average(us): 16766 Sleep C3 state: Total(ms):219 Usage:167 Failures: 0 Maximum(us): 28296 Average(us): 1311 Sleep C4 state: Total(ms):374 Usage:251 Failures: 0 Maximum(us): 18870 Average(us): 1490 Measures based on ACPI PM timer reads Total switches between C-states: 4659 Switches between C-states per second: 65 per second Total measure time (s): 71 Total measure time (based on starting measures) (s): 75 I buffer C-state times in an array and write them to /dev/cstX. From there I calc the stats from userspace. Tony: If you like I can send you the patch and dump prog for http://www.muru.com/linux/dyntick/ ? I try to find a better algorithm (directly adjust slept time to C-state latency or something) for NO_IDLE_HZ (hints are very welcome) and try to come up with new figures soon. Thomas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 SCM saga..
Chris Wedgwood [EMAIL PROTECTED] wrote: I'm playing with monotone right now. Superficially it looks like it has tons of gee-whiz neato stuff... however, it's *agonizingly* slow. I mean glacial. A heavily sedated sloth with no legs is probably faster. I tried some time ago to import the BKCVS revisions since Linux 2.6.9 into a monotone-0.16 repository. I later tried to upgrade the database (repository) to monotone version 0.17. The result - converting ~3500 revisions would have taken more than *one year*, fact confirmed by the monotone developers. The bottleneck seemed to be the big size of the manifest (which stores the file names and the corresponding SHA1 values) and all the validation performed when converting. The solution, unsafe, is to disable the revision checks in monotone but you can end up with an inconsistent repository (haven't tried this). -- Catalin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm2
On Friday, 8 of April 2005 12:08, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm2/ - Although small, bk-audit.patch was causing conflits with a couple of other projects. Dropped for now. - Greg is not using bk now, so bk-pci.patch, bk-i2c.patch, bk-driver-core.patch and bk-usb.patch have been replaced with gregkh-*.patch in -mm. - Largeish x86_64 update It does not compile on a uniprocessor x86-64: CC arch/x86_64/kernel/process.o CC arch/x86_64/kernel/semaphore.o CC arch/x86_64/kernel/signal.o AS arch/x86_64/kernel/entry.o CC arch/x86_64/kernel/traps.o CC arch/x86_64/kernel/irq.o CC arch/x86_64/kernel/ptrace.o CC arch/x86_64/kernel/time.o CC arch/x86_64/kernel/ioport.o CC arch/x86_64/kernel/ldt.o CC arch/x86_64/kernel/setup.o arch/x86_64/kernel/setup.c: In function `amd_detect_cmp': arch/x86_64/kernel/setup.c:759: error: `cpu_core_id' undeclared (first use in this function) arch/x86_64/kernel/setup.c:759: error: (Each undeclared identifier is reported only once arch/x86_64/kernel/setup.c:759: error: for each function it appears in.) make[1]: *** [arch/x86_64/kernel/setup.o] Error 1 make: *** [arch/x86_64/kernel] Error 2 Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm2
Hello Andrew, along the 2.6.12-rcX-mmX PCI-Express is not usable at all with mm-patchsets. I posted some days ago the problem taht the IRQs get not regonized by the kernel also with pci=routeirq nothing helped. The problem still the same and some new problems now with 2.6.12-rc2-mm2 in addition. This computer has an Intel Pentium 4 630 with HT,EIST and EMT64 enabled. In 2.6.12-rc2 everything works perfect. So I post my dmesg output maybe you can see some interesting things there. I hope you'll find the issue or bug..whatever hope that its possible to sort the problems out. Thanks in Advanced Now I post the 2.6.12-rc2-mm2 and after that the 2.6.12-rc2 vanilla kernel output 2.6.12-rc2-mm2 output: Bootdata ok (command line is root=/dev/md1 vga=794 quiet) Linux version 2.6.12-rc2-mm2-md1 ([EMAIL PROTECTED]) (gcc-Version 3.4.3 20041125 (Gentoo Linux 3.4.3-r1, ssp-3.4.3-0, pie-8.7.7)) #2 SMP PREEMPT Fri Apr 8 13:35:42 CEST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - 3ffb (usable) BIOS-e820: 3ffb - 3ffbe000 (ACPI data) BIOS-e820: 3ffbe000 - 3fff (ACPI NVS) BIOS-e820: 3fff - 4000 (reserved) BIOS-e820: ffb0 - 0001 (reserved) ACPI: RSDP (v002 ACPIAM) @ 0x000fafa0 ACPI: XSDT (v001 A M I OEMXSDT 0x02000503 MSFT 0x0097) @ 0x3ffb0100 ACPI: FADT (v003 A M I OEMFACP 0x02000503 MSFT 0x0097) @ 0x3ffb0290 ACPI: MADT (v001 A M I OEMAPIC 0x02000503 MSFT 0x0097) @ 0x3ffb0390 ACPI: OEMB (v001 A M I AMI_OEM 0x02000503 MSFT 0x0097) @ 0x3ffbe040 ACPI: MCFG (v001 A M I OEMMCFG 0x02000503 MSFT 0x0097) @ 0x3ffb6c40 ACPI: DSDT (v001 A0144 A0144000 0x INTL 0x02002026) @ 0x On node 0 totalpages: 262064 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 257968 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 16 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:4 APIC version 16 ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 4000 (gap: 4000:bfb0) Built 1 zonelists Initializing CPU#0 Kernel command line: root=/dev/md1 vga=794 quiet console=tty0 PID hash table entries: 4096 (order: 12, 131072 bytes) time.c: Using 1.193182 MHz PIT timer. time.c: Detected 3527.408 MHz processor. Console: colour dummy device 80x25 Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Memory: 1024964k/1048256k available (3240k kernel code, 22664k reserved, 1218k data, 212k init) Calibrating delay loop... 6963.20 BogoMIPS (lpj=3481600) Security Framework v1.0.0 initialized Capability LSM initialized Mount-cache hash table entries: 256 CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 2048K using mwait in idle threads. CPU: Physical Processor ID: 0 CPU0: Thermal monitoring enabled (TM1) Using IO APIC NMI watchdog activating NMI Watchdog ... done. Using local APIC timer interrupts. Detected 13.778 MHz APIC timer. Booting processor 1/1 rip 6000 rsp 81003ff35f58 Initializing CPU#1 Calibrating delay loop... 7045.12 BogoMIPS (lpj=3522560) CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 2048K CPU: Physical Processor ID: 0 CPU1: Thermal monitoring enabled (TM1) Intel(R) Pentium(R) 4 CPU 3.20GHz stepping 03 Synced TSC of CPU 1 difference 107374180328 APIC error on CPU1: 00(40) Brought up 2 CPUs time.c: Using PIT/TSC based timekeeping. CPU0 attaching sched-domain: domain 0: span 3 groups: 1 2 CPU1 attaching sched-domain: domain 0: span 3 groups: 2 1 NET: Registered protocol family 16 PCI: Using configuration type 1 PCI: Using MMCONFIG at e000 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050309 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] segment is 0 PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 Boot video device is :04:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Can't get handler for
Re: [PATCH] Updated: Dynamic Tick version 050408-1
* Thomas Renninger [EMAIL PROTECTED] [050408 04:34]: Here are some figures about idle/C-states: Passing bm_history=0xF to processor module makes it going into C3 and deeper. Passing lower values, deeper states are reached more often, but system could freeze: Hmm, I wonder why it freezes? Is it ACPI issue or related to dyn-tick? Figures NO_IDLE_HZ disabled, HZ=1000 (max sleep 1ms) ... Total switches between C-states: 20205 Switches between C-states per second: 1063 per second Figures NO_IDLE_HZ enabled, processor.bm_history=0xF HZ=1000: ... Total switches between C-states: 4659 Switches between C-states per second: 65 per second The reduction in C state changes should produce some power savings, assuming the C states do something... I buffer C-state times in an array and write them to /dev/cstX. From there I calc the stats from userspace. Tony: If you like I can send you the patch and dump prog for http://www.muru.com/linux/dyntick/ ? Yeah, that would nice to have! I try to find a better algorithm (directly adjust slept time to C-state latency or something) for NO_IDLE_HZ (hints are very welcome) and try to come up with new figures soon. I suggest we modify idle so we can call it with the estimated sleep length in usecs. Then the idle loop can directly decide when to go to C2 or C3 depening on the estimated sleep length. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] 2.6.12-rc1/rc2 mouse0 became mouse1
Hello, This doesn't sound right to me. After upgrading from 2.6.11.5/6 to 2.6.12-rc1/rc2 I detected that my mouse didn't operate anymore when loading up XOrg, I realized that /dev/input/mouse0 (which worked for years) had to be changed to /dev/input/mouse1. Anyone care to explain why this had to be changed or what the intention behind this was ? greetings, Ali Akcaagac - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 SCM saga..
Andrea Arcangeli schrieb am 2005-04-08:
On Thu, Apr 07, 2005 at 09:42:04PM -0700, Linus Torvalds wrote:
play with something _really_ nasty (but also very _very_ fast), take a
look at kernel.org:/pub/linux/kernel/people/torvalds/.
Why not to use sql as backend instead of the tree of directories? That solves
userland journaling too (really one still has to be careful to know the
read-committed semantics of sql, which is not obvious stuff, but 99% of
common cases like this one just works safe automatically since all
inserts/delete/update are always atomic).
You can keep the design of your db exactly the same and even the command line
of your script the same, except you won't have deal with the implementation of
it anymore, and the end result may run even faster with proper btrees and you
won't have scalability issues if the directory of hashes fills up, and it'll
get userland journaling, live backups, runtime analyses of your queries with
genetic algorithms (pgsql 8 seems to have it) etc...
I seem to recall there's a way to do delayed commits too, so you won't
be sychronous, but you'll still have journaling. You clearly don't care
to do synchronous writes, all you care about is that the commit is
either committed completely or not committed at all (i.e. not an half
write of the patch that leaves your db corrupt).
Example:
CREATE TABLE patches (
patch BIGSERIAL PRIMARY KEY,
commiter_name VARCHAR(32) NOT NULL CHECK(commiter_name !=
''),
commiter_email VARCHAR(32) NOT NULL CHECK(commiter_email
!= ''),
The length is too optimistic and insufficient to import the current BK
stuff. I'd vote for 64 or at least 48 for each, although 48 is going to
be a tight fit. It costs a bit but considering the expected payload
size it's irrelevant.
Committer (double t) email is up to 36 characters at the moment and the
name up to 43 characters when analyzing the shortlog script with this
little Perl snippet:
while (($k, $v) = each %addresses) {
$lk = length $k;
$lv = length $v;
if ($lk $mk) { $mk = $lk; }
if ($lv $mv) { $mv = $lv; }
}
print max key len $mk, max val len $mv\n;
which prints: (key is the email, val the name)
max key len 43, max val len 36
--
Matthias Andree
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] pm_message_t corrections still missing from 2.6.12-rc2
Hi.
Here, for your consideration, are fixups I still have in my tree after
updating to rc2.
(USB Framebuffer lists copied because a reasonable number apply
there).
Regards,
Nigel
diff -ruNp
840-combined-pm_message_t-patch.patch-old/drivers/base/power/resume.c
840-combined-pm_message_t-patch.patch-new/drivers/base/power/resume.c
--- 840-combined-pm_message_t-patch.patch-old/drivers/base/power/resume.c
2004-12-10 14:26:51.0 +1100
+++ 840-combined-pm_message_t-patch.patch-new/drivers/base/power/resume.c
2005-04-08 13:41:41.0 +1000
@@ -41,7 +41,7 @@ void dpm_resume(void)
list_add_tail(entry, dpm_active);
up(dpm_list_sem);
- if (!dev-power.prev_state)
+ if (!dev-power.prev_state.event)
resume_device(dev);
down(dpm_list_sem);
put_device(dev);
diff -ruNp
840-combined-pm_message_t-patch.patch-old/drivers/base/power/runtime.c
840-combined-pm_message_t-patch.patch-new/drivers/base/power/runtime.c
--- 840-combined-pm_message_t-patch.patch-old/drivers/base/power/runtime.c
2005-02-03 22:33:23.0 +1100
+++ 840-combined-pm_message_t-patch.patch-new/drivers/base/power/runtime.c
2005-04-08 13:41:41.0 +1000
@@ -13,10 +13,10 @@
static void runtime_resume(struct device * dev)
{
dev_dbg(dev, resuming\n);
- if (!dev-power.power_state)
+ if (!dev-power.power_state.event)
return;
if (!resume_device(dev))
- dev-power.power_state = 0;
+ dev-power.power_state = PMSG_ON;
}
@@ -49,10 +49,10 @@ int dpm_runtime_suspend(struct device *
int error = 0;
down(dpm_sem);
- if (dev-power.power_state == state)
+ if (dev-power.power_state.event == state.event)
goto Done;
- if (dev-power.power_state)
+ if (dev-power.power_state.event)
runtime_resume(dev);
if (!(error = suspend_device(dev, state)))
diff -ruNp
840-combined-pm_message_t-patch.patch-old/drivers/base/power/shutdown.c
840-combined-pm_message_t-patch.patch-new/drivers/base/power/shutdown.c
--- 840-combined-pm_message_t-patch.patch-old/drivers/base/power/shutdown.c
2004-11-03 21:54:14.0 +1100
+++ 840-combined-pm_message_t-patch.patch-new/drivers/base/power/shutdown.c
2005-04-08 13:41:41.0 +1000
@@ -29,7 +29,8 @@ int device_detach_shutdown(struct device
dev-driver-shutdown(dev);
return 0;
}
- return dpm_runtime_suspend(dev, dev-detach_state);
+ /* FIXME */
+ return dpm_runtime_suspend(dev, PMSG_FREEZE);
}
diff -ruNp
840-combined-pm_message_t-patch.patch-old/drivers/base/power/suspend.c
840-combined-pm_message_t-patch.patch-new/drivers/base/power/suspend.c
--- 840-combined-pm_message_t-patch.patch-old/drivers/base/power/suspend.c
2005-04-08 12:35:14.0 +1000
+++ 840-combined-pm_message_t-patch.patch-new/drivers/base/power/suspend.c
2005-04-08 13:41:41.0 +1000
@@ -43,7 +43,7 @@ int suspend_device(struct device * dev,
dev-power.prev_state = dev-power.power_state;
- if (dev-bus dev-bus-suspend !dev-power.power_state)
+ if (dev-bus dev-bus-suspend (!dev-power.power_state.event))
error = dev-bus-suspend(dev, state);
return error;
diff -ruNp 840-combined-pm_message_t-patch.patch-old/drivers/base/power/sysfs.c
840-combined-pm_message_t-patch.patch-new/drivers/base/power/sysfs.c
--- 840-combined-pm_message_t-patch.patch-old/drivers/base/power/sysfs.c
2004-11-03 21:55:04.0 +1100
+++ 840-combined-pm_message_t-patch.patch-new/drivers/base/power/sysfs.c
2005-04-08 13:41:41.0 +1000
@@ -26,19 +26,20 @@
static ssize_t state_show(struct device * dev, char * buf)
{
- return sprintf(buf, %u\n, dev-power.power_state);
+ return sprintf(buf, %u\n, dev-power.power_state.event);
}
static ssize_t state_store(struct device * dev, const char * buf, size_t n)
{
- u32 state;
+ pm_message_t state;
char * rest;
int error = 0;
- state = simple_strtoul(buf, rest, 10);
+ state.event = simple_strtoul(buf, rest, 10);
+ state.flags = PFL_RUNTIME;
if (*rest)
return -EINVAL;
- if (state)
+ if (state.event)
error = dpm_runtime_suspend(dev, state);
else
dpm_runtime_resume(dev);
diff -ruNp 840-combined-pm_message_t-patch.patch-old/drivers/ide/ide.c
840-combined-pm_message_t-patch.patch-new/drivers/ide/ide.c
--- 840-combined-pm_message_t-patch.patch-old/drivers/ide/ide.c 2005-04-08
16:46:36.0 +1000
+++ 840-combined-pm_message_t-patch.patch-new/drivers/ide/ide.c 2005-04-08
13:41:41.0 +1000
@@ -1385,7 +1385,7 @@ static int generic_ide_suspend(struct de
rq.special = args;
rq.pm = rqpm;
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Adrian Bunk wrote: Debian doesn't seem to care much about the possible legal problems of patents. The possible legal problem of software patents is, up to the present time, AFAICT, not producing effects yet in Europe, and is a non-problem in jurisdictions like mine (down here neither business methods nor software are patentable). The firmware issues are an urgent real problem? OTOH, the firmware issues *is* a legal real problem (copyright infringement is even a criminal offense in a lot of juristictions -- down here, 6 months to 2 years of soft jail + fine for non-commercial and 2 to 4 years of hard-jail + fine for commercial intents). Debian should define how much legal risk they are willing to impose on their mirrors and distributors and should act accordingly in all areas. You are right, but as I told you, the mirrors are really worse when there is a chance of copyrights infringement than of patents infringement -- even on those jurisdictions that *have* software patents, things are more difficult to prosecute in the patent field. But ignoring some areas while being more religious than RMS in other areas is simply silly. Conceded. You are right on this. HTH, Massa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
buggy ia64_fls() ? (was Re: /dev/random problem on 2.6.12-rc1)
On Fri, 8 Apr 2005, Matt Mackall wrote:
On Fri, Apr 08, 2005 at 08:56:51AM +0200, Simon Derr wrote:
On Thu, 7 Apr 2005, Matt Mackall wrote:
On Thu, Apr 07, 2005 at 05:36:59PM +0200, Simon Derr wrote:
I run:
# dd if=/dev/random bs=1 count=1 | od
strace the dd process, please. This works fine here.
As expected, dd is waiting in:
read(0, 0x60014000, 1)
with fd 0 being /dev/random.
About /proc/sys/kernel/random/entropy_avail:
(5 second refresh interval)
That may not be sufficient resolution. The upper layers will pull from
it whenever it rises above 64 and bash it back down to within 7 bits
of 0. What does it do when no one is reading from it?
Oh, you're right.
with 1/100 sec (or so) resolution, things look like:
(with nobody reading /dev/random, this time)
* usually zero, lots of zero
* sometimes things such as:
0 0 0 1 0 0 0 0 0 0 0 2 0 0 0 1 0 4 1 0 0 0 1 2 2 2 0 2 0 0 0 0 3 0 0 0
or even
0 0 0 1 0 0 3 2 0 2 0 0 0 0 0 0 0 0 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 9 0
Other values:
poolsize:4096
read_wakeup_threshold:64
write_wakeup_threshold:128
I enabled the debug messages in random.c and I think I found the problem
lying in the IA64 version of fls().
It turns out that the generic and IA64 versions of fls() disagree:
(output from a small test program)
x ia64_fls(x) generic_fls(x)
i=-1, t=0, ia64: -65535 et generic:0
i=0, t=1, ia64: 0 et generic:1
i=1, t=2, ia64: 1 et generic:2
i=2, t=4, ia64: 2 et generic:3
i=3, t=8, ia64: 3 et generic:4
i=4, t=16, ia64: 4 et generic:5
i=5, t=32, ia64: 5 et generic:6
i=6, t=64, ia64: 6 et generic:7
i=7, t=128, ia64: 7 et generic:8
i=8, t=256, ia64: 8 et generic:9
i=9, t=512, ia64: 9 et generic:10
i=10, t=1024, ia64: 10 et generic:11
i=11, t=2048, ia64: 11 et generic:12
i=12, t=4096, ia64: 12 et generic:13
i=13, t=8192, ia64: 13 et generic:14
i=14, t=16384, ia64: 14 et generic:15
i=15, t=32768, ia64: 15 et generic:16
i=16, t=65536, ia64: 16 et generic:17
i=17, t=131072, ia64: 17 et generic:18
i=18, t=262144, ia64: 18 et generic:19
i=19, t=524288, ia64: 19 et generic:20
i=20, t=1048576, ia64: 20 et generic:21
i=21, t=2097152, ia64: 21 et generic:22
i=22, t=4194304, ia64: 22 et generic:23
i=23, t=8388608, ia64: 23 et generic:24
i=24, t=16777216, ia64: 24 et generic:25
i=25, t=33554432, ia64: 25 et generic:26
i=26, t=67108864, ia64: 26 et generic:27
i=27, t=134217728, ia64: 27 et generic:28
i=28, t=268435456, ia64: 28 et generic:29
i=29, t=536870912, ia64: 29 et generic:30
i=30, t=1073741824, ia64: 30 et generic:31
i=31, t=-2147483648, ia64: 31 et generic:32
i=32, t=0, ia64: -65535 et generic:0
...
I tried to fix it with an ia64 version that would give the same result as
the generic version, but the kernel did not boot, I guess some functions
rely on the broken ia64_fls() behaviour.
So I just changed fls() to use generic_fls() instead of ia64_fls().
(Patch below).
And /dev/random seems to work again.
Simon.
Signed-Off-By: Simon Derr [EMAIL PROTECTED]
Index: linux-2.6.11/include/asm-ia64/bitops.h
===
--- linux-2.6.11.orig/include/asm-ia64/bitops.h 2005-04-08 14:07:46.826191877
+0200
+++ linux-2.6.11/include/asm-ia64/bitops.h 2005-04-08 14:08:09.750996284
+0200
@@ -327,11 +327,7 @@ ia64_fls (unsigned long x)
return exp - 0x;
}
-static inline int
-fls (int x)
-{
- return ia64_fls((unsigned int) x);
-}
+#define fls(x) generic_fls(x)
/*
* ffs: find first bit set. This is defined the same way as the libc and
compiler builtin
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] sched: unlocked context-switches
the scheduler still has a complex maze of locking in the *arch_switch()
/ *lock_switch() code. Different arches do it differently, creating
diverging context-switch behavior. There are now 3 variants: fully
locked, unlocked but irqs-off, unlocked and irqs-on.
Nick has cleaned them up in sched-cleanup-context-switch-locking.patch,
but i'm still not happy with the end result. So here's a more radical
approach: do all context-switching without the runqueue lock held and
with interrupts enabled.
the patch below (which is against Andrew's current scheduler queue) thus
unifies all arches and greatly simplifies things:
9 files changed, 83 insertions(+), 236 deletions(-)
other details:
- switched the order of stack/register-switching and MM-switching: we
now first switch the stack and registers, this further simplified
things.
- introduced set_task_on_cpu/task_on_cpu to unify -oncpu and
task_running naming and to simplify usage. Did s/oncpu/on_cpu.
- dropped rq-prev_mm - it's now all straight code in one function.
- moved Sparc/Sparc64's prepare_arch_switch() code to the head of
their switch_to() macros, and s390's finish_arch_switch() to
the tail of switch_to().
tested on x86, and all other arches should work as well, but if an
architecture has irqs-off assumptions in its switch_to() logic it might
break. (I havent found any but there may such assumptions.)
i've measured no regressions in context-switch performance (lat_ctx,
hackbench), on a UP x86 and an 8-way SMP x86 box. Tested it on
PREEMPT/!PREEMPT/SMP/!SMP, on x86 and x64.
Ingo
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
--- linux/kernel/sched.c.orig
+++ linux/kernel/sched.c
@@ -222,7 +222,6 @@ struct runqueue {
unsigned long expired_timestamp;
unsigned long long timestamp_last_tick;
task_t *curr, *idle;
- struct mm_struct *prev_mm;
prio_array_t *active, *expired, arrays[2];
int best_expired_prio;
atomic_t nr_iowait;
@@ -276,71 +275,25 @@ static DEFINE_PER_CPU(struct runqueue, r
#define task_rq(p) cpu_rq(task_cpu(p))
#define cpu_curr(cpu) (cpu_rq(cpu)-curr)
-#ifndef prepare_arch_switch
-# define prepare_arch_switch(next) do { } while (0)
-#endif
-#ifndef finish_arch_switch
-# define finish_arch_switch(prev) do { } while (0)
-#endif
-
-#ifndef __ARCH_WANT_UNLOCKED_CTXSW
-static inline int task_running(runqueue_t *rq, task_t *p)
-{
- return rq-curr == p;
-}
-
-static inline void prepare_lock_switch(runqueue_t *rq, task_t *next)
-{
-}
-
-static inline void finish_lock_switch(runqueue_t *rq, task_t *prev)
-{
- spin_unlock_irq(rq-lock);
-}
-
-#else /* __ARCH_WANT_UNLOCKED_CTXSW */
-static inline int task_running(runqueue_t *rq, task_t *p)
+/*
+ * We can optimise this out completely for !SMP, because the
+ * SMP rebalancing from interrupt is the only thing that cares:
+ */
+static inline void set_task_on_cpu(struct task_struct *p, int val)
{
#ifdef CONFIG_SMP
- return p-oncpu;
-#else
- return rq-curr == p;
+ p-on_cpu = val;
#endif
}
-static inline void prepare_lock_switch(runqueue_t *rq, task_t *next)
+static inline int task_on_cpu(runqueue_t *rq, task_t *p)
{
#ifdef CONFIG_SMP
- /*
-* We can optimise this out completely for !SMP, because the
-* SMP rebalancing from interrupt is the only thing that cares
-* here.
-*/
- next-oncpu = 1;
-#endif
-#ifdef __ARCH_WANT_INTERRUPTS_ON_CTXSW
- spin_unlock_irq(rq-lock);
+ return p-on_cpu;
#else
- spin_unlock(rq-lock);
-#endif
-}
-
-static inline void finish_lock_switch(runqueue_t *rq, task_t *prev)
-{
-#ifdef CONFIG_SMP
- /*
-* After -oncpu is cleared, the task can be moved to a different CPU.
-* We must ensure this doesn't happen until the switch is completely
-* finished.
-*/
- smp_wmb();
- prev-oncpu = 0;
-#endif
-#ifndef __ARCH_WANT_INTERRUPTS_ON_CTXSW
- local_irq_enable();
+ return rq-curr == p;
#endif
}
-#endif /* __ARCH_WANT_UNLOCKED_CTXSW */
/*
* task_rq_lock - lock the runqueue a given task resides on and disable
@@ -855,7 +808,7 @@ static int migrate_task(task_t *p, int d
* If the task is not on a runqueue (and not running), then
* it is sufficient to simply update the task's cpu field.
*/
- if (!p-array !task_running(rq, p)) {
+ if (!p-array !task_on_cpu(rq, p)) {
set_task_cpu(p, dest_cpu);
return 0;
}
@@ -885,9 +838,9 @@ void wait_task_inactive(task_t * p)
repeat:
rq = task_rq_lock(p, flags);
/* Must be off runqueue entirely, not preempted. */
- if (unlikely(p-array || task_running(rq, p))) {
+ if (unlikely(p-array || task_on_cpu(rq, p))) {
/* If it's preempted, we yield. It could be a while. */
- preempted = !task_running(rq, p);
+ preempted = !task_on_cpu(rq,
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, 2005-04-08 at 09:08 -0300, Humberto Massa wrote: Adrian Bunk wrote: Debian doesn't seem to care much about the possible legal problems of patents. You have lots of possible legal problems of any kind. Basically everyone can sue you for (almost) whatever he wants almost all ofth time. The possible legal problem of software patents is, up to the present time, AFAICT, not producing effects yet in Europe, and is a non-problem It is starting now. Basically the corporations with the masses of software patents and patent lawyers are probably waiting for the settling of the discussion and the ratification of the relevant to-be-accepted laws. And the war is not over yet ... In fact software patents are real in EUrope and they exist (though illegally). Up to now it was a question of whether you can succeed in court with them and which courts to go in jurisdictions like mine (down here neither business methods nor software are patentable). I suspect that .br is commercially not relevant enough for this ATM. Or the legislation is already USPTO-conform in place and nobody knows . Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 SCM saga..
* Matthias Andree: commiter_name VARCHAR(32) NOT NULL CHECK(commiter_name != ''), commiter_email VARCHAR(32) NOT NULL CHECK(commiter_email != ''), The length is too optimistic and insufficient to import the current BK stuff. I'd vote for 64 or at least 48 for each, although 48 is going to be a tight fit. It costs a bit but considering the expected payload size it's irrelevant. You should also check your database documentation if VARCHAR(n) is actually implemented implemented in the same way as TEXT (or what the unbounded string type is called), plus an additional length check. It doesn't make much sense to use VARCHAR if there isn't a performance (or disk space) benefit, IMHO, especially for such data. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] Updated: Dynamic Tick version 050408-1
Hi! I think I have an idea on what's going on; Your system does not wake to APIC interrupt, and the system timer updates time only on other interrupts. I'm experiencing the same on a loaner ThinkPad T30. I'll try to do another patch today. Meanwhile it now should work without lapic in cmdline. Following is an updated patch. Anybody having trouble, please try disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. I'm hoping this might work on Pavel's machine too? The volume hang was explained: I was using CPU frequency scaling, it probably did not like that. After disabling CPU frequency scaling, it seems to work ok: OK, good. I assume this was the same machine that did not work with any of the earlier patches? I do not have *that* machine near me just now, but I'll try it. Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm2
Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm2/ Wow... it responds despite the load average of 83.63 :) http://www.tuleriit.ee/progs/img/pic1.png http://www.tuleriit.ee/progs/img/pic2.png http://www.tuleriit.ee/progs/img/pic3.png dmesg is not clean though: TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow printk: 392 messages suppressed. TCP: time wait bucket table overflow printk: 290 messages suppressed. TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow printk: 295 messages suppressed. TCP: time wait bucket table overflow What I did: - bombing httpd with JMeter (from another computer) - copying files from USB memory device to harddisk - copying file with scp Indrek - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, Apr 08, 2005 at 09:41:35AM +0200, Sven Luther wrote: BTW, have any of you read the analysis i made, where i claim, rooted in the GPL FAQ and with examples, why i believe that the firmware can be considerated a non derivative of the linux kernel. I hadn't. I did just now. Here's my opinions, after reading it: [1a] It's pretty long, and some of the redundancy is not really relevant to the issue at hand. This might be less of an issue, except [1b] It has some grammar problems that should be fixed. [2] The presented arguments all look plausible. Maybe I should study it more, but I didn't see any significant logical flaws. [3] It focuses on debian issues more than kernel issues (though a dedicated reader could see some issues relevant to the linux-kernel mailing list). I agree with both you and the gpl faq writers that communicates at arms length is probably a good measure of whether or not the kernel and the module are the same program. I can think of cases where this wouldn't hold (GPLed documentation, for example), but those kinds of issues don't seem to be relevant here. I further argumented that taking any different stance would bring us worlds of hurt as we would consider the bios as being a derivative work of the kernel they are running, or the bootloader, or the firmware present in proms on devices loaded into the system and so on. Here, you've confused two issues: Are A and B part of the same program? and Are A and B together part of a derivative work under copyright law? Sometimes one is true, sometimes the other is true. You have a GPL issue when both are true. One question has to do with the function of A and B. The other question is whether the combination is eligible for copyright protection. Copyright protection is not granted or denied because of functionality. The functional issues are relevant only because they're written into the license. Of course there can be other GPL issues (e.g. it's bad to put a GPL notice on something which isn't GPLed). And, of course, there can be non-GPL issues (pulling the blobs out of the kernel lets people update their firmware without having to compile the kernel or a kernel module). I think only the fact that if you consider firmware as being a derivative work, you should consider it a derivative work also when it is flashed on the prom of a pci card or what not, is decisive enough to make those firmware blobs not derivative works of the kernel they are under. Uh... not precisely. You have your facts straight, but your logic is bad. This fact alone isn't enough to decide whether or not firmware is a derivative work. Fortunately this thought isn't a big deal for the cases we're currently talking about. -- Raul - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] pm_message_t corrections still missing from 2.6.12-rc2
Hi! Here, for your consideration, are fixups I still have in my tree after updating to rc2. (USB Framebuffer lists copied because a reasonable number apply there). Regards, Nigel diff -ruNp 840-combined-pm_message_t-patch.patch-old/drivers/base/power/resume.c 840-combined-pm_message_t-patch.patch-new/drivers/base/power/resume.c --- 840-combined-pm_message_t-patch.patch-old/drivers/base/power/resume.c 2004-12-10 14:26:51.0 +1100 +++ 840-combined-pm_message_t-patch.patch-new/drivers/base/power/resume.c 2005-04-08 13:41:41.0 +1000 @@ -41,7 +41,7 @@ void dpm_resume(void) list_add_tail(entry, dpm_active); up(dpm_list_sem); - if (!dev-power.prev_state) + if (!dev-power.prev_state.event) resume_device(dev); down(dpm_list_sem); put_device(dev); We do not want these to go anywhere for now. These depend on switching pm_message_t to struct, and that's 2.6.13 material. Except that, there are some good fixes (u32-pm_message_t), but they should be in -mm kernel already. ...except USB. I'm talking with David Brownell about those. Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
