[patch] genirq: fix simple and fasteoi irq handlers
On Thu, Aug 02, 2007 at 10:11:26PM +0200, Ingo Molnar wrote:
>
> * Gabriel C <[EMAIL PROTECTED]> wrote:
>
> > I get a warning on each boot now with this patch ..
> >
> > [ 63.686613] WARNING: at kernel/irq/resend.c:70 check_irq_resend()
...
> we are still trying to figure out what happens with ne2k-pci. The
> message will vanish soon.
Hi,
I can't guarantee this is all needed to fix this bug, but I think
this patch is necessary here.
Regards,
Jarek P.
>
Subject: genirq: fix simple and fasteoi irq handlers
After the "genirq: do not mask interrupts by default" patch interrupts
should be disabled not immediately upon request, but after they happen.
But, handle_simple_irq() and handle_fasteoi_irq() can skip this once or
more if an irq is just serviced (IRQ_INPROGRESS), possibly disrupting a
driver's work.
The main reason of problems here, pointing the broken patch and making
the first patch which can fix this was done by Marcin Slusarz.
Additional test patches of Thomas Gleixner and Ingo Molnar tested by
Marcin Slusarz helped to narrow possible reasons even more. Thanks.
PS: this patch fixes only one evident error here, but there could be
more places affected by above-mentioned change in irq handling.
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
diff -Nurp 2.6.23-rc1-/kernel/irq/chip.c 2.6.23-rc1/kernel/irq/chip.c
--- 2.6.23-rc1-/kernel/irq/chip.c 2007-07-09 01:32:17.0 +0200
+++ 2.6.23-rc1/kernel/irq/chip.c2007-08-02 20:42:38.0 +0200
@@ -295,12 +295,11 @@ handle_simple_irq(unsigned int irq, stru
spin_lock(>lock);
- if (unlikely(desc->status & IRQ_INPROGRESS))
- goto out_unlock;
kstat_cpu(cpu).irqs[irq]++;
action = desc->action;
- if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
+ if (unlikely(!action || (desc->status & (IRQ_INPROGRESS |
+IRQ_DISABLED {
if (desc->chip->mask)
desc->chip->mask(irq);
desc->status &= ~(IRQ_REPLAY | IRQ_WAITING);
@@ -392,18 +391,16 @@ handle_fasteoi_irq(unsigned int irq, str
spin_lock(>lock);
- if (unlikely(desc->status & IRQ_INPROGRESS))
- goto out;
-
desc->status &= ~(IRQ_REPLAY | IRQ_WAITING);
kstat_cpu(cpu).irqs[irq]++;
/*
-* If its disabled or no action available
+* If it's running, disabled or no action available
* then mask it and get out of here:
*/
action = desc->action;
- if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
+ if (unlikely(!action || (desc->status & (IRQ_INPROGRESS |
+IRQ_DISABLED {
desc->status |= IRQ_PENDING;
if (desc->chip->mask)
desc->chip->mask(irq);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] More sh updates for 2.6.23-rc2
Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.23.git Which contains: David McCullough (1): sh: update snapgear defconfig. Magnus Damm (3): sh: update r2d defconfig sh: fix cf support on r2d boards sh: fix defconfigs for sh7751r boards Paul Mundt (5): sh: Fix lockdep debugging oops on SH-3/4. sh: Fix irqflags tracing for SH-3/4 nommu. sh: Don't include fault-nommu on SH-2/SH-2A. sh: Fix pgd mismatch from cached TTB in unhandled fault. sh: Fix SH-X3 FPU exception handling. arch/sh/boards/renesas/rts7751r2d/setup.c |9 +- arch/sh/configs/hs7751rvoip_defconfig |2 +- arch/sh/configs/landisk_defconfig |2 +- arch/sh/configs/lboxre2_defconfig |2 +- arch/sh/configs/rts7751r2d_defconfig |8 +- arch/sh/configs/snapgear_defconfig| 587 - arch/sh/configs/systemh_defconfig |2 +- arch/sh/configs/titan_defconfig |2 +- arch/sh/kernel/cpu/sh3/entry.S|3 +- arch/sh/kernel/traps.c|5 + arch/sh/mm/Makefile |4 +- arch/sh/mm/fault-nommu.c | 47 +-- arch/sh/mm/fault.c|3 +- include/asm-sh/rts7751r2d.h |2 +- 14 files changed, 282 insertions(+), 396 deletions(-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] balance-on-fork NUMA placement
On Fri, 3 Aug 2007, Nick Piggin wrote: > Well what's wrong with it? It seems to use memory policies for exactly > what they are intended (aside from it being kernel directed...). Sure I think you could do it with some effort. They were primarily designed for user space. Lots of little side issues where surprises await you. I think Lee documented many of them. See the recent mm commits. > > start the new thread and can the original processor wait on some flag > > until that is complete? > > I guess you could, but that is going to add a context switch to fork > (although it usually already has one in single-CPU situation because we > run child first)... I bet it will slow something down, but it would be > interesting to see. The context switch is needed at some point anyways to get the new process running on the new CPU? Just do it before allocating structures. That way the potential memory policy and cpuset context is preserved and followed. > I don't know the fork path well enough off the top of my head to know if > it will be that simple (with error handling etc). But I think it could > be done. I would think that the forking process has to wait on completion anyways and get an error code. > > Forking off from there not only places the data correctly but it also > > warms up the caches for the new process and avoids evicting cacheline on > > the original processor. > > Yeah, you might be right there. If the numbers say that approach is > better, then I'd not be against it. But we'd still need the simpler > mpol approach to compare it with. Lets hope that the simpler process is really simpler after all the corner cases have been dealt with. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Distributed storage.
On 7/31/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > TODO list currently includes following main items: > * redundancy algorithm (drop me a request of your own, but it is highly > unlikley that Reed-Solomon based will ever be used - it is too slow > for distributed RAID, I consider WEAVER codes) LDPC codes[1][2] have been replacing Turbo code[3] with regards to communication links and we have been seeing that transition. (maybe helpful, came to mind seeing the mention of Turbo code) Don't know how weaver compares to LDPC, though found some comparisons [4][5] But looking at fault tolerance figures, i guess Weaver is much better. [1] http://www.ldpc-codes.com/ [2] http://portal.acm.org/citation.cfm?id=1240497 [3] http://en.wikipedia.org/wiki/Turbo_code [4] http://domino.research.ibm.com/library/cyberdig.nsf/papers/BD559022A190D41C85257212006CEC11/$File/rj10391.pdf [5] http://hplabs.hp.com/personal/Jay_Wylie/publications/wylie_dsn2007.pdf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote: On Thu, 2 Aug 2007, Randy Dunlap wrote: C99 spec that Al referred you to (available for around US$18 as a pdf) says in 6.7.8, para. 14 (where Al said): "An array of character type may be initialized by a character string literal, optionally enclosed in braces. Successive characters of the character string literal (including the terminating null character if there is room or if the array is of unknown size) initialize the elements of the array." Wow... So, the terminating '\0' in the string constant IS "special" and "optional"... Ok, then, THIS does answer my question, THIS I can understand, and, ghm, accept... Thanks to all who tried to explain this to me and sorry it took so long... You should not have asked in the first place. The declaration char c[4] = "abcd" is perfectly valid. There is no cause for debate about it :) Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote:
On Thu, 2 Aug 2007, Robert Hancock wrote:
Because 5 characters will not fit in a 4 character array, even without the
null terminator.
On Fri, 3 Aug 2007, Stefan Richter wrote:
How should gcc know whether you actually wanted that char foo[len] to
contain a \0 as last element?
Robert, Stefan, I am sorry, I think, you are VERY wrong here. There is no
"even" and no guessing. The "string" DOES include a terminating '\0'. It
is EQUIVALENT to {'s', 't', 'r', 'i', 'n', 'g', '\0'}. And it contains
SEVEN characters. Please, re-read your K Specifically, the Section
"Initialization" in the "Function and Program Structure" chapter (section
4.9 in my copy), the paragraph about initialization with a string, which I
quoted in an earlier email.
Guennadi,
The declaration
char c[4] = "abcd";
is perfectly valid.
If other versions of gcc give warnings with that declaration, then those
warnings may be useful but it does not mean to say that other versions of
gcc follow the standards or not.
K is good as a reference but not as an authority. They drafted the book
as an informal specification of C. C has evolved throughout the decades.
The current standard is C99. And as quoted earlier in this thread,
character array initializations are described as:
6.7.8.14 of C99:
An array of character type may be initialized by a character string
literal, optionally enclosed in braces. Successive characters of the
character string literal (including the terminating null character if there
is room or if the array is of unknown size) initialize the elements of the
array.
The gcc warning you see on other versions is a warning that does not have
anything to do with the current C standard. The other versions of gcc that
do not emit such character initialization warnings do not mean that they
are buggy in that respect.
IOW, the fact that you did not see the warning in a certain gcc version
does not mean that it is buggy in that respect.
Thank you very much.
Best Regards,
Carlo
--
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, UP Campus Diliman
1101 Quezon City, Philippines
http://www.astra.ph
--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: CFS review
On Thu, Aug 02, 2007 at 09:31:19PM -0700, Arjan van de Ven wrote: > On Fri, 2007-08-03 at 06:18 +0200, Willy Tarreau wrote: > > On Thu, Aug 02, 2007 at 08:57:47PM -0700, Arjan van de Ven wrote: > > > On Thu, 2007-08-02 at 22:04 -0500, Matt Mackall wrote: > > > > On Wed, Aug 01, 2007 at 01:22:29PM +0200, Ingo Molnar wrote: > > > > > > > > > > * Roman Zippel <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > [...] e.g. in this example there are three tasks that run only for > > > > > > about 1ms every 3ms, but they get far more time than should have > > > > > > gotten fairly: > > > > > > > > > > > > 4544 roman 20 0 1796 520 432 S 32.1 0.4 0:21.08 lt > > > > > > 4545 roman 20 0 1796 344 256 R 32.1 0.3 0:21.07 lt > > > > > > 4546 roman 20 0 1796 344 256 R 31.7 0.3 0:21.07 lt > > > > > > 4547 roman 20 0 1532 272 216 R 3.3 0.2 0:01.94 l > > > > > > > > > > Mike and me have managed to reproduce similarly looking 'top' output, > > > > > but it takes some effort: we had to deliberately run a non-TSC > > > > > sched_clock(), CONFIG_HZ=100, !CONFIG_NO_HZ and > > > > > !CONFIG_HIGH_RES_TIMERS. > > > > > > > > ..which is pretty much the state of play for lots of non-x86 hardware. > > > > > > question is if it's significantly worse than before. With a 100 or > > > 1000Hz timer, you can't expect perfect fairness just due to the > > > extremely rough measurement of time spent... > > > > Well, at least we're able to *measure* that task 'l' used 3.3% and > > that tasks 'lt' used 32%. > > It's not measured if you use jiffies level stuff. It's at best sampled! But if we rely on the same sampling method, at least we will report something consistent with what happens. And sampling is often the correct method to get finer resolution on a macroscopic scale. I mean, we're telling users that we include the "completely fair scheduler" in 2.6.23, a scheduler which will ensure that all tasks get a fair share of CPU time. A user starts top and sees 33%+32%+32+3% for 4 tasks while he would have expected to see 25%+25%+25%+25%. You can try to explain users that it's the fairest distribution, but they will have a hard time believing it, especially when they measure the time spent on CPU with the "time" command. OK this is all sampling, but we should try to avoid relying on different sources of data for computation and reporting. Time and Top should report something close to 4*25% for comparable tasks. And if not, because of some sampling problem, maybe the scheduler cannot be that fair in some situations, but either it should make use of the sampling time and top use, or top and time should rely on the view of the scheduler. I'll try to quickly hack up a program which makes use of rdtsc from userspace to precisely measure user-space time, and disable TSC use from the kernel to see how the values diverge. Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: renaming kernel devices [was: VIA EPIA EK: strange eth dev numbering]
On Thu, 2 Aug 2007, Ondrej Zajicek wrote: On Thu, Aug 02, 2007 at 01:47:23PM +0200, Jan Engelhardt wrote: It does not rename ethX to the "next free" one, but to a _persistent_ one. If it were a "next free" thing, then removing a card would shuffle all your eth around again (and invalidate your iptables rules at the same time, to note). It is questionable what is _persistent_ . MAC-based names are persistent with regard to adding and removing of other cards, 'Plain' names are persistent with regard to replacing that card with different item (of a same kind). I am very happy that (using 'plain' names) i can send technician to replace broken NIC in our routers without need for configuration change. this is a very important point, and with the distros (and many kernel people) treating udev as a requirement this is going to bite a lot of people. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: CFS review
On Thu, Aug 02, 2007 at 08:57:47PM -0700, Arjan van de Ven wrote: > On Thu, 2007-08-02 at 22:04 -0500, Matt Mackall wrote: > > On Wed, Aug 01, 2007 at 01:22:29PM +0200, Ingo Molnar wrote: > > > > > > * Roman Zippel <[EMAIL PROTECTED]> wrote: > > > > > > > [...] e.g. in this example there are three tasks that run only for > > > > about 1ms every 3ms, but they get far more time than should have > > > > gotten fairly: > > > > > > > > 4544 roman 20 0 1796 520 432 S 32.1 0.4 0:21.08 lt > > > > 4545 roman 20 0 1796 344 256 R 32.1 0.3 0:21.07 lt > > > > 4546 roman 20 0 1796 344 256 R 31.7 0.3 0:21.07 lt > > > > 4547 roman 20 0 1532 272 216 R 3.3 0.2 0:01.94 l > > > > > > Mike and me have managed to reproduce similarly looking 'top' output, > > > but it takes some effort: we had to deliberately run a non-TSC > > > sched_clock(), CONFIG_HZ=100, !CONFIG_NO_HZ and !CONFIG_HIGH_RES_TIMERS. > > > > ..which is pretty much the state of play for lots of non-x86 hardware. > > question is if it's significantly worse than before. With a 100 or > 1000Hz timer, you can't expect perfect fairness just due to the > extremely rough measurement of time spent... Indeed. I'm just pointing out that not having TSC, fast HZ, no-HZ mode, or high-res timers should not be treated as an unusual circumstance. That's a PC-centric view. -- 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: CFS review
On Fri, 2007-08-03 at 06:18 +0200, Willy Tarreau wrote: > On Thu, Aug 02, 2007 at 08:57:47PM -0700, Arjan van de Ven wrote: > > On Thu, 2007-08-02 at 22:04 -0500, Matt Mackall wrote: > > > On Wed, Aug 01, 2007 at 01:22:29PM +0200, Ingo Molnar wrote: > > > > > > > > * Roman Zippel <[EMAIL PROTECTED]> wrote: > > > > > > > > > [...] e.g. in this example there are three tasks that run only for > > > > > about 1ms every 3ms, but they get far more time than should have > > > > > gotten fairly: > > > > > > > > > > 4544 roman 20 0 1796 520 432 S 32.1 0.4 0:21.08 lt > > > > > 4545 roman 20 0 1796 344 256 R 32.1 0.3 0:21.07 lt > > > > > 4546 roman 20 0 1796 344 256 R 31.7 0.3 0:21.07 lt > > > > > 4547 roman 20 0 1532 272 216 R 3.3 0.2 0:01.94 l > > > > > > > > Mike and me have managed to reproduce similarly looking 'top' output, > > > > but it takes some effort: we had to deliberately run a non-TSC > > > > sched_clock(), CONFIG_HZ=100, !CONFIG_NO_HZ and !CONFIG_HIGH_RES_TIMERS. > > > > > > ..which is pretty much the state of play for lots of non-x86 hardware. > > > > question is if it's significantly worse than before. With a 100 or > > 1000Hz timer, you can't expect perfect fairness just due to the > > extremely rough measurement of time spent... > > Well, at least we're able to *measure* that task 'l' used 3.3% and > that tasks 'lt' used 32%. It's not measured if you use jiffies level stuff. It's at best sampled! > If we're able to measure it, then that's > already fine enough to be able to adjust future timeslices credits. > Granted it may be rough for small periods (a few jiffies), but it > should be fair for larger periods. Or at least it should *report* but the testcase here uses a LOT shorter time than jiffies... not "a few jiffies". -- 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: blackfin toolchain and build issues
On Fri, Aug 03, 2007 at 10:18:01AM +0800, Bryan Wu wrote: > > I will check this on my side ASAP. But the git-tree did not merge my > "fs.h" header file patch, how could it compiled passed like this? > I just inserted "#include in mm.h as a temporary workaround. I also had to deselect a few drivers to make it build this far (used defconfig). 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: CFS review
On Thu, Aug 02, 2007 at 08:57:47PM -0700, Arjan van de Ven wrote: > On Thu, 2007-08-02 at 22:04 -0500, Matt Mackall wrote: > > On Wed, Aug 01, 2007 at 01:22:29PM +0200, Ingo Molnar wrote: > > > > > > * Roman Zippel <[EMAIL PROTECTED]> wrote: > > > > > > > [...] e.g. in this example there are three tasks that run only for > > > > about 1ms every 3ms, but they get far more time than should have > > > > gotten fairly: > > > > > > > > 4544 roman 20 0 1796 520 432 S 32.1 0.4 0:21.08 lt > > > > 4545 roman 20 0 1796 344 256 R 32.1 0.3 0:21.07 lt > > > > 4546 roman 20 0 1796 344 256 R 31.7 0.3 0:21.07 lt > > > > 4547 roman 20 0 1532 272 216 R 3.3 0.2 0:01.94 l > > > > > > Mike and me have managed to reproduce similarly looking 'top' output, > > > but it takes some effort: we had to deliberately run a non-TSC > > > sched_clock(), CONFIG_HZ=100, !CONFIG_NO_HZ and !CONFIG_HIGH_RES_TIMERS. > > > > ..which is pretty much the state of play for lots of non-x86 hardware. > > question is if it's significantly worse than before. With a 100 or > 1000Hz timer, you can't expect perfect fairness just due to the > extremely rough measurement of time spent... Well, at least we're able to *measure* that task 'l' used 3.3% and that tasks 'lt' used 32%. If we're able to measure it, then that's already fine enough to be able to adjust future timeslices credits. Granted it may be rough for small periods (a few jiffies), but it should be fair for larger periods. Or at least it should *report* some fair distribution. Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Distributed storage.
On 7/31/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > Hi. > > I'm pleased to announce first release of the distributed storage > subsystem, which allows to form a storage on top of remote and local > nodes, which in turn can be exported to another storage as a node to > form tree-like storages. Very interesting work, I read through your blog for the project and it is amazing how quickly you developed/tested this code. Thanks for capturing the evolution of DST like you have. > Compared to other similar approaches namely iSCSI and NBD, > there are following advantages: > * non-blocking processing without busy loops (compared to both above) > * small, plugable architecture > * failover recovery (reconnect to remote target) > * autoconfiguration (full absence in NBD and/or device mapper on top of > it) > * no additional allocatins (not including network part) - at least two in > device mapper for fast path > * very simple - try to compare with iSCSI > * works with different network protocols > * storage can be formed on top of remote nodes and be exported > simultaneously (iSCSI is peer-to-peer only, NBD requires device > mapper and is synchronous) Having the in-kernel export is a great improvement over NBD's userspace nbd-server (extra copy, etc). But NBD's synchronous nature is actually an asset when coupled with MD raid1 as it provides guarantees that the data has _really_ been mirrored remotely. > TODO list currently includes following main items: > * redundancy algorithm (drop me a request of your own, but it is highly > unlikley that Reed-Solomon based will ever be used - it is too slow > for distributed RAID, I consider WEAVER codes) I'd like to better understand where you see DST heading in the area of redundancy.Based on your blog entries: http://tservice.net.ru/~s0mbre/blog/devel/dst/2007_07_24_1.html http://tservice.net.ru/~s0mbre/blog/devel/dst/2007_07_31_2.html (and your todo above) implementing a mirroring algorithm appears to be a near-term goal for you. Can you comment on how your intended implementation would compare, in terms of correctness and efficiency, to say MD (raid1) + NBD? MD raid1 has a write intent bitmap that is useful to speed resyncs; what if any mechanisms do you see DST embracing to provide similar and/or better reconstruction infrastructure? Do you intend to embrace any exisiting MD or DM infrastructure? BTW, you have definitely published some very compelling work and its sad that you're predisposed to think DST won't be recieved well if you pushed for inclusion (for others, as much was said in the 7.31.2007 blog post I referenced above). Clearly others need to embrace DST to help inclusion become a reality. To that end, its great to see that Daniel Phillips and the other zumastor folks will be putting DST through its paces. regards, 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/
[RFC] Handling kernel stack overflows
First a bit of background for people who are not familiar with kernel stack constructs. * Every process has a dedicated kernel stack. In this context, 'process' includes user space processes and threads, plus those processes that only exist inside the kernel (e.g. kswapd, xfslogd). * When a process is sleeping, there is some state in its kernel stack to let the scheduler wake it up, that stack does not change until the scheduler assigns the task to a cpu. When a processing is running and is scheduled on a cpu, it is actively reading and writing its stack. * Kernel stacks are a fixed size. Unlike user space stacks, they do not expand as required. Also unlike user space stacks, kernel stacks are not swappable. * Each architecture uses different size kernel stacks (defined by THREAD_SIZE). THREAD_SIZE is typically (always?) a multiple of the kernel page size. * When a kernel stack occupies multiple pages, the pages assigned to that stack must be physically contiguous and in memory. * Kernel stacks are typically aligned on a THREAD_SIZE boundary so (stack_pointer & ~(THREAD_SIZE - 1)) gives you the start of the stack. * If you overflow the kernel stack for a process then you corrupt the next page, with undefined results. This usually causes very strange kernel oops. * Historically (up to 2.4/2.5 kernels), 'struct task' for a process was embedded in the kernel stack for that process, reducing the usable amount of stack space. Variable 'current' pointed to both the 'struct task' and the kernel stack. * In more recent kernels, almost all architectures separate 'struct task' from the stack. 'struct task' is created via a slab allocator, the stack is created from a page allocator. 'current' now points to 'struct task' which in turn points to the active kernel stack. * Separating 'struct task' from the stack means that a single 'struct task' can point to different kernel stacks throughout its lifetime. This makes it possible to use additional kernel stacks for special processing like interrupt handling. * IA64 is different (isn't it always?). It is the only architecture that still embeds 'struct task' within the kernel stack. I wish that it separated the two, it would make MCA/INIT handling so much easier. Alas David Mosberger vetoed that approach for IA64. On IA64, 'current' still points to both 'struct task' and the kernel stack, making it impossible to use specialized kernel stacks on IA64. * On i386, kernel stacks were historically 8K in size, with all processing being done on that single 8K stack (no additional specialized stacks). On i386 boxes with large numbers of processes, it became difficult to kmalloc() a kernel stack when forking a new process. Each new process required two physically contiguous pages, starting on an 8K boundary. i386 boxes would often get into a state where there were enough free pages, but they were not contiguous and 8K aligned. * Interrupt processing can be separated into hard and soft IRQ contexts. Hard IRQ context is when the kernel is servicing the hardware, e.g. talking to a disk controller. To minimize the amount of time that the hardware is disabled, most drivers will grab some data from the hardware, store the data in a kernel structure, schedule some work to be done later then re-enable the hardware. When the kernel returns from a hard interrupt it checks for any scheduled work then runs that work in a soft IRQ context. * Even when an 8K kernel stack could be allocated, 8K was not always enough room to cope with an interrupt arriving while a process was active. Normal processing could be interrupted by a hard IRQ which could schedule a soft IRQ which could in turn be interrupted by another hard IRQ. Those three levels of processing all had to fit into 8K. * Enter CONFIG_4KSTACKS for i386. It recognizes that activity on the kernel stack only occurs while the process is running, and that much of that activity occurs in response to an interrupt, either in hard or soft IRQ context. * By reducing the per-process stack to 4K, CONFIG_4KSTACKS makes it easier to allocate the kernel stack for a new process when the system is under heavy memory pressure. * If an interrupt occurs while a CONFIG_4KSTACKS process is running, the kernel retains the current task but switches the stack to a separate specialized stack. There are two additional 4K stacks on each cpu, for soft and hard IRQ processing. The combination of the normal process stack plus the soft and hard IRQ stacks gives up to 12K of stack for an active process, instead of the previous total of 8K. * By definition, processes cannot sleep in interrupt context. Therefore when a process does sleep, it is guaranteed that the soft and hard IRQ stacks on that cpu are not in use. The process state is saved in its dedicated 4K stack and the per cpu IRQ stacks are now free
Re: [patch] add kdump_after_notifier
Vivek Goyal (on Thu, 2 Aug 2007 16:58:52 +0530) wrote: >On Wed, Aug 01, 2007 at 04:00:48AM -0600, Eric W. Biederman wrote: >> Takenori Nagano <[EMAIL PROTECTED]> writes: >> >> >> No. The problem with your patch is that it doesn't have a code >> >> impact. We need to see who is using this and why. >> > >> > My motivation is very simple. I want to use both kdb and kdump, but I >> > think it >> > is too weak to satisfy kexec guys. Then I brought up the example enterprise >> > software. But it isn't a lie. I know some drivers which use panic_notifier. >> > IMHO, they use only major distribution, and they has the workaround or they >> > don't notice this problem yet. I think they will be in trouble if all >> > distributions choose only kdump. >> >> Possibly. >> >> > BTW, I use kdb and lkcd now, but I want to use kdb and kdump. I sent a >> > patch to >> > kdb community but it was rejected. kdb maintainer Keith Owens said, >> >> >> Both KDB and crash_kexec should be using the panic_notifier_chain, with >> >> KDB having a higher priority than crash_exec. The whole point of >> >> notifier chains is to handle cases like this, so we should not be >> >> adding more code to the panic routine. >> >> >> >> The real problem here is the way that the crash_exec code is hard coded >> >> into various places instead of using notifier chains. The same issue >> >> exists in arch/ia64/kernel/mca.c because of bad coding practices from >> >> kexec. >> >> I respectfully disagree with his opinion, as using notifier chains >> assumes more of the kernel works. Although following it's argument >> to it's logical conclusion we should call crash_kexec as the very >> first thing inside of panic. Given how much state something like >> bust_spinlocks messes up that might not be a bad idea. >> >> It does make adding an alternative debug mechanism in there difficult. >> Does anyone know if this also affects kgdb? >> >> > Then I gave up to merge my patch to kdb, and I tried to send another patch >> > to >> > kexec community. I can understand his opinion, but it is very difficult to >> > modify that kdump is called from panic_notifier. Because it has a reason >> > why >> > kdump don't use panic_notifier. So, I made this patch. >> > >> > Please do something about this problem. >> >> Hmm. Tricky. These appear to be two code bases with a completely different >> philosophy on what errors are being avoided. >> >> The kexec on panic assumption is that the kernel is broken and we better not >> touch it something horrible has gone wrong. And this is the reason why >> kexec on panic is replacing lkcd. Because the strong assumption results >> in more errors getting captured with less likely hood of messing up your >> system. >> >> The kdb assumption appears to be that the kernel is mostly ok, and that there >> are just some specific thing that is wrong. >> > >Thinking more about it. So basically there are two kind of users. One who >believe that despite the kernel has crashed something meaningful can >be done. In fact kernel also thinks so. That's why we have created >panic_notifier_list and even exported it to modules and now we have some >users. These users most of the time do non-disruptive activities and >can co-exist. > >OTOH, we have kexec on panic, which thinks that once kernel is crashed >nothing meaningful can be done and it is disruptive and can't co-exist >with other users. > >Some thoughts on possible solutions for this problem. > >- Stop exporting panic_notifier_list list to modules. Audit the in kernel > users of panic_notifier_list. Let crash_kexec() run once all other users > of panic_notifier_list have been executed. This has fall side of breaking > down external modules using panic_notifier_list and at the same time > there is no gurantee that audited code will not run into the issues. > >- Continue with existing policy. If kdump is configured, panic_notifier_list > notifications will not be invoked. Any post panic action should be executed > in second kernel. There might be 1-2 odd cases like in kernel debugger > which still needs to be invoked in first kernel. These users should > explicitly put hooks in panic() routine and refrain from using > panic_notifier list. > > One thing to keep in mind, doing things in second kernel might not be easy > as we have lost all the config data of the first kernel. For example, > if one wants to send a kernel crash event over network to a system > management software, he might have to pack in lot of software in > second kernel's initrd. > >- Let the user decide if he wants to run panic_notifier_list after the > crash or not with the help of a /proc option as suggested by the > Takenori's patch. Fall side is, on what basis an enterprise user will > take a decision whether he wants to run the notifiers or not. My gut > feeling is that distro will end up setting this parameter as 1 by default, > which would mean first run panic notifiers and then run
Re: CFS review
On Thu, 2007-08-02 at 22:04 -0500, Matt Mackall wrote: > On Wed, Aug 01, 2007 at 01:22:29PM +0200, Ingo Molnar wrote: > > > > * Roman Zippel <[EMAIL PROTECTED]> wrote: > > > > > [...] e.g. in this example there are three tasks that run only for > > > about 1ms every 3ms, but they get far more time than should have > > > gotten fairly: > > > > > > 4544 roman 20 0 1796 520 432 S 32.1 0.4 0:21.08 lt > > > 4545 roman 20 0 1796 344 256 R 32.1 0.3 0:21.07 lt > > > 4546 roman 20 0 1796 344 256 R 31.7 0.3 0:21.07 lt > > > 4547 roman 20 0 1532 272 216 R 3.3 0.2 0:01.94 l > > > > Mike and me have managed to reproduce similarly looking 'top' output, > > but it takes some effort: we had to deliberately run a non-TSC > > sched_clock(), CONFIG_HZ=100, !CONFIG_NO_HZ and !CONFIG_HIGH_RES_TIMERS. > > ..which is pretty much the state of play for lots of non-x86 hardware. question is if it's significantly worse than before. With a 100 or 1000Hz timer, you can't expect perfect fairness just due to the extremely rough measurement of time spent... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [NFSD OOPS] 2.6.23-rc1-git10
On Thursday August 2, [EMAIL PROTECTED] wrote: > Hi, > > Got the following oopsen just now from 2.6.23-rc1-git10 on a 2 > processor Opteron with 2GB RAM. System is running 64bit Fedora Core 6. > > nfsd is exporting directories from a XFS filesystem on top a software > RAID 5 array comprising 3 x 250GB SATA disks using the sata_sil driver. > > Amongst other things, users (about 12) home directories are > automounted from it. > > Some problems seem to start when I was experimenting with the > stripe_cache_size of the md array. People could no longer run some apps > and having general NFS issues. IIRC I had dropped the stripe_cache_size > down from 8192 to 768 then I attempted to restart nfsd > via /etc/rc.d/init.d/nfsd restart > > I then got the Oopses and the machine locked up needing a power cycle. > > > Aug 2 10:15:55 thor mountd[30048]: Caught signal 15, un-registering and > exiting. > Aug 2 10:15:55 thor nfsd[16390]: nfssvc: Setting version failed: errno 16 > (Device or resource busy) > Aug 2 10:15:56 thor kernel: lockd_down: lockd failed to exit, clearing pid > Aug 2 10:15:56 thor kernel: nfsd: last server has exited > Aug 2 10:15:56 thor kernel: nfsd: unexporting all filesystems > Aug 2 10:15:56 thor kernel: [ cut here ] > Aug 2 10:15:56 thor kernel: kernel BUG at > /home/andrew/src/linux-2.6/net/sunrpc/svc.c:488! It seems you have found a race between shutting down and starting up nfsd. You md array was probably going very slowly due to playing with stripe_cache_size, and that stretched things out long enough to loose the race. NFSD is shut down by something similar to killall nfsd which sends signals to all the threads, but doesn't wait for them to exit. The first line in the log is mountd exiting. nfsd should have all been signalled at the same time. The second line comes from the nfsd program trying to start up the nfsd threads again, and getting an error because there were some already running. The third is a similar issue with lockd. The 4th and 5th show the last thread exiting. Only it isn't really the last thread. By this stage some more nfsd threads have started up. There was probably a backlog of requests as things were running slowly so as soon as a new nfsd thread was started, it accepted a connection and created a new temporary socket. This would have been after the thread that thought it was the last thread, thought it had closed the last temp socket. This caused the BUG. As part of shutting down, the thread that thought it was last cleared out the read-ahead info cache. When the new threads tried to use it, they all suffered general protection faults. So clearly we need some proper locking around thread start-up and shutdown. We had previous relied on lock_kernel, but that isn't really good enough for this. I'll try to figure out the best way to fix it. Meanwhile, I doubt the problem will recur. Thanks for the report. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: Hibernation considerations
On Wed, 1 Aug 2007, Pavel Machek wrote: Hi! Do we have to block module loading? No. Registering new drivers is okay, registering new devices is bad. Of course, some modules do want to register a new device in their init method. I don't know what we should do about them. Force the registration to fail, I suppose. How often will people suspend while a module is loading? Well... plug this pcmcia card into the slot so that I do not have to carry it separately, close the lid and go? ...not that impossible to imagine... I useually leave my broadband card in the slot, but not seated. I wouldn't bet against it getting pushed in enough to be detected while putting the laptop in the bag. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.22-rc1-mm1 huge pages VM freeze (maybe?)
On 8/1/07, Zan Lynx <[EMAIL PROTECTED]> wrote: > On Wed, 2007-08-01 at 08:52 -0700, Nish Aravamudan wrote: > > On 7/31/07, Zan Lynx <[EMAIL PROTECTED]> wrote: > > > On Tue, 2007-07-31 at 15:02 -0700, Randy Dunlap wrote: > > > > On Tue, 31 Jul 2007 15:44:21 -0600 Zan Lynx wrote: > > > > > > > > > I was playing with huge pages and libhugetlbfs. Small programs like > > > > > "ls" work fine. I tried running Evolution through libhugetlbfs and > > > > > the > > > > > system slowly stops running. One interesting thing is the "ps" > > > > > command, > > > > > it gets stuck like this: > > > > > > > > Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1? > > > > > > D'oh! I mean 2.6.23-rc1-mm1, the 22 was a typo. Cut & paste to be > > > sure: > > > Linux zephyr 2.6.23-rc1-mm1 #1 SMP PREEMPT Wed Jul 25 17:33:04 MDT 2007 > > > x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux > > > > Just to confirm, still happens with -mm2? > > No, it does not seem to. Evolution runs OK. ps, top, pmap all work > fine. Interesting. > However, a couple of other things happened. Could be unrelated or only > loosely related. > > Evolution launches spamd (spamassassin) to filter junk mail. spamd died > and I have this in dmesg to show for it: > > VM: killing process spamd > > spamd would have inherited the libhugetlbfs.so environment variables. > There are no other clues as to why it died though. Interesting. Any chance spamd can be run manually with those env variables, but with HUGETLB_VERBOSE=99 (and/or in gdb) to see what happens to it? > Also, immediately after launching evolution with libhugetlbfs, I got > that USB bug where the mouse starts creating keyboard input. I got some > of these in dmesg: > keyboard.c: can't emulate rawmode for keycode 240 > > That could be pure coincidence, although I had been using the system > almost all day before that, and it hadn't happened. Had you started evolution w/o libhugetlbs at all before that? It does seem like that would be coincidence. Thanks, Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Fri, Aug 03, 2007 at 08:47:56AM +0530, Satyam Sharma wrote:
>
>
>On Thu, 2 Aug 2007, Jan Engelhardt wrote:
>
>> On Aug 2 2007 21:55, Guennadi Liakhovetski wrote:
>> > [...]
>> >
>> >struct {
>> >char c[4];
>> >int i;
>> >} t;
>> >t.i = 0x12345678;
>> >strcpy(t.c, c);
>> >
>> >and t.i is silently corrupted. Just wanted to ask if this is known,
>> >really...
>>
>> What does this have to do with the kernel? The string "0123" is
>> generally _five_ characters long, so c[4] is not enough.
>> Or use strncpy.
>
>
>
>While we're talking of null-termination of strings, then I bet you
>generally want to be using strlcpy(), really. Often strncpy() isn't
>what you want. Of course, if that buffer isn't a string at all, then
>you should be using memfoo() functions and not strbar() ones in the
>first place ...
Afaik, strlcpy() and strlcat() are NOT standard C library functions.
But, I know, they are available in Linux kernel. ;) And yes, they
are better than strn{cpy,cat}().
Regards.
--
_ /|
\'o.O'
=(___)=
U
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] retrieve VBE EDID/DDC info independent of used video mode
On Thu, 2007-08-02 at 22:33 -0400, Daniel Drake wrote:
> Antonino A. Daplas wrote:
> > How about this patch?
> >
> > Tony
> > ---
> >
> > Subject: video setup: Fix VBE DDC reading
> >
> > Add memory operand constraint and write-only modifier to the inline
> > assembly to effect the writing of the EDID block to boot_params.edid_info.
>
>
> Thanks, this patch works in that Linux now reports the correct resolution.
>
> However, the TV output is now scrambled...
The previous problem was just a display shift of 6 pixels, correct? If
the display is now scrambled, then this is a new problem.
> I suspect this might be a result of adding CONFIG_FRAMEBUFFER_CONSOLE in
> the most recent tests.
It's useless to unset CONFIG_FRAMEBUFFER_CONSOLE to 'n', he'll just end
up with a 640x400 stretched or windowed display.
Can he...
1. describe what 'scrambled' means?
2. Boot with video=intelfb:accel=0,?
3. post the output of 'fbset -i' and the latest dmesg?
4. change the color depth ('fbset -depth 16')?
5. If possible, run X using 'fbdev' as the driver at 16 bpp
(I don't think 32 bpp works with X-fbdev)?
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc] balance-on-fork NUMA placement
On Thu, Aug 02, 2007 at 06:34:04PM -0700, Christoph Lameter wrote: > On Fri, 3 Aug 2007, Nick Piggin wrote: > > > Yeah it only gets set if the parent is initially using a default policy > > at this stage (and then is restored afterwards of course). > > Uggh. Looks like more hackery ahead. I think this cannot be done in the > desired clean way until we have some revving of the memory policy > subsystem that makes policies task context independent so that you can do Well what's wrong with it? It seems to use memory policies for exactly what they are intended (aside from it being kernel directed...). > alloc_pages(, memory_policy) That still doesn't completely help because again it would require modifying call sites (at which point I could just do alloc_pages_node). > The cleanest solution that I can think of at this point is certainly to > switch to another processor and do the allocation and copying actions from > there. We have the migration process context right? Can that be used to > start the new thread and can the original processor wait on some flag > until that is complete? I guess you could, but that is going to add a context switch to fork (although it usually already has one in single-CPU situation because we run child first)... I bet it will slow something down, but it would be interesting to see. I don't know the fork path well enough off the top of my head to know if it will be that simple (with error handling etc). But I think it could be done. > Forking off from there not only places the data correctly but it also > warms up the caches for the new process and avoids evicting cacheline on > the original processor. Yeah, you might be right there. If the numbers say that approach is better, then I'd not be against it. But we'd still need the simpler mpol approach to compare it with. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: eurotechwdt will cause reboot
>On 8/3/07, Dave Young <[EMAIL PROTECTED]> wrote: > >On 8/1/07, Dave Young <[EMAIL PROTECTED]> wrote: > > >On 8/1/07, Wim Van Sebroeck <[EMAIL PROTECTED]> wrote: > > > Hi Dave, > > > > > > > config eurotechwdt to yes will cause system silent reboot. Is it right > > > > behaviour or a bug? > > > > > > I think this might be a bug. I'll look at the code and will ask you to do > > > some > > > tests for me (if that is ok for you). > > > > > I'm ok for me. BTW, the rebooting is too quick that I have to set he > > boot_delay command line parameter to see it. > > > > Hi, > News: 2.6.23-rc1-mm1 will reboot with eurotechwdt, but 2.6.23-rc1-mm2 > will not. do you need the config files? > > I will concentrate on this problem as well. Any hints how to debug? under 2.6.23-rc1-mm1, modprobe eurotechwdt kernel will print: [ 4268.950385] timeout WDT timeout [ 4268.950443] Initiating system reboot. [ 4268.950472] eurwdt (IRQ 10) handled a spurious interrupt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: gcc fixed size char array initialization bug - known?
On Thu, 2 Aug 2007, Jan Engelhardt wrote:
> On Aug 2 2007 21:55, Guennadi Liakhovetski wrote:
> > [...]
> >
> > struct {
> > char c[4];
> > int i;
> > } t;
> > t.i = 0x12345678;
> > strcpy(t.c, c);
> >
> >and t.i is silently corrupted. Just wanted to ask if this is known,
> >really...
>
> What does this have to do with the kernel? The string "0123" is
> generally _five_ characters long, so c[4] is not enough.
> Or use strncpy.
While we're talking of null-termination of strings, then I bet you
generally want to be using strlcpy(), really. Often strncpy() isn't
what you want. Of course, if that buffer isn't a string at all, then
you should be using memfoo() functions and not strbar() ones in the
first place ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: CFS review
On Wed, Aug 01, 2007 at 01:22:29PM +0200, Ingo Molnar wrote: > > * Roman Zippel <[EMAIL PROTECTED]> wrote: > > > [...] e.g. in this example there are three tasks that run only for > > about 1ms every 3ms, but they get far more time than should have > > gotten fairly: > > > > 4544 roman 20 0 1796 520 432 S 32.1 0.4 0:21.08 lt > > 4545 roman 20 0 1796 344 256 R 32.1 0.3 0:21.07 lt > > 4546 roman 20 0 1796 344 256 R 31.7 0.3 0:21.07 lt > > 4547 roman 20 0 1532 272 216 R 3.3 0.2 0:01.94 l > > Mike and me have managed to reproduce similarly looking 'top' output, > but it takes some effort: we had to deliberately run a non-TSC > sched_clock(), CONFIG_HZ=100, !CONFIG_NO_HZ and !CONFIG_HIGH_RES_TIMERS. ..which is pretty much the state of play for lots of non-x86 hardware. -- 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: [NFS] rpc.mountd crashes when extensively using netgroups
On Thursday August 2, [EMAIL PROTECTED] wrote: > > I started having a look at this today. The original patches that I > proposed to clean up the rmtab a few months ago also eliminated this > comma-delimited string. Neil had valid objections to it at the time, > but if we switched to using the IP address as a cache key like Bruce > describes then doing that becomes more reasonable. > > The only downside I see is the one Bruce points out -- the size of > the kernel export cache would increase. I don't have a feel for whether > this is a show stopper, however. > > Neil, do you have thoughts on what you'd consider a reasonable approach > to fixing this? > I'm having troubling visualising the problematic setup. Is it possible to get a copy of the /etc/exports file, and some idea of what hosts are in which netgroups? Knowing that would help assess the appropriateness of various solutions. The core issue is this: We need to map IPADDRESS to THING, and THING + PATH to EXPORTPOINT. (roughly). So what do we choose for "THING"? One obvious option is the dotted quad of the IP address. People tend to have large sets of similar clients, so doing this seems to be missing out on a valuable optimisation and adding bloat to the lookup tables in the kernel. Another apparently obvious solution is to use FQDN, but we really don't want to do that, as a multihomed host might have one IP address that you want to trust, and another that you don't (as the subnet is less secure against forgery). It doesn't help must over dotted-quad anyway. Another option is to use whatever strings are included in /etc/exports to identify things. e.g. *.my.domain or @mynetgroup. This seems simple and elegant, but it can be messy in some situations. In particular, if one IP address matches several strings, which one do you use? We have to use them all. One path might be exported to *.my.domain and a different path might be exported to @mynetgroup. If a.b.c.d is in both of those sets of machines, then the THING that a.b.c.d is mapped to must allow the correct THING + PATH -> EXPORTPOINT mapping for both paths. *.my.domain,@mynetgroup works quite effectively. But if you have lots and lots of different netgroups mentioned in /etc/exports, and one machine is in all of those netgroups, then you have to generate a very long string @a,@b,@c,@d,. I guess we could use a hash and keep a hash table in mountd. So mountd: 1/ Generates the comma-separated name as needed, being careful to allocate enough space. 2a/ If this is small enough, write it to the kernel as is. 2b/ If it is too big, Find it in a table (adding if needed) and write the address of the table entry to the kernel When a THING + PATH request arrives: If THING looks like an address in the table, do the lookup to get the string. This would work to keep the strings in the kernel shorter, but is rather ugly - storing in the kernel addresses in a user-space program. Also, if you have lots of netgroups mentioned, then finding out which ones contain a given IP address might be slow, and all the information isn't really needed. Once you get THING, it will be paired with a specific path, so you only really need to look up netgroups that are related to that path. So maybe we want to combine the two workable approaches. Sometimes IPADDRESS maps to DOTTED_QUAD Sometimes IPADDRESS maps to LIST,OF,STRINGS,FROM,ETC,EXPORTS Possibly the choice could be based on a command line switch. In the absence of such a switch, it could be based on the number of entries in /etc/exports. int i; int size = 0; nfs_client *clp; for (i = 0 ; i < MCL_MAXTYPES; i++) for (clp = clientlist[i]; clp ; clp = clp->m_next) size += strlen(clp->m_hostname)+1; if (size > 1000) use DOTTED_QUAD; els don't. ?? NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.23-rc1-mm2 + cpufreq patch -- inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
I am running Ubuntu Gutsy with latest updates.
When I run "/etc/init.d/networking stop" with my custom kernel, I get:
=
[ INFO: inconsistent lock state ]
2.6.23-rc1-mm2 #21
-
inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
ifconfig/8982 [HC0[0]:SC0[0]:HE1:SE1] takes:
(>lock){++..}, at: [] rtl8139_interrupt+0x22/0x377 [8139too]
{in-hardirq-W} state was registered at:
[] __lock_acquire+0x430/0xbca
[] lock_acquire+0x76/0x9d
[] _spin_lock+0x23/0x32
[] rtl8139_interrupt+0x22/0x377 [8139too]
[] handle_IRQ_event+0x1a/0x4f
[] handle_fasteoi_irq+0x7d/0xb6
[] do_IRQ+0xaf/0xd9
[] 0x
irq event stamp: 1501
hardirqs last enabled at (1501): [] kfree+0xc7/0xdb
hardirqs last disabled at (1500): [] kfree+0x67/0xdb
softirqs last enabled at (1480): [] dev_deactivate+0x87/0xa0
softirqs last disabled at (1478): [] _spin_lock_bh+0xb/0x37
other info that might help us debug this:
1 lock held by ifconfig/8982:
#0: (rtnl_mutex){--..}, at: [] mutex_lock+0x1c/0x1f
stack backtrace:
[] show_trace_log_lvl+0x12/0x25
[] show_trace+0xd/0x10
[] dump_stack+0x16/0x18
[] print_usage_bug+0x107/0x114
[] mark_lock+0x1e9/0x400
[] __lock_acquire+0x4a4/0xbca
[] lock_acquire+0x76/0x9d
[] _spin_lock+0x23/0x32
[] rtl8139_interrupt+0x22/0x377 [8139too]
[] free_irq+0xc9/0xf2
[] rtl8139_close+0xac/0x14a [8139too]
[] dev_close+0x4e/0x6b
[] dev_change_flags+0x9f/0x152
[] devinet_ioctl+0x209/0x506
[] inet_ioctl+0x86/0xa4
[] sock_ioctl+0x1a9/0x1c7
[] do_ioctl+0x22/0x67
[] vfs_ioctl+0x249/0x25c
[] sys_ioctl+0x2c/0x45
[] sysenter_past_esp+0x6b/0xb5
===
eth2: link down
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[NFSD OOPS] 2.6.23-rc1-git10
Hi, Got the following oopsen just now from 2.6.23-rc1-git10 on a 2 processor Opteron with 2GB RAM. System is running 64bit Fedora Core 6. nfsd is exporting directories from a XFS filesystem on top a software RAID 5 array comprising 3 x 250GB SATA disks using the sata_sil driver. Amongst other things, users (about 12) home directories are automounted from it. Some problems seem to start when I was experimenting with the stripe_cache_size of the md array. People could no longer run some apps and having general NFS issues. IIRC I had dropped the stripe_cache_size down from 8192 to 768 then I attempted to restart nfsd via /etc/rc.d/init.d/nfsd restart I then got the Oopses and the machine locked up needing a power cycle. Aug 2 10:15:55 thor mountd[30048]: Caught signal 15, un-registering and exiting. Aug 2 10:15:55 thor nfsd[16390]: nfssvc: Setting version failed: errno 16 (Device or resource busy) Aug 2 10:15:56 thor kernel: lockd_down: lockd failed to exit, clearing pid Aug 2 10:15:56 thor kernel: nfsd: last server has exited Aug 2 10:15:56 thor kernel: nfsd: unexporting all filesystems Aug 2 10:15:56 thor kernel: [ cut here ] Aug 2 10:15:56 thor kernel: kernel BUG at /home/andrew/src/linux-2.6/net/sunrpc/svc.c:488! Aug 2 10:15:56 thor kernel: invalid opcode: [1] SMP Aug 2 10:15:56 thor kernel: CPU 0 Aug 2 10:15:56 thor kernel: Pid: 30039, comm: nfsd Not tainted 2.6.23-rc1-git10 #28 Aug 2 10:15:56 thor kernel: RIP: 0010:[] [] svc_destroy+0x1bd/0x1d0 Aug 2 10:15:56 thor kernel: RSP: 0018:81007a149ee0 EFLAGS: 00010212 Aug 2 10:15:56 thor kernel: RAX: 81006fd4f4a8 RBX: 81006fd4f498 RCX: 8100c000 Aug 2 10:15:56 thor kernel: RDX: 81006fd4f498 RSI: 004c RDI: 81006fd4f498 Aug 2 10:15:56 thor kernel: RBP: 81006fd4f4b8 R08: 9018 R09: 8000 Aug 2 10:15:56 thor kernel: R10: R11: 80453990 R12: 81006fd4f4a8 Aug 2 10:15:56 thor kernel: R13: 81006fd4f480 R14: 81006fd4f480 R15: 802dc000 Aug 2 10:15:56 thor kernel: FS: 2affe30536e0() GS:805be000() knlGS: Aug 2 10:15:56 thor kernel: CS: 0010 DS: ES: CR0: 8005003b Aug 2 10:15:56 thor kernel: CR2: 00345ce03080 CR3: 6fd65000 CR4: 06e0 Aug 2 10:15:56 thor kernel: DR0: DR1: DR2: Aug 2 10:15:56 thor kernel: DR3: DR6: 0ff0 DR7: 0400 Aug 2 10:15:56 thor kernel: Process nfsd (pid: 30039, threadinfo 81007a148000, task 810062fe77b0) Aug 2 10:15:56 thor kernel: Stack: 810062fe77b0 001e 81007a0c2000 81007a149f20 Aug 2 10:15:56 thor kernel: 810070eedf80 802dc268 feff 6e692e6c6363702e Aug 2 10:15:56 thor kernel: fef8 810062fe77b0 810070eedf84 Aug 2 10:15:56 thor kernel: Call Trace: Aug 2 10:15:56 thor kernel: [] nfsd+0x268/0x2d0 Aug 2 10:15:56 thor kernel: [] child_rip+0xa/0x12 Aug 2 10:15:56 thor kernel: [] nfsd+0x0/0x2d0 Aug 2 10:15:56 thor kernel: [] nfsd+0x0/0x2d0 Aug 2 10:15:56 thor kernel: [] child_rip+0x0/0x12 Aug 2 10:15:56 thor kernel: Aug 2 10:15:56 thor kernel: Aug 2 10:15:56 thor kernel: Code: 0f 0b eb fe 0f 1f 80 00 00 00 00 0f 1f 84 00 00 00 00 00 41 Aug 2 10:15:56 thor kernel: RIP [] svc_destroy+0x1bd/0x1d0 Aug 2 10:15:56 thor kernel: RSP Aug 2 10:16:17 thor kernel: general protection fault: [2] SMP Aug 2 10:16:17 thor kernel: CPU 0 Aug 2 10:16:17 thor kernel: Pid: 16406, comm: nfsd Tainted: G D 2.6.23-rc1-git10 #28 Aug 2 10:16:17 thor kernel: RIP: 0010:[] [] nfsd_vfs_read+0x13e/0x450 Aug 2 10:16:17 thor kernel: RSP: 0018:8100496ffd60 EFLAGS: 00010202 Aug 2 10:16:17 thor kernel: RAX: 3b5f0767 RBX: 0100 RCX: 81007a579340 Aug 2 10:16:17 thor kernel: RDX: 0001 RSI: RDI: 80649f48 Aug 2 10:16:17 thor kernel: RBP: 80649f40 R08: 8100149d0990 R09: 0007 Aug 2 10:16:17 thor kernel: R10: 5245544e R11: 0001 R12: 495f594157455441 Aug 2 10:16:17 thor kernel: R13: 18328d3e R14: 0004 R15: 810065dc66c0 Aug 2 10:16:17 thor kernel: FS: 2b83155a86e0() GS:805be000() knlGS: Aug 2 10:16:17 thor kernel: CS: 0010 DS: ES: CR0: 8005003b Aug 2 10:16:17 thor kernel: CR2: 00345c495890 CR3: 7b2c1000 CR4: 06e0 Aug 2 10:16:17 thor kernel: DR0: DR1: DR2: Aug 2 10:16:17 thor kernel: DR3: DR6: 0ff0 DR7: 0400 Aug 2 10:16:17 thor kernel: Process nfsd (pid: 16406, threadinfo 8100496fe000, task 81007e1310c0) Aug 2 10:16:17 thor kernel: Stack: 8100704f9b68 00078034eee8
Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes
On Fri, 3 Aug 2007, Matthew Garrett wrote: > On Thu, Aug 02, 2007 at 06:15:05PM -0700, Greg KH wrote: > > > Well, if you do this, then you can pretty much delete the whole quirk > > table we have, right? > > At the moment, yes. > > > And personally, I want to do better than Windows XP when it comes to > > power management. This patch is only going to suspend a very tiny > > subset of devices, including a whole bunch of ones that do not even have > > drivers in Linux, causing our power footprint to be bigger than needed. > > I agree. I'd much rather see us suspending devices whenever possible - > it's just that I have concerns over the scalability of the blacklist, > given the number of devices that seem to have issues. While I agree in general, perhaps a different approach would work better. For instance, we could blacklist a few known-bad device classes (maybe even using the existing blacklist) rather than whitelisting a few known-good ones -- or trying to blacklist each member of the bad classes! Also, building something this sweeping into a kernel driver feels like a mistake. It ought to be more easily configurable from userspace, say via a sysfs file. Although this wouldn't be so important if we take the blacklist-classes route. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mtd: Makefile fix (was Re: [PATCH] mtdsuper: licensce = GPL)
Hi,
On Thu, 2 Aug 2007, Rafał Bilski wrote:
> [...]
> CC drivers/mtd/chips/chipreg.mod.o
> LD [M] drivers/mtd/chips/chipreg.ko
> CC drivers/mtd/devices/block2mtd.mod.o
> LD [M] drivers/mtd/devices/block2mtd.ko
> CC drivers/mtd/mtd_blkdevs.mod.o
> LD [M] drivers/mtd/mtd_blkdevs.ko
> CC drivers/mtd/mtdblock.mod.o
> LD [M] drivers/mtd/mtdblock.ko
> CC drivers/mtd/mtdchar.mod.o
> LD [M] drivers/mtd/mtdchar.ko
> CC drivers/mtd/mtdcore.mod.o
> LD [M] drivers/mtd/mtdcore.ko
> CC drivers/mtd/mtdsuper.mod.o
> LD [M] drivers/mtd/mtdsuper.ko
>
> % ls *.ko
> mtd_blkdevs.ko mtdblock.ko mtdchar.ko mtdcore.ko mtdsuper.ko
Yup, I end up with the above situation myself. Please try the patch
below.
David, are mtdcore, mtdsuper, mtdpart (and I also noticed mtdbdi.c
in -mm kernel) supposed to be linked into the same module or are they
supposed to be built as separate modules?
If separate, we need to apply Rafal's patch and ensure MODULE_LICENSE
(at least) in all the above files.
If the same module, then please consider applying the patch below.
[PATCH] mtd: Makefile fix
We want drivers/mtd/{mtdcore, mtdsuper, mtdpart}.c to be built and linked
into the same mtd.ko module. Fix the Makefile to ensure this, and remove
duplicate MODULE_ declarations in mtdpart.c, as mtdcore.c already has them.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/mtd/Makefile |2 +-
drivers/mtd/mtdpart.c |4
2 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 451adcc..6d958a4 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -3,9 +3,9 @@
#
# Core functionality.
+obj-$(CONFIG_MTD) += mtd.o
mtd-y := mtdcore.o mtdsuper.o
mtd-$(CONFIG_MTD_PARTITIONS) += mtdpart.o
-obj-$(CONFIG_MTD) += $(mtd-y)
obj-$(CONFIG_MTD_CONCAT) += mtdconcat.o
obj-$(CONFIG_MTD_REDBOOT_PARTS) += redboot.o
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 9c62368..6174a97 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -560,7 +560,3 @@ int parse_mtd_partitions(struct mtd_info *master, const
char **types,
EXPORT_SYMBOL_GPL(parse_mtd_partitions);
EXPORT_SYMBOL_GPL(register_mtd_parser);
EXPORT_SYMBOL_GPL(deregister_mtd_parser);
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Nicolas Pitre <[EMAIL PROTECTED]>");
-MODULE_DESCRIPTION("Generic support for partitioning of MTD devices");
Re: [PATCH] retrieve VBE EDID/DDC info independent of used video mode
Antonino A. Daplas wrote: How about this patch? Tony --- Subject: video setup: Fix VBE DDC reading Add memory operand constraint and write-only modifier to the inline assembly to effect the writing of the EDID block to boot_params.edid_info. Thanks, this patch works in that Linux now reports the correct resolution. However, the TV output is now scrambled... I suspect this might be a result of adding CONFIG_FRAMEBUFFER_CONSOLE in the most recent tests. I've asked the user to test without that option but with the patch: https://bugs.gentoo.org/show_bug.cgi?id=181067#c27 Thanks! Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rpc.mountd crashes when extensively using netgroups
Hi,
On Thu, 2 Aug 2007, Stefan Walter wrote:
> Steve Dickson wrote:
> > Stefan Walter wrote:
> >>
> >> We do this on a much larger scale though. The bug we ran into is
> >> in line 96 in utils/mountd/auth.c. The strcpy can corrupt
> >> memory when it copies the string returned by client_compose() to
> >> my_client.m_hostname which has a fixed size of 1024 bytes. For our
> >> example above, client_compose() returns "@joe,@jane"
> >> for any machine in the offices_1 netgroup. Unfortunately we have
> >> a machine to which roughly 150 netgroups like @joe or @jane
>> export to and client_compose() returns a string over 1300 bytes
> >> long and rpc.mountd nicely segfaults.
> >>
> >> To prevent the crash is of course trivial: Inserting a simple
> >> 'if (strlen(n) > 1024) return NULL;' before line 96 does the job.
> > Does the attached patch help?
> >
> rpc.mountd does not crash anymore but I get a 'permission denied' when
> trying
> to mount a share. Doing an 'strace rpc.mountd -F' reveals:
>
> ...
> open("/proc/net/rpc/auth.unix.ip/channel", O_WRONLY|O_CREAT|O_TRUNC,
> 0666) = 9
> fstat64(9, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7f41000
> time(NULL) = 1186041882
> write(9, "nfsd 129.132.10.33 1186043682 @a"..., 1024) = -1 EINVAL
> (Invalid argument)
> write(9, "\n", 1) = -1 EINVAL (Invalid argument)
> close(9)= 0
> munmap(0xb7f41000, 4096)= 0
> open("/proc/net/rpc/nfsd.export/channel", O_WRONLY|O_CREAT|O_TRUNC,
> 0666) = 9
> fstat64(9, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7f41000
> write(9, "@anbuehle,@anhorni,@antoinet,@ap"..., 1024) = -1 EINVAL
> (Invalid argument)
> time(NULL) = 1186041882
> write(9, "/export/groups/grossm/h1/home/gr"..., 68) = -1 ENOENT (No such
> file or directory)
> close(9)= 0
> munmap(0xb7f41000, 4096)= 0
> open("/proc/fs/nfsd/filehandle", O_RDWR) = 9
> fstat64(9, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7f41000
> write(9, "@anbuehle,@anhorni,@antoinet,@ap"..., 1066) = -1 EPERM
> (Operation not permitted)
> ...
Yup, the snprintf() in the patch would've truncated the input string.
Steve (D), you should check the return of snprintf() and compare against
the size specified (NFSCLNT_IDMAX+1) and do a graceful cleanup + print
an error message to the user, when detecting truncation of input:
err = snprintf(my_client.m_hostname, (NFSCLNT_IDMAX+1), "%s", *n?n:"DEFAULT");
if (err >= (NFSCLNT_IDMAX+1)) {
printf("too large input string ...\n");
/* cleanups and graceful exit */
}
Sorry, I don't have rpc.mountd sources nearby, so cannot make a patch
myself (I'm an exclusively kernel guy :-)
Thanks,
Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: blackfin toolchain and build issues
On Thu, 2007-08-02 at 21:44 +0200, Sam Ravnborg wrote: > > > > > Oh, do you need use blackfin toolchain? Actually, it is very simple to > > setup it on your machine. > > please get the latest binary toolchain here: > > http://blackfin.uclinux.org/gf/download/frsrelease/344/3180/blackfin-toolchain-uclinux-SVN.tar.bz2 > > http://blackfin.uclinux.org/gf/download/frsrelease/344/3181/blackfin-toolchain-linux-uclibc-SVN.tar.bz2 > > Thanks - installed. > > While building latest git tree I see several 'funny' errors. > LD kernel/built-in.o > bfin-linux-uclibc-ld: Warning: size of symbol `_sys_futex' changed from 4 in > kernel/sys_ni.o to 262 in kernel/futex.o > bfin-linux-uclibc-ld: Warning: size of symbol `_sys_set_robust_list' changed > from 4 in kernel/sys_ni.o to 30 in kernel/futex.o > bfin-linux-uclibc-ld: Warning: size of symbol `_sys_get_robust_list' changed > from 4 in kernel/sys_ni.o to 170 in kernel/futex.o > bfin-linux-uclibc-ld: Warning: size of symbol `_sys_setfsgid16' changed from > 4 in kernel/sys_ni.o to 16 in kernel/uid16.o > bfin-linux-uclibc-ld: Warning: size of symbol `_sys_setfsuid16' changed from > 4 in kernel/sys_ni.o to 16 in kernel/uid16.o > bfin-linux-uclibc-ld: Warning: size of symbol `_sys_setresgid16' changed from > 4 in kernel/sys_ni.o to 36 in kernel/uid16.o > bfin-linux-uclibc-ld: Warning: size of symbol `_sys_setresuid16' changed from > 4 in kernel/sys_ni.o to 36 in kernel/uid16.o > bfin-linux-uclibc-ld: Warning: size of symbol `_sys_setuid16' changed from 4 > in kernel/sys_ni.o to 16 in kernel/uid16.o > bfin-linux-uclibc-ld: Warning: size of symbol `_sys_setreuid16' changed from > 4 in kernel/sys_ni.o to 26 in kernel/uid16.o > ... > > and later: > > LD .tmp_vmlinux1 > bfin-linux-uclibc-ld: Warning: size of symbol `_sys_mremap' changed from 4 in > kernel/built-in.o to 82 in mm/built-in.o > bfin-linux-uclibc-ld: Warning: size of symbol `_sys_ioprio_set' changed from > 4 in kernel/built-in.o to 362 in fs/built-in.o > bfin-linux-uclibc-ld: Warning: size of symbol `_sys_epoll_wait' changed from > 4 in kernel/built-in.o to 1002 in fs/built-in.o > bfin-linux-uclibc-ld: Warning: size of symbol `_sys_timerfd' changed from 4 > in kernel/built-in.o to 346 in fs/built-in.o > bfin-linux-uclibc-ld: Warning: size of symbol `_sys_ioprio_get' changed from > 4 in kernel/built-in.o to 344 in fs/built-in.o > > I will check this on my side ASAP. But the git-tree did not merge my "fs.h" header file patch, how could it compiled passed like this? > > I did not look into these. I assume it is a toolchain issue?? > > PS. I had to fix a few things to get so far but as I did not do > it the right way I have no patch. > > Sam Thanks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: eurotechwdt will cause reboot
>On 8/1/07, Dave Young <[EMAIL PROTECTED]> wrote: > >On 8/1/07, Wim Van Sebroeck <[EMAIL PROTECTED]> wrote: > > Hi Dave, > > > > > config eurotechwdt to yes will cause system silent reboot. Is it right > > > behaviour or a bug? > > > > I think this might be a bug. I'll look at the code and will ask you to do > > some > > tests for me (if that is ok for you). > > > I'm ok for me. BTW, the rebooting is too quick that I have to set the > boot_delay command line parameter to see it. > Hi, News: 2.6.23-rc1-mm1 will reboot with eurotechwdt, but 2.6.23-rc1-mm2 will not. do you need the config files? I will concentrate on this problem as well. Any hints how to debug? I add andrew to cc. Regards dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 usb-u132-hcd.c-fix-a-warning-when-config_pm-n.patch added to gregkh-2.6 tree
This is a note to let you know that I've just added the patch titled
Subject: USB: u132-hcd.c - Fix a warning when CONFIG_PM=n
to my gregkh-2.6 tree. Its filename is
usb-u132-hcd.c-fix-a-warning-when-config_pm-n.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
>From [EMAIL PROTECTED] Thu Aug 2 18:39:02 2007
From: Gabriel C <[EMAIL PROTECTED]>
Date: Mon, 30 Jul 2007 12:57:03 +0200
Subject: USB: u132-hcd.c - Fix a warning when CONFIG_PM=n
To: Linux Kernel Mailing List
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
I noticed this warning with CONFING_PM=n
...
drivers/usb/host/u132-hcd.c:1525: warning: 'port_power' defined but not used
...
Signed-off-by: Gabriel Craciunescu <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/host/u132-hcd.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/host/u132-hcd.c
+++ b/drivers/usb/host/u132-hcd.c
@@ -1519,12 +1519,15 @@ static void u132_hcd_endp_work_scheduler
}
}
}
+#ifdef CONFIG_PM
static void port_power(struct u132 *u132, int pn, int is_on)
{
u132->port[pn].power = is_on;
}
+#endif
+
static void u132_power(struct u132 *u132, int is_on)
{
struct usb_hcd *hcd = u132_to_hcd(u132)
Patches currently in gregkh-2.6 which might be from [EMAIL PROTECTED] are
usb/usb-u132-hcd.c-fix-a-warning-when-config_pm-n.patch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] USB: Only enable autosuspend by default on certain device classes
On Thu, Aug 02, 2007 at 06:15:05PM -0700, Greg KH wrote: > Well, if you do this, then you can pretty much delete the whole quirk > table we have, right? At the moment, yes. > And personally, I want to do better than Windows XP when it comes to > power management. This patch is only going to suspend a very tiny > subset of devices, including a whole bunch of ones that do not even have > drivers in Linux, causing our power footprint to be bigger than needed. I agree. I'd much rather see us suspending devices whenever possible - it's just that I have concerns over the scalability of the blacklist, given the number of devices that seem to have issues. > Also, we have udev rules for SANE that disables their autosuspend > settings, which handles the majority of the devices we have seen with > problems. Several printers seem to have the issue as well, and the blacklist seems to contain some odd miscellaneous devices like the Blackberry. The main concern I have is that kernel developers just don't tend to be the sort of people that use webcams, printers or scanners, so we're relying on normal users to go to the effort of reporting that their device has stopped working. > So I really don't want to accept this patch. But, what problems are you > seeing with our current suspend logic that you feel we need to be this > harsh? It's definitely a brute force approach, but it's one that means that we get the low hanging fruit (ie, pretty much anything that's likely to be plugged into a laptop) while massively reducing the probability of breaking anyone's system. Saving some power is a nice win, but breaking someone's printer is a pretty big loss. -- Matthew Garrett | [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: [rfc] balance-on-fork NUMA placement
On Fri, 3 Aug 2007, Nick Piggin wrote: > Yeah it only gets set if the parent is initially using a default policy > at this stage (and then is restored afterwards of course). Uggh. Looks like more hackery ahead. I think this cannot be done in the desired clean way until we have some revving of the memory policy subsystem that makes policies task context independent so that you can do alloc_pages(, memory_policy) The cleanest solution that I can think of at this point is certainly to switch to another processor and do the allocation and copying actions from there. We have the migration process context right? Can that be used to start the new thread and can the original processor wait on some flag until that is complete? Forking off from there not only places the data correctly but it also warms up the caches for the new process and avoids evicting cacheline on the original processor. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problem with USB Gadget Filesystem
Hi, everyone. Now I'm developing USB Mass Storage App with GadgetFS(drivers/usb/gadget/inode.c). (linux kernel version is 2.6.17. We ported it to arm(s5c7329). The target board is now FPGA board. USB chip is 3884-0 DWC USB 2.0 HS OTG of Synopsys.) But, when plug in USB to Desktop PC(Win xp pro), kernel panic occur. The panic messages are like below. How can I debug like this panic? Or is there anybody to tell me about below situation? complete_ep :complete_ep :read_packet complete_ep :complete_ep :read_packet complete_ep :complete_ep :read_packet complete_ep :<1>Unable to handle kernel NULL pointer dereference at virtual add4 pgd = c5f24000 [0004] *pgd=256a2031, *pte=, *ppte= Internal error: Oops: 17 [#1] Modules linked in: CPU: 0 PC is at kfree+0x50/0x9c LR is at ep_read+0xd8/0x16c pc : []lr : []Not tainted sp : c566ff1c ip : c566ff38 fp : c566ff34 r10: 40037000 r9 : c566e000 r8 : 001f r7 : c027f940 r6 : a013 r5 : c027f940 r4 : 0004 r3 : 0080 r2 : c018ec30 r1 : c0198fe0 r0 : c01930c0 Flags: nZcv IRQs off FIQs on Mode SVC_32 Segment user Control: 5317F Table: 25F24000 DAC: 0015 Process ums (pid: 133, stack limit = 0xc566e198) Stack: (0xc566ff1c to 0xc567) ff00:001f ff20: c17b4460 0003c4da c566ff58 c566ff38 c0126324 c0066814 c02a8580 0003c4da ff40: c566e000 c012624c c566ff80 c566ff7c c566ff5c c006ae9c c012625c ff60: c02a8580 0003 c001af84 c566ffa4 c566ff80 c006b194 c006ae00 ff80: 0001 bddffbe0 c004 c566ffa8 ffa0: c001ade0 c006b154 bddffbe0 0007 0003c4da 001f 0001 ffc0: bddffbe0 c004 001ff000 0004 bdc01000 40037000 bddff9ec ffe0: bddff9bc 4002ca30 4002ca44 6010 0007 Backtrace: [] (kfree+0x0/0x9c) from [] (ep_read+0xd8/0x16c) r6 = 0003C4DA r5 = C17B4460 r4 = 001F [] (ep_read+0x0/0x16c) from [] (vfs_read+0xac/0x124) r8 = C566FF80 r7 = C012624C r6 = C566E000 r5 = 0003C4DA r4 = C02A8580 [] (vfs_read+0x0/0x124) from [] (sys_read+0x50/0x88) r8 = C001AF84 r7 = 0003 r6 = C02A8580 r5 = r4 = [] (sys_read+0x0/0x88) from [] (ret_fast_syscall+0x0/0x2c) r6 = C004 r5 = BDDFFBE0 r4 = Code: e3130901 1591100c e5910018 e5904000 (e5943000) <1>Unable to handle kernel NULL pointer dereference at virtual address 0004 pgd = c0004000 [0004] *pgd= Internal error: Oops: 17 [#2] Modules linked in: CPU: 0 PC is at drain_array+0x18/0xd0 LR is at cache_reap+0x68/0x1f0 pc : []lr : []Not tainted sp : c17d5efc ip : c17d5f18 fp : c17d5f14 r10: r9 : r8 : c0280770 r7 : c0193108 r6 : c01930c0 r5 : 0001 r4 : 0004 r3 : r2 : 0004 r1 : r0 : c01930c0 Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment kernel Control: 5317F Table: 25F24000 DAC: 0017 Process events/0 (pid: 3, stack limit = 0xc17d4198) Stack: (0xc17d5efc to 0xc17d6000) 5ee0:c027e860 5f00: 0001 c01930c0 c17d5f48 c17d5f18 c0068420 c0066b20 c012ea38 5f20: c02806a0 8013 c00683b8 c02806a8 c02806a0 c17d5f88 c17d5f68 5f40: c17d5f4c c0040db4 c00683c8 c02806b0 c02806a8 c17d5f98 c17d4000 c17d5fc0 5f60: c17d5f6c c0040f44 c0040d30 0001 c002cd64 5f80: 0001 c028f7c0 c002cd64 00100100 00200200 c0040e30 5fa0: c17d4000 fffc c0297efc c02806a0 0001 c17d5ff4 c17d5fc4 c004494c 5fc0: c0040e40 0001 5fe0: c17d5ff8 c0032c08 c0044854 Backtrace: [] (drain_array+0x0/0xd0) from [] (cache_reap+0x68/0x1f0) r6 = C01930C0 r5 = 0001 r4 = C027E860 [] (cache_reap+0x0/0x1f0) from [] (run_workqueue+0x94/0x110) [] (run_workqueue+0x0/0x110) from [] (worker_thread+0x114/0) r7 = C17D4000 r6 = C17D5F98 r5 = C02806A8 r4 = C02806B0 [] (worker_thread+0x0/0x158) from [] (kthread+0x108/0x134) [] (kthread+0x0/0x134) from [] (do_exit+0x0/0x894) Code: e24cb004 e2524000 e1a01003 089da870 (e5943000) ==> gadgetfs event 3 [Info]: UMS_CONNECT==> gadgetfs event 3 [Info]: UMS_CONNECT==> gadgetfs event 3 [Info]: UMS_CONNECT==> gadgetfs event 3 [Info]: UMS_CONNECT==> gadgetfs event 3 [Info]: UMS_CONNECT==> gadgetfs event 3 [Info]: UMS_CONNECT==> gadgetfs event 3 [Info]: UMS_CONNECT==> gadgetfs event 3 [Info]: UMS_CONNECT==> gadgetfs event 3 [Info]: UMS_CONNECT==> gadgetfs event 3 [Info]: UMS_CONNECT==> gadgetfs event 3 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] balance-on-fork NUMA placement
On Thu, Aug 02, 2007 at 06:02:56PM -0700, Christoph Lameter wrote: > On Fri, 3 Aug 2007, Nick Piggin wrote: > > > > Ok. So MPOL_BIND on a single node. We would have to save the current > > > memory policy on the stack and then restore it later. Then you would need > > > a special call anyways. > > > > Well the memory policy will already be set to MPOL_BIND at this point. > > The slab allocator I think would just have to honour the node at the > > object level. > > Who set the policy? The parent process may have its own memory policy. If > you set that then the earlier policy is lost. Yeah it only gets set if the parent is initially using a default policy at this stage (and then is restored afterwards of course). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] USB: Only enable autosuspend by default on certain device classes
On Fri, Aug 03, 2007 at 12:56:13AM +0100, Matthew Garrett wrote: > We're seeing a large number of problems with devices not appreciating > USB autosuspend, especially printers and scanners. According to > http://www.microsoft.com/whdc/system/bus/USB/USBFAQ_intro.mspx only a > subset of drivers support it in Windows XP, meaning that most devices > are probably untested in this situation. This patch alters the behaviour > to match that of Windows. Userspace can still whitelist devices as > appropriate, and the set of classes supporting autosuspend probably > covers pretty much every driver likely to be found on any portable > device. > > Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]> Well, if you do this, then you can pretty much delete the whole quirk table we have, right? And personally, I want to do better than Windows XP when it comes to power management. This patch is only going to suspend a very tiny subset of devices, including a whole bunch of ones that do not even have drivers in Linux, causing our power footprint to be bigger than needed. Also, we have udev rules for SANE that disables their autosuspend settings, which handles the majority of the devices we have seen with problems. So I really don't want to accept this patch. But, what problems are you seeing with our current suspend logic that you feel we need to be this harsh? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] balance-on-fork NUMA placement
On Fri, 3 Aug 2007, Nick Piggin wrote: > > Ok. So MPOL_BIND on a single node. We would have to save the current > > memory policy on the stack and then restore it later. Then you would need > > a special call anyways. > > Well the memory policy will already be set to MPOL_BIND at this point. > The slab allocator I think would just have to honour the node at the > object level. Who set the policy? The parent process may have its own memory policy. If you set that then the earlier policy is lost. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] balance-on-fork NUMA placement
On Thu, Aug 02, 2007 at 05:52:28PM -0700, Christoph Lameter wrote: > On Fri, 3 Aug 2007, Nick Piggin wrote: > > > > Add a (slow) kmalloc_policy? Strict Object round robin for interleave > > > right? It probably needs its own RR counter otherwise it disturbs the per > > > task page RR. > > > > I guess interleave could be nice for other things, but for this, I > > just want MPOL_BIND to work. The problem is that the pagetable copying > > etc codepaths cover a lot of code and some of it (eg pagetable allocation) > > is used for other paths as well.. so I was just hoping to do something > > less intrusive for now if possible. > > Ok. So MPOL_BIND on a single node. We would have to save the current > memory policy on the stack and then restore it later. Then you would need > a special call anyways. Well the memory policy will already be set to MPOL_BIND at this point. The slab allocator I think would just have to honour the node at the object level. > Or is there some way to execute the code on the target cpu? That may be > the easiest solution. It isn't so easy... we'd have to migrate the parent process to the new node to perform the setup, and then migrate it back again afterwards. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] balance-on-fork NUMA placement
On Fri, 3 Aug 2007, Nick Piggin wrote: > > Add a (slow) kmalloc_policy? Strict Object round robin for interleave > > right? It probably needs its own RR counter otherwise it disturbs the per > > task page RR. > > I guess interleave could be nice for other things, but for this, I > just want MPOL_BIND to work. The problem is that the pagetable copying > etc codepaths cover a lot of code and some of it (eg pagetable allocation) > is used for other paths as well.. so I was just hoping to do something > less intrusive for now if possible. Ok. So MPOL_BIND on a single node. We would have to save the current memory policy on the stack and then restore it later. Then you would need a special call anyways. Or is there some way to execute the code on the target cpu? That may be the easiest solution. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Fix two potential mem leaks in MPT Fusion (mpt_attach())
Mempools do not want to wait if there is an allocation failure. Its like GFP_THISNODE in that we want a failure. I had to add a if (NUMA_BUILD && (gfp_mask & GFP_THISNODE) == GFP_THISNODE) goto nopage; in page_alloc.c to make GFP_THISNODE fail. Maybe add a GFP_FAIL and check for that? diff --git a/include/linux/gfp.h b/include/linux/gfp.h index bc68dd9..41b6aa3 100644 --- a/include/linux/gfp.h +++ b/include/linux/gfp.h @@ -43,6 +43,7 @@ struct vm_area_struct; #define __GFP_REPEAT ((__force gfp_t)0x400u) /* Retry the allocation. Might fail */ #define __GFP_NOFAIL ((__force gfp_t)0x800u) /* Retry for ever. Cannot fail */ #define __GFP_NORETRY ((__force gfp_t)0x1000u)/* Do not retry. Might fail */ +#define __GFP_FAIL ((__force gfp_t)0x2000u)/* Fail immediately if there is a problem */ #define __GFP_COMP ((__force gfp_t)0x4000u)/* Add compound page metadata */ #define __GFP_ZERO ((__force gfp_t)0x8000u)/* Return zeroed page on success */ #define __GFP_NOMEMALLOC ((__force gfp_t)0x1u) /* Don't use emergency reserves */ @@ -81,7 +82,8 @@ struct vm_area_struct; __GFP_MOVABLE) #ifdef CONFIG_NUMA -#define GFP_THISNODE (__GFP_THISNODE | __GFP_NOWARN | __GFP_NORETRY) +#define GFP_THISNODE (__GFP_THISNODE | __GFP_NOWARN | __GFP_NORETRY |\ + __GFP_FAIL) #else #define GFP_THISNODE ((__force gfp_t)0) #endif diff --git a/mm/mempool.c b/mm/mempool.c index 02d5ec3..c1ac622 100644 --- a/mm/mempool.c +++ b/mm/mempool.c @@ -211,8 +211,9 @@ void * mempool_alloc(mempool_t *pool, gfp_t gfp_mask) gfp_mask |= __GFP_NOMEMALLOC; /* don't allocate emergency reserves */ gfp_mask |= __GFP_NORETRY; /* don't loop in __alloc_pages */ gfp_mask |= __GFP_NOWARN; /* failures are OK */ + gfp_mask |= __GFP_FAIL; - gfp_temp = gfp_mask & ~(__GFP_WAIT|__GFP_IO); + gfp_temp = gfp_mask & ~__GFP_IO; repeat_alloc: diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 3da85b8..58c1a4d 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1250,15 +1250,7 @@ restart: if (page) goto got_pg; - /* -* GFP_THISNODE (meaning __GFP_THISNODE, __GFP_NORETRY and -* __GFP_NOWARN set) should not cause reclaim since the subsystem -* (f.e. slab) using GFP_THISNODE may choose to trigger reclaim -* using a larger set of nodes after it has established that the -* allowed per node queues are empty and that nodes are -* over allocated. -*/ - if (NUMA_BUILD && (gfp_mask & GFP_THISNODE) == GFP_THISNODE) + if (gfp_mask & __GFP_FAIL) goto nopage; for (z = zonelist->zones; *z; z++) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] balance-on-fork NUMA placement
On Thu, Aug 02, 2007 at 12:58:13PM -0700, Christoph Lameter wrote: > On Thu, 2 Aug 2007, Nick Piggin wrote: > > > > It does in the sense that slabs are allocated following policies. If you > > > want to place individual objects then you need to use kmalloc_node(). > > > > Is there no way to place objects via policy? At least kernel stack and page > > tables on x86-64 should be covered by page allocator policy, so the patch > > will still be useful. > > Implementing policies on an object level introduces significant allocator > overhead. Tried to do it in SLAB which created a mess. > > Add a (slow) kmalloc_policy? Strict Object round robin for interleave > right? It probably needs its own RR counter otherwise it disturbs the per > task page RR. I guess interleave could be nice for other things, but for this, I just want MPOL_BIND to work. The problem is that the pagetable copying etc codepaths cover a lot of code and some of it (eg pagetable allocation) is used for other paths as well.. so I was just hoping to do something less intrusive for now if possible. > For interleave kmalloc() does allocate the slabs round robin not the > objects. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.23-rc1-mm1 - fix missing numa_zonelist_order sysctl
On Thu, 02 Aug 2007 11:07:38 -0400 Lee Schermerhorn <[EMAIL PROTECTED]> wrote: > Of course, I don't have any idea of what is a "reasonable amount". > Guess I could look at non-movable zone memory usage in a system at > typical or peak load to get an idea. Anyone have any data in this > regard? > I'm sorry that I have no data and idea. ZONE_MOVABLE is too young to be used under business workload... just I feel... Considering i686 which divides memory into NORMAL and HIGHMEM, it seems that 4G to 8G servers looks stable under various workload in my experience. Then, at least, 12.5% to 25% of "Total Memory - Hugepages" memory should be under ZONE_NORMAL. But this is from experience of 32bit/SMP :( Thanks, -Kame - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] balance-on-fork NUMA placement
On Thu, Aug 02, 2007 at 11:33:39AM -0700, Martin Bligh wrote: > Nick Piggin wrote: > >On Wed, Aug 01, 2007 at 03:52:11PM -0700, Martin Bligh wrote: > >>>And so forth. Initial forks will balance. If the children refuse to > >>>die, forks will continue to balance. If the parent starts seeing short > >>>lived children, fork()s will eventually start to stay local. > >>Fork without exec is much more rare than without. Optimising for > >>the uncommon case is the Wrong Thing to Do (tm). What we decided > > > >It's only the wrong thing to do if it hurts the common case too > >much. Considering we _already_ balance on exec, then adding another > >balance on fork is not going to introduce some order of magnitude > >problem -- at worst it would be 2x but it really isn't too slow > >anyway (at least nobody complained when we added it). > > > >One place where we found it helps is clone for threads. > > > >If we didn't do such a bad job at keeping tasks together with their > >local memory, then we might indeed reduce some of the balance-on-crap > >and increase the aggressiveness of periodic balancing. > > > >Considering we _already_ balance on fork/clone, I don't know what > >your argument is against this patch is? Doing the balance earlier > >and allocating more stuff on the local node is surely not a bad > >idea. > > I don't know who turned that on ;-( I suspect nobody bothered > actually measuring it at the time though, or used some crap > benchmark like stream to do so. It should get reverted. So you have numbers to show it hurts? I tested some things where it is not supposed to help, and it didn't make any difference. Nobody else noticed either. If the cost of doing the double balance is _really_ that painful, then we ccould skip balance-on-exec for domains with balance-on-fork set. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 patch] mm/migrate.c: cleanups
On Thu, 2 Aug 2007 11:43:21 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]> wrote: > On Thu, 2 Aug 2007, Yasunori Goto wrote: > > > But, this patch is the cause of compile error of memory unplug code of > > 2.6.23-rc1-mm2. It uses putback_lru_pages(). > > Don't make it static please... :-( > > Right. But Adrian insisted since it was currently not used upstream. > > So I guess you will have to revert this piece in your unplug code. > Okay, I'll take are. But I'm too busy in these days. Andrew, If you have to drop unplug patch set, please do. I'll rework all when I find time. Thanks, -Kame - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: lmbench ctxsw regression with CFS
On Thu, Aug 02, 2007 at 05:44:47PM +0200, Ingo Molnar wrote: > > * Nick Piggin <[EMAIL PROTECTED]> wrote: > > > > > > One thing to check out is whether the lmbench numbers are > > > > > "correct". Especially on SMP systems, the lmbench numbers are > > > > > actually *best* when the two processes run on the same CPU, even > > > > > though that's not really at all the best scheduling - it's just > > > > > that it artificially improves lmbench numbers because of the > > > > > close cache affinity for the pipe data structures. > > > > > > > > Yes, I bound them to a single core. > > > > > > could you send me the .config you used? > > > > Sure, attached... > > > > You don't see a regression? If not, then can you send me the .config > > you used? [...] > > i used your config to get a few numbers and to see what happens. Here's > the numbers of 10 consecutive "lat_ctx -s 0 2" runs: > > [ time in micro-seconds, smaller is better ] > > v2.6.22 v2.6.23-git v2.6.23-git+const-param > --- --- --- > 1.30 1.60 1.19 > 1.30 1.36 1.18 > 1.14 1.50 1.01 > 1.26 1.27 1.23 > 1.22 1.40 1.04 > 1.13 1.34 1.09 > 1.27 1.39 1.05 > 1.20 1.30 1.16 > 1.20 1.17 1.16 > 1.25 1.33 1.01 >- > avg: 1.22 1.36 (+11.3%) 1.11 (-10.3%) > min: 1.13 1.17 ( +3.5%) 1.01 (-11.8%) > max: 1.27 1.60 (+26.0%) 1.23 ( -3.2%) > > one reason for the extra overhead is the current tunability of CFS, but > that is not fundamental, it's caused by the many knobs that CFS has at > the moment. The const-tuning patch (attached below, results in the > rightmost column) changes those knobs to constants, allowing the > compiler to optimize the math better and reduce code size. (the code > movement in the patch makes up for most of its size, the change that it > does is simple otherwise.) [...] Oh good. Thanks for getting to the bottom of it. We have normally disliked too much runtime tunables in the scheduler, so I assume these are mostly going away or under a CONFIG option for 2.6.23? Or...? What CPU did you get these numbers on? Do the indirect calls hurt much on those without an indirect predictor? (I'll try running some tests). I must say that I don't really like the indirect calls a great deal, and they could be eliminated just with a couple of branches and direct calls. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: ck vs. cfs : realtime audio performance
Martin Steigerwald wrote: Am Donnerstag 02 August 2007 schrieb Martin Steigerwald: The tone I see on responses to posts that are CCed to LKML in my perception often is just completely and utterly awfully unfriendly. And often those responses actual include factual inaccuracies and preliminary assumptions as well. Is that how Linux Kernel Management Style is supposed to work? I hope not. [...] Well, if Carlo is not a Linux Kernel manager this comment of mine is inapprobiate. Sorry for that. I am not a kernel manager, just a simple Linux user. I'm very very sorry if I have hurt anyone in this thread. Thank you very much. Best Regards. Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: REGRESSION: serial_cs broken by 8250 changes
Andrew Morton wrote: On Thu, 02 Aug 2007 16:24:42 -0700 Yinghai Lu <[EMAIL PROTECTED]> wrote: Daniel Ritz wrote: commit 18a8bd949d6adb311ea816125ff65050df1f3f6e breaks serial_cs badly with an oops, completely killing PCMCIA. register_console() now calls console->early_setup(). which in case of 8250.c (the only user anyway) is serial8250_console_early_setup() which is __init, calling 8250_early.c:serial8250_find_port_for_earlycon() which is __init as well. boom. the changelog mentions SERIAL_PORT_DFNS removal which happens to be commit 7e92b4fc345f5b6f57585fbe5ffdb0f24d7c9b26. but this got reverted by commit 57d4810ea0d9ca58a7bcc1336607f0cede0a2abf. so i'd suggest to just revert the 8250 changes as well. rgds -daniel Is there any flag or sign that init code has been released? Nope. We could use that to prevent init code to be called after code is freed. If we can omit a function call without breaking anything then we shouldn't have been calling that function at all ;) It sounds like making serial8250_console_early_setup() and serial8250_find_port_for_earlycon() non-__init will fix this. yes, together update_console_cmdline in kernel/printk.c Daniel, can you test that in your setup? Thanks Yinghai Lu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] USB: Only enable autosuspend by default on certain device classes
We're seeing a large number of problems with devices not appreciating
USB autosuspend, especially printers and scanners. According to
http://www.microsoft.com/whdc/system/bus/USB/USBFAQ_intro.mspx only a
subset of drivers support it in Windows XP, meaning that most devices
are probably untested in this situation. This patch alters the behaviour
to match that of Windows. Userspace can still whitelist devices as
appropriate, and the set of classes supporting autosuspend probably
covers pretty much every driver likely to be found on any portable
device.
Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]>
---
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index caaa46f..12ba789 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1278,6 +1278,22 @@ int usb_new_device(struct usb_device *udev)
{
int err;
+#ifdef CONFIG_USB_SUSPEND
+ /* Disable autosuspend for most devices - Windows only enables it
+ for a small subset of classes, so most hardware hasn't been tested
+ with it. Userspace can always reenable at a later point */
+
+ switch (udev->descriptor.bDeviceClass) {
+ case USB_CLASS_HID:
+ case USB_CLASS_COMM:
+ case USB_CLASS_WIRELESS_CONTROLLER:
+ case USB_CLASS_HUB:
+ break;
+ default:
+ udev->autosuspend_disabled = 1;
+ }
+#endif
+
/* Determine quirks */
usb_detect_quirks(udev);
--
Matthew Garrett | [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: gcc fixed size char array initialization bug - known?
On Thu, Aug 02, 2007 at 09:55:51PM +0200, Guennadi Liakhovetski wrote: > I've run across the following gcc "feature": > > char c[4] = "01234"; > > gcc emits a nice warning > > warning: initializer-string for array of chars is too long > > But do a > > char c[4] = "0123"; > > and - a wonder - no warning. No warning with gcc 3.3.2, 3.3.5, 3.4.5, > 4.1.2. I was told 4.2.x does produce a warning. 4.2.x nor 4.3 doesn't warn either and it is correct not to warn about perfectly valid code. ISO C99 is very obvious in that the terminating '\0' (resp. L'\0') from the string literal is only added if there is room in the array or if the array has unknown size. Jakub - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: gcc fixed size char array initialization bug - known?
On 08/03/2007 01:26 AM, Guennadi Liakhovetski wrote: On Thu, 2 Aug 2007, Randy Dunlap wrote: C99 spec that Al referred you to (available for around US$18 as a pdf) says in 6.7.8, para. 14 (where Al said): "An array of character type may be initialized by a character string literal, optionally enclosed in braces. Successive characters of the character string literal (including the terminating null character if there is room or if the array is of unknown size) initialize the elements of the array." Wow... So, the terminating '\0' in the string constant IS "special" and "optional"... Ok, then, THIS does answer my question, THIS I can understand, and, ghm, accept... Thanks to all who tried to explain this to me and sorry it took so long... Ah come on, it would be great fun to now make the argument that that quoted bit doesn't actually say wat should happen when there's _no_ room for the terminating null character... Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: REGRESSION: serial_cs broken by 8250 changes
On Thu, 02 Aug 2007 16:24:42 -0700 Yinghai Lu <[EMAIL PROTECTED]> wrote: > Daniel Ritz wrote: > > commit 18a8bd949d6adb311ea816125ff65050df1f3f6e breaks serial_cs badly > > with an oops, completely killing PCMCIA. > > > > register_console() now calls console->early_setup(). which in case of > > 8250.c (the only user anyway) is serial8250_console_early_setup() > > which is __init, calling 8250_early.c:serial8250_find_port_for_earlycon() > > which is __init as well. boom. > > > > the changelog mentions SERIAL_PORT_DFNS removal which happens to be > > commit 7e92b4fc345f5b6f57585fbe5ffdb0f24d7c9b26. but this got reverted > > by commit 57d4810ea0d9ca58a7bcc1336607f0cede0a2abf. so i'd suggest to > > just revert the 8250 changes as well. > > > > rgds > > -daniel > > Is there any flag or sign that init code has been released? Nope. > We could use that to prevent init code to be called after code is freed. If we can omit a function call without breaking anything then we shouldn't have been calling that function at all ;) It sounds like making serial8250_console_early_setup() and serial8250_find_port_for_earlycon() non-__init will fix this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: gcc fixed size char array initialization bug - known?
On Fri, 3 Aug 2007, Al Viro wrote: > It doesn't change the fact that use of c[4] or strlen(c) or strcpy(..., c) > means nasal demon country for you. Haha, funny. You, certainly, may think whatever you want, I'm anyway greatful to you and to all the rest for the trouble you took to find THE quote that actually answers the question. Thanks Guennadi --- Guennadi Liakhovetski - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: gcc fixed size char array initialization bug - known?
Al Viro wrote:
> On Fri, Aug 03, 2007 at 12:51:16AM +0200, Guennadi Liakhovetski wrote:
>> On Fri, 3 Aug 2007, Stefan Richter wrote:
>>
>>> Guennadi Liakhovetski wrote:
with
char c[4] = "012345";
the compiler warns, but actually allocates a 6-byte long array...
>>> Off-topic here, but: sizeof c / sizeof *c == 4.
>> Don't think it is OT here - kernel depends on gcc. And, what I meant, is,
>> that gcc places all 7 (sorry, not 6 as I said above) characters in the
>> .rodata section of the compiled object file. Of course, it doesn't mean,
>> that c is 7 characters long.
>
> So gcc does that kind of recovery, after having warned you. Makes sense,
> as long as it's for ordinary variables (and not, say it, struct fields) -
> you get less likely runtime breakage on the undefined behaviour (e.g.
> passing c to string functions). So gcc has generated some padding between
> the global variables, that's all.
No, the fact that the full 012345\0 ends up in the object file is
apparently unrelated to what happens to the variable c...
> It doesn't change the fact that use of c[4] or strlen(c) or strcpy(..., c)
> means nasal demon country for you.
>
> Now, if gcc does that for similar situation with struct fields, you'd have
> a cause to complain.
...since only 0123 will get into c at runtime, i.e. a 4 bytes long array
without \0 appendix or other extraordinary padding.
#include
#include
int main()
{
char c[4] = "012345";
printf("%d %d _%s_\n", sizeof c / sizeof *c, strlen(c), c);
return 0;
}
$ ./a.out
4 8 _01230®¿_
$ strings a.out |grep 0123
012345
--
Stefan Richter
-=-=-=== =--- ---==
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, 2 Aug 2007, Randy Dunlap wrote: > C99 spec that Al referred you to (available for around US$18 as a pdf) > says in 6.7.8, para. 14 (where Al said): > > "An array of character type may be initialized by a character string literal, > optionally > enclosed in braces. Successive characters of the character string literal > (including the > terminating null character if there is room or if the array is of unknown > size) initialize the > elements of the array." Wow... So, the terminating '\0' in the string constant IS "special" and "optional"... Ok, then, THIS does answer my question, THIS I can understand, and, ghm, accept... Thanks to all who tried to explain this to me and sorry it took so long... Thanks Guennadi --- Guennadi Liakhovetski - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Fix two potential mem leaks in MPT Fusion (mpt_attach())
On 03/08/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Fri, 3 Aug 2007 01:10:02 +0200 > "Jesper Juhl" <[EMAIL PROTECTED]> wrote: > > > > > So, where do we go from here? > > > > > > Where I said ;) Add a new __GFP_ flag which suppresses the warning, add > > > that flag to known-to-be-OK callsites, such as mempool_alloc(). > > > > > Ok, I'll try to play around with this some more, try to filter out > > false positives and see what I'm left with (if anything - I'm pretty > > limited hardware-wise, so I can only test a small subset of drivers, > > archs etc) - I'll keep you informed, but expect a few days to pass > > before I have any news... > > Make it a once-off thing for now, so the warning will disable itself after > it has triggered once. That will prevent the debug feature from making > anyone's kernel unusable. > Ok, I'll do that :-) Just be a little patient. I'm doing this in my spare time and I do have a real job/life to attend to, so I'll be playing with this in the little free time I have over the next couple of days. I'll get something done, but don't expect it until a few days have passed :-) -- 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/
Re: CFS review
Hi, On Wed, 1 Aug 2007, Linus Torvalds wrote: > So I think it would be entirely appropriate to > > - do something that *approximates* microseconds. > >Using microseconds instead of nanoseconds would likely allow us to do >32-bit arithmetic in more areas, without any real overflow. The basic problem is that one needs a number of bits (at least 16) for normalization, which limits the time range one can work with. This means that 32 bit leaves only room for 1 millisecond resolution, the remainder could maybe saved and reused later. So AFAICT using micro- or nanosecond resolution doesn't make much computational difference. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: REGRESSION: serial_cs broken by 8250 changes
Daniel Ritz wrote: commit 18a8bd949d6adb311ea816125ff65050df1f3f6e breaks serial_cs badly with an oops, completely killing PCMCIA. register_console() now calls console->early_setup(). which in case of 8250.c (the only user anyway) is serial8250_console_early_setup() which is __init, calling 8250_early.c:serial8250_find_port_for_earlycon() which is __init as well. boom. the changelog mentions SERIAL_PORT_DFNS removal which happens to be commit 7e92b4fc345f5b6f57585fbe5ffdb0f24d7c9b26. but this got reverted by commit 57d4810ea0d9ca58a7bcc1336607f0cede0a2abf. so i'd suggest to just revert the 8250 changes as well. rgds -daniel Is there any flag or sign that init code has been released? We could use that to prevent init code to be called after code is freed. Thanks Yinghai Lu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Fix two potential mem leaks in MPT Fusion (mpt_attach())
On Fri, 3 Aug 2007 01:10:02 +0200 "Jesper Juhl" <[EMAIL PROTECTED]> wrote: > > > So, where do we go from here? > > > > Where I said ;) Add a new __GFP_ flag which suppresses the warning, add > > that flag to known-to-be-OK callsites, such as mempool_alloc(). > > > Ok, I'll try to play around with this some more, try to filter out > false positives and see what I'm left with (if anything - I'm pretty > limited hardware-wise, so I can only test a small subset of drivers, > archs etc) - I'll keep you informed, but expect a few days to pass > before I have any news... Make it a once-off thing for now, so the warning will disable itself after it has triggered once. That will prevent the debug feature from making anyone's kernel unusable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: REGRESSION: serial_cs broken by 8250 changes
On Fri, 3 Aug 2007 01:06:32 +0200 Daniel Ritz <[EMAIL PROTECTED]> wrote: > commit 18a8bd949d6adb311ea816125ff65050df1f3f6e breaks serial_cs badly > with an oops, completely killing PCMCIA. > > register_console() now calls console->early_setup(). which in case of > 8250.c (the only user anyway) is serial8250_console_early_setup() > which is __init, calling 8250_early.c:serial8250_find_port_for_earlycon() > which is __init as well. boom. > > the changelog mentions SERIAL_PORT_DFNS removal which happens to be > commit 7e92b4fc345f5b6f57585fbe5ffdb0f24d7c9b26. but this got reverted > by commit 57d4810ea0d9ca58a7bcc1336607f0cede0a2abf. so i'd suggest to > just revert the 8250 changes as well. > Sounds like you'd be the ideal person to propose a patch ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.23-rc1-git3 init failure
Michal Piotrowski wrote: Hi Sid, On 29/07/07, Sid Boyce <[EMAIL PROTECTED]> wrote: > Boot failure on x86_64 (64X2), says it can't find init, specifically > /init. 2.6.23-rc1-git1 boots and runs successfully. I haven't tried > -git2. I shall reboot on 2.6.23-rc1-git3 tomorrow and record the full > message. > Strings from vmlinux in both the above:- > > Kernel alive > /dev/console > <4>Warning: unable to open an initial console. > <4>Failed to execute %s > <4>Failed to execute %s. Attempting defaults... > /sbin/init > /etc/init > /bin/init > /bin/sh > No init found. Try passing init= option to kernel. > > Tried option "init=/sbin/init" and got the same failure. > Regards > Sid. I see the sam problem with 2.6.23-rc1-git5. Freeing unused kernel memory: 236k freed failed to execute /init kernel panic - not syncing: No init found. Try passing init= option to kernel Copying /sbin/init to / results in the same error. openSUSE 10.3Alpha6plus # rpm -qf /sbin/init sysvinit-2.86-90 Please read chapter 4.1 and 4.5 http://www.stardust.webpages.pl/files/handbook/handbook-en-0.3-rc1.pdf It should be very simple git-bisect start git-bisect bad git-bisect good 0de085bb474f64e4fdb2f1ff3268590792648c7b and so on and so forth Regards Sid. Regards, Michal I had to do a fresh install of opeSUSE 10.3 Alpha6 to replace a failing drive. After that I again built 2.6.23-rc1-git10 which boots without problems. My guess is that something on the old hard drive got mangled. The old drive was PATA, the new one SATA, also disappeared have been the problems that suddenly appeared with sata_nv slow responses and timeouts with no devices installed and which I didn't see without the sata_nv module loaded. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] hysdn: convert to PCI hotplug API
This patch has been committed to the 'hysdn' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git
commit b025c86cba3bb9fd7218ce6e8a60f0c65b414d0c
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Thu Aug 2 18:51:14 2007 -0400
[ISDN] hysdn: convert to PCI hotplug API
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/isdn/hysdn/hysdn_init.c | 274 ++--
1 file changed, 130 insertions(+), 144 deletions(-)
b025c86cba3bb9fd7218ce6e8a60f0c65b414d0c
diff --git a/drivers/isdn/hysdn/hysdn_init.c b/drivers/isdn/hysdn/hysdn_init.c
index 9e01748..b7cc5c2 100644
--- a/drivers/isdn/hysdn/hysdn_init.c
+++ b/drivers/isdn/hysdn/hysdn_init.c
@@ -20,10 +20,15 @@
#include "hysdn_defs.h"
static struct pci_device_id hysdn_pci_tbl[] = {
- {PCI_VENDOR_ID_HYPERCOPE, PCI_DEVICE_ID_HYPERCOPE_PLX, PCI_ANY_ID,
PCI_SUBDEVICE_ID_HYPERCOPE_METRO},
- {PCI_VENDOR_ID_HYPERCOPE, PCI_DEVICE_ID_HYPERCOPE_PLX, PCI_ANY_ID,
PCI_SUBDEVICE_ID_HYPERCOPE_CHAMP2},
- {PCI_VENDOR_ID_HYPERCOPE, PCI_DEVICE_ID_HYPERCOPE_PLX, PCI_ANY_ID,
PCI_SUBDEVICE_ID_HYPERCOPE_ERGO},
- {PCI_VENDOR_ID_HYPERCOPE, PCI_DEVICE_ID_HYPERCOPE_PLX, PCI_ANY_ID,
PCI_SUBDEVICE_ID_HYPERCOPE_OLD_ERGO},
+ { PCI_VENDOR_ID_HYPERCOPE, PCI_DEVICE_ID_HYPERCOPE_PLX,
+ PCI_ANY_ID, PCI_SUBDEVICE_ID_HYPERCOPE_METRO, 0, 0, BD_METRO },
+ { PCI_VENDOR_ID_HYPERCOPE, PCI_DEVICE_ID_HYPERCOPE_PLX,
+ PCI_ANY_ID, PCI_SUBDEVICE_ID_HYPERCOPE_CHAMP2, 0, 0, BD_CHAMP2 },
+ { PCI_VENDOR_ID_HYPERCOPE, PCI_DEVICE_ID_HYPERCOPE_PLX,
+ PCI_ANY_ID, PCI_SUBDEVICE_ID_HYPERCOPE_ERGO, 0, 0, BD_ERGO },
+ { PCI_VENDOR_ID_HYPERCOPE, PCI_DEVICE_ID_HYPERCOPE_PLX,
+ PCI_ANY_ID, PCI_SUBDEVICE_ID_HYPERCOPE_OLD_ERGO, 0, 0, BD_ERGO },
+
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE(pci, hysdn_pci_tbl);
@@ -34,128 +39,7 @@ MODULE_LICENSE("GPL");
static char *hysdn_init_revision = "$Revision: 1.6.6.6 $";
static int cardmax;/* number of found cards */
hysdn_card *card_root = NULL; /* pointer to first card */
-
-/**/
-/* table assigning PCI-sub ids to board types */
-/* the last entry contains all 0 */
-/**/
-static struct {
- unsigned short subid; /* PCI sub id */
- unsigned char cardtyp; /* card type assigned */
-} pci_subid_map[] = {
-
- {
- PCI_SUBDEVICE_ID_HYPERCOPE_METRO, BD_METRO
- },
- {
- PCI_SUBDEVICE_ID_HYPERCOPE_CHAMP2, BD_CHAMP2
- },
- {
- PCI_SUBDEVICE_ID_HYPERCOPE_ERGO, BD_ERGO
- },
- {
- PCI_SUBDEVICE_ID_HYPERCOPE_OLD_ERGO, BD_ERGO
- },
- {
- 0, 0
- } /* terminating entry */
-};
-
-
-/*/
-/* search_cards searches for available cards in the pci config data. */
-/* If a card is found, the card structure is allocated and the cards */
-/* ressources are reserved. cardmax is incremented. */
-/*/
-static void
-search_cards(void)
-{
- struct pci_dev *akt_pcidev = NULL;
- hysdn_card *card, *card_last;
- int i;
-
- card_root = NULL;
- card_last = NULL;
- while ((akt_pcidev = pci_find_device(PCI_VENDOR_ID_HYPERCOPE,
PCI_DEVICE_ID_HYPERCOPE_PLX,
-akt_pcidev)) != NULL) {
- if (pci_enable_device(akt_pcidev))
- continue;
-
- if (!(card = kzalloc(sizeof(hysdn_card), GFP_KERNEL))) {
- printk(KERN_ERR "HYSDN: unable to alloc device mem \n");
- return;
- }
- card->myid = cardmax; /* set own id */
- card->bus = akt_pcidev->bus->number;
- card->devfn = akt_pcidev->devfn;/* slot + function */
- card->subsysid = akt_pcidev->subsystem_device;
- card->irq = akt_pcidev->irq;
- card->iobase = pci_resource_start(akt_pcidev,
PCI_REG_PLX_IO_BASE);
- card->plxbase = pci_resource_start(akt_pcidev,
PCI_REG_PLX_MEM_BASE);
- card->membase = pci_resource_start(akt_pcidev,
PCI_REG_MEMORY_BASE);
- card->brdtype = BD_NONE;/* unknown */
- card->debug_flags = DEF_DEB_FLAGS; /* set default debug */
- card->faxchans = 0; /* default no fax channels */
- card->bchans = 2; /* and 2 b-channels */
- for (i = 0; pci_subid_map[i].subid; i++)
- if (pci_subid_map[i].subid == card->subsysid) {
- card->brdtype = pci_subid_map[i].cardtyp;
-
[PATCH 2/2] hysdn: fix SMP brokenness
This patch has been committed to the 'hysdn' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git
commit 4ef2632c0fdf4598cf6a417f39514257ecbb2ba2
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Thu Aug 2 19:08:10 2007 -0400
[ISDN] hysdn: fix SMP brokenness
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/isdn/hysdn/Kconfig |2 +-
drivers/isdn/hysdn/boardergo.c | 14 --
2 files changed, 9 insertions(+), 7 deletions(-)
4ef2632c0fdf4598cf6a417f39514257ecbb2ba2
diff --git a/drivers/isdn/hysdn/Kconfig b/drivers/isdn/hysdn/Kconfig
index c6d8a70..c9e4231 100644
--- a/drivers/isdn/hysdn/Kconfig
+++ b/drivers/isdn/hysdn/Kconfig
@@ -3,7 +3,7 @@
#
config HYSDN
tristate "Hypercope HYSDN cards (Champ, Ergo, Metro) support (module
only)"
- depends on m && PROC_FS && PCI && BROKEN_ON_SMP
+ depends on m && PROC_FS && PCI
help
Say Y here if you have one of Hypercope's active PCI ISDN cards
Champ, Ergo and Metro. You will then get a module called hysdn.
diff --git a/drivers/isdn/hysdn/boardergo.c b/drivers/isdn/hysdn/boardergo.c
index 6cdbad3..7145d37 100644
--- a/drivers/isdn/hysdn/boardergo.c
+++ b/drivers/isdn/hysdn/boardergo.c
@@ -90,7 +90,12 @@ ergo_irq_bh(struct work_struct *ugli_api)
card->hw_lock = 1; /* we now lock the hardware */
do {
- sti(); /* reenable other ints */
+ spin_unlock_irqrestore(>hysdn_lock, flags);
+
+ cond_resched();
+
+ spin_lock_irqsave(>hysdn_lock, flags);
+
again = 0; /* assume loop not to be repeated */
if (!dpr->ToHyFlag) {
@@ -110,7 +115,7 @@ ergo_irq_bh(struct work_struct *ugli_api)
again = 1; /* restart loop */
}
} /* a message has arrived for us */
- cli(); /* no further ints */
+
if (again) {
dpr->ToHyInt = 1;
dpr->ToPcInt = 1; /* interrupt to E1 for all
cards */
@@ -240,9 +245,7 @@ ergo_writebootimg(struct HYSDN_CARD *card, unsigned char
*buf,
while (!dpram->ToHyNoDpramErrLog); /* reread volatile
register to flush PCI */
byteout(card->iobase + PCI9050_USER_IO, PCI9050_E1_RUN);
/* start E1 processor */
- /* the interrupts are still masked */
- sti();
msleep_interruptible(20); /* Timeout 20ms */
if (((tDpramBootSpooler *) card->dpram)->Len !=
DPRAM_SPOOLER_DATA_SIZE) {
@@ -276,7 +279,6 @@ ergo_writebootseq(struct HYSDN_CARD *card, unsigned char
*buf, int len)
dst = sp->Data; /* point to data in spool structure */
buflen = sp->Len; /* maximum len of spooled data */
wr_mirror = sp->WrPtr; /* only once read */
- sti();
/* try until all bytes written or error */
i = 0x1000; /* timeout value */
@@ -380,7 +382,7 @@ ergo_waitpofready(struct HYSDN_CARD *card)
#endif /* CONFIG_HYSDN_CAPI */
return (0); /* success */
} /* data has arrived */
- sti();
+
msleep_interruptible(50); /* Timeout 50ms */
} /* wait until timeout */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: gcc fixed size char array initialization bug - known?
On Fri, Aug 03, 2007 at 12:51:16AM +0200, Guennadi Liakhovetski wrote: > On Fri, 3 Aug 2007, Stefan Richter wrote: > > > Guennadi Liakhovetski wrote: > > > with > > > > > > char c[4] = "012345"; > > > > > > the compiler warns, but actually allocates a 6-byte long array... > > > > Off-topic here, but: sizeof c / sizeof *c == 4. > > Don't think it is OT here - kernel depends on gcc. And, what I meant, is, > that gcc places all 7 (sorry, not 6 as I said above) characters in the > .rodata section of the compiled object file. Of course, it doesn't mean, > that c is 7 characters long. So gcc does that kind of recovery, after having warned you. Makes sense, as long as it's for ordinary variables (and not, say it, struct fields) - you get less likely runtime breakage on the undefined behaviour (e.g. passing c to string functions). So gcc has generated some padding between the global variables, that's all. It doesn't change the fact that use of c[4] or strlen(c) or strcpy(..., c) means nasal demon country for you. Now, if gcc does that for similar situation with struct fields, you'd have a cause to complain. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Fix two potential mem leaks in MPT Fusion (mpt_attach())
On 03/08/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Fri, 3 Aug 2007 00:53:44 +0200
> Jesper Juhl <[EMAIL PROTECTED]> wrote:
>
> > On Thursday 02 August 2007 10:20:47 Jesper Juhl wrote:
> > > On 02/08/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > [snip]
> > > > y'know, we could have a debug option which will spit warnings if someone
> > > > does a !__GFP_WAIT allocation while !in_atomic() (only works if
> > > > CONFIG_PREEMPT).
> > > >
> > > > But please, make it depend on !CONFIG_AKPM. I shudder to think about
> > > > all
> > > > the stuff it would pick up.
> > > >
> > >
> > > I can try to cook up something like that tonight...
> > >
> >
> > Ok, so I did a quick hack and I'm drowning in dmesg WARN_ON() traces
> > with my usual config.
> >
> > This is what I added :
> >
> > diff --git a/mm/slub.c b/mm/slub.c
> > index 6c6d74f..e60dd9e 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -20,6 +20,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > /*
> > * Lock order:
> > @@ -1568,6 +1569,10 @@ static void __always_inline *slab_alloc(struct
> > kmem_cache *s,
> >
> > void *kmem_cache_alloc(struct kmem_cache *s, gfp_t gfpflags)
> > {
> > +#ifdef CONFIG_PREEMPT
> > + WARN_ON( !in_atomic() && !(gfpflags & __GFP_WAIT) );
> > +#endif
> > +
> > return slab_alloc(s, gfpflags, -1, __builtin_return_address(0));
> > }
> > EXPORT_SYMBOL(kmem_cache_alloc);
> > @@ -2370,6 +2375,10 @@ void *__kmalloc(size_t size, gfp_t flags)
> > {
> > struct kmem_cache *s = get_slab(size, flags);
> >
> > +#ifdef CONFIG_PREEMPT
> > + WARN_ON( !in_atomic() && !(flags & __GFP_WAIT) );
> > +#endif
> > +
> > if (ZERO_OR_NULL_PTR(s))
> > return s;
> >
> >
> >
> > And this is what I'm getting heaps of :
> >
> > ...
> > [ 165.128607] ===
> > [ 165.128609] WARNING: at mm/slub.c:1573 kmem_cache_alloc()
> > [ 165.128611] [] show_trace_log_lvl+0x1a/0x30
> > [ 165.128614] [] show_trace+0x12/0x20
> > [ 165.128616] [] dump_stack+0x16/0x20
> > [ 165.128619] [] kmem_cache_alloc+0xe3/0x110
> > [ 165.128622] [] mempool_alloc_slab+0xe/0x10
> > [ 165.128625] [] mempool_alloc+0x31/0xf0
>
> I said you would.
>
Hehe, I know you did. I'm not complaining, simply stating facts
(confirming what you said actually).
> > So, where do we go from here?
>
> Where I said ;) Add a new __GFP_ flag which suppresses the warning, add
> that flag to known-to-be-OK callsites, such as mempool_alloc().
>
Ok, I'll try to play around with this some more, try to filter out
false positives and see what I'm left with (if anything - I'm pretty
limited hardware-wise, so I can only test a small subset of drivers,
archs etc) - I'll keep you informed, but expect a few days to pass
before I have any news...
--
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/
REGRESSION: serial_cs broken by 8250 changes
commit 18a8bd949d6adb311ea816125ff65050df1f3f6e breaks serial_cs badly with an oops, completely killing PCMCIA. register_console() now calls console->early_setup(). which in case of 8250.c (the only user anyway) is serial8250_console_early_setup() which is __init, calling 8250_early.c:serial8250_find_port_for_earlycon() which is __init as well. boom. the changelog mentions SERIAL_PORT_DFNS removal which happens to be commit 7e92b4fc345f5b6f57585fbe5ffdb0f24d7c9b26. but this got reverted by commit 57d4810ea0d9ca58a7bcc1336607f0cede0a2abf. so i'd suggest to just revert the 8250 changes as well. rgds -daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix two potential mem leaks in MPT Fusion (mpt_attach())
On Fri, 3 Aug 2007 00:53:44 +0200
Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On Thursday 02 August 2007 10:20:47 Jesper Juhl wrote:
> > On 02/08/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> [snip]
> > > y'know, we could have a debug option which will spit warnings if someone
> > > does a !__GFP_WAIT allocation while !in_atomic() (only works if
> > > CONFIG_PREEMPT).
> > >
> > > But please, make it depend on !CONFIG_AKPM. I shudder to think about all
> > > the stuff it would pick up.
> > >
> >
> > I can try to cook up something like that tonight...
> >
>
> Ok, so I did a quick hack and I'm drowning in dmesg WARN_ON() traces
> with my usual config.
>
> This is what I added :
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 6c6d74f..e60dd9e 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * Lock order:
> @@ -1568,6 +1569,10 @@ static void __always_inline *slab_alloc(struct
> kmem_cache *s,
>
> void *kmem_cache_alloc(struct kmem_cache *s, gfp_t gfpflags)
> {
> +#ifdef CONFIG_PREEMPT
> + WARN_ON( !in_atomic() && !(gfpflags & __GFP_WAIT) );
> +#endif
> +
> return slab_alloc(s, gfpflags, -1, __builtin_return_address(0));
> }
> EXPORT_SYMBOL(kmem_cache_alloc);
> @@ -2370,6 +2375,10 @@ void *__kmalloc(size_t size, gfp_t flags)
> {
> struct kmem_cache *s = get_slab(size, flags);
>
> +#ifdef CONFIG_PREEMPT
> + WARN_ON( !in_atomic() && !(flags & __GFP_WAIT) );
> +#endif
> +
> if (ZERO_OR_NULL_PTR(s))
> return s;
>
>
>
> And this is what I'm getting heaps of :
>
> ...
> [ 165.128607] ===
> [ 165.128609] WARNING: at mm/slub.c:1573 kmem_cache_alloc()
> [ 165.128611] [] show_trace_log_lvl+0x1a/0x30
> [ 165.128614] [] show_trace+0x12/0x20
> [ 165.128616] [] dump_stack+0x16/0x20
> [ 165.128619] [] kmem_cache_alloc+0xe3/0x110
> [ 165.128622] [] mempool_alloc_slab+0xe/0x10
> [ 165.128625] [] mempool_alloc+0x31/0xf0
I said you would.
> So, where do we go from here?
Where I said ;) Add a new __GFP_ flag which suppresses the warning, add
that flag to known-to-be-OK callsites, such as mempool_alloc().
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: scripts/mod/file2alias.c cross compile problem
On Fri, Aug 03, 2007 at 08:08:20AM +1000, Rusty Russell wrote: >... > scripts/mod/file2alias is the program that reads this: although it can > be altered to parse 32-vs-64, Adrian's fix is the simplest. s/Adrian/Thomas/ > Hope that clarifies, > Rusty. cu Adrian -- "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: gcc fixed size char array initialization bug - known?
On Thu, Aug 02, 2007 at 03:54:34PM -0700, Randy Dunlap wrote:
> >
> > And, Stefan, there is a perfect way to specify a "0123" without the '\0' -
> > {'0', '1', '2', '3'}.
>
> We are actually a bit beyond traditional K, fwiw.
Not in that area - this behaviour is precisely what traditional K
had all along. Unchanged.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: gcc fixed size char array initialization bug - known?
On Fri, Aug 03, 2007 at 12:36:40AM +0200, Guennadi Liakhovetski wrote: > On Thu, 2 Aug 2007, Robert Hancock wrote: > > > Because 5 characters will not fit in a 4 character array, even without the > > null terminator. > > On Fri, 3 Aug 2007, Stefan Richter wrote: > > > How should gcc know whether you actually wanted that char foo[len] to > > contain a \0 as last element? > > Robert, Stefan, I am sorry, I think, you are VERY wrong here. There is no > "even" and no guessing. The "string" DOES include a terminating '\0'. Read the fucking standard. In particular, notice that meaning of string literals outside of initializer is *defined* via that in initializers. IOW, string literals contain _nothing_ - not '\0', not anything else. The entire reason why use of string literal ends up with anon array containing \0 is exactly there - it's "how do we determine the actual length of array of character with unknown length initialized by string literal". _That_ is where \0 comes from. And yes, all quotes you've given are correct. You are blatantly ignoring the context even when you are including all relevant parts into the quoted text. This stuff hadn't changed since K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Fix two potential mem leaks in MPT Fusion (mpt_attach())
On Thursday 02 August 2007 10:20:47 Jesper Juhl wrote:
> On 02/08/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
[snip]
> > y'know, we could have a debug option which will spit warnings if someone
> > does a !__GFP_WAIT allocation while !in_atomic() (only works if
> > CONFIG_PREEMPT).
> >
> > But please, make it depend on !CONFIG_AKPM. I shudder to think about all
> > the stuff it would pick up.
> >
>
> I can try to cook up something like that tonight...
>
Ok, so I did a quick hack and I'm drowning in dmesg WARN_ON() traces
with my usual config.
This is what I added :
diff --git a/mm/slub.c b/mm/slub.c
index 6c6d74f..e60dd9e 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
/*
* Lock order:
@@ -1568,6 +1569,10 @@ static void __always_inline *slab_alloc(struct
kmem_cache *s,
void *kmem_cache_alloc(struct kmem_cache *s, gfp_t gfpflags)
{
+#ifdef CONFIG_PREEMPT
+ WARN_ON( !in_atomic() && !(gfpflags & __GFP_WAIT) );
+#endif
+
return slab_alloc(s, gfpflags, -1, __builtin_return_address(0));
}
EXPORT_SYMBOL(kmem_cache_alloc);
@@ -2370,6 +2375,10 @@ void *__kmalloc(size_t size, gfp_t flags)
{
struct kmem_cache *s = get_slab(size, flags);
+#ifdef CONFIG_PREEMPT
+ WARN_ON( !in_atomic() && !(flags & __GFP_WAIT) );
+#endif
+
if (ZERO_OR_NULL_PTR(s))
return s;
And this is what I'm getting heaps of :
...
[ 165.128607] ===
[ 165.128609] WARNING: at mm/slub.c:1573 kmem_cache_alloc()
[ 165.128611] [] show_trace_log_lvl+0x1a/0x30
[ 165.128614] [] show_trace+0x12/0x20
[ 165.128616] [] dump_stack+0x16/0x20
[ 165.128619] [] kmem_cache_alloc+0xe3/0x110
[ 165.128622] [] mempool_alloc_slab+0xe/0x10
[ 165.128625] [] mempool_alloc+0x31/0xf0
[ 165.128628] [] bio_alloc_bioset+0x73/0x140
[ 165.128631] [] bio_alloc+0xe/0x20
[ 165.128634] [] bio_map_kern+0x31/0x100
[ 165.128637] [] blk_rq_map_kern+0x52/0x90
[ 165.128640] [] scsi_execute+0x4b/0xe0
[ 165.128643] [] sr_do_ioctl+0xa8/0x230
[ 165.128646] [] sr_read_tochdr+0x76/0xb0
[ 165.128649] [] sr_disk_status+0x1b/0xa0
[ 165.128652] [] sr_cd_check+0x9b/0x1b0
[ 165.128655] [] sr_media_change+0x7d/0x250
[ 165.128659] [] media_changed+0x5e/0xa0
[ 165.128662] [] cdrom_media_changed+0x31/0x40
[ 165.128665] [] sr_block_media_changed+0xe/0x10
[ 165.128668] [] check_disk_change+0x20/0x80
[ 165.128671] [] cdrom_open+0x173/0xa10
[ 165.128674] [] sr_block_open+0x5e/0xa0
[ 165.128677] [] do_open+0x85/0x2c0
[ 165.128680] [] blkdev_open+0x33/0x80
[ 165.128683] [] __dentry_open+0xe4/0x200
[ 165.128686] [] nameidata_to_filp+0x35/0x40
[ 165.128689] [] do_filp_open+0x49/0x60
[ 165.128692] [] do_sys_open+0x49/0xe0
[ 165.128695] [] sys_open+0x1c/0x20
[ 165.128697] [] syscall_call+0x7/0xb
...
[ 165.134957] WARNING: at mm/slub.c:1573 kmem_cache_alloc()
[ 165.134959] [] show_trace_log_lvl+0x1a/0x30
[ 165.134962] [] show_trace+0x12/0x20
[ 165.134965] [] dump_stack+0x16/0x20
[ 165.134969] [] kmem_cache_alloc+0xe3/0x110
[ 165.134971] [] mempool_alloc_slab+0xe/0x10
[ 165.134974] [] mempool_alloc+0x31/0xf0
[ 165.134977] [] get_request+0xac/0x260
[ 165.134981] [] get_request_wait+0x1c/0x100
[ 165.134983] [] blk_get_request+0x32/0x70
[ 165.134986] [] scsi_execute+0x22/0xe0
[ 165.134989] [] scsi_execute_req+0x6c/0xd0
[ 165.134991] [] ioctl_internal_command+0x40/0x100
[ 165.134996] [] scsi_set_medium_removal+0x5c/0x90
[ 165.134999] [] sr_lock_door+0x16/0x20
[ 165.135002] [] cdrom_release+0x104/0x250
[ 165.135005] [] sr_block_release+0x24/0x40
[ 165.135008] [] __blkdev_put+0x146/0x150
[ 165.135012] [] blkdev_put+0xa/0x10
[ 165.135015] [] blkdev_close+0x32/0x40
[ 165.135018] [] __fput+0xb6/0x180
[ 165.135021] [] fput+0x19/0x20
[ 165.135024] [] filp_close+0x47/0x80
[ 165.135027] [] sys_close+0x66/0xc0
[ 165.135030] [] syscall_call+0x7/0xb
[ 165.135032] ===
[ 166.564998] WARNING: at mm/slub.c:1573 kmem_cache_alloc()
[ 166.565006] [] show_trace_log_lvl+0x1a/0x30
[ 166.565013] [] show_trace+0x12/0x20
[ 166.565016] [] dump_stack+0x16/0x20
[ 166.565020] [] kmem_cache_alloc+0xe3/0x110
[ 166.565030] [] mempool_alloc_slab+0xe/0x10
[ 166.565039] [] mempool_alloc+0x31/0xf0
[ 166.565047] [] bio_alloc_bioset+0x1f/0x140
[ 166.565057] [] bio_alloc+0xe/0x20
[ 166.565066] [] submit_bh+0x63/0x100
[ 166.565075] [] journal_do_submit_data+0x28/0x40
[ 166.565085] [] journal_commit_transaction+0x658/0x1290
[ 166.565095] [] kjournald+0xb2/0x1e0
[ 166.565103] [] kthread+0x42/0x70
[ 166.565112] [] kernel_thread_helper+0x7/0x18
[ 166.565121] ===
...
etc...
So, where do we go from here?
Obviously my patch above is nothing but a quick hack.
Should I turn that into a proper debug config option?
Do we even want to clean up this stuff?
Am I even looking at the right thing?
I'm more than willing to try and create a
Re: [PATCH]: PCI Error Recovery: Symbios SCSI device driver
On Thu, Jul 05, 2007 at 12:54:06PM -0600, Matthew Wilcox wrote: > On Thu, Jul 05, 2007 at 11:28:38AM -0700, Andrew Morton wrote: > > Well you've sent it a couple of times, and I've sent it in five more times > > over the past year. Once we were told "awaiting maintainer ack". > > > > This situation is fairly stupid. How about we make you the maintainer? > > Last time I looked at it, I still wasn't comfortable with it. I'm going > to look at it again. Please do. Its burning the proverbial hole in my pocket; I'd really like to get this off my list of things I worry about. > I'm fairly sure Linas doesn't want to be the sym2 maintainer. It's > still an ugly pile of junk that needs cleaning up. Heh. I have no difficulty living with ugly code: its actually a great excuse to fix things instead of doing "real work" :-) Rather, the menagerie of hardware I have access to is constantly changing; I don't have a symbios card just right now, and it might take a few days to even find someone who did. Which is an incredibly unpleasent, unrewarding activity. --linas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] handle the multi-threaded init's exit() properly
This looks fine to me, though I don't know anything about the nsproxy bit. Now that choose_new_parent is one trivial line, you might go on to get rid of it and roll its one line into reparent_thread. Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: gcc fixed size char array initialization bug - known?
On Fri, 3 Aug 2007, Stefan Richter wrote: > Guennadi Liakhovetski wrote: > > with > > > > char c[4] = "012345"; > > > > the compiler warns, but actually allocates a 6-byte long array... > > Off-topic here, but: sizeof c / sizeof *c == 4. Don't think it is OT here - kernel depends on gcc. And, what I meant, is, that gcc places all 7 (sorry, not 6 as I said above) characters in the .rodata section of the compiled object file. Of course, it doesn't mean, that c is 7 characters long. Thanks Guennadi --- Guennadi Liakhovetski - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: gcc fixed size char array initialization bug - known?
On Fri, 3 Aug 2007 00:36:40 +0200 (CEST) Guennadi Liakhovetski wrote:
> On Thu, 2 Aug 2007, Robert Hancock wrote:
>
> > Because 5 characters will not fit in a 4 character array, even without the
> > null terminator.
>
> On Fri, 3 Aug 2007, Stefan Richter wrote:
>
> > How should gcc know whether you actually wanted that char foo[len] to
> > contain a \0 as last element?
>
> Robert, Stefan, I am sorry, I think, you are VERY wrong here. There is no
> "even" and no guessing. The "string" DOES include a terminating '\0'. It
> is EQUIVALENT to {'s', 't', 'r', 'i', 'n', 'g', '\0'}. And it contains
> SEVEN characters. Please, re-read your K Specifically, the Section
> "Initialization" in the "Function and Program Structure" chapter (section
> 4.9 in my copy), the paragraph about initialization with a string, which I
> quoted in an earlier email.
>
> And, Stefan, there is a perfect way to specify a "0123" without the '\0' -
> {'0', '1', '2', '3'}.
We are actually a bit beyond traditional K, fwiw.
C99 spec that Al referred you to (available for around US$18 as a pdf)
says in 6.7.8, para. 14 (where Al said):
"An array of character type may be initialized by a character string literal,
optionally
enclosed in braces. Successive characters of the character string literal
(including the
terminating null character if there is room or if the array is of unknown size)
initialize the
elements of the array."
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: VIA EPIA EK: strange eth dev numbering
On Fri, 2007-08-03 at 00:39 +0200, Jan Engelhardt wrote: > On Aug 3 2007 00:00, Kay Sievers wrote: > >On 8/2/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > >> I know I have seen my kernel outputting "A renamed to B". Since you two > >> however wanted that information in the first place, I grepped a bit > >> around, and actually found, (drumroll), that the SUSE kernel has had a > >> proper patch for [I can't remember how long] quite some time. (At least > >> one distro which does the right thing.) I copied it below. > > > >> e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection > >> dev_change_name: about to rename 'eth3' to 'eth0' > >> dev_change_name: about to rename 'eth3' to 'ethxx3' > >> eth3 renamed to ethxx3 > > > >I just made udev when it successfully renamed an interface to write > >that to the kernel log, so dmesg will show: > > <6>udev: renamed network interface eth0 to eth1 > > I think it is helpful to integrate the suse patch rather than to patch udev > alone. This way, renames that do not involve udev also show up. But if you need to swap interface names, you will see the useless temporary device names. On SUSE, nothing else renames network interfaces these days, so we'll probably just remove that patch. :) Kay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [REGRESSION] tg3 dead after s2ram
On Thu, 2007-08-02 at 15:06 -0700, David Miller wrote: > From: "Michael Chan" <[EMAIL PROTECTED]> > Date: Thu, 02 Aug 2007 12:10:29 -0700 > > > Alternatively, we can also fix it by calling pci_enable_device() again > > in tg3_open(). But I think it is better to just always save and restore > > in suspend/resume. bnx2.c will also require the same fix. > > We could do it that way. But don't you think it's more reliable to > save and restore around the event we know will be what clobbers the > PCI config space on us? :-) > Yes for sure when netif state is running and we were already doing that. > Other things might happen between ->resume() and ->open() that could > modify PCI config space, and we could overwrite such changes if we do > the PCI restore in ->open(). I suggested calling pci_enable_device() in ->open(), not calling pci_restore_state() in ->open(). I ultimately decided against it because some devices do not enable memory as a workaround and it would be messy to deal with it again in tg3_open(). I definitely agree that calling PCI restore in ->open() is a bad idea. We used to save PCI state in ->probe() once and restore PCI state after every chip reset. This sequence caused many subtle problems. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
(off-topic) Re: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote:
> Robert, Stefan, I am sorry, I think, you are VERY wrong here.
You meant to say "C99 is very wrong".
> And, Stefan, there is a perfect way to specify a "0123" without the '\0' -
> {'0', '1', '2', '3'}.
C99 says char c[4] = "0123"; is a perfect way to say char c[4] = {'0',
'1', '2', '3'};. Do you want gcc to choose otherwise and ban the former
of the two idioms?
--
Stefan Richter
-=-=-=== =--- ---==
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ICH8 CF timeout (regression)...
Daniel J Blueman wrote: On 02/08/07, Tejun Heo <[EMAIL PROTECTED]> wrote: Daniel J Blueman wrote: I'll grab kernel logs from the legacy ATA boot; what else can help debug this issue? No problem testing patches too. Yeap, please post the old log. Not much actually - perhaps I need to enable some debugging: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx hdc: SanDisk SDCFX-4096, CFA DISK drive ide1 at 0x170-0x177,0x376 on irq 15 hdc: max request size: 128KiB hdc: 8027712 sectors (4110 MB) w/1KiB Cache, CHS=7964/16/63 hdc: hdc1 hdc2 hdc3 --- [2] ata2.00: limiting speed to UDMA/33:PIO4 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: soft resetting port ata2.00: configured for UDMA/33 ata2: EH complete What happens after this? More EH occurs - I've left it for ~5 mins, but let me know if longer would give more information, eg if it converges on a lower speed. Would it be useful to compare some of the port setup registers in the working and non-working cases? Or any other debug I can grab? I'm betting that this is the exact same problem we recently debugged for someone else here: there's a Marvell PATA->SATA bridge chip between that CF card and the SATA controller, and it only works with PIO modes. Tejun.. perhaps (for debugging) a simple patch to disallow DMA completely, just to see if PIO works? Cheers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: VIA EPIA EK: strange eth dev numbering
On Aug 3 2007 00:00, Kay Sievers wrote: >On 8/2/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: >> I know I have seen my kernel outputting "A renamed to B". Since you two >> however wanted that information in the first place, I grepped a bit >> around, and actually found, (drumroll), that the SUSE kernel has had a >> proper patch for [I can't remember how long] quite some time. (At least >> one distro which does the right thing.) I copied it below. > >> e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection >> dev_change_name: about to rename 'eth3' to 'eth0' >> dev_change_name: about to rename 'eth3' to 'ethxx3' >> eth3 renamed to ethxx3 > >I just made udev when it successfully renamed an interface to write >that to the kernel log, so dmesg will show: > <6>udev: renamed network interface eth0 to eth1 I think it is helpful to integrate the suse patch rather than to patch udev alone. This way, renames that do not involve udev also show up. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: CFS review
Hi, On Thu, 2 Aug 2007, Ingo Molnar wrote: > Most importantly, CFS _already_ includes a number of measures that act > against too frequent math. So even though you can see 64-bit math code > in it, it's only rarely called if your clock has a low resolution - and > that happens all automatically! (see below the details of this buffered > delta math) > > I have not seen Roman notice and mention any of these important details > (perhaps because he was concentrating on finding faults in CFS - which a > reviewer should do), but those measures are still very important for a > complete, balanced picture, especially if one focuses on overhead on > small boxes where the clock is low-resolution. > > As Peter has said it in his detailed review of Roman's suggested > algorithm, our main focus is on keeping total complexity down - and we > are (of course) fundamentally open to changing the math behind CFS, we > ourselves tweaked it numerous times, it's not cast into stone in any > way, shape or form. You're comparing apples with oranges, I explicitely said: "At this point I'm not that much interested in a few localized optimizations, what I'm interested in is how can this optimized at the design level" IMO it's very important to keep computational and algorithmic complexity separately, I want to concentrate on the latter, so unless you can _prove_ that a similiar set of optimizations is impossible within my example, I'm going to ignore them for now. CFS has already gone through several versions of optimization and tuning, expecting the same from my design prototype is a little confusing... I want to analyze the foundation CFS is based on, in the review I mentioned a number of other issues and design related questions. If you need more time, that's fine, but I'd appreciate more background information related to that and not that you only jump on the more trivial issues. > In Roman's variant of CFS's algorithm the variables are 32-bit, but the > error is rolled forward in separate fract_* (fractional) 32-bit > variables, so we still have 32+32==64 bit of stuff to handle. So we > think that in the end such a 32+32 scheme would be more complex (and > anyone who took a look at fs2.c would i think agree - it took Peter a > day to decypher the math!) Come on, Ingo, you can do better than that, I did mention in my review some of the requirements for the data types. I'm amazed how you can get to that judgement so quickly, could you please substantiate that a little more? I admit that the lack of source comments is an open invitation for further questions and Peter did exactly this and his comments were great - I'm hoping for more like that. You OTOH jump to conclusions based on a partial understanding what I'm actually trying to do. Ingo, how about you provide some of the mathematical prove CFS is based on? Can you prove that the rounding errors are irrelevant? Can you prove that all the limit checks can have no adverse effect? I tried that and I'm not entirely convinced of that, but maybe it's just me, so I'd love to see someone else's attempt at this. A major goal of my design is it to be able to define the limits within the scheduler is working correctly, so I know which information is relevant and what can be approximated. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] do_sigaction: remove now unneeded recalc_sigpending()
> With the recent changes, do_sigaction()->recalc_sigpending_and_wake() can > never clear TIF_SIGPENDING. Instead, it can set this flag and wake up the > thread without any reason. Harmless, but unneeded and wastes CPU. > > Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]> ACK. (We agreed months ago this was the thing to do.) Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: gcc fixed size char array initialization bug - known?
On Thu, 2 Aug 2007, Robert Hancock wrote:
> Because 5 characters will not fit in a 4 character array, even without the
> null terminator.
On Fri, 3 Aug 2007, Stefan Richter wrote:
> How should gcc know whether you actually wanted that char foo[len] to
> contain a \0 as last element?
Robert, Stefan, I am sorry, I think, you are VERY wrong here. There is no
"even" and no guessing. The "string" DOES include a terminating '\0'. It
is EQUIVALENT to {'s', 't', 'r', 'i', 'n', 'g', '\0'}. And it contains
SEVEN characters. Please, re-read your K Specifically, the Section
"Initialization" in the "Function and Program Structure" chapter (section
4.9 in my copy), the paragraph about initialization with a string, which I
quoted in an earlier email.
And, Stefan, there is a perfect way to specify a "0123" without the '\0' -
{'0', '1', '2', '3'}.
Thanks
Guennadi
---
Guennadi Liakhovetski
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] do_sigaction: remove now unneeded recalc_sigpending()
With the recent changes, do_sigaction()->recalc_sigpending_and_wake() can
never clear TIF_SIGPENDING. Instead, it can set this flag and wake up the
thread without any reason. Harmless, but unneeded and wastes CPU.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- t/kernel/signal.c~ 2007-08-03 02:26:30.0 +0400
+++ t/kernel/signal.c 2007-08-03 02:28:50.0 +0400
@@ -2342,7 +2342,6 @@ int do_sigaction(int sig, struct k_sigac
rm_from_queue_full(, >signal->shared_pending);
do {
rm_from_queue_full(, >pending);
- recalc_sigpending_and_wake(t);
t = next_thread(t);
} while (t != 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: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote: > with > > char c[4] = "012345"; > > the compiler warns, but actually allocates a 6-byte long array... Off-topic here, but: sizeof c / sizeof *c == 4. -- Stefan Richter -=-=-=== =--- ---== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] debugfs helper for decimal challenged
From: Robin Getz <[EMAIL PROTECTED]>
Allows debugfs helper functions to have a hex output, rather than just decimal
Signed-off-by: Robin Getz <[EMAIL PROTECTED]>
---
fs/debugfs/file.c | 36
include/linux/debugfs.h | 27 +++
2 files changed, 63 insertions(+)
Index: linux-2.6.x/include/linux/debugfs.h
===
--- linux-2.6.x/include/linux/debugfs.h (revision 3534)
+++ linux-2.6.x/include/linux/debugfs.h (working copy)
@@ -44,6 +44,12 @@
struct dentry *parent, u16 *value);
struct dentry *debugfs_create_u32(const char *name, mode_t mode,
struct dentry *parent, u32 *value);
+struct dentry *debugfs_create_x8(const char *name, mode_t mode,
+struct dentry *parent, u8 *value);
+struct dentry *debugfs_create_x16(const char *name, mode_t mode,
+struct dentry *parent, u16 *value);
+struct dentry *debugfs_create_x32(const char *name, mode_t mode,
+struct dentry *parent, u32 *value);
struct dentry *debugfs_create_bool(const char *name, mode_t mode,
struct dentry *parent, u32 *value);
@@ -104,6 +110,27 @@
return ERR_PTR(-ENODEV);
}
+static inline struct dentry *debugfs_create_x8(const char *name, mode_t mode,
+ struct dentry *parent,
+ u8 *value)
+{
+ return ERR_PTR(-ENODEV);
+}
+
+static inline struct dentry *debugfs_create_x16(const char *name, mode_t mode,
+ struct dentry *parent,
+ u16 *value)
+{
+ return ERR_PTR(-ENODEV);
+}
+
+static inline struct dentry *debugfs_create_x32(const char *name, mode_t mode,
+ struct dentry *parent,
+ u32 *value)
+{
+ return ERR_PTR(-ENODEV);
+}
+
static inline struct dentry *debugfs_create_bool(const char *name, mode_t mode,
struct dentry *parent,
u32 *value)
Index: linux-2.6.x/fs/debugfs/file.c
===
--- linux-2.6.x/fs/debugfs/file.c (revision 3534)
+++ linux-2.6.x/fs/debugfs/file.c (working copy)
@@ -179,6 +179,42 @@
}
EXPORT_SYMBOL_GPL(debugfs_create_u32);
+DEFINE_SIMPLE_ATTRIBUTE(fops_x8, debugfs_u8_get, debugfs_u8_set, "0x%02llx\n");
+
+DEFINE_SIMPLE_ATTRIBUTE(fops_x16, debugfs_u16_get, debugfs_u16_set,
"0x%04llx\n");
+
+DEFINE_SIMPLE_ATTRIBUTE(fops_x32, debugfs_u32_get, debugfs_u32_set,
"0x%08llx\n");
+
+/**
+ * debugfs_create_x8 - create a debugfs file that is used to read and write an
unsigned 8-bit value
+ * debugfs_create_x16 - create a debugfs file that is used to read and write
an unsigned 16-bit value
+ * debugfs_create_x32 - create a debugfs file that is used to read and write
an unsigned 32-bit value
+ *
+ * These functions are exactly the same as the above functions, (but use a hex
+ * output for the decimal challenged) for details look at the above unsigned
+ * decimal functions.
+ */
+struct dentry *debugfs_create_x8(const char *name, mode_t mode,
+struct dentry *parent, u8 *value)
+{
+ return debugfs_create_file(name, mode, parent, value, _x8);
+}
+EXPORT_SYMBOL_GPL(debugfs_create_x8);
+
+struct dentry *debugfs_create_x16(const char *name, mode_t mode,
+struct dentry *parent, u16 *value)
+{
+ return debugfs_create_file(name, mode, parent, value, _x16);
+}
+EXPORT_SYMBOL_GPL(debugfs_create_x16);
+
+struct dentry *debugfs_create_x32(const char *name, mode_t mode,
+struct dentry *parent, u32 *value)
+{
+ return debugfs_create_file(name, mode, parent, value, _x32);
+}
+EXPORT_SYMBOL_GPL(debugfs_create_x32);
+
static ssize_t read_file_bool(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
{
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: mmap behavior on out-of-space conditions
On Thu, Aug 02, 2007 at 03:06:15PM +0200, Peter Zijlstra wrote: > On Thu, 2007-08-02 at 14:41 +0200, Petr Tesarik wrote: > > Hello, > > > > while solving a different issue, my colleague Libor Pechacek found a > > problem with handling mmapped sparse files. If you mmap the hole insidea > > sparse file and write to it, the data gets silently lost if there is not > > enough space left on the underlying device. > > I think Dave's block_page_mkwrite() stuff addresses this as well, no? > > http://lkml.org/lkml/2007/3/18/198 Yes it does. But only XFS hooks that right now. It works, too. ;) Create and mount 128MB filesystem: budgie:~ # mkfs.xfs -f -d size=128m /dev/sdb9 Fill it up: budgie:~ # dd if=/dev/zero of=/mnt/scratch/fred bs=1024k count=127 dd: writing `/mnt/scratch/fred': No space left on device 119+0 records in 118+0 records out 124764160 bytes (125 MB) copied, 4.69505 seconds, 26.6 MB/s budgie:~ # sync budgie:~ # df -h /mnt/scratch FilesystemSize Used Avail Use% Mounted on /dev/sdb9 124M 120M 48K 100% /mnt/scratch Free up one block: budgie:~ # xfs_io -f -c "truncate 12476" /mnt/scratch/fred budgie:~ # df -h /mnt/scratch FilesystemSize Used Avail Use% Mounted on /dev/sdb9 124M 120M 52K 100% /mnt/scratch Create sparse file: budgie:~ # dd if=/dev/zero of=/mnt/scratch/sparse_mmap_file bs=4k count=1 seek=10 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 0.00022675 seconds, 18.1 MB/s budgie:~ # ls -l /mnt/scratch/sparse_mmap_file -rw-r--r-- 1 root root 409604096 Aug 3 08:13 /mnt/scratch/sparse_mmap_file Mmap sparse file and try to write to it: budgie:~ # xfs_io -f -c "mmap 0 10" -c " mwrite 400 5" /mnt/scratch/sparse_mmap_file Bus error There's your bus error. The blocks that were allocated before ENOSPC: budgie:~ # xfs_bmap -vp /mnt/scratch/sparse_mmap_file /mnt/scratch/sparse_mmap_file: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..7807]:hole 7808 1: [7808..7839]: 155520..114 (24448..24479) 32 2: [7840..79]: hole 792160 3: [80..87]: 155512..1555194 (24440..24447)8 budgie:~ # We got 4x4k data blocks allocated and: budgie:~ # df -h /mnt/scratch FilesystemSize Used Avail Use% Mounted on /dev/sdb9 124M 120M 32K 100% /mnt/scratch That shows that 5 blocks were allocated to hold the 4 data blocks that lead to ENOSPC. i.e. a metadata block of some kind was also allocated. 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: [PATCH] debugfs helper for decimal challenged
On Thu 2 Aug 2007 17:09, Greg KH pondered: > On Wed, Aug 01, 2007 at 11:13:51PM -0400, Robin Getz wrote: > > From: Robin Getz <[EMAIL PROTECTED]> > > > > Allows debugfs helper functions to have a hex output, rather than just > decimal > > > > Signed-off-by: Robin Getz <[EMAIL PROTECTED]> > > --- > > fs/debugfs/file.c | 36 > > 1 file changed, 36 insertions(+) > > You forgot to add the prototypes to the debugfs.h file so that people > can actually use these functions :) > > Care to redo this? No problem. > > --- fs/debugfs/file.c (revision 3529) > > +++ fs/debugfs/file.c (working copy) > > Oh, and add another level to the patch so it can be applied with "-p1" > by patch. will do. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote: > On Thu, 2 Aug 2007, Andi Kleen wrote: >> 6.7.8.14 of C99: >> `` >> An array of character type may be initialized by a character string literal, >> optionally >> enclosed in braces. Successive characters of the character string literal >> (including the >> terminating null character if there is room or if the array is of unknown >> size) initialize the >> elements of the array. >> '' >> >> Note the "if there is room". >> >> I believe the rationale is that it still allows to conveniently initialize >> non zero terminated strings. > > Right, I accept that it will compile, but I don't understand why "01234" > produces a warning and "0123" doesn't? Don't think C99 says anything about How should gcc know whether you actually wanted that char foo[len] to contain a \0 as last element? Given the respective command line switches, gcc does warn in some cases where it is guesswork whether what you typed is what you intended. For example if (i = j()) is reason for gcc to warn even if that might exactly be what you wanted. However this construct can easily be annotated as if ((i = j())) to show to gcc and to carbon-based bipedals that you indeed wanted this. Now there is no nice way to make an annotation that says "look, I'm going to initialize an array of char with a string literal now, and the resulting array will contain a non-zero member as last element, and I mean it". And since there is no such annotation possible, gcc does not warn and demand that you annotate the perfectly valid and 100% spec-compliant construct char a[4] = "1234";. -- Stefan Richter -=-=-=== =--- ---== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: scripts/mod/file2alias.c cross compile problem
On Thu, 2007-08-02 at 09:25 -0700, Luck, Tony wrote:
> > Adrian Bunk: scripts/mod/file2alias.c is compiled with HOSTCC and ensures
> > that
> > kernel_ulong_t is correct, but it can't cope with different padding on
> > different architectures.
>
> Surely this is the root cause ... you can't expect that the alignment
> rules of HOSTCC to make any sense for an arbitraty target.
>
> > +#define FILLUP_LEN 7 /* dirty fix for i386 -> 64bit cross-compilation */
> >
> > struct acpi_device_id {
> > __u8 id[ACPI_ID_LEN];
> > + __u8 dummy[FILLUP_LEN];
> > kernel_ulong_t driver_data;
> > };
>
> What's so special about this structure that we get an error?
It's in mod_devicetable.h: see comment at top of that file. These
structures serve dual purpose: to describe the capabilities of the
driver to the kernel probing functions, *and* to export them to
userspace tables. The former purpose is why there's a data pointer in
there.
scripts/mod/file2alias is the program that reads this: although it can
be altered to parse 32-vs-64, Adrian's fix is the simplest.
Hope that clarifies,
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [REGRESSION] tg3 dead after s2ram
From: "Michael Chan" <[EMAIL PROTECTED]> Date: Thu, 02 Aug 2007 12:10:29 -0700 > On Thu, 2007-08-02 at 02:23 -0700, David Miller wrote: > > From: "Joachim Deguara" <[EMAIL PROTECTED]> > > Date: Thu, 2 Aug 2007 11:15:05 +0200 > > > > > Seams like even if powersave shuts down the network that the device > > > should > > > still work after a suspend to ram, so who is at fault here? > > > > It's a good question. > > > > The pci_enable() is done on the PCI device at probe time, at least in > > the tg3 driver, and with such a model restoring and saving of PCI > > config space should not be dependant upon whether the netdev is > > running or not. > > > > Alternatively, we can also fix it by calling pci_enable_device() again > in tg3_open(). But I think it is better to just always save and restore > in suspend/resume. bnx2.c will also require the same fix. We could do it that way. But don't you think it's more reliable to save and restore around the event we know will be what clobbers the PCI config space on us? :-) Other things might happen between ->resume() and ->open() that could modify PCI config space, and we could overwrite such changes if we do the PCI restore in ->open(). One thing that's interesting to me is that, essentially, every PCI driver with very few if any exceptions needs to do this sequence on suspend and resume. It would be nice if there was a way to get this to happen transparently by default, with some reasonable override mechanism, for PCI device drivers. Anyways, once your patch is tested feel free to send me the bnx2 one too. Thanks! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 2/3] Freezer: Use wait queue instead of busy looping (updated)
On 08/02, Rafael J. Wysocki wrote:
>
> On Thursday, 2 August 2007 23:23, Oleg Nesterov wrote:
> > On 08/02, Rafael J. Wysocki wrote:
> > >
> > > On Thursday, 2 August 2007 20:40, Oleg Nesterov wrote:
> > > > On 08/02, Rafael J. Wysocki wrote:
> > > > >
> > > > > @@ -171,6 +186,10 @@ static int try_to_freeze_tasks(int freez
> > > > >
> > > > > end_time = jiffies + TIMEOUT;
> > > > > do {
> > > > > + DEFINE_WAIT(wait);
> > > > > +
> > > > > + add_wait_queue(_waitq, );
> > > >
> > > > Hmm. In that case I'd sugest to use prepare_to_wait(). This means that
> > > > multiple wakeups from refrigerator() won't do unnecessary work,
> > >
> > > I'm not sure what you mean.
> > >
> > > Do you mean that if we are TASK_UNINTERRUPTIBLE, then the first wake up
> > > should remove us from the queue?
> >
> > No, not because we are TASK_UNINTERRUPTIBLE, but yes, first wake up will
> > remove us because DEFINE_WAIT() uses autoremove_wake_function().
>
> Yes, it does, but the prepare_to_wait() version would only cause current to
> become TASK_UNINTERRUPTIBLE before it sends freezing requests, the other
> differences don't seem to matter. I'm trying to understand why it would
> change
> the behavior in the way you have described.
Ugh, this is not the first time when I didn't read your patch carefully, sorry!
I missed that your patch already uses DEFINE_WAIT(), and I was confused by the
add_wait_queue() which is usually used along with DECLARE_WAITQUEUE().
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] kernel-parameters.txt : watchdog.txt should be wdt.txt
Documentation/watchdog/watchdog.txt does not exist, it is Documentation/watchdog/wdt.txt Signed-off-by: Gabriel Craciunescu <[EMAIL PROTECTED]> --- Documentation/kernel-parameters.txt |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index efdb42f..a326487 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1922,7 +1922,7 @@ and is between 256 and 4096 characters. It is defined in the file See header of drivers/scsi/wd7000.c. wdt=[WDT] Watchdog - See Documentation/watchdog/watchdog.txt. + See Documentation/watchdog/wdt.txt. xd= [HW,XT] Original XT pre-IDE (RLL encoded) disks. xd_geo= See header of drivers/block/xd.c. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: VIA EPIA EK: strange eth dev numbering
On 8/2/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > I know I have seen my kernel outputting "A renamed to B". Since you two > however wanted that information in the first place, I grepped a bit > around, and actually found, (drumroll), that the SUSE kernel has had a > proper patch for [I can't remember how long] quite some time. (At least > one distro which does the right thing.) I copied it below. > e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection > dev_change_name: about to rename 'eth3' to 'eth0' > dev_change_name: about to rename 'eth3' to 'ethxx3' > eth3 renamed to ethxx3 I just made udev when it successfully renamed an interface to write that to the kernel log, so dmesg will show: <6>udev: renamed network interface eth0 to eth1 Kay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.22 regression: thermal trip points
On Thursday 02 August 2007 05:45, Adrian Schröter wrote: > On Thursday 02 August 2007 11:42:27 wrote Thomas Renninger: > > On Thu, 2007-08-02 at 10:40 +0200, Knut Petersen wrote: > > > Hi everybody! > > > > > > Kernel 2.6.22 decreases performance by about 50% on my system. > > > No, I do not like that. The reason is a broken BIOS, granted, but there > > > was a perfect workaround in the kernel that has been dropped. > > > > > > mainboard: AOpen i915GMm-hfs, AWARD BIOS > > > cpu: Pentium-M 750 (0.8 to 1.86 MHz) > > > openSuSE 10.2 with kernel 2.6.22.1 > > > > Is this a DELL laptop that gets throttled by 75% to throttling state 6 > > if 60 degrees are exceeded? > > Adrian has such a machine..., no idea what is going on with that one, > > but only workaround to get any use out of this machine is to override at > > least the passive trip point. > > JFYI, there are plenty of these systems around, it was one out of four > standard Novell modells. I am mabye just the first one who uses Factory on > it, but expect more bugreports when 10.3 gets released ... That's very good news, Adrian. In the past all we had to go on was the memory of a machine that died several years ago. But if you've got a live failure, that is really valuable. Please go here http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI and submit a new sighting vs. Power-Thermal and attach the output from acpidump, cat /proc/acpi/thermal_zone/*/* and assign it to [EMAIL PROTECTED] 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: 2.6.22 regression: thermal trip points
On Thursday 02 August 2007 04:40, Knut Petersen wrote: > Kernel 2.6.22 decreases performance by about 50% on my system. > No, I do not like that. The reason is a broken BIOS, granted, but there > was a perfect workaround in the kernel that has been dropped. > > mainboard: AOpen i915GMm-hfs, AWARD BIOS > cpu: Pentium-M 750 (0.8 to 1.86 MHz) > openSuSE 10.2 with kernel 2.6.22.1 > > The cpu fan can not be controled by linux kernel. > The BIOS will switch on the cpu fan a bit above 50 deg. Celsius. > The active and passive trip points both are set to 50 deg. Celsius. > Temperature of the idle cpu at 800 Mhz: 34 to 42 deg. C. > The BIOS never changes the trip points. > Cpufreq does work perfectly. > > Previously there was the possibility to add something like > > echo "100:0:65:70:0" > /proc/acpi/thermal_zone/THRM/trip_points > echo 2 > /proc/acpi/thermal_zone/THRM/polling_frequency > echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor > > to e.g. /etc/init.d/boot.local. With 2.6.22 that solution does not exist > any longer. Now the code in thermal.c slows down the cpu under load > to prevent "overheating". Kernel compile time increases from about 12 > to 18 minutes. No, I don´t like that, nobody would. Thanks for the sighting, Knut! This regression is dramatic when put in the terms of 50% performance hit! I guess the good news is that thermal throttling is doing the job we are asking it to:-) The statement above regarding the existence of active trip points and the kernel not being able to control the fan are inconsistent with each other. Please open a sighting for this machine here: http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI vs. Power-Thermal and attach the output from acpidump, cat /proc/acpi/thermal_zone/*/* and assign it to [EMAIL PROTECTED] BTW. does the board boot and run properly with "acpi=off"? 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: ACPI on Averatec 2370
On Thu, 2 Aug 2007, Linus Torvalds wrote: > On Thu, 2 Aug 2007, Cal Peake wrote: > > > > Figured I should have sent that right after I hit the send key... > > > > processor : 0 > > vendor_id : AuthenticAMD > > cpu family : 15 > > model : 72 > > model name : AMD Turion(tm) 64 X2 Mobile Technology TL-52 > > Sadly, this doesn't show the "extended family" stuff from cpuid. > > So it doesn't show any of the bits we actually care about. Sad. > > That said, the "AMD Turion(tm) 64 X2 Mobile Technology TL-52" _should_ be > a REV-F CPU afaik, and it should have thus fallen through to the > "ENABLE_C1E_MASK" logic. Afaik that's broken. > > Cal - can you > (a) test that forcing a "return 1" from that amd_apic_timer_broken() > function fixes it for you. ACK > (b) make that function print out the values it uses for debugging (ie the > xtended family and model numbers, and the MSR_K8_ENABLE_C1E MSR > values)? eax & CPUID_XFAM == 0x eax & CPUID_XMOD == 0x0004 MSR_K8_ENABLE_C1E lo == 0x04c14015 MSR_K8_ENABLE_C1E hi == 0x lo & ENABLE_C1E_MASK == 0 amd_apic_timer_broken: forcing return value of 1 -- Cal Peake - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
