Re: RSDL v0.31
On Tue, 2007-03-20 at 07:11 +0100, Willy Tarreau wrote: > Also, while I don't agree with starting to renice X to get something usable, > it seems real that there's something funny on Mike's system which makes it > behave particularly strangely when combined with RSDL, because other people > in comparable tests (including me) have found X perfectly smooth even with > loads in the tens or even hundreds. I really suspect that we will find a bug > in RSDL which triggers the problem and that this fix will help discover > another problem on Mike's hardware which was not triggered by mainline. I don't _think_ there's anything funny in my system, and Con said it was the expected behavior with my testcase, but I won't rule it out. Moving right along to the bugs part, I hope others are looking as well, and not only talking. One area that looks pretty fishy to me is cross-cpu wakeups and task migration. p->rotation appears to lose all meaning when you cross the cpu boundary, and try_to_wake_up()is using that information in the cross-cpu case. In pull_task() OTOH, it checks to see if the task ran on the remote cpu (at all, hmm), and if so tags the task accordingly. It is not immediately obvious to me why this would be a good thing though, because quotas of one runqueue don't appear to have any relation to quotas of some other runqueue. (i'm going to it that this old information is meaningless) -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/6] per device dirty throttling
On Tue, 2007-03-20 at 18:47 +1100, David Chinner wrote: > On Mon, Mar 19, 2007 at 04:57:37PM +0100, Peter Zijlstra wrote: > > This patch-set implements per device dirty page throttling. Which should > > solve > > the problem we currently have with one device hogging the dirty limit. > > > > Preliminary testing shows good results: > > I just ran some higher throughput number on this patchset. > > Identical 4-disk dm stripes, XFS, 4p x86_64, 16GB RAM, dirty_ratio = 5: > > One dm stripe: 320MB/s > two dm stripes: 310+315MB/s > three dm stripes: 254+253+253MB/s (pci-x bus bound) > > The three stripe test was for 100GB of data to each > filesystem - all the writes finished with 1s of each other > at 7m4s. Interestingly, the amount of memory in cache for > each of these devices was almost exactly the same - about > 5.2GB each. Looks good so far > > Hmmm - small problem - root disk (XFS) got stuck in > balance_dirty_pages_ratelimited_nr() after the above write test > attempting to unmount the filesystems (i.e. umount trying > to modify /etc/mtab got stuck and the root fs locked up) > > (reboot) Hmm, interesting, I'll look into it. > None-identical dm stripes, XFS, run alone: > > Single disk: 80MB/s > 2 disk dm stripe: 155MB/s > 4 disk dm stripe: 310MB/s > > Combined, after some runtime: > > # ls -sh /mnt/dm*/test > 10G /mnt/dm0/test 19G /mnt/dm1/test 41G /mnt/dm2/test > 15G /mnt/dm0/test 27G /mnt/dm1/test 52G /mnt/dm2/test > 18G /mnt/dm0/test 32G /mnt/dm1/test 64G /mnt/dm2/test > 24G /mnt/dm0/test 45G /mnt/dm1/test 86G /mnt/dm2/test > 27G /mnt/dm0/test 51G /mnt/dm1/test 95G /mnt/dm2/test > 29G /mnt/dm0/test 52G /mnt/dm1/test 97G /mnt/dm2/test > 29G /mnt/dm0/test 54G /mnt/dm1/test 101G /mnt/dm2/test [done] > 35G /mnt/dm0/test 65G /mnt/dm1/test 101G /mnt/dm2/test > 38G /mnt/dm0/test 70G /mnt/dm1/test 101G /mnt/dm2/test > > And so on. Final number: > > Single disk: 70MB/s > 2 disk dm stripe: 130MB/s > 4 disk dm stripe: 260MB/s > > So overall we've lost about 15-20% of the theoretical aggregate > perfomrance, but we haven't starved any of the devices over a > long period of time. > > However, looking at vmstat for total throughput, there are periods > of time where it appears that the fastest disk goes idle. That is, > we drop from an aggregate of about 550MB/s to below 300MB/s for > several seconds at a time. You can sort of see this from the file > size output above - long term the ratios remain the same, but in the > short term we see quite a bit of variability. I suspect you did not apply 7/6? There is some trouble with signed vs unsigned in the initial patch set that I tried to 'fix' by masking out the MSB, but that doesn't work and results in 'time' getting stuck for about half the time. > When the fast disk completed, I saw almost the same thing, but > this time it seems like the slow disk (i.e. ~230MB/s to ~150MB/s) > stopped for several seconds. > > I haven't really digested what the patches do, If you have questions please ask, I'll try to write up coherent answers :-) > but it's almost > like it is throttling a device completely while it allows another > to finish writing it's quota (underestimating bandwidth?). Yeah, there is some lumpy-ness in BIO submission or write completions it seems, and when that granularity (multiplied by the number of active devices) is larger than the 'time' period over with we average (indicated by vm_cycle_shift) very weird stuff can happen. > (umount after writes hung again. Same root disk thing as before) > > This is looking promising, Peter. When it is more stable I'll run > some more tests Thanks for the tests. - 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: axp question 'bout uname voodoo
Hi Eric! On 03/19/2007 06:44 PM, Eric W. Biederman wrote: Oliver Falk <[EMAIL PROTECTED]> writes: [ ... ] The kernel uname function at least does not have fields that report processor or hardware platform. But on i386 it reports: [EMAIL PROTECTED] ~]$ uname -mpi i686 i686 i386 And I remember that it used to report alphaev67 or alphaev56... -of - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG lapic: Can't boot on battery (2.6.21-rc{1,2,3,4})
2007/3/20, Thomas Gleixner <[EMAIL PROTECTED]>: On Mon, 2007-03-19 at 22:51 +0100, Stefan Prechtel wrote: > 2007/3/19, Thomas Gleixner <[EMAIL PROTECTED]>: > > On Mon, 2007-03-19 at 21:35 +0100, Stefan Prechtel wrote: > > >CPU0 CPU1 > > > 0: 28289 0 local-APIC-edge-fasteio timer > > > ... > > > LOC: 28237 28236 > > > > > > after a read: (I hope that is this what you want :-) > > >CPU0 CPU1 > > > 0: 30344 0 local-APIC-edge-fasteio timer > > > ... > > > LOC: 30292 30291 > > > > Is this with AC plugged in ? If yes, please provide the same numbers for > > battery mode. > > Yes. And here is the output for battery mode (2.6.20): >CPU0 CPU1 > 0: 292153 0 local-APIC-edge-fasteio timer > LOC: 292114 292113 > >CPU0 CPU1 > 0: 293263 0 local-APIC-edge-fasteio timer > LOC: 293224 293223 Hmm. Can you please apply the following patch on top of 2.6.20 and check, if the WARN_ON_ONCE triggers when you boot w/o AC plugged ? Thanks, tglx Good morning! The WARN_ON / WARN_ON_ONCE didn't trigger on boot. - Stefan Prechtel - 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][5/5][resend] floppy.c: Fix device_create_file() warning
On Mon, 19 Mar 2007 18:42:22 +0100, Jesper Juhl wrote: > --- a/drivers/block/floppy.c > +++ b/drivers/block/floppy.c > @@ -4302,7 +4302,12 @@ static int __init floppy_init(void) > if (err) > goto out_flush_work; > > - device_create_file(&floppy_device[drive].dev,&dev_attr_cmos); > + err = device_create_file(&floppy_device[drive].dev, > &dev_attr_cmos); > + if (err) > + goto out_flush_work; > + > /* to be cleaned up... */ > disks[drive]->private_data = (void *)(long)drive; > disks[drive]->queue = floppy_queue; The floppy driver's sysfs file just provides some auxiliary information to user-space, none of which matters for most of its users. It is IMO totally inappropriate to fail floppy driver init in this case. /Mikael - 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: PNPACPI probes serial twice, messes up serial console
On Tue, Mar 20, 2007 at 05:46:46PM +1100, Keith Owens wrote: > Should pnpacpi probe and setup the serial devices even when thay have > already been setup? Or this is something strange about the UART in > this particular box? Yes, so it can be associated with the correct device. No idea why it's affecting your serial console though - the autoconfig should be transparent once it's completed. Sure, if you enable serial debugging (thereby making it produce output during the autoconfig) it will mess it up, but that's the standard gun and foot scenario. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RSDL v0.31
On Tue, 2007-03-20 at 07:11 +0100, Willy Tarreau wrote: > I don't agree with starting to renice X to get something usable X looks very special to me: it's a big userspace driver, the primary task handling user interaction on the desktop, and on some OS the part responsible for moving the mouse pointer and interacting with windows is even implemented as an interrupt handler, and that for sure provides for smooth user experience even on very low-end hardware. Why not compensate for X design by prioritizing it a bit ? If RSDL + reniced X makes for a better desktop than sotck kernel + X, on all kind of workloads, it's good to know. - 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: mm snapshot broken-out-2007-03-18-02-44.tar.gz uploaded
On 20/03/07, Nick Piggin <[EMAIL PROTECTED]> wrote: Andrew Morton wrote: > On Tue, 20 Mar 2007 13:47:53 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote: > > >>Andrew Morton wrote: >> >>Hang on a sec... I'll try fixing the thing before you next make a >>release. >> > > > Too late. hot-fixes/ awaits thee. Awww... well thanks very much Michal for reporting the bug, I reproduced it easily and it turns out to be a typo. In my testing I never had a lot of writeout going on, so most of the pages will have been truncated in the first loop... Problem fixed. Thanks! Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - 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: [BUG] 2.6.21-rc1,2,3 regressions on my system that I found so far
On Mon, 2007-03-19 at 21:27 -0700, Greg KH wrote: > On Sat, Mar 17, 2007 at 02:26:57PM +0100, Andi Kleen wrote: > > Arjan van de Ven <[EMAIL PROTECTED]> writes: > > > > > > well we can do the handshake to take ownership like we do much later in > > > boot, but that requires PCI to be there and fully discovered, which we > > > don't have this early. > > > > That's not true - we do early pci discovery. Doing USB handsoff > > there would be quite possible. > > What, we don't do USB "handoff" early enough in the boot process? It's > happening at PCI quirk time now, which I think should be early enough > for everyone (and too early for some who rely on USB keyboards and > initramfs shells...) it's not early enough for this bug, where the SMM code is ruining the cpu calibrations :) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.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: [BUG] 2.6.21-rc1,2,3 regressions on my system that I found so far
On Tue, 2007-03-20 at 01:36 -0400, Eric St-Laurent wrote: > On Tue, 2007-20-03 at 01:04 -0400, Lee Revell wrote: > > > I think CONFIG_TRY_TO_DISABLE_SMI would be excellent for debugging, > > not to mention people trying to spec out hardware for RT > > applications... > > There is a SMI disabling module in RTAI, check the smi-module.c in this: > > https://www.rtai.org/RTAI/rtai-3.5.tar.bz2 > > More infos: > > http://www.captain.at/rtai-smi-high-latency.php > http://www.captain.at/xenomai-smi-high-latency.php > > It might make sense to merge this code, at least in the -rt tree. it NEVER makes sense to disable SMM. SMM is there to ensure that your hardware doesn't get physically damaged. disabling that is a BAD idea. I'm no fan of SMM myself, but it's there, and we have to live with it. Disabling it without knowing what it does on your system is madness. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.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][5/5][resend] floppy.c: Fix device_create_file() warning
On 20/03/07, Mikael Pettersson <[EMAIL PROTECTED]> wrote: On Mon, 19 Mar 2007 18:42:22 +0100, Jesper Juhl wrote: > --- a/drivers/block/floppy.c > +++ b/drivers/block/floppy.c > @@ -4302,7 +4302,12 @@ static int __init floppy_init(void) > if (err) > goto out_flush_work; > > - device_create_file(&floppy_device[drive].dev,&dev_attr_cmos); > + err = device_create_file(&floppy_device[drive].dev, &dev_attr_cmos); > + if (err) > + goto out_flush_work; > + > /* to be cleaned up... */ > disks[drive]->private_data = (void *)(long)drive; > disks[drive]->queue = floppy_queue; The floppy driver's sysfs file just provides some auxiliary information to user-space, none of which matters for most of its users. It is IMO totally inappropriate to fail floppy driver init in this case. Which is why my original patch just output a warning to let the user know that creating the file had failed. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
user defined hotplug events?
Hello, on my notebook, the built in wlan card uses the ipw2100 driver. On boot time, the ipw2100 module is loaded and fires a hotplug "add" event. The hotplug event configures the interface and starts wpa_supplicant and wpa_cli. The ipw2100 chip can be enabled/disabled by a hardware switch, so i only enabled it if i need a connection. Now: even if the wlan hardware is disabled by the switch, wpa_supplicant tries to get a connection. That's not fine... The ipw2100 driver exports a switch state file in sysfs, but polling this file is not fine also. I want that it works as follows: A state change of the hardware switch should fire a hotplug event, so that the wpa_* programs are started if the switch is put on, and killed if the switch is put off. The ipw2100 driver already logs a state change of the switch in klog, so adding a kobject_uevent should not be the major problem. But which KOBJ_* event enum should be used? KOBJ_ONLINE, KOBJ_OFFLINE ? Or new, user defined, ones? Comments? Suggestions? Thomas "Jetzt Handykosten senken mit klarmobil - 14 Ct./Min.! Hier klicken" http://www.klarmobil.de/index.html?pid=73025 - 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] Re: [2.6.20] BUG: workqueue leaked lock
On 19-03-2007 07:24, Neil Brown wrote:
> On Friday March 16, [EMAIL PROTECTED] wrote:
>> OK. That's not necessarily a bug: one could envisage a (weird) piece of
>> code which takes a lock then releases it on a later workqueue invokation.
>> But I'm not sure that nfs4_laundromat() is actually supposed to be doing
>> anything like that.
>>
>> Then again, maybe it is: it seems to be waddling through a directory under
>> the control of a little state machine, with timeouts.
>>
>> Neil: help?
>
> I'm quite certain that laundromat_main does *not* leave client_mutex
> locked as the last thing it does is call nfs4_unlock_state which is
> mutex_unlock(&client_mutex);
> To me, that raises some doubt about whether the lock leak check is
> working properly...
> It is somewhat harder to track locking of i_mutex, but it seems to me
> that every time it is taken, it is released again shortly afterwards.
>
> So I think this must be a problem with leak detection, not with NFSd.
>
> NeilBrown
>
>
>> On Fri, 16 Mar 2007 09:41:20 +0100 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>>
>>> On Thu, 2007-03-15 at 11:06 -0800, Andrew Morton wrote:
> On Tue, 13 Mar 2007 17:50:14 +0100 Folkert van Heusden <[EMAIL
> PROTECTED]> wrote:
> ...
> [ 1756.728209] BUG: workqueue leaked lock or atomic: nfsd4/0x/3577
> [ 1756.728271] last function: laundromat_main+0x0/0x69 [nfsd]
> [ 1756.728392] 2 locks held by nfsd4/3577:
> [ 1756.728435] #0: (client_mutex){--..}, at: []
> mutex_lock+0x8/0xa
> [ 1756.728679] #1: (&inode->i_mutex){--..}, at: []
> mutex_lock+0x8/0xa
> [ 1756.728923] [] show_trace_log_lvl+0x1a/0x30
> [ 1756.729015] [] show_trace+0x12/0x14
> [ 1756.729103] [] dump_stack+0x16/0x18
> [ 1756.729187] [] run_workqueue+0x167/0x170
> [ 1756.729276] [] worker_thread+0x146/0x165
> [ 1756.729368] [] kthread+0x97/0xc4
> [ 1756.729456] [] kernel_thread_helper+0x7/0x10
> [ 1756.729547] ===
...
>>> I think I'm responsible for this message (commit
>>> d5abe669172f20a4129a711de0f250a4e07db298); what is says is that the
>>> function executed by the workqueue (here laundromat_main) leaked an
>>> atomic context or is still holding locks (2 locks in this case).
This check is valid with keventd, but it looks like nfsd runs
kthread by itself. I'm not sure it's illegal to hold locks then,
so, if I'm not wrong with this, here is my patch proposal (for
testing) to take this into consideration.
Reported-by: Folkert van Heusden <[EMAIL PROTECTED]>
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
diff -Nurp 2.6.21-rc4-git4-/kernel/workqueue.c
2.6.21-rc4-git4/kernel/workqueue.c
--- 2.6.21-rc4-git4-/kernel/workqueue.c 2007-02-04 19:44:54.0 +0100
+++ 2.6.21-rc4-git4/kernel/workqueue.c 2007-03-20 09:30:46.0 +0100
@@ -316,6 +316,7 @@ static void run_workqueue(struct cpu_wor
struct work_struct *work = list_entry(cwq->worklist.next,
struct work_struct, entry);
work_func_t f = work->func;
+ int ld;
list_del_init(cwq->worklist.next);
spin_unlock_irqrestore(&cwq->lock, flags);
@@ -323,13 +324,15 @@ static void run_workqueue(struct cpu_wor
BUG_ON(get_wq_data(work) != cwq);
if (!test_bit(WORK_STRUCT_NOAUTOREL, work_data_bits(work)))
work_release(work);
+ ld = lockdep_depth(current);
+
f(work);
- if (unlikely(in_atomic() || lockdep_depth(current) > 0)) {
+ if (unlikely(in_atomic() || (ld -= lockdep_depth(current {
printk(KERN_ERR "BUG: workqueue leaked lock or atomic: "
- "%s/0x%08x/%d\n",
+ "%s/0x%08x/%d/%d\n",
current->comm, preempt_count(),
- current->pid);
+ current->pid, ld);
printk(KERN_ERR "last function: ");
print_symbol("%s\n", (unsigned long)f);
debug_show_held_locks(current);
-
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] clockevents: Fix suspend/resume to disk hangs
Thomas Gleixner wrote: > I finally found a dual core box, which survives suspend/resume without > crashing in the middle of nowhere. Sigh, I never figured out from the > code and the bug reports what's going on. > > The observed hangs are caused by a stale state transition of the clock > event devices, which keeps the RCU synchronization away from completion, > when the non boot CPU is brought back up. This didn't fix the suspend problems on my Thinkpad R60. (Sorry for nagging - please let me know if I can assist in debugging this...) Marcus - 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: Re: ex-upload
Hello, >> How can I put delay between subsequent msg sends to achieve desired >> packet rate without loses, e.g., 3.5Gbps without bursts? Even nanosleep() >> with the lowest possible delay seems to be too much delay. Busy loop with >> clock_gettime(3) works OK on SMP boxes, but on UP it causes problems. > > Why do you want to avoid bursts? You're going to be bursting between 10Gb/s > and 0 anyway. It is because bursts above 5.5Gbps cannot be received by the peer. The peer is only able to receive bursts up to 5.5Gbps whereas the sender is able to burst up to 9.9Gbps. > It sounds like you're deliberately putting impossible requirements on > yourself choosing the worst possible protocol and demanding the pacing be > perfect. I don't think the technology to do that is here yet, but why would > you possibly need it? it is video transmission encapsulated in RTP over UDP. I do not know whether there are any other possibilities that would work also on Mac OS or FreeBSD. (Please Cc me) -- Lukáš Hejtmánek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/6] per device dirty throttling
On Tue, Mar 20, 2007 at 09:08:24AM +0100, Peter Zijlstra wrote: > On Tue, 2007-03-20 at 18:47 +1100, David Chinner wrote: > > So overall we've lost about 15-20% of the theoretical aggregate > > perfomrance, but we haven't starved any of the devices over a > > long period of time. > > > > However, looking at vmstat for total throughput, there are periods > > of time where it appears that the fastest disk goes idle. That is, > > we drop from an aggregate of about 550MB/s to below 300MB/s for > > several seconds at a time. You can sort of see this from the file > > size output above - long term the ratios remain the same, but in the > > short term we see quite a bit of variability. > > I suspect you did not apply 7/6? There is some trouble with signed vs > unsigned in the initial patch set that I tried to 'fix' by masking out > the MSB, but that doesn't work and results in 'time' getting stuck for > about half the time. I applied the fixes patch as well, so i had all that you posted... > > but it's almost > > like it is throttling a device completely while it allows another > > to finish writing it's quota (underestimating bandwidth?). > > Yeah, there is some lumpy-ness in BIO submission or write completions it > seems, and when that granularity (multiplied by the number of active > devices) is larger than the 'time' period over with we average > (indicated by vm_cycle_shift) very weird stuff can happen. Sounds like the period is a bit too short atm if we can get into this sort of problem with only 2 active devices Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - 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: [BUG 2.6.21-rc3-git9] SATA NCQ failure with Samsum HD401LJ
On 2007/03/19 13:09, Jeff Garzik <[EMAIL PROTECTED]> wrote: > I may have missed the answer to this before, but: does the problem > go away if you disable preempt? On my system (same problem, original bug report), preemption is disabled. Max - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/6] per device dirty throttling
On Tue, 2007-03-20 at 20:38 +1100, David Chinner wrote: > On Tue, Mar 20, 2007 at 09:08:24AM +0100, Peter Zijlstra wrote: > > On Tue, 2007-03-20 at 18:47 +1100, David Chinner wrote: > > > So overall we've lost about 15-20% of the theoretical aggregate > > > perfomrance, but we haven't starved any of the devices over a > > > long period of time. > > > > > > However, looking at vmstat for total throughput, there are periods > > > of time where it appears that the fastest disk goes idle. That is, > > > we drop from an aggregate of about 550MB/s to below 300MB/s for > > > several seconds at a time. You can sort of see this from the file > > > size output above - long term the ratios remain the same, but in the > > > short term we see quite a bit of variability. > > > > I suspect you did not apply 7/6? There is some trouble with signed vs > > unsigned in the initial patch set that I tried to 'fix' by masking out > > the MSB, but that doesn't work and results in 'time' getting stuck for > > about half the time. > > I applied the fixes patch as well, so i had all that you posted... Humm, not that then. > > > but it's almost > > > like it is throttling a device completely while it allows another > > > to finish writing it's quota (underestimating bandwidth?). > > > > Yeah, there is some lumpy-ness in BIO submission or write completions it > > seems, and when that granularity (multiplied by the number of active > > devices) is larger than the 'time' period over with we average > > (indicated by vm_cycle_shift) very weird stuff can happen. > > Sounds like the period is a bit too short atm if we can get into this > sort of problem with only 2 active devices Yeah, trouble is, I significantly extended this period in 7/6. Will have to ponder a bit on what is happening then. Anyway, thanks for the feedback. I'll try and reproduce the umount problem, maybe that will give some hints. - 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.21-rc4-mm1
Andrew Morton wrote: > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ > > > [All of the below is from the pre hot-fix runs. The very few results which are in for the hot-fix runs seem worse if anything. :( All results should be out on TKO.] > - Restored the RSDL CPU scheduler (a new version thereof) Unsure if the above is the culprit but there seems to be a smattering of BUG's in kernbench from the schedular on several systems, and panics which do not fully dump out. elm3b239 is about 2/4 kernbench being the test in progress when we blammo in both failed tests, elm3b234 doesn't boot at all. >From elm3b239: [ cut here ] kernel BUG at kernel/sched.c:3505! invalid opcode: [1] SMP last sysfs file: devices/pci:00/:00:00.0/irq CPU 19 Modules linked in: loop dm_mod md_mod sg Pid: 59, comm: migration/19 Not tainted 2.6.21-rc4-mm1-autokern1 #1 RIP: 0010:[] [] __sched_text_start+0x3a6/0x882 RSP: 0018:810100cefe20 EFLAGS: 00010002 RAX: 008c RBX: 81002b0f64d8 RCX: 000c RDX: RSI: 008c RDI: 81002b0f6da8 RBP: 810100cefeb0 R08: 008c R09: 81002b0f6d98 R10: 0034 R11: 8021ab20 R12: 81002b0f5a40 R13: 0002 R14: 00725eb99ef7 R15: 0013 FS: () GS:810100c42bc0() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 2ba9c431ab70 CR3: 0001060fc000 CR4: 06e0 Process migration/19 (pid: 59, threadinfo 810100cee000, task 810100ced8e0) Stack: 0001 0001 81010b681e98 810100ced8e0 810100cefe80 810100ceda78 0003 81010b681e88 81010b681e90 0286 0013 Call Trace: [] migration_thread+0x1b0/0x250 [] migration_thread+0x0/0x250 [] kthread+0xdb/0x120 [] child_rip+0xa/0x12 [] kthread+0x0/0x120 [] child_rip+0x0/0x12 Code: 0f 0b eb fe 49 8b 94 24 b8 01 00 00 49 8b 84 24 b0 01 00 00 RIP [] __sched_text_start+0x3a6/0x882 RSP [ cut here ] kernel BUG at kernel/sched.c:3505! invalid opcode: [1] SMP last sysfs file: devices/pci:00/:00:00.0/irq CPU 21 Modules linked in: loop dm_mod md_mod sg Pid: 15583, comm: cc1 Not tainted 2.6.21-rc4-mm1-autokern1 #1 RIP: 0010:[] [] __sched_text_start+0x3a6/0x882 RSP: :81010aca7ee0 EFLAGS: 00010002 RAX: 008c RBX: 81002b111358 RCX: 000c RDX: RSI: 008c RDI: 81002b111c28 RBP: 81010aca7f70 R08: 008c R09: 81002b111c18 R10: 0034 R11: 0001 R12: 81002b1108c0 R13: 0002 R14: 006cb9bdff1a R15: 0015 FS: 2b6ef0bc66d0() GS:810100d02e40() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 2b6ef20c1000 CR3: 000106e2b000 CR4: 06e0 Process cc1 (pid: 15583, threadinfo 81010aca6000, task 810105b03620) Stack: 0100 0100 81010964c148 810105b03620 8054c9b7 810105b037c0 000b000e 81010b216d80 2b6ef20b7d00 2b6ef20c1000 0400 Call Trace: [] retint_careful+0xd/0x21 Code: 0f 0b eb fe 49 8b 94 24 b8 01 00 00 49 8b 84 24 b0 01 00 00 RIP [] __sched_text_start+0x3a6/0x882 RSP >From elm3b245: [ cut here ] kernel BUG at kernel/sched.c:3505! invalid opcode: [1] SMP last sysfs file: CPU 0 Modules linked in: Pid: 1, comm: init Not tainted 2.6.21-rc4-mm1-autokern1 #1 RIP: 0010:[] [] __sched_text_start+0x377/0x819 RSP: 0018:81010037dee0 EFLAGS: 00010002 RAX: 008c RBX: 0002 RCX: RDX: 0034 RSI: 008c RDI: 810002c15210 RBP: 81010037df70 R08: 008c R09: 000c R10: 810002c15200 R11: 8020968e R12: 810002c14940 R13: 7fff1da16360 R14: 810002c14780 R15: FS: 2b428d88d6d0() GS:805af000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 00586a48 CR3: 08c2f000 CR4: 06e0 Process init (pid: 1, threadinfo 81010037c000, task 810003369450) Stack: 03e10059d1b0 81010037df28 80276dd3 810003369450 810008313880 003727988fe6 8100033695f0 7fff1da16250 7fff1da16360 0059bb70 8020968e 81010037df48 Call Trace: [] generic_file_llseek+0x87/0x96 [] system_call+0x7e/0x83 [] sys_clone+0x23/0x25 [] sysret_careful+0xd/0x10 Code: 0f 0b eb fe 49 8b 96 b8 01 00 00 49 8b 86 b0 01 00 00 be 8c RIP [] __sched_text_start+0x377/0x819 RSP - To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Re: Odd suspend regression in 2.6.21-rc[123]
Hi! > In 2.6.21-rc1,2,3, my laptop will fully suspend to ram, but then > *immediately* resumes back from suspension. (It resumes just fine, as well.) > > Nothing out of the ordinary is logged, and this happens even when > booting into init=/bin/sh with minimal modules loaded and executing > s2ram from that minimal environment. > > I'm going to ponder the 2.6.20 to 2.6.21-rc1 changelog, but I'm hoping > someone with a clue can offer a suggestion before I end up bisecting the > whole thing. (Wouldn't be so bad, except I'm given to understand that > there are multiple places in those changes where nothing quite works > with respect to suspend.) > > HP/Compaq NX6125 system, AMD64, dmesg attached. Known problem in ACPI, hopefully already fixed? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops after cd /sys/.../cpufreq/; rmmod; cat stats/time_in_state
On Mon, Mar 19, 2007 at 01:41:25PM -0700, Greg KH wrote: > On Mon, Mar 19, 2007 at 06:30:13PM +0300, Alexey Dobriyan wrote: > > Steps to reproduce: > > > > # modprobe p4-clockmod > > $ cd /sys/devices/system/cpu/cpu0/cpufreq/ > > # rmmod p4-clockmod > > $ cat stats/time_in_state > > Segmentation fault > > Has this always happened? Or is it new? I've checked 2.6.17 and up and it happens too. Some .config peculiarities: CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_STAT=y CONFIG_X86_P4_CLOCKMOD=m After modprobe/rmmod cpufreq/stats directory appears but doesn't get removed. Should it? /sys/devices/system/cpu/cpu0/cpufreq $ ls -lR .: total 0 drwxr-xr-x 2 root root 0 2007-03-20 12:59 stats ./stats: total 0 -r--r--r-- 1 root root 4096 2007-03-20 12:59 time_in_state -r--r--r-- 1 root root 4096 2007-03-20 12:59 total_trans - 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: [lm-sensors] [RFC][PATCH] Apple SMC driver (hardware monitoring and control)
On Mon, 19 Mar 2007 17:43:38 -0400, Bob Copeland wrote: > I tried out an earlier version of this patch several months ago just to play > around with the joystick part of the accelerometer driver on my MacBook, and > found that it was backwards in the y-direction compared to what Neverball > seemed to want (of course, NB has no way to invert the joystick). I think > I just did something like this in my own copy: > > + y = -y; > input_report_abs(applesmc_idev, ABS_X, x - rest_x); > input_report_abs(applesmc_idev, ABS_Y, y - rest_y); > > I don't claim you necessarily want to change it, but thought I'd pass it > along. This appears to be a common problem with these devices, the hdaps driver (IBM) needs to invert the axis on some models too, and I seem to remember something similar for the (not yet merged) HP laptops accelerometer driver. -- 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/
[PATCH] time : SMP friendly alignment of struct clocksource
struct clocksource is a critical data structure.
Most of its fields are read only, some of them are heavily modified at each
timer interrupt.
It makes sense to separate those fields and make sure they all share one cache
line, or at least the minimum for machines with small cache lines.
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
--- linux-2.6.21-rc4-mm1/include/linux/clocksource.h
+++ linux-2.6.21-rc4-mm1-ed/include/linux/clocksource.h
@@ -49,25 +49,35 @@ struct clocksource;
* @flags: flags describing special properties
* @vread: vsyscall based read
* @cycle_interval:Used internally by timekeeping core, please ignore.
* @xtime_interval:Used internally by timekeeping core, please ignore.
*/
struct clocksource {
+ /*
+* First part of structure is read mostly
+*/
char *name;
struct list_head list;
int rating;
cycle_t (*read)(void);
cycle_t mask;
u32 mult;
u32 shift;
unsigned long flags;
cycle_t (*vread)(void);
/* timekeeping specific data, ignore */
- cycle_t cycle_last, cycle_interval;
- u64 xtime_nsec, xtime_interval;
+ cycle_t cycle_interval;
+ u64 xtime_interval;
+ /*
+* Second part is written at each timer interrupt
+* Keep it in a different cache line to dirty no
+* more than one cache line.
+*/
+ cycle_t cycle_last cacheline_aligned_in_smp;
+ u64 xtime_nsec;
s64 error;
#ifdef CONFIG_CLOCKSOURCE_WATCHDOG
/* Watchdog related data, used by the framework */
struct list_head wd_list;
cycle_t wd_last;
-
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: [ck] Re: RSDL v0.31
Op Tuesday 20 March 2007, schreef Bill Davidsen: > Kasper Sandberg wrote: > > On Sun, 2007-03-18 at 08:38 +0100, Mike Galbraith wrote: > >> On Sun, 2007-03-18 at 08:22 +0100, Radoslaw Szkodzinski wrote: > >>> I'd recon KDE regresses because of kioslaves waiting on a pipe > >>> (communication with the app they're doing IO for) and then expiring. > >>> That's why splitting IO from an app isn't exactly smart. It should at > >>> least be ran in an another thread. > >> > >> Hm. Sounds rather a lot like the... > >> X sucks, fix X and RSDL will rock your world. RSDL is perfect. > >> ...that I've been getting. > > > > not really, only X sucks. KDE works atleast as good with rsdl as > > vanilla. i dont know how originally said kde works worse, wasnt it just > > someone that thought? > > It was probably me, and I had the opinion that KDE is not as smooth as > GNOME with RSDL. I haven't had time to measure, but using for daily > stuff for about an hour each way hasn't changed my opinion. Every once > in a while KDE will KLUNK to a halt for 200-300ms doing mundane stuff > like redrawing a page, scrolling, etc. I don't see it with GNOME. yeah, here too... sometimes even longer (and I have a dualcore, 3gb ram, damnit!) -- Disclaimer: Alles wat ik doe denk en zeg is gebaseerd op het wereldbeeld wat ik nu heb. Ik ben niet verantwoordelijk voor wijzigingen van de wereld, of het beeld wat ik daarvan heb, noch voor de daaruit voortvloeiende gedragingen van mezelf. Alles wat ik zeg is aardig bedoeld, tenzij expliciet vermeld. Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html pgpTTtAuMOZKH.pgp Description: PGP signature
Re: [ck] Re: RSDL v0.31
Op Tuesday 20 March 2007, schreef Linus Torvalds:
> On Mon, 19 Mar 2007, Xavier Bestel wrote:
> > > >> Stock scheduler wins easily, no contest.
> > > >
> > > > What happens when you renice X ?
> > >
> > > Dunno -- not necessary with the stock scheduler.
> >
> > Could you try something like renice -10 $(pidof Xorg) ?
>
> Could you try something as simple and accepting that maybe this is a
> problem?
>
> Quite frankly, I was *planning* on merging RSDL very early after 2.6.21,
> but there is one thing that has turned me completely off the whole thing:
>
> - the people involved seem to be totally unwilling to even admit there
>might be a problem.
>
> This is like alcoholism. If you cannot admit that you might have a
> problem, you'll never get anywhere. And quite frankly, the RSDL proponents
> seem to be in denial ("we're always better", "it's your problem if the old
> scheduler works better", "just one report of old scheduler being better").
>
> And the thing is, if people aren't even _willing_ to admit that there may
> be issues, there's *no*way*in*hell* I will merge it even for testing.
> Because the whole and only point of merging RSDL was to see if it could
> replace the old scheduler, and the most important feature in that case is
> not whether it is perfect, BUT WHETHER ANYBODY IS INTERESTED IN TRYING TO
> FIX THE INEVITABLE PROBLEMS!
Con simply isn't available right now, but you're right. RSDL isn't ready yet,
imho, there seem to be some regressions (and I'm bitten by them, too). But if
con's past behaviour says anything about how he's going to behave in the
future (and according to my psych prof it's the most reliable predictor ;-)),
I'm pretty sure he'll jump on this when he's healthy again. He's gone through
great lengths to fix problems with staircase, no matter how obscure, so I see
no reason why he wouldn't do the same for RSDL... Though scheduler problems
can be extremely hard to reproduce on other hardware.
> See?
>
> Can you people not see that the way you're doing that "RSDL is perfect"
> chorus in the face of people who report problems, you're just making it
> totally unrealistic that it will *ever* get merged.
>
> So unless somebody steps up to the plate and actually *talks* about the
> problem reports, and admits that maybe RSDL will need some tweaking, I'm
> not going to merge it.
>
> Because there is just _one_ thing that is more important than code - and
> that is the willingness to fix the code...
>
> Linus
> ___
> http://ck.kolivas.org/faqs/replying-to-mailing-list.txt
> ck mailing list - mailto: [EMAIL PROTECTED]
> http://vds.kolivas.org/mailman/listinfo/ck
--
Disclaimer:
Alles wat ik doe denk en zeg is gebaseerd op het wereldbeeld wat ik nu heb.
Ik ben niet verantwoordelijk voor wijzigingen van de wereld, of het beeld wat
ik daarvan heb, noch voor de daaruit voortvloeiende gedragingen van mezelf.
Alles wat ik zeg is aardig bedoeld, tenzij expliciet vermeld.
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
pgp5Lq89fFLhw.pgp
Description: PGP signature
Re: [1/6] 2.6.21-rc4: known regressions
Adrian Bunk wrote: > This email lists some known regressions in Linus' tree compared to 2.6.20. Since I didn't see any mention of this: I'm seeing an Oops when removing the ohci1394 module: [ 16.047275] ieee1394: Node removed: ID:BUS[158717321-38:0860] GUID[c033ced6] [ 16.047287] BUG: unable to handle kernel NULL pointer dereference at virtual address 0094 [ 16.047451] printing eip: [ 16.047524] c02daf3d [ 16.047527] *pde = [ 16.047603] Oops: [#1] [ 16.047676] PREEMPT [ 16.047788] Modules linked in: backlight ohci1394 parport_pc parport [ 16.048069] CPU:0 [ 16.048071] EIP:0060:[]Not tainted VLI [ 16.048074] EFLAGS: 00010246 (2.6.21-rc4 #35) [ 16.048298] EIP is at class_device_remove_attrs+0xa/0x30 [ 16.048377] eax: dfd04338 ebx: ecx: df655988 edx: [ 16.048456] esi: edi: dfd04338 ebp: esp: df506e38 [ 16.048535] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [ 16.048614] Process rmmod (pid: 1455, ti=df506000 task=df6cc0b0 task.ti=df506000) [ 16.048693] Stack: dfd04338 dfd04340 c02db02f dfd04338 dfd041e4 c0331871 [ 16.049159] c02db065 dfd041b0 c0331858 c055006d 0975d589 0026 035c [ 16.049626] c033ced6 df24c000 c0331879 c02d859f df24c0bc df24c0bc [ 16.050091] Call Trace: [ 16.050233] [] class_device_del+0xcc/0xfa [ 16.050352] [] __nodemgr_remove_host_dev+0x0/0xb [ 16.050475] [] class_device_unregister+0x8/0x10 [ 16.050595] [] nodemgr_remove_ne+0x61/0x7a [ 16.050714] [] ether1394_header_cache+0x0/0x43 [ 16.050835] [] __nodemgr_remove_host_dev+0x8/0xb [ 16.050954] [] device_for_each_child+0x1a/0x3c [ 16.051073] [] nodemgr_remove_host+0x30/0x90 [ 16.051192] [] __unregister_host+0x1a/0xad [ 16.051311] [] hl_get_hostinfo+0x5b/0x76 [ 16.051430] [] highlevel_remove_host+0x21/0x42 [ 16.051549] [] hpsb_remove_host+0x37/0x56 [ 16.051668] [] ohci1394_pci_remove+0x44/0x1c7 [ohci1394] [ 16.051794] [] pci_device_remove+0x16/0x35 [ 16.053376] [] __device_release_driver+0x6e/0x8b [ 16.053496] [] driver_detach+0xa1/0xde [ 16.053613] [] bus_remove_driver+0x57/0x75 [ 16.053733] [] driver_unregister+0x8/0x13 [ 16.053850] [] pci_unregister_driver+0xc/0x6e [ 16.053969] [] sys_delete_module+0x174/0x19a [ 16.054091] [] do_page_fault+0x277/0x525 [ 16.054211] [] do_munmap+0x193/0x1ac [ 16.054331] [] syscall_call+0x7/0xb [ 16.054450] === [ 16.054523] Code: ff c3 85 c0 74 08 83 c0 08 e9 9b f8 ea ff b8 ea ff ff ff c3 85 c0 74 08 83 c0 08 e9 b9 db ea ff c3 57 89 c7 56 53 31 db 8b 70 44 <83> be 94 00 00 00 00 75 09 eb 17 89 f8 e8 d7 ff ff ff 89 da 83 [ 16.057248] EIP: [] class_device_remove_attrs+0xa/0x30 SS:ESP 0068:df506e38 -- Tobias PGP: http://9ac7e0bc.uguu.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.6.20 does not work anymore with SCSI or SATA on old Opteron / Xeon servers
Hello! Here are more informations... the problem seems to be a little bit more special. 1.) I've bootet these systems through NFS and would like to access /dev/sda or /dev/sdb then. For example via fdisk and this does not work. 2.) I've now tested the following kernels - 2.6.18.8 - works 2.6.19.7 - works 2.6.20 - does not work 2.6.21-rc4 - does not work 3.) The funny thing is, i can boot the whole system via 2.6.18.8 for example - fdisk the harddisk and format it + plus copying the whole image with a 2.6.20.3 kernel - and then the Server installied works perfectly i also can fdisk /dev/sdb or so. It only does not work if the system itself is bootet via NFS... Stefan Andrew Morton schrieb: On Sun, 18 Mar 2007 21:50:46 +0100 Stefan Priebe <[EMAIL PROTECTED]> wrote: Hello! We've a very strange Problem with Kernel 2.6.20.x If i try to access a SCSI or SATA Disk (tested with Adaptec U320 ASC-29320, ICP Vortex 9024, Promise TX300) the whole server hangs - no output - no error on the screen - but it hangs completely. But it does not happen on all our systems affected are only old 604pin xeons and socket 940 Opterons. Socket F Opteron or 771 Xeons does work fine. I've also testet apci=off pci=routeirq but both does not help. The systems work fine with 2.6.19.x and before. Well that's a bit sad. Could you please set up netconsole (Documentation/networking/netconsole.txt) and add initcall_debug to the kernel boot command line and then send us the full bootup logs? (Even better: serial console with earlyprintk). If that doesn't shed any light, we might have to ask you to perform a git-bisect search to find the buggy commit, I'm afraid. - 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: Files corrupt after moving LVM volume to USB disk
Hello LKML, Second repost of "BUG: Killing and reviving files with USB disks", this time also destined to linux-fsdevel. This is a reproducible demonstration of the problem initially reported in my first e-mail, titled "PROBLEM: 'bio too big device' after moving to a USB disk" (http://lkml.org/lkml/2007/3/7/657) Summary: 01. Create LVM volume; initialize dm-crypt; initialize reiserfs; mount 02. Populate the disk with files; sync; flush caches 03. Confirm that the files are still readable and non-corrupt (sha1sum) 04. Migrate logical volume to USB disk; sync; flush caches 05. Confirm that ALL PREVIOUSLY VERIFIED FILES ARE CORRUPT 06. Observe "bio too big device dm-0 (256 > 240)" messages in dmesg 07. Run reiserfsck to check for corruptions -- none. 08. Migrate logical volume back to SATA disk; sync; flush caches 09. Confirm that files are readable and non-corrupt again 10. Clean up Environment/configuration: * Linux non 2.6.19-gentoo-r6 #1 Wed Feb 28 20:55:24 EET 2007 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux * USB disk 120GB Western Digital, model 00UE-00KVT0 (according to udev), serial DEF10CD7F64C * Older SATA disk 200GB Seagate 7200.7, model ST3200822AS * Motherboard Asus A8N5X, nForce4 chipset * Offending file system: reiserfs v3.6, mounted with noatime,barrier=flush * dm-crypt using aes-256 with cbc-essiv:sha256; using assembly-optimized AES on x86_64 (CONFIG_CRYPTO_AES_X86_64) * Test partition is 68 extents times 16MiB = 1088 MiB large (that's the largest I could allocate while remaining in one segment -- otherwise lvmove wouldn't move the partition back to /dev/sda5 after "defragmenting" it.) * LVM utilities version: 2.02.17 (2006-12-14) * LVM library version: 1.02.12 (2006-10-13) * LVM driver version: 4.10.0 * cryptsetup-luks 1.0.4 (user space interface to dm-crypt) Involved block devices: * /dev/sda: My old SATA disk. * /dev/sda5: The LVM partition on the old disk. * /dev/sdb: The new offending USB disk; whole disk is used as an LVM physical volume. * /dev/primary: LVM volume group 'primary', consisting of /dev/sdb and /dev/sda5 * /dev/primary/punchbag: LVM volume 'punchbag' for demonstration purposes. * /dev/mapper/crypt-punchbag: The dm-crypt "decrypted" loopback device. 00. PV information [non]# pvdisplay /dev/sda5 --- Physical volume --- PV Name /dev/sda5 VG Name primary PV Size 145.83 GB / not usable 2.73 MB Allocatable yes PE Size (KByte) 16384 Total PE 9333 Free PE 117 Allocated PE 9216 PV UUID YdrDuL-jw5z-J0SA-EEKU-NOC4-6gGR-T90YCA [non]# pvdisplay /dev/sdb --- Physical volume --- PV Name /dev/sdb VG Name primary PV Size 111.79 GB / not usable 9.46 MB Allocatable yes PE Size (KByte) 16384 Total PE 7154 Free PE 7129 Allocated PE 25 PV UUID nE8C5L-lfI1-VNgs-Q7ei-1Zz3-GeGT-UNhH4p 01. Create LVM volume; initialize dm-crypt; initialize reiserfs; mount [non]# lvcreate -n punchbag --extents 68 primary /dev/sda5 Logical volume "punchbag" created [non]# lvs --segments -o +devices LV VG Attr #Str Type SSize Devices [...] punchbag primary -wi-a-1 linear 1.06G /dev/sda5(0) [...] [non]# cryptsetup luksFormat /dev/primary/punchbag -c aes-cbc-essiv:sha256 -h sha1 [...] Are you sure? (Type uppercase yes): YES Enter LUKS passphrase: Verify passphrase: Command successful. [non]# cryptsetup luksOpen /dev/primary/punchbag crypt-punchbag Enter LUKS passphrase: key slot 0 unlocked. Command successful. [non]# mkfs.reiserfs /dev/mapper/crypt-punchbag [...] Guessing about desired format.. Kernel 2.6.19-gentoo-r6 is running. Format 3.6 with standard journal Count of blocks on the device: 343920 Number of blocks consumed by mkreiserfs formatting process: 8222 Blocksize: 4096 Hash function used to sort names: "r5" Journal Size 8193 blocks (first block 18) Journal Max transaction length 1024 inode generation number: 0 UUID: c1857208-5090-49dd-9163-9fb002d96a88 ATTENTION: YOU SHOULD REBOOT AFTER FDISK! ALL DATA WILL BE LOST ON '/dev/mapper/crypt-punchbag'! Continue (y/n):y Initializing journal - 0%20%40%60%80%100% Syncing..ok [...] ReiserFS is successfully created on /dev/mapper/crypt-punchbag. [non]# mkdir /mnt/punchbag [non]# mount /dev/mapper/crypt-punchbag /mnt/punchbag -o noatime,barrier=flush 02. Populate the disk with files; sync; flush caches [non]# cp -r ~marti/mp3 /mnt/punchbag [... yes, these are legal mp3s ;)] cp: writing `/mnt/punchbag/mp3/...': No space left on device ^C [non]# sync [non]# echo 3 > /proc/sys/vm/drop_caches [non]# cd /mnt/punchbag/mp3/mr\ Epic\ -\ Sideways 03. Confirm that the files are still readable and non-corrupt (sha1sum) [non]# sha1sum -c *.sha1 mr Epic - Sideways - 01. Down Low.flac: OK mr Epic - Sidewa
Re: [PATCH] Complain about missing system calls.
David Woodhouse <[EMAIL PROTECTED]> wrote: > > hm, did you try running this on x86_64? > > I don't have any. I only tested it on PowerPC and i386. Others then > provided more exclusions for SPARC and maybe ARM, although I'm not sure > you have the latter yet. It's not hard to add extra exclusions. You could always have asked to borrow my test box. David - 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/
JFFS2: BUG: sleeping function called from invalid context
When testing how JFFS2 handles write errors, the following message appears:
BUG: sleeping function called from invalid context at
include/linux/writeback.h:76
Here is the terminal output:
# uname -a
Linux ahunter-desktop 2.6.20ded11 #13 SMP PREEMPT Mon Mar 19 16:20:42 EET 2007
i686 GNU/Linux
# insmod $NANDSIM weakpages=444
NAND device: Manufacturer ID: 0x98, Chip ID: 0x39 (Toshiba NAND 8MiB 1,8V 8-bit)
flash size: 8 MiB
page size: 512 bytes
OOB area size: 16 bytes
sector size: 8 KiB
pages number: 16384
pages per sector: 16
bus width: 8
bits in sector size: 13
bits in page size: 9
bits in OOB size: 4
flash size with OOB: 8448 KiB
page address bytes: 3
sector address bytes: 2
options: 0x62
Scanning device for bad blocks
Creating 1 MTD partitions on "NAND 8MiB 1,8V 8-bit":
0x-0x0080 : "NAND simulator partition 0"
# mount -t jffs2 mtd0 /mnt/test_file_system
JFFS2 version 2.2. (NAND) (SUMMARY) (C) 2001-2006 Red Hat, Inc.
# pwd
/home/git/fs-tests/integrity
# ./integck -n0
[nandsim] warning: simulating write failure in page 444
jffs2_flush_wbuf(): Write failed with -5
In jffs2_wbuf_recover
Skipping node at 0x00036000(3)-0x000361c0 which is either before 0x00037800 or
obsolete
Skipping node at 0x000361c0(3)-0x00036204 which is either before 0x00037800 or
obsolete
Skipping node at 0x00036204(3)-0x00036f14 which is either before 0x00037800 or
obsolete
First node to be recovered is at 0x00036f14(3)-0x00037828
wbuf recover 00036f14-000378fc (2536 bytes in 3 nodes)
Write 0x800 bytes at 0x007a2000 in wbuf recover
Recovery of wbuf succeeded to 007a2000
Refiling block of 0914 at 00036f14(3) to 007a2000
calling jffs2_gc_fetch_inode
BUG: sleeping function called from invalid context at
include/linux/writeback.h:76
in_atomic():1, irqs_disabled():0
2 locks held by jffs2_gcd_mtd0/5710:
#0: (&c->wbuf_sem){}, at: [] jffs2_flash_writev+0x67/0x5c0
[jffs2]
#1: (&c->erase_completion_lock){--..}, at: []
jffs2_wbuf_recover+0xb03/0x11f1 [jffs2]
[] show_trace_log_lvl+0x1a/0x30
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] __might_sleep+0xb8/0xcb
[] ifind_fast+0x48/0x86
[] iget_locked+0x2a/0x133
[] jffs2_gc_fetch_inode+0x18e/0x229 [jffs2]
[] jffs2_wbuf_recover+0xd5e/0x11f1 [jffs2]
[] __jffs2_flush_wbuf+0x3b6/0x791 [jffs2]
[] jffs2_flash_writev+0x367/0x5c0 [jffs2]
[] jffs2_write_dnode+0x180/0x403 [jffs2]
[] jffs2_garbage_collect_dnode+0x7d3/0x8cd [jffs2]
[] jffs2_garbage_collect_live+0x242/0x31e [jffs2]
[] jffs2_garbage_collect_pass+0x99b/0xac9 [jffs2]
[] jffs2_garbage_collect_thread+0x341/0x396 [jffs2]
[] kernel_thread_helper+0x7/0x14
===
Refiling block of 008c at 00037828(3) to 007a2914
calling jffs2_gc_fetch_inode
Refiling block of 0048 at 000378b4(2) to 007a29a0
calling jffs2_gc_fetch_inode
wbuf recovery completed OK. wbuf_ofs 0x007a2800, len 0x1e8
-
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] Complain about missing system calls.
On Tue, Mar 20, 2007 at 07:43:08AM +, David Woodhouse wrote: > On Mon, 2007-03-19 at 16:42 -0700, Andrew Morton wrote: > > hm, did you try running this on x86_64? > > I don't have any. I only tested it on PowerPC and i386. Others then > provided more exclusions for SPARC and maybe ARM, although I'm not sure > you have the latter yet. It's not hard to add extra exclusions. Some of the ones which come up on x86_64 also come up on ARM for the same reason; they're obsolete system calls which probably shouldn't be implemented on anything but legacy i386. Things like waitpid, etc. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1 [PATCH] init/missing_syscalls.h fix
On Mon, Mar 19, 2007 at 08:56:23PM -0800, Andrew Morton wrote:
>
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
[..]
> +complain-about-missing-system-calls.patch
> +complain-about-missing-system-calls-update.patch
Hi,
I needed the following patch to fix this compile error (which does not
happend at first compile):
[EMAIL PROTECTED]:/usr/src/linux-2.6.21-rc4-mm1 $ rm init/missing_syscalls.h
[EMAIL PROTECTED]:/usr/src/linux-2.6.21-rc4-mm1 $ make init
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CHK include/linux/compile.h
GEN init/missing_syscalls.h
CC init/missing_syscalls.o
LD init/built-in.o
[EMAIL PROTECTED]:/usr/src/linux-2.6.21-rc4-mm1 $ cat
init/.missing_syscalls.h.cmd
cmd_init/missing_syscalls.h := sed -n
'/^\#define/s/[^_]*__NR_\([^[:space:]]*\).*/ \#if !defined (__NR_) \&\&
!defined (__IGNORE_)
\#warning syscall not implemented
\#endif/p' /usr/src/linux-2.6.21-rc4-mm1/include/asm-i386/unistd.h
>init/missing_syscalls.h
# (note all three \1 missing, replaced by char '^A', not visible here.
# note also that my /bin/sh is symlinked to dash (not bash) 0.5.3
[EMAIL PROTECTED]:/usr/src/linux-2.6.21-rc4-mm1 $ make init
CHK include/linux/version.h
CHK include/linux/utsrelease.h
init/.missing_syscalls.h.cmd:2: *** séparateur manquant . Arrêt.
make: *** [init] Erreur 2
As far as I understand it, Makefile rule cmd_missing_syscalls (from
init/Makefile) is used twice in two different ways:
- At first compile:
- run the command directly from Makefile,
- dump this command to init/.missing_syscalls.h.cmd for further use;
- At every but first compile:
- run existing init/.missing_syscalls.h.cmd
Can someone confirm that this is the right way to patch this ?
Thanks,
- Stéphane.
# complain-about-missing-system-calls-fix.patch
# Make generation of init/missing_syscalls.h more robust.
# Note: This fix is required only for "all but first" compilations, and
# perhaps only on some configurations (cf. /bin/sh).
Signed-off-by: Stéphane (kwisatz) Jourdois <[EMAIL PROTECTED]>
diff -uNr linux-2.6.21-rc4-mm1.orig/init/Makefile
linux-2.6.21-rc4-mm1/init/Makefile
--- linux-2.6.21-rc4-mm1.orig/init/Makefile 2007-03-20 09:54:23.0
+0100
+++ linux-2.6.21-rc4-mm1/init/Makefile 2007-03-20 11:19:02.0 +0100
@@ -35,10 +35,8 @@
quiet_cmd_missing_syscalls = GEN $@
- cmd_missing_syscalls = sed -n
'/^\#define/s/[^_]*__NR_\([^[:space:]]*\).*/\
- \#if !defined (__NR_\1) \&\& !defined (__IGNORE_\1)\n\
- \#warning syscall \1 not implemented\n\
- \#endif/p' $(srctree)/include/asm-i386/unistd.h >$@
+ cmd_missing_syscalls = sed -n -f scripts/mkmissing_syscalls_h \
+ $(srctree)/include/asm-i386/unistd.h >$@
targets += missing_syscalls.h
$(obj)/missing_syscalls.h: include/asm-i386/unistd.h
$(call if_changed,missing_syscalls)
diff -uNr linux-2.6.21-rc4-mm1.orig/scripts/mkmissing_syscalls_h
linux-2.6.21-rc4-mm1/scripts/mkmissing_syscalls_h
--- linux-2.6.21-rc4-mm1.orig/scripts/mkmissing_syscalls_h 1970-01-01
01:00:00.0 +0100
+++ linux-2.6.21-rc4-mm1/scripts/mkmissing_syscalls_h 2007-03-20
11:34:21.0 +0100
@@ -0,0 +1,6 @@
+/^\#define/ {
+ s/[^_]*__NR_\([^[:space:]]*\).*/\
+\#if !defined (__NR_\1) \&\& !defined (__IGNORE_\1)\
+\#warning syscall \1 not implemented\
+\#endif/p
+}
--
/// Stephane Jourdois /"\ ASCII RIBBON CAMPAIGN \\\
(((Consultant securite \ /AGAINST HTML MAIL)))
\\\ 24 rue Cauchy X ///
\\\ 75015 Paris / \+33 6 8643 3085///
-
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: Move to unshared VMAs in NOMMU mode?
Eric W. Biederman <[EMAIL PROTECTED]> wrote: > As I understand your description for non-shared mappings the VMAs are > per process. Are you talking about the current state of play? If so, not precisely. In the current scheme of things, *all* VMAs are kept in a global tree and are globally available; it's just that any VMA that's not shareable will not be shared, and so, in effect, is per-process. In my suggested revamp, VMAs revert to being per-process objects only, and sharing is effected by indirection. > For shared mappings you share in some sense the page cache. Currently, no - not unless the driver does something clever as ramfs does. Sharing through the page cache is a nice idea, but it has some limitations, mainly that non-sharing then operates differently. > My gut feel says just keep a vma per process of the regions the > process has and do the appropriate book keeping and all will be fine. I'm sure it will be, but at the cost of consuming extra memory. I'm not sure that the amount of extra memory is, however, all that significant. Now that I think about it, I don't imagine that a lot of processes are going to be running at once on a NOMMU system, and so the scope for sharing isn't all that wide. > For shm_nattach it looks like you simply are not calling the > open/close methods on fork (because you have a shared pool of vmas). There is no fork. No, the problem is that sys_shmat() relies on do_mmap_pgoff() to call the VMA open() method. However, this assumes that a new VMA will be made per process. David - 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 4/4] coredump: documentation for proc entry
Hi Pavel, I'm sorry for my late reply. Pavel Machek wrote: > Hi! > >>+If you don't want to dump all shared memory segments attached to pid 1234, >>+write 0 to the process's proc file. >>+ >>+ $ echo 1 > /proc/1234/coredump_omit_anonymous_shared > > Write 0? Thank you for pointing out. It seems I mistook when I changed the documents. `write 1' is correct. >>+When a new process is created, the process inherits the flag status from its >>+parent. It is useful to set the flag before the program runs. >>+For example: >>+ >>+ $ echo 1 > /proc/self/coredump_omit_anonymous_shared >>+ $ ./some_program >>+ > > Notice that this docs is wrong. You have to retry until kernel stops > producing spurious errors. > Pavel I'll fix the patchset so that kernel doesn't produce the spurious error. For answers to your another mail, please wait a few days. I'm still considering the answer partly. Thanks, -- Hidehiro Kawai Hitachi, Ltd., Systems Development Laboratory - 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/
dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
On 15-03-2007 20:17, Folkert van Heusden wrote:
>>> On Tue, 13 Mar 2007 17:50:14 +0100 Folkert van Heusden <[EMAIL PROTECTED]>
>>> wrote:
...
> Haha ok :-)
>
> Good, since I run 2.6.20 with these debugging switches switched on, I
> get occasionally errors like these. I get ALWAYS the following error
> when the system first boots when the TOR executable is started:
>
> [ 137.324255] ===
> [ 137.324359] [ INFO: possible circular locking dependency detected ]
> [ 137.324412] 2.6.20 #2
> [ 137.324457] ---
> [ 137.324510] tor/4857 is trying to acquire lock:
> [ 137.324559] (tty_mutex){--..}, at: [] mutex_lock+0x8/0xa
> [ 137.324765]
> [ 137.324766] but task is already holding lock:
> [ 137.324859] (&s->s_dquot.dqptr_sem){}, at: []
> dquot_alloc_space+0x50/0x189
> [ 137.325067]
> [ 137.325069] which lock already depends on the new lock.
IMHO lockdep found that two locks are taken in different order:
-> #1: 1) tty_mutex in con_console() 2) dqptr_sem (somewhere later)
-> #0: 1) dqptr_sem 2) tty_console in dquot_alloc_space() with print_warning()
Probably print_warning() and flush_warnings() should be reworked
to do printing without dqptr_sem or locking order should be changed.
I hope somebody from this CC can work it out better.
Regards,
Jarek P.
> [ 137.325071]
> [ 137.325206]
> [ 137.325208] the existing dependency chain (in reverse order) is:
> [ 137.325300]
> [ 137.325301] -> #4 (&s->s_dquot.dqptr_sem){}:
> [ 137.325501][] check_prev_add+0x154/0x206
> [ 137.325852][] check_prevs_add+0x6a/0xd5
> [ 137.326197][] __lock_acquire+0x61c/0xa05
> [ 137.326538][] lock_acquire+0x62/0x81
> [ 137.326887][] down_read+0x2b/0x3d
> [ 137.327241][] dquot_alloc_space+0x50/0x189
> [ 137.327588][] ext3_new_blocks+0x44b/0x5a2
> [ 137.327935][] ext3_alloc_blocks+0x40/0xdf
> [ 137.328280][] ext3_alloc_branch+0x50/0x21b
> [ 137.328622][] ext3_get_blocks_handle+0x1b8/0x367
> [ 137.328980][] ext3_getblk+0x97/0x228
> [ 137.329330][] ext3_bread+0x1a/0x78
> [ 137.329672][] ext3_mkdir+0xf4/0x270
> [ 137.330022][] vfs_mkdir+0xb3/0x161
> [ 137.330368][] sys_mkdirat+0x8c/0xc4
> [ 137.330714][] sys_mkdir+0x20/0x22
> [ 137.331063][] syscall_call+0x7/0xb
> [ 137.331406][] 0x
> [ 137.331771]
> [ 137.331772] -> #3 (&ei->truncate_mutex){--..}:
> [ 137.331979][] check_prev_add+0x154/0x206
> [ 137.332332][] check_prevs_add+0x6a/0xd5
> [ 137.332676][] __lock_acquire+0x61c/0xa05
> [ 137.333025][] lock_acquire+0x62/0x81
> [ 137.70][] __mutex_lock_slowpath+0x75/0x28c
> [ 137.333930][] mutex_lock+0x8/0xa
> [ 137.334271][] ext3_truncate+0x170/0x468
> [ 137.334613][] vmtruncate+0xa6/0x116
> [ 137.334949][] inode_setattr+0x145/0x16c
> [ 137.335286][] ext3_setattr+0x150/0x22f
> [ 137.335627][] notify_change+0x35b/0x392
> [ 137.335968][] do_truncate+0x52/0x75
> [ 137.336305][] may_open+0x1ec/0x231
> [ 137.336642][] open_namei+0xda/0x59b
> [ 137.336975][] do_filp_open+0x2c/0x53
> [ 137.337310][] do_sys_open+0x52/0xd8
> [ 137.337645][] sys_open+0x1c/0x1e
> [ 137.337980][] syscall_call+0x7/0xb
> [ 137.338315][] 0x
> [ 137.338665]
> [ 137.338666] -> #2 (&inode->i_alloc_sem){--..}:
> [ 137.338864][] check_prev_add+0x154/0x206
> [ 137.339200][] check_prevs_add+0x6a/0xd5
> [ 137.339535][] __lock_acquire+0x61c/0xa05
> [ 137.339200][] check_prevs_add+0x6a/0xd5
> [ 137.339535][] __lock_acquire+0x61c/0xa05
> [ 137.339874][] lock_acquire+0x62/0x81
> [ 137.340207][] down_write+0x2b/0x45
> [ 137.340545][] notify_change+0x2e2/0x392
> [ 137.340886][] do_truncate+0x52/0x75
> [ 137.341222][] may_open+0x1ec/0x231
> [ 137.341557][] open_namei+0xda/0x59b
> [ 137.341898] [] sys_open+0x1c/0x1e
> [ 137.343109][] syscall_call+0x7/0xb
> [ 137.343444][] 0x
> [ 137.343792]
> [ 137.343793] -> #1 (&sysfs_inode_imutex_key){--..}:
> [ 137.343988][] check_prev_add+0x154/0x206
> [ 137.344320][] check_prevs_add+0x6a/0xd5
> [ 137.344655][] __lock_acquire+0x61c/0xa05
> [ 137.344986][] lock_acquire+0x62/0x81
> [ 137.345321][] __mutex_lock_slowpath+0x75/0x28c
> [ 137.345658][] mutex_lock+0x8/0xa
> [ 137.345991][] sysfs_hash_and_remove+0x43/0x11c
> [ 137.346328][] sysfs_remove_file+0xd/0x12
> [ 137.346660][] device_remove_file+0x32/0x44
> [ 137.346992][] device_del+0x174/0x1d2
> [ 137.347325][] device_unregister+0xb/0x15
> [ 137.347661][] device_destroy+0x8d/0x9a
> [ 137
Re: [1/6] 2.6.21-rc4: known regressions
On Tue, Mar 20, 2007 at 11:24:41AM +0100, Tobias Diedrich wrote: > Adrian Bunk wrote: > > This email lists some known regressions in Linus' tree compared to 2.6.20. > > Since I didn't see any mention of this: > > I'm seeing an Oops when removing the ohci1394 module: > > [ 16.047275] ieee1394: Node removed: ID:BUS[158717321-38:0860] > GUID[c033ced6] > [ 16.047287] BUG: unable to handle kernel NULL pointer dereference at > virtual address 0094 > [ 16.047451] printing eip: > [ 16.047524] c02daf3d > [ 16.047527] *pde = > [ 16.047603] Oops: [#1] > [ 16.047676] PREEMPT > [ 16.047788] Modules linked in: backlight ohci1394 parport_pc parport > [ 16.048069] CPU:0 > [ 16.048071] EIP:0060:[]Not tainted VLI > [ 16.048074] EFLAGS: 00010246 (2.6.21-rc4 #35) > [ 16.048298] EIP is at class_device_remove_attrs+0xa/0x30 > [ 16.048377] eax: dfd04338 ebx: ecx: df655988 edx: > [ 16.048456] esi: edi: dfd04338 ebp: esp: df506e38 > [ 16.048535] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > [ 16.048614] Process rmmod (pid: 1455, ti=df506000 task=df6cc0b0 > task.ti=df506000) > [ 16.048693] Stack: dfd04338 dfd04340 c02db02f dfd04338 > dfd041e4 c0331871 > [ 16.049159] c02db065 dfd041b0 c0331858 c055006d 0975d589 > 0026 035c > [ 16.049626] c033ced6 df24c000 c0331879 c02d859f > df24c0bc df24c0bc > [ 16.050091] Call Trace: > [ 16.050233] [] class_device_del+0xcc/0xfa > [ 16.050352] [] __nodemgr_remove_host_dev+0x0/0xb >... > [ 16.057248] EIP: [] class_device_remove_attrs+0xa/0x30 SS:ESP > 0068:df506e38 >... You missed the following entry in my list [1]: Subject: Oops in __nodemgr_remove_host_dev References : http://lkml.org/lkml/2007/3/14/4 http://lkml.org/lkml/2007/3/18/87 Submitter : Ismail Dönmez <[EMAIL PROTECTED]> Stefan Richter <[EMAIL PROTECTED]> Thomas Meyer <[EMAIL PROTECTED]> Caused-By : Greg Kroah-Hartman <[EMAIL PROTECTED]> commit 43cb76d91ee85f579a69d42bc8efc08bac560278 commit 40cf67c5fcc513406558c01b91129280208e57bf Handled-By : Stefan Richter <[EMAIL PROTECTED]> Status : problem is being debugged cu Adrian [1] not meant as an offence - there are so many items in the list that it's easy to miss one -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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] ptrace needs PROC_FS
Hi! > Thanks, that Kconfig change seems like the simplest solution for this. Simplest, maybe, but is it right? Ptrace should work without /proc, no? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski wrote: ... > IMHO lockdep found that two locks are taken in different order: > > -> #1: 1) tty_mutex in con_console() 2) dqptr_sem (somewhere later) > -> #0: 1) dqptr_sem 2) tty_console in dquot_alloc_space() with print_warning() Should be: -> #0: 1) dqptr_sem 2) tty_mutex in dquot_alloc_space() with print_warning() Jarek P. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
On Tue, Mar 20, 2007 at 12:22:53PM +0100, Jarek Poplawski wrote: > On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski wrote: > ... > > IMHO lockdep found that two locks are taken in different order: > > > > -> #1: 1) tty_mutex in con_console() 2) dqptr_sem (somewhere later) > > -> #0: 1) dqptr_sem 2) tty_console in dquot_alloc_space() with > > print_warning() Once more - should be: -> #1: 1) tty_mutex in con_close() 2) dqptr_sem (somewhere later) -> #0: 1) dqptr_sem 2) tty_mutex in dquot_alloc_space() with print_warning() Very sorry!!! Jarek P. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][5/5][resend] floppy.c: Fix device_create_file() warning
> The floppy driver's sysfs file just provides some auxiliary > information to user-space, none of which matters for most of > its users. It is IMO totally inappropriate to fail floppy > driver init in this case. I thought it was for udev to create the device nodes? But I might be wrong on that. If it's ok to ignore such failures there sometimes then the warning attribute should be dropped. But just shutting the warning up is the wrong change. Beides if floppy doesn't need sysfs for anything why does it initialize sysfs? IMHO sysfs should be only used if there is a good reason, otherwise it is just wasted memory. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.21-rc1,2,3 regressions on my system that I found so far
On Mon, Mar 19, 2007 at 09:27:34PM -0700, Greg KH wrote: > On Sat, Mar 17, 2007 at 02:26:57PM +0100, Andi Kleen wrote: > > Arjan van de Ven <[EMAIL PROTECTED]> writes: > > > > > > well we can do the handshake to take ownership like we do much later in > > > boot, but that requires PCI to be there and fully discovered, which we > > > don't have this early. > > > > That's not true - we do early pci discovery. Doing USB handsoff > > there would be quite possible. > > What, we don't do USB "handoff" early enough in the boot process? It's > happening at PCI quirk time now, which I think should be early enough > for everyone (and too early for some who rely on USB keyboards and Early for drivers, but quite late for architecture initialization. > initramfs shells...) It's long after timer calibration, which is what it interfered with here. To handle that it would need to be moved to the x86 early quirks and use boot_ioremap etc. It would be probably somewhat messy, but doable. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.21-rc1,2,3 regressions on my system that I found so far
Am Dienstag, 20. März 2007 12:36 schrieb Andi Kleen: > It's long after timer calibration, which is what it interfered with here. > > To handle that it would need to be moved to the x86 early quirks and > use boot_ioremap etc. It would be probably somewhat messy, but doable. USB is not specific to x86. And not necessarily the only user of SMM. Is this really necessary? Regards Oliver - 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: mm snapshot broken-out-2007-03-18-02-44.tar.gz uploaded
On Mon, Mar 19, 2007 at 04:25:29PM -0700, Andrew Morton wrote: > On Sun, 18 Mar 2007 19:35:48 +0100 > Michal Piotrowski <[EMAIL PROTECTED]> wrote: > > > WARNING: could not find versions for .tmp_versions/built-in.mod > > WARNING: could not find versions for .tmp_versions/built-in.mod > > WARNING: could not find versions for .tmp_versions/built-in.mod > > WARNING: could not find versions for .tmp_versions/built-in.mod > > WARNING: could not find versions for .tmp_versions/built-in.mod > > WARNING: could not find versions for .tmp_versions/built-in.mod > > This is caused by git-kbuild. I don't know what the significance of it is. This is caused by the patch that runs modpost on all files used to make up vmlinux. The warning is harmless and I will try to fix it up tonight or tomorrow. Sam - 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][5/5][resend] floppy.c: Fix device_create_file() warning
On Tue, 20 Mar 2007 12:29:49 +0100 (CET), Andreas Kleen <[EMAIL PROTECTED]> wrote: > > The floppy driver's sysfs file just provides some auxiliary > > information to user-space, none of which matters for most of > > its users. It is IMO totally inappropriate to fail floppy > > driver init in this case. > > I thought it was for udev to create the device nodes? But > I might be wrong on that. It's a file called "cmos" containing the ASCII representation of UDP->cmos, which appears to be some kind of "type" indicator. See floppy_cmos_show(). The file is only readable, not even root can write to it. On one of my machines it contains the value "4", but the device nodes udev created are still just /dev/fd0 and /dev/floppy -> /dev/fd0, so I don't think it affects udev. The "cmos" file seems to be a relatively new addition, as another machine here running an RHEL4 2.6.9 kernel doesn't have it. Unless someone can prove that it's useful I think it should be removed. /Mikael - 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/
s2ram autowake regression is still there in 2.6.21-rc4-git
Hi! Run this script. The s2ram at the end of it will wakeup immediately after going to sleep, bad. I tried reproducing it with smaller version, but was not too successful. Pavel #!/bin/bash killall klogd echo -n "testing refrigerator (testproc)..." echo testproc > /sys/power/disk echo disk > /sys/power/state echo "okay" sleep 2 echo -n "testing drivers (test)..." echo test > /sys/power/disk echo disk > /sys/power/state echo "okay" sleep 2 echo -n "testing swsusp (reboot)..." echo reboot > /sys/power/disk echo disk > /sys/power/state echo "okay" sleep 2 echo -n "testing s2ram..." s2ram echo "okay" sleep 2 echo -n "testing swsusp (shutdown)..." echo shutdown > /sys/power/disk echo disk > /sys/power/state echo "okay" sleep 2 echo -n "testing swsusp (platform)..." echo platform > /sys/power/disk echo disk > /sys/power/state echo "okay" sleep 2 echo -n "testing s2ram..." s2ram echo "okay" -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: s2ram autowake regression is still there in 2.6.21-rc4-git
Hi! > Run this script. The s2ram at the end of it will wakeup immediately > after going to sleep, bad. I tried reproducing it with smaller > version, but was not too successful. Actually > sleep 2 > echo -n "testing swsusp (platform)..." > echo platform > /sys/power/disk > echo disk > /sys/power/state > echo "okay" > > sleep 2 > echo -n "testing s2ram..." > s2ram > echo "okay" ...this is enough to trigger it. I've done my testing on x60, FWIW. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
On Tue 20-03-07 12:31:51, Jarek Poplawski wrote: > On Tue, Mar 20, 2007 at 12:22:53PM +0100, Jarek Poplawski wrote: > > On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski wrote: > > ... > > > IMHO lockdep found that two locks are taken in different order: > > > > > > -> #1: 1) tty_mutex in con_console() 2) dqptr_sem (somewhere later) > > > -> #0: 1) dqptr_sem 2) tty_console in dquot_alloc_space() with > > > print_warning() > > Once more - should be: > -> #1: 1) tty_mutex in con_close() 2) dqptr_sem (somewhere later) > -> #0: 1) dqptr_sem 2) tty_mutex in dquot_alloc_space() with print_warning() Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex being acquired under dqptr_sem in quota code. But looking at the path from con_close() there's another inversion with i_mutex which is also acquired along the path for sysfs. And we can hardly get rid of it in the quota code. Now none of these is a real deadlock as quota should never call print_warning() for sysfs (it doesn't use quota) but still it's nasty. I suppose tty_mutex is above i_mutex because of those sysfs calls and it seems sysfs must be called under tty_mutex because of races with init_dev(). So it's not easy to get rid of that dependency either. Honza -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - 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] Complain about missing system calls.
On Thu, Mar 08, 2007 at 04:14:07PM -0800, David Miller wrote: > From: David Woodhouse <[EMAIL PROTECTED]> > Date: Thu, 08 Mar 2007 23:01:13 + > > > Most system calls seem to get added to i386 first. This patch > > automatically generates a warning for any new system call which is > > implemented on i386 but not the architecture currently being compiled. > > On PowerPC at the moment, for example, it results in these warnings: > > init/missing_syscalls.h:935:3: warning: #warning syscall sync_file_range > > not implemented > > init/missing_syscalls.h:947:3: warning: #warning syscall getcpu not > > implemented > > init/missing_syscalls.h:950:3: warning: #warning syscall epoll_pwait not > > implemented > > > > Signed-off-by: David Woodhouse <[EMAIL PROTECTED]> > > David, thanks for this __incredibly__ __useful__ patch. I kicked it > around on sparc64 and found some more ignores to add, see below. > > The vast majority of them vector to sys_ni_syscall in the i386 syscall > table. > > sys_ugetrlimit is only necessary if the platform started out > using the non-SuS compliant sys_old_getrlimit() > > The rest, like ioperm, iopl, modify_ldt, et al. are i386 > specific. > > Signed-off-by: David S. Miller <[EMAIL PROTECTED]> > > --- a/init/missing_syscalls.c.ORIG2007-03-08 16:11:00.0 -0800 > +++ b/init/missing_syscalls.c 2007-03-08 16:02:30.0 -0800 > @@ -18,6 +18,22 @@ > #endif > > /* i386-specific or historical system calls */ > +#define __IGNORE_break Could it make sense to keep this in arch specific header files? So when we fiddle with ARM we do not impact SPARC etc. And in this way ARCH specific changes are kept in ARCH specific files. For the "Ignore historical" part this should be in a common file I think. So in other words: init/missing_syscalls.h => Contains common stuff and include: include/asm/missing_syscalls.h => contains ARCH specific stuff. Sam - 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 00/22 take 3] UBI: Unsorted Block Images
On Mon, 2007-03-19 at 14:54 -0500, Matt Mackall wrote: > > False starts that get mainlined delay or prevent things getting done > right. The question is and remains "is UBI the right way to do > things?" Not "is UBI the easiest way to do things?" or "is UBI > something people have already adopted?" > > If the right way is instead to extend the block layer and device > mapper to encompass the quirks of NAND in a sensible fashion, then UBI > should not go in. This is where we disagree obviously. However, getting UBI into mainline won't delay or prevent your proposal from getting done. That's like saying having ext3 in mainline prevents other filesystems from getting created. There is nothing wrong with having different subsystems that overlap in a few areas. What you're proposing seems like it would take at least several weeks to even get close to what is needed in terms of reliability and the required wear-leveling if it is indeed possible to implement. And it would likely duplicate some of the wear-leveling and bad block handling code that is present in UBI anyway. In the meantime, the need for UBI exists today and there is a working, tested implementation available. josh - 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.21-rc3-mm2
On Mon, Mar 19, 2007 at 05:27:11PM -0700, Randy Dunlap wrote: > On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote: > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/ > > > > - This is the same as 2.6.21-rc3-mm1, except Con's CPU scheduler changes > > were dropped. > > > > This is for A/B comparison purposes, and because those changes crashed on > > one test setup. > > I don't quite see why this error is happening. Looks like all > the nested #includes should handle it... > > CONFIG_KEXEC=y > CONFIG_CRASH_DUMP=y > CONFIG_UTRACE=y > # PTRACE=n > # PROC_FS=n > > In file included from arch/x86_64/kernel/crash.c:19: > include/linux/elfcore.h: In function 'elf_core_copy_regs': > include/linux/elfcore.h:103: error: dereferencing pointer to incomplete type > include/linux/elfcore.h:103: error: dereferencing pointer to incomplete type > make[1]: *** [arch/x86_64/kernel/crash.o] Error 1 > make: *** [arch/x86_64/kernel] Error 2 make arch/x86_64/kernel/crash.i may tell you a bit more why the includes foes wrong. Sam - 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 00/22 take 3] UBI: Unsorted Block Images
>
> iSCSI/nbd(6)
> |
> filesystem {swap | ext3ext3 jffs2
> \ | || /
>/ \ | dm-crypt->snapshot(5) /
> device mapper -|\ \ | /
>| partitioning /
>| | partitioning(4)
>|wear leveling(3) /
>| | /
>| block concatenation
>| ||| |
>\ bad block remapping(2)
>||| |
> MTD raw block { raw block devices with no smarts(1)
> / | \ \
> hardware { NANDNAND NAND NAND
You failed to clearly define what is block until now, then you blame me
that I do not understand you. So I see block = eraseblock, lets assume
for further conversation.
OK. Suppose we have done what you say, although I _do not_ think it is
makes a lot of sense. So, now we have a block device, with 128KiB block
size. We have LVM, dm-wl or whatever stuff. Fine.
Do you realize that 128KiB is _huge_ block size, and performance will
suck, and suck a lot if you utilize say, ext2 or whatever block device
FS.
Do you realize that I may not be satisfied with slow I/O? Do I have
right to have faster one? Thanks if yes.
To make it faster I have to have a way to do finer grained I/O:
read/write to different positions of 128KiB block. Do you realize how
much you will abuse all the generic block device infrastructure if you
try to add this? Note, all levels up to LVM will need to have this. A
believe it is braindead ((c) tglx) to add this feature.
Also, in UBI we have the following features:
1. data type hints: you basically may help UBI to pick optimal
eraseblock if you specify data life-time - is it long-live data, or
short-live/temporary data.
2. Some other ones, do not want to describe now.
Do you offer to add this stuff to DM-mapper?
So, you approach only makes sense if you are going to work with flash as
block device with block size = eraseblock size. No finer grained access
at all. It is fine, some users may be ok with this. But please, do not
be so naive - the performance will suck a _lot_. Let alone I doubt it
will really fit the DM infrastructure.
We work on different approach. And in general, the picture which Thomas
drew to you makes _much more_ sense. Please, do not be so stuck to your
way, it is not bad or good, it is just _different_, and it has obvious
limitations which we do not want to have, thus we go other way.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] split file and anonymous page queues #2
Nick Piggin wrote: Rik van Riel wrote: We apply pressure to each of sets of the pageout queues based on: - the size of each queue - the fraction of recently referenced pages in each queue, not counting used-once file pages - swappiness (file IO is more efficient than swap IO) This ignores whether a file page is mapped, doesn't it? Even so, it could be a good approach anyway. It does, but once it gets the file list down to the size where it finds that a fair number of the pages were referenced, it will back off the pressure automatically. Also, we do not apply the used-once algorithm to mapped pages, meaning that mapped pages with the accessed bit set always get rotated back onto the active list, while unmapped pages do not. There are a couple of little nice improvements you have there, such as treating shmem pages in the same class as anon pages. We found that we needed something similar, so some of those things should go upstream on their own. It will be hard to merge that "on its own" without the split queues. I can't really think of a good way to split this patch up into multiple functional bits... -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - 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/
"reboot" swsusp mode leaves moon icon blinking
Hi!
...and cause is really simple.
During resume, we do not know that "reboot" method was used, so we
assume plaform and make the led blink...
Unfortunately I see no easy solution, and this may/will cause other
problems -- in case of broken bios and user telling us not to call
that bios, we'll call it anyway.
(Ouch and I think this is regression after 2.6.20?)
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Pavel
diff --git a/kernel/power/disk.c b/kernel/power/disk.c
index 873cdf8..dee0ff4 100644
--- a/kernel/power/disk.c
+++ b/kernel/power/disk.c
@@ -241,18 +241,11 @@ static int software_resume(void)
goto Done;
}
- error = platform_prepare();
- if (error) {
- swsusp_free();
- goto Thaw;
- }
-
pr_debug("PM: Reading swsusp image.\n");
error = swsusp_read();
if (error) {
swsusp_free();
- platform_finish();
goto Thaw;
}
@@ -270,7 +263,6 @@ static int software_resume(void)
enable_nonboot_cpus();
Free:
swsusp_free();
- platform_finish();
device_resume();
resume_console();
Thaw:
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
x60 time travels after resume
Hi! ..and machine is pretty unhappy about that. I triggered it by paralel-building kernel while suspending/resuming. [EMAIL PROTECTED]:/home/pavel/sf/suspend# date Thu Feb 12 05:22:32 CET 1914 [EMAIL PROTECTED]:/home/pavel/sf/suspend# ...and no, it is not easily reproducible :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html delme.gz Description: Binary data
BUG: soft lockup during suspend
Hi! I got this nastinness in my syslog... perhaps HDA intel takes too long to play with its hardware? Or should we just kill the softlockup watchdog since Linux is not realtime system, yet? Pavel HDA Intel :00:1b.0: freeze BUG: soft lockup detected on CPU#0! [] softlockup_tick+0xa9/0xd0 [] update_process_times+0x33/0x80 [] tick_periodic+0x22/0x70 [] tick_handle_periodic+0x17/0x80 [] tick_do_broadcast+0x6a/0x80 [] tick_do_periodic_broadcast+0x1c/0x30 [] tick_handle_periodic_broadcast+0x1b/0x60 [] tick_do_periodic_broadcast+0x1c/0x30 [] timer_interrupt+0x2c/0x40 [] handle_IRQ_event+0x25/0x60 [] handle_edge_irq+0xe7/0x130 [] do_IRQ+0x3b/0x80 [] do_IRQ+0x40/0x80 [] common_interrupt+0x23/0x28 [] ieee80211_wx_get_scan+0x2b/0x130 [] delay_tsc+0x14/0x20 [] __delay+0x6/0x10 [] azx_send_cmd+0xfa/0x110 [] snd_hda_codec_write+0x3e/0x60 [] hda_set_power_state+0xab/0xe0 [] snd_hda_suspend+0x48/0x60 [] azx_suspend+0x52/0xd0 [] pci_device_suspend+0x23/0x70 [] suspend_device+0x11b/0x2e0 [] device_suspend+0xb2/0x170 [] printk+0x1b/0x20 [] pm_suspend_disk+0x4d/0x2b0 [] enter_state+0x195/0x220 [] state_store+0xa9/0xc0 [] state_store+0x0/0xc0 [] subsys_attr_store+0x29/0x40 [] sysfs_write_file+0xac/0x130 [] vfs_write+0xa6/0x140 [] sysfs_write_file+0x0/0x130 [] syscall_call+0x7/0xb [] ieee80211_translate_scan+0xa00/0xa50 === ACPI: PCI interrupt for device :00:1b.0 disabled -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: soft lockup during suspend
At Tue, 20 Mar 2007 13:32:53 +0100, Pavel Machek wrote: > > Hi! > > I got this nastinness in my syslog... perhaps HDA intel takes too long > to play with its hardware? Or should we just kill the softlockup > watchdog since Linux is not realtime system, yet? X60/T60 is known to be often broken regarding the communication between the controller and the codec chip. When this kind of thing happens, the driver tries to switch to a single-shot I/O without using ring-buffers and IRQs, and even in such a mode, the communication gets broken. FWIW, it doesn't happen on other machines with HD-audio, so it's fairly specific to X60/T60. No idea why. Takashi > Pavel > > HDA Intel :00:1b.0: freeze > BUG: soft lockup detected on CPU#0! > [] softlockup_tick+0xa9/0xd0 > [] update_process_times+0x33/0x80 > [] tick_periodic+0x22/0x70 > [] tick_handle_periodic+0x17/0x80 > [] tick_do_broadcast+0x6a/0x80 > [] tick_do_periodic_broadcast+0x1c/0x30 > [] tick_handle_periodic_broadcast+0x1b/0x60 > [] tick_do_periodic_broadcast+0x1c/0x30 > [] timer_interrupt+0x2c/0x40 > [] handle_IRQ_event+0x25/0x60 > [] handle_edge_irq+0xe7/0x130 > [] do_IRQ+0x3b/0x80 > [] do_IRQ+0x40/0x80 > [] common_interrupt+0x23/0x28 > [] ieee80211_wx_get_scan+0x2b/0x130 > [] delay_tsc+0x14/0x20 > [] __delay+0x6/0x10 > [] azx_send_cmd+0xfa/0x110 > [] snd_hda_codec_write+0x3e/0x60 > [] hda_set_power_state+0xab/0xe0 > [] snd_hda_suspend+0x48/0x60 > [] azx_suspend+0x52/0xd0 > [] pci_device_suspend+0x23/0x70 > [] suspend_device+0x11b/0x2e0 > [] device_suspend+0xb2/0x170 > [] printk+0x1b/0x20 > [] pm_suspend_disk+0x4d/0x2b0 > [] enter_state+0x195/0x220 > [] state_store+0xa9/0xc0 > [] state_store+0x0/0xc0 > [] subsys_attr_store+0x29/0x40 > [] sysfs_write_file+0xac/0x130 > [] vfs_write+0xa6/0x140 > [] sysfs_write_file+0x0/0x130 > [] syscall_call+0x7/0xb > [] ieee80211_translate_scan+0xa00/0xa50 > === > ACPI: PCI interrupt for device :00:1b.0 disabled > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RSDL v0.31
Xavier Bestel wrote: > On Tue, 2007-03-20 at 07:11 +0100, Willy Tarreau wrote: >> I don't agree with starting to renice X to get something usable > > X looks very special to me: it's a big userspace driver, the primary > task handling user interaction on the desktop, and on some OS the part > responsible for moving the mouse pointer and interacting with windows is > even implemented as an interrupt handler, and that for sure provides for > smooth user experience even on very low-end hardware. Why not compensate > for X design by prioritizing it a bit ? > If RSDL + reniced X makes for a better desktop than sotck kernel + X, on > all kind of workloads, it's good to know. No, running X at a different priority than its clients is not really a good idea. If it isn't immediately obvious why try something like this: mkdir /tmp/tempdir cd /tmp/tempdir for i in `seq -w 1 1` ; do touch longfilenamexx$i ; done nice --20 xterm & xterm & nice -20 xterm & then do "time ls -l ." in each xterm. This is what i get on UP 2.6.20+RSDL.31 w/ X at nice 0: -20: 0m0.244s user 0m0.156s system 0m3.113s elapsed 12.84% CPU 0: 0m0.216s user 0m0.168s system 0m2.801s elapsed 13.70% CPU 19: 0m0.188s user 0m0.196s system 0m3.268s elapsed 11.75% CPU I just made this simple example up and it doesn't show the problem too well, but you can already see the ~10% performance drop. It's actually worse in practice, because for some apps the increased amount of rendering is clearly visible; text areas scroll line-by-line, content is incrementally redrawn several times etc. This happens because an X server running at a higher priority than a client will often get scheduled immediately after some x11 traffic arrives; when the process priorities are equal usually the client gets a chance to supply some more data. IOW by renicing the server you make X almost synchronous. This isn't specific to RSDL - it happens w/ any cpu scheduler; and while the effects of less extreme prio differences (ie -5 instead of -20 etc) may be less visible i also doubt they will help much. A better approach to X interactivity might be allowing the server to use (part of) the clients timeslice, but it's not trivial -- you'd only want to do that when the client is waiting for a reply and you almost never want to preempt the client just because the server received some data. As to RSDL - it seems to work great for desktop use and feels better than mainline. However top output under 100% load (eg kernel compilation) looks like below -- the %CPU error seems a bit high... Tasks: 97 total, 6 running, 91 sleeping, 0 stopped, 0 zombie Cpu(s): 81.7% us, 18.3% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 7566 root 17 0 9196 4108 1188 R 3.0 0.8 0:00.09 cc1 7499 root 11 0 1952 924 648 S 0.3 0.2 0:00.01 make 12279 root 1 0 5556 2928 2064 S 0.3 0.6 0:00.83 xterm 31510 root 1 0 2152 1100 840 R 0.3 0.2 0:00.25 top 1 root 1 0 1584 88 60 S 0.0 0.0 0:00.30 init artur - 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.21-rc4-mm1 [PATCH] init/missing_syscalls.h fix
Stephane Jourdois wrote: On Mon, Mar 19, 2007 at 08:56:23PM -0800, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ [..] +complain-about-missing-system-calls.patch +complain-about-missing-system-calls-update.patch Hi, I needed the following patch to fix this compile error (which does not happend at first compile): [..] # (note all three \1 missing, replaced by char '^A', not visible here. # note also that my /bin/sh is symlinked to dash (not bash) 0.5.3 [..] Can someone confirm that this is the right way to patch this ? Can't confirm the correctness but I can confirm that this problem appears for me using both bash and dash and that the attached patch allows compile to progress. Cheers :) --Ben. Thanks, - Stéphane. - 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/3] swsusp: Do not use page flags
Hi! > > The patch is designed to minimize the amount of changes and there are some > > nice > > simplifications and optimizations possible on top of it. I am going to > > implement them separately in the future. > > Blows up with ia64 allmodconfig due to CONFIG_PM=y, CONFIG_SOFTWARE_SUSPEND=n: > > kernel/power/main.c:223: error: redefinition of 'software_suspend' > include/linux/suspend.h:46: error: previous definition of 'software_suspend' > was here > > I had a look at fixing it, but it's unobvious why we're compiling most of > kernel/power/main.c when CONFIG_SOFTWARE_SUSPEND=n so I'll send this series > back for repair please. main.c is needed for suspend-to-ram, too. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RSDL v0.31
Linus Torvalds wrote:
Quite frankly, I was *planning* on merging RSDL very early after 2.6.21,
but there is one thing that has turned me completely off the whole thing:
- the people involved seem to be totally unwilling to even admit there
might be a problem.
Not to mention that it seems to only be tested thus far
by a very vocal and supportive core. It needs much wider
exposure for much longer before risking it in mainline.
It likely will get there, eventually, just not yet.
I've droppped it from my machine -- interactive response is much
more important for my primary machine right now.
I believe Ingo's much simpler hack produces as good/bad results
as this RSDL thingie, and with one important extra:
it can be switched on/off at runtime.
->forwarded message:
Subject: [patch] CFS scheduler: Completely Fair Scheduler
From: Ingo Molnar <[EMAIL PROTECTED]>
add the CONFIG_SCHED_FAIR option (default: off): this turns the Linux
scheduler into a completely fair scheduler for SCHED_OTHER tasks: with
perfect roundrobin scheduling, fair distribution of timeslices combined
with no interactivity boosting and no heuristics.
a /proc/sys/kernel/sched_fair option is also available to turn
this behavior on/off.
if this option establishes itself amongst leading distributions then we
could in the future remove the interactivity estimator altogether.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
include/linux/sched.h |1 +
kernel/Kconfig.preempt |9 +
kernel/sched.c |8
kernel/sysctl.c| 10 ++
4 files changed, 28 insertions(+)
Index: linux/include/linux/sched.h
===
--- linux.orig/include/linux/sched.h
+++ linux/include/linux/sched.h
@@ -119,6 +119,7 @@ extern unsigned long avenrun[]; /* Load
load += n*(FIXED_1-exp); \
load >>= FSHIFT;
+extern unsigned int sched_fair;
extern unsigned long total_forks;
extern int nr_threads;
DECLARE_PER_CPU(unsigned long, process_counts);
Index: linux/kernel/Kconfig.preempt
===
--- linux.orig/kernel/Kconfig.preempt
+++ linux/kernel/Kconfig.preempt
@@ -63,3 +63,12 @@ config PREEMPT_BKL
Say Y here if you are building a kernel for a desktop system.
Say N if you are unsure.
+config SCHED_FAIR
+ bool "Completely Fair Scheduler"
+ help
+ This option turns the Linux scheduler into a completely fair
+ scheduler. User-space workloads will round-robin fairly, and
+ they have to be prioritized using nice levels.
+
+ Say N if you are unsure.
+
Index: linux/kernel/sched.c
===
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -4040,6 +4040,10 @@ static inline struct task_struct *find_p
return pid ? find_task_by_pid(pid) : current;
}
+#ifdef CONFIG_SCHED_FAIR
+unsigned int sched_fair = 1;
+#endif
+
/* Actually do priority change: must hold rq lock. */
static void __setscheduler(struct task_struct *p, int policy, int prio)
{
@@ -4055,6 +4059,10 @@ static void __setscheduler(struct task_s
*/
if (policy == SCHED_BATCH)
p->sleep_avg = 0;
+#ifdef CONFIG_SCHED_FAIR
+ if (policy == SCHED_NORMAL && sched_fair)
+ p->sleep_avg = 0;
+#endif
set_load_weight(p);
}
Index: linux/kernel/sysctl.c
===
--- linux.orig/kernel/sysctl.c
+++ linux/kernel/sysctl.c
@@ -205,6 +205,16 @@ static ctl_table root_table[] = {
};
static ctl_table kern_table[] = {
+#ifdef CONFIG_SCHED_FAIR
+ {
+ .ctl_name = CTL_UNNUMBERED,
+ .procname = "sched_fair",
+ .data = &sched_fair,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec,
+ },
+#endif
{
.ctl_name = KERN_PANIC,
.procname = "panic",
-
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: BUG: soft lockup during suspend
Hi! > > I got this nastinness in my syslog... perhaps HDA intel takes too long > > to play with its hardware? Or should we just kill the softlockup > > watchdog since Linux is not realtime system, yet? > > X60/T60 is known to be often broken regarding the communication > between the controller and the codec chip. When this kind of thing > happens, the driver tries to switch to a single-shot I/O without using > ring-buffers and IRQs, and even in such a mode, the communication gets > broken. FWIW, it doesn't happen on other machines with HD-audio, so > it's fairly specific to X60/T60. No idea why. Is adding touch_softlockup_watchdog() to hd_audio right solution? Or should watchdog just disappear? Pavel > > HDA Intel :00:1b.0: freeze > > BUG: soft lockup detected on CPU#0! > > [] softlockup_tick+0xa9/0xd0 > > [] update_process_times+0x33/0x80 > > [] tick_periodic+0x22/0x70 > > [] tick_handle_periodic+0x17/0x80 > > [] tick_do_broadcast+0x6a/0x80 > > [] tick_do_periodic_broadcast+0x1c/0x30 > > [] tick_handle_periodic_broadcast+0x1b/0x60 > > [] tick_do_periodic_broadcast+0x1c/0x30 > > [] timer_interrupt+0x2c/0x40 > > [] handle_IRQ_event+0x25/0x60 > > [] handle_edge_irq+0xe7/0x130 > > [] do_IRQ+0x3b/0x80 > > [] do_IRQ+0x40/0x80 > > [] common_interrupt+0x23/0x28 > > [] ieee80211_wx_get_scan+0x2b/0x130 > > [] delay_tsc+0x14/0x20 > > [] __delay+0x6/0x10 > > [] azx_send_cmd+0xfa/0x110 > > [] snd_hda_codec_write+0x3e/0x60 > > [] hda_set_power_state+0xab/0xe0 > > [] snd_hda_suspend+0x48/0x60 > > [] azx_suspend+0x52/0xd0 > > [] pci_device_suspend+0x23/0x70 > > [] suspend_device+0x11b/0x2e0 > > [] device_suspend+0xb2/0x170 > > [] printk+0x1b/0x20 > > [] pm_suspend_disk+0x4d/0x2b0 > > [] enter_state+0x195/0x220 > > [] state_store+0xa9/0xc0 > > [] state_store+0x0/0xc0 > > [] subsys_attr_store+0x29/0x40 > > [] sysfs_write_file+0xac/0x130 > > [] vfs_write+0xa6/0x140 > > [] sysfs_write_file+0x0/0x130 > > [] syscall_call+0x7/0xb > > [] ieee80211_translate_scan+0xa00/0xa50 > > === > > ACPI: PCI interrupt for device :00:1b.0 disabled > > > > -- > > (english) http://www.livejournal.com/~pavelmachek > > (cesky, pictures) > > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > > -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
> Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex being > acquired under dqptr_sem in quota code. But looking at the path from > con_close() there's another inversion with i_mutex which is also acquired > along the path for sysfs. And we can hardly get rid of it in the quota code. > Now none of these is a real deadlock as quota should never call > print_warning() for sysfs (it doesn't use quota) but still it's nasty. I > suppose tty_mutex is above i_mutex because of those sysfs calls and it > seems sysfs must be called under tty_mutex because of races with > init_dev(). So it's not easy to get rid of that dependency either. maybe a far more serious option: Why on EARTH is the quota code going to TTY's directly? That's just WRONG. Maybe it wasn't 10 years ago, but nowadays most people use graphical user interfaces and the like... can we please just get rid of this instead? - 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: BUG: soft lockup during suspend
At Tue, 20 Mar 2007 14:22:03 +0100,
Pavel Machek wrote:
>
> Hi!
>
> > > I got this nastinness in my syslog... perhaps HDA intel takes too long
> > > to play with its hardware? Or should we just kill the softlockup
> > > watchdog since Linux is not realtime system, yet?
> >
> > X60/T60 is known to be often broken regarding the communication
> > between the controller and the codec chip. When this kind of thing
> > happens, the driver tries to switch to a single-shot I/O without using
> > ring-buffers and IRQs, and even in such a mode, the communication gets
> > broken. FWIW, it doesn't happen on other machines with HD-audio, so
> > it's fairly specific to X60/T60. No idea why.
>
> Is adding touch_softlockup_watchdog() to hd_audio right solution? Or
> should watchdog just disappear?
This should be at a loop in azx_single_send_cmd(),
int timeout = 50;
...
while (timeout--) {
/* check ICB busy bit */
if (! (azx_readw(chip, IRS) & ICH6_IRS_BUSY)) {
...
return 0;
}
udelay(1);
}
and this function is not in spinlock by itself.
Hence I feel the softlockup is too sensitive in this regard.
But calling touch_softlockup_watchdog() is surely a workaround.
Takashi
> Pavel
>
> > > HDA Intel :00:1b.0: freeze
> > > BUG: soft lockup detected on CPU#0!
> > > [] softlockup_tick+0xa9/0xd0
> > > [] update_process_times+0x33/0x80
> > > [] tick_periodic+0x22/0x70
> > > [] tick_handle_periodic+0x17/0x80
> > > [] tick_do_broadcast+0x6a/0x80
> > > [] tick_do_periodic_broadcast+0x1c/0x30
> > > [] tick_handle_periodic_broadcast+0x1b/0x60
> > > [] tick_do_periodic_broadcast+0x1c/0x30
> > > [] timer_interrupt+0x2c/0x40
> > > [] handle_IRQ_event+0x25/0x60
> > > [] handle_edge_irq+0xe7/0x130
> > > [] do_IRQ+0x3b/0x80
> > > [] do_IRQ+0x40/0x80
> > > [] common_interrupt+0x23/0x28
> > > [] ieee80211_wx_get_scan+0x2b/0x130
> > > [] delay_tsc+0x14/0x20
> > > [] __delay+0x6/0x10
> > > [] azx_send_cmd+0xfa/0x110
> > > [] snd_hda_codec_write+0x3e/0x60
> > > [] hda_set_power_state+0xab/0xe0
> > > [] snd_hda_suspend+0x48/0x60
> > > [] azx_suspend+0x52/0xd0
> > > [] pci_device_suspend+0x23/0x70
> > > [] suspend_device+0x11b/0x2e0
> > > [] device_suspend+0xb2/0x170
> > > [] printk+0x1b/0x20
> > > [] pm_suspend_disk+0x4d/0x2b0
> > > [] enter_state+0x195/0x220
> > > [] state_store+0xa9/0xc0
> > > [] state_store+0x0/0xc0
> > > [] subsys_attr_store+0x29/0x40
> > > [] sysfs_write_file+0xac/0x130
> > > [] vfs_write+0xa6/0x140
> > > [] sysfs_write_file+0x0/0x130
> > > [] syscall_call+0x7/0xb
> > > [] ieee80211_translate_scan+0xa00/0xa50
> > > ===
> > > ACPI: PCI interrupt for device :00:1b.0 disabled
> > >
> > > --
> > > (english) http://www.livejournal.com/~pavelmachek
> > > (cesky, pictures)
> > > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> > >
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
On Tue, Mar 20, 2007 at 01:19:09PM +0100, Jan Kara wrote: > On Tue 20-03-07 12:31:51, Jarek Poplawski wrote: > > On Tue, Mar 20, 2007 at 12:22:53PM +0100, Jarek Poplawski wrote: > > > On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski wrote: > > > ... > > > > IMHO lockdep found that two locks are taken in different order: > > > > > > > > -> #1: 1) tty_mutex in con_console() 2) dqptr_sem (somewhere later) > > > > -> #0: 1) dqptr_sem 2) tty_console in dquot_alloc_space() with > > > > print_warning() > > > > Once more - should be: > > -> #1: 1) tty_mutex in con_close() 2) dqptr_sem (somewhere later) > > -> #0: 1) dqptr_sem 2) tty_mutex in dquot_alloc_space() with > > print_warning() > Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex being > acquired under dqptr_sem in quota code. But looking at the path from > con_close() there's another inversion with i_mutex which is also acquired > along the path for sysfs. And we can hardly get rid of it in the quota code. > Now none of these is a real deadlock as quota should never call > print_warning() for sysfs (it doesn't use quota) but still it's nasty. I > suppose tty_mutex is above i_mutex because of those sysfs calls and it > seems sysfs must be called under tty_mutex because of races with > init_dev(). So it's not easy to get rid of that dependency either. I wonder if this cannot be done with a workqueue (message to a buffer, maybe after try_lock on tty_mutex) and BTW isn't there any "modern" way to queue console messages like these? Jarek P. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21-rc4-mm1 + 3 hot-fixes -- init/.missing_syscalls.h.cmd:2: *** missing separator. Stop.
Hello, I don't see any announcement for 2.6.21-rc4-mm1 on LKML, but I went ahead and tried it out. I hit the following, even after running mrproper. init/.missing_syscalls.h.cmd:2: *** missing separator. Stop. make: *** [.tmp_vmlinux1] Error 2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/22 take 3] UBI: Unsorted Block Images
On Tue, Mar 20, 2007 at 02:25:49PM +0200, Artem Bityutskiy wrote: > You failed to clearly define what is block until now, then you blame me > that I do not understand you. So I see block = eraseblock, lets assume > for further conversation. > > OK. Suppose we have done what you say, although I _do not_ think it is > makes a lot of sense. So, now we have a block device, with 128KiB block > size. We have LVM, dm-wl or whatever stuff. Fine. > > Do you realize that 128KiB is _huge_ block size, and performance will > suck, and suck a lot if you utilize say, ext2 or whatever block device > FS. As a suggestion, let's stop right here and see if we can get both sides talking in a more constructive fashion. Maybe it's just me, but I see both sides talking past each other in a rather dramatic fashion. Linux seems to allow multiple implementations of things at the edge (such as filesystems), but not at the core (devicemapper when in, device mapper didn't; it's unlikely that we would have two competing block device layers or two VFS layers, etc.). The question then is whether UBI and dm are close enough or not that should be one subsystem or not. There a number of red herrings that have been introduced in this discussion; of *course* the existing block device layer can handle FLASH devices; Matt is proposing that they be extended. And of *course* you woulnd't propose to use ext2 on top of an 128k blocksize, anymore than you would force a flash filesystem to use a 4k or 512 byte blocksize; there are plenty of configurations that won't make sense, and by itself this isn't an indictment of the core idea that the block device layer and dm should be augmented to encompass flash functionality. As far as who gets to do the work, unfortunately sometimes the people submitting the new code have to make the changes suggested by the reviewer. That's one of the prices that gets paid for mainline inclusion. It's different when someone asks for a completely new feature, especially for code that is already in mainline; then, "feel free to send a patch" is perfectly accepted. But if it's a matter of refactoring the code to fit in some other framework, that's often up to the submitter to do, not the reviewer. Of course, it remains to be seen whether or not this is a good idea to do in the first place; but some of the arguments being used to shoot down Matt's suggestion aren't really good ones to begin with. > To make it faster I have to have a way to do finer grained I/O: > read/write to different positions of 128KiB block. Do you realize how > much you will abuse all the generic block device infrastructure if you > try to add this? Note, all levels up to LVM will need to have this. A > believe it is braindead ((c) tglx) to add this feature. OK, and this could be it. But I suspect one of the things which may be missing that make it easier for you to explain why what UBI is doing is so different from the dm and block device stack is to include the contents of: http://www.linux-mtd.infradead.org/faq/ubi.html http://www.linux-mtd.infradead.org/doc/ubi.html and some system level documentation in a Documentation/ubi.txt file as part of the patch set. I don't think people completely understand the high-level architecture of what UBI is trying to achieve. What are the interfaces at the top and the bottom of the stack? For example, the fact that UBI exports Logical Erase blocks that are not a power-of-two (possibly 128k minus 128 bytes) means that it certainly might not be a good match for the dm stack. But why is that the case? I can imagine good reasons for it, but a high-level description of the design decisions would be very useful. It would also help people understand why there are so many "units" in UBI, since hopefully the high-level documentation would explain why they fit together, and perhaps why some of the units weren't folded together. What value do they add as separate components? There are hints of the overall system architecture in some of the indivdual comments for data structures, but even reading all of those, there isn't quite enough for people to figure out what it is; and that may be causing some of these comments of people saying there's too much code to evaluate, or why didn't you do it *this* way? Regards, - Ted - 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: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
On Tue 20-03-07 14:44:46, Jarek Poplawski wrote: > On Tue, Mar 20, 2007 at 01:19:09PM +0100, Jan Kara wrote: > > On Tue 20-03-07 12:31:51, Jarek Poplawski wrote: > > > On Tue, Mar 20, 2007 at 12:22:53PM +0100, Jarek Poplawski wrote: > > > > On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski wrote: > > > > ... > > > > > IMHO lockdep found that two locks are taken in different order: > > > > > > > > > > -> #1: 1) tty_mutex in con_console() 2) dqptr_sem (somewhere later) > > > > > -> #0: 1) dqptr_sem 2) tty_console in dquot_alloc_space() with > > > > > print_warning() > > > > > > Once more - should be: > > > -> #1: 1) tty_mutex in con_close() 2) dqptr_sem (somewhere later) > > > -> #0: 1) dqptr_sem 2) tty_mutex in dquot_alloc_space() with > > > print_warning() > > Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex being > > acquired under dqptr_sem in quota code. But looking at the path from > > con_close() there's another inversion with i_mutex which is also acquired > > along the path for sysfs. And we can hardly get rid of it in the quota code. > > Now none of these is a real deadlock as quota should never call > > print_warning() for sysfs (it doesn't use quota) but still it's nasty. I > > suppose tty_mutex is above i_mutex because of those sysfs calls and it > > seems sysfs must be called under tty_mutex because of races with > > init_dev(). So it's not easy to get rid of that dependency either. > > I wonder if this cannot be done with a workqueue (message to a buffer, > maybe after try_lock on tty_mutex) and BTW isn't there any "modern" > way to queue console messages like these? I don't know about any such way... Honza -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - 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] add Fujitsu Siemens Tablet PC devices to 8250_pnp.c
adds device ids of two Fujitsu Siemens Tablet PCs to pnp_dev_table
Signed-off-by: Danny Kukawka <[EMAIL PROTECTED]>
--- linux-2.6.21-rc4/drivers/serial/8250_pnp.c 2007-03-19 21:42:43.0
+0100
+++ linux-2.6.21-rc5/drivers/serial/8250_pnp.c 2007-03-19 21:55:53.0
+0100
@@ -340,6 +340,9 @@ static const struct pnp_device_id pnp_de
{ "FUJ02B8", 0 },
{ "FUJ02B9", 0 },
{ "FUJ02BC", 0 },
+ /* Fujitsu Wacom Tablet PC devices */
+ { "FUJ02E5", 0 },
+ { "FUJ02E6", 0 },
/* Rockwell's (PORALiNK) 33600 INT PNP */
{ "WCI0003", 0 },
/* Unkown PnP modems */
-
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: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
On Tue 20-03-07 14:35:10, Arjan van de Ven wrote: > > > > Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex being > > acquired under dqptr_sem in quota code. But looking at the path from > > con_close() there's another inversion with i_mutex which is also acquired > > along the path for sysfs. And we can hardly get rid of it in the quota code. > > Now none of these is a real deadlock as quota should never call > > print_warning() for sysfs (it doesn't use quota) but still it's nasty. I > > suppose tty_mutex is above i_mutex because of those sysfs calls and it > > seems sysfs must be called under tty_mutex because of races with > > init_dev(). So it's not easy to get rid of that dependency either. > > maybe a far more serious option: Why on EARTH is the quota code going to > TTY's directly? That's just WRONG. Maybe it wasn't 10 years ago, but > nowadays most people use graphical user interfaces and the like... We've been discussing this sometimes back in August ;) (http://lkml.org/lkml/2006/8/8/237) and we've decided to leave the code in. The only reason why I think it should stay in is the existence of quota softlimits. There it's nice to warn the user and there's no other way to propagate this information into userspace (as the write succeeds). One solution would be to leave the warning to some userspace process (like warnquota) run from cron but still I'm not sure we should change the behavior. Honza -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - 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 2.6.20 does not work anymore with SCSI or SATA on old Opteron / Xeon servers
On Tuesday 20 March 2007 11:33, Stefan Priebe wrote: > 1.) I've bootet these systems through NFS and would like to access > /dev/sda or /dev/sdb then. For example via fdisk and this does not work. What do you mean by "booted through NFS"? Do you mean the machine runs with the root file system mounted via NFS? Or does it mean you booted, and started the NFS server? Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax - 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 2.6.20 does not work anymore with SCSI or SATA on old Opteron / Xeon servers
Hello! It runs with nfsroot # mount 192.168.0.100:/PXE/debian on / type nfs (rw) Kernel command line: nfs root=/dev/nfs nfsroot=192.168.0.100:/PXE/debian ip=dhcp Stefan Olaf Kirch schrieb: On Tuesday 20 March 2007 11:33, Stefan Priebe wrote: 1.) I've bootet these systems through NFS and would like to access /dev/sda or /dev/sdb then. For example via fdisk and this does not work. What do you mean by "booted through NFS"? Do you mean the machine runs with the root file system mounted via NFS? Or does it mean you booted, and started the NFS server? Olaf - 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: [Alsa-devel] 2.6.21-rc4: known regressions with patches available
At Mon, 19 Mar 2007 21:39:43 +0100, Adrian Bunk wrote: > > Subject: snd-intel8x0: no 3d surround sound > References : http://lkml.org/lkml/2007/3/5/164 > Submitter : Michal Piotrowski <[EMAIL PROTECTED]> > Caused-By : Randy Cushman <[EMAIL PROTECTED]> > commit 831466f4ad2b5fe23dff77edbe6a7c244435e973 > Handled-By : Takashi Iwai <[EMAIL PROTECTED]> > Status : patch available The patch was already merged after rc4. thanks, Takashi - 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 2.6.20 does not work anymore with SCSI or SATA on old Opteron / Xeon servers
Hello! Here a some more information: - sometimes the whole systems crash - sometimes they are still alive - if they are alive fdisk consumes 99% CPU - fdisk cannot be killed also not with kill -9 - the same happens with a cat on /dev/sdX - no problem when trying to access /dev/hdX Stefan Olaf Kirch schrieb: On Tuesday 20 March 2007 11:33, Stefan Priebe wrote: 1.) I've bootet these systems through NFS and would like to access /dev/sda or /dev/sdb then. For example via fdisk and this does not work. What do you mean by "booted through NFS"? Do you mean the machine runs with the root file system mounted via NFS? Or does it mean you booted, and started the NFS server? Olaf - 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 2.6.20 does not work anymore with SCSI or SATA on old Opteron / Xeon servers
> - on a 2.6.20 system, try "dd if=/dev/sdb of=/dev/null bs=4k count=1" or
>something like this (with NFS root) - does this crash, too?
no it does not crash it is also no problem to set the count= to 1 or
so or change the bs to 16k ...
> - do you have ACLs on files in /dev?
no
> - enable the sysrq key, make sure kernel messages go to the console
>by using "dmesg -n7", and when the kernel hangs, try sysrq-p, and
>sysrq-t
>(sysrq is documented in Documation/sysrq.txt in the kernel source)
> - try to capture the oops message - there must be one.
OK i've done the following:
1.) I've set up netconsole
2.) dmesg -n7
3.) fdisk /dev/sda
4.) sysrq-t / sysrq-p
So here is the output of -p and -t it hangs at nfs_sync_mapping_wait:
SysRq : Show Regs
Pid: 1598, comm:fdisk
EIP: 0060:[] CPU: 0
EIP is at _spin_lock+0x7/0xf
EFLAGS: 0286Not tainted (2.6.20.3 #6)
EAX: c3117afc EBX: c3117a2c ECX: 0020 EDX:
ESI: f7b63ed4 EDI: f7b63f04 EBP: f7b63edc DS: 007b ES: 007b GS: 00d8
CR0: 8005003b CR2: b7f00f90 CR3: 033ea000 CR4: 06d0
[] nfs_sync_mapping_wait+0x83/0x1aa
[] cache_alloc_refill+0xc8/0x196
[] nfs_sync_mapping_range+0x97/0xb6
[] nfs_getattr+0x3a/0x96
[] nfs_getattr+0x0/0x96
[] vfs_getattr+0x21/0x30
[] vfs_fstat+0x22/0x31
[] sys_fstat64+0xf/0x23
[] sys_ioctl+0x33/0x4b
[] do_page_fault+0x0/0x549
[] syscall_call+0x7/0xb
[] call_verify+0x182/0x36f
===
SysRq : Show State
freesibling
task PCstack pid father child younger older
init S C0117721 0 1 0 2 (NOTLB)
c313fc48 0082 c312fa90 c0117721 00100100 00200200 f7da9600
f7941e40
0010 c313fc04 0008 0002 c3022700 c312fa90 c312fb9c
08dd
64bf803e 0029 c312f030 c313fc90 c30013c0 c03b3515
c03b352f
Call Trace:
[] default_wake_function+0x0/0xc
[] rpc_wait_bit_interruptible+0x0/0x1f
[] rpc_wait_bit_interruptible+0x1a/0x1f
[] __wait_on_bit+0x2c/0x51
[] rpc_wait_bit_interruptible+0x0/0x1f
[] out_of_line_wait_on_bit+0x73/0x7b
[] wake_bit_function+0x0/0x3c
[] wake_bit_function+0x0/0x3c
[] __rpc_execute+0xdb/0x18b
[] rpc_set_active+0x19/0x57
[] rpc_call_sync+0x71/0x98
[] nfs_proc_getattr+0x5b/0x7f
[] __nfs_revalidate_inode+0xe7/0x21a
[] nfs_permission+0x0/0x133
[] nfs_permission+0x0/0x133
[] nfs_permission+0x112/0x133
[] nfs_permission+0x0/0x133
[] permission+0x94/0xa2
[] __link_path_walk+0x6c/0xa59
[] __alloc_pages+0x4a/0x2a3
[] link_path_walk+0x3f/0xa4
[] do_path_lookup+0x170/0x18b
[] __user_walk_fd+0x2d/0x43
[] vfs_stat_fd+0x19/0x40
[] sys_stat64+0xf/0x23
[] copy_to_user+0x2f/0x37
[] do_gettimeofday+0x35/0x119
[] sys_time+0x1e/0x2e
[] syscall_call+0x7/0xb
===
ksoftirqd/0 S C33442C0 0 3 1 4 2 (L-TLB)
c3149fb8 0046 c013cd73 c33442c0 c30131e0 0003
f7931900
c301321c c33f5030 c3012700 c3136030 c313613c
01d9
a733fbbd 0004 c04a8cc0 c0539380 c0539380 c0120494 fffc
c01204d6
Call Trace:
[] mempool_free+0x65/0x6a
[] ksoftirqd+0x0/0xa7
[] ksoftirqd+0x42/0xa7
[] kthread+0x72/0x96
[] kthread+0x0/0x96
[] kernel_thread_helper+0x7/0x10
===
migration/1 S F745BF24 0 4 1 5 3 (L-TLB)
c314bfb0 0046 0092 f745bf24 0001 f745bf70 c314bf94
f7ab03c0
0001 f745bf74 0001 c301a700 c3139a90 c3139b9c
23c5
b7d09ccb 0004 c312f560 c301b054 c301a700 0001 c314bfc4
c0118643
Call Trace:
[] migration_thread+0x7a/0xd2
[] migration_thread+0x0/0xd2
[] kthread+0x72/0x96
[] kthread+0x0/0x96
[] kernel_thread_helper+0x7/0x10
===
ksoftirqd/1 S C301B1A0 0 5 1 6 4 (L-TLB)
c316ffb8 0046 c301b1a0 0008 c012a884 c301b1e0
f7f39040
c012aa25 c301b21c 0001 c301a700 c3139560 c313966c
0c4f
48c808e9 0004 c312f560 c0539380 c0539380 c0120494 fffc
c01204d6
Call Trace:
[] rcu_do_batch+0x1a/0x7f
[] __rcu_process_callbacks+0x8f/0xa1
[] ksoftirqd+0x0/0xa7
[] ksoftirqd+0x42/0xa7
[] kthread+0x72/0x96
[] kthread+0x0/0x96
[] kernel_thread_helper+0x7/0x10
===
migration/2 S F7B63F24 0 6 1 7 5 (L-TLB)
c3171fb0 0046 0092 f7b63f24 0001 f7b63f70 c3171f94
f79703c0
0001 f7b63f74 0002 c3022700 c3139030 c313913c
11f0
482d3411 0022 c312f030 c3023054 c3022700 0002 c3171fc4
c0118643
Call Trace:
[] migration_thread+0x7a/0xd2
[] migration_thread+0x0/0xd2
[] kthread+0x72/0x96
[] kthread+0x0/0x96
[] kernel_thread_helper+0x7/0x10
===
ksoftirqd/2 S C324D780 0 7 1 8 6 (L-TLB)
c3175fb8 0046 c013cd73 c324d780 c30231e0 0
[PATCH 2.6.22 RESEND] Optional LED trigger for libata
This adds an optional wrapper around ata_ac_issue_prot that triggers the LED
layer.
This is used for the PMU LED on G5 towers (IDE trigger). My test platform is a
PowerMac 7,3 (Dual G5 2.0GHz, June 2004) with a K2 (sata_svw) controller.
Now respun as a single patch, and the function name shortened as requested.
Signed-off-by: Tony Vroon <[EMAIL PROTECTED]>
diff -uNr linux-2.6.ORIG/drivers/ata/libata-core.c
linux-2.6/drivers/ata/libata-core.c
--- linux-2.6.ORIG/drivers/ata/libata-core.c2007-03-20 09:10:44.0
+
+++ linux-2.6/drivers/ata/libata-core.c 2007-03-20 09:17:53.0 +
@@ -49,6 +49,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -5050,6 +5051,25 @@
}
/**
+ * ata_qc_issue_prot_ledtrigger - trigger LED core
+ * @qc: command to issue to device
+ *
+ * This triggers the LED core and then calls the
+ * regular ata_qc_issue_prot function.
+ *
+ * LOCKING:
+ * spin_lock_irqsave(host lock)
+ *
+ * RETURNS:
+ * Zero on success, AC_ERR_* mask on failure
+ */
+unsigned int ata_qc_issue_prot_ledtrigger(struct ata_queued_cmd *qc)
+{
+ ledtrig_ide_activity();
+ return ata_qc_issue_prot(qc);
+}
+
+/**
* ata_host_intr - Handle host interrupt for given (port, task)
* @ap: Port on which interrupt arrived (possibly...)
* @qc: Taskfile currently active in engine
@@ -6316,6 +6336,7 @@
EXPORT_SYMBOL_GPL(ata_qc_complete);
EXPORT_SYMBOL_GPL(ata_qc_complete_multiple);
EXPORT_SYMBOL_GPL(ata_qc_issue_prot);
+EXPORT_SYMBOL_GPL(ata_qc_issue_prot_ledtrigger);
EXPORT_SYMBOL_GPL(ata_tf_load);
EXPORT_SYMBOL_GPL(ata_tf_read);
EXPORT_SYMBOL_GPL(ata_noop_dev_select);
diff -uNr linux-2.6.ORIG/drivers/ata/sata_svw.c linux-2.6/drivers/ata/sata_svw.c
--- linux-2.6.ORIG/drivers/ata/sata_svw.c 2007-03-20 09:10:44.0
+
+++ linux-2.6/drivers/ata/sata_svw.c2007-03-20 09:17:17.0 +
@@ -348,7 +348,7 @@
.bmdma_stop = ata_bmdma_stop,
.bmdma_status = ata_bmdma_status,
.qc_prep= ata_qc_prep,
- .qc_issue = ata_qc_issue_prot,
+ .qc_issue = ata_qc_issue_prot_ledtrigger,
.data_xfer = ata_data_xfer,
.freeze = ata_bmdma_freeze,
.thaw = ata_bmdma_thaw,
diff -uNr linux-2.6.ORIG/include/linux/libata.h linux-2.6/include/linux/libata.h
--- linux-2.6.ORIG/include/linux/libata.h 2007-03-20 09:11:46.0
+
+++ linux-2.6/include/linux/libata.h2007-03-20 09:17:32.0 +
@@ -786,6 +786,7 @@
extern void ata_qc_prep(struct ata_queued_cmd *qc);
extern void ata_noop_qc_prep(struct ata_queued_cmd *qc);
extern unsigned int ata_qc_issue_prot(struct ata_queued_cmd *qc);
+extern unsigned int ata_qc_issue_prot_ledtrigger(struct ata_queued_cmd *qc);
extern void ata_sg_init_one(struct ata_queued_cmd *qc, void *buf,
unsigned int buflen);
extern void ata_sg_init(struct ata_queued_cmd *qc, struct scatterlist *sg,
-
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.22 RESEND] Optional LED trigger for libata
Tony Vroon wrote: > This adds an optional wrapper around ata_ac_issue_prot that triggers the LED > layer. > This is used for the PMU LED on G5 towers (IDE trigger). My test platform is > a > PowerMac 7,3 (Dual G5 2.0GHz, June 2004) with a K2 (sata_svw) controller. > Now respun as a single patch, and the function name shortened as requested. > > Signed-off-by: Tony Vroon <[EMAIL PROTECTED]> Acked-by: Tejun Heo <[EMAIL PROTECTED]> -- tejun - 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 2.6.20 does not work anymore with SCSI or SATA on old Opteron / Xeon servers
Hello! With the sysrq i've found the function with is the problem: inode.c => nfs_getattr => nfs_sync_mapping_range I've also found the attached patch - which is not included in any stable release nor in 2.6.21.X but is public since 20.02.07 I think this is very important. Stefan Priebe commit 090ad38f8ceea3cc048981e9fe9cc62ed43fee58 Author: Trond Myklebust <[EMAIL PROTECTED]> Date: Tue Feb 20 19:28:07 2007 -0500 NFS: nfs_getattr() can't call nfs_sync_mapping_range() for non-regular files Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]> diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c index af53c02..93d046c 100644 --- a/fs/nfs/inode.c +++ b/fs/nfs/inode.c @@ -429,7 +429,8 @@ int nfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) int err; /* Flush out writes to the server in order to update c/mtime */ - nfs_sync_mapping_range(inode->i_mapping, 0, 0, FLUSH_NOCOMMIT); + if (S_ISREG(inode->i_mode)) + nfs_sync_mapping_range(inode->i_mapping, 0, 0, FLUSH_NOCOMMIT); /* * We may force a getattr if the user cares about atime.
Re: 2.6.21-rc4-mm1 + 3 hot-fixes -- init/.missing_syscalls.h.cmd:2: *** missing separator. Stop.
Miles Lane a écrit : > Hello, > > I don't see any announcement for 2.6.21-rc4-mm1 on LKML, but I went > ahead and tried it out. I hit the following, even after running > mrproper. > > init/.missing_syscalls.h.cmd:2: *** missing separator. Stop. > make: *** [.tmp_vmlinux1] Error 2 Would you please try the following patch ? http://lkml.org/lkml/2007/3/20/79 Thanks. - Stéphane. -- /// Stephane Jourdois /"\ ASCII RIBBON CAMPAIGN \\\ (((Consultant securite \ /AGAINST HTML MAIL))) \\\ 24 rue Cauchy X /// \\\ 75015 Paris / \+33 6 8643 3085/// -- /// Stephane Jourdois /"\ ASCII RIBBON CAMPAIGN \\\ (((Consultant securite \ /AGAINST HTML MAIL))) \\\ 24 rue Cauchy X /// \\\ 75015 Paris / \+33 6 8643 3085/// - 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: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
On Tue, 2007-03-20 at 15:21 +0100, Jan Kara wrote: > On Tue 20-03-07 14:35:10, Arjan van de Ven wrote: > > > > > > > Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex > > > being > > > acquired under dqptr_sem in quota code. But looking at the path from > > > con_close() there's another inversion with i_mutex which is also acquired > > > along the path for sysfs. And we can hardly get rid of it in the quota > > > code. > > > Now none of these is a real deadlock as quota should never call > > > print_warning() for sysfs (it doesn't use quota) but still it's nasty. I > > > suppose tty_mutex is above i_mutex because of those sysfs calls and it > > > seems sysfs must be called under tty_mutex because of races with > > > init_dev(). So it's not easy to get rid of that dependency either. > > > > maybe a far more serious option: Why on EARTH is the quota code going to > > TTY's directly? That's just WRONG. Maybe it wasn't 10 years ago, but > > nowadays most people use graphical user interfaces and the like... > We've been discussing this sometimes back in August ;) > (http://lkml.org/lkml/2006/8/8/237) and we've decided to leave the code in. > The only reason why I think it should stay in is the existence of quota > softlimits. There it's nice to warn the user and there's no other way to > propagate this information into userspace (as the write succeeds). > One solution would be to leave the warning to some userspace process > (like warnquota) run from cron but still I'm not sure we should change the > behavior. or send a uevent or something -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.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/
[PATCH] fbdev sysfs imrovements
This patch does several things to allow the underlying hardware to be
shared amount many devices. The most important thing is the use of
the created device via device_create instead of the hardware device. No
longer should fbdev drivers use the xxx_set_drvdata with the parent
bus device. The second change is having a bus independent power management
for the framebuffer driver. The final change is using the release method
to cleanup the device. The reason again is to make the fbdev driver
independent of the bus parent device. Feedback is welcomed.
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 2822526..2cff39c 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1268,8 +1268,6 @@ static const struct file_operations fb_fops = {
#endif
};
-struct class *fb_class;
-EXPORT_SYMBOL(fb_class);
/**
* register_framebuffer - registers a frame buffer device
* @fb_info: frame buffer info structure
@@ -1295,14 +1293,9 @@ register_framebuffer(struct fb_info *fb_info)
break;
fb_info->node = i;
- fb_info->dev = device_create(fb_class, fb_info->device,
-MKDEV(FB_MAJOR, i), "fb%d", i);
- if (IS_ERR(fb_info->dev)) {
- /* Not fatal */
+ /* Not fatal */
+ if (fb_init_device(fb_info))
printk(KERN_WARNING "Unable to create device for framebuffer
%d; errno = %ld\n", i, PTR_ERR(fb_info->dev));
- fb_info->dev = NULL;
- } else
- fb_init_device(fb_info);
if (fb_info->pixmap.addr == NULL) {
fb_info->pixmap.addr = kmalloc(FBPIXMAPSIZE, GFP_KERNEL);
@@ -1356,7 +1349,6 @@ unregister_framebuffer(struct fb_info *fb_info)
registered_fb[i]=NULL;
num_registered_fb--;
fb_cleanup_device(fb_info);
- device_destroy(fb_class, MKDEV(FB_MAJOR, i));
event.info = fb_info;
fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED, &event);
return 0;
@@ -1402,11 +1394,7 @@ fbmem_init(void)
if (register_chrdev(FB_MAJOR,"fb",&fb_fops))
printk("unable to get major %d for fb devs\n", FB_MAJOR);
- fb_class = class_create(THIS_MODULE, "graphics");
- if (IS_ERR(fb_class)) {
- printk(KERN_WARNING "Unable to create fb class; errno = %ld\n",
PTR_ERR(fb_class));
- fb_class = NULL;
- }
+ fb_create_class();
return 0;
}
@@ -1415,8 +1403,8 @@ module_init(fbmem_init);
static void __exit
fbmem_exit(void)
{
- class_destroy(fb_class);
unregister_chrdev(FB_MAJOR, "fb");
+ fb_destroy_class();
}
module_exit(fbmem_exit);
diff --git a/drivers/video/fbsysfs.c b/drivers/video/fbsysfs.c
index 40c80c8..d3caba6 100644
--- a/drivers/video/fbsysfs.c
+++ b/drivers/video/fbsysfs.c
@@ -505,42 +505,99 @@ static struct device_attribute device_attrs[] = {
#endif
};
-int fb_init_device(struct fb_info *fb_info)
+struct class *fb_class;
+EXPORT_SYMBOL(fb_class);
+
+static void fb_device_release(struct device *dev)
{
- int i, error = 0;
+ struct fb_info *fb_info = dev_get_drvdata(dev);
- dev_set_drvdata(fb_info->dev, fb_info);
+ if (fb_info) {
+ acquire_console_sem();
- fb_info->class_flag |= FB_SYSFS_FLAG_ATTR;
+ // shutdown the hardware.
+ if (fb_info->fbops->fb_release)
+ fb_info->fbops->fb_release(fb_info, 0);
- for (i = 0; i < ARRAY_SIZE(device_attrs); i++) {
- error = device_create_file(fb_info->dev, &device_attrs[i]);
+ fb_dealloc_cmap(&fb_info->cmap);
+ unregister_framebuffer(fb_info);
- if (error)
- break;
+ //framebuffer_release(info); Not every driver does this yet
+ release_console_sem();
}
+}
- if (error) {
- while (--i >= 0)
- device_remove_file(fb_info->dev, &device_attrs[i]);
+int fb_init_device(struct fb_info *fb_info)
+{
+ int error = 0;
+
+ fb_info->dev = device_create(fb_class, fb_info->device,
+ MKDEV(FB_MAJOR, fb_info->node),
+ "fb%d", fb_info->node);
+ if (IS_ERR(fb_info->dev)) {
fb_info->class_flag &= ~FB_SYSFS_FLAG_ATTR;
+ fb_info->dev = NULL;
+ error = -EINVAL;
+ } else {
+ dev_set_drvdata(fb_info->dev, fb_info);
+ fb_info->dev->release = fb_device_release;
+ fb_info->class_flag |= FB_SYSFS_FLAG_ATTR;
}
-
- return 0;
+ return error;
}
void fb_cleanup_device(struct fb_info *fb_info)
{
- unsigned int i;
+ fb_info->class_flag &= ~FB_SYSFS_FLAG_ATTR;
+ dev_set_drvdata(fb_info->dev, NULL);
+ device_destroy(fb_class, MKDEV(FB_MAJOR, fb_info->node));
+}
- if (fb_info->class_flag
Re: 2.6.21-rc4-mm1 + 3 hot-fixes -- init/.missing_syscalls.h.cmd:2: *** missing separator. Stop.
On 3/20/07, Stéphane Jourdois <[EMAIL PROTECTED]> wrote: Miles Lane a écrit : > Hello, > > I don't see any announcement for 2.6.21-rc4-mm1 on LKML, but I went > ahead and tried it out. I hit the following, even after running > mrproper. > > init/.missing_syscalls.h.cmd:2: *** missing separator. Stop. > make: *** [.tmp_vmlinux1] Error 2 Would you please try the following patch ? http://lkml.org/lkml/2007/3/20/79 I tried your patch. After applying it, the error still occurred, so then I performed the other stepa you mentioned: rm init/missing_syscalls.h make init I was then able to continue the build successfully. Hopefully, I'd not need to run the additional steps again. Otherwise, the patch needs a little more work. Thanks, Miles - 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: user defined hotplug events?
> Or new, user defined, ones? there's always the "CHANGED" event.. it's very very generic and just means "check my state for new stuff" - 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.21-rc4-mm1
Andrew Morton napsal(a): > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ I'm getting this while trying to swsusp: Stopping tasks ... Stopping kernel threads timed out after 20 seconds (1 tasks refusing to freeze): swapper Restarting tasks ... done. What to test? Enable PM_DEBUG? regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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: PNPACPI probes serial twice, messes up serial console
On Tuesday 20 March 2007 00:46, Keith Owens wrote:
> Booting with 'console=tty console=ttyS0,9600'. The serial console on
> ttyS0 (0x3f8, irq 4) is probed twice, once from serial8250_init() and
> again from serial_pnp_probe().
I played with this last summer, but was too timid to finish it
and post it. My plan was to remove the legacy SERIAL_PORT_DFNS,
make platform devices for them, and only register the platform
devices in the absence of PNP.
My motivation at the time was to prevent 8250 from claiming IRDA
devices that happened to live at legacy UART addresses. I also
wanted to make IRDA (smsc-ircc2 in my case) smart enough to use
PNP to locate its devices, since 8250 would no longer claim them.
Here's the dusty patch (against 2.6.18-rc1-mm2). If it seems
like a reasonable thing to do, I can update it, polish it up,
add a changelog, and post it.
Index: work-mm2/drivers/serial/8250_x86.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ work-mm2/drivers/serial/8250_x86.c 2006-08-22 16:47:02.0 -0600
@@ -0,0 +1,67 @@
+/*
+ * Legacy COM port devices for x86 platforms without PNPBIOS or ACPI.
+ * Data taken from include/asm-i386/serial.h.
+ *
+ * (c) Copyright 2006 Hewlett-Packard Development Company, L.P.
+ * Bjorn Helgaas <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+
+/* Standard COM flags (except for COM4, because of the 8514 problem) */
+#ifdef CONFIG_SERIAL_DETECT_IRQ
+#define COM_FLAGS (UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_AUTO_IRQ)
+#define COM4_FLAGS (UPF_BOOT_AUTOCONF | UPF_AUTO_IRQ)
+#else
+#define COM_FLAGS (UPF_BOOT_AUTOCONF | UPF_SKIP_TEST)
+#define COM4_FLAGS UPF_BOOT_AUTOCONF
+#endif
+
+#define PORT(_base,_irq,_flags)\
+ { \
+ .iobase = _base,\
+ .irq= _irq, \
+ .uartclk= 1843200, \
+ .iotype = UPIO_PORT,\
+ .flags = _flags, \
+ }
+
+static struct plat_serial8250_port x86_com_data[] = {
+ PORT(0x3F8, 4, COM_FLAGS),
+ PORT(0x2F8, 3, COM_FLAGS),
+ PORT(0x3E8, 4, COM_FLAGS),
+ PORT(0x2E8, 3, COM4_FLAGS),
+ { },
+};
+
+static struct platform_device x86_com_device = {
+ .name = "serial8250",
+ .id = PLAT8250_DEV_X86,
+ .dev= {
+ .platform_data = x86_com_data,
+ },
+};
+
+static int __init serial8250_x86_com_init(void)
+{
+#ifdef CONFIG_SERIAL_8250_PNP
+ extern int serial8250_nopnp;
+
+ if (pnp_platform_devices && !serial8250_nopnp)
+ return 0;
+#endif
+
+ return platform_device_register(&x86_com_device);
+}
+
+module_init(serial8250_x86_com_init);
+
+MODULE_AUTHOR("Bjorn Helgaas");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Generic 8250/16x50 legacy probe module");
Index: work-mm2/drivers/serial/Makefile
===
--- work-mm2.orig/drivers/serial/Makefile 2006-08-22 12:26:25.0
-0600
+++ work-mm2/drivers/serial/Makefile2006-08-22 16:37:36.0 -0600
@@ -7,6 +7,7 @@
obj-$(CONFIG_SERIAL_CORE) += serial_core.o
obj-$(CONFIG_SERIAL_21285) += 21285.o
obj-$(CONFIG_SERIAL_8250) += 8250.o
+obj-$(CONFIG_SERIAL_8250_X86) += 8250_x86.o
obj-$(CONFIG_SERIAL_8250_PNP) += 8250_pnp.o
obj-$(CONFIG_SERIAL_8250_GSC) += 8250_gsc.o
obj-$(CONFIG_SERIAL_8250_PCI) += 8250_pci.o
Index: work-mm2/include/linux/serial_8250.h
===
--- work-mm2.orig/include/linux/serial_8250.h 2006-08-22 12:26:25.0
-0600
+++ work-mm2/include/linux/serial_8250.h2006-08-22 16:37:36.0
-0600
@@ -44,6 +44,7 @@
PLAT8250_DEV_HUB6,
PLAT8250_DEV_MCA,
PLAT8250_DEV_AU1X00,
+ PLAT8250_DEV_X86,
};
/*
Index: work-mm2/include/asm-i386/serial.h
===
--- work-mm2.orig/include/asm-i386/serial.h 2006-08-22 12:26:25.0
-0600
+++ work-mm2/include/asm-i386/serial.h 2006-08-22 16:37:36.0 -0600
@@ -11,19 +11,3 @@
* megabits/second; but this requires the faster clock.
*/
#define BASE_BAUD ( 1843200 / 16 )
-
-/* Standard COM flags (except for COM4, because of the 8514 problem) */
-#ifdef CONFIG_SERIAL_DETECT_IRQ
-#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ)
-#define STD_COM4_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_AUTO_IRQ)
-#else
-#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST)
-#define STD_COM4
2.6.21-rc4-mm1 + 3 hot-fixes -- WARNING: could not find versions for .tmp_versions/built-in.mod
It looks like the number of section mismatches is much reduced, which is great. But, I don't remember seeing "WARNING: could not find versions for ..." warnings before. Is this an artifact of the init/.missing_syscalls.h problem I encountered earlier? MODPOST vmlinux WARNING: could not find versions for .tmp_versions/head.mod WARNING: could not find versions for .tmp_versions/init_task.mod WARNING: init/built-in.o - Section mismatch: reference to .init.text: from .text between 'rest_init' (at offset 0x101) and 'try_name' WARNING: could not find versions for .tmp_versions/built-in.mod WARNING: could not find versions for .tmp_versions/built-in.mod WARNING: could not find versions for .tmp_versions/built-in.mod WARNING: could not find versions for .tmp_versions/built-in.mod WARNING: could not find versions for .tmp_versions/built-in.mod WARNING: could not find versions for .tmp_versions/built-in.mod WARNING: mm/built-in.o - Section mismatch: reference to .init.text:__alloc_bootmem_node from .text between 'sparse_init' (at offset 0x15c8f) and '__section_nr' WARNING: mm/built-in.o - Section mismatch: reference to .init.text:__alloc_bootmem_node from .text between 'sparse_init' (at offset 0x15d02) and '__section_nr' WARNING: mm/built-in.o - Section mismatch: reference to .init.data:initkmem_list3 from .text between 'set_up_list3s' (at offset 0x18c32) and 's_start' WARNING: could not find versions for .tmp_versions/built-in.mod WARNING: could not find versions for .tmp_versions/built-in.mod WARNING: could not find versions for .tmp_versions/built-in.mod WARNING: could not find versions for .tmp_versions/built-in.mod WARNING: could not find versions for .tmp_versions/built-in.mod WARNING: could not find versions for .tmp_versions/built-in.mod WARNING: could not find versions for .tmp_versions/built-in.mod WARNING: could not find versions for .tmp_versions/built-in.mod WARNING: could not find versions for .tmp_versions/built-in.mod WARNING: could not find versions for .tmp_versions/built-in.mod WARNING: could not find versions for .tmp_versions/built-in.mod - 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.21-rc4-mm1 + 3 hot-fixes -- init/.missing_syscalls.h.cmd:2: *** missing separator. Stop.
Miles Lane a écrit : > On 3/20/07, Stéphane Jourdois <[EMAIL PROTECTED]> wrote: >> Miles Lane a écrit : >> > Hello, >> > >> > I don't see any announcement for 2.6.21-rc4-mm1 on LKML, but I went >> > ahead and tried it out. I hit the following, even after running >> > mrproper. >> > >> > init/.missing_syscalls.h.cmd:2: *** missing separator. Stop. >> > make: *** [.tmp_vmlinux1] Error 2 >> >> Would you please try the following patch ? >> >> http://lkml.org/lkml/2007/3/20/79 > > I tried your patch. After applying it, the error still occurred, so > then I performed the other stepa you mentioned: > rm init/missing_syscalls.h Of course, you have to first delete the corrupted file with this command: rm init/.missing_syscalls.h.cmd The command : rm init/missing_syscalls.h works only once, and you have to redo it at each compile. > make init This one is not necessary. > I was then able to continue the build successfully. > > Hopefully, I'd not need to run the additional steps again. Otherwise, > the patch needs a little more work. unlink the good file (init/.missing_syscalls.h.cmd), not the .h file, and you won't need to redo it again :-) I admit I should have said that earlier ;-) The fact that whole init/ is not compiled again when init/Makefile is perhaps a bug, but it is unrelated to this bug/patch. Thanks. -- /// Stephane Jourdois /"\ ASCII RIBBON CAMPAIGN \\\ (((Consultant securite \ /AGAINST HTML MAIL))) \\\ 24 rue Cauchy X /// \\\ 75015 Paris / \+33 6 8643 3085/// - 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 RESEND 1/1] crypto API: RSA algorithm patch (kernel version 2.6.20.1)
Francois Romieu wrote: RSA is slow. syscalls are fast. Which part of the kernel is supposed to benefit from this code ? The main purpose behind the development of this module was to create an in-kernel system of signed modules. The scenario applies most in embedded systems that are running linux where the kernel is physically secure but its filesystem is not, so one may tamper executable code. In such systems we need to detect the tampering in a centralized way (e.g without using hash databases e.t.c). So what you need to do is sign the executable (or the library) with a private key and have a kernel that will use the public key part to authenticate the executable againts its digital signature. Of course the signing and the authentication is not done against the whole executable but against its secure hash, and this takes milliseconds to complete before loading the code onto memory. You see, in such a usage scenario most of the time the kernel will spend will be on hashing (sha1 module) and not in modular exponentiation. Of course this will not produce any soft lockups Such a system cannot depend on userland to do the authentication for obvious security reasons, it must be in kernel. Of course sha1 is slow as well but there is an sha1 module for anyone who may need it. That was my idea, we developed it for our own security needs, why not make it available for others that may want to use it? Furthermore one can use the API to do multi-precision arithmetics, if any kernel module may need it -- Tasos Parisinos - 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 RESEND 1/1] crypto API: RSA algorithm patch (kernel version 2.6.20.1)
Thanks for your comments
On Mon, Mar 19, 2007 at 06:22:15PM +0200, Tasos Parisinos wrote:
+static inline _i32 rsa_max(_i32 x, _i32 y)
+{
+return (x > y)? x: y;
+}
We've got a max() already. Use tabs.
This is right, will be fixed, just hate discipline
+
+/*
+ * Module loading callback function
+ *
+ * Returns 0 on success or a negative value indicating error
+ */
This comment is not very useful.
Some of them are just bookmarks for me, i can get rid of them
+static _err __init rsa_load(void)
+{
+_u32 i;
Can we use int and u32 instead of _err and _u32, please?
+_err retval = RSA_NO_ERR;
And 0.
right
+/* Pre-allocate some auxilliary mpis */
+rsa_echo("Preallocating %lu bytes for auxilliary operands\n",
+ RSA_AUX_SIZE * RSA_AUX_COUNT * sizeof(_u32));
And printk.
i made such a printk wrapper not to mess with all the printk instances when i
needed to
does this hurt, to be left as is?
+memset(&aux, 0, sizeof(aux));
+for(i = 0; i < RSA_AUX_COUNT; i++) {
+retval = rsa_mpi_alloc(&aux[i], RSA_AUX_SIZE);
kmalloc, please? RSA_AUX_SIZE appears to be in bytes.
I need such a wrapper because there are other things done in rsa_mpi_alloc
than kmalloc
+if(retval < 0)
We use "for (" and "if (" so they don't look like function calls.
right, will fix
+goto rollback;
+}
+
+rsa_echo("RSA cipher algorithm module initialized\n");
+return RSA_NO_ERR;
+
+/* Free all allocated resources if any errors occur */
+rollback:
+for(i = 0; i < RSA_AUX_COUNT; i++)
+rsa_mpi_free(aux[i]);
kfree()
same as above, i need this wrapper
+/*
+ * Preallocate an mpi. The allocated mpi will be all-zeroed and not
+ * canonicalized.
+ *
+ * Returns 0 on success or a negative value indicating error
+ *
+ * @n: pointer pointer to the allocated mpi
+ * @limbs: number of allocated limbs (32 bit digits)
+ */
+static _err rsa_mpi_alloc(mpi ** n, _i32 limbs)
Kerneldoc style is "function_name - short description". We write
pointers as "mpi **n". These things probably all want to be named
mpi_* rather than rsa_mpi_*, as they're not specific to the RSA algorithm.
+{
+mpi * handle;
And here.
+rsa_debug("%s: kzalloc failed\n", __FUNCTION__);
printk.
+static _err rsa_mpi_init(mpi **n, _u8 * str, _u32 size, _u32 xtra)
If str is an actual string, use char *str.
+/* Allocate space for the mpi and its data */
+s = (size / 4) + ((size % 4)? 1: 0);
Uhhh.. (size + 1) / 4?
i think (size + 3)/4
+retval = rsa_mpi_alloc(n, s + xtra);
Is this not in bytes?
+/* Copy the data */
+for(i = size - 1, j = 0; i >= 0; i--, j++)
+buf[j / 4] |= ((_u32)str[i] << ((j % 4) * 8));
Ew.
not obvious eh? ok will break it apart
+/* Zero the xtra limbs */
+else if(size < handle->size)
+for(i = size; i < s; i++)
+buf[i] = 0;
memset?
in the first case it broke my results, so i left it for later
+return RSA_ERR_INVARG;
-EINVAL
+buf = (*n)->data;
+for(i = size - 1, j = 0; i >= 0; i--, j++)
+buf[j / 4] |= ((_u32)str[i] << ((j % 4) * 8));
That mess looks familiar.
not obvious as well, will break it apart
+#define RSA_AUX_COUNT CONFIG_RSA_AUXCOUNT
+#define RSA_AUX_SIZE CONFIG_RSA_AUXSIZE
Just use the config value.
+#define RSA_MAX_U320x
I'm sure we've got this somewhere.
if you could tell me i will fix it
+#define RSA_NO_ERR0
+#define RSA_ERR_INVARG-1
+#define RSA_ERR_NOMEM-2
0, -EINVAL, -ENOMEM.
+#define true0x01
+#define false0x00
Ew.
development leftovers, will fix
+/* Mpi utility functions */
+static _errrsa_mpi_alloc(mpi **, _i32);
+static void rsa_mpi_free(mpi *);
+static _err rsa_mpi_init(mpi **, _u8 *, _u32, _u32);
+static _err rsa_mpi_resize(mpi **, _i32, _u8);
+static _err rsa_mpi_set(mpi **, _u8 *, _u32);
+static inline _err rsa_mpi_copy(mpi **, mpi *);
+static void rsa_mpi_print(mpi *, _u8);
Why are you declaring a bunch of static functions in a header file?
i think the compiler will disagree if i dont, but i will give it a try
--
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/
[PATCH] small documentation fix in Documentation/kbuild/modules.txt
The Makefile fragment in Documentation/kbuild/modules.txt looks to be missing some braces. Signed-off-by: Anton Blanchard <[EMAIL PROTECTED]> --- diff --git a/Documentation/kbuild/modules.txt b/Documentation/kbuild/modules.txt index 769ee05..1d247d5 100644 --- a/Documentation/kbuild/modules.txt +++ b/Documentation/kbuild/modules.txt @@ -249,7 +249,7 @@ following files: --> filename: Makefile KERNELDIR := /lib/modules/`uname -r`/build all:: - $(MAKE) -C $KERNELDIR M=`pwd` $@ + $(MAKE) -C $(KERNELDIR) M=`pwd` $@ # Module specific targets genbin: - 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: Odd suspend regression in 2.6.21-rc[123]
Pavel Machek wrote: > Hi! > >> In 2.6.21-rc1,2,3, my laptop will fully suspend to ram, but then >> *immediately* resumes back from suspension. (It resumes just fine, as well.) >> >> Nothing out of the ordinary is logged, and this happens even when >> booting into init=/bin/sh with minimal modules loaded and executing >> s2ram from that minimal environment. >> >> I'm going to ponder the 2.6.20 to 2.6.21-rc1 changelog, but I'm hoping >> someone with a clue can offer a suggestion before I end up bisecting the >> whole thing. (Wouldn't be so bad, except I'm given to understand that >> there are multiple places in those changes where nothing quite works >> with respect to suspend.) >> >> HP/Compaq NX6125 system, AMD64, dmesg attached. > > Known problem in ACPI, hopefully already fixed? Mostly. The ACPI git tree has the fix (1d99967badac599c0d1db0b45c99e073e8e98cd4), but Len has yet to push it to Linus. Hopefully that'll happen before 2.6.21 final. Thanks Pavel, Ray - 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 RESEND 1/1] crypto API: RSA algorithm patch (kernel version 2.6.20.1)
On Tue, 20 Mar 2007, Tasos Parisinos wrote: > The main purpose behind the development of this module was to create an > in-kernel system of signed modules. I suggest you read this thread: http://lkml.org/lkml/2007/2/14/164 -- James Morris <[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: PNPACPI probes serial twice, messes up serial console
On Tue, Mar 20, 2007 at 08:32:24AM -0600, Bjorn Helgaas wrote: > Index: work-mm2/include/linux/serial_8250.h > === > --- work-mm2.orig/include/linux/serial_8250.h 2006-08-22 12:26:25.0 > -0600 > +++ work-mm2/include/linux/serial_8250.h 2006-08-22 16:37:36.0 > -0600 > @@ -44,6 +44,7 @@ > PLAT8250_DEV_HUB6, > PLAT8250_DEV_MCA, > PLAT8250_DEV_AU1X00, > + PLAT8250_DEV_X86, There's no need for PLAT8250_DEV_X86 if x86 went to the model that ARM and all the others which I did convert use - iow, PLAT8250_DEV_PLATFORM and friends. They're there so that the arch/* code can provide their serial port information to the 8250 driver instead of using include/asm-*/serial.h -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/22 take 3] UBI: Unsorted Block Images
On Tue, 2007-03-20 at 09:52 -0400, Theodore Tso wrote: > It would also help people understand why there are so many "units" in > UBI, since hopefully the high-level documentation would explain why > they fit together, and perhaps why some of the units weren't folded > together. What value do they add as separate components? Teo, the units will go away. I'll leave only 4 of them: 1. I/O, just to hide some I/O related complexities. 2. Scanning: just because I am planning to add other device attaching methods, without scanning. 3. Wear-leveling, just because I want to improve the algorithm in future. Changing algorithm means changing data structures. So I want to keeps them separate. 4. EBA - because I want to keep all mapping-related stuff in one place. Well, this does not have to be called unit, just mapping-related code in on file. Also, long-term is to have the table on-flash (currently it is in-ram which does not scale well). Everything else will be folded together. No itsy-bitsy. I've almost finished this re-structuring, doing bug-fixing. P.S.: I'll let other folks to comment the other stuff. -- Best regards, Artem Bityutskiy (Битюцкий Артём) - 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: RSDL v0.31
On 3/20/07, Mark Lord <[EMAIL PROTECTED]> wrote: I've droppped it from my machine -- interactive response is much more important for my primary machine right now. Help out with a data point? Are you running KDE as well? If you are, then it looks like the common denominator that RSDL is handling poorly is client-server communication. (KDE's KIO slaves in this case, but X in general.) If so, one would hope that a variation on Linus's 2.5.63 pipe wakeup pass-the-interactivity idea could work here. The problem with that original patch, IIRC, was that a couple of tasks could bounce their interactivity bonus back and forth and thereby starve others. Which might be expected given there was no 'decaying' of the interactivity bonus, which means you can make a feedback loop. Anyway, looks like processes that do A -> B -> A communication chains are getting penalized under RSDL. In which case, perhaps I can make a test case that exhibits the problem without having to have the same graphics card or desktop as you. Ray - 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: RSDL v0.31
Ray Lee wrote: On 3/20/07, Mark Lord <[EMAIL PROTECTED]> wrote: I've droppped it from my machine -- interactive response is much more important for my primary machine right now. Help out with a data point? Are you running KDE as well? Yes, KDE. - 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: s2ram autowake regression is still there in 2.6.21-rc4-git
On Tuesday 20 March 2007 08:06, Pavel Machek wrote: > Hi! > > > Run this script. The s2ram at the end of it will wakeup immediately > > after going to sleep, bad. I tried reproducing it with smaller > > version, but was not too successful. > > Actually > > > sleep 2 > > echo -n "testing swsusp (platform)..." > > echo platform > /sys/power/disk > > echo disk > /sys/power/state > > echo "okay" > > > > sleep 2 > > echo -n "testing s2ram..." > > s2ram > > echo "okay" > > ...this is enough to trigger it. I've done my testing on x60, FWIW. Please try the consolidated ACPI patch that is currently staged for release to upstream: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.21/acpi-release-20070126-2.6.21-rc4.diff.gz comming soon to a mirror near you:-) thanks, -Len - 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 RESEND 1/1] crypto API: RSA algorithm patch (kernel version 2.6.20.1)
On Tue, Mar 20, 2007 at 04:44:01PM +0200, Tasos Parisinos wrote:
> >>+/* Pre-allocate some auxilliary mpis */
> >>+rsa_echo("Preallocating %lu bytes for auxilliary operands\n",
> >>+ RSA_AUX_SIZE * RSA_AUX_COUNT * sizeof(_u32));
> >
> >And printk.
>
> i made such a printk wrapper not to mess with all the printk instances when
> i needed to
> does this hurt, to be left as is?
It's not horrible, but it's not pretty either.
> >>+memset(&aux, 0, sizeof(aux));
> >>+for(i = 0; i < RSA_AUX_COUNT; i++) {
> >>+retval = rsa_mpi_alloc(&aux[i], RSA_AUX_SIZE);
> >
> >kmalloc, please? RSA_AUX_SIZE appears to be in bytes.
>
> I need such a wrapper because there are other things done in rsa_mpi_alloc
> than kmalloc
Did you see my comment about removing all the rsa_ prefixes from the
MPI functions?
> >>+/* Copy the data */
> >>+for(i = size - 1, j = 0; i >= 0; i--, j++)
> >>+buf[j / 4] |= ((_u32)str[i] << ((j % 4) * 8));
> >
> >Ew.
>
> not obvious eh? ok will break it apart
You probably want to do it using ntohl.
> >>+buf[j / 4] |= ((_u32)str[i] << ((j % 4) * 8));
> >
> >That mess looks familiar.
> >
>
> not obvious as well, will break it apart
Well, it probably wants a function call.
>
> >>+#define RSA_AUX_COUNT CONFIG_RSA_AUXCOUNT
> >>+#define RSA_AUX_SIZE CONFIG_RSA_AUXSIZE
> >
> >Just use the config value.
> >
> >>+#define RSA_MAX_U320x
> >
> >I'm sure we've got this somewhere.
>
> if you could tell me i will fix it
Hmmm, odd. I can't find one. There are plenty of things that roll
their own though.
> >>+/* Mpi utility functions */
> >>+static _errrsa_mpi_alloc(mpi **, _i32);
> >>+static void rsa_mpi_free(mpi *);
> >>+static _err rsa_mpi_init(mpi **, _u8 *, _u32, _u32);
> >>+static _err rsa_mpi_resize(mpi **, _i32, _u8);
> >>+static _err rsa_mpi_set(mpi **, _u8 *, _u32);
> >>+static inline _err rsa_mpi_copy(mpi **, mpi *);
> >>+static void rsa_mpi_print(mpi *, _u8);
> >
> >Why are you declaring a bunch of static functions in a header file?
> >
>
> i think the compiler will disagree if i dont, but i will give it a try
static at the global level marks something as internal to a
compilation unit. We generally put these sorts of private declarations
straight into the .c file.
And we often skip such prototypes entirely if the .c file can be
ordered such that no forward declarations are necessary.
--
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: RSDL v0.31
On Tue, 20 Mar 2007, Willy Tarreau wrote: > > Linus, you're unfair with Con. He initially was on this position, and lately > worked with Mike by proposing changes to try to improve his X responsiveness. I was not actually so much speaking about Con, as about a lot of the tone in general here. And yes, it's not been entirely black and white. I was very happy to see the "try this patch" email from Al Boldi - not because I think that patch per se was necessarily the right fix (I have no idea), but simply because I think that's the kind of mindset we need to have. Not a lot of people really *like* the old scheduler, but it's been tweaked over the years to try to avoid some nasty behaviour. I'm really hoping that RSDL would be a lot better (and by all accounts it has the potential for that), but I think it's totally naïve to expect that it won't need some tweaking too. So I'll happily still merge RSDL right after 2.6.21 (and it won't even be a config option - if we want to make it good, we need to make sure *everybody* tests it), but what I want to see is that "can do" spirit wrt tweaking for issues that come up. Because let's face it - nothing is ever perfect. Even a really nice conceptual idea always ends up hitting the "but in real life, things are ugly and complex, and we've depended on behaviour X in the past and can't change it, so we need some tweaking for problem Y". And everything is totally fixable - at least as long as people are willing to! Linus
Re: [PATCH 2.6.21-rc3-mm2 3/4] futex_requeue_pi optimization
Peter Zijlstra a écrit :
+static void *get_futex_address(union futex_key *key)
+{
+ void *uaddr;
+
+ if (key->both.offset & 1) {
+ /* shared mapping */
+ uaddr = (void*)((key->shared.pgoff << PAGE_SHIFT)
+ + key->shared.offset - 1);
+ } else {
+ /* private mapping */
+ uaddr = (void*)(key->private.address + key->private.offset);
+ }
+
+ return uaddr;
+}
This will not work for nonlinear vmas, granted, not a lot of ppl stick
futexes in nonlinear vmas, but the futex_key stuff handles it, this
doesn't.
Indeed ! Thanks for pointing me to this.
Since I'm not familiar with vmm, does this code look more correct to you ?
static void *get_futex_address(union futex_key *key)
{
void *uaddr;
struct vm_area_struct *vma = current->mm->mmap;
if (key->both.offset & 1) {
/* shared mapping */
struct file * vmf;
do {
if ((vmf = vma->vm_file)
&& (key->shared.inode == vmf->f_dentry->d_inode))
break;
vma = vma->vm_next;
} while (vma);
if (likely(!(vma->vm_flags & VM_NONLINEAR)))
uaddr = (void*)((key->shared.pgoff << PAGE_SHIFT)
+ key->shared.offset - 1);
else
uaddr = (void*) vma->vm_start
+ ((key->shared.pgoff - vma->vm_pgoff)
<< PAGE_SHIFT)
+ key->shared.offset - 1;
} else {
/* private mapping */
uaddr = (void*)(key->private.address + key->private.offset);
}
return uaddr;
}
Or is there a more direct way to retrieve the vma corresponding to the given
inode ?
Thanks,
--
Pierre
-
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/
strange keyboard lag after suspend testing
Hi! I was testing suspend in 2.6.21-rc4 a lot, and now... machine feels like someone added 50..100msec delay somewhere in keyboard handling. Mouse does not seem affected. /proc/interrupts seem to increase as they should, for both keyboard and mouse. Can someone reproduce it? Any ideas how to debug it? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
