Re: [RFC PATCH 02/12] PAT 64b: Basic PAT implementation
* Siddha, Suresh B <[EMAIL PROTECTED]> wrote: > > Ok. I will send a separate patch fixing ioremap_nocache on x86. > > Appended the patch. x86 folks, please consider for x86 mm git tree. > Thanks. thanks, applied. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/8] unify paravirt parts of system.h
On Tue 2007-12-04 20:34:32, Andi Kleen wrote:
> On Tue, Dec 04, 2007 at 09:18:33PM +0200, Avi Kivity wrote:
> > Glauber de Oliveira Costa wrote:
> >> This patch moves the i386 control registers manipulation functions,
> >> wbinvd, and clts functions to system.h. They are essentially the same
> >> as in x86_64, except for the cr8 register, which we add.
> >>
> >> +
> >> +static inline unsigned long native_read_cr8(void)
> >> +{
> >> + unsigned long cr8;
> >> + asm volatile("mov %%cr8,%0" : "=r" (cr8), "=m" (__force_order));
> >> + return cr8;
> >> +}
> >> +
> >>
> >
> > There is no cr8 register on i386. This had better be protected by an
> > #ifdef.
> >
> > (you're likely not getting an error since it's a static inline, so the asm
> > is never emitted)
>
> Linux never uses that register. The only user is suspend save/restore,
> but that' bogus because it wasn't ever initialized by Linux in the first
> place. It could be probably all safely removed.
It probably is safe to remove... but we currently support '2.8.95
kernel loads/resumes 2.6.24 image'... which would break if 2.8 uses
cr8.
So please keep it if it is not a big problem.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: vcsa and big endian
On Sun 2007-12-09 23:50:39, Samuel Thibault wrote:
> Samuel Thibault, le Sun 09 Dec 2007 23:43:49 +0100, a écrit :
> > On big endian machines, /dev/vcsa stores text/attribute bytes in big
> > endian order, while it stores them in little endian order on little
> > endian machines. Is that expected?
>
> It looks like ggi considers this as normal. In any case, the vcsa
> manual page should probably be made more clear ("but including
> attributes" -> "but using unsigned shorts that include attributes" for
> instance).
I'd say you need stronger warning than that, "warning, vcsa is in host
byte endianity" or something.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/urandom uses uninit bytes, leaks user data
On Fri, 14 Dec 2007 23:20:30 PST, Matti Linnanvuori said:
> From: Matti Linnanvuori <[EMAIL PROTECTED]>
>
> /dev/urandom use no uninit bytes, leak no user data
>
> Signed-off-by: Matti Linnanvuori <[EMAIL PROTECTED]>
>
> ---
>
> --- a/drivers/char/random.c 2007-12-15 09:09:37.895414000 +0200
> +++ b/drivers/char/random.c 2007-12-15 09:12:02.607831500 +0200
> @@ -689,7 +689,7 @@ static ssize_t extract_entropy(struct en
> */
> static void xfer_secondary_pool(struct entropy_store *r, size_t nbytes)
> {
> - __u32 tmp[OUTPUT_POOL_WORDS];
> + static __u32 tmp[OUTPUT_POOL_WORDS];
This looks like a race waiting to happen - what lock is held so we don't have
'tmp' smashed by 2 instances on different CPUs (not a problem when each
instance lives on a hopefully separate stack)?
pgpQIfVSMwnsR.pgp
Description: PGP signature
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
* H. Peter Anvin <[EMAIL PROTECTED]> wrote: > I believe this will suffer from the issue that was raised: this will > use udelay() long before loop calibration (and no, we can't just "be > conservative" since there is no "conservative" value we can use.) > > Worse, I suspect that at least the PIT, which may need to be used for > udelay calibration, is one of the devices that may be affected. I > have seen the Verilog for a contemporary chipset, and it can only > access the PIT once per microsecond -- this actually has to do with > the definition of the PIT; some of the PIT operations are ill-defined > if allowed at a higher frequency than the PIT clock. i think the native_io_delay() in quirks.c signals the obvious solution: a DMI (or otherwise) driven quirk that activates a port 0x80 based delay on such boards. Combined with an iodelay=port80 boot option as well perhaps, just in case someone hits a system that is not blacklisted yet. This way such crazy broken hardware can be mapped correctly - like we map such quirks in every other case. Perhaps even do this workaround on the PIT driver level. Instead of perpetuating the superstition of port 80 forever. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Use helper in kprobes{32|64}.c
On Sat, 2007-12-15 at 08:36 +0100, Ingo Molnar wrote:
> * Harvey Harrison <[EMAIL PROTECTED]> wrote:
>
> > x86: Use helper in kprobes{32|64}.c
>
> thanks, i've applied your kprobes pre-unification patches to x86.git.
>
> While we are at it, it might be nice to reduce the numbers of checkpatch
> warnings:
>
> $ scripts/checkpatch.pl --file arch/x86/kernel/kprobes*.c | grep total
> total: 10 errors, 9 warnings, 959 lines checked
> total: 10 errors, 8 warnings, 923 lines checked
>
> to 0/0 ? :-) (but that can happen after the unification too)
>
That was my plan...you'll notice I already cut ~200 from each file
though, so the lion's share is done. I'll have the final few in the
series shortly.
Harvey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] x86: Use helper in kprobes{32|64}.c
* Harvey Harrison <[EMAIL PROTECTED]> wrote:
> x86: Use helper in kprobes{32|64}.c
thanks, i've applied your kprobes pre-unification patches to x86.git.
While we are at it, it might be nice to reduce the numbers of checkpatch
warnings:
$ scripts/checkpatch.pl --file arch/x86/kernel/kprobes*.c | grep total
total: 10 errors, 9 warnings, 959 lines checked
total: 10 errors, 8 warnings, 923 lines checked
to 0/0 ? :-) (but that can happen after the unification too)
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/5] x86, ptrace: remove bad comment
Markus, i've applied the first 4 patches to x86.git. another detail: shouldnt this be structured so that the APIs are introduced in kernel/ptrace.c, and that the architecture offers the mechanism. (which would thus be ptrace-independent) This would also open these APIs up to kernel-internal use and to be used by other architectures. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
/dev/urandom uses uninit bytes, leaks user data
From: Matti Linnanvuori <[EMAIL PROTECTED]>
/dev/urandom use no uninit bytes, leak no user data
Signed-off-by: Matti Linnanvuori <[EMAIL PROTECTED]>
---
--- a/drivers/char/random.c 2007-12-15 09:09:37.895414000 +0200
+++ b/drivers/char/random.c 2007-12-15 09:12:02.607831500 +0200
@@ -689,7 +689,7 @@ static ssize_t extract_entropy(struct en
*/
static void xfer_secondary_pool(struct entropy_store *r, size_t nbytes)
{
- __u32 tmp[OUTPUT_POOL_WORDS];
+ static __u32 tmp[OUTPUT_POOL_WORDS];
if (r->pull && r->entropy_count < nbytes * 8 &&
r->entropy_count < r->poolinfo->POOLBITS) {
Machen Sie Yahoo! zu Ihrer Startseite. Los geht's:
http://de.yahoo.com/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: [patch 4/5] x86, ptrace: new ptrace BTS API
* Markus Metzger <[EMAIL PROTECTED]> wrote: > Here's the new ptrace BTS API that supports two different overflow > handling mechanisms (wrap-around and buffer-full-signal) to support > two different use cases (debugging and profiling). > > It further combines buffer allocation and configuration. > > Opens: > - memory rlimit > - overflow signal > > What would be the right signal to use? i think we tend to have such signal targets configurable (like in the POSIX timers APIs) - or we could use SIGIO. I've Cc:-ed Ulrich - maybe he has some specific ideas how to structure this. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: More info on port 80 symptoms on MCP51 machine.
On 14-12-07 23:05, Chuck Ebbert wrote: On 12/12/2007 04:05 PM, H. Peter Anvin wrote: Rene Herman wrote: By the way, _does_ anyone have a contact at nVidia who could clarify? Alan maybe? I'm quite curious what they did... Summary: Unless after booting with "acpi=off", outputs to port 0x80 (the legacy way to delay I/O) reliably, but not immediately, hang MCP51 machines. Outputs to port 0xed do not indicating it's a not a generic bus abort problem. Sorry, the first sentence didn't parse unambiguously for me. Do you mean "acpi=off" works, or that "acpi=off" allows *subsequent* boots to work? I have some people at nVidia I can probably ping. Sorry, didn't see this again due to aforementioned horseshit ISP. "acpi=off" works it seems. Report from David Reed here: http://lkml.org/lkml/2007/12/12/291 Have them search on Google for: hp tx1000 noapic :) 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: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
[EMAIL PROTECTED] wrote: On Dec 14, 2007 11:37 PM, <[EMAIL PROTECTED]> wrote: I'll attach these logs since I can't read much into them. I should do what I say... It will take a while to finish looking over those logs, but are you using ipv6? If not, please blacklist the ipv6 module to prevent it from loading - add the line 'blacklist ipv6' to file /etc/modprobe.d/blacklist. In some cases, ipv6 can cause timeouts even though you do not have any ipv6 routers. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.24-rc5-mm1 -- inconsistent {in-softirq-W} -> {softirq-on-R} usage.
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> I'd say you hit a networking locking bug and then when trying to report
> that bug, lockdep crashed.
>
> The networking bug looks to be around sock_i_ino()'s taking of
> sk_callback_lock with softirq's enabled. Perhaps this will fix it.
>
> diff -puN net/core/sock.c~a net/core/sock.c
> --- a/net/core/sock.c~a
> +++ a/net/core/sock.c
> @@ -1115,9 +1115,9 @@ int sock_i_uid(struct sock *sk)
> {
>int uid;
>
> - read_lock(>sk_callback_lock);
> + read_lock_bh(>sk_callback_lock);
>uid = sk->sk_socket ? SOCK_INODE(sk->sk_socket)->i_uid : 0;
> - read_unlock(>sk_callback_lock);
> + read_unlock_bh(>sk_callback_lock);
The callback lock is never taken for writing in BH context so
this shouldn't be needed.
Let's fix the lockdep checker first and then decide what's broken
in networking, OK?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/urandom uses uninit bytes, leaks user data
John Reiser <[EMAIL PROTECTED]> wrote:
>
> If speed matters that much, then please recoup 33 cycles on x86
> by using shifts instead of three divides, such as (gcc 4.1.2):
>
>add_entropy_words(r, tmp, (bytes + 3) / 4);
>
> 0x8140689 :lea0x3(%esi),%eax
> 0x814068c :mov$0x4,%dl
> 0x814068e :mov%edx,%edi
> 0x8140690 :cltd
> 0x8140691 :idiv %edi
There ought to be a warning about this sort of thing.
[CHAR] random: Avoid signed integer division
Joihn Reiser pointed out that we use signed integer divisions
unnecessarily in random.c. This is bad because the C compiler
is obliged to consider the case of a negative dividend.
This patch changes all the relevant divisions and modulus operations
to use unsigned arithmetic.
Signed-off: Herbert Xu <[EMAIL PROTECTED]>
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 5fee056..6c70bfb 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -694,11 +694,11 @@ static void xfer_secondary_pool(struct entropy_store *r,
size_t nbytes)
if (r->pull && r->entropy_count < nbytes * 8 &&
r->entropy_count < r->poolinfo->POOLBITS) {
/* If we're limited, always leave two wakeup worth's BITS */
- int rsvd = r->limit ? 0 : random_read_wakeup_thresh/4;
+ int rsvd = r->limit ? 0 : random_read_wakeup_thresh / 4u;
int bytes = nbytes;
/* pull at least as many as BYTES as wakeup BITS */
- bytes = max_t(int, bytes, random_read_wakeup_thresh / 8);
+ bytes = max_t(int, bytes, random_read_wakeup_thresh / 8u);
/* but never more than the buffer size */
bytes = min_t(int, bytes, sizeof(tmp));
@@ -707,8 +707,8 @@ static void xfer_secondary_pool(struct entropy_store *r,
size_t nbytes)
r->name, bytes * 8, nbytes * 8, r->entropy_count);
bytes=extract_entropy(r->pull, tmp, bytes,
- random_read_wakeup_thresh / 8, rsvd);
- add_entropy_words(r, tmp, (bytes + 3) / 4);
+ random_read_wakeup_thresh / 8u, rsvd);
+ add_entropy_words(r, tmp, (bytes + 3) / 4u);
credit_entropy_store(r, bytes*8);
}
}
@@ -739,14 +739,14 @@ static size_t account(struct entropy_store *r, size_t
nbytes, int min,
nbytes * 8, r->name);
/* Can we pull enough? */
- if (r->entropy_count / 8 < min + reserved) {
+ if (r->entropy_count / 8u < min + reserved) {
nbytes = 0;
} else {
/* If limited, never pull more than available */
- if (r->limit && nbytes + reserved >= r->entropy_count / 8)
- nbytes = r->entropy_count/8 - reserved;
+ if (r->limit && nbytes + reserved >= r->entropy_count / 8u)
+ nbytes = r->entropy_count / 8u - reserved;
- if(r->entropy_count / 8 >= nbytes + reserved)
+ if(r->entropy_count / 8u >= nbytes + reserved)
r->entropy_count -= nbytes*8;
else
r->entropy_count = reserved;
@@ -781,7 +781,7 @@ static void extract_buf(struct entropy_store *r, __u8 *out)
/* hash blocks of 16 words = 512 bits */
sha_transform(buf, (__u8 *)(r->pool + i), buf + 5);
/* feed back portion of the resulting hash */
- add_entropy_words(r, [i % 5], 1);
+ add_entropy_words(r, [i % 5u], 1);
}
/*
@@ -789,7 +789,7 @@ static void extract_buf(struct entropy_store *r, __u8 *out)
* portion of the pool while mixing, and hash one
* final time.
*/
- __add_entropy_words(r, [i % 5], 1, data);
+ __add_entropy_words(r, [i % 5u], 1, data);
sha_transform(buf, (__u8 *)data, buf + 5);
/*
@@ -1040,7 +1040,7 @@ write_pool(struct entropy_store *r, const char __user
*buffer, size_t count)
count -= bytes;
p += bytes;
- add_entropy_words(r, buf, (bytes + 3) / 4);
+ add_entropy_words(r, buf, (bytes + 3) / 4u);
}
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Wireshark sees no packets in 2.6.24-rc3
On Dec 14, 2007 6:41 PM, Gabriel C <[EMAIL PROTECTED]> wrote: > Rafael J. Wysocki wrote: > > On Friday, 14 of December 2007, Ray Lee wrote: > >> tshark -i eth0, eth1, lo are all empty. Works under 2.6.23.0 just > >> fine. A quick scan of the log between 2.6.24-rc3 and current tip > >> (-rc5) doesn't show any obvious fixes, but then again, what do I know. > >> I'll check current tip on the weekend when I'll have the luxury to > >> have my main system down long enough for a test. Right now I'm kinda > >> up against a deadline, but didn't want to leave it unreported. Should > >> be easy for someone else to confirm or deny whether current tip has > >> the problem. > > > > FYI, I have created a bugzilla entry for this issue at: > > http://bugzilla.kernel.org/show_bug.cgi?id=9568 > > Hmm what do you mean by empty ? it does not capturing anything on that > interface ? Correct, absolutely no traffic. So if it works for you, then either it's something that got fixed between -rc3 and -rc5, or something odd when I did a make oldconfig, I suppose. (Or because I'm on an x86-64 kernel?) Regardless, -rc5 is currently building, and I'll try it in the morning. > I do run -rc5-git with wireshark-0.99.6 and tshark -i eth0 or lo works here. Excellent. Thank you for checking! Rafael: I'll update the bugzilla as warranted after testing. Ray -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-mm1: kernel BUG at include/linux/scatterlist.h:59!
On Fri, 14 Dec 2007 18:05:56 -0500 "John Stoffel" <[EMAIL PROTECTED]> wrote: > > Hi, > > Just fired up 2.6.24-rc5-mm1 on a Dual CPU PIII 550mhz system with 2gb > of RAM. Got the following error. Let me know if you need more > details or want me to run tests or make changes. Looks like something > in the SCSI st driver, which makes sense since I have a pair of DLT 7k > drives hooked upto this system via a Symbios PCI card. I've also got > a P1000 jukebox on there as well. Can you try the following patch? diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c index 98dfd6e..328c47c 100644 --- a/drivers/scsi/st.c +++ b/drivers/scsi/st.c @@ -3611,6 +3611,7 @@ static struct st_buffer * tb->dma = need_dma; tb->buffer_size = got; + sg_init_table(tb->sg, max_sg); return tb; } -- 1.5.3.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make WARN_ON/WARN_ON_ONCE no-ops when CONFIG_BUG is off
On Sat, Dec 15, 2007 at 02:04:49PM +0800, Herbert Xu wrote:
>
> I suppose we'll have to either introduce a new primitive or just
> go back to using BUG_ON.
Let's do the conservative thing and add a new primitive.
[PATCH] Added BARF_ON/BARF_ON_ONCE
The description of CONFIG_BUG clearly states that both BUG and
WARN_ON may be skipped. However, our actual implementation still
checks the condition on WARN_ON if it's used as part of an if
statement or such.
I tried to compile it away but Matt Mackall pointed out that
people may already be using it in ways that were not intended.
In particular, it may have been used for conditions that are
thought to be possible.
So this patch adds a new pair of macros BARF_ON and BARF_ON_ONCE
that are clearly marked as such to prevent abuse. The intended
usage model is identical to WARN_ON except that they should only
be used for conditions that are thought to be impossible. In
other words, only use them to replace BUG_ON's that may be called
by an IRQ handler or within locks.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index d56fedb..36e565c 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -43,6 +43,19 @@ struct bug_entry {
})
#endif
+/*
+ * BARF_ON should only be used in situations which are thought to be
+ * impossible in practice. In other words, do NOT use it in a place
+ * where you would not use BUG_ON. It only exists so that the message
+ * gets a chance to be written to disk.
+ *
+ * It should only be used if we can afford to not kill the current
+ * process or the kernel. So don't use it if we may end up scribbling
+ * over the disk or give people remote root access.
+ */
+#define BARF_ON(condition) WARN_ON(condition)
+#define BARF_ON_ONCE(condition) WARN_ON_ONCE(condition)
+
#else /* !CONFIG_BUG */
#ifndef HAVE_ARCH_BUG
#define BUG()
@@ -58,6 +71,9 @@ struct bug_entry {
unlikely(__ret_warn_on);\
})
#endif
+
+#define BARF_ON(condition) ((condition), 0)
+#define BARF_ON_ONCE(condition) BARF_ON(condition)
#endif
#define WARN_ON_ONCE(condition)({ \
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
New question on that sata controller
Greetings; When I asked about a sata controller earlier this week, I gave a link to it. Unforch (maybe) when it actually arrived, the cards box showed a silicon image chip, and the card had a via. So much for getting what I ordered... The required module then was sata_via, not sata_uli, and it seems to be working ok. However, this one claims its a raid controller according to an lspci -v: 01:0a.0 RAID bus controller: VIA Technologies, Inc. VT6421 IDE RAID Controller (rev 50) Subsystem: VIA Technologies, Inc. VT6421 IDE RAID Controller Flags: bus master, medium devsel, latency 32, IRQ 19 I/O ports at 9400 [size=16] I/O ports at 9800 [size=16] I/O ports at 9c00 [size=16] I/O ports at a000 [size=16] I/O ports at a400 [size=32] I/O ports at a800 [size=256] [virtual] Expansion ROM at e900 [disabled] [size=64K] Capabilities: [e0] Power Management version 2 I just noted that the Expansion ROM is disabled, but I didn't see any jumpers to enable it on the card prior to installing it. Does anyone know how this is supposed to work? I would like to make it directly bootable but I believe this has to be 'enabled' for that. I cannot find any references to this particular chip in a 'make xconfig' for 2.6.24-rc5. Should this be a concern, or is this one a 'Just Works(TM)' chipset? This card has 3 sata port connectors and one ide fitted. Two rather pleasant side effects of going to the Biostar.tw site and finding a newer bios and installing it on an M7NCD Pro mobo are: 1: FSB now running at 400MHZ, was 333 before as it was not at all stable at 400 and I have been told the XP-2800 Athlon only supports 333 and AMD's site agrees. 2: CPU temps are down around 13F. CPU speed still the same at 2079MHZ according to dmesg. The reduced temps at a higher FSB indicates better interface timing, and if it runs the rest of the night at 400 without a self reboot or crash, I'll leave it there. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Q: Why is it that Mexico isn't sending anyone to the '84 summer games? A: Anyone in Mexico who can run, swim or jump is already in LA. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] ARM: OMAP: Change mailing list for OMAP in MAINTAINERS
OMAP has now a list at vger. Signed-off-by: Dirk Behme <[EMAIL PROTECTED]> Index: linux-osk/MAINTAINERS === --- linux-osk.orig/MAINTAINERS +++ linux-osk/MAINTAINERS @@ -3683,7 +3683,7 @@ S: Maintained TI OMAP MMC INTERFACE DRIVER P: Carlos Aguiar, Anderson Briglia and Syed Khasim -M: [EMAIL PROTECTED] (subscribers only) +M: [EMAIL PROTECTED] W: http://linux.omap.com W: http://www.muru.com/linux/omap/ S: Maintained
Re: [PATCH] Make WARN_ON/WARN_ON_ONCE no-ops when CONFIG_BUG is off
On Fri, Dec 14, 2007 at 11:52:18PM -0600, Matt Mackall wrote: > Then I kindly submit that you should instead withdraw the code that > allows you to use WARN_ON in a condition in the first place. > > Note that Dave Jones is currently poking at making WARN_ON > out-of-line, so you're liable to collide with him. Actually I'm not likely to get back to this until post xmas. I'm on vacation until then from today, so I'll be paying less attention to stuff than usual. Dave -- http://www.codemonkey.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make WARN_ON/WARN_ON_ONCE no-ops when CONFIG_BUG is off
On Sat, Dec 15, 2007 at 05:31:30PM +1100, Benjamin Herrenschmidt wrote:
>
> That's something I've actually never quite liked... the fact that we
> evaluate the expression anyway. I'm pretty happy with -not- evaluating
> the expression when CONFIG_BUG is on most of the time since whatever is
> in there is purely here for the sake of the BUG/WARN test.
Whether we evaluate the expression is a completely different debate.
I personally agree with you that expressions that have side-effects
are a stupid idea for either WARN_ON or BUG_ON.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make WARN_ON/WARN_ON_ONCE no-ops when CONFIG_BUG is off
On Fri, 2007-12-14 at 21:27 +0800, Herbert Xu wrote: > Hi: > > [PATCH] Make WARN_ON/WARN_ON_ONCE no-ops when CONFIG_BUG is off > > The description of CONFIG_BUG clearly states that both BUG and > WARN_ON may be skipped. However, our actual implementation still > checks the condition on WARN_ON if it's used as part of an if > statement or such. > > This patch makes it return 0 after evaluating the expression > if CONFIG_BUG is disabled. This is consistent with the spirit > of the CONFIG_BUG option. > > The same change is made to WARN_ON_ONCE. > > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> That's something I've actually never quite liked... the fact that we evaluate the expression anyway. I'm pretty happy with -not- evaluating the expression when CONFIG_BUG is on most of the time since whatever is in there is purely here for the sake of the BUG/WARN test. I understand why some people may want it the other way around, but I personally find it a very bad idea in the first place to write a normal statement part of the program as BUG_ON(do_something()); It's way clearer to me I believe to write: rc = do_something(); BUG_ON(rc); And thus, when I write: BUG_ON(do_sanity_check()); I'm actually execting the function call to disappear when CONFIG_BUG is turned off... Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make WARN_ON/WARN_ON_ONCE no-ops when CONFIG_BUG is off
On Sat, Dec 15, 2007 at 12:12:00AM -0600, Matt Mackall wrote:
>
> I tend to agree with this position, except when it comes to handling
> filesystems, where panic is often (but not always) the right thing to
> do.
Given the choice between crashing the machine or potentially giving
an attacker remote root access, I definitely prefer the former in
many instances in the network stack.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: dst cache overflow
Tobias Diedrich <[EMAIL PROTECTED]> wrote:
>
> Meanwhile I added a slab statistic rrd script. Nothing obvious to
> see on ari or yumi yet, but on oni (which after all is the most
> affected by this) I can see 'size_2048' and 'TCPv6' growing
> steadily along with the route cache size (Presumably 'ip_dst_cache',
> which is also growing larger at a more or less constant rate).
OK that almost certainly means that we have a leak of TCPv6
objects which would then cause a leak of dst objects.
So you need to track down why TCPv6 isn't getting cleaned up.
First check the obvious, do you have any process(es) that are
hoarding TCPv6 sockets?
If not do you see a growing list of dead sockets in netstat?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make WARN_ON/WARN_ON_ONCE no-ops when CONFIG_BUG is off
On Fri, 2007-12-14 at 12:02 -0600, Matt Mackall wrote: > > I added CONFIG_BUG, and I think the current behavior is correct. As > you've noticed, we have to evaluate condition, it may have > side-effects. And if code does: > > /* this indicates a driver bug, report and fail gracefully */ > if (WARN_ON(val == NULL)) > return -EFAULT; > > ..we surely want it to continue returning -EFAULT, regardless of > whether we log it, no? What use case did you have in mind? I find such code totally distateful. Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arch/cris/arch-v10/vmlinux.lds.S fix boot problem
arch/cris/arch-v10/vmlinux.lds.S
fix boot problem
* too old initcall style. replace INITCALLS macro
* __init_begin, __init_end move for free_initmem()
Note: with this patch kernel boot and mount root,
but after init done, kernel panic at do_signal() ...
ryu
Signed-off-by: Yuusei KUWANA <[EMAIL PROTECTED]>
---
arch/cris/arch-v10/vmlinux.lds.S | 13 -
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/cris/arch-v10/vmlinux.lds.S b/arch/cris/arch-v10/vmlinux.lds.S
index 9859d49..c5bab0e 100644
--- a/arch/cris/arch-v10/vmlinux.lds.S
+++ b/arch/cris/arch-v10/vmlinux.lds.S
@@ -53,26 +53,22 @@ SECTIONS
.data.init_task : { *(.data.init_task) }
. = ALIGN(8192); /* Init code and data */
- __init_begin = .;
.init.text : {
_sinittext = .;
*(.init.text)
_einittext = .;
}
+ __init_begin = .;
.init.data : { *(.init.data) }
+ __init_end = .;
+
. = ALIGN(16);
__setup_start = .;
.init.setup : { *(.init.setup) }
__setup_end = .;
.initcall.init : {
__initcall_start = .;
- *(.initcall1.init);
- *(.initcall2.init);
- *(.initcall3.init);
- *(.initcall4.init);
- *(.initcall5.init);
- *(.initcall6.init);
- *(.initcall7.init);
+ INITCALLS
__initcall_end = .;
}
@@ -97,7 +93,6 @@ SECTIONS
#endif
__vmlinux_end = .;/* last address of the physical file */
- __init_end = .;
__data_end = . ; /* Move to _edata ? */
__bss_start = .; /* BSS */
--
1.5.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: [PATCH] Make WARN_ON/WARN_ON_ONCE no-ops when CONFIG_BUG is off
On Sat, Dec 15, 2007 at 02:04:49PM +0800, Herbert Xu wrote: > On Fri, Dec 14, 2007 at 11:52:18PM -0600, Matt Mackall wrote: > > > > No. The code as written above should reduce to: > > > > if (val == NULL) > > return -EFAULT; > > > > If I hadn't wanted to return -EFAULT in this case, I would have just > > written: > > > > WARN_ON(val == NULL); > > Well the only reason I introduced > > if (WARN_ON) > > is so that what would otherwise be a BUG_ON condition would have > a chance to get written to disk when invoked from an IRQ handler. > > > I don't want code that was running safely (ie returning -EFAULT) to > > start crashing the system just because I've, say, disabled printk. > > That's creating an obnoxious heisenbug. > > I'm disappointed that it has been used in ways that it shouldn't > have been. > > I suppose we'll have to either introduce a new primitive or just > go back to using BUG_ON. Seems we haven't yet reached concensus on what an appropriate use for BUG_ON is. There's a fairly large camp who think that there are basically no good reasons to outright crash a machine and that WARN_ON should replace BUG_ON everywhere. I tend to agree with this position, except when it comes to handling filesystems, where panic is often (but not always) the right thing to do. -- 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: PROBLEM: E6850 has an 8+ minute delay during boot
On Friday 14 December 2007 04:10, Arun Thomas wrote: > Hi, > > My Dell Vostro desktop w/ an Intel E6850 dual-core 3GHz CPU has an 8+ > minute delay during boot. The machine seems to run fine after it > boots. The problem occurs on the Ubuntu gutsy 2.6.22-14 kernel, > 2.6.23.9, and 2.6.24-rc5. I have upgraded to the most recent Dell BIOS > version (1.0.8). I am running an SMP kernel currently, but the problem > presents itself in uniprocessor mode (nosmp) also. I'm running the > machine in 32-bit mode w/hyperthreading configured. > > Here are a few interesting things in the dmesg output for the > 2.6.24-rc5 kernel (smp). The full dmesg is also included farther down. > > [ 20.101501] CPU: After generic identify, caps: bfebfbff 2010 > e3fd 0001 > [ 20.101505] monitor/mwait feature present. > [ 20.101506] using mwait in idle threads. > [ 20.101508] CPU: L1 I cache: 32K, L1 D cache: 32K > [ 20.101509] CPU: L2 cache: 4096K > [ 20.101511] CPU: Physical Processor ID: 0 > [ 20.101511] CPU: Processor Core ID: 0 > [ 20.101513] CPU: After all inits, caps: bfebfbff 2010 > 3940 e3fd 0001 > [ 20.101517] Compat vDSO mapped to e000. > [ 20.101525] Checking 'hlt' instruction... OK. > [ 20.117651] SMP alternatives: switching to UP code > [ 20.118574] ACPI: Core revision 20070126 > [ 20.175154] CPU0: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz stepping > 0b > [ 20.175163] SMP alternatives: switching to SMP code > [ 20.175437] Booting processor 1/1 eip 3000 > [ 20.185881] Initializing CPU#1 > [ 527.926587] Calibrating delay using timer specific routine.. > 200566.59 BogoMIPS (lpj=401133185) > [ 527.926592] CPU: After generic identify, caps: bfebfbff 2010 try CONFIG_HIGH_RES_TIMERS=n try "hpet=disable" -Len -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make WARN_ON/WARN_ON_ONCE no-ops when CONFIG_BUG is off
On Fri, Dec 14, 2007 at 11:52:18PM -0600, Matt Mackall wrote:
>
> No. The code as written above should reduce to:
>
> if (val == NULL)
> return -EFAULT;
>
> If I hadn't wanted to return -EFAULT in this case, I would have just written:
>
> WARN_ON(val == NULL);
Well the only reason I introduced
if (WARN_ON)
is so that what would otherwise be a BUG_ON condition would have
a chance to get written to disk when invoked from an IRQ handler.
> I don't want code that was running safely (ie returning -EFAULT) to
> start crashing the system just because I've, say, disabled printk.
> That's creating an obnoxious heisenbug.
I'm disappointed that it has been used in ways that it shouldn't
have been.
I suppose we'll have to either introduce a new primitive or just
go back to using BUG_ON.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-stable causes oomkiller to be invoked
On Sat, 15 Dec 2007 09:22:00 +0530 Dhaval Giani <[EMAIL PROTECTED]> wrote:
> > Is it really the case that the bug only turns up when you run tests like
> >
> > while echo; do cat /sys/kernel/kexec_crash_loaded; done
> > and
> > while echo; do cat /sys/kernel/uevent_seqnum ; done;
> >
> > or will any fork-intensive workload also do it? Say,
> >
> > while echo ; do true ; done
> >
>
> This does not leak, but having a simple text file and reading it in a
> loop causes it.
hm.
> > ?
> >
> > Another interesting factoid here is that after the oomkilling you slabinfo
> > has
> >
> > mm_struct 38 9858471 : tunables 32 168
> > : slabdata 14 14 0 : globalstat278119649 31
> > 01000 : cpustat 368800 11864
> > 368920 11721
> >
> > so we aren't leaking mm_structs. In fact we aren't leaking anything from
> > slab. But we are leaking pgds.
> >
> > iirc the most recent change we've made in the pgd_t area is the quicklist
> > management which went into 2.6.22-rc1. You say the bug was present in
> > 2.6.22. Can you test 2.6.21?
>
> Nope, leak is not present in 2.6.21.7
Could you try this debug patch please?
It might need some fiddling to get useful output. Basic idea is to see if
we are failing to empty the quicklists.
--- a/include/linux/quicklist.h~a
+++ a/include/linux/quicklist.h
@@ -69,6 +69,8 @@ static inline void __quicklist_free(int
*(void **)p = q->page;
q->page = p;
q->nr_pages++;
+ if (q->nr_pages && !(q->nr_pages % 1000))
+ printk("eek: %d\n", q->nr_pages);
put_cpu_var(quicklist);
}
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.24-rc5-mm1 -- inconsistent {in-softirq-W} -> {softirq-on-R} usage.
On Fri, 14 Dec 2007 22:58:24 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
> On Dec 14, 2007 6:36 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Fri, 14 Dec 2007 17:13:21 -0500
> > "Miles Lane" <[EMAIL PROTECTED]> wrote:
> >
> >
> > > Sorry Andrew, I don't know who to forward this problem to.
> > >
> > > I tried running: find /proc | xargs cat
> > > and got this:
> > >
> > > =
> > > [ INFO: inconsistent lock state ]
> > > 2.6.24-rc5-mm1 #26
> > > -
> > > inconsistent {in-softirq-W} -> {softirq-on-R} usage.
> > > cat/6944 [HC0[0]:SC0[0]:HE1:SE1] takes:
> > > BUG: unable to handle kernel paging request at virtual address 0f1eff0b
> > > printing ip: c01fe64d *pde =
> > > Oops: [#1] PREEMPT SMP
> > > last sysfs file: /sys/block/sda/sda3/stat
> > > Modules linked in: aes_generic i915 drm rfcomm l2cap bluetooth
> > > cpufreq_stats cpufreq_conservative cpufreq_performance sbs sbshc
> > > dm_crypt sbp2 parport_pc lp parport pcmcia arc4 ecb crypto_blkcipher
> > > cryptomgr crypto_algapi tifm_7xx1 tifm_core yenta_socket
> > > rsrc_nonstatic pcmcia_core iwl3945 iTCO_wdt iTCO_vendor_support
> > > watchdog_core watchdog_dev snd_hda_intel mac80211 snd_pcm_oss
> > > snd_mixer_oss cfg80211 snd_pcm sky2 snd_seq_dummy snd_seq_oss
> > > snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer
> > > snd_seq_device snd soundcore snd_page_alloc shpchp pci_hotplug
> > > firewire_ohci firewire_core crc_itu_t ata_generic piix ide_core
> > >
> > > Pid: 6944, comm: cat Not tainted (2.6.24-rc5-mm1 #26)
> > > EIP: 0060:[] EFLAGS: 00210097 CPU: 0
> > > EIP is at strnlen+0x9/0x1c
> > > EAX: 0f1eff0b EBX: 0f1eff0b ECX: 0f1eff0b EDX: fffe
> > > ESI: c05b74f6 EDI: d6267d94 EBP: d6267cc8 ESP: d6267cc8
> > > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> > > Process cat (pid: 6944, ti=d6267000 task=d5a09000 task.ti=d6267000)
> > > Stack: d6267cfc c01fdd22 0400 c05b74f4 0001 c05b78f4
> > >
> > > c048f503 0400 d5a09000 0002 d6267d0c c01fdf41
> > > d6267d94
> > >db68c04a d6267d74 c012ae81 d6267d94 0028 c05b89f7 00200046
> > >
> > > Call Trace:
> > > [] show_trace_log_lvl+0x12/0x25
> > > [] show_stack_log_lvl+0x8a/0x95
> > > [] show_registers+0x8a/0x1bd
> > > [] die+0x118/0x1dc
> > > [] do_page_fault+0x5a4/0x681
> > > [] error_code+0x72/0x78
> > > [] vsnprintf+0x277/0x40e
> > > [] vscnprintf+0xe/0x1d
> > > [] vprintk+0xcb/0x2f3
> > > [] printk+0x15/0x17
> > > [] print_lock_name+0x4e/0xa2
> > > [] print_lock+0xe/0x3a
> > > [] print_usage_bug+0xbc/0x117
> > > [] mark_lock+0x2e7/0x3fe
> > > [] __lock_acquire+0x498/0xbf4
> > > [] lock_acquire+0x76/0x9d
> > > [] _read_lock+0x23/0x32
> > > [] sock_i_ino+0x14/0x30
> > > [] packet_seq_show+0x22/0x75
> > > [] seq_read+0x19d/0x26f
> > > [] proc_reg_read+0x60/0x74
> > > [] vfs_read+0x8a/0x106
> > > [] sys_read+0x3b/0x60
> > > [] sysenter_past_esp+0x6b/0xc1
> > > ===
> > > Code: 01 00 00 00 4f 89 fa 5f 89 d0 5d c3 55 85 c9 89 e5 57 89 c7 89
> > > d0 74 05 f2 ae 75 01 4f 89 f8 5f 5d c3 55 89 c1 89 e5 89 c8 eb 06 <80>
> > > 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 5d c3 90 90 90 55 83
> > > EIP: [] strnlen+0x9/0x1c SS:ESP 0068:d6267cc8
> > > note: cat[6944] exited with preempt_count 4
> >
> > I'd say you hit a networking locking bug and then when trying to report
> > that bug, lockdep crashed.
> >
> > The networking bug looks to be around sock_i_ino()'s taking of
> > sk_callback_lock with softirq's enabled. Perhaps this will fix it.
> >
> > diff -puN net/core/sock.c~a net/core/sock.c
> > --- a/net/core/sock.c~a
> > +++ a/net/core/sock.c
> > @@ -1115,9 +1115,9 @@ int sock_i_uid(struct sock *sk)
> > {
> > int uid;
> >
> > - read_lock(>sk_callback_lock);
> > + read_lock_bh(>sk_callback_lock);
> > uid = sk->sk_socket ? SOCK_INODE(sk->sk_socket)->i_uid : 0;
> > - read_unlock(>sk_callback_lock);
> > + read_unlock_bh(>sk_callback_lock);
> > return uid;
> > }
> >
> > @@ -1125,9 +1125,9 @@ unsigned long sock_i_ino(struct sock *sk
> > {
> > unsigned long ino;
> >
> > - read_lock(>sk_callback_lock);
> > + read_lock_bh(>sk_callback_lock);
> > ino = sk->sk_socket ? SOCK_INODE(sk->sk_socket)->i_ino : 0;
> > - read_unlock(>sk_callback_lock);
> > + read_unlock_bh(>sk_callback_lock);
> > return ino;
> > }
> >
> > _
> >
> >
>
> I applied the patch and then tried my test again. This time my system
> locked up.
> Perhaps I should open a new thread for this, since the problem looks
> pretty different.
>
> Dec 14 21:32:55 feargod kernel: process `cat' is using deprecated
> sysctl (syscall) net.ipv6.neigh.default.retrans_time; Use
> net.ipv6.neigh.default.retran
> s_time_ms instead.
> Dec 14 21:32:55 feargod kernel:
> Dec 14 21:32:55 feargod kernel: =
> Dec 14 21:32:55 feargod kernel:
Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?
On Fri, Dec 14, 2007 at 06:02:06PM -0800, Andrew Morton wrote: > On Sat, 15 Dec 2007 01:09:41 + Mel Gorman <[EMAIL PROTECTED]> wrote: > > > On (13/12/07 14:29), Andrew Morton didst pronounce: > > > > The simple way seems to be to malloc a large area, touch every page and > > > > then look at the physical pages assigned ... they now mostly seem to be > > > > descending in physical address. > > > > > > > > > > OIC. -mm's /proc/pid/pagemap can be used to get the pfn's... > > > > > > > I tried using pagemap to verify the patch but it triggered BUG_ON > > checks. Perhaps I am using the interface wrong but I would still not > > expect it to break in this fashion. I tried 2.6.24-rc4-mm1, 2.6.24-rc5-mm1, > > 2.6.24-rc5 with just the maps4 patches applied and 2.6.23 with maps4 patches > > applied. Each time I get errors like this; > > > > [ 90.108315] BUG: sleeping function called from invalid context at > > include/asm/uaccess_32.h:457 > > [ 90.211227] in_atomic():1, irqs_disabled():0 > > [ 90.262251] no locks held by showcontiguous/2814. > > [ 90.318475] Pid: 2814, comm: showcontiguous Not tainted 2.6.24-rc5 #1 > > [ 90.395344] [] show_trace_log_lvl+0x1a/0x30 > > [ 90.456948] [] show_trace+0x12/0x20 > > [ 90.510173] [] dump_stack+0x6e/0x80 > > [ 90.563409] [] __might_sleep+0xc3/0xe0 > > [ 90.619765] [] copy_to_user+0x3d/0x60 > > [ 90.675153] [] add_to_pagemap+0x5c/0x80 > > [ 90.732513] [] pagemap_pte_range+0x68/0xb0 > > [ 90.793010] [] walk_page_range+0x112/0x210 > > [ 90.853482] [] pagemap_read+0x176/0x220 > > [ 90.910863] [] vfs_read+0x94/0x150 > > [ 90.963058] [] sys_read+0x3d/0x70 > > [ 91.014219] [] syscall_call+0x7/0xb > > > > ... > > > > Just using cp to read the file is enough to cause problems but I included > > a very basic program below that produces the BUG_ON checks. Is this a known > > issue or am I using the interface incorrectly? > > I'd say you're using it correctly but you've found a hitherto unknown bug. > On i386 highmem machines with CONFIG_HIGHPTE (at least) pte_offset_map() > takes kmap_atomic(), so pagemap_pte_range() can't do copy_to_user() as it > presently does. Damn, I coulda sworn I fixed that. -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make WARN_ON/WARN_ON_ONCE no-ops when CONFIG_BUG is off
On Sat, Dec 15, 2007 at 12:16:59PM +0800, Herbert Xu wrote: > On Fri, Dec 14, 2007 at 12:02:46PM -0600, Matt Mackall wrote: > > > > I added CONFIG_BUG, and I think the current behavior is correct. As > > you've noticed, we have to evaluate condition, it may have > > side-effects. And if code does: > > > > /* this indicates a driver bug, report and fail gracefully */ > > if (WARN_ON(val == NULL)) > > return -EFAULT; > > That's exactly the sort of use I had in mind :) I'm actually the > one who added the ability to use WARN_ON inside an if clause. > > Just as the case of a BUG_ON, a WARN_ON should never occur in > practice, unless there is a bug which the code is not aware of. Agreed. > As such we want it to go away completely if CONFIG_BUG is off. No. The code as written above should reduce to: if (val == NULL) return -EFAULT; If I hadn't wanted to return -EFAULT in this case, I would have just written: WARN_ON(val == NULL); I don't want code that was running safely (ie returning -EFAULT) to start crashing the system just because I've, say, disabled printk. That's creating an obnoxious heisenbug. > > ..we surely want it to continue returning -EFAULT, regardless of > > whether we log it, no? What use case did you have in mind? > > If you're using it for a scenario which is known to actually > occur, then some other mechanism should be chosen in place of > WARN_ON. Then I kindly submit that you should instead withdraw the code that allows you to use WARN_ON in a condition in the first place. Note that Dave Jones is currently poking at making WARN_ON out-of-line, so you're liable to collide with him. -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
David P. Reed wrote: Just a thought for a way to fix the "very early" timing needed to set up udelay to work in a way that works on all machines. Perhaps we haven't exploited the BIOS enough: The PC BIOS since the PC AT (286) has always had a standard "countdown timer" way to delay for n microseconds, which as far as I know still works. This can be used to measure the speed of a delay loop, without using ANY in/out instructions directly (the ones in the BIOS are presumably correctly delayed...). If we enter from the 32-bit entrypoint, we already don't have access to the BIOS, though. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tmpfs: restore missing clear_highpage
On Sat, 15 Dec 2007, Adrian Bunk wrote: > On Wed, Dec 12, 2007 at 05:01:51AM +, Hugh Dickins wrote: > > On Tue, 11 Dec 2007, Chuck Ebbert wrote: > > > On 11/28/2007 01:55 PM, Hugh Dickins wrote: > > > > tmpfs was misconverted to __GFP_ZERO in 2.6.11. There's an unusual > > > > case in > > > > which shmem_getpage receives the page from its caller instead of > > > > allocating. > > > > We must cover this case by clear_highpage before SetPageUptodate, as > > > > before. > > > > > > > > Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> > > > > --- > > > > > > What are the symptoms of the bug this fixes? > > > > I've not seen it in practice, just noticed it while working on that > > area in the code. What's the polite way of describing these things > > in public? It's a vulnerability which might allow an attacker to > > access data from inside the kernel which should have been zeroed - > > in very limited circumstances I'd prefer not to have to devise and > > announce. > > > > It would also be wrong data, so could for example crash any program > > rightly relying on uninitialized static data to be zeroed - in the > > unlikely event that its data was coming via this route (in most setups > > it never can do, perhaps I'd conclude that's true of all setups). It > > has escaped notice for nearly three years, so it's not a commonplace. > > > > Further discussion offline if you like! > > Can we get or is there already a CVE number? I've not asked for one, so I don't suppose there is one: do go ahead and get one if you wish (though of course it would have been better earlier, so 2.6.22.15 and 2.6.23.10 could have cited it along with their fix: sorry about that). Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][patch 3/3] block: non-atomic queue_flags accessors
Introduce queue_ accessors to set and clear queue_flags, which include debug
checks to ensure queue_lock is held. Non-checking versions are provided where
it is known that there can be no parallelism on queue_flags.
Index: linux-2.6/block/elevator.c
===
--- linux-2.6.orig/block/elevator.c
+++ linux-2.6/block/elevator.c
@@ -1032,7 +1032,7 @@ static int elevator_switch(struct reques
*/
spin_lock_irq(q->queue_lock);
- __set_bit(QUEUE_FLAG_ELVSWITCH, >queue_flags);
+ queue_flag_set(QUEUE_FLAG_ELVSWITCH, q);
elv_drain_elevator(q);
@@ -1067,7 +1067,7 @@ static int elevator_switch(struct reques
*/
elevator_exit(old_elevator);
spin_lock_irq(q->queue_lock);
- __clear_bit(QUEUE_FLAG_ELVSWITCH, >queue_flags);
+ queue_flag_clear(QUEUE_FLAG_ELVSWITCH, q);
spin_unlock_irq(q->queue_lock);
return 1;
@@ -1082,7 +1082,7 @@ fail_register:
elv_register_queue(q);
spin_lock_irq(q->queue_lock);
- __clear_bit(QUEUE_FLAG_ELVSWITCH, >queue_flags);
+ queue_flag_clear(QUEUE_FLAG_ELVSWITCH, q);
spin_unlock_irq(q->queue_lock);
return 0;
Index: linux-2.6/block/ll_rw_blk.c
===
--- linux-2.6.orig/block/ll_rw_blk.c
+++ linux-2.6/block/ll_rw_blk.c
@@ -720,7 +720,7 @@ void blk_queue_stack_limits(struct reque
t->max_segment_size = min(t->max_segment_size,b->max_segment_size);
t->hardsect_size = max(t->hardsect_size,b->hardsect_size);
if (!test_bit(QUEUE_FLAG_CLUSTER, >queue_flags))
- __clear_bit(QUEUE_FLAG_CLUSTER, >queue_flags);
+ queue_flag_clear(QUEUE_FLAG_CLUSTER, t);
}
EXPORT_SYMBOL(blk_queue_stack_limits);
@@ -823,7 +823,7 @@ static void __blk_queue_free_tags(struct
__blk_free_tags(bqt);
q->queue_tags = NULL;
- __clear_bit(QUEUE_FLAG_QUEUED, >queue_flags);
+ queue_flag_clear(QUEUE_FLAG_QUEUED, q);
}
@@ -852,7 +852,7 @@ EXPORT_SYMBOL(blk_free_tags);
**/
void blk_queue_free_tags(struct request_queue *q)
{
- __clear_bit(QUEUE_FLAG_QUEUED, >queue_flags);
+ queue_flag_clear(QUEUE_FLAG_QUEUED, q);
}
EXPORT_SYMBOL(blk_queue_free_tags);
@@ -942,7 +942,7 @@ int blk_queue_init_tags(struct request_q
} else if (q->queue_tags) {
if ((rc = blk_queue_resize_tags(q, depth)))
return rc;
- __set_bit(QUEUE_FLAG_QUEUED, >queue_flags);
+ queue_flag_set(QUEUE_FLAG_QUEUED, q);
return 0;
} else
atomic_inc(>refcnt);
@@ -951,7 +951,7 @@ int blk_queue_init_tags(struct request_q
* assign it, all done
*/
q->queue_tags = tags;
- __set_bit(QUEUE_FLAG_QUEUED, >queue_flags);
+ queue_flag_set(QUEUE_FLAG_QUEUED, q);
INIT_LIST_HEAD(>tag_busy_list);
return 0;
fail:
@@ -1558,7 +1558,7 @@ void blk_plug_device(struct request_queu
return;
if (!test_bit(QUEUE_FLAG_PLUGGED, >queue_flags)) {
- __set_bit(QUEUE_FLAG_PLUGGED, >queue_flags);
+ queue_flag_set(QUEUE_FLAG_PLUGGED, q);
mod_timer(>unplug_timer, jiffies + q->unplug_delay);
blk_add_trace_generic(q, NULL, 0, BLK_TA_PLUG);
}
@@ -1576,7 +1576,7 @@ int blk_remove_plug(struct request_queue
if (!test_bit(QUEUE_FLAG_PLUGGED, >queue_flags))
return 0;
- __clear_bit(QUEUE_FLAG_PLUGGED, >queue_flags);
+ queue_flag_clear(QUEUE_FLAG_PLUGGED, q);
del_timer(>unplug_timer);
return 1;
@@ -1674,16 +1674,16 @@ void blk_start_queue(struct request_queu
{
WARN_ON(!irqs_disabled());
- __clear_bit(QUEUE_FLAG_STOPPED, >queue_flags);
+ queue_flag_clear(QUEUE_FLAG_STOPPED, q);
/*
* one level of recursion is ok and is much faster than kicking
* the unplug handling
*/
if (!test_bit(QUEUE_FLAG_REENTER, >queue_flags)) {
- __set_bit(QUEUE_FLAG_REENTER, >queue_flags);
+ queue_flag_set(QUEUE_FLAG_REENTER, q);
q->request_fn(q);
- __clear_bit(QUEUE_FLAG_REENTER, >queue_flags);
+ queue_flag_clear(QUEUE_FLAG_REENTER, q);
} else {
blk_plug_device(q);
kblockd_schedule_work(>unplug_work);
@@ -1709,7 +1709,7 @@ EXPORT_SYMBOL(blk_start_queue);
void blk_stop_queue(struct request_queue *q)
{
blk_remove_plug(q);
- __set_bit(QUEUE_FLAG_STOPPED, >queue_flags);
+ queue_flag_set(QUEUE_FLAG_STOPPED, q);
}
EXPORT_SYMBOL(blk_stop_queue);
@@ -1748,9 +1748,9 @@ void __blk_run_queue(struct request_queu
*/
if (!elv_queue_empty(q)) {
if (!test_bit(QUEUE_FLAG_REENTER, >queue_flags)) {
- __set_bit(QUEUE_FLAG_REENTER, >queue_flags);
[rfc][patch 2/3] block: non-atomic queue_flags
All queue_flag manipulations are performed under queue_lock (or eg. during
allocation-time where parallelism isn't a problem). So we can use non-atomic
bitops for these.
Index: linux-2.6/block/elevator.c
===
--- linux-2.6.orig/block/elevator.c
+++ linux-2.6/block/elevator.c
@@ -1032,7 +1032,7 @@ static int elevator_switch(struct reques
*/
spin_lock_irq(q->queue_lock);
- set_bit(QUEUE_FLAG_ELVSWITCH, >queue_flags);
+ __set_bit(QUEUE_FLAG_ELVSWITCH, >queue_flags);
elv_drain_elevator(q);
@@ -1067,7 +1067,7 @@ static int elevator_switch(struct reques
*/
elevator_exit(old_elevator);
spin_lock_irq(q->queue_lock);
- clear_bit(QUEUE_FLAG_ELVSWITCH, >queue_flags);
+ __clear_bit(QUEUE_FLAG_ELVSWITCH, >queue_flags);
spin_unlock_irq(q->queue_lock);
return 1;
@@ -1082,7 +1082,7 @@ fail_register:
elv_register_queue(q);
spin_lock_irq(q->queue_lock);
- clear_bit(QUEUE_FLAG_ELVSWITCH, >queue_flags);
+ __clear_bit(QUEUE_FLAG_ELVSWITCH, >queue_flags);
spin_unlock_irq(q->queue_lock);
return 0;
Index: linux-2.6/block/ll_rw_blk.c
===
--- linux-2.6.orig/block/ll_rw_blk.c
+++ linux-2.6/block/ll_rw_blk.c
@@ -720,7 +720,7 @@ void blk_queue_stack_limits(struct reque
t->max_segment_size = min(t->max_segment_size,b->max_segment_size);
t->hardsect_size = max(t->hardsect_size,b->hardsect_size);
if (!test_bit(QUEUE_FLAG_CLUSTER, >queue_flags))
- clear_bit(QUEUE_FLAG_CLUSTER, >queue_flags);
+ __clear_bit(QUEUE_FLAG_CLUSTER, >queue_flags);
}
EXPORT_SYMBOL(blk_queue_stack_limits);
@@ -823,7 +823,7 @@ static void __blk_queue_free_tags(struct
__blk_free_tags(bqt);
q->queue_tags = NULL;
- q->queue_flags &= ~(1 << QUEUE_FLAG_QUEUED);
+ __clear_bit(QUEUE_FLAG_QUEUED, >queue_flags);
}
@@ -852,7 +852,7 @@ EXPORT_SYMBOL(blk_free_tags);
**/
void blk_queue_free_tags(struct request_queue *q)
{
- clear_bit(QUEUE_FLAG_QUEUED, >queue_flags);
+ __clear_bit(QUEUE_FLAG_QUEUED, >queue_flags);
}
EXPORT_SYMBOL(blk_queue_free_tags);
@@ -942,7 +942,7 @@ int blk_queue_init_tags(struct request_q
} else if (q->queue_tags) {
if ((rc = blk_queue_resize_tags(q, depth)))
return rc;
- set_bit(QUEUE_FLAG_QUEUED, >queue_flags);
+ __set_bit(QUEUE_FLAG_QUEUED, >queue_flags);
return 0;
} else
atomic_inc(>refcnt);
@@ -951,7 +951,7 @@ int blk_queue_init_tags(struct request_q
* assign it, all done
*/
q->queue_tags = tags;
- q->queue_flags |= (1 << QUEUE_FLAG_QUEUED);
+ __set_bit(QUEUE_FLAG_QUEUED, >queue_flags);
INIT_LIST_HEAD(>tag_busy_list);
return 0;
fail:
@@ -1205,7 +1205,7 @@ static void blk_recalc_rq_segments(struc
if (!rq->bio)
return;
- cluster = q->queue_flags & (1 << QUEUE_FLAG_CLUSTER);
+ cluster = test_bit(QUEUE_FLAG_CLUSTER, >queue_flags);
hw_seg_size = seg_size = 0;
phys_size = hw_size = nr_phys_segs = nr_hw_segs = 0;
rq_for_each_segment(bv, rq, iter) {
@@ -1263,7 +1263,7 @@ new_hw_segment:
static int blk_phys_contig_segment(struct request_queue *q, struct bio *bio,
struct bio *nxt)
{
- if (!(q->queue_flags & (1 << QUEUE_FLAG_CLUSTER)))
+ if (!test_bit(QUEUE_FLAG_CLUSTER, >queue_flags))
return 0;
if (!BIOVEC_PHYS_MERGEABLE(__BVEC_END(bio), __BVEC_START(nxt)))
@@ -1310,7 +1310,7 @@ int blk_rq_map_sg(struct request_queue *
int nsegs, cluster;
nsegs = 0;
- cluster = q->queue_flags & (1 << QUEUE_FLAG_CLUSTER);
+ cluster = test_bit(QUEUE_FLAG_CLUSTER, >queue_flags);
/*
* for each bio in rq
@@ -1557,7 +1557,8 @@ void blk_plug_device(struct request_queu
if (blk_queue_stopped(q))
return;
- if (!test_and_set_bit(QUEUE_FLAG_PLUGGED, >queue_flags)) {
+ if (!test_bit(QUEUE_FLAG_PLUGGED, >queue_flags)) {
+ __set_bit(QUEUE_FLAG_PLUGGED, >queue_flags);
mod_timer(>unplug_timer, jiffies + q->unplug_delay);
blk_add_trace_generic(q, NULL, 0, BLK_TA_PLUG);
}
@@ -1573,8 +1574,9 @@ int blk_remove_plug(struct request_queue
{
WARN_ON(!irqs_disabled());
- if (!test_and_clear_bit(QUEUE_FLAG_PLUGGED, >queue_flags))
+ if (!test_bit(QUEUE_FLAG_PLUGGED, >queue_flags))
return 0;
+ __clear_bit(QUEUE_FLAG_PLUGGED, >queue_flags);
del_timer(>unplug_timer);
return 1;
@@ -1672,15 +1674,16 @@ void blk_start_queue(struct request_queu
{
WARN_ON(!irqs_disabled());
- clear_bit(QUEUE_FLAG_STOPPED,
[rfc][patch 1/3] block: non-atomic queue_flags prep
Hi,
This is just an idea I had, which might make request processing a little
bit cheaper depending on queue behaviour. For example if it is getting plugged
unplugged frequently (as I think is the case for some database workloads),
then we might save one or two atomic operations per request.
Anyway, I'm not completely sure if I have ensured all queue_flags users are
safe (I think md may need a bit of help). But overall it seems quite doable.
Comments?
---
Prep queue_flags to be non-atomic and taking protection from queue_lock.
Do this by ensuring the queue_lock is held everywhere that queue_flags
are changed. Locking additions are confined to slowpaths.
Index: linux-2.6/block/elevator.c
===
--- linux-2.6.orig/block/elevator.c
+++ linux-2.6/block/elevator.c
@@ -1066,7 +1066,10 @@ static int elevator_switch(struct reques
* finally exit old elevator and turn off BYPASS.
*/
elevator_exit(old_elevator);
+ spin_lock_irq(q->queue_lock);
clear_bit(QUEUE_FLAG_ELVSWITCH, >queue_flags);
+ spin_unlock_irq(q->queue_lock);
+
return 1;
fail_register:
@@ -1077,7 +1080,11 @@ fail_register:
elevator_exit(e);
q->elevator = old_elevator;
elv_register_queue(q);
+
+ spin_lock_irq(q->queue_lock);
clear_bit(QUEUE_FLAG_ELVSWITCH, >queue_flags);
+ spin_unlock_irq(q->queue_lock);
+
return 0;
}
Index: linux-2.6/block/ll_rw_blk.c
===
--- linux-2.6.orig/block/ll_rw_blk.c
+++ linux-2.6/block/ll_rw_blk.c
@@ -1732,14 +1732,11 @@ void blk_sync_queue(struct request_queue
EXPORT_SYMBOL(blk_sync_queue);
/**
- * blk_run_queue - run a single device queue
+ * __blk_run_queue - run a single device queue. queue_lock must be held.
* @q: The queue to run
*/
-void blk_run_queue(struct request_queue *q)
+void __blk_run_queue(struct request_queue *q)
{
- unsigned long flags;
-
- spin_lock_irqsave(q->queue_lock, flags);
blk_remove_plug(q);
/*
@@ -1755,7 +1752,19 @@ void blk_run_queue(struct request_queue
kblockd_schedule_work(>unplug_work);
}
}
+}
+EXPORT_SYMBOL(__blk_run_queue);
+/**
+ * blk_run_queue - run a single device queue
+ * @q: The queue to run
+ */
+void blk_run_queue(struct request_queue *q)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(q->queue_lock, flags);
+ __blk_run_queue(q);
spin_unlock_irqrestore(q->queue_lock, flags);
}
EXPORT_SYMBOL(blk_run_queue);
@@ -1804,7 +1813,9 @@ EXPORT_SYMBOL(blk_put_queue);
void blk_cleanup_queue(struct request_queue * q)
{
mutex_lock(>sysfs_lock);
+ spin_lock_irq(q->queue_lock);
set_bit(QUEUE_FLAG_DEAD, >queue_flags);
+ spin_unlock_irq(q->queue_lock);
mutex_unlock(>sysfs_lock);
if (q->elevator)
Index: linux-2.6/drivers/scsi/scsi_lib.c
===
--- linux-2.6.orig/drivers/scsi/scsi_lib.c
+++ linux-2.6/drivers/scsi/scsi_lib.c
@@ -532,6 +532,9 @@ static void scsi_run_queue(struct reques
!shost->host_blocked && !shost->host_self_blocked &&
!((shost->can_queue > 0) &&
(shost->host_busy >= shost->can_queue))) {
+
+ int flagset;
+
/*
* As long as shost is accepting commands and we have
* starved queues, call blk_run_queue. scsi_request_fn
@@ -547,17 +550,17 @@ static void scsi_run_queue(struct reques
list_del_init(>starved_entry);
spin_unlock_irqrestore(shost->host_lock, flags);
-
- if (test_bit(QUEUE_FLAG_REENTER, >queue_flags) &&
- !test_and_set_bit(QUEUE_FLAG_REENTER,
- >request_queue->queue_flags)) {
- blk_run_queue(sdev->request_queue);
+ spin_lock(sdev->request_queue->queue_lock);
+ flagset = test_bit(QUEUE_FLAG_REENTER, >queue_flags) &&
+ !test_and_set_bit(QUEUE_FLAG_REENTER,
+ >request_queue->queue_flags);
+ __blk_run_queue(sdev->request_queue);
+ if (flagset)
clear_bit(QUEUE_FLAG_REENTER,
- >request_queue->queue_flags);
- } else
- blk_run_queue(sdev->request_queue);
+ >request_queue->queue_flags);
+ spin_unlock(sdev->request_queue->queue_lock);
- spin_lock_irqsave(shost->host_lock, flags);
+ spin_lock(shost->host_lock);
if (unlikely(!list_empty(>starved_entry)))
/*
* sdev lost a race, and was put back on the
Index: linux-2.6/drivers/block/loop.c
Re: [patch 01/10] e1000e: make E1000E default to the same kconfig setting as E1000
On Fri, 14 Dec 2007, Andrew Morton wrote: > On Fri, 14 Dec 2007 15:39:26 -0500 > Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > [EMAIL PROTECTED] wrote: > > > From: Randy Dunlap <[EMAIL PROTECTED]> > > > > > > Make E1000E default to the same kconfig setting as E1000. So people's > > > machiens don't stop working when they use oldconfig. > > > > > I am not inclined to apply this one. This practice, applied over time, > > will tend to accumulate weird 'default' and 'select' statements. > > > > So I think the breakage that occurs is mitigated by two factors: > > 1) kernel hackers that do their own configs are expected to be able to > > figure this stuff. > > 2) kernel builders (read: distros, mainly) are expected to have put > > thought into the Kconfig selection and driver migration strategies. > > > > PCI IDs move across drivers from time, and we don't want to apply these > > sorts changes: Viewed in the long term, the suggested patch is merely a > > temporary change to allow kernel experts to more easily deal with the > > PCI ID migration across drivers. > > > > I would prefer simply to communicate to kernel experts and builders > > about a Kconfig issue that could potentially their booting/networking... > > because this patch is only needed if the kernel experts do not already > > know about a necessary config update. > > You can take it out again later on - most people's .configs will then have > E1000E set. People who still do `cp ancientconfig .config ; make oldconfig' > remain screwed. I was thinking the same thing. Leave it in for 2 or 3 major versions and then remove it (something analogous to the timeframe for a feature removal). And during the interim period, add something like the following to the Kconfig help text: Note some hardware that was previously supported by the e1000 driver is now only handled by the e1000e driver. If unsure and you previously used the e1000 driver, say Y or M here. > I dunno. I guess I'm not into causing people pain in an attempt to train > them to do what we want. This is a popular driver and a *lot* of people > are going to: > > - build new kernel > > - install new kernel > > - find it doesn't work, go through quite large amounts of hassle trying > to work out why it stopped working. Eventually work out that e1000 > stopped working. Eventually work out that it stopped working because we > forcibly switched them to a new driver which they didn't know about. > > - reconfigure kernel > > - rebuild, reinstall Having been there, done that, it's definitely a pain. It's especially painful when you're doing it remotely, and since the network no longer works, you can't get into the system anymore. > Multiply that by 100s of people (at least). All because Jeff wouldn't > apply a one-liner? -Bill -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] gpiolib: add support for PCA9539
Jean, I'd like to postpone the corresponding change to the point that polling i2c patch is merged. On Dec 15, 2007 12:16 AM, Jean Delvare <[EMAIL PROTECTED]> wrote: > Hi Eric, > > > On Mon, 10 Dec 2007 17:37:05 +0800, eric miao wrote: > > Support for PCA9539 as a GPIO chip is separated into two patches: > > > > 0001 - gpiolib: basic support for 16-bit PCA9539 GPIO expander > > 0002 - gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander > > > > the 2nd one uses workqueue for IRQ handling due to the interrupt mode > > nature of the i2c-core, thus making it a separate patch. > > Note that the situation could change according to the discussion in > this thread: > http://lists.lm-sensors.org/pipermail/i2c/2007-December/002378.html > > -- > Jean Delvare > -- Cheers - eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 9:27 PM, Larry Finger <[EMAIL PROTECTED]> wrote: > > I suspect that mac80211 is doing something that your router does not like. Do > you have any chance to > capture the traffic between your computer and the router by using a second > wireless computer running > kismet or wireshark? A look at the differences between b43 and bcm43xx should > show the reason. > Hi Larry, thanks for replying. I have to admit, I've never used either of these before, so I'm not sure if I did this correctly. I created two different packet dumps using kismet, one when my laptop was using b43 and the other when it was using bcm43xx. While my desktop was logging, I used my laptop to go to kernel.org and download patch-2.6.23.11.bz2 (both times the browser started at http://www.kernel.org/pub/linux/kernel/). Then I used tshark to parse the dump files and create two new readable logs. I'll attach these logs since I can't read much into them. The only strange difference I noticed is that with b43, I got messages like ICMP Destination unreachable (Host administratively prohibited), which I didn't get with bcm43xx. There's about 5 machines connected to this network -- the laptop with the broadcom card has internal ip 192.168.0.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: /dev/urandom uses uninit bytes, leaks user data
On Fri, Dec 14, 2007 at 04:30:08PM -0800, John Reiser wrote: > There is a path that goes from user data into the pool. This path > is subject to manipulation by an attacker, for both reading and > writing. Are you going to guarantee that in five years nobody > will discover a way to take advantage of it? Five years ago > there were no public attacks against MD5 except brute force; > now MD5 is on the "weak" list. Yep, I'm confident about making such a guarantee. Very confident. First of all, keep in mind that the attacks on MD5 are about being able to find hash collisions. The way the cryptographic hash is being used in /dev/random, merely being able to find hash collision means squat. You need to be able to carry out a preimage attack; which no one has been able to do yet. And even if you could figure out how to do a pre-image attack (which none of the "successful attacks" on MD4, MD5, SHA-0, HAVAL-128, RIPEMD, et. al have been able to acomplish), we don't give you the entire hash output; instead, what you get is the hash folded in half via XOR, so you only get the two halves of the SHA hash XOR'ed together to form 80 bits. So given one of these folded 80 bits of hash, you need to figure out a large number of the possible combinations 1024 bits that were in secondry entropy pool could have resulted in the folded hash image. And using the pigeon-hole princple and assuming that SHA approximates a random function, you need to figure out which one of the 2**944 possible combination of 1024 bits was the correct pool pre-image that generated those 80 bits. That's a hard problem. But secondly, even *that's* not enough. As I said earlier, the pool is simply unavailable to the attacker; we never make it available, except by revealing 80 bit hashes of the pool. So you can't read the initial or current state of the pool without first breaking root --- and after 3 bytes of kernel stack is mixed into the pool, via an XOR operation, there is no way to read out the pool. And if you don't know the initial contents of the pool --- funny thing, but UNKNOWN XOR KNOWN == UNKNOWN. So here I'm not even relying on cryptographers of the future not being able to find preimage attacks. I'm just relying on simple logic. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.24-rc5-mm 3/3] gpiolib: obsolete drivers/i2c/chips/pca9539.c
>From 0bca662f68e7ffe84f333d7d26df25d846713db2 Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Sat, 15 Dec 2007 12:07:26 +0800
Subject: [PATCH] gpiolib: obsolete drivers/i2c/chips/pca9539.c
for the following reasons:
1. there is currently no known users of this driver
2. the functionality of this driver is well supported with the recent
proposed drivers/gpio/pca9539.c, using GPIO_LIB
Signed-off-by: eric miao <[EMAIL PROTECTED]>
Acked-by: Ben Gardner <[EMAIL PROTECTED]>
---
drivers/i2c/chips/Kconfig | 10 --
drivers/i2c/chips/Makefile |1 -
drivers/i2c/chips/pca9539.c | 196 ---
3 files changed, 0 insertions(+), 207 deletions(-)
delete mode 100644 drivers/i2c/chips/pca9539.c
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index 2e1c24f..a676f57 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -65,16 +65,6 @@ config SENSORS_PCF8574
These devices are hard to detect and rarely found on mainstream
hardware. If unsure, say N.
-config SENSORS_PCA9539
- tristate "Philips PCA9539 16-bit I/O port"
- depends on EXPERIMENTAL
- help
- If you say yes here you get support for the Philips PCA9539
- 16-bit I/O port.
-
- This driver can also be built as a module. If so, the module
- will be called pca9539.
-
config SENSORS_PCF8591
tristate "Philips PCF8591"
depends on EXPERIMENTAL
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index ca924e1..bc9e9ca 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -8,7 +8,6 @@ obj-$(CONFIG_DS1682)+= ds1682.o
obj-$(CONFIG_SENSORS_EEPROM) += eeprom.o
obj-$(CONFIG_SENSORS_MAX6875) += max6875.o
obj-$(CONFIG_SENSORS_M41T00) += m41t00.o
-obj-$(CONFIG_SENSORS_PCA9539) += pca9539.o
obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
diff --git a/drivers/i2c/chips/pca9539.c b/drivers/i2c/chips/pca9539.c
deleted file mode 100644
index f43c4e7..000
--- a/drivers/i2c/chips/pca9539.c
+++ /dev/null
@@ -1,196 +0,0 @@
-/*
-pca9539.c - 16-bit I/O port with interrupt and reset
-
-Copyright (C) 2005 Ben Gardner <[EMAIL PROTECTED]>
-
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; version 2 of the License.
-*/
-
-#include
-#include
-#include
-#include
-#include
-
-/* Addresses to scan */
-static unsigned short normal_i2c[] = {0x74, 0x75, 0x76, 0x77, I2C_CLIENT_END};
-
-/* Insmod parameters */
-I2C_CLIENT_INSMOD_1(pca9539);
-
-enum pca9539_cmd
-{
- PCA9539_INPUT_0 = 0,
- PCA9539_INPUT_1 = 1,
- PCA9539_OUTPUT_0= 2,
- PCA9539_OUTPUT_1= 3,
- PCA9539_INVERT_0= 4,
- PCA9539_INVERT_1= 5,
- PCA9539_DIRECTION_0 = 6,
- PCA9539_DIRECTION_1 = 7,
-};
-
-static int pca9539_attach_adapter(struct i2c_adapter *adapter);
-static int pca9539_detect(struct i2c_adapter *adapter, int address, int kind);
-static int pca9539_detach_client(struct i2c_client *client);
-
-/* This is the driver that will be inserted */
-static struct i2c_driver pca9539_driver = {
- .driver = {
- .name = "pca9539",
- },
- .attach_adapter = pca9539_attach_adapter,
- .detach_client = pca9539_detach_client,
-};
-
-struct pca9539_data {
- struct i2c_client client;
-};
-
-/* following are the sysfs callback functions */
-static ssize_t pca9539_show(struct device *dev, struct device_attribute *attr,
- char *buf)
-{
- struct sensor_device_attribute *psa = to_sensor_dev_attr(attr);
- struct i2c_client *client = to_i2c_client(dev);
- return sprintf(buf, "%d\n", i2c_smbus_read_byte_data(client,
-psa->index));
-}
-
-static ssize_t pca9539_store(struct device *dev, struct device_attribute *attr,
-const char *buf, size_t count)
-{
- struct sensor_device_attribute *psa = to_sensor_dev_attr(attr);
- struct i2c_client *client = to_i2c_client(dev);
- unsigned long val = simple_strtoul(buf, NULL, 0);
- if (val > 0xff)
- return -EINVAL;
- i2c_smbus_write_byte_data(client, psa->index, val);
- return count;
-}
-
-/* Define the device attributes */
-
-#define PCA9539_ENTRY_RO(name, cmd_idx) \
- static SENSOR_DEVICE_ATTR(name, S_IRUGO, pca9539_show, NULL, cmd_idx)
-
-#define PCA9539_ENTRY_RW(name, cmd_idx) \
- static SENSOR_DEVICE_ATTR(name, S_IRUGO | S_IWUSR, pca9539_show, \
- pca9539_store, cmd_idx)
-
-PCA9539_ENTRY_RO(input0, PCA9539_INPUT_0);
-PCA9539_ENTRY_RO(input1, PCA9539_INPUT_1);
Re: [PATCH] Make WARN_ON/WARN_ON_ONCE no-ops when CONFIG_BUG is off
On Fri, Dec 14, 2007 at 12:02:46PM -0600, Matt Mackall wrote:
>
> I added CONFIG_BUG, and I think the current behavior is correct. As
> you've noticed, we have to evaluate condition, it may have
> side-effects. And if code does:
>
> /* this indicates a driver bug, report and fail gracefully */
> if (WARN_ON(val == NULL))
> return -EFAULT;
That's exactly the sort of use I had in mind :) I'm actually the
one who added the ability to use WARN_ON inside an if clause.
Just as the case of a BUG_ON, a WARN_ON should never occur in
practice, unless there is a bug which the code is not aware of.
As such we want it to go away completely if CONFIG_BUG is off.
> ..we surely want it to continue returning -EFAULT, regardless of
> whether we log it, no? What use case did you have in mind?
If you're using it for a scenario which is known to actually
occur, then some other mechanism should be chosen in place of
WARN_ON.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.24-rc5-mm 2/3] gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander
>From b45be77acbf592b9c2085ed03ab5f16d780fa8c7 Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:24:36 +0800
Subject: [PATCH] gpiolib: add Generic IRQ support for 16-bit PCA9539
GPIO expander
This patch adds the generic IRQ support for the PCA9539 on-chip GPIOs.
Note: due to the inaccessibility of the generic IRQ code within modules,
this support is only available if the driver is built-in.
Signed-off-by: eric miao <[EMAIL PROTECTED]>
---
drivers/gpio/Kconfig | 11 +++-
drivers/gpio/pca9539.c | 183
2 files changed, 193 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 4b54f60..a4f89a6 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -17,7 +17,16 @@ config GPIO_PCA9539
parts are made by NXP and TI.
This driver can also be built as a module. If so, the module
- will be called pca9539.
+ will be called pca9539. Note: the Generic IRQ support for the
+ chip will only be available if the driver is built-in
+
+config GPIO_PCA9539_GENERIC_IRQ
+ bool "Generic IRQ support for PCA9539"
+ depends on GPIO_PCA9539=y && GENERIC_HARDIRQS
+ help
+ Say yes here to support the Generic IRQ for the PCA9539 on-chip
+ GPIO lines. Only pin-changed IRQs (IRQ_TYPE_EDGE_BOTH) are
+ supported in hardware.
config GPIO_PCF857X
tristate "PCF857x, PCA857x, and PCA967x I2C GPIO expanders"
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
index 955d891..ad3267b 100644
--- a/drivers/gpio/pca9539.c
+++ b/drivers/gpio/pca9539.c
@@ -14,6 +14,9 @@
#include
#include
+#include
+#include
+#include
#include
#include
@@ -33,6 +36,22 @@ struct pca9539_chip {
struct i2c_client *client;
struct gpio_chip gpio_chip;
+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+ /*
+* Note: Generic IRQ is not accessible within module code, the IRQ
+* support will thus _only_ be available if the driver is built-in
+*/
+ int irq;/* IRQ for the chip itself */
+ int irq_start; /* starting IRQ for the on-chip GPIO lines */
+
+ uint16_t irq_mask;
+ uint16_t irq_falling_edge;
+ uint16_t irq_rising_edge;
+ uint16_t last_input;
+
+ struct irq_chip irq_chip;
+ struct work_struct irq_work;
+#endif
};
static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
@@ -155,6 +174,156 @@ static int pca9539_init_gpio(struct pca9539_chip *chip)
return gpiochip_add(gc);
}
+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+/* FIXME: change to schedule_delayed_work() here if reading out of
+ * registers does not reflect the actual pin levels
+ */
+
+static void pca9539_irq_work(struct work_struct *work)
+{
+ struct pca9539_chip *chip;
+ uint16_t input, mask, rising, falling;
+ int ret, i;
+
+ chip = container_of(work, struct pca9539_chip, irq_work);
+
+ ret = pca9539_read_reg(chip, PCA9539_INPUT, );
+ if (ret < 0)
+ return;
+
+ mask = (input ^ chip->last_input) & chip->irq_mask;
+ rising = (input & mask) & chip->irq_rising_edge;
+ falling = (~input & mask) & chip->irq_falling_edge;
+
+ irq_enter();
+
+ for (i = 0; i < NR_PCA9539_GPIOS; i++) {
+ if ((rising | falling) & (1u << i)) {
+ int irq = chip->irq_start + i;
+ struct irq_desc *desc;
+
+ desc = irq_desc + irq;
+ desc_handle_irq(irq, desc);
+ }
+ }
+
+ irq_exit();
+
+ chip->last_input = input;
+}
+
+static void fastcall
+pca9539_irq_demux(unsigned int irq, struct irq_desc *desc)
+{
+ struct pca9539_chip *chip = desc->handler_data;
+
+ desc->chip->mask(chip->irq);
+ desc->chip->ack(chip->irq);
+ schedule_work(>irq_work);
+ desc->chip->unmask(chip->irq);
+}
+
+static void pca9539_irq_mask(unsigned int irq)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct pca9539_chip *chip = desc->chip_data;
+
+ chip->irq_mask &= ~(1u << (irq - chip->irq_start));
+}
+
+static void pca9539_irq_unmask(unsigned int irq)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct pca9539_chip *chip = desc->chip_data;
+
+ chip->irq_mask |= 1u << (irq - chip->irq_start);
+}
+
+static void pca9539_irq_ack(unsigned int irq)
+{
+ /* unfortunately, we have to provide an empty irq_chip.ack even
+* if we do nothing here, Generic IRQ will complain otherwise
+*/
+}
+
+static int pca9539_irq_set_type(unsigned int irq, unsigned int type)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct pca9539_chip *chip = desc->chip_data;
+ uint16_t mask = 1u << (irq - chip->irq_start);
+
+ if (type == IRQT_PROBE) {
+ if ((mask & chip->irq_rising_edge) ||
+
[PATCH 2.6.24-rc5-mm 1/3] gpiolib: basic support for 16-bit PCA9539 GPIO expander
>From 5ebe07236b99587296cbf603a965d284ceaf Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:19:12 +0800
Subject: [PATCH] gpiolib: basic support for 16-bit PCA9539 GPIO expander
1. use 16-bit register access to simplify the logic, cache OUTPUT
and DIRECTION registers for fast access
2. platform code is required to setup
a) the numbering of GPIO for PCA9539 (base and number)
c) pass "pca9539_platform_data" within "i2c_board_info"
Derived from drivers/i2c/chips/pca9539.c (which has no current known
users).
Signed-off-by: eric miao <[EMAIL PROTECTED]>
---
drivers/gpio/Kconfig| 10 ++
drivers/gpio/Makefile |1 +
drivers/gpio/pca9539.c | 247 +++
include/linux/i2c/pca9539.h | 18 +++
4 files changed, 276 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/pca9539.c
create mode 100644 include/linux/i2c/pca9539.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index dd9e697..4b54f60 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -9,6 +9,16 @@ menu "GPIO Expanders"
comment "I2C GPIO expanders:"
+config GPIO_PCA9539
+ tristate "PCA9539 16-bit I/O port"
+ depends on I2C
+ help
+ Say yes here to support the PCA9539 16-bit I/O port. These
+ parts are made by NXP and TI.
+
+ This driver can also be built as a module. If so, the module
+ will be called pca9539.
+
config GPIO_PCF857X
tristate "PCF857x, PCA857x, and PCA967x I2C GPIO expanders"
depends on I2C
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 575bb57..d14fc1e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -1,4 +1,5 @@
# gpio support: dedicated expander chips, etc
obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
+obj-$(CONFIG_GPIO_PCA9539) += pca9539.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
new file mode 100644
index 000..955d891
--- /dev/null
+++ b/drivers/gpio/pca9539.c
@@ -0,0 +1,247 @@
+/*
+ * pca9539.c - 16-bit I/O port with interrupt and reset
+ *
+ * Copyright (C) 2005 Ben Gardner <[EMAIL PROTECTED]>
+ * Copyright (C) 2007 Marvell International Ltd.
+ *
+ * Derived from drivers/i2c/chips/pca9539.c (which has no current known
+ * users).
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+#define NR_PCA9539_GPIOS 16
+
+#define PCA9539_INPUT 0
+#define PCA9539_OUTPUT 2
+#define PCA9539_INVERT 4
+#define PCA9539_DIRECTION 6
+
+struct pca9539_chip {
+ unsigned gpio_start;
+ uint16_t reg_output;
+ uint16_t reg_direction;
+
+ struct i2c_client *client;
+ struct gpio_chip gpio_chip;
+};
+
+static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
+{
+ return i2c_smbus_write_word_data(chip->client, reg, val);
+}
+
+static int pca9539_read_reg(struct pca9539_chip *chip, int reg, uint16_t *val)
+{
+ int ret;
+
+ ret = i2c_smbus_read_word_data(chip->client, reg);
+ if (ret < 0) {
+ dev_err(>client->dev, "failed reading register\n");
+ return ret;
+ }
+
+ *val = (uint16_t)ret;
+ return 0;
+}
+
+static int pca9539_gpio_direction_input(struct gpio_chip *gc, unsigned off)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ reg_val = chip->reg_direction | (1u << off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return ret;
+
+ chip->reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gpio_direction_output(struct gpio_chip *gc,
+ unsigned off, int val)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ /* set output level */
+ if (val)
+ reg_val = chip->reg_output | (1u << off);
+ else
+ reg_val = chip->reg_output & ~(1u << off);
+
+ ret = pca9539_write_reg(chip, PCA9539_OUTPUT, reg_val);
+ if (ret)
+ return ret;
+
+ chip->reg_output = reg_val;
+
+ /* then direction */
+ reg_val = chip->reg_direction & ~(1u << off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return ret;
+
+ chip->reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gpio_get_value(struct gpio_chip *gc, unsigned off)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip =
[PATCH 2.6.24-rc5-mm 0/3] gpiolib: add support for NXP/TI PCA9539
[updated] support for PCA9539 as a GPIO chip is separated into three patches: 0001 - gpiolib: basic support for 16-bit PCA9539 GPIO expander 0002 - gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander 0003 - gpiolib: obsolete drivers/i2c/chips/pca9539.c The 2nd one uses workqueue for IRQ handling due to the interrupt mode nature of the i2c-core, thus making it a separate patch. -- Cheers - eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] Linux 2.6.23.10
On Sat, Dec 15, 2007 at 03:55:40AM +0100, Rafael J. Wysocki wrote: > On Saturday, 15 of December 2007, Rafael J. Wysocki wrote: > > On Saturday, 15 of December 2007, Chuck Ebbert wrote: > > > On 12/14/2007 08:52 PM, Rafael J. Wysocki wrote: > > > > On Saturday, 15 of December 2007, Chuck Ebbert wrote: > > > >> On 12/14/2007 02:49 PM, Greg Kroah-Hartman wrote: > > > >>> Freezer: Fix APM emulation breakage > > > >> drivers/char/apm-emulation.c: In function 'apm_ioctl': > > > >> drivers/char/apm-emulation.c:370: error: implicit declaration of > > > >> function 'wait_event_freezable' > > > >> make[2]: *** [drivers/char/apm-emulation.o] Error 1 > > > >> make[1]: *** [drivers/char] Error 2 > > > > > > > > This is my fault, sorry. > > > > > > > > I though the 2.6.24-rc fix would be suitable for 2.6.23.x, but that's > > > > not the > > > > case. > > > > > > > > Greg, please revert the "Freezer: Fix APM emulation breakage" patch, > > > > I'll > > > > prepare a separate fix suitable for -stable. > > > > > > > > > > It works if you add the changes to freezer.h made in commit > > > e42837bcd35b75bb59ae5d3e62f87be1aeeb05c3 > > > > Yes, exactly, but a new patch is needed anyway. > > > > Hmm, perhaps it's better to add a new patch on top of "Freezer: Fix APM > > emulation breakage"? Would that be preferred? > > For convenience, below is the patch that should fix the breakage when applied > on top of the "Freezer: Fix APM emulation breakage" patch. Can you send me a whole new patch that works properly for the next 2.6.23-stable release? 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: Linux 2.6.23.11
diff --git a/Makefile b/Makefile
index 3f2c4e3..ada10d5 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 23
-EXTRAVERSION = .10
+EXTRAVERSION = .11
NAME = Arr Matey! A Hairy Bilge Rat!
# *DOCUMENTATION*
diff --git a/drivers/char/apm-emulation.c b/drivers/char/apm-emulation.c
index 72183bd..ec116df 100644
--- a/drivers/char/apm-emulation.c
+++ b/drivers/char/apm-emulation.c
@@ -295,6 +295,7 @@ static int
apm_ioctl(struct inode * inode, struct file *filp, u_int cmd, u_long arg)
{
struct apm_user *as = filp->private_data;
+ unsigned long flags;
int err = -EINVAL;
if (!as->suser || !as->writer)
@@ -330,16 +331,10 @@ apm_ioctl(struct inode * inode, struct file *filp, u_int
cmd, u_long arg)
* Wait for the suspend/resume to complete. If there
* are pending acknowledges, we wait here for them.
*/
- freezer_do_not_count();
+ flags = current->flags;
wait_event(apm_suspend_waitqueue,
as->suspend_state == SUSPEND_DONE);
-
- /*
-* Since we are waiting until the suspend is done, the
-* try_to_freeze() in freezer_count() will not trigger
-*/
- freezer_count();
} else {
as->suspend_state = SUSPEND_WAIT;
mutex_unlock(_lock);
@@ -367,10 +362,14 @@ apm_ioctl(struct inode * inode, struct file *filp, u_int
cmd, u_long arg)
* Wait for the suspend/resume to complete. If there
* are pending acknowledges, we wait here for them.
*/
- wait_event_freezable(apm_suspend_waitqueue,
+ flags = current->flags;
+
+ wait_event_interruptible(apm_suspend_waitqueue,
as->suspend_state == SUSPEND_DONE);
}
+ current->flags = flags;
+
mutex_lock(_lock);
err = as->suspend_result;
as->suspend_state = SUSPEND_NONE;
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index eb57502..bc40377 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -44,7 +44,7 @@ int __init br_fdb_init(void)
return 0;
}
-void __exit br_fdb_fini(void)
+void br_fdb_fini(void)
{
kmem_cache_destroy(br_fdb_cache);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux 2.6.23.11
We (the -stable team) are announcing the release of the 2.6.23.11 kernel. It fixes two build errors in the 2.6.23.10 kernel. If you have no problems with 2.6.23.10, then be happy and don't waste the electrons on downloading another release. I'll also be replying to this message with a copy of the patch between 2.6.23.10 and 2.6.23.11 The updated 2.6.23.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.23.y.git and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=summary thanks, greg k-h Makefile |2 +- drivers/char/apm-emulation.c | 15 +++ net/bridge/br_fdb.c |2 +- 3 files changed, 9 insertions(+), 10 deletions(-) Summary of changes from v2.6.23.10 to v2.6.23.11 Andrew Morton (1): BRIDGE: Section fix. Greg Kroah-Hartman (2): Revert "Freezer: Fix APM emulation breakage" Linux 2.6.23.11 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.24-rc4-mm 1/2] gpiolib: basic support for 16-bit PCA9539 GPIO expander[
I'd like to create another thread in LKML for the updated version, sorry.
On Dec 15, 2007 11:56 AM, eric miao <[EMAIL PROTECTED]> wrote:
> OK,
>
> Here's the updated version, which
> 1. modify the author info but still preserve Ben's credit in the source head
> 2. Alphabetic order in Kconfig/Makefile
> 3. typo fix and corrected Philips to NXP/TI
> 4. use dev_err instead of printk
> 5. move module_{init,exit} next to the routines
> 6. preserve initial output/direction register settings
>
> Also I'd like to fire another patch to obsolete drivers/i2c/chips/pca9539.c
> as everyone agreed.
>
> From 5ebe07236b99587296cbf603a965d284ceaf Mon Sep 17 00:00:00 2001
> From: eric miao <[EMAIL PROTECTED]>
> Date: Mon, 10 Dec 2007 17:19:12 +0800
> Subject: [PATCH] gpiolib: basic support for 16-bit PCA9539 GPIO expander
>
> 1. use 16-bit register access to simplify the logic, cache OUTPUT
>and DIRECTION registers for fast access
>
> 2. platform code is required to setup
>a) the numbering of GPIO for PCA9539 (base and number)
>c) pass "pca9539_platform_data" within "i2c_board_info"
>
> Derived from drivers/i2c/chips/pca9539.c (which has no current known
> users).
>
> Signed-off-by: eric miao <[EMAIL PROTECTED]>
> ---
> drivers/gpio/Kconfig| 10 ++
> drivers/gpio/Makefile |1 +
> drivers/gpio/pca9539.c | 247
> +++
> include/linux/i2c/pca9539.h | 18 +++
> 4 files changed, 276 insertions(+), 0 deletions(-)
> create mode 100644 drivers/gpio/pca9539.c
> create mode 100644 include/linux/i2c/pca9539.h
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index dd9e697..4b54f60 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -9,6 +9,16 @@ menu "GPIO Expanders"
>
> comment "I2C GPIO expanders:"
>
> +config GPIO_PCA9539
> + tristate "PCA9539 16-bit I/O port"
> + depends on I2C
> + help
> + Say yes here to support the PCA9539 16-bit I/O port. These
> + parts are made by NXP and TI.
> +
> + This driver can also be built as a module. If so, the module
> + will be called pca9539.
> +
> config GPIO_PCF857X
> tristate "PCF857x, PCA857x, and PCA967x I2C GPIO expanders"
> depends on I2C
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 575bb57..d14fc1e 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -1,4 +1,5 @@
> # gpio support: dedicated expander chips, etc
>
> obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
> +obj-$(CONFIG_GPIO_PCA9539) += pca9539.o
> obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
> diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
> new file mode 100644
> index 000..955d891
> --- /dev/null
> +++ b/drivers/gpio/pca9539.c
> @@ -0,0 +1,247 @@
> +/*
> + * pca9539.c - 16-bit I/O port with interrupt and reset
> + *
> + * Copyright (C) 2005 Ben Gardner <[EMAIL PROTECTED]>
> + * Copyright (C) 2007 Marvell International Ltd.
> + *
> + * Derived from drivers/i2c/chips/pca9539.c (which has no current known
> + * users).
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#define NR_PCA9539_GPIOS 16
> +
> +#define PCA9539_INPUT 0
> +#define PCA9539_OUTPUT 2
> +#define PCA9539_INVERT 4
> +#define PCA9539_DIRECTION 6
> +
> +struct pca9539_chip {
> + unsigned gpio_start;
> + uint16_t reg_output;
> + uint16_t reg_direction;
> +
> + struct i2c_client *client;
> + struct gpio_chip gpio_chip;
> +};
> +
> +static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t
> val)
> +{
> + return i2c_smbus_write_word_data(chip->client, reg, val);
> +}
> +
> +static int pca9539_read_reg(struct pca9539_chip *chip, int reg, uint16_t
> *val)
> +{
> + int ret;
> +
> + ret = i2c_smbus_read_word_data(chip->client, reg);
> + if (ret < 0) {
> + dev_err(>client->dev, "failed reading register\n");
>
> + return ret;
> + }
> +
> + *val = (uint16_t)ret;
> + return 0;
> +}
> +
> +static int pca9539_gpio_direction_input(struct gpio_chip *gc, unsigned off)
> +{
> + struct pca9539_chip *chip;
> + uint16_t reg_val;
> + int ret;
> +
> + chip = container_of(gc, struct pca9539_chip, gpio_chip);
> +
> + reg_val = chip->reg_direction | (1u << off);
> + ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
> + if (ret)
> + return ret;
> +
> + chip->reg_direction = reg_val;
> + return 0;
> +}
> +
> +static int pca9539_gpio_direction_output(struct gpio_chip *gc,
> + unsigned off, int val)
> +{
> + struct pca9539_chip *chip;
> +
Re: [PATCH 2.6.24-rc4-mm 1/2] gpiolib: basic support for 16-bit PCA9539 GPIO expander[
OK,
Here's the updated version, which
1. modify the author info but still preserve Ben's credit in the source head
2. Alphabetic order in Kconfig/Makefile
3. typo fix and corrected Philips to NXP/TI
4. use dev_err instead of printk
5. move module_{init,exit} next to the routines
6. preserve initial output/direction register settings
Also I'd like to fire another patch to obsolete drivers/i2c/chips/pca9539.c
as everyone agreed.
>From 5ebe07236b99587296cbf603a965d284ceaf Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:19:12 +0800
Subject: [PATCH] gpiolib: basic support for 16-bit PCA9539 GPIO expander
1. use 16-bit register access to simplify the logic, cache OUTPUT
and DIRECTION registers for fast access
2. platform code is required to setup
a) the numbering of GPIO for PCA9539 (base and number)
c) pass "pca9539_platform_data" within "i2c_board_info"
Derived from drivers/i2c/chips/pca9539.c (which has no current known
users).
Signed-off-by: eric miao <[EMAIL PROTECTED]>
---
drivers/gpio/Kconfig| 10 ++
drivers/gpio/Makefile |1 +
drivers/gpio/pca9539.c | 247 +++
include/linux/i2c/pca9539.h | 18 +++
4 files changed, 276 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/pca9539.c
create mode 100644 include/linux/i2c/pca9539.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index dd9e697..4b54f60 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -9,6 +9,16 @@ menu "GPIO Expanders"
comment "I2C GPIO expanders:"
+config GPIO_PCA9539
+ tristate "PCA9539 16-bit I/O port"
+ depends on I2C
+ help
+ Say yes here to support the PCA9539 16-bit I/O port. These
+ parts are made by NXP and TI.
+
+ This driver can also be built as a module. If so, the module
+ will be called pca9539.
+
config GPIO_PCF857X
tristate "PCF857x, PCA857x, and PCA967x I2C GPIO expanders"
depends on I2C
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 575bb57..d14fc1e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -1,4 +1,5 @@
# gpio support: dedicated expander chips, etc
obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
+obj-$(CONFIG_GPIO_PCA9539) += pca9539.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
new file mode 100644
index 000..955d891
--- /dev/null
+++ b/drivers/gpio/pca9539.c
@@ -0,0 +1,247 @@
+/*
+ * pca9539.c - 16-bit I/O port with interrupt and reset
+ *
+ * Copyright (C) 2005 Ben Gardner <[EMAIL PROTECTED]>
+ * Copyright (C) 2007 Marvell International Ltd.
+ *
+ * Derived from drivers/i2c/chips/pca9539.c (which has no current known
+ * users).
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+#define NR_PCA9539_GPIOS 16
+
+#define PCA9539_INPUT 0
+#define PCA9539_OUTPUT 2
+#define PCA9539_INVERT 4
+#define PCA9539_DIRECTION 6
+
+struct pca9539_chip {
+ unsigned gpio_start;
+ uint16_t reg_output;
+ uint16_t reg_direction;
+
+ struct i2c_client *client;
+ struct gpio_chip gpio_chip;
+};
+
+static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
+{
+ return i2c_smbus_write_word_data(chip->client, reg, val);
+}
+
+static int pca9539_read_reg(struct pca9539_chip *chip, int reg, uint16_t *val)
+{
+ int ret;
+
+ ret = i2c_smbus_read_word_data(chip->client, reg);
+ if (ret < 0) {
+ dev_err(>client->dev, "failed reading register\n");
+ return ret;
+ }
+
+ *val = (uint16_t)ret;
+ return 0;
+}
+
+static int pca9539_gpio_direction_input(struct gpio_chip *gc, unsigned off)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ reg_val = chip->reg_direction | (1u << off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return ret;
+
+ chip->reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gpio_direction_output(struct gpio_chip *gc,
+ unsigned off, int val)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ /* set output level */
+ if (val)
+ reg_val = chip->reg_output | (1u << off);
+ else
+ reg_val = chip->reg_output & ~(1u << off);
+
+ ret = pca9539_write_reg(chip, PCA9539_OUTPUT, reg_val);
+ if (ret)
+ return ret;
+
+ chip->reg_output = reg_val;
+
+
[PATCH][RT] 2.6.24-rc5-rt1 drivers/dma/ioat_dma.c compile fix
Hi Steve, looks like this patch didn't make it into 2.6.23-rc5-rt1. I refreshed Trem's final version - please review and include in the next RT release. Thanks Sven On Tue, 2007-11-20 at 23:09 +0100, trem wrote: > Steven Rostedt wrote: > > On Fri, 16 Nov 2007, Nelson, Shannon wrote: > >> first->async_tx.phys; > >>> - __list_splice(_chain, ioat_chan->used_desc.prev); > >>> + list_splice_tail(_chain, ioat_chan->used_desc.prev); > >>> > >> NAK. > >> > >> These functions do insertions differently. The 'prev' is pointing > to > >> the last valid descriptor in the queue and you really want to get > the > >> new_chain stuck on after this. Your list_splice_tail() will insert > the > >> new_chain just before it which will muck up the order of the DMA > >> requests. > >> > >> You might have more success with > >>list_splice_tail(_chain, ioat_chan->used_desc); > >> where used_desc points to the whole list, rather than using > the .prev > >> pointer to a specific node. > >> > >> Please copy me on future ioatdma related comments. > >> > > > Hi > > I've tried this change, but it still don't compile. So I propose this patch. > > regards, > trem From: trem <[EMAIL PROTECTED]> Subject: Re: [PATCH][RT] 2.6.24-rc2-rt1 drivers/dma/ioat_dma.c compile fix Steven Rostedt wrote: > On Fri, 16 Nov 2007, Nelson, Shannon wrote: >> first->async_tx.phys; >>> - __list_splice(_chain, ioat_chan->used_desc.prev); >>> + list_splice_tail(_chain, ioat_chan->used_desc.prev); >>> >> NAK. >> >> These functions do insertions differently. The 'prev' is pointing to >> the last valid descriptor in the queue and you really want to get the >> new_chain stuck on after this. Your list_splice_tail() will insert the >> new_chain just before it which will muck up the order of the DMA >> requests. >> >> You might have more success with >> list_splice_tail(_chain, ioat_chan->used_desc); >> where used_desc points to the whole list, rather than using the .prev >> pointer to a specific node. >> >> Please copy me on future ioatdma related comments. >> > > And people wonder why we post RT related patches to LKML. This is exactly > why! > > Thanks for the response Shannon! > > -- Steve > Hi I've tried this change, but it still don't compile. So I propose this patch. regards, trem Acked-by: Sven-Thorsten Dietrich <[EMAIL PROTECTED]> --- drivers/dma/ioat_dma.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.23/drivers/dma/ioat_dma.c === --- linux-2.6.23.orig/drivers/dma/ioat_dma.c +++ linux-2.6.23/drivers/dma/ioat_dma.c @@ -260,7 +260,7 @@ static dma_cookie_t ioat1_tx_submit(stru /* write address into NextDescriptor field of last desc in chain */ to_ioat_desc(ioat_chan->used_desc.prev)->hw->next = first->async_tx.phys; - __list_splice(_chain, ioat_chan->used_desc.prev); + list_splice(_chain, _chan->used_desc); ioat_chan->dmacount += desc_count; ioat_chan->pending += desc_count; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-stable causes oomkiller to be invoked
> Is it really the case that the bug only turns up when you run tests like > > while echo; do cat /sys/kernel/kexec_crash_loaded; done > and > while echo; do cat /sys/kernel/uevent_seqnum ; done; > > or will any fork-intensive workload also do it? Say, > > while echo ; do true ; done > This does not leak, but having a simple text file and reading it in a loop causes it. > ? > > Another interesting factoid here is that after the oomkilling you slabinfo has > > mm_struct 38 9858471 : tunables 32 168 : > slabdata 14 14 0 : globalstat278119649 31 > 01000 : cpustat 368800 11864 368920 > 11721 > > so we aren't leaking mm_structs. In fact we aren't leaking anything from > slab. But we are leaking pgds. > > iirc the most recent change we've made in the pgd_t area is the quicklist > management which went into 2.6.22-rc1. You say the bug was present in > 2.6.22. Can you test 2.6.21? Nope, leak is not present in 2.6.21.7 -- regards, Dhaval -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23.10
On Fri, Dec 14, 2007 at 06:55:46PM -0800, Randy Dunlap wrote: > On Fri, 14 Dec 2007 11:49:53 -0800 Greg Kroah-Hartman wrote: > > > We (the -stable team) are announcing the release of the 2.6.23.10 kernel. > > It a number of bugfixes and anyone using the 2.6.23 kernel series is > > recommended to upgrade. > > > > I'll also be replying to this message with a copy of the patch between > > 2.6.23.9 and 2.6.23.10 > > > > The updated 2.6.23.y git tree can be found at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.23.y.git > > and can be browsed at the normal kernel.org git web browser: > > > > http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=summary > > > WARNING: vmlinux.o(.init.text.23+0x7e6b): Section mismatch: reference to > .exit.text:br_fdb_fini (between 'br_init' and 'br_fdb_init') > > Fixed by: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=73afc9069289bdb77cf0c81cb9775dcb63894bbe Nice, thanks for letting me know, I'll add this to the next release. 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: Strange ATA problems
Thanks for all your help :-) Best wishes from Munich, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Linux 2.6.23.10
On Sat, Dec 15, 2007 at 02:52:56AM +0100, Rafael J. Wysocki wrote: > On Saturday, 15 of December 2007, Chuck Ebbert wrote: > > On 12/14/2007 02:49 PM, Greg Kroah-Hartman wrote: > > > Freezer: Fix APM emulation breakage > > > > drivers/char/apm-emulation.c: In function 'apm_ioctl': > > drivers/char/apm-emulation.c:370: error: implicit declaration of function > > 'wait_event_freezable' > > make[2]: *** [drivers/char/apm-emulation.o] Error 1 > > make[1]: *** [drivers/char] Error 2 > > This is my fault, sorry. > > I though the 2.6.24-rc fix would be suitable for 2.6.23.x, but that's not the > case. > > Greg, please revert the "Freezer: Fix APM emulation breakage" patch, I'll > prepare a separate fix suitable for -stable. Thanks, I'll revert this and do a new release. If you want to send another patch to fix this so it builds, I'll add it to the queue for the next release. 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: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Just a thought for a way to fix the "very early" timing needed to set up udelay to work in a way that works on all machines. Perhaps we haven't exploited the BIOS enough: The PC BIOS since the PC AT (286) has always had a standard "countdown timer" way to delay for n microseconds, which as far as I know still works. This can be used to measure the speed of a delay loop, without using ANY in/out instructions directly (the ones in the BIOS are presumably correctly delayed...). So first thing in the boot sequence, one can calibrate a timing loop using this technique, and save the value to be used for all the "early" stuff. Here's skeleton code from old ASM code I found lying around in my archives to use BIOS to measure how many unrolled short jumps can execute in 10 msec. Note that it can run without knowing anything whatsoever about port timing. haltbyte db 0 calibrate: les bx,haltbyte ; address of halt flag into es:bx mov ax,8300h sub cx,cx mov dx,1 ; 10 msec. in cx:dx int 15h jc bad sub dx,dx sub cx,cx ; decrement counter in dx:cx tloop: jmp short $+2 ; 10 short jmps jmp short $+2 jmp short $+2 jmp short $+2 jmp short $+2 jmp short $+2 jmp short $+2 jmp short $+2 jmp short $+2 test haltbyte loopz tloop jnz done dec dx jnz tloop " overflowed 32 bits ... never happens, cancel BIOS event wait. mov ax,8301h int 15h jmp error done: mov ax,cx negl " here dx:ax contains 32 bit loop count corresponding to 10 msec. ret ; return 32-bit value Doc on function 83h of int 15h should be available online. Alan Cox wrote: On Fri, 14 Dec 2007 14:13:46 -0800 "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: Pavel Machek wrote: On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote: Ingo Molnar wrote: wow, cool fix! (I remember that there were other systems as well that are affected by port 0x80 muckery - i thought we had removed port 0x80 accesses long ago.) how about the simpler fix below, as a first-level approach? We can then remove the _p in/out sequences after this. I believe this will suffer from the issue that was raised: this will use udelay() long before loop calibration (and no, we can't just "be conservative" since there is no "conservative" value we can use.) ?? Just initialize bogomips to 6GHz equivalent... and we are fine until 6GHz cpus come out. How long will that take to boot on a 386? Well the dumb approach to fix that would seem to be to initialise it to cpu->family 3 -> 50MHz 4 -> 300Mhz 5-> etc... Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23.10
On Fri, 14 Dec 2007 11:49:53 -0800 Greg Kroah-Hartman wrote: > We (the -stable team) are announcing the release of the 2.6.23.10 kernel. > It a number of bugfixes and anyone using the 2.6.23 kernel series is > recommended to upgrade. > > I'll also be replying to this message with a copy of the patch between > 2.6.23.9 and 2.6.23.10 > > The updated 2.6.23.y git tree can be found at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.23.y.git > and can be browsed at the normal kernel.org git web browser: > > http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=summary WARNING: vmlinux.o(.init.text.23+0x7e6b): Section mismatch: reference to .exit.text:br_fdb_fini (between 'br_init' and 'br_fdb_init') Fixed by: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=73afc9069289bdb77cf0c81cb9775dcb63894bbe --- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Could not set non-blocking flag with 2.6.24-rc5
Tino Keitel wrote:
Hi folks,
I often build Debian packages inside a chroot. Today I discovered a
failure during an "aptitude update", which is a command to download new
package lists for the package management. In strace, the lines around
the failure look like this:
99% [Working]) = 14 14
[pid 5986] select(6, [3 4 5], [], NULL, {0, 50}) = 0 (Timeout)
[pid 5986] gettimeofday({1197576353, 670510}, NULL) = 0
[pid 5986] rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
[pid 5986] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
99% [Working]) = 14 14
[pid 5986] select(6, [3 4 5], [], NULL, {0, 50}) = 0 (Timeout)
[pid 5986] gettimeofday({1197576354, 173902}, NULL) = 0
[pid 5986] rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
[pid 5986] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
99% [Working]) = 14 14
[pid 5986] select(6, [3 4 5], [], NULL, {0, 50}
[pid 5988] <... select resumed> ) = 1 (in [3], left {105, 0})
[pid 5988] read(3, "", 56559) = 0
[pid 5988] fcntl64(-1, F_GETFL)= -1 EBADF (Bad file
descriptor)
[pid 5988] fcntl64(-1, F_SETFL,
O_ACCMODE|O_CREAT|O_EXCL|O_NOCTTY|O_TRUNC|O_APPEND|O_SYNC|O_ASYNC|O_DIRECT|O_LARGEFILE|O_DIRECTORY|O_NOFOLLOW|O_NOATIME|0xfff8003c)
= -1 EBADF (Bad file descriptor)
[pid 5988] write(2, ""..., 41FATAL -> Could not set non-blocking flag
) = 41
[pid 5988] write(2, ""..., 19Bad file descriptor) = 19
[pid 5988] write(2, ""..., 1
) = 1
[pid 5988] exit_group(100) = ?
Process 5988 detached
This happened with a kernel after 2.6.24-rc5
(4af75653031c6d454b4ace47c1536f0d2e727e3e). I rebooted into 2.6.23.8
and it worked. Now I rebooted into 2.6.24-rc5 again and was able to
reproduce the failure, so it looks like a kernel issue to me.
With this part of strace output it seems like an obvious userspace bug
(calling fcntl on a -1 file descriptor). Could be some other change in
behavior or timing difference is triggering the bug,however.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [x86_64] remove unused variable from drivers/ata/ahci.c
Michael Kühn wrote: Hi, my first kernel patch, yay. :-) On the file drivers/ata/ahci.c in line 1433 is declared a variable that is never used in the function. I removed it. Patch is in attachments (based on 2.6.23.10). ... You'll need to do: (1) repost it, but this time to [EMAIL PROTECTED], (2) place the patch INLINE, where it's easier to comment/correct as needed, (3) include a Signed-off-by line, (4) read / follow much of the Documentation/SubmittingPatches file. *Then* you can try for fame and glory! :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: Wireshark sees no packets in 2.6.24-rc3
Rafael J. Wysocki wrote: > On Friday, 14 of December 2007, Ray Lee wrote: >> tshark -i eth0, eth1, lo are all empty. Works under 2.6.23.0 just >> fine. A quick scan of the log between 2.6.24-rc3 and current tip >> (-rc5) doesn't show any obvious fixes, but then again, what do I know. >> I'll check current tip on the weekend when I'll have the luxury to >> have my main system down long enough for a test. Right now I'm kinda >> up against a deadline, but didn't want to leave it unreported. Should >> be easy for someone else to confirm or deny whether current tip has >> the problem. > > FYI, I have created a bugzilla entry for this issue at: > http://bugzilla.kernel.org/show_bug.cgi?id=9568 Hmm what do you mean by empty ? it does not capturing anything on that interface ? I do run -rc5-git with wireshark-0.99.6 and tshark -i eth0 or lo works here. snip ... -- sudo tshark -i eth0 Capturing on eth0 1197685732.785920 192.168.0.1 -> 239.255.255.250 SSDP NOTIFY * HTTP/1.1 1197685732.790126 192.168.0.1 -> 239.255.255.250 SSDP NOTIFY * HTTP/1.1 1197685732.793613 192.168.0.1 -> 239.255.255.250 SSDP NOTIFY * HTTP/1.1 1197685732.797656 192.168.0.1 -> 239.255.255.250 SSDP NOTIFY * HTTP/1.1 ... 1197685738.680962 77.37.20.73 -> 192.168.0.2 TCP 44544 > 44625 [PSH, ACK] Seq=0 Ack=20 Win=88 Len=27 TSV=914082460 TSER=145333592 1197685738.681007 192.168.0.2 -> 77.37.20.73 TCP 44625 > 44544 [ACK] Seq=20 Ack=27 Win=1002 Len=0 TSV=145333645 TSER=914082460 1197685745.994576 192.168.0.2 -> 81.169.185.129 NTP NTP client 1197685746.058523 81.169.185.129 -> 192.168.0.2 NTP NTP server 1197685749.058576 192.168.0.2 -> 85.214.68.60 NTP NTP client 1197685749.121771 85.214.68.60 -> 192.168.0.2 NTP NTP server 1197685751.391157 77.37.20.73 -> 192.168.0.2 TCP 44544 > 44625 [PSH, ACK] Seq=27 Ack=20 Win=88 Len=55 TSV=914085637 TSER=145333645 1197685751.391201 192.168.0.2 -> 77.37.20.73 TCP 44625 > 44544 [ACK] Seq=20 Ack=82 Win=1002 Len=0 TSV=145346355 TSER=914085637 -- sudo tshark -i lo Capturing on lo 1197686288.330222 192.168.0.2 -> 192.168.0.2 TCP 53122 > http [SYN] Seq=0 Len=0 MSS=16396 TSV=145883294 TSER=0 WS=6 1197686288.330225 192.168.0.2 -> 192.168.0.2 TCP http > 53122 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=16396 TSV=145883294 TSER=145883294 WS=6 1197686288.330251 192.168.0.2 -> 192.168.0.2 TCP 53122 > http [ACK] Seq=1 Ack=1 Win=32832 Len=0 TSV=145883294 TSER=145883294 1197686288.330327 192.168.0.2 -> 192.168.0.2 HTTP GET /.KDE/kdegames-3.97.1_747147.tar.bz2 HTTP/1.0 1197686288.330357 192.168.0.2 -> 192.168.0.2 TCP http > 53122 [ACK] Seq=1 Ack=132 Win=33856 Len=0 TSV=145883294 TSER=145883294 1197686288.474624 192.168.0.2 -> 192.168.0.2 HTTP HTTP/1.1 200 OK (application/x-bzip2) 1197686288.474684 192.168.0.2 -> 192.168.0.2 TCP 53122 > http [ACK] Seq=132 Ack=16385 Win=49344 Len=0 TSV=145883439 TSER=145883439 snip Regards, Gabriel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23.10
On Saturday, 15 of December 2007, Rafael J. Wysocki wrote:
> On Saturday, 15 of December 2007, Chuck Ebbert wrote:
> > On 12/14/2007 08:52 PM, Rafael J. Wysocki wrote:
> > > On Saturday, 15 of December 2007, Chuck Ebbert wrote:
> > >> On 12/14/2007 02:49 PM, Greg Kroah-Hartman wrote:
> > >>> Freezer: Fix APM emulation breakage
> > >> drivers/char/apm-emulation.c: In function 'apm_ioctl':
> > >> drivers/char/apm-emulation.c:370: error: implicit declaration of
> > >> function 'wait_event_freezable'
> > >> make[2]: *** [drivers/char/apm-emulation.o] Error 1
> > >> make[1]: *** [drivers/char] Error 2
> > >
> > > This is my fault, sorry.
> > >
> > > I though the 2.6.24-rc fix would be suitable for 2.6.23.x, but that's not
> > > the
> > > case.
> > >
> > > Greg, please revert the "Freezer: Fix APM emulation breakage" patch, I'll
> > > prepare a separate fix suitable for -stable.
> > >
> >
> > It works if you add the changes to freezer.h made in commit
> > e42837bcd35b75bb59ae5d3e62f87be1aeeb05c3
>
> Yes, exactly, but a new patch is needed anyway.
>
> Hmm, perhaps it's better to add a new patch on top of "Freezer: Fix APM
> emulation breakage"? Would that be preferred?
For convenience, below is the patch that should fix the breakage when applied
on top of the "Freezer: Fix APM emulation breakage" patch.
Thanks,
Rafael
---
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
This patch is needed to fix the compilation breakage in the
APM emulation driver in 2.6.23.10 caused by the
"Freezer: Fix APM emulation breakage" patch.
The changes introduced by this patch are already in the
mainline (commit e42837bcd35b75bb59ae5d3e62f87be1aeeb05c3).
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
include/linux/freezer.h | 38 ++
1 file changed, 38 insertions(+)
Index: linux-2.6.23.y/include/linux/freezer.h
===
--- linux-2.6.23.y.orig/include/linux/freezer.h
+++ linux-2.6.23.y/include/linux/freezer.h
@@ -4,6 +4,7 @@
#define FREEZER_H_INCLUDED
#include
+#include
#ifdef CONFIG_PM_SLEEP
/*
@@ -126,6 +127,36 @@ static inline void set_freezable(void)
current->flags &= ~PF_NOFREEZE;
}
+/*
+ * Freezer-friendly wrappers around wait_event_interruptible() and
+ * wait_event_interruptible_timeout(), originally defined in
+ */
+
+#define wait_event_freezable(wq, condition)\
+({ \
+ int __retval; \
+ do {\
+ __retval = wait_event_interruptible(wq, \
+ (condition) || freezing(current)); \
+ if (__retval && !freezing(current)) \
+ break; \
+ else if (!(condition)) \
+ __retval = -ERESTARTSYS;\
+ } while (try_to_freeze()); \
+ __retval; \
+})
+
+
+#define wait_event_freezable_timeout(wq, condition, timeout) \
+({ \
+ long __retval = timeout;\
+ do {\
+ __retval = wait_event_interruptible_timeout(wq, \
+ (condition) || freezing(current), \
+ __retval); \
+ } while (try_to_freeze()); \
+ __retval; \
+})
#else /* !CONFIG_PM_SLEEP */
static inline int frozen(struct task_struct *p) { return 0; }
static inline int freezing(struct task_struct *p) { return 0; }
@@ -143,6 +174,13 @@ static inline void freezer_do_not_count(
static inline void freezer_count(void) {}
static inline int freezer_should_skip(struct task_struct *p) { return 0; }
static inline void set_freezable(void) {}
+
+#define wait_event_freezable(wq, condition)\
+ wait_event_interruptible(wq, condition)
+
+#define wait_event_freezable_timeout(wq, condition, timeout) \
+ wait_event_interruptible_timeout(wq, condition, timeout)
+
#endif /* !CONFIG_PM_SLEEP */
#endif /* FREEZER_H_INCLUDED */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
[EMAIL PROTECTED] wrote: Could this be the reason my BCM94311MCG rev 1 receives such terrible performance with b43 but works well with bcm43xx? The device is 802.11b/g but my router is 802.11b. I filed a report on this issue here: https://bugzilla.redhat.com/show_bug.cgi?id=413291 No. On my BCM4311/1, my transfer rate peaked at about 12 Mbs with bcm43xx, but increased to 20 Mbs with b43. These tests were done with iperf with a server running running on a second computer connected by wire to my router. These rates are for 802.11g. When my interface was locked at 11 Mbs, the transfer rate was the expected 5.3-5.5 Mbs with both drivers. I was told by Michael that I would have to fix it myself, and I am trying, but the learning curve is a little steep. If this is relevant, I might at least have some direction to go in. I suspect that mac80211 is doing something that your router does not like. Do you have any chance to capture the traffic between your computer and the router by using a second wireless computer running kismet or wireshark? A look at the differences between b43 and bcm43xx should show the reason. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
David P. Reed wrote: I believe (though no one seems to have confirming documentation from the chipset or motherboard vendor) that port 80 is actually functional for some unknown function on these machines. (They do respond to "in" instructions faster than a bus cycle abort does - more evidence). This is normal. IN from port 0x80 is used by the DMA address map chip. As far as I understand, there are other laptops with the same chipset which don't have this problem, so it's likely either a motherboard or firmware issue. My guess is that they probably let debugging code out in the field (trap port 0x80 in SMM, and then try to output it on some debugging bus.) -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible issue with dangling PCI BARs
On Sat, 2007-12-15 at 09:11 +1100, Benjamin Herrenschmidt wrote: > On Fri, 2007-12-14 at 06:52 -0500, Jon Masters wrote: > > On Thu, 2007-12-13 at 14:00 +1100, Benjamin Herrenschmidt wrote: > > > While reworking the powerpc PCI resource management, to make it more > > > x86-like and use more of the generic code in setup-bus.c and > > > setup-res.c, I noticed something a bit fishy in the way we deal with > > > resources that we failed to assign. > > > > On a tangent here, is there a way (other than pci=rom) to ensure greater > > address space/resource space for PCI resource mappings? > > limit lowmem ? 4g/4g ? 64 bits ? :-) Oh, I've seen resource allocation fail on x86_64, which is what bothers me, since this really shouldn't be happening. Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Avi Kivity wrote: kvm will forward a virtual machine's writes to port 0x80 to the real port. The reason is that the write is much faster than exiting and emulating it; the difference is measurable when compiling kernels. Now if the cause is simply writing to port 0x80, then we must stop doing that. But if the reason is the back-to-back writes, when we can keep it, since the other writes will be trapped by kvm and emulated. Do you which is the case? As for kvm, I don't have enough info to know anything about that. Is there a test you'd like me to try? I think you are also asking if the crash on these laptops is caused only by back-to-back writes. Actually, it doesn't seem to matter if they are back to back. I can cause the crash if the writes to 80 are very much spread out in time - it seems only to matter how many of them get executed - almost as if there is a buffer overflow. (And of course if you do back to back writes to other ports that are apparently fully unused, such as 0xED on my machine, no crash occurs). I believe (though no one seems to have confirming documentation from the chipset or motherboard vendor) that port 80 is actually functional for some unknown function on these machines. (They do respond to "in" instructions faster than a bus cycle abort does - more evidence). I searched the DSDT to see if there is any evidence of an ACPI use for this port, but found nothing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?
On Sat, 15 Dec 2007 01:09:41 + Mel Gorman <[EMAIL PROTECTED]> wrote: > On (13/12/07 14:29), Andrew Morton didst pronounce: > > > The simple way seems to be to malloc a large area, touch every page and > > > then look at the physical pages assigned ... they now mostly seem to be > > > descending in physical address. > > > > > > > OIC. -mm's /proc/pid/pagemap can be used to get the pfn's... > > > > I tried using pagemap to verify the patch but it triggered BUG_ON > checks. Perhaps I am using the interface wrong but I would still not > expect it to break in this fashion. I tried 2.6.24-rc4-mm1, 2.6.24-rc5-mm1, > 2.6.24-rc5 with just the maps4 patches applied and 2.6.23 with maps4 patches > applied. Each time I get errors like this; > > [ 90.108315] BUG: sleeping function called from invalid context at > include/asm/uaccess_32.h:457 > [ 90.211227] in_atomic():1, irqs_disabled():0 > [ 90.262251] no locks held by showcontiguous/2814. > [ 90.318475] Pid: 2814, comm: showcontiguous Not tainted 2.6.24-rc5 #1 > [ 90.395344] [] show_trace_log_lvl+0x1a/0x30 > [ 90.456948] [] show_trace+0x12/0x20 > [ 90.510173] [] dump_stack+0x6e/0x80 > [ 90.563409] [] __might_sleep+0xc3/0xe0 > [ 90.619765] [] copy_to_user+0x3d/0x60 > [ 90.675153] [] add_to_pagemap+0x5c/0x80 > [ 90.732513] [] pagemap_pte_range+0x68/0xb0 > [ 90.793010] [] walk_page_range+0x112/0x210 > [ 90.853482] [] pagemap_read+0x176/0x220 > [ 90.910863] [] vfs_read+0x94/0x150 > [ 90.963058] [] sys_read+0x3d/0x70 > [ 91.014219] [] syscall_call+0x7/0xb > > ... > > Just using cp to read the file is enough to cause problems but I included > a very basic program below that produces the BUG_ON checks. Is this a known > issue or am I using the interface incorrectly? I'd say you're using it correctly but you've found a hitherto unknown bug. On i386 highmem machines with CONFIG_HIGHPTE (at least) pte_offset_map() takes kmap_atomic(), so pagemap_pte_range() can't do copy_to_user() as it presently does. Drat. Still, that shouldn't really disrupt the testing which you're doing. You could disable CONFIG_HIGHPTE to shut it up. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 7:58 PM, Larry Finger <[EMAIL PROTECTED]> wrote: > Rafael J. Wysocki wrote: > > > > Actually, can you explain why, from the technical point of view, the > > version 4 > > firware is better than version 3, please? > > I will be very interested in Michael's answer to this question; however, my > experience is that it > doesn't make much difference if your device is supported by both V3 and V4 > firmware. This impression > was obtained by comparing BCM4318 and BCM4311/1 devices with b43 and > b43legacy. > > Note that 802.11b and early BCM4306 devices are not supported by V4 firmware. Could this be the reason my BCM94311MCG rev 1 receives such terrible performance with b43 but works well with bcm43xx? The device is 802.11b/g but my router is 802.11b. I filed a report on this issue here: https://bugzilla.redhat.com/show_bug.cgi?id=413291 I was told by Michael that I would have to fix it myself, and I am trying, but the learning curve is a little steep. If this is relevant, I might at least have some direction to go in. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23.10
On Saturday, 15 of December 2007, Chuck Ebbert wrote: > On 12/14/2007 08:52 PM, Rafael J. Wysocki wrote: > > On Saturday, 15 of December 2007, Chuck Ebbert wrote: > >> On 12/14/2007 02:49 PM, Greg Kroah-Hartman wrote: > >>> Freezer: Fix APM emulation breakage > >> drivers/char/apm-emulation.c: In function 'apm_ioctl': > >> drivers/char/apm-emulation.c:370: error: implicit declaration of function > >> 'wait_event_freezable' > >> make[2]: *** [drivers/char/apm-emulation.o] Error 1 > >> make[1]: *** [drivers/char] Error 2 > > > > This is my fault, sorry. > > > > I though the 2.6.24-rc fix would be suitable for 2.6.23.x, but that's not > > the > > case. > > > > Greg, please revert the "Freezer: Fix APM emulation breakage" patch, I'll > > prepare a separate fix suitable for -stable. > > > > It works if you add the changes to freezer.h made in commit > e42837bcd35b75bb59ae5d3e62f87be1aeeb05c3 Yes, exactly, but a new patch is needed anyway. Hmm, perhaps it's better to add a new patch on top of "Freezer: Fix APM emulation breakage"? Would that be preferred? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange ATA problems
Tejun Heo wrote: Dec 14 01:06:33 fermat kernel: ata1: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000 status 0x400 next cpb count 0x0 next cpb idx 0x0 Dec 14 01:06:33 fermat kernel: ata1: CPB 0: ctl_flags 0x1f, resp_flags 0x2 Dec 14 01:06:33 fermat kernel: ata1: CPB 1: ctl_flags 0x1f, resp_flags 0x2 Dec 14 01:06:33 fermat kernel: ata1: CPB 2: ctl_flags 0x1f, resp_flags 0x2 Dec 14 01:06:33 fermat kernel: ata1: CPB 3: ctl_flags 0x1f, resp_flags 0x2 Dec 14 01:06:33 fermat kernel: ata1: CPB 4: ctl_flags 0x1f, resp_flags 0x2 Dec 14 01:06:33 fermat kernel: ata1: CPB 5: ctl_flags 0x1f, resp_flags 0x2 Dec 14 01:06:33 fermat kernel: ata1: CPB 6: ctl_flags 0x1f, resp_flags 0x2 Dec 14 01:06:33 fermat kernel: ata1: CPB 7: ctl_flags 0x1f, resp_flags 0x2 Dec 14 01:06:33 fermat kernel: ata1: CPB 8: ctl_flags 0x1f, resp_flags 0x2 Dec 14 01:06:33 fermat kernel: ata1: CPB 9: ctl_flags 0x1f, resp_flags 0x2 Dec 14 01:06:33 fermat kernel: ata1: CPB 10: ctl_flags 0x1f, resp_flags 0x2 CPB flags stuck at 0x2 indicates that the controller issued the command to the drive and is waiting for completion. Usually seems to indicate some kind of SATA communication problem. If your USB cdrom is bus powered and you yanked it, it could have caused fluctuation in power which in turn can cause disruption on serial ATA bus leading to transmission error and timeouts. There are other possibilities but this kind of thing does happen often with SATA. Those highspeed low-voltage serial links are very susceptible to interferences. Well,.. it actually "worked" again when I unplugged it, but the errors from the cdrom above are probably unrelated.. As long as EH recovered it properly, there's nothing to worry about. What does that mean? That means unless the problem continues to occur repeatedly, you don't have to worry about it. Yes, if it didn't recur, was likely just a transient glitch. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: Wireshark sees no packets in 2.6.24-rc3
On Friday, 14 of December 2007, Ray Lee wrote: > tshark -i eth0, eth1, lo are all empty. Works under 2.6.23.0 just > fine. A quick scan of the log between 2.6.24-rc3 and current tip > (-rc5) doesn't show any obvious fixes, but then again, what do I know. > I'll check current tip on the weekend when I'll have the luxury to > have my main system down long enough for a test. Right now I'm kinda > up against a deadline, but didn't want to leave it unreported. Should > be easy for someone else to confirm or deny whether current tip has > the problem. FYI, I have created a bugzilla entry for this issue at: http://bugzilla.kernel.org/show_bug.cgi?id=9568 Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23.10
On 12/14/2007 08:52 PM, Rafael J. Wysocki wrote: > On Saturday, 15 of December 2007, Chuck Ebbert wrote: >> On 12/14/2007 02:49 PM, Greg Kroah-Hartman wrote: >>> Freezer: Fix APM emulation breakage >> drivers/char/apm-emulation.c: In function 'apm_ioctl': >> drivers/char/apm-emulation.c:370: error: implicit declaration of function >> 'wait_event_freezable' >> make[2]: *** [drivers/char/apm-emulation.o] Error 1 >> make[1]: *** [drivers/char] Error 2 > > This is my fault, sorry. > > I though the 2.6.24-rc fix would be suitable for 2.6.23.x, but that's not the > case. > > Greg, please revert the "Freezer: Fix APM emulation breakage" patch, I'll > prepare a separate fix suitable for -stable. > It works if you add the changes to freezer.h made in commit e42837bcd35b75bb59ae5d3e62f87be1aeeb05c3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange ATA problems
Hi Alan. On Fri, 2007-12-14 at 22:24 +, Alan Cox wrote: > Can you reproduce this without the Nvidia stuff ? No,.. I'm running for about 2 years now with propreitary nvidia gpu module,.. but I've never encountered that problem before. Anyway,... I might have just missed it... Ah and by the way,.. in the meantime to problem didn't occure again :) Best wishes, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Linux 2.6.23.10
On Saturday, 15 of December 2007, Chuck Ebbert wrote: > On 12/14/2007 02:49 PM, Greg Kroah-Hartman wrote: > > Freezer: Fix APM emulation breakage > > drivers/char/apm-emulation.c: In function 'apm_ioctl': > drivers/char/apm-emulation.c:370: error: implicit declaration of function > 'wait_event_freezable' > make[2]: *** [drivers/char/apm-emulation.o] Error 1 > make[1]: *** [drivers/char] Error 2 This is my fault, sorry. I though the 2.6.24-rc fix would be suitable for 2.6.23.x, but that's not the case. Greg, please revert the "Freezer: Fix APM emulation breakage" patch, I'll prepare a separate fix suitable for -stable. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARP Bug?
On Dec 14 2007 17:11, Gosney, JeremiX wrote: >Subject: ARP Bug? > >We've noticed the 2.6-based Linux systems in our test lab are >experiencing some "ARP flux"-like symptoms. > >The systems reply with eth0's hardware address to all ARP requests, If you have the same subnet on multiple interfaces, only the first interface will be served. Case closed? >regardless of the IP being queried. Because of this, the system will >only send and receive packets on eth0; if eth0 is brought down, the >system is unreachable even though it still has several active >connections. With eth0 unplugged, none of the other interfaces are >reachable (this is presumably a side-effect caused by the switch ARP >cache.) Failover routes are defined in the routing table, but the system >still will not send/receive packets out those interfaces. > I am not sure ARP even uses the routing table. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ARP Bug?
We've noticed the 2.6-based Linux systems in our test lab are experiencing some "ARP flux"-like symptoms. The systems reply with eth0's hardware address to all ARP requests, regardless of the IP being queried. Because of this, the system will only send and receive packets on eth0; if eth0 is brought down, the system is unreachable even though it still has several active connections. With eth0 unplugged, none of the other interfaces are reachable (this is presumably a side-effect caused by the switch ARP cache.) Failover routes are defined in the routing table, but the system still will not send/receive packets out those interfaces. Can anything be done to correct this behaviour? Jeremi M Gosney Enterprise Linux Engineer DIJIC, Intel Corporation Work: 253-371-4849 Mobile: 253-495-4254 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?
On (13/12/07 14:29), Andrew Morton didst pronounce:
> > The simple way seems to be to malloc a large area, touch every page and
> > then look at the physical pages assigned ... they now mostly seem to be
> > descending in physical address.
> >
>
> OIC. -mm's /proc/pid/pagemap can be used to get the pfn's...
>
I tried using pagemap to verify the patch but it triggered BUG_ON
checks. Perhaps I am using the interface wrong but I would still not
expect it to break in this fashion. I tried 2.6.24-rc4-mm1, 2.6.24-rc5-mm1,
2.6.24-rc5 with just the maps4 patches applied and 2.6.23 with maps4 patches
applied. Each time I get errors like this;
[ 90.108315] BUG: sleeping function called from invalid context at
include/asm/uaccess_32.h:457
[ 90.211227] in_atomic():1, irqs_disabled():0
[ 90.262251] no locks held by showcontiguous/2814.
[ 90.318475] Pid: 2814, comm: showcontiguous Not tainted 2.6.24-rc5 #1
[ 90.395344] [] show_trace_log_lvl+0x1a/0x30
[ 90.456948] [] show_trace+0x12/0x20
[ 90.510173] [] dump_stack+0x6e/0x80
[ 90.563409] [] __might_sleep+0xc3/0xe0
[ 90.619765] [] copy_to_user+0x3d/0x60
[ 90.675153] [] add_to_pagemap+0x5c/0x80
[ 90.732513] [] pagemap_pte_range+0x68/0xb0
[ 90.793010] [] walk_page_range+0x112/0x210
[ 90.853482] [] pagemap_read+0x176/0x220
[ 90.910863] [] vfs_read+0x94/0x150
[ 90.963058] [] sys_read+0x3d/0x70
[ 91.014219] [] syscall_call+0x7/0xb
[ 91.067433] ===
[ 91.110137] BUG: scheduling while atomic: showcontiguous/2814/0x0001
[ 91.190169] no locks held by showcontiguous/2814.
[ 91.246293] Pid: 2814, comm: showcontiguous Not tainted 2.6.24-rc5 #1
[ 91.323145] [] show_trace_log_lvl+0x1a/0x30
[ 91.384633] [] show_trace+0x12/0x20
[ 91.437878] [] dump_stack+0x6e/0x80
[ 91.491116] [] __schedule_bug+0x66/0x70
[ 91.548467] [] schedule+0x556/0x7b0
[ 91.601698] [] work_resched+0x5/0x21
[ 91.655977] ===
[ 91.704927] showcontiguous[2814]: segfault at b7eaa900 eip b7eaa900 esp
bfa02e8c error 4
[ 91.801633] BUG: scheduling while atomic: showcontiguous/2814/0x0001
[ 91.881634] no locks held by showcontiguous/2814.
[ 91.937779] Pid: 2814, comm: showcontiguous Not tainted 2.6.24-rc5 #1
[ 92.014606] [] show_trace_log_lvl+0x1a/0x30
[ 92.076123] [] show_trace+0x12/0x20
[ 92.129354] [] dump_stack+0x6e/0x80
[ 92.182567] [] __schedule_bug+0x66/0x70
[ 92.239959] [] schedule+0x556/0x7b0
[ 92.293187] [] work_resched+0x5/0x21
[ 92.347452] ===
[ 92.392697] note: showcontiguous[2814] exited with preempt_count 1
[ 92.468611] BUG: scheduling while atomic: showcontiguous/2814/0x1001
[ 92.548588] no locks held by showcontiguous/2814.
[ 92.604732] Pid: 2814, comm: showcontiguous Not tainted 2.6.24-rc5 #1
[ 92.681665] [] show_trace_log_lvl+0x1a/0x30
[ 92.743180] [] show_trace+0x12/0x20
[ 92.796409] [] dump_stack+0x6e/0x80
[ 92.849621] [] __schedule_bug+0x66/0x70
[ 92.907014] [] schedule+0x556/0x7b0
[ 92.960349] [] __cond_resched+0x27/0x40
[ 93.017804] [] cond_resched+0x2a/0x40
[ 93.073122] [] unmap_vmas+0x4ec/0x540
[ 93.128418] [] exit_mmap+0x6f/0xf0
[ 93.180611] [] mmput+0x31/0xb0
[ 93.228665] [] exit_mm+0x8d/0xf0
[ 93.278788] [] do_exit+0x15f/0x7e0
[ 93.330965] [] do_group_exit+0x29/0x70
[ 93.387321] [] get_signal_to_deliver+0x2b7/0x490
[ 93.454013] [] do_notify_resume+0x7d/0x760
[ 93.514476] [] work_notifysig+0x13/0x1a
[ 93.571869] ===
Just using cp to read the file is enough to cause problems but I included
a very basic program below that produces the BUG_ON checks. Is this a known
issue or am I using the interface incorrectly?
#include
#include
#include
#include
#include
#include
#include
#include
#define MAPSIZE (4*1048576)
#define PM_ENTRY_BYTES sizeof(__u64)
int main(int argc, char **argv)
{
int pagemap_fd;
unsigned long *anonmapping;
__u64 pagemap_entry = 0ULL;
unsigned long vpfn, ppfn;
size_t mmap_offset;
int pagesize = getpagesize();
/* Open the pagemap interface */
pagemap_fd = open("/proc/self/pagemap", O_RDONLY);
if (pagemap_fd == -1) {
perror("fopen");
exit(EXIT_FAILURE);
}
/* Create an anonymous mapping */
anonmapping = mmap(NULL, MAPSIZE,
PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_POPULATE,
-1, 0);
if (anonmapping == MAP_FAILED) {
perror("mmap");
exit(1);
}
/* Work out the VPN the mapping is at and seek to it in pagemap */
vpfn = ((unsigned long)anonmapping) / pagesize;
mmap_offset = lseek(pagemap_fd, vpfn * PM_ENTRY_BYTES, SEEK_SET);
if (mmap_offset == -1) {
perror("fseek");
exit(EXIT_FAILURE);
}
/*
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Friday, 14 of December 2007, Michael Buesch wrote: > On Friday 14 December 2007 18:59:10 Ingo Molnar wrote: > > > > * Michael Buesch <[EMAIL PROTECTED]> wrote: > > > > > In my opinion this all is the work of the distributions and not the > > > work of the kernel developers. Distributions have to make sure that > > > everything works after a kernel update. [...] > > > > actually, not. The the task of kernel developers is to KEEP OLD > > DISTRIBUTIONS WORKING WITH NEW DRIVERS. Or the "old" driver stays around > > until eternity, because the new one is just BROKEN. > > What exactly prevents an old distribution from using new b43 > given that they fix their broken udev scripts first? > > (I cannot fix their broken scripts from within the kernel.) Well, we talked about that some time ago, didn't we? The rule is this: if one uses kernel 2.6.x from kernel.org _successfully_ with certain distribution (whatever it is), then one is supposed to be able to take the kernel 2.6.(x+1), install it on that distribution and use it without any major configuration changes. If this rule is not followed, people will stop testing kernel.org kernels and we'll all suffer from that. Now, in my not so humble opinion, switching from bcm43xx to b43 _is_ a major configuration change (I did it, so please don't try to discuss with my experience) and forcing users to do that breaks the rule above. > > Take a look at CONFIG_COMPAT_VDSO for example - one single version of > > glibc was released in a distro that depended on a kernel vDSO bug. So > > we'll keep that aspect of the vDSO perhaps forever. Simple as that. > > Stuff must just work. Whatever it takes. Best is if you add in new stuff > > without the user noticing _ANYTHING_ but that the kernel version bumped. > > If the maintainers of the other 7 million lines of kernel code can get > > this right then the wireless code should be able to do it too. Ok? > > > > all this "distributors will have to sort out the mess" talk is nonsense, > > and i really hope you do not truly believe in that crap. If your > > attitude is prevalent in the wireless development community then it's in > > worse shape than i thought :-( > > Sorry if I didn't chose my wording correctly. But I was only talking > about the development of drivers. It is correct that userspace ABI has > to be preserved, but that is not an issue at all to drivers. > I was talking about things like installing the right firmware for > the new driver. It is the job of the distributors to install the new > firmware when they introduce a new driver. Yes, as far as new distributions are concerned. However, we _want_ kernel.org kernels to work with the old ones too. Yes, WE DO. > It is the job of the distributors to test their userland scripts and > configuration stuff with that driver and fix their stuff. It is _not_ my job > to fix random distribution udev scripts or explaining over and over again to > people how the firmware is installed. Given specific software environment (it may be a home-made system compiled from sources or whatever), if installing a new kernel forces me to reconfigure it in any significant way to obtain the functionality that I previously had, the problem is with the kernel. No less, no more. > Either distributions have to install it automatically or people simply have > to read one or two lines of documentation. That's just what I wanted to say. It's not that simple. For example, regression testing will be a major PITA if one needs to switch back and forth from the new driver to the old one in the process. > Of course it is _my_ job to preserve ABI. I did never want to question that. Greetings, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] arch/x86/kernel/cpu/mcheck/p4.c, kernel 2.6.24-rc5
Consolidate printk and insert CPU id to cleanup SMP interleaved output.
In SMP, the machine check exception dispatches all logical processors
within a physical package to the machine-check exception handler, so the
printk within each handler outputs concurrently and makes the output
unreadable. Refer to Intel system programming guide Part 1 Section 7.8.5
http://developer.intel.com/design/processor/manuals/253668.pdf
Signed-off-by: Min Zhang <[EMAIL PROTECTED]>
Index: linux-2.6.24-rc5/arch/x86/kernel/cpu/mcheck/p4.c
===
--- linux-2.6.24-rc5.orig/arch/x86/kernel/cpu/mcheck/p4.c
+++ linux-2.6.24-rc5/arch/x86/kernel/cpu/mcheck/p4.c
@@ -158,32 +158,35 @@ static fastcall void intel_machine_check
if (mce_num_extended_msrs > 0) {
struct intel_mce_extended_msrs dbg;
intel_get_extended_msrs();
- printk (KERN_DEBUG "CPU %d: EIP: %08x EFLAGS: %08x\n",
- smp_processor_id(), dbg.eip, dbg.eflags);
- printk (KERN_DEBUG "\teax: %08x ebx: %08x ecx: %08x edx:
%08x\n",
- dbg.eax, dbg.ebx, dbg.ecx, dbg.edx);
- printk (KERN_DEBUG "\tesi: %08x edi: %08x ebp: %08x esp:
%08x\n",
+ printk (KERN_DEBUG "CPU %d: EIP: %08x EFLAGS: %08x\n"
+ "\teax: %08x ebx: %08x ecx: %08x edx: %08x\n"
+ "\tesi: %08x edi: %08x ebp: %08x esp: %08x\n",
+ smp_processor_id(), dbg.eip, dbg.eflags,
+ dbg.eax, dbg.ebx, dbg.ecx, dbg.edx,
dbg.esi, dbg.edi, dbg.ebp, dbg.esp);
}
for (i=0; ihttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23.10
On 12/14/2007 02:49 PM, Greg Kroah-Hartman wrote: > Freezer: Fix APM emulation breakage drivers/char/apm-emulation.c: In function 'apm_ioctl': drivers/char/apm-emulation.c:370: error: implicit declaration of function 'wait_event_freezable' make[2]: *** [drivers/char/apm-emulation.o] Error 1 make[1]: *** [drivers/char] Error 2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
Rafael J. Wysocki wrote: Actually, can you explain why, from the technical point of view, the version 4 firware is better than version 3, please? I will be very interested in Michael's answer to this question; however, my experience is that it doesn't make much difference if your device is supported by both V3 and V4 firmware. This impression was obtained by comparing BCM4318 and BCM4311/1 devices with b43 and b43legacy. Note that 802.11b and early BCM4306 devices are not supported by V4 firmware. Similarly, with BCM4311/2 and newer devices V3 firmware fails. As Michael said "newer drivers supporting newer hardware need newer firmware". Larry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] x86: Use helper in kprobes{32|64}.c
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
arch/x86/kernel/kprobes_32.c | 18 +++---
arch/x86/kernel/kprobes_64.c | 14 --
2 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/kprobes_32.c b/arch/x86/kernel/kprobes_32.c
index 2a8acd6..878b0c4 100644
--- a/arch/x86/kernel/kprobes_32.c
+++ b/arch/x86/kernel/kprobes_32.c
@@ -239,13 +239,7 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
if (!p->ainsn.insn)
return -ENOMEM;
- memcpy(p->ainsn.insn, p->addr, (MAX_INSN_SIZE + 1) *
sizeof(kprobe_opcode_t));
- p->opcode = *p->addr;
- if (can_boost(p->addr)) {
- p->ainsn.boostable = 0;
- } else {
- p->ainsn.boostable = -1;
- }
+ arch_copy_kprobe(p);
return 0;
}
@@ -303,6 +297,15 @@ static s32 __kprobes *is_riprel(u8 *insn)
static void __kprobes arch_copy_kprobe(struct kprobe *p)
{
+#ifdef CONFIG_X86_32
+ memcpy(p->ainsn.insn, p->addr, (MAX_INSN_SIZE + 1) *
sizeof(kprobe_opcode_t));
+ p->opcode = *p->addr;
+ if (can_boost(p->addr)) {
+ p->ainsn.boostable = 0;
+ } else {
+ p->ainsn.boostable = -1;
+ }
+#else
s32 *ripdisp;
memcpy(p->ainsn.insn, p->addr, MAX_INSN_SIZE);
ripdisp = is_riprel(p->ainsn.insn);
@@ -325,6 +328,7 @@ static void __kprobes arch_copy_kprobe(struct kprobe *p)
*ripdisp = disp;
}
p->opcode = *p->addr;
+#endif
}
void __kprobes arch_arm_kprobe(struct kprobe *p)
diff --git a/arch/x86/kernel/kprobes_64.c b/arch/x86/kernel/kprobes_64.c
index 5f02e75..b437f7a 100644
--- a/arch/x86/kernel/kprobes_64.c
+++ b/arch/x86/kernel/kprobes_64.c
@@ -245,9 +245,9 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
{
/* insn: must be on special executable page on x86_32|64. */
p->ainsn.insn = get_insn_slot();
- if (!p->ainsn.insn) {
+ if (!p->ainsn.insn)
return -ENOMEM;
- }
+
arch_copy_kprobe(p);
return 0;
}
@@ -306,6 +306,15 @@ static s32 __kprobes *is_riprel(u8 *insn)
static void __kprobes arch_copy_kprobe(struct kprobe *p)
{
+#ifdef CONFIG_X86_32
+ memcpy(p->ainsn.insn, p->addr, (MAX_INSN_SIZE + 1) *
sizeof(kprobe_opcode_t));
+ p->opcode = *p->addr;
+ if (can_boost(p->addr)) {
+ p->ainsn.boostable = 0;
+ } else {
+ p->ainsn.boostable = -1;
+ }
+#else
s32 *ripdisp;
memcpy(p->ainsn.insn, p->addr, MAX_INSN_SIZE);
ripdisp = is_riprel(p->ainsn.insn);
@@ -328,6 +337,7 @@ static void __kprobes arch_copy_kprobe(struct kprobe *p)
*ripdisp = disp;
}
p->opcode = *p->addr;
+#endif
}
void __kprobes arch_arm_kprobe(struct kprobe *p)
--
1.5.4.rc0.1083.gf568
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: soft lockup - CPU#1 stuck for 15s! [swapper:0]
On Dec 14, 2007 6:17 PM, Len Brown <[EMAIL PROTECTED]> wrote: > does processor.max_cstate=1 make the failing configuration work? > If yes, how about processor.max_cstate=2? Until now 2 things were necessary to reproduce the problem - 1) CPU_IDLE=y and 2) Wakeups from Idle = 5-7 Per second (== Longer/deeper C state residency) If I left the wakeups to high number (50-60) - there were no lockups but it was very jerky over ssh. (Typing keys had no effect for seconds etc.) CPU_IDLE=y With max_cstate=1 and CPU_IDLE=y things are pretty smooth - no lockups for the last hour. (Soft lockups used to appear in minutes previously.) With max_cstate=2 - old story repeats - it's very jerky and soft lockups appear in under a minute after going to 3-5 wakeups from idle per sec. > > what do you see in /proc/acpi/processor/*/power? > Normally (without any max_cstate= parameter) I see this - (I admit I never thought there was a C8 - C3 was all I ever heard.) [EMAIL PROTECTED] router]$ cat /proc/acpi/processor/CPU0/power active state:C2 max_cstate: C8 bus master activity: maximum allowed latency: 8000 usec states: C1: type[C1] promotion[C2] demotion[--] latency[001] usage[1010] duration[] *C2: type[C2] promotion[--] demotion[C1] latency[001] usage[07181700] duration[379397304978] Thanks Parag -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Top kernel oopses/warnings this week
Andrew Morton wrote: On Fri, 14 Dec 2007 10:46:36 -0800 Arjan van de Ven <[EMAIL PROTECTED]> wrote: The http://www.kerneloops.org website collects kernel oops and warning reports from various mailing lists and bugzillas Well that would have been fun to write. Does it watch https://lists.linux-foundation.org/mailman/listinfo/bugme-new ? yes it does; Martin pointed me at that recently What doesn't work yet (I now realize) is the link from the oops to the bugzilla URL; I'll be working on that shortly. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
Arun Thomas wrote: On Dec 14, 2007 2:01 PM, H. Peter Anvin <[EMAIL PROTECTED]> wrote: Thomas Gleixner wrote: The problem is caused by an SMI during the calibration routine. We really need to come up with a solid solution which does not rely on the periodic timer coming in, when there is something else (HPET, pm_timer) available. How long is the SMI? Is there some instrumentation code somewhere which would allow me to determine this? If not, can you give me some hints on where to add the instrumentation code? Well, the most obvious way to do it would be to run the calibration loop a large number of times, and observe the statistical variation. In particular, one should see a bi- or multimodal pattern where the difference between the peaks amount to the "lost time". When we have a clue about the loss of time then we can figure out how to detect it. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Friday, 14 of December 2007, Michael Buesch wrote: > On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote: > > > This user did get the following messages in dmesg: > > > > > > b43err(dev->wl, "Firmware file \"%s\" not found " > > >"or load failed.\n", path); > > > > So the question seems to be why b43 needs version 4, when b43legacy and > > bcm43x uses version 3? > > That's really a question, right? > > Well. linux-2.4 doesn't work with the linux-2.6 modutils. > Windows Vista doesn't work with Windows 98 device drivers. > That leads to this assumption: > b43 doesn't work with version 3 firmware but needs version 4. > > Newer drivers supporting newer hardware need newer firmware. Actually, can you explain why, from the technical point of view, the version 4 firware is better than version 3, please? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
how to implement this logic?
Hi,
I've a block device driver which does the following,
Inside the request function I do something like this:
request(fn) {
while ((req = elv_next_request(q)) != NULL) {
set up the request;
spin_unlock_irq(q->queue_lock);
call the transfer(set_up_req) function;
spin_lock_irq(q->queue_lock);
}
spin_unlock_irq (q->queue_lock);
/* allow callback to execute as it needs the lock!!! */
spin_lock_irq (q->queue_lock);
}
and the transfer function calls the scsi_execute_asyn() with the
callback function doing the end request. So, the ending of the request is
done like below:
callback(fn) {
spin_lock_irqsave(q->queue_lock, flags);
if (!end_that_request_first(set_up_req->req, cmpstatus,
set_up_req->req->nr_sectors)) {
add_disk_randomness(...);
end_that_request_last(set_up_req->req,0);
}
spin_unlock_irqrestore(q->queue_lock, flags);
}
This code works fine with most of the kernel versions, but fails on some
like , Linux 2.6.18-8.el5-xen
Please help me to find out where I'm going wrong?
Thanks in advance for an early reply.
Anil P.
--
View this message in context:
http://www.nabble.com/how-to-implement-this-logic--tp14339868p14339868.html
Sent from the linux-kernel mailing list archive at Nabble.com.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/urandom uses uninit bytes, leaks user data
Theodore Tso wrote: > On Fri, Dec 14, 2007 at 12:45:23PM -0800, John Reiser wrote: > >>>It's getting folded into the random number pool, where it will be >>>impossible to recover it unless you already know what was in the >>>pool. And if you know what's in the pool, you've already broken into >>>the kernel. >> >>The combination of capturing data from other users, plus seeding >>the pool with your own data, just might be powerful enough to help >>steal secrets, sometime in the next five years, from data that is >>recorded today. > > > Um, no. Just seeding the pool with your own data won't help, since > that still won't tell you the initial contents of the pool. And if > you know the initial contents of the pool, then you've broken root. > And being able to steal from the pool also assumes that you've broken > into the system; it is never, ever exported to userspace, even if > you're root (unless you use something like /dev/kmem). Furthermore, > if you don't know the previous contents of the pool, you'll never be > able to recover the information, either now or five years in the > future, since information is XOR'ed into the pool. There is a path that goes from user data into the pool. This path is subject to manipulation by an attacker, for both reading and writing. Are you going to guarantee that in five years nobody will discover a way to take advantage of it? Five years ago there were no public attacks against MD5 except brute force; now MD5 is on the "weak" list. >>>But I'm sympathetic to making Valgrind happy. ... > > > How about wrapping it in a #ifdef CONFIG_UML, which is the only way > you can use Valgrind? The memset will slow down things unnecessarily, > and mixing in the unknown previous contents of the stack (a) doesn't > hurt, and (b) could make life more complicated for an attacker. If speed matters that much, then please recoup 33 cycles on x86 by using shifts instead of three divides, such as (gcc 4.1.2): add_entropy_words(r, tmp, (bytes + 3) / 4); 0x8140689 :lea0x3(%esi),%eax 0x814068c :mov$0x4,%dl 0x814068e :mov%edx,%edi 0x8140690 :cltd 0x8140691 :idiv %edi -- John Reiser, [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
patch add-documentation-for-fair_user_sched-sysfs-files.patch added to gregkh-2.6 tree
This is a note to let you know that I've just added the patch titled Subject: Add Documentation for FAIR_USER_SCHED sysfs files to my gregkh-2.6 tree. Its filename is add-documentation-for-fair_user_sched-sysfs-files.patch This tree can be found at http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/ >From [EMAIL PROTECTED] Tue Dec 11 21:51:17 2007 From: Dhaval Giani <[EMAIL PROTECTED]> Date: Wed, 12 Dec 2007 11:18:59 +0530 Subject: Add Documentation for FAIR_USER_SCHED sysfs files To: Greg KH <[EMAIL PROTECTED]> Cc: lkml , Ingo Molnar <[EMAIL PROTECTED]>, Andrew Morton <[EMAIL PROTECTED]>, Srivatsa Vaddagiri <[EMAIL PROTECTED]>, Balbir Singh <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Disposition: inline This patch adds documentation about /sys/kernel/uids//cpu_share to Documentation/ABI. Signed-off-by: Dhaval Giani <[EMAIL PROTECTED]> Cc: Ingo Molnar <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- Documentation/ABI/testing/sysfs-kernel-uids | 14 ++ 1 file changed, 14 insertions(+) --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-uids @@ -0,0 +1,14 @@ +What: /sys/kernel/uids//cpu_shares +Date: December 2007 +Contact: Dhaval Giani <[EMAIL PROTECTED]> + Srivatsa Vaddagiri <[EMAIL PROTECTED]> +Description: + The /sys/kernel/uids//cpu_shares tunable is used + to set the cpu bandwidth a user is allowed. This is a + propotional value. What that means is that if there + are two users logged in, each with an equal number of + shares, then they will get equal CPU bandwidth. Another + example would be, if User A has shares = 1024 and user + B has shares = 2048, User B will get twice the CPU + bandwidth user A will. For more details refer + Documentation/sched-design-CFS.txt Patches currently in gregkh-2.6 which might be from [EMAIL PROTECTED] are driver/struct-user_info-sysfs.patch driver/add-documentation-for-fair_user_sched-sysfs-files.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] tmpfs: restore missing clear_highpage
On Wed, Dec 12, 2007 at 05:01:51AM +, Hugh Dickins wrote: > On Tue, 11 Dec 2007, Chuck Ebbert wrote: > > On 11/28/2007 01:55 PM, Hugh Dickins wrote: > > > tmpfs was misconverted to __GFP_ZERO in 2.6.11. There's an unusual case > > > in > > > which shmem_getpage receives the page from its caller instead of > > > allocating. > > > We must cover this case by clear_highpage before SetPageUptodate, as > > > before. > > > > > > Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> > > > --- > > > > What are the symptoms of the bug this fixes? > > I've not seen it in practice, just noticed it while working on that > area in the code. What's the polite way of describing these things > in public? It's a vulnerability which might allow an attacker to > access data from inside the kernel which should have been zeroed - > in very limited circumstances I'd prefer not to have to devise and > announce. > > It would also be wrong data, so could for example crash any program > rightly relying on uninitialized static data to be zeroed - in the > unlikely event that its data was coming via this route (in most setups > it never can do, perhaps I'd conclude that's true of all setups). It > has escaped notice for nearly three years, so it's not a commonplace. > > Further discussion offline if you like! Can we get or is there already a CVE number? > Hugh 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: [PATCH] Option to disable AMD C1E (allows dynticks to work)
On Fri, 14 Dec 2007 17:35:13 -0500 Chuck Ebbert <[EMAIL PROTECTED]> wrote: > On 12/14/2007 05:17 AM, Andi Kleen wrote: > >> so do whatever is necessary to enable dynticks. > > > > dynticks' main purpose is to save power, but C1e saves more power. > > Disabling C1e for dynticks would be a fairly useless default > > trade off. > > > > What about machines where the BIOS has disabled C1e on CPU 0 but > left it enabled on CPU 1 ?? Do you mean Linux should enable C1E on CPU 0 if it's detected on CPU 1? C3 + dynticks make up a better power saver than simply C1E, as far as I know. Higher C-states should be enabled on such CPUs, as AMD docs say firmware should either enable C1E or C2 & C3 (it must provide one of these mutually exclusive options). I take having C1E on the second CPU but not the first as an attempt on BIOS's part to provide higher C-states instead of the former. How broken is it, really? But maybe someone with access to such hardware can tell us what happens: does he get C2/C3 power states under such circumstances? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 01/10] e1000e: make E1000E default to the same kconfig setting as E1000
On Fri, Dec 14, 2007 at 06:17:55PM -0500, Jeff Garzik wrote: > Adrian Bunk wrote: >> On Fri, Dec 14, 2007 at 03:39:26PM -0500, Jeff Garzik wrote: >>> [EMAIL PROTECTED] wrote: From: Randy Dunlap <[EMAIL PROTECTED]> >>> ... >>> So I think the breakage that occurs is mitigated by two factors: >>> 1) kernel hackers that do their own configs are expected to be able to >>> figure this stuff. >>> 2) kernel builders (read: distros, mainly) are expected to have put >>> thought into the Kconfig selection and driver migration strategies. >>> ... >>> I would prefer simply to communicate to kernel experts and builders about >>> a Kconfig issue that could potentially their booting/networking... >>> because this patch is only needed if the kernel experts do not already >>> know about a necessary config update. >> >> You miss the vast majority of kconfig users: >> >> 3) system administrators etc. who for different reasons compile their own >> kernels but neither are nor want to be kernel developers >> >> There's a reason why e.g. LPI requires you to be able to compile your own >> kernel even for getting a "Junior Level Linux Professional" certificate. > > Great! > > >> Or that one of the authors of "Linux Device drivers" has written a book >> covering only how to build and run your own kernel. > > Nonetheless, it will always be true that configuring your own kernel > requires knowledge of the options you are setting. We are not talking about Aunt Tillie, "system administrator" is the use case that might cover this (quite diverse) group of users best. We can expect kconfig users to know what filesystems their data is on and to have some knowledge of their hardware, but every other knowledge we must give through kconfig. > Jeff 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: PROBLEM: E6850 has an 8+ minute delay during boot
On Dec 14, 2007 2:01 PM, H. Peter Anvin <[EMAIL PROTECTED]> wrote: > Thomas Gleixner wrote: > > > > The problem is caused by an SMI during the calibration routine. We > > really need to come up with a solid solution which does not rely on > > the periodic timer coming in, when there is something else (HPET, > > pm_timer) available. > > How long is the SMI? Is there some instrumentation code somewhere which would allow me to determine this? If not, can you give me some hints on where to add the instrumentation code? Thanks, Arun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 01/10] e1000e: make E1000E default to the same kconfig setting as E1000
Andrew Morton wrote: On Fri, 14 Dec 2007 15:39:26 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote: From: Randy Dunlap <[EMAIL PROTECTED]> Make E1000E default to the same kconfig setting as E1000. So people's machiens don't stop working when they use oldconfig. Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> Cc: Auke Kok <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/net/Kconfig |1 + 1 file changed, 1 insertion(+) diff -puN drivers/net/Kconfig~e1000e-make-e1000e-default-to-the-same-kconfig-setting-as-e1000 drivers/net/Kconfig --- a/drivers/net/Kconfig~e1000e-make-e1000e-default-to-the-same-kconfig-setting-as-e1000 +++ a/drivers/net/Kconfig @@ -1986,6 +1986,7 @@ config E1000_DISABLE_PACKET_SPLIT config E1000E tristate "Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support" depends on PCI + default E1000 I am not inclined to apply this one. This practice, applied over time, will tend to accumulate weird 'default' and 'select' statements. So I think the breakage that occurs is mitigated by two factors: 1) kernel hackers that do their own configs are expected to be able to figure this stuff. 2) kernel builders (read: distros, mainly) are expected to have put thought into the Kconfig selection and driver migration strategies. PCI IDs move across drivers from time, and we don't want to apply these sorts changes: Viewed in the long term, the suggested patch is merely a temporary change to allow kernel experts to more easily deal with the PCI ID migration across drivers. I would prefer simply to communicate to kernel experts and builders about a Kconfig issue that could potentially their booting/networking... because this patch is only needed if the kernel experts do not already know about a necessary config update. You can take it out again later on - most people's .configs will then have E1000E set. People who still do `cp ancientconfig .config ; make oldconfig' remain screwed. Sounds like something build system should help with. Some more user friendly syntax for dealing with issues of driver conversion. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] fix bloat-o-meter for ppc64
bloat-o-meter assumes that a '.' anywhere in a symbol's name means
that it is static and prepends 'static.' to the first part of the
symbol name, discarding the portion of the name that follows the '.'.
However, the names of function entry points begin with '.' in the
ppc64 ABI. This causes all function text size changes to be accounted
to a single 'static.' entry in the output when comparing ppc64
kernels.
Change getsizes() to ignore the first character of the symbol name
when searching for '.'.
Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
---
scripts/bloat-o-meter |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/scripts/bloat-o-meter b/scripts/bloat-o-meter
index ce59fc2..6501a50 100755
--- a/scripts/bloat-o-meter
+++ b/scripts/bloat-o-meter
@@ -18,7 +18,8 @@ def getsizes(file):
for l in os.popen("nm --size-sort " + file).readlines():
size, type, name = l[:-1].split()
if type in "tTdDbB":
-if "." in name: name = "static." + name.split(".")[0]
+# function names begin with '.' on 64-bit powerpc
+if "." in name[1:]: name = "static." + name.split(".")[0]
sym[name] = sym.get(name, 0) + int(size, 16)
return sym
--
1.5.3.7.1112.g9758e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Fri, 14 Dec 2007 14:13:46 -0800 "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: > Pavel Machek wrote: > > On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote: > >> Ingo Molnar wrote: > >>> wow, cool fix! (I remember that there were other systems as well that are > >>> affected by port 0x80 muckery - i thought we had removed port 0x80 > >>> accesses long ago.) > >>> how about the simpler fix below, as a first-level approach? We can then > >>> remove the _p in/out sequences after this. > >> I believe this will suffer from the issue that was raised: this will use > >> udelay() long before loop calibration (and no, we can't just "be > >> conservative" since there is no "conservative" value we can use.) > > > > ?? Just initialize bogomips to 6GHz equivalent... and we are fine > > until 6GHz cpus come out. > > How long will that take to boot on a 386? Well the dumb approach to fix that would seem to be to initialise it to cpu->family 3 -> 50MHz 4 -> 300Mhz 5-> etc... Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.24-rc5-mm1 -- inconsistent {in-softirq-W} -> {softirq-on-R} usage.
On Fri, 14 Dec 2007 17:13:21 -0500
"Miles Lane" <[EMAIL PROTECTED]> wrote:
> Sorry Andrew, I don't know who to forward this problem to.
>
> I tried running: find /proc | xargs cat
> and got this:
>
> =
> [ INFO: inconsistent lock state ]
> 2.6.24-rc5-mm1 #26
> -
> inconsistent {in-softirq-W} -> {softirq-on-R} usage.
> cat/6944 [HC0[0]:SC0[0]:HE1:SE1] takes:
> BUG: unable to handle kernel paging request at virtual address 0f1eff0b
> printing ip: c01fe64d *pde =
> Oops: [#1] PREEMPT SMP
> last sysfs file: /sys/block/sda/sda3/stat
> Modules linked in: aes_generic i915 drm rfcomm l2cap bluetooth
> cpufreq_stats cpufreq_conservative cpufreq_performance sbs sbshc
> dm_crypt sbp2 parport_pc lp parport pcmcia arc4 ecb crypto_blkcipher
> cryptomgr crypto_algapi tifm_7xx1 tifm_core yenta_socket
> rsrc_nonstatic pcmcia_core iwl3945 iTCO_wdt iTCO_vendor_support
> watchdog_core watchdog_dev snd_hda_intel mac80211 snd_pcm_oss
> snd_mixer_oss cfg80211 snd_pcm sky2 snd_seq_dummy snd_seq_oss
> snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer
> snd_seq_device snd soundcore snd_page_alloc shpchp pci_hotplug
> firewire_ohci firewire_core crc_itu_t ata_generic piix ide_core
>
> Pid: 6944, comm: cat Not tainted (2.6.24-rc5-mm1 #26)
> EIP: 0060:[] EFLAGS: 00210097 CPU: 0
> EIP is at strnlen+0x9/0x1c
> EAX: 0f1eff0b EBX: 0f1eff0b ECX: 0f1eff0b EDX: fffe
> ESI: c05b74f6 EDI: d6267d94 EBP: d6267cc8 ESP: d6267cc8
> DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> Process cat (pid: 6944, ti=d6267000 task=d5a09000 task.ti=d6267000)
> Stack: d6267cfc c01fdd22 0400 c05b74f4 0001 c05b78f4
> c048f503 0400 d5a09000 0002 d6267d0c c01fdf41 d6267d94
>db68c04a d6267d74 c012ae81 d6267d94 0028 c05b89f7 00200046
> Call Trace:
> [] show_trace_log_lvl+0x12/0x25
> [] show_stack_log_lvl+0x8a/0x95
> [] show_registers+0x8a/0x1bd
> [] die+0x118/0x1dc
> [] do_page_fault+0x5a4/0x681
> [] error_code+0x72/0x78
> [] vsnprintf+0x277/0x40e
> [] vscnprintf+0xe/0x1d
> [] vprintk+0xcb/0x2f3
> [] printk+0x15/0x17
> [] print_lock_name+0x4e/0xa2
> [] print_lock+0xe/0x3a
> [] print_usage_bug+0xbc/0x117
> [] mark_lock+0x2e7/0x3fe
> [] __lock_acquire+0x498/0xbf4
> [] lock_acquire+0x76/0x9d
> [] _read_lock+0x23/0x32
> [] sock_i_ino+0x14/0x30
> [] packet_seq_show+0x22/0x75
> [] seq_read+0x19d/0x26f
> [] proc_reg_read+0x60/0x74
> [] vfs_read+0x8a/0x106
> [] sys_read+0x3b/0x60
> [] sysenter_past_esp+0x6b/0xc1
> ===
> Code: 01 00 00 00 4f 89 fa 5f 89 d0 5d c3 55 85 c9 89 e5 57 89 c7 89
> d0 74 05 f2 ae 75 01 4f 89 f8 5f 5d c3 55 89 c1 89 e5 89 c8 eb 06 <80>
> 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 5d c3 90 90 90 55 83
> EIP: [] strnlen+0x9/0x1c SS:ESP 0068:d6267cc8
> note: cat[6944] exited with preempt_count 4
I'd say you hit a networking locking bug and then when trying to report
that bug, lockdep crashed.
The networking bug looks to be around sock_i_ino()'s taking of
sk_callback_lock with softirq's enabled. Perhaps this will fix it.
diff -puN net/core/sock.c~a net/core/sock.c
--- a/net/core/sock.c~a
+++ a/net/core/sock.c
@@ -1115,9 +1115,9 @@ int sock_i_uid(struct sock *sk)
{
int uid;
- read_lock(>sk_callback_lock);
+ read_lock_bh(>sk_callback_lock);
uid = sk->sk_socket ? SOCK_INODE(sk->sk_socket)->i_uid : 0;
- read_unlock(>sk_callback_lock);
+ read_unlock_bh(>sk_callback_lock);
return uid;
}
@@ -1125,9 +1125,9 @@ unsigned long sock_i_ino(struct sock *sk
{
unsigned long ino;
- read_lock(>sk_callback_lock);
+ read_lock_bh(>sk_callback_lock);
ino = sk->sk_socket ? SOCK_INODE(sk->sk_socket)->i_ino : 0;
- read_unlock(>sk_callback_lock);
+ read_unlock_bh(>sk_callback_lock);
return ino;
}
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 02/12] PAT 64b: Basic PAT implementation
On Fri, Dec 14, 2007 at 01:10:39PM -0800, Siddha, Suresh B wrote:
> On Thu, Dec 13, 2007 at 09:23:26PM -0700, Eric W. Biederman wrote:
> > [EMAIL PROTECTED] (Eric W. Biederman) writes:
> > Ok. My analysis here was wrong. Currently pgprot_noncached and
> > ioremap_nocache are out of sync. With ioremap_nocache only specifying
> > _PAGE_PCD and pgprot_noncached specifying _PAGE_PCD | _PAGE_PWT.
> >
> > So I don't have a clue how someone could reprogram the mtrrs currently
> > and expect things to work.
> >
> > ...
> >
> > If we bother to ask ioremap for memory that is not cached, the last
> > thing in the world we want is the MTRRs upgrading that to write combining.
> > So ioremap_nocache has been slightly buggy for ages. ioremap_nocache
> > and PAGE_KERNEL_NOCACHE should get _PAGE_PWT added to their
> > definitions.
> >
> > Could we please get a cleanup patch at the beginning of this patchset
> > or that comes before it that fixes ioremap_nocache on x86?
> >
> > That will make us a lot more git-bisect safe.
>
> Ok. I will send a separate patch fixing ioremap_nocache on x86.
Appended the patch. x86 folks, please consider for x86 mm git tree. Thanks.
---
[patch] x86: Set strong uncacheable where UC is really desired
Also use _PAGE_PWT for all the mappings which need uncache mapping. Instead of
existing PAT2 which is UC- (and can be overwritten by MTRRs), we now use PAT3
which is strong uncacheable.
This makes it consistent with pgprot_noncached()
Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
---
diff --git a/arch/x86/mm/ioremap_32.c b/arch/x86/mm/ioremap_32.c
index 0b27831..ef0f6a4 100644
--- a/arch/x86/mm/ioremap_32.c
+++ b/arch/x86/mm/ioremap_32.c
@@ -119,7 +119,7 @@ EXPORT_SYMBOL(__ioremap);
void __iomem *ioremap_nocache (unsigned long phys_addr, unsigned long size)
{
unsigned long last_addr;
- void __iomem *p = __ioremap(phys_addr, size, _PAGE_PCD);
+ void __iomem *p = __ioremap(phys_addr, size, _PAGE_PCD | _PAGE_PWT);
if (!p)
return p;
diff --git a/arch/x86/mm/ioremap_64.c b/arch/x86/mm/ioremap_64.c
index 6cac90a..8be3062 100644
--- a/arch/x86/mm/ioremap_64.c
+++ b/arch/x86/mm/ioremap_64.c
@@ -158,7 +158,7 @@ EXPORT_SYMBOL(__ioremap);
void __iomem *ioremap_nocache (unsigned long phys_addr, unsigned long size)
{
- return __ioremap(phys_addr, size, _PAGE_PCD);
+ return __ioremap(phys_addr, size, _PAGE_PCD | _PAGE_PWT);
}
EXPORT_SYMBOL(ioremap_nocache);
diff --git a/include/asm-x86/pgtable_32.h b/include/asm-x86/pgtable_32.h
index ed3e70d..b1215e1 100644
--- a/include/asm-x86/pgtable_32.h
+++ b/include/asm-x86/pgtable_32.h
@@ -156,7 +156,7 @@ void paging_init(void);
extern unsigned long long __PAGE_KERNEL, __PAGE_KERNEL_EXEC;
#define __PAGE_KERNEL_RO (__PAGE_KERNEL & ~_PAGE_RW)
#define __PAGE_KERNEL_RX (__PAGE_KERNEL_EXEC & ~_PAGE_RW)
-#define __PAGE_KERNEL_NOCACHE (__PAGE_KERNEL | _PAGE_PCD)
+#define __PAGE_KERNEL_NOCACHE (__PAGE_KERNEL | _PAGE_PCD | _PAGE_PWT)
#define __PAGE_KERNEL_LARGE(__PAGE_KERNEL | _PAGE_PSE)
#define __PAGE_KERNEL_LARGE_EXEC (__PAGE_KERNEL_EXEC | _PAGE_PSE)
diff --git a/include/asm-x86/pgtable_64.h b/include/asm-x86/pgtable_64.h
index 9b0ff47..4e4dcc4 100644
--- a/include/asm-x86/pgtable_64.h
+++ b/include/asm-x86/pgtable_64.h
@@ -185,13 +185,13 @@ static inline pte_t ptep_get_and_clear_full(struct
mm_struct *mm, unsigned long
#define __PAGE_KERNEL_EXEC \
(_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY | _PAGE_ACCESSED)
#define __PAGE_KERNEL_NOCACHE \
- (_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY | _PAGE_PCD | _PAGE_ACCESSED |
_PAGE_NX)
+ (_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY | _PAGE_PCD | _PAGE_PWT |
_PAGE_ACCESSED | _PAGE_NX)
#define __PAGE_KERNEL_RO \
(_PAGE_PRESENT | _PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_NX)
#define __PAGE_KERNEL_VSYSCALL \
(_PAGE_PRESENT | _PAGE_USER | _PAGE_ACCESSED)
#define __PAGE_KERNEL_VSYSCALL_NOCACHE \
- (_PAGE_PRESENT | _PAGE_USER | _PAGE_ACCESSED | _PAGE_PCD)
+ (_PAGE_PRESENT | _PAGE_USER | _PAGE_ACCESSED | _PAGE_PCD | _PAGE_PWT)
#define __PAGE_KERNEL_LARGE \
(__PAGE_KERNEL | _PAGE_PSE)
#define __PAGE_KERNEL_LARGE_EXEC \
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/urandom uses uninit bytes, leaks user data
On Fri, Dec 14, 2007 at 12:45:23PM -0800, John Reiser wrote: > > It's getting folded into the random number pool, where it will be > > impossible to recover it unless you already know what was in the > > pool. And if you know what's in the pool, you've already broken into > > the kernel. > > The combination of capturing data from other users, plus seeding > the pool with your own data, just might be powerful enough to help > steal secrets, sometime in the next five years, from data that is > recorded today. Um, no. Just seeding the pool with your own data won't help, since that still won't tell you the initial contents of the pool. And if you know the initial contents of the pool, then you've broken root. And being able to steal from the pool also assumes that you've broken into the system; it is never, ever exported to userspace, even if you're root (unless you use something like /dev/kmem). Furthermore, if you don't know the previous contents of the pool, you'll never be able to recover the information, either now or five years in the future, since information is XOR'ed into the pool. > > But I'm sympathetic to making Valgrind happy. ... How about wrapping it in a #ifdef CONFIG_UML, which is the only way you can use Valgrind? The memset will slow down things unnecessarily, and mixing in the unknown previous contents of the stack (a) doesn't hurt, and (b) could make life more complicated for an attacker. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
