Re: [patch] sched: remove __resched_legal() and fix cond_resched_softirq()
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * OGAWA Hirofumi <[EMAIL PROTECTED]> wrote:
>
>> "Fabio Comolli" <[EMAIL PROTECTED]> writes:
>>
>> > Just found this in syslog. It was during normal activity, about 6
>> > minutes after resume-from-ram. I never saw this before.
>>
>> It seems someone missed to check PREEMPT_ACTIVE in __resched_legal().
>
> but PREEMPT_ACTIVE is 0x1000, not 0x2000.
>
>> Could you please test the following patch?
>
> no. cond_resched() is always legal in the !PREEMPT case.
>
> i found another bug and realized that the whole __resched_legal()
> approach is fundamentally wrong! The patch below fixes this.
Hmm.. but the path seems,
-> cond_resched()
-> if (__resched_legal()) /* preempt_count == 0 */
-> __cond_resched() /* preempt_count == 0x1000 */
-> schedule()
[...]
-> cond_resched()
-> if (__resched_legal()) /* preempt_count == 0x1000 */
-> __cond_resched() /* preempt_count == 0x2000 */
-> schedule() /* warning */
Where is it prevented? Or warning is just wrong?
> --->
> Subject: [patch] sched: remove __resched_legal() and fix
> cond_resched_softirq()
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> remove the __resched_legal() check: it is conceptually broken. The
> biggest problem it had is that it can mask buggy cond_resched() calls. A
> cond_resched() call is only legal if we are not in an atomic context.
> But __resched_legal() hid this fact. Same goes for cond_resched_locked()
> and cond_resched_softirq().
>
> furthermore, the __legal_resched(0) call was buggy in
> cond_resched_softirq() and caused unnecessary long softirq latencies!
>
> the fix is to preserve the only valid inhibitor to voluntary preemption:
> if the system is still booting. None of the other behavior of
> __resched_legal() made any sense.
>
> the effect of this fix should be more real bugs exposed, and shorter
> softirq latencies.
>
> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
> ---
> kernel/sched.c | 17 +++--
> 1 file changed, 3 insertions(+), 14 deletions(-)
>
> Index: linux/kernel/sched.c
> ===
> --- linux.orig/kernel/sched.c
> +++ linux/kernel/sched.c
> @@ -4617,17 +4617,6 @@ asmlinkage long sys_sched_yield(void)
> return 0;
> }
>
> -static inline int __resched_legal(int expected_preempt_count)
> -{
> -#ifdef CONFIG_PREEMPT
> - if (unlikely(preempt_count() != expected_preempt_count))
> - return 0;
> -#endif
> - if (unlikely(system_state != SYSTEM_RUNNING))
> - return 0;
> - return 1;
> -}
> -
> static void __cond_resched(void)
> {
> #ifdef CONFIG_DEBUG_SPINLOCK_SLEEP
> @@ -4647,7 +4636,7 @@ static void __cond_resched(void)
>
> int __sched cond_resched(void)
> {
> - if (need_resched() && __resched_legal(0)) {
> + if (need_resched() && system_state == SYSTEM_RUNNING) {
> __cond_resched();
> return 1;
> }
> @@ -4673,7 +4662,7 @@ int cond_resched_lock(spinlock_t *lock)
> ret = 1;
> spin_lock(lock);
> }
> - if (need_resched() && __resched_legal(1)) {
> + if (need_resched() && system_state == SYSTEM_RUNNING) {
> spin_release(>dep_map, 1, _THIS_IP_);
> _raw_spin_unlock(lock);
> preempt_enable_no_resched();
> @@ -4689,7 +4678,7 @@ int __sched cond_resched_softirq(void)
> {
> BUG_ON(!in_softirq());
>
> - if (need_resched() && __resched_legal(0)) {
> + if (need_resched() && system_state == SYSTEM_RUNNING) {
> raw_local_irq_disable();
> _local_bh_enable();
> raw_local_irq_enable();
--
OGAWA Hirofumi <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PATA -- pata_amd on 2.6.19 fails to IDENTIFY my DVD-ROM
Rene Herman wrote: > Good day. > > I just tried the PATA driver for my AMD756 chip. During boot, it hangs > for 3 minutes failing to identify my DVD-ROM (secondary slave) and does > not give me access to it after it timed out. Please give a shot at v2.6.20-rc2 and report what the kernel says. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one
On Tue, 26 Dec 2006, David Miller wrote:
>
> I've seen it on sparc64, UP kernel, no preempt.
Btw, having tried to debug the writeback code, there's one very special
case that just makes me go "hmm".
If we have a buffer that is "busy" when we try to write back a page, we
have this magic "wbc->sync_mode == WB_SYNC_NONE && wbc->nonblocking" mode,
where we won't wait for it, but instead we'll redirty the page and redo
the whole thing.
Looking at the code, that should all work, but at the same time, it
triggers some of my debug messages about having a dirty page during
writeback, and one way to trigger that debug message is to try to run
rtorrent on the machine..
I dunno. Witht he writeback being suspicious, and the normal
"block_write_full_page()" path being implicated in at least ext2, I just
wonder. This is one of those "let's see if behaviour changes" patches,
that I'm just throwing out there..
Linus
---
diff --git a/fs/buffer.c b/fs/buffer.c
index 263f88e..4652ef1 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1653,19 +1653,7 @@ static int __block_write_full_page(struct inode *inode,
struct page *page,
do {
if (!buffer_mapped(bh))
continue;
- /*
-* If it's a fully non-blocking write attempt and we cannot
-* lock the buffer then redirty the page. Note that this can
-* potentially cause a busy-wait loop from pdflush and kswapd
-* activity, but those code paths have their own higher-level
-* throttling.
-*/
- if (wbc->sync_mode != WB_SYNC_NONE || !wbc->nonblocking) {
- lock_buffer(bh);
- } else if (test_set_buffer_locked(bh)) {
- redirty_page_for_writepage(wbc, page);
- continue;
- }
+ lock_buffer(bh);
if (test_clear_buffer_dirty(bh)) {
mark_buffer_async_write(bh);
} else {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PATA_SIS and SIS 5513
Ioan Ionita wrote: > pata_sis will not work with my CD-ROM > > dmesg output when trying to mount a cd-rom: Please post full dmesg including all boot messages. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
problem with starting an application daemon from rcS script in case of lnux-2.6.18 kernel version.
Hi,
I wrote a small appication "test_shell" and started
the same as a background process ("test_shell&") from
"rcS" script to print a message "This is to test the
shell for daemon processes" on console for every ten
seconds.
For this, the rcS script contains the below command:
"test_shell &"
I have built two images for the target with the kernel
versions linux-2.6.18 and linux-mips-2.6.12.
In case of liunux-mips-2.6.12 i am able to see the
prints on the console.
In case of liunux-2.6.18 i am not getting the prints
on the console. if i try "ps" command i am able to see
the process running in the background.
In both kernel versions libraries and shell used are
same.
What could be the reason for this?
Please suggest me some solution for this.
Could any body please suggest an alternate solution to
start the application from the rcS as a daemon
"test_shell&" and still get the prints on the
console???
Thanks in advance.
Regards,
veeru.
Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download
Now! http://messenger.yahoo.com/download.php
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ip_recv_error (ip_sockglue.c) - why zero the port on ICMP errors?
Hello all,
I am developing a UDP application and wish to receive
the ICMP unreachable messages that some hosts send in
response to a UDP datagram that hits a closed port. I
use the IP_RECVERR on my socket, recvmsg (fd, ,
MSG_ERRQUEUE) and all that, however the returned port
in the sock_extended_err SO_EE_OFFENDER data always 0.
The following code in net/ipv4/ip_sockglue.c
illustrates this:
...
sin =
sin->sin_family = AF_UNSPEC;
if (serr->ee.ee_origin == SO_EE_ORIGIN_ICMP) {
struct inet_sock *inet = inet_sk(sk);
sin->sin_family = AF_INET;
sin->sin_addr.s_addr = skb->nh.iph->saddr;
sin->sin_port = 0;
memset(>sin_zero, 0, sizeof(sin->sin_zero));
if (inet->cmsg_flags)
ip_cmsg_recv(msg, skb);
}
...
For some reason, even though the full IP header is
available here (and the port preserved in
ip_icmp_error), sin->sin_port is set to zero in the
ip_recv_error function, which really hurts the
potential use of this in some applications which need
the port to uniquely identify multiple clients using
the same IP address.
I realise there's more than one way to do this - as a
workaround, I am using the msg.msg_name field, however
on earlier kernel versions (or maybe an earlier libc -
I didn't track down the reason), the msg.msg_name
field is not set correctly and the data fetched by
SO_EE_OFFENDER is the only way to find out the full
source of the error.
I'm just curious as to the reasoning behind zeroing
out the port in this piece of code, it doesn't seem to
make much sense as usermode applications will just see
a zero port instead of the real port. I noticed in
earlier kernel versions that sin_port and sin_zero
were unspecified which led to uninitialized kernel
stack memory being returned, maybe this was a hasty
bug fix for that problem?
I hope someone can quell my curiosity behind this :). Thanks.
Send instant messages to your online friends http://uk.messenger.yahoo.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: Feature request: exec self for NOMMU.
On Wed, 2006-12-27 at 00:51 -0500, Rob Landley wrote:
> On Wednesday 27 December 2006 12:13 am, Ray Lee wrote:
> > How about openning an fd to yourself at the beginning of execution, then
> > calling fexecve later?
>
> I haven't got a man page for fexecve. Does libc have it?
It's implemented inside glibc, and uses /proc to execve() the file that
the fd points to. Here's the code from
sysdeps/unix/sysv/linux/fexecve.c:
fexecve (fd, argv, envp)
int fd;
char *const argv[];
char *const envp[];
{
...
/* We use the /proc filesystem to get the information. If it is not
mounted we fail. */
char buf[sizeof "/proc/self/fd/" + sizeof (int) * 3];
__snprintf (buf, sizeof (buf), "/proc/self/fd/%d", fd);
/* We do not need the return value. */
__execve (buf, argv, envp);
...
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: System / libata IDE controller woes (long)
On Wednesday 27 December 2006 00:50, Erik Ohrnberger wrote: >Hi There! > Yea, I thought that it might be power related as well, so I moved >1/2 of the drives from the 500 Watt power supply onto a separate one, > and it did not change any of the symptoms. So I think that it's been > ruled out. > > Thanks, > Erik. Cable lengths can be a bear too, particularly if the drive set as master is NOT on the end connector of the cable. >> Hello, >> >> Erik Ohrnberger wrote: >> > Earlier this year, when I started putting it together, I >> >> gathered my >> >> > hardware. A decent 2 GHz Athlon system with 512 MB RAM, >> >> DVD drive, a >> >> > 40 GB system drive, and a 500 Watt power supply. Then I started >> > adding hard disks. To date, I've got 5 80 GB PATA, 2 200 >> >> GB PATA, and 1 60 GB PATA. >> >> That's 9 hard drives. How did you hook up your power supply? >> My dual-rail 450w PS has a lot of problem driving 9 drives >> no matter how I hook it up while my 350w power supply can >> happily handle the load. I suspect it's because how the >> separate 12v rails are configured in the PS. >> >> It's nothing concrete but I wanna rule PS issue first. If >> you've got an extra power supply (buy cheap 350w one if you >> don't have one), hook half of the drives to it and see what >> happens. Using PS without motherboard is easy. Just ask google. >> >> Happy holidays. >> >> -- >> tejun > >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" > in the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ -- 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) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Feature request: exec self for NOMMU.
On Wednesday 27 December 2006 12:13 am, Ray Lee wrote: > How about openning an fd to yourself at the beginning of execution, then > calling fexecve later? I haven't got a man page for fexecve. Does libc have it? In the 2.6.19 kernel: "find . | xargs grep fexecve" produces no hits. Are you sure there _is_ one? Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: System / libata IDE controller woes (long)
Hi There! Yea, I thought that it might be power related as well, so I moved 1/2 of the drives from the 500 Watt power supply onto a separate one, and it did not change any of the symptoms. So I think that it's been ruled out. Thanks, Erik. > > Hello, > > Erik Ohrnberger wrote: > > Earlier this year, when I started putting it together, I > gathered my > > hardware. A decent 2 GHz Athlon system with 512 MB RAM, > DVD drive, a > > 40 GB system drive, and a 500 Watt power supply. Then I started > > adding hard disks. To date, I've got 5 80 GB PATA, 2 200 > GB PATA, and 1 60 GB PATA. > > That's 9 hard drives. How did you hook up your power supply? > My dual-rail 450w PS has a lot of problem driving 9 drives > no matter how I hook it up while my 350w power supply can > happily handle the load. I suspect it's because how the > separate 12v rails are configured in the PS. > > It's nothing concrete but I wanna rule PS issue first. If > you've got an extra power supply (buy cheap 350w one if you > don't have one), hook half of the drives to it and see what > happens. Using PS without motherboard is easy. Just ask google. > > Happy holidays. > > -- > tejun > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Feature request: exec self for NOMMU.
On Tuesday 26 December 2006 11:24 pm, Denis Vlasenko wrote:
> busybox needs it in order to spawn, for example, gzip/bzip2 helper
> for tar. We know that our own executable has this function.
> How to execute _our own executable_? exec("/proc/self/exe")
> works only if /proc is mounted. I can imagine that some embedded
> people want to be able to not rely on that.
Actually, we added CONFIG_BUSYBOX_EXEC_PATH so you could feed it a different
path to the busybox executable if you haven't got proc. It's still a hack,
and it still breaks when you chroot, but you can use the standalone shell
without /proc.
Why do people chroot? To do system recovery using busybox with the standalone
shell and built-in commands. They chroot into the damaged root partition to
run some of the commands in there (shared library paths get a bit twitchy
without the chroot), but they want to use the built-in busybox commands for
most of it because PAM and selinux can get screwed up by passing birds,
brightly colored wallpaper or large flowers, and when they do they interfere
with everything.
*shrug* This was a bigger deal a few years ago, before the invention of the
knoppix CD...
Rob
--
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sata_mv and Marvell 88SE6121
Jose Alberto Reguero wrote: > Can this sata controler Marvell 88SE6121 work with this driver? > Is anything I can try to make it work? > Any hints are welcome. > Thanks. Combination of sata_mv and pata_marvell should do it. Beware that sata_mv is still experimental. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Feature request: exec self for NOMMU.
On 12/26/06, Rob Landley <[EMAIL PROTECTED]> wrote: I'm trying to make some nommu-friendly busybox-like tools, which means using vfork() instead of fork(). This means that after I fork I have to exec in the child to unblock the parent, and if I want to exec my current executable I have to find out where it lives so I can feed the path to exec(). This is nontrivial. Worse, it's not always possible. If chroot() has happened since the program started, there may not _be_ a path to my current executable available from this process's current or root directories. How about openning an fd to yourself at the beginning of execution, then calling fexecve later? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.19.1, sata_sil: sata dvd writer doesn't work
Harald Dunkel wrote: > Hi Tejun, > > Tejun Heo wrote: >> * dmesg is truncated, please post the content of file /var/log/boot.msg. >> >> * Please post the result of 'lspci -nnvvv' >> >> * Please try the attached patch and see if it makes any difference and >> post the result of 'dmesg' after trying to play a problematic dvd. >> > > It still doesn't work, but the dmesg output looks less > weird. See attachments. > > > Hope this helps. Please mail. Okay, Hmmm... Weird. I tried to reproduce it here w/ LG dvd ram and sil3114 (almost identical, just two more ports) with no success. I just ordered SH-S183A and it should arrive later today (zero-day shipping just at USD 3.5!). I'll write again when I know more. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one
From: Tobias Diedrich <[EMAIL PROTECTED]> Date: Tue, 26 Dec 2006 17:17:00 +0100 > Linus Torvalds wrote: > > I don't think it's a page table issue any more, it just doesn't look > > likely with the ARM UP corruption. It's also not apparently even on a > > cacheline boundary, so it probably is really a dirty bit that got cleared > > wrogn due to some race with IO. > > So, until now it's only been reported for SMP on i386? > I'm seeing the issue on my Pentium-M Notebook (Thinkpad R52) over > here, UP kernel, no preempt. I've seen it on sparc64, UP kernel, no preempt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: util-linux: orphan
On Tue, Dec 26, 2006 at 07:08:43PM -0800, H. Peter Anvin wrote: > >I saw that the current Fedora already dynamically links /bin/mount > >against /usr/lib/libblkid.so. This obviously does not work if > >/usr is a separate partition that needs to be mounted with /bin/mount. > >I also had problems with selinux claiming I had no right to access > >libblkid, which meant that the root fs could not be remounted r/w. > > > >I'd suggest that you make sure that mount always gets statically linked > >against libblkid to avoid these problems. > > That's a pretty silly statement. The real issue is that any library > needed by binaries in /bin or /sbin should live in /lib, not /usr/lib. >From a Debian unstable system: think:~# ldd /bin/mount linux-gate.so.1 => (0xe000) libblkid.so.1 => /lib/libblkid.so.1 (0xb7f23000) libuuid.so.1 => /lib/libuuid.so.1 (0xb7f2) libc.so.6 => /lib/libc.so.6 (0xb7ddf000) libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0xb7dcd000) libselinux.so.1 => /lib/libselinux.so.1 (0xb7db8000) libsepol.so.1 => /lib/libsepol.so.1 (0xb7d77000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7d61000) /lib/ld-linux.so.2 (0xb7f3f000) libdl.so.2 => /lib/libdl.so.2 (0xb7d5d000) ... and in fact the e2fsprogs's configure program normally installs the critical libraries used by mount, fsck, e2fsck, including the blkid and uuid libraries, in /lib, not /usr/lib. If blkid is being installed in /usr/lib in Fedora, someone must have gone out of their way to override e2fsprogs' defaults, which are designed to do the right things by default. (Basically, because I generally don't trust the choices made by distributions' packaging engineers, having been burned more than once. :-) - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: scheduling while atomic, new libata code
On 12/26/06, Randy Dunlap <[EMAIL PROTECTED]> wrote: Can you apply and test the patch here: http://lkml.org/lkml/2006/12/26/62 and let us know if that fixes the BUG, please. I am running with the patch and haven't hit the BUG. But I wasn't hitting it very often without the patch so it may take a while to know if there is a difference. -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
.text.head is not type AX so it will be left out from the linked output. No, it does get added, but the section is not added to any segment, so a) it ends up near the end of the address map instead of being first thing, and b) it won't be loaded at run time. This reminds me that I have put another patch in kernel/head.S creating a new section .text.head. I think I shall have to put a patch there too to make it work with older binutils. Yeah. Current stuff works with 2.15, which is three years old, but it doesn't hurt supporting older toolchains where possible. Segher - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: util-linux: orphan
Once upon a time, Arnd Bergmann <[EMAIL PROTECTED]> said: >I saw that the current Fedora already dynamically links /bin/mount >against /usr/lib/libblkid.so. What do you mean by "current" Fedora? I think the first Fedora version that linked /bin/mount against libblkid.so was FC4, and FC4, FC5, FC6, and rawhide all have libblkid.so in /lib. -- Chris Adams <[EMAIL PROTECTED]> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Feature request: exec self for NOMMU.
On Wednesday 27 December 2006 00:55, David Lang wrote:
> On Tue, 26 Dec 2006, Rob Landley wrote:
>
> > I'm trying to make some nommu-friendly busybox-like tools, which means using
> > vfork() instead of fork(). This means that after I fork I have to exec in
> > the child to unblock the parent, and if I want to exec my current executable
> > I have to find out where it lives so I can feed the path to exec(). This is
> > nontrivial.
> >
> > Worse, it's not always possible. If chroot() has happened since the program
> > started, there may not _be_ a path to my current executable available from
> > this process's current or root directories.
>
> does this even make sense (as a general purpose function)? if the executable
> isn't available in your path it's likly that any config files it needs are
> not
> available either.
busybox needs it in order to spawn, for example, gzip/bzip2 helper
for tar. We know that our own executable has this function.
How to execute _our own executable_? exec("/proc/self/exe")
works only if /proc is mounted. I can imagine that some embedded
people want to be able to not rely on that.
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 "i386: Relocatable kernel support" causes instant reboot
On Tue, Dec 26, 2006 at 01:43:31PM +0100, Segher Boessenkool wrote: > >Thanks Jean. Your compressed/head.o looks fine. > > No it doesn't -- the .text.head section doesn't have > the ALLOC attribute set. The section then ends up not > being assigned to an output segment (during the linking > of vmlinux) and all hell breaks loose. The linker gives > you a warning about this btw. > Thanks Segher. You are right. I did not notice that. Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS 34 44 00 AX 0 0 4 [ 2] .rel.text REL 0005c8 40 08 8 1 4 [ 3] .data PROGBITS 78 00 00 WA 0 0 4 [ 4] .bss NOBITS 78 001000 00 WA 0 0 4 [ 5] .text.headPROGBITS 78 6e 00 0 0 1 .text.head is not type AX so it will be left out from the linked output. This reminds me that I have put another patch in kernel/head.S creating a new section .text.head. I think I shall have to put a patch there too to make it work with older binutils. Thanks Vivek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: util-linux: orphan
On Wednesday 27 December 2006 04:08, H. Peter Anvin wrote: > > > I'd suggest that you make sure that mount always gets statically linked > > against libblkid to avoid these problems. > > > > That's a pretty silly statement. The real issue is that any library > needed by binaries in /bin or /sbin should live in /lib, not /usr/lib. Right, this is obviously true in general. I don't understand enough about selinux (who does?) to be sure what went wrong there on top of this, but my impression was that I could have solved the problem if I had been able to remount the root partition, or mount the selinux file system, which was made impossible by the fact that I had no permission to access one of the libraries for the mount binary. The location of the library file was not the problem I had, as that system doesn't have a separate /usr partition. Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: System / libata IDE controller woes (long)
Hello, Erik Ohrnberger wrote: > Earlier this year, when I started putting it together, I gathered my > hardware. A decent 2 GHz Athlon system with 512 MB RAM, DVD drive, a 40 GB > system drive, and a 500 Watt power supply. Then I started adding hard > disks. To date, I've got 5 80 GB PATA, 2 200 GB PATA, and 1 60 GB PATA. That's 9 hard drives. How did you hook up your power supply? My dual-rail 450w PS has a lot of problem driving 9 drives no matter how I hook it up while my 350w power supply can happily handle the load. I suspect it's because how the separate 12v rails are configured in the PS. It's nothing concrete but I wanna rule PS issue first. If you've got an extra power supply (buy cheap 350w one if you don't have one), hook half of the drives to it and see what happens. Using PS without motherboard is easy. Just ask google. Happy holidays. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.16.29 1/1] memory: enhance Linux swap subsystem
The job listed in Documentation/vm_pps.txt of my patch is too heavy to me, so I'm appreciate that Linux kernel group can arrange a schedule to help me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.16.29 1/1] memory: enhance Linux swap subsystem
To multiple address space, multiple memory inode architecture, we can introduce a new core object -- section which has several features 1) Section is used as the atomic unit to contain the pages of a VMA residing in the memory inode of the section. 2) When page migration occurs among different memory inodes, new secion should be set up to trace the pages. 3) Section can be scanned by the SwapDaemon of its memory inode directely. 4) All sections of a VMA are excluded with each other not overlayed. 5) VMA is made up of sections totally, but its section objects scatter on memory inodes. So to the architecture, we can deploy swap subsystem on an architecture-independent layer by section and scan pages batchly. The idea issued by me is whether swap subsystem should be deployed on layer 2 or layer 3 which is described in Documentation/vm_pps.txt of my patch. To multiple memory inode architecture, the special memory model should be encapsulated on layer 3 (architecture-dependent), I think. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: util-linux: orphan
Arnd Bergmann wrote: On Monday 18 December 2006 08:17, Karel Zak wrote: - remove FS/device detection code (libblkid from e2fsprogs or libvolumeid is replacement) I saw that the current Fedora already dynamically links /bin/mount against /usr/lib/libblkid.so. This obviously does not work if /usr is a separate partition that needs to be mounted with /bin/mount. I also had problems with selinux claiming I had no right to access libblkid, which meant that the root fs could not be remounted r/w. I'd suggest that you make sure that mount always gets statically linked against libblkid to avoid these problems. That's a pretty silly statement. The real issue is that any library needed by binaries in /bin or /sbin should live in /lib, not /usr/lib. -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: util-linux: orphan
On Monday 18 December 2006 08:17, Karel Zak wrote: > - remove FS/device detection code > (libblkid from e2fsprogs or libvolumeid is replacement) I saw that the current Fedora already dynamically links /bin/mount against /usr/lib/libblkid.so. This obviously does not work if /usr is a separate partition that needs to be mounted with /bin/mount. I also had problems with selinux claiming I had no right to access libblkid, which meant that the root fs could not be remounted r/w. I'd suggest that you make sure that mount always gets statically linked against libblkid to avoid these problems. Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Buglet in vmscan.c
The attached patch fixes a rather obvious buglet. Noticed while instrumenting the VM using /proc/vmstat. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- .orig/mm/vmscan.c 2006-12-26 21:34:30.0 -0500 +++ 2.6.20-rc2-wb-fix/mm/vmscan.c 2006-12-26 21:32:17.0 -0500 @@ -692,7 +692,7 @@ __count_vm_events(KSWAPD_STEAL, nr_freed); } else __count_zone_vm_events(PGSCAN_DIRECT, zone, nr_scan); - __count_vm_events(PGACTIVATE, nr_freed); + __count_zone_vm_events(PGSTEAL, zone, nr_freed); if (nr_taken == 0) goto done;
RE: linux tcp stack behavior change
> However, I know that plain -sF worked with previous kernels. Using > nmap-4.00 on 2.6.18.5 yields the same result, so I do not think it is > caused by a change in nmap code. Could someone with 2.6.13-2.6.17 verify > that the TCP stack returned a RST? Works for me on 2.6.18.3: [EMAIL PROTECTED] bb]# tcpdump -ni lo & [EMAIL PROTECTED] bb]# nmap localhost -n -sX -p 22 Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2006-12-26 21:26 EST 21:26:09.217187 IP 127.0.0.1.46872 > 127.0.0.1.22: FP 4139391634:4139391634(0) win 1024 urg 0 21:26:09.217355 IP 127.0.0.1.22 > 127.0.0.1.46872: R 0:0(0) ack 4139391635 win 0 Interesting ports on 127.0.0.1: PORT STATE SERVICE 22/tcp closed ssh [EMAIL PROTECTED] bb]# uname -a Linux DS-12 2.6.18-ARCH #1 SMP PREEMPT Sun Nov 19 09:14:35 CET 2006 i686 Intel(R) Pentium(R) 4 Mobile CPU 1.80GHz GenuineIntel GNU/Linux [EMAIL PROTECTED] bb]# pacman -Q kernel26 kernel26 2.6.18.3-1 - Björn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] mm: Set HASHDIST_DEFAULT to 1 for x86_64 NUMA
Enable system hashtable memory to be distributed among nodes on x86_64 NUMA Forcing the kernel to use node interleaved vmalloc instead of bootmem for the system hashtable memory (alloc_large_system_hash) reduces the memory imbalance on node 0 by around 40MB on a 8 node x86_64 NUMA box: Before the following patch, on bootup of a 8 node box: Node 0 MemTotal: 3407488 kB Node 0 MemFree: 3206296 kB Node 0 MemUsed:201192 kB Node 0 Active: 7012 kB Node 0 Inactive: 512 kB Node 0 Dirty: 0 kB Node 0 Writeback: 0 kB Node 0 FilePages:1912 kB Node 0 Mapped:420 kB Node 0 AnonPages:5612 kB Node 0 PageTables:468 kB Node 0 NFS_Unstable:0 kB Node 0 Bounce: 0 kB Node 0 Slab: 5408 kB Node 0 SReclaimable: 644 kB Node 0 SUnreclaim: 4764 kB After the patch (or using hashdist=1 on the kernel command line): Node 0 MemTotal: 3407488 kB Node 0 MemFree: 3247608 kB Node 0 MemUsed:159880 kB Node 0 Active: 3012 kB Node 0 Inactive: 616 kB Node 0 Dirty: 0 kB Node 0 Writeback: 0 kB Node 0 FilePages:2424 kB Node 0 Mapped:380 kB Node 0 AnonPages:1200 kB Node 0 PageTables:396 kB Node 0 NFS_Unstable:0 kB Node 0 Bounce: 0 kB Node 0 Slab: 6304 kB Node 0 SReclaimable: 1596 kB Node 0 SUnreclaim: 4708 kB I guess it is a good idea to keep HASHDIST_DEFAULT "on" for x86_64 NUMA since x86_64 has no dearth of vmalloc space? Or maybe enable hash distribution for all 64bit NUMA arches? The following patch does it only for x86_64. Signed-off-by: Pravin B. Shelar <[EMAIL PROTECTED]> Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTECTED]> Signed-off-by: Shai Fultheim <[EMAIL PROTECTED]> Index: linux-2.6.20-rc1/include/linux/bootmem.h === --- linux-2.6.20-rc1.orig/include/linux/bootmem.h 2006-12-21 14:34:36.321610875 -0800 +++ linux-2.6.20-rc1/include/linux/bootmem.h2006-12-26 15:55:04.501064560 -0800 @@ -122,9 +122,9 @@ extern void *alloc_large_system_hash(con #define HASH_EARLY 0x0001 /* Allocating during early boot? */ /* Only NUMA needs hash distribution. - * IA64 is known to have sufficient vmalloc space. + * IA64 and x86_64 have sufficient vmalloc space. */ -#if defined(CONFIG_NUMA) && defined(CONFIG_IA64) +#if defined(CONFIG_NUMA) && (defined(CONFIG_IA64) || defined(CONFIG_X86_64)) #define HASHDIST_DEFAULT 1 #else #define HASHDIST_DEFAULT 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: Oops in 2.6.19.1
On Sat, 2006-12-23 at 15:40 +, Alistair John Strachan wrote: > On Wednesday 20 December 2006 14:21, Alistair John Strachan wrote: > > Hi, > > > > Any ideas? > > Pretty much like clockwork, it happened again. I think it's time to take this > seriously as a software bug, and not some hardware problem. I've ran kernels > since 2.6.0 on this machine without such crashes, and now two of the same in > 2.6.19.1? Pretty unlikely! > > BUG: unable to handle kernel NULL pointer dereference at virtual address > 0009 > printing eip: > c0156f60 > *pde = > Oops: 0002 [#1] > Modules linked in: ipt_recent ipt_REJECT xt_tcpudp ipt_MASQUERADE iptable_nat > xt_sta > te iptable_filter ip_tables x_tables prism54 yenta_socket rsrc_nonstatic > pcmcia_core snd_via82xx snd_ac97_codec snd_ac97_bus > snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd soundcore > usblp ehci_hcd eth1394 uhci_hcd usbcore ohci1394 i > eee1394 via_agp agpgart vt1211 hwmon_vid hwmon ip_nat_ftp ip_nat > ip_conntrack_ftp ip_conntrack > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010246 (2.6.19.1 #1) > EIP is at pipe_poll+0xa0/0xb0 > eax: 0008 ebx: ecx: 0008 edx: > esi: ee1b9e9c edi: f4d80a00 ebp: ee1b9c1c esp: ee1b9c0c > ds: 007b es: 007b ss: 0068 > Process java (pid: 5374, ti=ee1b8000 task=f7117560 task.ti=ee1b8000) > Stack: ee1b9e9c f6c17160 ee1b9fa4 c015d7f3 ee1b9c54 ee1b9fac >082dff90 0010 082dffa0 ee1b9e94 ee1b9e94 0002 ee1b9eac > ee1b9e94 c015e580 0002 f6c17160 > Call Trace: > [] do_sys_poll+0x253/0x480 > [] sys_poll+0x33/0x50 > [] syscall_call+0x7/0xb > [] 0xb7f26402 > === > Code: 58 01 00 00 0f 4f c2 09 c1 89 c8 83 c8 08 85 db 0f 44 c8 8b 5d f4 89 c8 > 8b 75 > f8 8b 7d fc 89 ec 5d c3 89 ca 8b 46 6c 83 ca 10 3b <87> 68 01 00 00 0f 45 ca > eb b6 8d b6 00 00 00 00 55 b8 01 00 00 Above codes look weird. Could you disassemble kernel image and post the part around address 0xc0156f60? "87 68 01 00 00" is instruction xchg, but if I disassemble from the begining, I couldn't see instruct xchg. > EIP: [] pipe_poll+0xa0/0xb0 SS:ESP 0068:ee1b9c0c > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 tcp stack behavior change
Hello list, I have been noticing that running nmap -sF on oneself does not generate a reply from the TCP stack on 2.6.18(.5). In other words: # tcpdump -ni lo & [1] 32376 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes # nmap localhost -n -sX -p 22 Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2006-12-27 02:59 CET 02:59:54.199763 IP 127.0.0.1.44431 > 127.0.0.1.22: FP 2987942575:2987942575(0) win 3072 urg 0 and it just sits there. By chance, I found that passing FIN,ACK gives the desired effect # nmap localhost -n -sX -p 22 --scanflags FIN,ACK Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2006-12-27 03:01 CET 03:01:28.847871 IP 127.0.0.1.34140 > 127.0.0.1.22: F 935914709:935914709(0) ack 1975786655 win 4096 03:01:28.847943 IP 127.0.0.1.22 > 127.0.0.1.34140: R 1975786655:1975786655(0) win 0 Interesting ports on 127.0.0.1: PORT STATE SERVICE 22/tcp closed ssh Nmap finished: 1 IP address (1 host up) scanned in 0.071 seconds However, I know that plain -sF worked with previous kernels. Using nmap-4.00 on 2.6.18.5 yields the same result, so I do not think it is caused by a change in nmap code. Could someone with 2.6.13-2.6.17 verify that the TCP stack returned a RST? Or perhaps someone else actually knows there was a change in the linux kernel to cause the now-observed behavior. Thanks, Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: scheduling while atomic, new libata code
On Tue, 26 Dec 2006 20:47:31 -0500 Jon Smirl wrote: > Got this is my logs, no idea what triggered it. Using 2.6.20-rc2 > I have one PATA and one SATA HD on ICH5 and two PATA CDROM > All using the new libata drivers > > BUG: scheduling while atomic: hald-addon-stor/0x2000/5170 > [schedule+1529/2816] __sched_text_start+0x5f9/0xb00 > [blk_done_softirq+88/112] blk_done_softirq+0x58/0x70 > [__do_softirq+114/224] __do_softirq+0x72/0xe0 > [do_IRQ+69/128] do_IRQ+0x45/0x80 > [reschedule_interrupt+40/48] reschedule_interrupt+0x28/0x30 > [__cond_resched+22/64] __cond_resched+0x16/0x40 > [cond_resched+35/48] cond_resched+0x23/0x30 > [__reacquire_kernel_lock+28/60] __reacquire_kernel_lock+0x1c/0x3c > [schedule+1577/2816] __sched_text_start+0x629/0xb00 > [scsi_done+0/32] scsi_done+0x0/0x20 > [ata_scsi_translate+154/320] ata_scsi_translate+0x9a/0x140 > [scsi_request_fn+542/800] scsi_request_fn+0x21e/0x320 > [__cond_resched+22/64] __cond_resched+0x16/0x40 > [cond_resched+35/48] cond_resched+0x23/0x30 > [wait_for_completion+15/192] wait_for_completion+0xf/0xc0 > [blk_execute_rq_nowait+91/160] blk_execute_rq_nowait+0x5b/0xa0 > [cfq_set_request+0/896] cfq_set_request+0x0/0x380 > [cfq_set_request+508/896] cfq_set_request+0x1fc/0x380 > [blk_execute_rq+124/224] blk_execute_rq+0x7c/0xe0 > [blk_end_sync_rq+0/48] blk_end_sync_rq+0x0/0x30 > [cfq_set_request+0/896] cfq_set_request+0x0/0x380 > [elv_set_request+28/64] elv_set_request+0x1c/0x40 > [get_request+289/624] get_request+0x121/0x270 > [get_request_wait+39/288] get_request_wait+0x27/0x120 > [scsi_execute+217/256] scsi_execute+0xd9/0x100 > [pg0+944853162/1069057024] sr_do_ioctl+0x7a/0x240 [sr_mod] > [__wake_up+56/80] __wake_up+0x38/0x50 > [pg0+944854258/1069057024] sr_drive_status+0x62/0x80 [sr_mod] > [pg0+945482260/1069057024] cdrom_ioctl+0x514/0xde0 [cdrom] > [__mark_inode_dirty+52/400] __mark_inode_dirty+0x34/0x190 > [touch_atime+158/272] touch_atime+0x9e/0x110 > [pg0+944852851/1069057024] sr_block_ioctl+0x53/0xb0 [sr_mod] > [blkdev_driver_ioctl+109/128] blkdev_driver_ioctl+0x6d/0x80 > [blkdev_ioctl+751/2000] blkdev_ioctl+0x2ef/0x7d0 > [kobject_get+15/32] kobject_get+0xf/0x20 > [get_disk+57/112] get_disk+0x39/0x70 > [exact_lock+7/16] exact_lock+0x7/0x10 > [kobject_get+15/32] kobject_get+0xf/0x20 > [pg0+944849884/1069057024] sr_block_open+0x5c/0xa0 [sr_mod] > [blkdev_open+0/112] blkdev_open+0x0/0x70 > [do_open+439/656] do_open+0x1b7/0x290 > [blkdev_open+0/112] blkdev_open+0x0/0x70 > [blkdev_open+48/112] blkdev_open+0x30/0x70 > [__dentry_open+353/448] __dentry_open+0x161/0x1c0 > [nameidata_to_filp+53/64] nameidata_to_filp+0x35/0x40 > [do_filp_open+75/96] do_filp_open+0x4b/0x60 > [block_ioctl+24/32] block_ioctl+0x18/0x20 > [block_ioctl+0/32] block_ioctl+0x0/0x20 > [do_ioctl+43/144] do_ioctl+0x2b/0x90 > [vfs_ioctl+92/672] vfs_ioctl+0x5c/0x2a0 > [sys_ioctl+114/144] sys_ioctl+0x72/0x90 > [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85 > === Can you apply and test the patch here: http://lkml.org/lkml/2006/12/26/62 and let us know if that fixes the BUG, please. --- ~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/
BUG: scheduling while atomic, new libata code
Got this is my logs, no idea what triggered it. Using 2.6.20-rc2 I have one PATA and one SATA HD on ICH5 and two PATA CDROM All using the new libata drivers BUG: scheduling while atomic: hald-addon-stor/0x2000/5170 [schedule+1529/2816] __sched_text_start+0x5f9/0xb00 [blk_done_softirq+88/112] blk_done_softirq+0x58/0x70 [__do_softirq+114/224] __do_softirq+0x72/0xe0 [do_IRQ+69/128] do_IRQ+0x45/0x80 [reschedule_interrupt+40/48] reschedule_interrupt+0x28/0x30 [__cond_resched+22/64] __cond_resched+0x16/0x40 [cond_resched+35/48] cond_resched+0x23/0x30 [__reacquire_kernel_lock+28/60] __reacquire_kernel_lock+0x1c/0x3c [schedule+1577/2816] __sched_text_start+0x629/0xb00 [scsi_done+0/32] scsi_done+0x0/0x20 [ata_scsi_translate+154/320] ata_scsi_translate+0x9a/0x140 [scsi_request_fn+542/800] scsi_request_fn+0x21e/0x320 [__cond_resched+22/64] __cond_resched+0x16/0x40 [cond_resched+35/48] cond_resched+0x23/0x30 [wait_for_completion+15/192] wait_for_completion+0xf/0xc0 [blk_execute_rq_nowait+91/160] blk_execute_rq_nowait+0x5b/0xa0 [cfq_set_request+0/896] cfq_set_request+0x0/0x380 [cfq_set_request+508/896] cfq_set_request+0x1fc/0x380 [blk_execute_rq+124/224] blk_execute_rq+0x7c/0xe0 [blk_end_sync_rq+0/48] blk_end_sync_rq+0x0/0x30 [cfq_set_request+0/896] cfq_set_request+0x0/0x380 [elv_set_request+28/64] elv_set_request+0x1c/0x40 [get_request+289/624] get_request+0x121/0x270 [get_request_wait+39/288] get_request_wait+0x27/0x120 [scsi_execute+217/256] scsi_execute+0xd9/0x100 [pg0+944853162/1069057024] sr_do_ioctl+0x7a/0x240 [sr_mod] [__wake_up+56/80] __wake_up+0x38/0x50 [pg0+944854258/1069057024] sr_drive_status+0x62/0x80 [sr_mod] [pg0+945482260/1069057024] cdrom_ioctl+0x514/0xde0 [cdrom] [__mark_inode_dirty+52/400] __mark_inode_dirty+0x34/0x190 [touch_atime+158/272] touch_atime+0x9e/0x110 [pg0+944852851/1069057024] sr_block_ioctl+0x53/0xb0 [sr_mod] [blkdev_driver_ioctl+109/128] blkdev_driver_ioctl+0x6d/0x80 [blkdev_ioctl+751/2000] blkdev_ioctl+0x2ef/0x7d0 [kobject_get+15/32] kobject_get+0xf/0x20 [get_disk+57/112] get_disk+0x39/0x70 [exact_lock+7/16] exact_lock+0x7/0x10 [kobject_get+15/32] kobject_get+0xf/0x20 [pg0+944849884/1069057024] sr_block_open+0x5c/0xa0 [sr_mod] [blkdev_open+0/112] blkdev_open+0x0/0x70 [do_open+439/656] do_open+0x1b7/0x290 [blkdev_open+0/112] blkdev_open+0x0/0x70 [blkdev_open+48/112] blkdev_open+0x30/0x70 [__dentry_open+353/448] __dentry_open+0x161/0x1c0 [nameidata_to_filp+53/64] nameidata_to_filp+0x35/0x40 [do_filp_open+75/96] do_filp_open+0x4b/0x60 [block_ioctl+24/32] block_ioctl+0x18/0x20 [block_ioctl+0/32] block_ioctl+0x0/0x20 [do_ioctl+43/144] do_ioctl+0x2b/0x90 [vfs_ioctl+92/672] vfs_ioctl+0x5c/0x2a0 [sys_ioctl+114/144] sys_ioctl+0x72/0x90 [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85 === -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc2
On Wed, Dec 27, 2006 at 12:42:53AM +0100, Ingo Molnar wrote:
> * Florin Iucha <[EMAIL PROTECTED]> wrote:
> > I saw your subsequent message and will apply the patch, retest and
> > report.
>
> yeah. Just to make sure i've attached the latest and greatest version of
> the patch - please make sure you have this one applied.
The good news is, with this patch there is no oops.
The bad news is, the USB keyboard is still not functioning, but the
mice plugged in the keyboard hub are working.
One down, one more to go...
florin
> -->
> Subject: [patch] sched: fix cond_resched_softirq() offset
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> remove the __resched_legal() check: it is conceptually broken.
> The biggest problem it had is that it can mask buggy cond_resched()
> calls. A cond_resched() call is only legal if we are not in an
> atomic context, with two narrow exceptions:
>
> - if the system is booting
> - a reacquire_kernel_lock() down() done while PREEMPT_ACTIVE is set
>
> But __resched_legal() hid this and just silently returned whenever
> these primitives were called from invalid contexts. (Same goes for
> cond_resched_locked() and cond_resched_softirq()).
>
> furthermore, the __legal_resched(0) call was buggy in that it caused
> unnecessarily long softirq latencies via cond_resched_softirq(). (which
> is only called from softirq-off sections, hence the code did nothing.)
>
> the fix is to resurrect the efficiency of the might_sleep checks and to
> only allow the narrow exceptions.
>
> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
> ---
> kernel/sched.c | 18 --
> 1 file changed, 4 insertions(+), 14 deletions(-)
>
> Index: linux/kernel/sched.c
> ===
> --- linux.orig/kernel/sched.c
> +++ linux/kernel/sched.c
> @@ -4617,17 +4617,6 @@ asmlinkage long sys_sched_yield(void)
> return 0;
> }
>
> -static inline int __resched_legal(int expected_preempt_count)
> -{
> -#ifdef CONFIG_PREEMPT
> - if (unlikely(preempt_count() != expected_preempt_count))
> - return 0;
> -#endif
> - if (unlikely(system_state != SYSTEM_RUNNING))
> - return 0;
> - return 1;
> -}
> -
> static void __cond_resched(void)
> {
> #ifdef CONFIG_DEBUG_SPINLOCK_SLEEP
> @@ -4647,7 +4636,8 @@ static void __cond_resched(void)
>
> int __sched cond_resched(void)
> {
> - if (need_resched() && __resched_legal(0)) {
> + if (need_resched() && !(preempt_count() & PREEMPT_ACTIVE) &&
> + system_state == SYSTEM_RUNNING) {
> __cond_resched();
> return 1;
> }
> @@ -4673,7 +4663,7 @@ int cond_resched_lock(spinlock_t *lock)
> ret = 1;
> spin_lock(lock);
> }
> - if (need_resched() && __resched_legal(1)) {
> + if (need_resched() && system_state == SYSTEM_RUNNING) {
> spin_release(>dep_map, 1, _THIS_IP_);
> _raw_spin_unlock(lock);
> preempt_enable_no_resched();
> @@ -4689,7 +4679,7 @@ int __sched cond_resched_softirq(void)
> {
> BUG_ON(!in_softirq());
>
> - if (need_resched() && __resched_legal(0)) {
> + if (need_resched() && system_state == SYSTEM_RUNNING) {
> raw_local_irq_disable();
> _local_bh_enable();
> raw_local_irq_enable();
>
--
Bruce Schneier expects the Spanish Inquisition.
http://geekz.co.uk/schneierfacts/fact/163
signature.asc
Description: Digital signature
Re: Binary Drivers
On 12/26/06, David Schwartz <[EMAIL PROTECTED]> wrote: You buy a phone for $200. The manufacturer only represents that it works with CarrierCo. ... You have the right to do what you like with the phone, of course. It's a great doorstop and a reasonable paper weight. The manufacturer didn't promise the phone's configuration wouldn't become obsolete or that you would be able to change the configuration. Lack of documentation is not an imposition on your rights, and you had no specific promise of documentation from the seller. I have to say, it honestly astonishes me that would people would make arguments like these. Are we so used to these kinds of one-sided arrangements that we've lost our common sense? --- If the manufacturer knew about the forthcoming configuration change, you might have a fraud claim. Otherwise it's just bad luck, which happens sometimes. I'm not familiar with any situations where the manufacturer locks the phone. Locks are usually applied by the carrier in return for a subsidy. Once any contract restrictions are over, you would have the right to attempt to unlock the phone or to find someone who could do so. For most phones in the market today, I understand that to be a relatively easy thing to find. In the US, the Copyright office recently ruled that there should be an exception to the DMCA so that circumventing the lock would not be a DMCA violation. I don't know why you think of this as a particularly unfair situation. There's at least a chance that the phone might be reconfigurable. The phone might as easily have been physically unable to work with the new configuration. If you bought, for instance, an Iridium phone (which worked only on the Iridium satellite network and had no other useful function), it became a paperweight when the network ceased operation. You could sell the device on ebay or attempt to salvage parts of it for other purposes, but otherwise you're just out of luck. scott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] romsignature/checksum cleanup
On Mon, 2006-12-25 at 01:53 +0100, Rene Herman wrote: > Rene Herman wrote: > > > Use adding __init to romsignature() (it's only called from probe_roms() > > which is itself __init) as an excuse to submit a pedantic cleanup. > > Hmm, by the way, if romsignature() needs this probe_kernel_address() > thing, why doesn't romchecksum()? I assume it's all in the same page, but CC'ing Zach is easier than reading the code 8) Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.19-rt14 slowdown compared to 2.6.19
Ingo Molnar wrote: > > cool - thanks for the feedback! Running the 64-bit kernel, right? > Yes, 64-bit kernel was used. > > while some slowdown is to be expected, did in each case idle time > increase significantly? Volanomark and Re-Aim7 ran close to 0% idle time for 2.6.19 kernel. Idle time increase significantly for Volanomark (to 60% idle) and Re-Aim7 (to 20% idle) with the rt kernel. For netperf, the system was 60% idle for both 2.6.19 and rt kernel and changes in idle time was not significant. > If yes then this is the effect of lock > contention. Lock contention effects are 'magnified' by PREEMPT_RT. For > example if you run 128 threads workload that all use the same lock > then > the -rt kernel can act as if it were a 128-way box (!). This way by > running -rt you'll see scalability problems alot sooner than on real > hardware. In other words: PREEMPT_RT in essence simulates the > scalability behavior of up to an infinite amount of CPUs. (with the > exception of cachemiss emulation ;) [the effect is not this precise, > but > that's the rough trend] Turning off PREEMPT_RT for 2.6.20-rc2-rt0 kernel restored most the performance of Volanaomark and Re-Aim7. Idle time is close to 0%. So the benchmarks with large number of threads are affected more by PREEMPT_RT. For netperf TCP streaming, the performance improved from 40% down to 20% down from 2.6.20-rc2 kernel. There is only a server and a client process for netperf. The underlying reason for the change in performance is probably different. > > If you'd like to profile this yourself then the lowest-cost way of > profiling lock contention on -rt is to use the yum kernel and run the > attached trace-it-lock-prof.c code on the box while your workload is > in 'steady state' (and is showing those extended idle times): > > ./trace-it-lock-prof > trace.txt > Thanks for the pointer. Will let you know of any relevant traces. Thanks. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] romsignature/checksum cleanup
Rusty Russell wrote: On Mon, 2006-12-25 at 01:53 +0100, Rene Herman wrote: Hmm, by the way, if romsignature() needs this probe_kernel_address() thing, why doesn't romchecksum()? I assume it's all in the same page, but CC'ing Zach is easier than reading the code 8) If we're talking hardware pages here; the romchecksum() might be done over an area upto 0xff x 512 = 130560 bytes (there's also an acces to the length byte at rom[2] in probe_roms(). I assume that one's okay if romsignature() ensured that the first page is in). 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: Feature request: exec self for NOMMU.
On Tuesday 26 December 2006 6:55 pm, David Lang wrote: > > Worse, it's not always possible. If chroot() has happened since the program > > started, there may not _be_ a path to my current executable available from > > this process's current or root directories. > > does this even make sense (as a general purpose function)? if the executable > isn't available in your path it's likly that any config files it needs are > not available either. For a statically linked busybox it makes sense, but you're right that a dynamically linked one is going to suck however you do it... I guess what I really want to do is promote a vfork() to a real fork() after the fact. Which sounds painful. For the daemonize() case I want to unblock the parent and have it exit. Too bad I can't call clone() with some kind of CLONE_VFORK_BACKWARDS so it blocks the child until the parent exits. (Hmmm... CLONE_STOPPED doesn't help, just moves the race...) For the "new process runs code out of this executable" case what I really want is an actual fork, hideously expensive as that is on nommu systems. (There are things I can do to minimize that.) Maybe I can call clone() directly on a nommu system to get it to fork, even when the C library hasn't got it? Hmmm... > for something like busybox/toolbox where you have different functions based > on the name used to execute the program, which name would you use? The one from argv[0]. (Notice how exec has a "path to executable" and then an argv array? Nobody said that the path to executable and argv[0] had to point to the same string...) Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Feature request: exec self for NOMMU.
On Tue, 26 Dec 2006, Rob Landley wrote: I'm trying to make some nommu-friendly busybox-like tools, which means using vfork() instead of fork(). This means that after I fork I have to exec in the child to unblock the parent, and if I want to exec my current executable I have to find out where it lives so I can feed the path to exec(). This is nontrivial. Worse, it's not always possible. If chroot() has happened since the program started, there may not _be_ a path to my current executable available from this process's current or root directories. does this even make sense (as a general purpose function)? if the executable isn't available in your path it's likly that any config files it needs are not available either. What would be really nice is if I could feed a NULL path to exec on NOMMU systems, and have that mean "re-exec the current executable". I can't think of a way to do this without kernel support. Any opinions on whether this is worthwhile? for something like busybox/toolbox where you have different functions based on the name used to execute the program, which name would you use? David Lang A nommu-friendly daemonize() is another use for this, by the way... Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] USB power usage
> > > Couple of watts is not that bad, considering usb still eats 4W more > > > than it should. > > > > The USB autosuspend mechanism has been present for a while in -mm and is > > included in 2.6.20-rc (although you have to turn on CONFIG_USB_SUSPEND, > > which is off by default -- it would be nice to change that). Call me paranoid, but I'd like to leave it this way for for a while yet to shake out bugs. There are some complicated interactions here, some of which are hardware-specific, and we've only just started to really shake out the associated problems. (But yes, eventually we do want to see that option go away, and this behavior be standard with PM enabled.) > > Has anybody > > tried doing some real-world measurements to see if it actually makes a > > significant improvement in power usage? > > I did measurements while in -mm, and yes it helped. And yes, > it works in 2.6.20-rc2, too: > > ... > > As you can see, it saves ~3.5W, which is huge deal on machine that > eats 11W total. Hey, that's great to know. Thanks for sharing the figures! And special thanks to Alan, for reworking (and re-reworking) relevant parts of usbcore so that these power savings can (mostly) be automated. ISTR the first patches supporting USB suspend/resume/wakeup landed in about the 2.6.10 kernel, and things look a LOT better than back then. - Dave > (X60 owners, get 2.6.20, and _disable that bluetooth_ while not in use). > Pavel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.19.1-rt15: BUG in __tasklet_action at kernel/softirq.c:568
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-12-20 at 20:50 +0100, Ingo Molnar wrote:
> > * Robert Crocombe <[EMAIL PROTECTED]> wrote:
> >
> > > On 12/19/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > > >yeah. This is something that triggers very rarely on certain boxes. Not
> > > >fixed yet, and it's been around for some time.
> > >
> > > Is there anything you would like me to do to help diagnose this?
> >
> > to figure out what the bug is :-/ Below is the tasklet redesign patch -
> > the bug must be in there somewhere.
>
> > +static inline int tasklet_tryunlock(struct tasklet_struct *t)
> > +{
> > + return cmpxchg(>state, TASKLET_STATEF_RUN, 0) == TASKLET_STATEF_RUN;
> > +}
> > +
>
> This probably isn't it, but is cmpxchg available on all archs now?
yeah, it's probably not related, i saw these failures on plain i686 too,
which definitely has cmpxchg support. The failures i saw happened on a
hyperthreading CPU, so i guess it must be some sort of narrow race.
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] Consolidate default sched_clock()
* Alexey Dobriyan <[EMAIL PROTECTED]> wrote: > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> looks good to me. Acked-by: Ingo Molnar <[EMAIL PROTECTED]> 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: Binary Drivers
David Schwartz <[EMAIL PROTECTED]> wrote: [..] . > The point is that any rights the manufacturer may have had to the car should > have been sold along with the car, otherwise it's not a normal free and > clear sale. A normal free and clear sale includes all rights to the item > sold, except those specific laws allows the manufacturer to retain. This is complete nonsense. The car manufacturer can very well agree with you to sell you the right to only drive the car on weekdays, and rent it off on weekends. Nothing forces them to sell "all rights they have on the car". [...] > I simply do not accept the argument that it is lawful for a manufacturer to > sell a physical object in a normal free and clear sale and then refuse to > disclose the knowledge necessary to use it. Ask a lawyer about this, don't impose your wacky legal theories on us. > (And by that I mean necessary to > use it any reasonable way, not just the way the manufacturer intended it to > be used.) Define "reasonable way". The manufacturer could very well define it as "use the XYZ graphics card on Windows XP service pack 2", as it was designed specifically for that environment. Everything else (use on Linux, for example) is then "unreasonable use", and need not be supported at all. > This same issue has been pressed in other areas Examples? > and I think it's time it be > pressed with graphics cards. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Feature request: exec self for NOMMU.
I'm trying to make some nommu-friendly busybox-like tools, which means using vfork() instead of fork(). This means that after I fork I have to exec in the child to unblock the parent, and if I want to exec my current executable I have to find out where it lives so I can feed the path to exec(). This is nontrivial. Worse, it's not always possible. If chroot() has happened since the program started, there may not _be_ a path to my current executable available from this process's current or root directories. What would be really nice is if I could feed a NULL path to exec on NOMMU systems, and have that mean "re-exec the current executable". I can't think of a way to do this without kernel support. Any opinions on whether this is worthwhile? A nommu-friendly daemonize() is another use for this, by the way... Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20-rc2: oops with broken usb cable, fault handler locks up?
Hi! I have cable between sx1 <-> pc, that is of _very_ low quality. Well, today sx1 communication stopped working, and this time it was not sx1's fault. ...wait a moment, what is that? did oops handler lock up for long enough for softlockup to trigger? Pavel PM: Adding info for usb-serial:ttyUSB0 PM: Adding info for No Bus:ttyUSB0 usb 2-1: generic converter now attached to ttyUSB0 PM: Adding info for No Bus:usbdev2.81_ep01 PM: Adding info for No Bus:usbdev2.81_ep82 PM: Adding info for No Bus:usbdev2.81_ep83 usb 2-1: USB disconnect, address 81 PM: Removing info for No Bus:usbdev2.81_ep01 PM: Removing info for No Bus:usbdev2.81_ep82 PM: Removing info for No Bus:usbdev2.81_ep83 PM: Removing info for No Bus:ttyUSB0 generic ttyUSB0: generic converter now disconnected from ttyUSB0 PM: Removing info for usb-serial:ttyUSB0 usbserial_generic 2-1:1.0: device disconnected PM: Removing info for usb:2-1:1.0 PM: Removing info for No Bus:usbdev2.81_ep00 PM: Removing info for usb:2-1 usb 2-1: new full speed USB device using uhci_hcd and address 82 usb 2-1: device descriptor read/64, error -71 PM: Adding info for usb:2-1 PM: Adding info for No Bus:usbdev2.82_ep00 usb 2-1: configuration #1 chosen from 2 choices PM: Adding info for usb:2-1:1.0 usb0: register 'cdc_ether' at usb-:00:1d.0-1, CDC Ethernet Device, 5e:95:58:7c:02:7a PM: Adding info for No Bus:usbdev2.82_ep83 PM: Adding info for usb:2-1:1.1 PM: Adding info for No Bus:usbdev2.82_ep81 PM: Adding info for No Bus:usbdev2.82_ep02 usb 2-1: USB disconnect, address 82 PM: Removing info for No Bus:usbdev2.82_ep83 usb0: unregister 'cdc_ether' usb-:00:1d.0-1, CDC Ethernet Device PM: Removing info for usb:2-1:1.0 PM: Removing info for No Bus:usbdev2.82_ep81 PM: Removing info for No Bus:usbdev2.82_ep02 PM: Removing info for usb:2-1:1.1 PM: Removing info for No Bus:usbdev2.82_ep00 PM: Removing info for usb:2-1 usb 2-1: new full speed USB device using uhci_hcd and address 83 usb 2-1: device descriptor read/64, error -71 usb 2-1: new full speed USB device using uhci_hcd and address 84 usb 2-1: device descriptor read/64, error -71 usb 2-1: new full speed USB device using uhci_hcd and address 85 usb 2-1: device not accepting address 85, error -71 usb 2-1: new full speed USB device using uhci_hcd and address 87 usb 2-1: device not accepting address 87, error -71 usb 2-1: new full speed USB device using uhci_hcd and address 89 usb 2-1: device not accepting address 89, error -71 usb 2-1: new full speed USB device using uhci_hcd and address 91 usb 2-1: device not accepting address 91, error -71 usb 2-1: new full speed USB device using uhci_hcd and address 93 usb 2-1: device descriptor read/64, error -84 usb 2-1: new full speed USB device using uhci_hcd and address 94 usb 2-1: device descriptor read/64, error -71 usb 2-1: new full speed USB device using uhci_hcd and address 95 usb 2-1: device not accepting address 95, error -71 usb 2-1: new full speed USB device using uhci_hcd and address 97 usb 2-1: device not accepting address 97, error -71 usb 2-1: new full speed USB device using uhci_hcd and address 99 usb 2-1: new full speed USB device using uhci_hcd and address 100 usb 2-1: USB disconnect, address 100 BUG: unable to handle kernel NULL pointer dereference at virtual address 0010 printing eip: c060f5e4 *pde = usb 2-1: unable to read config index 0 descriptor/start usb 2-1: chopping to 0 config(s) usb 2-1: string descriptor 0 read error: -19 usb 2-1: string descriptor 0 read error: -19 PM: Adding info for usb:2-1 PM: Adding info for No Bus:usbdev2.100_ep00 usb 2-1: no configuration chosen from 0 choices BUG: soft lockup detected on CPU#1! [] softlockup_tick+0xa9/0xd0 [] update_process_times+0x33/0x80 [] smp_apic_timer_interrupt+0x6b/0x80 [] apic_timer_interrupt+0x28/0x30 [] delay_tsc+0x12/0x20 [] __delay+0x6/0x10 [] do_page_fault+0x35b/0x600 [] do_page_fault+0x0/0x600 [] error_code+0x7c/0x84 [] klist_del+0x14/0x50 [] device_del+0x1b/0x1c0 [] usb_disconnect+0xb1/0x120 [] hub_thread+0x3ca/0xe00 [] __activate_task+0x21/0x40 [] try_to_wake_up+0x3f/0x420 [] autoremove_wake_function+0x0/0x50 [] hub_thread+0x0/0xe00 [] kthread+0xec/0xf0 [] kthread+0x0/0xf0 [] kernel_thread_helper+0x7/0x10 === Oops: [#1] SMP Modules linked in: usbserial CPU:1 EIP:0060:[]Not tainted VLI EFLAGS: 00010292 (2.6.20-rc2 #384) EIP is at klist_del+0x14/0x50 eax: ebx: ecx: 000f edx: esi: 007c edi: f309db70 ebp: f309dc44 esp: c2279ea4 ds: 007b es: 007b ss: 0068 Process khubd (pid: 304, ti=c2278000 task=c21fb030 task.ti=c2278000) Stack: f309db80 007c f309db5c c0328a3b f7e81690 f309db80 007c f309db04 f309dc44 c044ae91 c0732acc c0701f8d f309dc14 0064 f7e818b8 f309db5c f78f84ac f7e99a44 f7e81638 f78f8494 c044d83a c2279fb0 000a c2279f10 Call Trace: [] device_del+0x1b/0x1c0 []
[git patch] Remove NetXen private ioctl
IMO this should not make it out into general release, and most kernel
hackers seemed to agree.
Please pull from 'netxen-ioctl' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git netxen-ioctl
to receive the following updates:
drivers/net/netxen/netxen_nic.h | 11 --
drivers/net/netxen/netxen_nic_ethtool.c |5 +-
drivers/net/netxen/netxen_nic_hw.c | 294 ---
drivers/net/netxen/netxen_nic_init.c| 237 -
drivers/net/netxen/netxen_nic_ioctl.h | 77
drivers/net/netxen/netxen_nic_main.c| 45 -
6 files changed, 1 insertions(+), 668 deletions(-)
delete mode 100644 drivers/net/netxen/netxen_nic_ioctl.h
Stephen Hemminger (1):
netxen: remove private ioctl
The netxen driver includes a private ioctl that provides access
to functionality that is already available in other ways. The PCI
layer has application access hooks (see setpci), and the statistics
are available in ethtool/netstats.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index b5410be..b4c4fc0 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -1027,14 +1027,6 @@ int netxen_nic_hw_read_wx(struct netxen_adapter
*adapter, u64 off, void *data,
int len);
int netxen_nic_hw_write_wx(struct netxen_adapter *adapter, u64 off, void *data,
int len);
-int netxen_nic_hw_read_ioctl(struct netxen_adapter *adapter, u64 off,
-void *data, int len);
-int netxen_nic_hw_write_ioctl(struct netxen_adapter *adapter, u64 off,
- void *data, int len);
-int netxen_nic_pci_mem_write_ioctl(struct netxen_adapter *adapter,
- u64 off, void *data, int size);
-int netxen_nic_pci_mem_read_ioctl(struct netxen_adapter *adapter,
- u64 off, void *data, int size);
void netxen_crb_writelit_adapter(struct netxen_adapter *adapter,
unsigned long off, int data);
@@ -1067,9 +1059,6 @@ void netxen_tso_check(struct netxen_adapter *adapter,
struct cmd_desc_type0 *desc, struct sk_buff *skb);
int netxen_nic_hw_resources(struct netxen_adapter *adapter);
void netxen_nic_clear_stats(struct netxen_adapter *adapter);
-int
-netxen_nic_do_ioctl(struct netxen_adapter *adapter, void *u_data,
- struct netxen_port *port);
int netxen_nic_rx_has_work(struct netxen_adapter *adapter);
int netxen_nic_tx_has_work(struct netxen_adapter *adapter);
void netxen_watchdog_task(struct work_struct *work);
diff --git a/drivers/net/netxen/netxen_nic_ethtool.c
b/drivers/net/netxen/netxen_nic_ethtool.c
index 2ab4885..3404461 100644
--- a/drivers/net/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/netxen/netxen_nic_ethtool.c
@@ -42,7 +42,6 @@
#include "netxen_nic_hw.h"
#include "netxen_nic.h"
#include "netxen_nic_phan_reg.h"
-#include "netxen_nic_ioctl.h"
struct netxen_nic_stats {
char stat_string[ETH_GSTRING_LEN];
@@ -79,8 +78,7 @@ static const struct netxen_nic_stats
netxen_nic_gstrings_stats[] = {
{"tx_bytes", NETXEN_NIC_STAT(stats.txbytes)},
};
-#define NETXEN_NIC_STATS_LEN \
- sizeof(netxen_nic_gstrings_stats) / sizeof(struct netxen_nic_stats)
+#define NETXEN_NIC_STATS_LEN ARRAY_SIZE(netxen_nic_gstrings_stats)
static const char netxen_nic_gstrings_test[][ETH_GSTRING_LEN] = {
"Register_Test_offline", "EEPROM_Test_offline",
@@ -711,7 +709,6 @@ netxen_nic_get_ethtool_stats(struct net_device *dev,
(netxen_nic_gstrings_stats[index].sizeof_stat ==
sizeof(u64)) ? *(u64 *) p : *(u32 *) p;
}
-
}
struct ethtool_ops netxen_nic_ethtool_ops = {
diff --git a/drivers/net/netxen/netxen_nic_hw.c
b/drivers/net/netxen/netxen_nic_hw.c
index 9147b60..5dac50c 100644
--- a/drivers/net/netxen/netxen_nic_hw.c
+++ b/drivers/net/netxen/netxen_nic_hw.c
@@ -997,297 +997,3 @@ void netxen_nic_flash_print(struct netxen_adapter
*adapter)
fw_major, fw_minor);
}
-int netxen_crb_read_val(struct netxen_adapter *adapter, unsigned long off)
-{
- int data;
- netxen_nic_hw_read_wx(adapter, off, , 4);
- return data;
-}
-
-int netxen_nic_hw_write_ioctl(struct netxen_adapter *adapter, u64 off,
- void *data, int len)
-{
- void *addr;
- u64 offset = off;
- u8 *mem_ptr = NULL;
- unsigned long mem_base;
- unsigned long mem_page;
-
- if (ADDR_IN_WINDOW1(off)) {
- addr = NETXEN_CRB_NORMALIZE(adapter, off);
- if (!addr) {
- mem_base = pci_resource_start(adapter->ahw.pdev, 0);
- offset = NETXEN_CRB_NORMAL(off);
-
Re: Binary Drivers
James C Georgas <[EMAIL PROTECTED]> wrote: [...] > Let's summarize the current situation: > 1) Hardware vendors don't have to tell us how to program their products, > as long as they provide some way to use it (i.e. binary blob driver). No. They have absolutely no obligation to tell you anything. If they sell you a card with a binary driver that /only/ works with, say, Minix, it is up to you to buy it or not. > 2) Hardware vendors don't want to tell us how to program their products, > because they think this information is their secret sauce (or maybe > their competitor's secret sauce). And lots of other reasons, including that with detailed specs you might be able to continue using the same card for 3 or 5 years, when they'd love to sell you a replacement next year... Creating, vetting and maintaining specs is /hard/ work, and costs money. If it won't bring a measurable increase in income, why do it? > 3) Hardware vendors don't tell us how to program their products, because > they know about (1) and they believe (2). The law says (1), and they know (2) for a fact. > 4) We need products with datasheets because of our development model. Yep. > 5) We want products with capabilities that these vendors advertise. Yep. > 6) Products that satisfy both (4) and (5) are often scarce or > non-existent. Just too bad. > So far, the suggestions I've seen to resolve the above conflict fall > into three categories: > a) Force vendors to provide datasheets. How? > b) Entice vendors to provide datasheets. How? > c) Reverse engineer the hardware and write our own datasheets. Not always legal... > Solution (a) involves denial of point (1), mostly through the use of > analogy and allegory. These are big companies, who deal in hard realities and cold cash. Poetry won't get you anywhere. > Alternatively, one can try to change the law > through government channels. Won't happen before open source is so prevalent that the point has long become moot. > Solution (b) requires market pressure, Will happen once open source has a large enough slice of a lucrative pie. I.e., it is happening today with "server class" machines. >charity, A company is bound /by law/ to make as much profit as possible. Whoever wants to go this route might spend some time as a neighbor to the Enron et al folks. > or visionary management. This cuts both ways... visionary management made small companies big, and huge companies dissappear from the face of the earth. > We can't exert enough market pressure currently to make much difference. OK. > Charity sometimes gives us datasheets for old hardware. OK. > Visionary > management is the future. Don't they tell that all aspiring MBAs... > Solution (c) is what we do now, with varying degrees of success. A good > example is the R300 support in the radeon DRM module. And others. And this is not the only avenue persued, not by far. Some developers are chummy with the engineers behind the devices they support, and get some help that way. There are people who convinced their companies to let them work on Linux drivers on their own time (with access to the people in the know and datasheets, one would presume), others have gone so far as to be able to work part-time on Linux drivers. Some companies have hired developers under NDA to develop drivers, others have given out datasheets (and access to sample hardware) under NDA (or just "don't give this out too freely") to interested developers. Then there are others (IBM comes to mind) where the company itself is officially developing drivers for their hardware. Sure, most of the more backstage deals you won't ever hear about, and for some of the other cases you might have absolutely no interest. Fact is, Linux has /by far/ the best hardware support of all operating systems out there. You only notice the (small) minority of devices that don't work (yet). Sure, it is mostly in the latest glitter where support is currently lacking, and this distorts the perspective quite a bit. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/10] cxgb3 - main header files
Divy Le Ray wrote: From: Divy Le Ray <[EMAIL PROTECTED]> This patch implements the main header files of the Chelsio T3 network driver. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> Once you think it's ready, email me a URL to a single patch that adds the driver to the latest linux-2.6.git kernel. Include in the email a description of the driver and signed-off-by line, which will get directly included in the git changelog. Adding new drivers is a bit special, because we want to merge it as a single changeset, but that would create a patch too large to review on the common kernel mailing lists. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2.6.20-rc2] ARM: AT91: clocksource for at91rm9200
Define a clocksource for the at91rm9200, switching it to use GENERIC_TIME.
(No clockevent support; this is against 2.6.20-rc code.)
Also, slightly streamline reads of the 32KHz counter; if we hit the update
window, we can now use 3 reads not 4.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
We've been asked to forward stuff to LKML not ARM or RT lists, so ...
arch/arm/mach-at91rm9200/Kconfig |1
arch/arm/mach-at91rm9200/at91rm9200_time.c | 47 -
2 files changed, 28 insertions(+), 20 deletions(-)
NOTE: at91sam926x chips need other solutions. The sam9263 will have two
RTTs; one could work like this 32K timer and the other can be the system's
battery-backed RTC. Otherwise the best bet may be the counter/timer module,
currently not usable from mainstream Linux patchsets. If the board doesn't
need one module for external interfacing, two 16-bit timers can chain to be
a clocksource (I have example code) and the third could issue clockevents
with the same precision (base is multi-MHz vs 32K).
Index: at91/arch/arm/mach-at91rm9200/Kconfig
===
--- at91.orig/arch/arm/mach-at91rm9200/Kconfig 2006-12-26 12:15:56.0
-0800
+++ at91/arch/arm/mach-at91rm9200/Kconfig 2006-12-26 12:16:04.0
-0800
@@ -7,6 +7,7 @@ choice
config ARCH_AT91RM9200
bool "AT91RM9200"
+ select GENERIC_TIME
config ARCH_AT91SAM9260
bool "AT91SAM9260"
Index: at91/arch/arm/mach-at91rm9200/at91rm9200_time.c
===
--- at91.orig/arch/arm/mach-at91rm9200/at91rm9200_time.c2006-12-26
12:07:36.0 -0800
+++ at91/arch/arm/mach-at91rm9200/at91rm9200_time.c 2006-12-26
12:16:04.0 -0800
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -38,33 +39,22 @@ static unsigned long last_crtr;
* The ST_CRTR is updated asynchronously to the master clock. It is therefore
* necessary to read it twice (with the same value) to ensure accuracy.
*/
-static inline unsigned long read_CRTR(void) {
+static inline unsigned long read_CRTR(void)
+{
unsigned long x1, x2;
- do {
- x1 = at91_sys_read(AT91_ST_CRTR);
+ x1 = at91_sys_read(AT91_ST_CRTR);
+ for (;;) {
x2 = at91_sys_read(AT91_ST_CRTR);
- } while (x1 != x2);
+ if (x1 == x2)
+ break;
+ x1 = x2;
+ };
return x1;
}
/*
- * Returns number of microseconds since last timer interrupt. Note that
interrupts
- * will have been disabled by do_gettimeofday()
- * 'LATCH' is hwclock ticks (see CLOCK_TICK_RATE in timex.h) per jiffy.
- * 'tick' is usecs per jiffy (linux/timex.h).
- */
-static unsigned long at91rm9200_gettimeoffset(void)
-{
- unsigned long elapsed;
-
- elapsed = (read_CRTR() - last_crtr) & AT91_ST_ALMV;
-
- return (unsigned long)(elapsed * (tick_nsec / 1000)) / LATCH;
-}
-
-/*
* IRQ handler for the timer.
*/
static irqreturn_t at91rm9200_timer_interrupt(int irq, void *dev_id)
@@ -91,6 +81,20 @@ static struct irqaction at91rm9200_timer
.handler= at91rm9200_timer_interrupt
};
+static cycle_t read_clk32k(void)
+{
+ return read_CRTR();
+}
+
+static struct clocksource clk32k = {
+ .name = "32k_counter",
+ .rating = 200,
+ .read = read_clk32k,
+ .mask = CLOCKSOURCE_MASK(20),
+ .shift = 10,
+ .is_continuous = 1,
+};
+
void at91rm9200_timer_reset(void)
{
last_crtr = 0;
@@ -125,6 +129,10 @@ void __init at91rm9200_timer_init(void)
/* Initialize and enable the timer interrupt */
at91rm9200_timer_reset();
+
+ /* register clocksource */
+ clk32k.mult = clocksource_hz2mult(32768, clk32k.shift);
+ clocksource_register();
}
#ifdef CONFIG_PM
@@ -139,7 +147,6 @@ static void at91rm9200_timer_suspend(voi
struct sys_timer at91rm9200_timer = {
.init = at91rm9200_timer_init,
- .offset = at91rm9200_gettimeoffset,
.suspend= at91rm9200_timer_suspend,
.resume = at91rm9200_timer_reset,
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Binary Drivers
> Again, while some of the car/house analogies may describe situations > where the seller has not conveyed all the rights, the video card > situation is completely different. You have the right to do what you > like with it and the seller retains no rights. Lack of documentation > is not an imposition on your rights, unless you had a specific promise > of documentation from the seller. I'm curious if you really believe this. So let me set up one last hypothetical. You buy a phone for $200. The manufacturer only represents that it works with CarrierCo. (You do not buy the phone form CarrierCo.) Two months later, CarrierCo stops supporting your phone's configuration. You need to make a configuration change to the phone to get it to work on CarrierCo's "newly upgraded" network. You go to change the phone's configuration and you discover it requires a code. You call the manufacturer of the phone and say "hey, it's my phone, give me my lock out code". The manufacturer says, "sure, for $450". You have the right to do what you like with the phone, of course. It's a great doorstop and a reasonable paper weight. The manufacturer didn't promise the phone's configuration wouldn't become obsolete or that you would be able to change the configuration. Lack of documentation is not an imposition on your rights, and you had no specific promise of documentation from the seller. I have to say, it honestly astonishes me that would people would make arguments like these. Are we so used to these kinds of one-sided arrangements that we've lost our common sense? DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: System / libata IDE controller woes (long)
I had the same problem you did when I put 3 identical controllers
together. To get around that problem I used 2 TX133s and 1 TX100x2. I
believe this is the root cause of your problems.
Justin.
On Tue, 26 Dec 2006, Erik Ohrnberger wrote:
> First off, Merry Christmas, Seasons Greetings and Happy Holidays!
>
> Hang on, this is a bit of a long story, but I think that you'll need the
> information and background.
>
> I want what amounts to a NAS, that I'd like to build on gentoo Linux. I'm
> familiar with gentoo and the use of EVMS, so I think I'm pretty well
> prepared from this perspective.
>
> Earlier this year, when I started putting it together, I gathered my
> hardware. A decent 2 GHz Athlon system with 512 MB RAM, DVD drive, a 40 GB
> system drive, and a 500 Watt power supply. Then I started adding hard
> disks. To date, I've got 5 80 GB PATA, 2 200 GB PATA, and 1 60 GB PATA.
>
> I mounted the drives on a set of aluminum rails that I had a friend make for
> me. They run vertically, and have slots through which screws are tightened
> into the normal hard drive's mounting holes. All the communication cables
> are 80 pin cables, and run pretty much straight to the controller cards,
> while the power pigtails fan out on the side of the 'tower'.
>
> With all these hard drives, I also got 3 Promise 20269 IDE controllers.
> After I put it all together, and creating 2 logical volumes, one linked EVMS
> LV, and one RAID5 across 5 80 GB drives. To support this configuration, I
> connected the drives in the follow manner (using /dev/hdX notation):
>
> ide0: /dev/hdc = System boot disk (Motherboard)
> /dev/hdb = DVD ROM
> ide1: /dev/hdc = nothing
> /dev/hdd = nothing
> ide2: /dev/hde = raid disk(First Promise card)
> /dev/hdf = lvm disk
> ide3: /dev/hdg = raid disk
> /dev/hdh = lvm disk
> ide4: /dev/hdi = raid disk(Second Promise card)
> /dev/hdj = lvm disk
> ide5: /dev/hdk = raid disk
> /dev/hdl = nothing
> ide6: /dev/hdm = raid disk(Thrid Promise card)
> /dev/hdn = nothing
> ide7: /dev/hdo = nothing
> /dev/hdp = nothing
>
> >From what I understood, this is how you want to connect a set of raid drives
> so that no one controller is over loaded with IO. But I had to use the
> other ports to connect the LVM.
>
> I started to get 'dma_expiry' errors (see message file extract below):
>
> Dec 22 21:29:33 livecd hdg: dma_timer_expiry: dma status == 0x21
> Dec 22 21:29:43 livecd hdg: DMA timeout error
> Dec 22 21:29:43 livecd hdg: dma timeout error: status=0x50 { DriveReady
> SeekComplete }
> Dec 22 21:29:43 livecd ide: failed opcode was: unknown
> Dec 22 21:29:43 livecd hdg: task_in_intr: status=0x51 { DriveReady
> SeekComplete Error }
> Dec 22 21:29:43 livecd hdg: task_in_intr: error=0x04 { DriveStatusError }
> Dec 22 21:29:43 livecd ide: failed opcode was: unknown
> Dec 22 21:29:43 livecd hdg: task_in_intr: status=0x51 { DriveReady
> SeekComplete Error }
> Dec 22 21:29:43 livecd hdg: task_in_intr: error=0x04 { DriveStatusError }
> Dec 22 21:29:43 livecd ide: failed opcode was: unknown
> Dec 22 21:29:43 livecd hdg: task_in_intr: status=0x51 { DriveReady
> SeekComplete Error }
> Dec 22 21:29:43 livecd hdg: task_in_intr: error=0x04 { DriveStatusError }
> Dec 22 21:29:43 livecd ide: failed opcode was: unknown
> Dec 22 21:29:43 livecd hdg: task_in_intr: status=0x51 { DriveReady
> SeekComplete Error }
> Dec 22 21:29:43 livecd hdg: task_in_intr: error=0x04 { DriveStatusError }
> Dec 22 21:29:43 livecd ide: failed opcode was: unknown
> Dec 22 21:29:43 livecd PDC202XX: Secondary channel reset.
> Dec 22 21:29:43 livecd ide3: reset: success
> Dec 22 21:30:03 livecd hdg: dma_timer_expiry: dma status == 0x21
> Dec 22 21:30:15 livecd hdg: DMA timeout error
> Dec 22 21:30:15 livecd hdg: dma timeout error: status=0x80 { Busy }
> Dec 22 21:30:15 livecd ide: failed opcode was: unknown
> Dec 22 21:30:15 livecd hdg: DMA disabled
> Dec 22 21:30:15 livecd PDC202XX: Secondary channel reset.
> Dec 22 21:30:20 livecd ide3: reset: success
> Dec 22 21:36:58 livecd hdg: irq timeout: status=0x80 { Busy }
> Dec 22 21:36:58 livecd ide: failed opcode was: unknown
> Dec 22 21:36:58 livecd PDC202XX: Secondary channel reset.
> Dec 22 21:37:33 livecd ide3: reset timed-out, status=0x80
> Dec 22 21:37:33 livecd hdg: status timeout: status=0x80 { Busy }
> Dec 22 21:37:33 livecd ide: failed opcode was: unknown
> Dec 22 21:37:33 livecd PDC202XX: Secondary channel reset.
> Dec 22 21:37:33 livecd hdg: drive not ready for command
> Dec 22 21:37:48 livecd ide3: reset: success
> Dec 22 21:37:58 livecd hdg: lost interrupt
>
> These errors caused the raid array to crash repeatedly, so I gave up on that
> and changed the raid to an EVMS drive linked logical volume, and changed
> their connections to as follows:
>
> ide0: /dev/hdc = System boot disk (motherboard)
> /dev/hdb = DVD ROM
> ide1: /dev/hdc = nothing
> /dev/hdd = nothing
> ide2:
[PATCH] Immediately update integer and string values in xconfig display
In xconfig's display integer and string values are also shown as part of
the config item's descriptive text.
This patch updates the descriptive text, when the corresponding
value has been changed.
Fix for http://bugzilla.kernel.org/show_bug.cgi?id=7744
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
--- rc1/scripts/kconfig/qconf.cc2006-12-23 21:35:12.0 +0100
+++ rc1-rt6-kw/scripts/kconfig/qconf.cc 2006-12-26 18:51:51.0 +0100
@@ -89,6 +89,8 @@ void ConfigItem::okRename(int col)
{
Parent::okRename(col);
sym_set_string_value(menu->sym, text(dataColIdx).latin1());
+ sym_calc_value(menu->sym);
+ updateMenu();
}
#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Tue, 26 Dec 2006, Nick Piggin wrote: > Linus Torvalds wrote: > > > > Ok, so how about this diff. > > > > I'm actually feeling good about this one. It really looks like > > "do_no_page()" was simply buggy, and that this explains everything. > > Still trying to catch up here, so I'm not going to reply to any old > stuff and just start at the tip of the thread... Other than to say > that I really like cancel_page_dirty ;) Yeah, I think that part is a bit clearer about what's going on now. > I think your patch is quite right so that's a good catch. Actually, since people told me it didn't matter, I went back and looked at _why_ - the thing is, "vma->vm_page_prot" should always be read-only anyway, except for mappings that don't do dirty accounting at all, so I think my patch only found cases that are unimportant (ie pages that get faulted on on filesystems like ramfs that doesn't do any dirty page accounting because they're all dirty anyway). > But I'm not too surprised that it does not help the problem, because I > don't think we have started shedding any old pte_dirty tests at > unmap/reclaim-time, have we? So the dirty bit isn't going to get lost, > as such. True. We should no longer _need_ those dirty bit reclaims at unmap/reclaim, but we still do them, so you're right, even if we were buggy in this area, it should only really matter for the dirty page counting, not for any lost data. > I was hoping that you've almost narrowed it down to the filesystem > writeback code, with the last few mails? I think so, yes. However, I've checked, and "rtorrent" really does seem to be fairly well-behaved wrt any filesystem activity. It does - no threading. It's 100% single-threaded, and doesn't even appear to use signals. - exactly _one_ "ftruncate()", and it does it at the beginning, for the full final size. IOW, it's not anything subtle with truncate and dirty page cancel. - It never uses mprotect on the shared mappings, but it _does_ do: "mincore()" - but the return values don't much matter (it's used as a heuristic on which parts to hash, apparently) I double- and triple-checked this one, because I did make changes to "mincore()", but those didn't go into the affected kernels anyway (ie they are not in plain 2.6.19, nor in 2.6.18.3 either) "madvise(MADV_WILLNEED)" "msync(MS_ASYNC)" (or MS_SYNC if you use a command line flag) "munmap()" of course - it never seems to mix mmap() and write() - it does _only_ mmap. - it seems to mmap/munmap the shared files in nice 64-page chunks, all 64-page aligned in the file (ie it does NOT create one big mapping, it has some kind of LRU of thse 64-page chunks). The only exception being the last chunk, which it maps byte-accurate to the size. - I haven't checked whether it only ever has the same chunk mapped once at a time. Anyway, the _one_ half-way interesting thing is the fact that it doesn't allocate any backing store at all for the file, and as such the page writeback needs to create all the underlying buffers on the filesystem. I really don't see why that would be a problem either, but I could imagine that if we have some writeback bug where we can end up writing back the _same_ page concurrently, we'd actually end up racing in the kernel, and allocating two different backing stores, and then maybe the other one would effectively "get lost" (and the earlier writeback would win the race, explaining why we'd end up with zeroes at the end of a block). Or something. However, all the codepaths _seem_ to test for PG_writeback, and not even try to start another writeback while the first one is still active. What would also actually be interesting is whether somebody can reproduce this on Reiserfs, for example. I _think_ all the reports I've seen are on ext2 or ext3, and if this is somehow writeback-related, it could be some bug that is just shared between the two by virtue of them still having a lot of stuff in common. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Binary Drivers
On 12/26/06, David Schwartz <[EMAIL PROTECTED]> wrote: It's really common sense. Imagine if you buy the right to use my car, but I don't give you the key. Can I say, "yes, you have the right to use my car, you bought that, but that doesn't mean I have to tell you how to use my car." --- I have to agree with Martin, that the car analogies really bear little relationship with the question of closed-source drivers... My point was that you buy what you buy, under the terms that you agree to. For a house, or a car, the "normal" terms would include any associated accessories, including keys. Keys also have a certain common-law "specialness", because they historically corresponded to the right to access. If you were buying a house or car and the seller was retaining keys (perhaps because they have some historical or personal significance), that would have to be disclosed and it would have to be clear that no rights were associated with the retained keys. --- ... Skipping the rest of the house/car analogies... When you buy a video car, you are *not* buying the right to use that video card with Windows. You are buying all the rights to the video card, to use it any way you please. The manufacturer has no right (because it sold that right when it sold the video card) to interfere or obstruct your right to use it as you please. --- There is a notion of "fitness for purpose" that sometimes applies - if the seller describes the object as fit for a particular purpose, then the seller has an obligation to make sure the object is, in fact, fit for that purpose. However, that's a very limited requirement - it's not required to be fit for any other purpose and being fit for that purpose would not require documentation unless that purpose normally required it. Note that selling a card as suitable for use with Windows would not suggest, in any way, that it was offered as suitable for use with Linux. Again, you buy the right to do anything you like with the object, but the seller has no obligation beyond the agreed terms. --- If you retain some rights over something, then you are not selling it in the normal sense. You are selling a subset of the rights to it, and the buy must be told what rights he is getting and what rights he is not getting. --- Again, while some of the car/house analogies may describe situations where the seller has not conveyed all the rights, the video card situation is completely different. You have the right to do what you like with it and the seller retains no rights. Lack of documentation is not an imposition on your rights, unless you had a specific promise of documentation from the seller. scott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/3] ensure unique i_ino in filesystems without permanent inode numbers (introduction)
Jeff Layton wrote: > > > > I'm still unsure whether idr has a sufficient advantage over simply > > hashing the inodes. Hch has suggested that keeping the hashtable > > smaller is good for performance. But idr adds new complexity, which > > should be avoided on its own right. So is the performance benefit big > > enough to add more complexity? Is it even measurable? > > > > Jörn > > > > > A very good question. Certainly, just hashing them would be a heck of a > lot simpler. That was my first inclination when I looked at this, but as > you said, HCH NAK'ed that idea stating that it would bloat out the > hashtable. I tend to think that it's probably not that significant, but > that might very much depend on workload. > > I'm OK with either approach, though I'd like to have some sort of buyin > from Christoph on hashing the inodes before I start working on patches to > do that. > > Christoph, care to comment? > > -- Jeff > > I'm still in limbo on this patchset and could use some guidance. It's not clear to me that IDR is really a big enough win over just hashing the inodes. It seems like the inode hash is pretty well optimized for fast lookups such that even if we get some extra hash collisions it shouldn't be too awful. Perhaps the best thing to do is to start with a patch that just hashes the inodes and then fall back to using IDR (or some other scheme) if it turns out that it impacts performance too much? Anyone have an opinion on what approach they think would be best here? -- Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Binary Drivers
Combined responses: > > If I bought the car from the manufacturer, it also must > > include any rights the manufacturer might have to the car's use. > > That includes using the car to violate emission control measures. > > If I didn't buy the right to use the car that way (insofar as > > that right was owned by the car manufacturer), I didn't > > buy the whole care -- just *some* of the rights to use it. > just to be dense - what makes you think that the car manufacturer has > any legal right to violate emission control measures? What an utter > nonsense (sorry). That's why I said "insofar as that right was owned by the car manufacturer". The example of emission control measures wasn't mine. I'm responding to a silly hypothetical. > So, lets stop the stupid car comparisons. They are no being funny any > more. They were never intended to be funny. They only become stupid when people deliberately pointed out the cases where the examples differ from the case we're realling interested in. I agree that examples involving cases where there are specific laws (such as emissions control) are silly. The point is that any rights the manufacturer may have had to the car should have been sold along with the car, otherwise it's not a normal free and clear sale. A normal free and clear sale includes all rights to the item sold, except those specific laws allows the manufacturer to retain. All the issues about whether the manufacturer has the right to break the law or whether the manufacturer has to help you break the law are not in any way relevant to the hardware issue we were discussion. Someone brought them up just to sidetrack the analogies. That's a very good way to make an analogy seem irrelevent, but it's cheating. So long as you stick to the issues that relate, the analogy is nearly perfect. See, for examlek, James C. Georgas post. -- >Solution (a) involves denial of point (1), mostly through the use of >analogy and allegory. Alternatively, one can try to change the law >through government channels. One doesn't need to change the law, just enforce it. I simply do not accept the argument that it is lawful for a manufacturer to sell a physical object in a normal free and clear sale and then refuse to disclose the knowledge necessary to use it. (And by that I mean necessary to use it any reasonable way, not just the way the manufacturer intended it to be used.) This same issue has been pressed in other areas and I think it's time it be pressed with graphics cards. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] net/xfrm: fix crash in ipsec audit logging
On Tue, 2006-26-12 at 18:56 +0100, Ingo Molnar wrote:
> + xfrm_audit_log(NETLINK_CB(skb).loginuid, NETLINK_CB(skb).sid,
> +AUDIT_MAC_IPSEC_DELSPD, delete, xp, NULL);
> +
> if (!delete) {
> struct sk_buff *resp_skb;
You could move the call into the else from above if (!delete) maybe?
Otherwise you have to add back the "if (delete)" check since that
function could be used to either retrieve (which is not subject to an
audit) or delete an xp.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] net/xfrm: fix crash in ipsec audit logging
Subject: [patch] net/xfrm: fix crash in ipsec audit logging
From: Ingo Molnar <[EMAIL PROTECTED]>
i got the following crash when restarting a (timed out) ipsec session on
2.6.20-rc1-rt4:
BUG: unable to handle kernel NULL pointer dereference at virtual address
00a2
printing eip:
c0320f67
*pde =
stopped custom tracer.
Oops: [#1]
PREEMPT SMP
Modules linked in: xfrm4_mode_tunnel deflate zlib_deflate twofish
twofish_common serpent blowfish cbc ecb xcbc sha256 crypto_null aes des
blkcipher xfrm4_tunnel tunnel4 ipcomp esp4 ah4 af_key radeon drm hidp l2cap
bluetooth sunrpc ipv6 n_hdlc ppp_synctty ppp_async crc_ccitt ppp_generic slhc
nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state xt_tcpudp
iptable_filter ip_tables x_tables dm_mirror dm_multipath dm_mod raid1 video sbs
i2c_ec button battery asus_acpi ac parport_pc lp parport floppy
snd_via82xx_modem snd_seq_dummy snd_via82xx snd_ac97_codec snd_seq_oss
snd_seq_midi_event ac97_bus bt878 tuner snd_seq bttv video_buf ir_common
snd_pcm_oss snd_mixer_oss videodev v4l1_compat v4l2_common i2c_algo_bit snd_pcm
btcx_risc tveeprom compat_ioctl32 pcspkr e100 skge mii i2c_viapro snd_timer
gameport snd_mpu401_uart snd_rawmidi snd_seq_device snd_page_alloc snd i2c_core
soundcore k8temp hwmon ide_cd serio_raw cdrom sata_via pata_via ata_generic
libata sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246 (2.6.20-rc1.1.rt4.0006 #1)
EIP is at xfrm_audit_log+0x116/0x423
eax: ebx: 0586 ecx: edx: c03dfc79
esi: 01f4 edi: ebp: f5229a48 esp: f522999c
ds: 007b es: 007b ss: 0068 preempt: 0001
Process pluto (pid: 12885, ti=f5229000 task=f7c06af0 task.ti=f5229000)
Stack: f7c5be00 c03f6e49 01f4 f3860a80 f52299bc c02ca13f
f52299dc c02ca247 0006 f52299e4 c01254ba 0001 e86fd000
f52299e4 c02ca27d f7c5be00 f8d928b9 f5229a10 c0155d14 f3860a80 fffd
Call Trace:
[] xfrm_get_policy+0x108/0x24f
[] xfrm_user_rcv_msg+0x132/0x155
[] netlink_run_queue+0x61/0xcd
[] xfrm_netlink_rcv+0x27/0x3b
[] netlink_data_ready+0x13/0x54
[] netlink_sendskb+0x1f/0x37
[] netlink_unicast+0x1aa/0x1b2
[] netlink_sendmsg+0x271/0x27d
[] sock_aio_write+0x104/0x110
[] do_sync_write+0xb2/0xef
[] vfs_write+0xc5/0x165
[] sys_write+0x3d/0x61
[] syscall_call+0x7/0xb
[<457d78b2>] 0x457d78b2
===
---
| preempt count: 0001 ]
| 1-level deep critical section nesting:
.. [] __spin_lock_irqsave+0x25/0x5e
.[] .. ( <= die+0x42/0x201)
skipping trace printing on CPU#0 != -1
Code: 24 e8 3e 5b e3 ff eb 08 8b 45 9c e8 43 9f e3 ff 83 7d 0c 00 74 12 8b 4d
0c 0f b7 99 9c 00 00 00 8b 91 18 01 00 00 eb 10 8b 45 10 <0f> b7 98 a2 00 00 00
8b 90 d8 01 00 00 85 d2 74 29 8d 42 08 89
EIP: [] xfrm_audit_log+0x116/0x423 SS:ESP 0068:f522999c
the reason for the crash is that we pass both 'xp' and 'x' as NULL into
xfrm_audit_log(), which thus has no other option but to crash.
The fix i think is to check for the presence of xp sooner and return
with -ENOENT, and to pass in the 'delete' flag as the result to the
audit subsystem, not the 'xp != NULL' boolen value.
(this is a new v2.6.19->v2.6.20-rc1 regression, i never had problems
with this functionality of the kernel.)
Hopefully i got the fix right :-)
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
net/xfrm/xfrm_user.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
Index: linux/net/xfrm/xfrm_user.c
===
--- linux.orig/net/xfrm/xfrm_user.c
+++ linux/net/xfrm/xfrm_user.c
@@ -1268,13 +1268,12 @@ static int xfrm_get_policy(struct sk_buf
xp = xfrm_policy_bysel_ctx(type, p->dir, >sel, tmp.security,
delete);
security_xfrm_policy_free();
}
- if (delete)
- xfrm_audit_log(NETLINK_CB(skb).loginuid, NETLINK_CB(skb).sid,
- AUDIT_MAC_IPSEC_DELSPD, (xp) ? 1 : 0, xp, NULL);
-
if (xp == NULL)
return -ENOENT;
+ xfrm_audit_log(NETLINK_CB(skb).loginuid, NETLINK_CB(skb).sid,
+ AUDIT_MAC_IPSEC_DELSPD, delete, xp, NULL);
+
if (!delete) {
struct sk_buff *resp_skb;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] ebtables: don't compute gap before checking struct type
We cannot compute the gap until we know we have a 'struct ebt_entry' and not 'struct ebt_entries'. Failure to check can cause crash. Tested by Santiago Garcia Mantinan <[EMAIL PROTECTED]> Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]> --- Can we get this upstream quickly? The bug's also in 2.6.19.1 and 2.6.18.6. --- 2.6.20-rc1-32smp.orig/net/bridge/netfilter/ebtables.c +++ 2.6.20-rc1-32smp/net/bridge/netfilter/ebtables.c @@ -610,7 +610,7 @@ ebt_check_entry(struct ebt_entry *e, str struct ebt_entry_target *t; struct ebt_target *target; unsigned int i, j, hook = 0, hookmask = 0; - size_t gap = e->next_offset - e->target_offset; + size_t gap; int ret; /* don't mess with the struct ebt_entries */ @@ -660,6 +660,7 @@ ebt_check_entry(struct ebt_entry *e, str if (ret != 0) goto cleanup_watchers; t = (struct ebt_entry_target *)(((char *)e) + e->target_offset); + gap = e->next_offset - e->target_offset; target = find_target_lock(t->u.name, , _mutex); if (!target) goto cleanup_watchers; -- MBTI: IXTP - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Tue, Dec 26, 2006 at 05:51:55PM +, Al Viro wrote: > On Sun, Dec 24, 2006 at 12:24:46PM -0800, Linus Torvalds wrote: > > > > > > On Sun, 24 Dec 2006, Andrei Popa wrote: > > > > > > Hash check on download completion found bad chunks, consider using > > > "safe_sync". > > > > Dang. Did you get any warning messages from the kernel? > > > > Linus > > BTW, rmap.c patch is broken - needs at least ... but that doesn't affect most of the architectures - only sparc64 and some of powerpc. So it's definitely not enough. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ebtables problems on 2.6.19.1 *and* 2.6.16.36
On Mon, Dec 25, 2006 at 11:42:32PM -0500, Chuck Ebbert wrote: > ebtables: don't compute gap until we know we have an ebt_entry > > We must check the bitmap field to make sure we have an ebt_entry and > not an ebt_entries struct before using fields from ebt_entry. > > Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]> Acked-by: Al Viro <[EMAIL PROTECTED]> My fault. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, Dec 24, 2006 at 12:24:46PM -0800, Linus Torvalds wrote: > > > On Sun, 24 Dec 2006, Andrei Popa wrote: > > > > Hash check on download completion found bad chunks, consider using > > "safe_sync". > > Dang. Did you get any warning messages from the kernel? > > Linus BTW, rmap.c patch is broken - needs at least Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- diff --git a/mm/rmap.c b/mm/rmap.c index 57306fa..669acb2 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -452,7 +452,7 @@ static int page_mkclean_one(struct page entry = ptep_clear_flush(vma, address, pte); entry = pte_wrprotect(entry); entry = pte_mkclean(entry); - set_pte_at(vma, address, pte, entry); + set_pte_at(mm, address, pte, entry); lazy_mmu_prot_update(entry); ret = 1; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc2
Hi.
Can you confirm that the problem I mentioned in
http://lkml.org/lkml/2006/12/24/32 is the same?
Best regards,
Fabio
On 12/26/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > I've had at least one more occurrence of it:
> >
> > [ 78.804940] BUG: scheduling while atomic: kbd/0x2000/3444
> > [ 78.804944]
> > [ 78.804945] Call Trace:
>
> ok, i can think of a simpler scenario:
> add_preempt_count(PREEMPT_ACTIVE) /twice/, nested into each other.
doh - the BKL! That does a down() in a PREEMPT_ACTIVE section, which can
trigger cond_resched(). The fix is to check for PREEMPT_ACTIVE in
cond_resched(). (and only in cond_resched())
Updated fix (against -rc2) attached.
Ingo
-->
Subject: [patch] sched: fix cond_resched_softirq() offset
From: Ingo Molnar <[EMAIL PROTECTED]>
remove the __resched_legal() check: it is conceptually broken.
The biggest problem it had is that it can mask buggy cond_resched()
calls. A cond_resched() call is only legal if we are not in an
atomic context, with two narrow exceptions:
- if the system is booting
- a reacquire_kernel_lock() down() done while PREEMPT_ACTIVE is set
But __resched_legal() hid this and just silently returned whenever
these primitives were called from invalid contexts. (Same goes for
cond_resched_locked() and cond_resched_softirq()).
furthermore, the __legal_resched(0) call was buggy in that it caused
unnecessarily long softirq latencies via cond_resched_softirq(). (which
is only called from softirq-off sections, hence the code did nothing.)
the fix is to resurrect the efficiency of the might_sleep checks and to
only allow the narrow exceptions.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
kernel/sched.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
Index: linux/kernel/sched.c
===
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -4617,17 +4617,6 @@ asmlinkage long sys_sched_yield(void)
return 0;
}
-static inline int __resched_legal(int expected_preempt_count)
-{
-#ifdef CONFIG_PREEMPT
- if (unlikely(preempt_count() != expected_preempt_count))
- return 0;
-#endif
- if (unlikely(system_state != SYSTEM_RUNNING))
- return 0;
- return 1;
-}
-
static void __cond_resched(void)
{
#ifdef CONFIG_DEBUG_SPINLOCK_SLEEP
@@ -4647,7 +4636,8 @@ static void __cond_resched(void)
int __sched cond_resched(void)
{
- if (need_resched() && __resched_legal(0)) {
+ if (need_resched() && !(preempt_count() & PREEMPT_ACTIVE) &&
+ system_state == SYSTEM_RUNNING) {
__cond_resched();
return 1;
}
@@ -4673,7 +4663,7 @@ int cond_resched_lock(spinlock_t *lock)
ret = 1;
spin_lock(lock);
}
- if (need_resched() && __resched_legal(1)) {
+ if (need_resched() && system_state == SYSTEM_RUNNING) {
spin_release(>dep_map, 1, _THIS_IP_);
_raw_spin_unlock(lock);
preempt_enable_no_resched();
@@ -4689,7 +4679,7 @@ int __sched cond_resched_softirq(void)
{
BUG_ON(!in_softirq());
- if (need_resched() && __resched_legal(0)) {
+ if (need_resched() && system_state == SYSTEM_RUNNING) {
raw_local_irq_disable();
_local_bh_enable();
raw_local_irq_enable();
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: scheduling while atomic - Linux 2.6.20-rc2-ga3d89517
On Tue, 26 Dec 2006 18:15:31 +0100 Pavel Machek wrote: > Hi! > > > some days and will let you know if the problem represents. Please note > > that it happened only twice and I don't have any clue on how to > > reproduce it. > > > > I added Pavel and Rafael to CC-list because for the first time in at > > least six months my laptop failed to resume after suspend-to-disk > > (userland tools) with this kernel. Guys, do you think that this > > failure could be related to this BUG? > > everything is possible, but this one does not seem too likely. Is > failure reproducible? Ingo just posted a patch for this problem. http://marc.theaimsgroup.com/?l=linux-kernel=116715139714252=2 --- ~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: BUG: scheduling while atomic - Linux 2.6.20-rc2-ga3d89517
Hi On 12/26/06, Pavel Machek <[EMAIL PROTECTED]> wrote: Hi! > some days and will let you know if the problem represents. Please note > that it happened only twice and I don't have any clue on how to > reproduce it. > > I added Pavel and Rafael to CC-list because for the first time in at > least six months my laptop failed to resume after suspend-to-disk > (userland tools) with this kernel. Guys, do you think that this > failure could be related to this BUG? everything is possible, but this one does not seem too likely. Is failure reproducible? Not at all. I applied Hirofumi's patch and the problem seems to be gone. But it was impossible to reproduce even without it: the BUG happened only twice and the resume failure only once. Pavel Fabio -- (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/
[PATCH 1/1 2.6.20-rc2] MM: SLOB is broken by recent cleanup of slab.h
From: Dimitri Gorokhovik <[EMAIL PROTECTED]>
Recent cleanup of slab.h broke SLOB allocator: the routine kmem_cache_init
has now the __init attribute for both slab.c and slob.c. This routine cannot
be removed after init in the case of slob.c -- it serves as a timer callback.
Provide a separate timer callback routine, call it once from kmem_cache_init,
keep the __init attribute on the latter.
Signed-off-by: Dimitri Gorokhovik <[EMAIL PROTECTED]>
---
--- linux-2.6.20-rc2-orig/mm/slob.c 2006-12-26 15:12:21.0 +0100
+++ linux-2.6.20-rc2/mm/slob.c 2006-12-26 18:02:28.0 +0100
@@ -60,6 +60,8 @@ static DEFINE_SPINLOCK(slob_lock);
static DEFINE_SPINLOCK(block_lock);
static void slob_free(void *b, int size);
+static void slob_timer_cbk(void);
+
static void *slob_alloc(size_t size, gfp_t gfp, int align)
{
@@ -326,7 +328,7 @@ const char *kmem_cache_name(struct kmem_
EXPORT_SYMBOL(kmem_cache_name);
static struct timer_list slob_timer = TIMER_INITIALIZER(
- (void (*)(unsigned long))kmem_cache_init, 0, 0);
+ (void (*)(unsigned long))slob_timer_cbk, 0, 0);
int kmem_cache_shrink(struct kmem_cache *d)
{
@@ -339,7 +341,12 @@ int kmem_ptr_validate(struct kmem_cache
return 0;
}
-void kmem_cache_init(void)
+void __init kmem_cache_init(void)
+{
+ slob_timer_cbk();
+}
+
+static void slob_timer_cbk(void)
{
void *p = slob_alloc(PAGE_SIZE, 0, PAGE_SIZE-1);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: scheduling while atomic - Linux 2.6.20-rc2-ga3d89517
Hi! > some days and will let you know if the problem represents. Please note > that it happened only twice and I don't have any clue on how to > reproduce it. > > I added Pavel and Rafael to CC-list because for the first time in at > least six months my laptop failed to resume after suspend-to-disk > (userland tools) with this kernel. Guys, do you think that this > failure could be related to this BUG? everything is possible, but this one does not seem too likely. Is failure reproducible? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] new home for atl1 driver
Happy Boxing Day! If you just turned on your shiny new box and discovered that it's got an Attansic L1 gigabit ethernet chip in it, and can't get Linux to recognize it, fear not. Jay and I are still working on getting the driver ready for merging. A lot of the fancy stuff is un(der)tested, but if you're just doing basic desktop stuff with it, it works just fine. We've started up a sourceforge project for it, at http://atl1.sf.net/ More content coming soon. If you're a user and want to be informed of our progress, subscribe to the atl1-users list. If you want to help out with development and/or testing, please subscribe to the atl1-devel list, and say hi. -- Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 2.6.20-rc2] MM: ramfs breaks without CONFIG_BLOCK
From: Dimitri Gorokhovik <[EMAIL PROTECTED]>
ramfs doesn't provide the .set_dirty_page a_op, and when the BLOCK
layer is not configured in, 'set_page_dirty' makes a call via a NULL
pointer.
Signed-off-by: Dimitri Gorokhovik <[EMAIL PROTECTED]>
---
--- linux-2.6.20-rc2-orig/mm/page-writeback.c 2006-12-26
15:12:21.0 +0100
+++ linux-2.6.20-rc2/mm/page-writeback.c2006-12-26 18:32:26.0
+0100
@@ -800,8 +800,8 @@ int redirty_page_for_writepage(struct wr
EXPORT_SYMBOL(redirty_page_for_writepage);
/*
- * If the mapping doesn't provide a set_page_dirty a_op, then
- * just fall through and assume that it wants buffer_heads.
+ * If the mapping doesn't provide a set_page_dirty a_op, and the BLOCK
layer is
+ * available, just fall through and assume that it wants buffer_heads.
*/
int fastcall set_page_dirty(struct page *page)
{
@@ -812,8 +812,12 @@ int fastcall set_page_dirty(struct page
#ifdef CONFIG_BLOCK
if (!spd)
spd = __set_page_dirty_buffers;
-#endif
return (*spd)(page);
+#else
+ if (spd)
+ return (*spd)(page);
+#endif
+
}
if (!PageDirty(page)) {
if (!TestSetPageDirty(page))
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [KORG] Re: kernel.org lies about latest -mm kernel
Willy Tarreau wrote: Just evil suggestion, but if you contact someone else than HP, they might be _very_ interested in taking HP's place and providing whatever you need to get their name on www.kernel.org. Sun and IBM do such monter machines too. That would not be very kind to HP, but it might help getting hardware faster. No, it would not be kind to HP. They have supported us pretty well so far, and as a consequence I really want to give them the right of first refusal. We're asking for a lot of equipment, and these things take time. This is all further complicated right now by the fact that we probably won't get our 501(c)3 decision from IRS until mid-2007. -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: [KORG] Re: kernel.org lies about latest -mm kernel
Nigel Cunningham wrote: Hi. I've have git trees against a few versions besides Linus', and have just moved all but Linus' to staging to help until you can get your new hardware. If others were encouraged to do the same, it might help a lot? Not really. In fact, it would hardly help at all. The two things git users can do to help is: 1. Make sure your alternatives file is set up correctly; 2. Keep your trees packed and pruned, to keep the file count down. If you do this, the load imposed by a single git tree is fairly negible. -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: [KORG] Re: kernel.org lies about latest -mm kernel
Russell King wrote: Ergo, downloads via http from ftp.uk.kernel.org are at best unreliable for multiple requests. I agree that it's not directly your problem, and isn't something you have direct control over. However, if you want to round-robin the .kernel.org IP addresses between different providers, I suggest that either the name resolves to just one site, or that kernel.org adopts a policy with their mirrors that they only become part of the .kernel.org DNS entries as long as they do not rewrite their site-specific URLs in terms of that address. Indeed. I just sent a complaint about this, and if we can figure out a decent way to test for this automatically we'll add it to our automatic tests. There is also always ftp. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 8250: make probing for TXEN bug a config option
Hello Andrew,
probing for UART_BUG_TXEN in 8250 driver leads to weird effects on some ARM
boards (pnx4008 for instance). That is, the driver detects UART_BUG_TXEN
(though it apparently shouldn't) and it leads to symbol loss in console on
input (i. e. you input 'a' and you get nothing, then you input 'b' and you get
'a', then you input 'c' and get 'b' and so on).
The patch below makes this very probing a configuration option turned on by
default.
drivers/serial/8250.c |5 -
drivers/serial/Kconfig | 10 ++
2 files changed, 14 insertions(+), 1 deletion(-)
Signed-off-by: Vitaly Wool <[EMAIL PROTECTED]>
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 51f3c73..cf3eb31 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -1645,6 +1645,7 @@ static int serial8250_startup(struct uar
serial8250_set_mctrl(>port, up->port.mctrl);
+#ifndef CONFIG_SERIAL_8250_DONT_TEST_BUG_TXEN
/*
* Do a quick test to see if we receive an
* interrupt when we enable the TX irq.
@@ -1660,7 +1661,9 @@ static int serial8250_startup(struct uar
pr_debug("ttyS%d - enabling bad tx status
workarounds\n",
port->line);
}
- } else {
+ } else
+#endif
+ {
up->bugs &= ~UART_BUG_TXEN;
}
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 2978c09..7efcaf3 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -223,6 +223,16 @@ config SERIAL_8250_DETECT_IRQ
If unsure, say N.
+config SERIAL_8250_DONT_TEST_BUG_TXEN
+ bool "Don't probe for TXEN bug"
+ depends on SERIAL_8250_EXTENDED
+ help
+ Say Y here if you don't want the kernel to probe for TXEN bug
+ on your serial port and try to workaround it. It might lead to
+ character loss on some boards, though this is quite a rare case.
+
+ If unsure, say N.
+
config SERIAL_8250_RSA
bool "Support RSA serial ports"
depends on SERIAL_8250_EXTENDED
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.20-rc2
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > I've had at least one more occurrence of it:
> >
> > [ 78.804940] BUG: scheduling while atomic: kbd/0x2000/3444
> > [ 78.804944]
> > [ 78.804945] Call Trace:
>
> ok, i can think of a simpler scenario:
> add_preempt_count(PREEMPT_ACTIVE) /twice/, nested into each other.
doh - the BKL! That does a down() in a PREEMPT_ACTIVE section, which can
trigger cond_resched(). The fix is to check for PREEMPT_ACTIVE in
cond_resched(). (and only in cond_resched())
Updated fix (against -rc2) attached.
Ingo
-->
Subject: [patch] sched: fix cond_resched_softirq() offset
From: Ingo Molnar <[EMAIL PROTECTED]>
remove the __resched_legal() check: it is conceptually broken.
The biggest problem it had is that it can mask buggy cond_resched()
calls. A cond_resched() call is only legal if we are not in an
atomic context, with two narrow exceptions:
- if the system is booting
- a reacquire_kernel_lock() down() done while PREEMPT_ACTIVE is set
But __resched_legal() hid this and just silently returned whenever
these primitives were called from invalid contexts. (Same goes for
cond_resched_locked() and cond_resched_softirq()).
furthermore, the __legal_resched(0) call was buggy in that it caused
unnecessarily long softirq latencies via cond_resched_softirq(). (which
is only called from softirq-off sections, hence the code did nothing.)
the fix is to resurrect the efficiency of the might_sleep checks and to
only allow the narrow exceptions.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
kernel/sched.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
Index: linux/kernel/sched.c
===
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -4617,17 +4617,6 @@ asmlinkage long sys_sched_yield(void)
return 0;
}
-static inline int __resched_legal(int expected_preempt_count)
-{
-#ifdef CONFIG_PREEMPT
- if (unlikely(preempt_count() != expected_preempt_count))
- return 0;
-#endif
- if (unlikely(system_state != SYSTEM_RUNNING))
- return 0;
- return 1;
-}
-
static void __cond_resched(void)
{
#ifdef CONFIG_DEBUG_SPINLOCK_SLEEP
@@ -4647,7 +4636,8 @@ static void __cond_resched(void)
int __sched cond_resched(void)
{
- if (need_resched() && __resched_legal(0)) {
+ if (need_resched() && !(preempt_count() & PREEMPT_ACTIVE) &&
+ system_state == SYSTEM_RUNNING) {
__cond_resched();
return 1;
}
@@ -4673,7 +4663,7 @@ int cond_resched_lock(spinlock_t *lock)
ret = 1;
spin_lock(lock);
}
- if (need_resched() && __resched_legal(1)) {
+ if (need_resched() && system_state == SYSTEM_RUNNING) {
spin_release(>dep_map, 1, _THIS_IP_);
_raw_spin_unlock(lock);
preempt_enable_no_resched();
@@ -4689,7 +4679,7 @@ int __sched cond_resched_softirq(void)
{
BUG_ON(!in_softirq());
- if (need_resched() && __resched_legal(0)) {
+ if (need_resched() && system_state == SYSTEM_RUNNING) {
raw_local_irq_disable();
_local_bh_enable();
raw_local_irq_enable();
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: bcm43xx-softmac broken on 2.6.20-rc2
Larry Finger <[EMAIL PROTECTED]> writes: > The patch does not apply because your mailer is breaking the white space and > substituting spaces for > tabs. No, it does not apply because it was space-stuffed. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.20-rc2
* Randy Dunlap <[EMAIL PROTECTED]> wrote: > I've had at least one more occurrence of it: > > [ 78.804940] BUG: scheduling while atomic: kbd/0x2000/3444 > [ 78.804944] > [ 78.804945] Call Trace: ok, i can think of a simpler scenario: add_preempt_count(PREEMPT_ACTIVE) /twice/, nested into each other. 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: bcm43xx-softmac broken on 2.6.20-rc2
bert hubert wrote: On Sun, Dec 24, 2006 at 09:51:50AM -0600, Larry Finger wrote: This is a heads-up for anyone wishing to use bcm43xx-softmac on Linus's git tree, which is now at v2.6.20-rc2. There are two serious bugs in that code. Fixes are found below. For some reason your patch does not apply to stock 2.6.20-rc2, although I don't see why. Applying it by hand makes things compile though, and even fixes the problem I mentioned in my previous post: The patch does not apply because your mailer is breaking the white space and substituting spaces for tabs. 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: [KORG] Re: kernel.org lies about latest -mm kernel
Dave Jones wrote: A wild idea just occured to me. You guys are running Fedora/RHEL kernels on the kernel.org boxes iirc, which have Ingo's 'tux' httpd accelerator. It might not make the problem go away, but it could make it more bearable under high load. Or it might do absolutely squat depending on the ratio of static/dynamic content. Almost the only dynamic content we have (that actually matters) is gitweb. Everything else is static, with Apache parked in sendfile(). Far too often in D state. -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: bcm43xx-softmac broken on 2.6.20-rc2
On Sun, Dec 24, 2006 at 09:51:50AM -0600, Larry Finger wrote: > This is a heads-up for anyone wishing to use bcm43xx-softmac on Linus's git > tree, which is now at > v2.6.20-rc2. There are two serious bugs in that code. Fixes are found below. For some reason your patch does not apply to stock 2.6.20-rc2, although I don't see why. Applying it by hand makes things compile though, and even fixes the problem I mentioned in my previous post: http://www.spinics.net/lists/netdev/msg21906.html Thanks! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc2
On Tue, 26 Dec 2006 13:40:19 +0100 Ingo Molnar wrote: > > * Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > [ 2844.871895] BUG: scheduling while atomic: cp/0x2000/2965 > > > This is the second report we've had where bit 29 of ->preempt_count is > > getting set. I don't think there's any legitimate way in which that > > bit can get set. (Ingo?) First one was me, on x86_64 UP. I ran memtest86 many hours with no problems found. It's an almost-new system fwiw. > It's not legitimate (the highest legitimate bit is PREEMPT_ACTIVE, bit > 28). Nor can i think of any bug scenario barring outright memory > corruption (either hardware or kernel induced) that could cause this. > It's quite hard to trigger bit 29 there via any of the scheduling > mechanisms: either the preempt count would have to underflow massively > /and/ avoid detection during that undflow (sheer impossible) or the > HARDIRQ_COUNT would have to overflow to more than 4096 (again near > impossible to trigger), and simultaneously the softirq and preempt count > would have to overflow by 256 /at once/, or underflow by 1 at once. The > likelyhood of that makes the likelyhood of GPL-ed Windows a sure bet in > comparison. > > So my guess would still be memory corruption of some sort, or some > really weird compiler bug. We just recently mandated REGPARM on i386 for > example, it would be interesting to know whether an older (say 2.6.18 or > 19) config had CONFIG_REGPARM enabled or not? Regparm can also tax the > hardware (the CPU in particular) a bit more. I've had at least one more occurrence of it: [ 78.804940] BUG: scheduling while atomic: kbd/0x2000/3444 [ 78.804944] [ 78.804945] Call Trace: [ 78.804952] [] __sched_text_start+0x60/0xae0 [ 78.804958] [] default_wake_function+0xd/0xf [ 78.804962] [] __wake_up_common+0x3e/0x68 [ 78.804966] [] __cond_resched+0x1c/0x44 [ 78.804969] [] cond_resched+0x29/0x30 [ 78.804973] [] __reacquire_kernel_lock+0x29/0x49 [ 78.804977] [] thread_return+0xa3/0xe2 [ 78.804981] [] __cond_resched+0x1c/0x44 [ 78.804985] [] cond_resched+0x29/0x30 [ 78.804989] [] device_add+0x3e1/0x53e [ 78.804993] [] device_register+0x19/0x1d [ 78.804996] [] device_create+0xdf/0x110 [ 78.805001] [] set_palette+0x5c/0x60 [ 78.805005] [] reset_terminal+0x1f0/0x1f5 [ 78.805010] [] vcs_make_sysfs+0x5e/0x62 [ 78.805014] [] con_open+0x88/0x9b [ 78.805018] [] tty_open+0x19c/0x310 [ 78.805022] [] chrdev_open+0x164/0x19d [ 78.805026] [] chrdev_open+0x0/0x19d [ 78.805030] [] __dentry_open+0xe9/0x1ba [ 78.805034] [] nameidata_to_filp+0x2d/0x3f [ 78.805038] [] do_filp_open+0x36/0x46 [ 78.805042] [] get_unused_fd+0x70/0x105 [ 78.805046] [] do_sys_open+0x4f/0xd7 [ 78.805050] [] sys_open+0x1b/0x1d [ 78.805054] [] system_call+0x7e/0x83 --- ~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: Linux 2.6.20-rc2
* Florin Iucha <[EMAIL PROTECTED]> wrote: > This is my year-old workstation that I've build from good parts (Asus > A8N-SLI premium, OCZ memory), not overclocked, not overheated (it is > in a Antec P180 case with 12 cm fans -> CPU max is 43'C when not used > for my hour-long simulations). I will leave it do memtest for a > couple hours. > > The compiler is "gcc version 4.1.2 20061028 (prerelease) (Debian > 4.1.1-19)" and the .config is attached. could you send a config that you used with the 2.6.19 (or 2.6.18) kernel? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/12] devres: implement managed PCI interface
Implement managed PCI interface - pcim_enable_device(),
pcim_pin_device() and pci_is_managed(). pcim_enable_device() is
equivalent to pci_enable_device() except that it makes the PCI device
managed. After pcim_enable_device(), PCI resources such as
enabledness, msi/msix/intx status and BAR regions become managed.
pcim_pin_device() is used by device drivers to ask PCI devres not to
disable the device on driver detach. This function is to handle cases
where a driver finds out that a device is otherwise busy and thus
shouldn't be disabled on probe failure or driver detach.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/pci/pci.c | 127 ++-
include/linux/pci.h |9
2 files changed, 135 insertions(+), 1 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 6bfb942..2ab2f8a 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -744,6 +744,104 @@ int pci_enable_device(struct pci_dev *dev)
return result;
}
+/*
+ * Managed PCI resources. This manages device on/off, intx/msi/msix
+ * on/off and BAR regions. pci_dev itself records msi/msix status, so
+ * there's no need to track it separately. pci_devres is initialized
+ * when a device is enabled using managed PCI device enable interface.
+ */
+struct pci_devres {
+ unsigned int disable:1;
+ unsigned int orig_intx:1;
+ unsigned int restore_intx:1;
+ u32 region_mask;
+};
+
+static void pcim_release(struct device *gendev, void *res)
+{
+ struct pci_dev *dev = container_of(gendev, struct pci_dev, dev);
+ struct pci_devres *this = res;
+ int i;
+
+ if (dev->msi_enabled)
+ pci_disable_msi(dev);
+ if (dev->msix_enabled)
+ pci_disable_msix(dev);
+
+ for (i = 0; i < DEVICE_COUNT_RESOURCE; i++)
+ if (this->region_mask & (1 << i))
+ pci_release_region(dev, i);
+
+ if (this->restore_intx)
+ pci_intx(dev, this->orig_intx);
+
+ if (this->disable)
+ pci_disable_device(dev);
+}
+
+static struct pci_devres * get_pci_dr(struct pci_dev *pdev)
+{
+ struct pci_devres *dr, *new_dr;
+
+ dr = devres_find(>dev, pcim_release, NULL, NULL);
+ if (dr)
+ return dr;
+
+ new_dr = devres_alloc(pcim_release, sizeof(*new_dr), GFP_KERNEL);
+ if (!new_dr)
+ return NULL;
+ return devres_get(>dev, new_dr, NULL, NULL);
+}
+
+static struct pci_devres * find_pci_dr(struct pci_dev *pdev)
+{
+ if (pci_is_managed(pdev))
+ return devres_find(>dev, pcim_release, NULL, NULL);
+ return NULL;
+}
+
+/**
+ * pcim_enable_device - Managed pci_enable_device()
+ * @pdev: PCI device to be initialized
+ *
+ * Managed pci_enable_device().
+ */
+int pcim_enable_device(struct pci_dev *pdev)
+{
+ struct pci_devres *dr;
+ int rc;
+
+ dr = get_pci_dr(pdev);
+ if (unlikely(!dr))
+ return -ENOMEM;
+ WARN_ON(!!dr->disable);
+
+ rc = pci_enable_device(pdev);
+ if (!rc) {
+ pdev->is_managed = 1;
+ dr->disable = 1;
+ }
+ return rc;
+}
+
+/**
+ * pcim_pin_device - Pin managed PCI device
+ * @pdev: PCI device to pin
+ *
+ * Pin managed PCI device @pdev. Pinned device won't be disabled on
+ * driver detach. @pdev must have been enabled with
+ * pcim_enable_device().
+ */
+void pcim_pin_device(struct pci_dev *pdev)
+{
+ struct pci_devres *dr;
+
+ dr = find_pci_dr(pdev);
+ WARN_ON(!dr || !dr->disable);
+ if (dr)
+ dr->disable = 0;
+}
+
/**
* pcibios_disable_device - disable arch specific PCI resources for device dev
* @dev: the PCI device to disable
@@ -767,8 +865,13 @@ void __attribute__ ((weak)) pcibios_disable_device (struct
pci_dev *dev) {}
void
pci_disable_device(struct pci_dev *dev)
{
+ struct pci_devres *dr;
u16 pci_command;
+ dr = find_pci_dr(dev);
+ if (dr)
+ dr->disable = 0;
+
if (atomic_sub_return(1, >enable_cnt) != 0)
return;
@@ -867,6 +970,8 @@ pci_get_interrupt_pin(struct pci_dev *dev, struct pci_dev
**bridge)
*/
void pci_release_region(struct pci_dev *pdev, int bar)
{
+ struct pci_devres *dr;
+
if (pci_resource_len(pdev, bar) == 0)
return;
if (pci_resource_flags(pdev, bar) & IORESOURCE_IO)
@@ -875,6 +980,10 @@ void pci_release_region(struct pci_dev *pdev, int bar)
else if (pci_resource_flags(pdev, bar) & IORESOURCE_MEM)
release_mem_region(pci_resource_start(pdev, bar),
pci_resource_len(pdev, bar));
+
+ dr = find_pci_dr(pdev);
+ if (dr)
+ dr->region_mask &= ~(1 << bar);
}
/**
@@ -893,6 +1002,8 @@ void pci_release_region(struct pci_dev *pdev, int bar)
*/
int pci_request_region(struct pci_dev *pdev, int bar, const char *res_name)
[PATCH 8/12] libata: update libata core layer to use devres
Update libata core layer to use devres.
* ata_device_add() acquires all resources in managed mode.
* ata_host is allocated as devres associated with ata_host_release.
* Port attached status is handled as devres associated with
ata_host_attach_release().
* Initialization failure and host removal is handedl by releasing
devres group.
* Except for ata_scsi_release() removal, LLD interface remains the
same. Some functions use hacky is_managed test to support both
managed and unmanaged devices. These will go away once all LLDs are
updated to use devres.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/ahci.c| 22 +-
drivers/ata/libata-core.c | 176 -
drivers/ata/libata-scsi.c |3 +-
drivers/ata/libata-sff.c | 47 ++---
include/linux/libata.h|9 +--
5 files changed, 109 insertions(+), 148 deletions(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 0656334..76bf3e6 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1763,38 +1763,24 @@ err_out:
return rc;
}
-static void ahci_remove_one (struct pci_dev *pdev)
+static void ahci_remove_one(struct pci_dev *pdev)
{
struct device *dev = pci_dev_to_dev(pdev);
struct ata_host *host = dev_get_drvdata(dev);
struct ahci_host_priv *hpriv = host->private_data;
- unsigned int i;
- int have_msi;
- for (i = 0; i < host->n_ports; i++)
- ata_port_detach(host->ports[i]);
+ ata_host_remove(host);
- have_msi = hpriv->flags & AHCI_FLAG_MSI;
- free_irq(host->irq, host);
-
- for (i = 0; i < host->n_ports; i++) {
- struct ata_port *ap = host->ports[i];
-
- ata_scsi_release(ap->scsi_host);
- scsi_host_put(ap->scsi_host);
- }
-
- kfree(hpriv);
pci_iounmap(pdev, host->mmio_base);
- kfree(host);
- if (have_msi)
+ if (hpriv->flags & AHCI_FLAG_MSI)
pci_disable_msi(pdev);
else
pci_intx(pdev, 0);
pci_release_regions(pdev);
pci_disable_device(pdev);
dev_set_drvdata(dev, NULL);
+ kfree(hpriv);
}
static int __init ahci_init(void)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 5fdf37f..3af7994 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -5511,28 +5511,25 @@ void ata_host_resume(struct ata_host *host)
* LOCKING:
* Inherited from caller.
*/
-
-int ata_port_start (struct ata_port *ap)
+int ata_port_start(struct ata_port *ap)
{
struct device *dev = ap->dev;
int rc;
- ap->prd = dma_alloc_coherent(dev, ATA_PRD_TBL_SZ, >prd_dma,
GFP_KERNEL);
+ ap->prd = dmam_alloc_coherent(dev, ATA_PRD_TBL_SZ, >prd_dma,
+ GFP_KERNEL);
if (!ap->prd)
return -ENOMEM;
rc = ata_pad_alloc(ap, dev);
- if (rc) {
- dma_free_coherent(dev, ATA_PRD_TBL_SZ, ap->prd, ap->prd_dma);
+ if (rc)
return rc;
- }
-
- DPRINTK("prd alloc, virt %p, dma %llx\n", ap->prd, (unsigned long long)
ap->prd_dma);
+ DPRINTK("prd alloc, virt %p, dma %llx\n", ap->prd,
+ (unsigned long long)ap->prd_dma);
return 0;
}
-
/**
* ata_port_stop - Undo ata_port_start()
* @ap: Port to shut down
@@ -5544,12 +5541,11 @@ int ata_port_start (struct ata_port *ap)
* LOCKING:
* Inherited from caller.
*/
-
void ata_port_stop (struct ata_port *ap)
{
struct device *dev = ap->dev;
- dma_free_coherent(dev, ATA_PRD_TBL_SZ, ap->prd, ap->prd_dma);
+ dmam_free_coherent(dev, ATA_PRD_TBL_SZ, ap->prd, ap->prd_dma);
ata_pad_free(ap, dev);
}
@@ -5732,6 +5728,27 @@ static struct ata_port * ata_port_add(const struct
ata_probe_ent *ent,
return ap;
}
+static void ata_host_release(struct device *gendev, void *res)
+{
+ struct ata_host *host = dev_get_drvdata(gendev);
+ int i;
+
+ for (i = 0; i < host->n_ports; i++) {
+ struct ata_port *ap = host->ports[i];
+
+ if (!ap)
+ continue;
+
+ if (ap->ops->port_stop)
+ ap->ops->port_stop(ap);
+
+ scsi_host_put(ap->scsi_host);
+ }
+
+ if (host->ops->host_stop)
+ host->ops->host_stop(host);
+}
+
/**
* ata_sas_host_init - Initialize a host struct
* @host: host to initialize
@@ -5784,11 +5801,17 @@ int ata_device_add(const struct ata_probe_ent *ent)
dev_printk(KERN_ERR, dev, "is not available: No interrupt
assigned.\n");
return 0;
}
+
+ if (!devres_open_group(dev, ata_device_add, GFP_KERNEL))
+ return 0;
+
/* alloc a container for our list of ATA ports (buses) */
- host = kzalloc(sizeof(struct ata_host) +
-
[PATCH 10/12] libata: remove unused functions
Now that all LLDs are converted to use devres, default stop callbacks
are unused. Remove them.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c | 91 -
include/linux/libata.h|4 --
2 files changed, 8 insertions(+), 87 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 3af7994..e4ad6e1 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -5531,31 +5531,6 @@ int ata_port_start(struct ata_port *ap)
}
/**
- * ata_port_stop - Undo ata_port_start()
- * @ap: Port to shut down
- *
- * Frees the PRD table.
- *
- * May be used as the port_stop() entry in ata_port_operations.
- *
- * LOCKING:
- * Inherited from caller.
- */
-void ata_port_stop (struct ata_port *ap)
-{
- struct device *dev = ap->dev;
-
- dmam_free_coherent(dev, ATA_PRD_TBL_SZ, ap->prd, ap->prd_dma);
- ata_pad_free(ap, dev);
-}
-
-void ata_host_stop (struct ata_host *host)
-{
- if (host->mmio_base)
- iounmap(host->mmio_base);
-}
-
-/**
* ata_dev_init - Initialize an ata_device structure
* @dev: Device structure to initialize
*
@@ -5894,7 +5869,7 @@ int ata_device_add(const struct ata_probe_ent *ent)
}
/* resource acquisition complete */
- devres_close_group(dev, ata_device_add);
+ devres_remove_group(dev, ata_device_add);
/* perform each probe synchronously */
DPRINTK("probe begin\n");
@@ -6032,26 +6007,6 @@ void ata_port_detach(struct ata_port *ap)
scsi_remove_host(ap->scsi_host);
}
-/**
- * ata_host_remove - PCI layer callback for device removal
- * @host: ATA host set that was removed
- *
- * Unregister all objects associated with this host set. Free those
- * objects.
- *
- * LOCKING:
- * Inherited from calling layer (may sleep).
- */
-void ata_host_remove(struct ata_host *host)
-{
- unsigned int i;
-
- for (i = 0; i < host->n_ports; i++)
- ata_port_detach(host->ports[i]);
-
- devres_release_group(host->dev, ata_device_add);
-}
-
struct ata_probe_ent *
ata_probe_ent_alloc(struct device *dev, const struct ata_port_info *port)
{
@@ -6111,26 +6066,13 @@ void ata_std_ports(struct ata_ioports *ioaddr)
#ifdef CONFIG_PCI
-void ata_pci_host_stop (struct ata_host *host)
-{
- struct pci_dev *pdev = to_pci_dev(host->dev);
-
- /* XXX - the following if can go away once all LLDs are managed */
- if (!list_empty(>dev->devres_head))
- pcim_iounmap(pdev, host->mmio_base);
- else
- pci_iounmap(pdev, host->mmio_base);
-}
-
/**
* ata_pci_remove_one - PCI layer callback for device removal
* @pdev: PCI device that was removed
*
- * PCI layer indicates to libata via this hook that
- * hot-unplug or module unload event has occurred.
- * Handle this by unregistering all objects associated
- * with this PCI device. Free those objects. Then finally
- * release PCI resources and disable device.
+ * PCI layer indicates to libata via this hook that hot-unplug or
+ * module unload event has occurred. Detach all ports. Resource
+ * release is handled via devres.
*
* LOCKING:
* Inherited from PCI layer (may sleep).
@@ -6139,19 +6081,10 @@ void ata_pci_remove_one(struct pci_dev *pdev)
{
struct device *dev = pci_dev_to_dev(pdev);
struct ata_host *host = dev_get_drvdata(dev);
+ int i;
- /* XXX - the following if can go away once all LLDs are managed */
- if (!list_empty(>dev->devres_head)) {
- ata_host_remove(host);
- pci_release_regions(pdev);
- pci_disable_device(pdev);
- dev_set_drvdata(dev, NULL);
- } else {
- int i;
-
- for (i = 0; i < host->n_ports; i++)
- ata_port_detach(host->ports[i]);
- }
+ for (i = 0; i < host->n_ports; i++)
+ ata_port_detach(host->ports[i]);
}
/* move to PCI subsystem */
@@ -6205,11 +6138,7 @@ int ata_pci_device_do_resume(struct pci_dev *pdev)
pci_set_power_state(pdev, PCI_D0);
pci_restore_state(pdev);
- /* XXX - the following if can go away once all LLDs are managed */
- if (!list_empty(>dev.devres_head))
- rc = pcim_enable_device(pdev);
- else
- rc = pci_enable_device(pdev);
+ rc = pcim_enable_device(pdev);
if (rc) {
dev_printk(KERN_ERR, >dev,
"failed to enable device after resume (%d)\n", rc);
@@ -6389,7 +6318,6 @@ EXPORT_SYMBOL_GPL(ata_std_ports);
EXPORT_SYMBOL_GPL(ata_host_init);
EXPORT_SYMBOL_GPL(ata_device_add);
EXPORT_SYMBOL_GPL(ata_port_detach);
-EXPORT_SYMBOL_GPL(ata_host_remove);
EXPORT_SYMBOL_GPL(ata_sg_init);
EXPORT_SYMBOL_GPL(ata_sg_init_one);
EXPORT_SYMBOL_GPL(ata_hsm_move);
@@ -6406,8
[PATCH 11/12] devres: implement pcim_iomap_regions()
Implement pcim_iomap_regions(). This function takes mask of BARs to
request and iomap. No BAR should have length of zero. BARs are
iomapped using pcim_iomap_table().
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
include/linux/io.h |2 +
lib/iomap.c| 53
2 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/include/linux/io.h b/include/linux/io.h
index 4266638..60d41eb 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -35,6 +35,8 @@ void __iomem * pcim_iomap(struct pci_dev *pdev, int bar,
unsigned long maxlen);
void pcim_iounmap(struct pci_dev *pdev, void __iomem *addr);
void __iomem * const * pcim_iomap_table(struct pci_dev *pdev);
+int pcim_iomap_regions(struct pci_dev *pdev, u16 mask, const char *name);
+
/**
* check_signature - find BIOS signatures
* @io_addr: mmio address to check
diff --git a/lib/iomap.c b/lib/iomap.c
index 2e058b6..735c38c 100644
--- a/lib/iomap.c
+++ b/lib/iomap.c
@@ -357,3 +357,56 @@ void pcim_iounmap(struct pci_dev *pdev, void __iomem *addr)
WARN_ON(1);
}
EXPORT_SYMBOL(pcim_iounmap);
+
+/**
+ * pcim_iomap_regions - Request and iomap PCI BARs
+ * @pdev: PCI device to map IO resources for
+ * @mask: Mask of BARs to request and iomap
+ * @name: Name used when requesting regions
+ *
+ * Request and iomap regions specified by @mask.
+ */
+int pcim_iomap_regions(struct pci_dev *pdev, u16 mask, const char *name)
+{
+ void __iomem * const *iomap;
+ int i, rc;
+
+ iomap = pcim_iomap_table(pdev);
+ if (!iomap)
+ return -ENOMEM;
+
+ for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
+ unsigned long len;
+
+ if (!(mask & (1 << i)))
+ continue;
+
+ rc = -EINVAL;
+ len = pci_resource_len(pdev, i);
+ if (!len)
+ goto err_inval;
+
+ rc = pci_request_region(pdev, i, name);
+ if (rc)
+ goto err_region;
+
+ rc = -ENOMEM;
+ if (!pcim_iomap(pdev, i, 0))
+ goto err_iomap;
+ }
+
+ return 0;
+
+ err_iomap:
+ pcim_iounmap(pdev, iomap[i]);
+ err_region:
+ pci_release_region(pdev, i);
+ err_inval:
+ while (--i >= 0) {
+ pcim_iounmap(pdev, iomap[i]);
+ pci_release_region(pdev, i);
+ }
+
+ return rc;
+}
+EXPORT_SYMBOL(pcim_iomap_regions);
--
1.4.4.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/
[PATCH 7/12] libata: handle pci_enable_device() failure while resuming
Handle pci_enable_device() failure while resuming. This patch kills
the "ignoring return value of 'pci_enable_device'" warning message and
propagates __must_check through ata_pci_device_do_resume().
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/ahci.c|4 +++-
drivers/ata/libata-core.c | 22 +-
drivers/ata/sata_sil.c|6 +-
drivers/ata/sata_sil24.c |5 -
include/linux/libata.h|2 +-
5 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index b517d24..0656334 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1372,7 +1372,9 @@ static int ahci_pci_device_resume(struct pci_dev *pdev)
void __iomem *mmio = host->mmio_base;
int rc;
- ata_pci_device_do_resume(pdev);
+ rc = ata_pci_device_do_resume(pdev);
+ if (rc)
+ return rc;
if (pdev->dev.power.power_state.event == PM_EVENT_SUSPEND) {
rc = ahci_reset_controller(mmio, pdev);
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 0d51d13..5fdf37f 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6221,12 +6221,22 @@ void ata_pci_device_do_suspend(struct pci_dev *pdev,
pm_message_t mesg)
}
}
-void ata_pci_device_do_resume(struct pci_dev *pdev)
+int ata_pci_device_do_resume(struct pci_dev *pdev)
{
+ int rc;
+
pci_set_power_state(pdev, PCI_D0);
pci_restore_state(pdev);
- pci_enable_device(pdev);
+
+ rc = pci_enable_device(pdev);
+ if (rc) {
+ dev_printk(KERN_ERR, >dev,
+ "failed to enable device after resume (%d)\n", rc);
+ return rc;
+ }
+
pci_set_master(pdev);
+ return 0;
}
int ata_pci_device_suspend(struct pci_dev *pdev, pm_message_t mesg)
@@ -6246,10 +6256,12 @@ int ata_pci_device_suspend(struct pci_dev *pdev,
pm_message_t mesg)
int ata_pci_device_resume(struct pci_dev *pdev)
{
struct ata_host *host = dev_get_drvdata(>dev);
+ int rc;
- ata_pci_device_do_resume(pdev);
- ata_host_resume(host);
- return 0;
+ rc = ata_pci_device_do_resume(pdev);
+ if (rc == 0)
+ ata_host_resume(host);
+ return rc;
}
#endif /* CONFIG_PCI */
diff --git a/drivers/ata/sata_sil.c b/drivers/ata/sata_sil.c
index 7808d03..ca7111a 100644
--- a/drivers/ata/sata_sil.c
+++ b/drivers/ata/sata_sil.c
@@ -710,8 +710,12 @@ err_out:
static int sil_pci_device_resume(struct pci_dev *pdev)
{
struct ata_host *host = dev_get_drvdata(>dev);
+ int rc;
+
+ rc = ata_pci_device_do_resume(pdev);
+ if (rc)
+ return rc;
- ata_pci_device_do_resume(pdev);
sil_init_controller(pdev, host->n_ports, host->ports[0]->flags,
host->mmio_base);
ata_host_resume(host);
diff --git a/drivers/ata/sata_sil24.c b/drivers/ata/sata_sil24.c
index 5aa288d..da982ed 100644
--- a/drivers/ata/sata_sil24.c
+++ b/drivers/ata/sata_sil24.c
@@ -1200,8 +1200,11 @@ static int sil24_pci_device_resume(struct pci_dev *pdev)
{
struct ata_host *host = dev_get_drvdata(>dev);
struct sil24_host_priv *hpriv = host->private_data;
+ int rc;
- ata_pci_device_do_resume(pdev);
+ rc = ata_pci_device_do_resume(pdev);
+ if (rc)
+ return rc;
if (pdev->dev.power.power_state.event == PM_EVENT_SUSPEND)
writel(HOST_CTRL_GLOBAL_RST, hpriv->host_base + HOST_CTRL);
diff --git a/include/linux/libata.h b/include/linux/libata.h
index ab27548..8028a57 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -719,7 +719,7 @@ extern int ata_pci_init_one (struct pci_dev *pdev, struct
ata_port_info **port_i
unsigned int n_ports);
extern void ata_pci_remove_one (struct pci_dev *pdev);
extern void ata_pci_device_do_suspend(struct pci_dev *pdev, pm_message_t mesg);
-extern void ata_pci_device_do_resume(struct pci_dev *pdev);
+extern int __must_check ata_pci_device_do_resume(struct pci_dev *pdev);
extern int ata_pci_device_suspend(struct pci_dev *pdev, pm_message_t mesg);
extern int ata_pci_device_resume(struct pci_dev *pdev);
extern int ata_pci_clear_simplex(struct pci_dev *pdev);
--
1.4.4.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/
[PATCH 6/12] devres: implement managed iomap interface
Implement managed iomap interface - pcim_iomap_table(), pcim_iomap()
and pcim_iounmap(). Except for being managed, pcim_iomap() and
pcim_iounmap() take the same arguments and have the same effect as
non-managed coutnerparts.
pcim_iomap_table() returns pointer to constant array of void __iomem *
which record addresses for all mapped BARs. This function is
guaranteed to succeed after successful pcim_iomap() and drivers are
free to reference the returned iomap table.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
include/linux/io.h |7 +++
lib/Makefile |3 +-
lib/iomap.c| 105 +++-
3 files changed, 112 insertions(+), 3 deletions(-)
diff --git a/include/linux/io.h b/include/linux/io.h
index 81877ea..4266638 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -28,6 +28,13 @@ void __iowrite64_copy(void __iomem *to, const void *from,
size_t count);
int ioremap_page_range(unsigned long addr, unsigned long end,
unsigned long phys_addr, pgprot_t prot);
+/*
+ * Managed PCI iomap interface
+ */
+void __iomem * pcim_iomap(struct pci_dev *pdev, int bar, unsigned long maxlen);
+void pcim_iounmap(struct pci_dev *pdev, void __iomem *addr);
+void __iomem * const * pcim_iomap_table(struct pci_dev *pdev);
+
/**
* check_signature - find BIOS signatures
* @io_addr: mmio address to check
diff --git a/lib/Makefile b/lib/Makefile
index 77b4bad..29b2e99 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -5,7 +5,7 @@
lib-y := ctype.o string.o vsprintf.o cmdline.o \
bust_spinlocks.o rbtree.o radix-tree.o dump_stack.o \
idr.o div64.o int_sqrt.o bitmap.o extable.o prio_tree.o \
-sha1.o irq_regs.o reciprocal_div.o
+sha1.o irq_regs.o reciprocal_div.o iomap.o
lib-$(CONFIG_MMU) += ioremap.o
lib-$(CONFIG_SMP) += cpumask.o
@@ -41,7 +41,6 @@ obj-$(CONFIG_CRC_CCITT) += crc-ccitt.o
obj-$(CONFIG_CRC16)+= crc16.o
obj-$(CONFIG_CRC32)+= crc32.o
obj-$(CONFIG_LIBCRC32C)+= libcrc32c.o
-obj-$(CONFIG_GENERIC_IOMAP) += iomap.o
obj-$(CONFIG_GENERIC_ALLOCATOR) += genalloc.o
obj-$(CONFIG_ZLIB_INFLATE) += zlib_inflate/
diff --git a/lib/iomap.c b/lib/iomap.c
index d6ccdd8..2e058b6 100644
--- a/lib/iomap.c
+++ b/lib/iomap.c
@@ -4,8 +4,10 @@
* (C) Copyright 2004 Linus Torvalds
*/
#include
+#include
+
+#ifdef CONFIG_GENERIC_IOMAP
#include
-#include
/*
* Read/write from/to an (offsettable) iomem cookie. It might be a PIO
@@ -254,3 +256,104 @@ void pci_iounmap(struct pci_dev *dev, void __iomem * addr)
}
EXPORT_SYMBOL(pci_iomap);
EXPORT_SYMBOL(pci_iounmap);
+
+#endif /* CONFIG_GENERIC_IOMAP */
+
+/*
+ * PCI iomap devres.
+ */
+#define PCIM_IOMAP_MAX PCI_ROM_RESOURCE
+
+struct pcim_iomap_devres {
+ void __iomem *table[PCIM_IOMAP_MAX];
+};
+
+static void pcim_iomap_release(struct device *gendev, void *res)
+{
+ struct pci_dev *dev = container_of(gendev, struct pci_dev, dev);
+ struct pcim_iomap_devres *this = res;
+ int i;
+
+ for (i = 0; i < PCIM_IOMAP_MAX; i++)
+ if (this->table[i])
+ pci_iounmap(dev, this->table[i]);
+}
+
+/**
+ * pcim_iomap_table - access iomap allocation table
+ * @pdev: PCI device to access iomap table for
+ *
+ * Access iomap allocation table for @dev. If iomap table doesn't
+ * exist and @pdev is managed, it will be allocated. All iomaps
+ * recorded in the iomap table are automatically unmapped on driver
+ * detach.
+ *
+ * This function might sleep when the table is first allocated but can
+ * be safely called without context and guaranteed to succed once
+ * allocated.
+ */
+void __iomem * const * pcim_iomap_table(struct pci_dev *pdev)
+{
+ struct pcim_iomap_devres *dr, *new_dr;
+
+ dr = devres_find(>dev, pcim_iomap_release, NULL, NULL);
+ if (dr)
+ return dr->table;
+
+ new_dr = devres_alloc(pcim_iomap_release, sizeof(*new_dr), GFP_KERNEL);
+ if (!new_dr)
+ return NULL;
+ dr = devres_get(>dev, new_dr, NULL, NULL);
+ return dr->table;
+}
+EXPORT_SYMBOL(pcim_iomap_table);
+
+/**
+ * pcim_iomap - Managed pcim_iomap()
+ * @pdev: PCI device to iomap for
+ * @bar: BAR to iomap
+ * @maxlen: Maximum length of iomap
+ *
+ * Managed pci_iomap(). Map is automatically unmapped on driver
+ * detach.
+ */
+void __iomem * pcim_iomap(struct pci_dev *pdev, int bar, unsigned long maxlen)
+{
+ void __iomem **tbl;
+
+ BUG_ON(bar >= PCIM_IOMAP_MAX);
+
+ tbl = (void __iomem **)pcim_iomap_table(pdev);
+ if (!tbl || tbl[bar]) /* duplicate mappings not allowed */
+ return NULL;
+
+ tbl[bar] = pci_iomap(pdev, bar, maxlen);
+ return tbl[bar];
+}
+EXPORT_SYMBOL(pcim_iomap);
+
+/**
+ * pcim_iounmap - Managed pci_iounmap()
+ * @pdev: PCI device to iounmap for
+ * @addr: Address to unmap
+ *
+ * Managed pci_iounmap(). @addr must be mapped using pcim_iomap().
+
[PATCH 2/12] devres: implement managed IO region interface
Implement managed IO region interface - devm_request_region() and
devm_release_region(). Except for the first @dev argument and being
managed, these take the same arguments and have the same effect as
non-managed coutnerparts.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
include/linux/ioport.h | 20 +++
kernel/resource.c | 62
2 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 15228d7..6859a3b 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -137,4 +137,24 @@ static inline int __deprecated
check_region(resource_size_t s,
{
return __check_region(_resource, s, n);
}
+
+/* Wrappers for managed devices */
+struct device;
+#define devm_request_region(dev,start,n,name) \
+ __devm_request_region(dev, _resource, (start), (n), (name))
+#define devm_request_mem_region(dev,start,n,name) \
+ __devm_request_region(dev, _resource, (start), (n), (name))
+
+extern struct resource * __devm_request_region(struct device *dev,
+ struct resource *parent, resource_size_t start,
+ resource_size_t n, const char *name);
+
+#define devm_release_region(start,n) \
+ __devm_release_region(dev, _resource, (start), (n))
+#define devm_release_mem_region(start,n) \
+ __devm_release_region(dev, _resource, (start), (n))
+
+extern void __devm_release_region(struct device *dev, struct resource *parent,
+ resource_size_t start, resource_size_t n);
+
#endif /* _LINUX_IOPORT_H */
diff --git a/kernel/resource.c b/kernel/resource.c
index 7b9a497..2a3f886 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
@@ -618,6 +619,67 @@ void __release_region(struct resource *parent,
resource_size_t start,
EXPORT_SYMBOL(__release_region);
/*
+ * Managed region resource
+ */
+struct region_devres {
+ struct resource *parent;
+ resource_size_t start;
+ resource_size_t n;
+};
+
+static void devm_region_release(struct device *dev, void *res)
+{
+ struct region_devres *this = res;
+
+ __release_region(this->parent, this->start, this->n);
+}
+
+static int devm_region_match(struct device *dev, void *res, void *match_data)
+{
+ struct region_devres *this = res, *match = match_data;
+
+ return this->parent == match->parent &&
+ this->start == match->start && this->n == match->n;
+}
+
+struct resource * __devm_request_region(struct device *dev,
+ struct resource *parent, resource_size_t start,
+ resource_size_t n, const char *name)
+{
+ struct region_devres *dr = NULL;
+ struct resource *res;
+
+ dr = devres_alloc(devm_region_release, sizeof(struct region_devres),
+ GFP_KERNEL);
+ if (!dr)
+ return NULL;
+
+ dr->parent = parent;
+ dr->start = start;
+ dr->n = n;
+
+ res = __request_region(parent, start, n, name);
+ if (res)
+ devres_add(dev, dr);
+ else
+ devres_free(dr);
+
+ return res;
+}
+EXPORT_SYMBOL(__devm_request_region);
+
+void __devm_release_region(struct device *dev, struct resource *parent,
+ resource_size_t start, resource_size_t n)
+{
+ struct region_devres match_data = { parent, start, n };
+
+ __release_region(parent, start, n);
+ WARN_ON(devres_destroy(dev, devm_region_release, devm_region_match,
+ _data));
+}
+EXPORT_SYMBOL(__devm_release_region);
+
+/*
* Called from init/main.c to reserve IO ports.
*/
#define MAXRESERVE 4
--
1.4.4.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/
[RFC,PATCHSET] Managed device resources
Hello, all.
This patchset implements managed device resources, in short, devres.
## Intro
devres came up while trying to convert libata to use iomap. Each
iomapped address should be kept and unmapped on driver detach. For
example, a plain SFF ATA controller (that is, good old PCI IDE) in
native mode makes use of 5 PCI BARs and all of them should be
maintained.
As with many other device drivers, libata low level drivers have
sufficient bugs in ->remove and ->probe failure path. Well, yes,
that's probably because libata low level driver developers are lazy
bunch, but aren't all low level driver developers? After spending a
day fiddling with braindamaged hardware with no document or
braindamaged document, if it's finally working, well, it's working.
For one reason or another, low level drivers don't receive as much
attention or testing as core code, and bugs on driver detach or
initilaization failure doesn't happen often enough to be noticeable.
Init failure path is worse because it's much less travelled while
needs to handle multiple entry points.
So, many low level drivers end up leaking resources on driver detach
and having half broken failure path implementation in ->probe() which
would leak resources or even cause oops when failure occurs. iomap
adds more to this mix. So do msi and msix.
## Devres
devres is basically linked list of arbitrarily sized memory areas
associated with a struct device. Each devres entry is associated with
a release function. A devres can be released in several ways. No
matter what, all devres entries are released on driver detach. On
release, the associated release function is invoked and then the
devres entry is freed.
Managed interface is created for resources commonly used by device
drivers using devres. For example, coherent DMA memory is acquired
using dma_alloc_coherent(). The managed version is called
dmam_alloc_coherent(). It is identical to dma_alloc_coherent() except
for the DMA memory allocated using it is managed and will be
automatically released on driver detach. Implementation looks like
the following.
struct dma_devres {
size_t size;
void*vaddr;
dma_addr_t dma_handle;
};
static void dmam_coherent_release(struct device *dev, void *res)
{
struct dma_devres *this = res;
dma_free_coherent(dev, this->size, this->vaddr, this->dma_handle);
}
dmam_alloc_coherent(dev, size, dma_handle, gfp)
{
struct dma_devres *dr;
void *vaddr;
dr = devres_alloc(dmam_coherent_release, sizeof(*dr), gfp);
...
/* alloc DMA memory as usual */
vaddr = dma_alloc_coherent(...);
...
/* record size, vaddr, dma_handle in dr */
dr->vaddr = vaddr;
...
devres_add(dev, dr);
return vaddr;
}
If a driver uses dmam_alloc_coherent(), the area is guaranteed to be
freed whether initialization fails half-way or the device gets
detached. If most resources are acquired using managed interface, a
driver can have much simpler init and exit code. Init path basically
looks like the following.
my_init_one()
{
struct mydev *d;
d = devm_kzalloc(dev, sizeof(*d), GFP_KERNEL);
if (!d)
return -ENOMEM;
d->ring = dmam_alloc_coherent(...);
if (!d->ring)
return -ENOMEM;
if (check something)
return -EINVAL;
...
return register_to_upper_layer(d);
}
And exit path,
my_remove_one()
{
unregister_from_upper_layer(d);
shutdown_my_hardware();
}
As shown above, low level drivers can be simplified a lot by using
devres. Complexity is shifted from less maintained low level drivers
to better maintained higher layer. Also, as init failure path is
shared with exit path, both can get more testing.
## Devres group
Devres entries can be grouped using devres group. When a group is
released, all contained normal devres entries and properly nested
groups are released. One usage is to rollback series of acquired
resources on failure. For example,
if (!devres_open_group(dev, NULL, GFP_KERNEL))
return -ENOMEM;
acquire A;
if (failed)
goto err;
acquire B;
if (failed)
goto err;
...
devres_remove_group(dev, NULL);
return 0;
err:
devres_release_group(dev, NULL);
return err_code;
As resource acquision failure usually means probe failure, constructs
like above are usually useful in midlayer driver (e.g. libata core
layer) where interface function shouldn't have side effect on failure.
For LLDs, just returning error code suffices in most cases.
## Details
Lifetime of a devres entry begins on devres allocation and finishes
when it is released or destroyed (removed and freed) - no reference
counting.
devres core guarantees atomicity to all basic devres operations and
has support for single-instance devres types (atomic
[PATCH 3/12] devres: implement managed IRQ interface
Implement managed IRQ interface - devm_request_irq() and
devm_free_irq(). Except for the first @dev argument and being
managed, these take the same arguments and have the same effect as
non-managed coutnerparts.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
include/linux/interrupt.h |6 +++
kernel/irq/manage.c | 86 +
2 files changed, 92 insertions(+), 0 deletions(-)
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index e36e86c..5a8ba0b 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -83,6 +84,11 @@ extern int request_irq(unsigned int, irq_handler_t handler,
unsigned long, const char *, void *);
extern void free_irq(unsigned int, void *);
+extern int devm_request_irq(struct device *dev, unsigned int irq,
+ irq_handler_t handler, unsigned long irqflags,
+ const char *devname, void *dev_id);
+extern void devm_free_irq(struct device *dev, unsigned int irq, void *dev_id);
+
/*
* On lockdep we dont want to enable hardirqs in hardirq
* context. Use local_irq_enable_in_hardirq() to annotate
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index b385878..9aa6544 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -479,3 +479,89 @@ int request_irq(unsigned int irq, irq_handler_t handler,
return retval;
}
EXPORT_SYMBOL(request_irq);
+
+/*
+ * Device resource management aware IRQ request/free implementation.
+ */
+struct irq_devres {
+ unsigned int irq;
+ void *dev_id;
+};
+
+static void devm_irq_release(struct device *dev, void *res)
+{
+ struct irq_devres *this = res;
+
+ free_irq(this->irq, this->dev_id);
+}
+
+static int devm_irq_match(struct device *dev, void *res, void *data)
+{
+ struct irq_devres *this = res, *match = data;
+
+ return this->irq == match->irq && this->dev_id == match->dev_id;
+}
+
+/**
+ * devm_request_irq - allocate an interrupt line for a managed device
+ * @dev: device to request interrupt for
+ * @irq: Interrupt line to allocate
+ * @handler: Function to be called when the IRQ occurs
+ * @irqflags: Interrupt type flags
+ * @devname: An ascii name for the claiming device
+ * @dev_id: A cookie passed back to the handler function
+ *
+ * Except for the extra @dev argument, this function takes the
+ * same arguments and performs the same function as
+ * request_irq(). IRQs requested with this function will be
+ * automatically freed on driver detach.
+ *
+ * If an IRQ allocated with this function needs to be freed
+ * separately, dev_free_irq() must be used.
+ */
+int devm_request_irq(struct device *dev, unsigned int irq,
+irq_handler_t handler, unsigned long irqflags,
+const char *devname, void *dev_id)
+{
+ struct irq_devres *dr;
+ int rc;
+
+ dr = devres_alloc(devm_irq_release, sizeof(struct irq_devres),
+ GFP_KERNEL);
+ if (!dr)
+ return -ENOMEM;
+
+ rc = request_irq(irq, handler, irqflags, devname, dev_id);
+ if (rc) {
+ kfree(dr);
+ return rc;
+ }
+
+ dr->irq = irq;
+ dr->dev_id = dev_id;
+ devres_add(dev, dr);
+
+ return 0;
+}
+EXPORT_SYMBOL(devm_request_irq);
+
+/**
+ * devm_free_irq - free an interrupt
+ * @dev: device to free interrupt for
+ * @irq: Interrupt line to free
+ * @dev_id: Device identity to free
+ *
+ * Except for the extra @dev argument, this function takes the
+ * same arguments and performs the same function as free_irq().
+ * This function instead of free_irq() should be used to manually
+ * free IRQs allocated with dev_request_irq().
+ */
+void devm_free_irq(struct device *dev, unsigned int irq, void *dev_id)
+{
+ struct irq_devres match_data = { irq, dev_id };
+
+ free_irq(irq, dev_id);
+ WARN_ON(devres_destroy(dev, devm_irq_release, devm_irq_match,
+ _data));
+}
+EXPORT_SYMBOL(devm_free_irq);
--
1.4.4.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/
[PATCH 4/12] devres: implement managed DMA interface
Implement managed DMA interface - dmam_alloc_coherent(),
dmam_free_coherent(), dmam_declare_coherent_memory(),
dmam_pool_create() and dmam_pool_destroy(). Except for being managed,
these take the same arguments and have the same effect as non-managed
counterparts.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/base/Makefile |3 +-
drivers/base/dma-mapping.c | 218 +++
drivers/base/dmapool.c | 59
include/linux/dma-mapping.h | 29 ++-
include/linux/dmapool.h |7 ++
5 files changed, 314 insertions(+), 2 deletions(-)
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index e236f42..e9eb738 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -2,7 +2,8 @@
obj-y := core.o sys.o bus.o dd.o \
driver.o class.o platform.o \
- cpu.o firmware.o init.o map.o dmapool.o devres.o \
+ cpu.o firmware.o init.o map.o dmapool.o \
+ dma-mapping.o devres.o \
attribute_container.o transport_class.o
obj-y += power/
obj-$(CONFIG_ISA) += isa.o
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
new file mode 100644
index 000..ca9186f
--- /dev/null
+++ b/drivers/base/dma-mapping.c
@@ -0,0 +1,218 @@
+/*
+ * drivers/base/dma-mapping.c - arch-independent dma-mapping routines
+ *
+ * Copyright (c) 2006 SUSE Linux Products GmbH
+ * Copyright (c) 2006 Tejun Heo <[EMAIL PROTECTED]>
+ *
+ * This file is released under the GPLv2.
+ */
+
+#include
+
+/*
+ * Managed DMA API
+ */
+struct dma_devres {
+ size_t size;
+ void*vaddr;
+ dma_addr_t dma_handle;
+};
+
+static void dmam_coherent_release(struct device *dev, void *res)
+{
+ struct dma_devres *this = res;
+
+ dma_free_coherent(dev, this->size, this->vaddr, this->dma_handle);
+}
+
+static void dmam_noncoherent_release(struct device *dev, void *res)
+{
+ struct dma_devres *this = res;
+
+ dma_free_noncoherent(dev, this->size, this->vaddr, this->dma_handle);
+}
+
+static int dmam_match(struct device *dev, void *res, void *match_data)
+{
+ struct dma_devres *this = res, *match = match_data;
+
+ if (this->vaddr == match->vaddr) {
+ WARN_ON(this->size != match->size ||
+ this->dma_handle != match->dma_handle);
+ return 1;
+ }
+ return 0;
+}
+
+/**
+ * dmam_alloc_coherent - Managed dma_alloc_coherent()
+ * @dev: Device to allocate coherent memory for
+ * @size: Size of allocation
+ * @dma_handle: Out argument for allocated DMA handle
+ * @gfp: Allocation flags
+ *
+ * Managed dma_alloc_coherent(). Memory allocated using this function
+ * will be automatically released on driver detach.
+ *
+ * RETURNS:
+ * Pointer to allocated memory on success, NULL on failure.
+ */
+void * dmam_alloc_coherent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t gfp)
+{
+ struct dma_devres *dr;
+ void *vaddr;
+
+ dr = devres_alloc(dmam_coherent_release, sizeof(*dr), gfp);
+ if (!dr)
+ return NULL;
+
+ vaddr = dma_alloc_coherent(dev, size, dma_handle, gfp);
+ if (!vaddr) {
+ devres_free(dr);
+ return NULL;
+ }
+
+ dr->vaddr = vaddr;
+ dr->dma_handle = *dma_handle;
+ dr->size = size;
+
+ devres_add(dev, dr);
+
+ return vaddr;
+}
+EXPORT_SYMBOL(dmam_alloc_coherent);
+
+/**
+ * dmam_free_coherent - Managed dma_free_coherent()
+ * @dev: Device to free coherent memory for
+ * @size: Size of allocation
+ * @vaddr: Virtual address of the memory to free
+ * @dma_handle: DMA handle of the memory to free
+ *
+ * Managed dma_free_coherent().
+ */
+void dmam_free_coherent(struct device *dev, size_t size, void *vaddr,
+ dma_addr_t dma_handle)
+{
+ struct dma_devres match_data = { size, vaddr, dma_handle };
+
+ dma_free_coherent(dev, size, vaddr, dma_handle);
+ WARN_ON(devres_destroy(dev, dmam_coherent_release, dmam_match,
+ _data));
+}
+EXPORT_SYMBOL(dmam_free_coherent);
+
+/**
+ * dmam_alloc_non_coherent - Managed dma_alloc_non_coherent()
+ * @dev: Device to allocate non_coherent memory for
+ * @size: Size of allocation
+ * @dma_handle: Out argument for allocated DMA handle
+ * @gfp: Allocation flags
+ *
+ * Managed dma_alloc_non_coherent(). Memory allocated using this
+ * function will be automatically released on driver detach.
+ *
+ * RETURNS:
+ * Pointer to allocated memory on success, NULL on failure.
+ */
+void *dmam_alloc_noncoherent(struct device *dev, size_t size,
+dma_addr_t *dma_handle, gfp_t gfp)
+{
+ struct dma_devres *dr;
+ void *vaddr;
+
+ dr = devres_alloc(dmam_noncoherent_release, sizeof(*dr),
Re: two architectures,same source tree
On Fri, 22 Dec 2006, Randy Dunlap wrote:
> On Fri, 22 Dec 2006 21:45:26 +0100 Bodo Eggert wrote:
> > J�rn Engel <[EMAIL PROTECTED]> wrote:
> > > On Wed, 20 December 2006 20:32:20 +0200, Yakov Lerner wrote:
> >
> > >> Is it easily possible to build two architectures in
> > >> the same source tree (so that intermediate fles
> > >> and resut files do not interfere ) ?
> > >
> > > I'd try something like this:
> > > make O=../foo ARCH=foo
> > > make O=../bar ARCH=bar
> > >
> > > But as I'm lazy I'll leave the debugging to you. :)
> >
> > IIRC You'll have to specify ARCH= on each make call, but O= is saved in
> > ../foo/Makefile.
>
> Hm, top-level README file says:
>
>Please note: If the 'O=output/dir' option is used then it must be
>used for all invocations of make.
That should be: `... for all invocations of make in the source tree directory'.
It's done automaticallt when invoking make in the build directory.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH 1/12] devres: device resource management core
Implement device resource management core, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
In addition, managed kzalloc() and kfree() are implemented by this
patch.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/base/Kconfig | 12 +
drivers/base/Makefile |2 +-
drivers/base/base.h|1 +
drivers/base/core.c|2 +
drivers/base/dd.c |3 +
drivers/base/devres.c | 644
include/linux/device.h | 38 +++
7 files changed, 701 insertions(+), 1 deletions(-)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 1429f3a..5d6312e 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -37,6 +37,18 @@ config DEBUG_DRIVER
If you are unsure about this, say N here.
+config DEBUG_DEVRES
+ bool "Managed device resources verbose debug messages"
+ depends on DEBUG_KERNEL
+ help
+ This option enables kernel parameter devres.log. If set to
+ non-zero, devres debug messages are printed. Select this if
+ you are having a problem with devres or want to debug
+ resource management for a managed device. devres.log can be
+ switched on and off from sysfs node.
+
+ If you are unsure about this, Say N here.
+
config SYS_HYPERVISOR
bool
default n
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 7bbb9ee..e236f42 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -2,7 +2,7 @@
obj-y := core.o sys.o bus.o dd.o \
driver.o class.o platform.o \
- cpu.o firmware.o init.o map.o dmapool.o \
+ cpu.o firmware.o init.o map.o dmapool.o devres.o \
attribute_container.o transport_class.o
obj-y += power/
obj-$(CONFIG_ISA) += isa.o
diff --git a/drivers/base/base.h b/drivers/base/base.h
index d26644a..de7e144 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -44,3 +44,4 @@ struct class_device_attribute *to_class_dev_attr(struct
attribute *_attr)
extern char *make_class_name(const char *name, struct kobject *kobj);
+extern void devres_release_all(struct device *dev);
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 67b79a7..d1c94e3 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -385,6 +385,8 @@ void device_initialize(struct device *dev)
INIT_LIST_HEAD(>dma_pools);
INIT_LIST_HEAD(>node);
init_MUTEX(>sem);
+ spin_lock_init(>devres_lock);
+ INIT_LIST_HEAD(>devres_head);
device_init_wakeup(dev, 0);
set_dev_node(dev, -1);
}
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 510e788..437e046 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -108,6 +108,7 @@ static int really_probe(void *void_data)
atomic_inc(_count);
pr_debug("%s: Probing driver %s with device %s\n",
drv->bus->name, drv->name, dev->bus_id);
+ WARN_ON(!list_empty(>devres_head));
dev->driver = drv;
if (driver_sysfs_add(dev)) {
@@ -133,6 +134,7 @@ static int really_probe(void *void_data)
goto done;
probe_failed:
+ devres_release_all(dev);
driver_sysfs_remove(dev);
dev->driver = NULL;
@@ -324,6 +326,7 @@ static void __device_release_driver(struct device * dev)
dev->bus->remove(dev);
else if (drv->remove)
drv->remove(dev);
+ devres_release_all(dev);
dev->driver = NULL;
put_driver(drv);
}
diff --git a/drivers/base/devres.c b/drivers/base/devres.c
new file mode 100644
index 000..e28c565
--- /dev/null
+++ b/drivers/base/devres.c
@@ -0,0 +1,644 @@
+/*
+ * drivers/base/devres.c - device resource management
+ *
+ * Copyright (c) 2006 SUSE Linux Products GmbH
+ * Copyright (c) 2006 Tejun Heo <[EMAIL PROTECTED]>
+ *
+ * This file is released under the GPLv2.
+ */
+
+#include
+#include
+
+struct devres_node {
+ struct list_headentry;
+ dr_release_trelease;
+#ifdef CONFIG_DEBUG_DEVRES
+ const char *name;
+ size_t size;
+#endif
+};
+
+struct devres {
+ struct devres_node node;
+
Re: Putting the sdhci to sleep safely [with attachments]
Hi! > > Okay, so trying 2.6.20-rc2 is good first step. > > OK. > > > And then description what the problem is. My machine sleeps okay with > > sdhci loaded... If I can reproduce, chance to do something about it > > gets bigger. > > Would it be easier/better if I managed to get to you a Lenovo 3000 V100 > (which *definitely* has the problem) for testing for 1 month? No, I do not think I've time for that. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Putting the sdhci to sleep safely [with attachments]
Hi, > Okay, so trying 2.6.20-rc2 is good first step. OK. > And then description what the problem is. My machine sleeps okay with > sdhci loaded... If I can reproduce, chance to do something about it > gets bigger. Would it be easier/better if I managed to get to you a Lenovo 3000 V100 (which *definitely* has the problem) for testing for 1 month? Merc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Putting the sdhci to sleep safely [with attachments]
Hi! > >> So, here I am... please find attache my lspci and the log of what > >> happens when the computer is put to sleep. > >> > >> I would also be happy to organise a bounty for this bug to be fixed. > > > > :-). Just hunt it yourself. It is probably easier than organizing a bounty. > > OK. I had a look at the code, and I foind it depressing. Not because it > was bad, but because it reminded me of how hopeless I am! > I can do my best to get you guys to communicate, *and* to get some > testing done - I am more than happy to spend as long as it takes > testing, compiling patches, and putting my laptop to sleep over and over > and over again. But coding... nope. Not on *this* code... Come on, C is not that hard. > > Ouch... you failed to mention what kernel you are using? > > I told you I'd embarrass myself... > > Linux merc-laptop 2.6.19-7-generic #2 SMP Mon Dec 4 16:46:19 UTC 2006 > i686 GNU/Linux Okay, so trying 2.6.20-rc2 is good first step. And then description what the problem is. My machine sleeps okay with sdhci loaded... If I can reproduce, chance to do something about it gets bigger. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB power usage
Hi! > > Couple of watts is not that bad, considering usb still eats 4W more > > than it should. > > The USB autosuspend mechanism has been present for a while in -mm and is > included in 2.6.20-rc (although you have to turn on CONFIG_USB_SUSPEND, > which is off by default -- it would be nice to change that). Has anybody > tried doing some real-world measurements to see if it actually makes a > significant improvement in power usage? I did measurements while in -mm, and yes it helped. And yes, it works in 2.6.20-rc2, too: [EMAIL PROTECTED]:~# cat /proc/acpi/battery/BAT0/state ; sleep 20; cat /proc/acpi/battery/BAT0/state ; sleep 20; cat /proc/acpi/battery/BAT0/state ; sleep 20 present: yes capacity state: ok charging state: discharging present rate:14245 mW remaining capacity: 50020 mWh present voltage: 15793 mV (turned off bluetooth hanging off USB here). present: yes capacity state: ok charging state: discharging present rate:11650 mW remaining capacity: 49940 mWh present voltage: 15830 mV present: yes capacity state: ok charging state: discharging present rate:10935 mW remaining capacity: 49870 mWh present voltage: 15826 mV [EMAIL PROTECTED]:~# As you can see, it saves ~3.5W, which is huge deal on machine that eats 11W total. (X60 owners, get 2.6.20, and _disable that bluetooth_ while not in use). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: omap compilation fixes
On Sat 2006-12-23 11:48:29, Tony Lindgren wrote: > Hi, > > * Pavel Machek <[EMAIL PROTECTED]> [061222 13:49]: > > Hi! > > > > > > This is not yet complete set. set_map() is missing in latest kernels. > > > > > > > > Fix DECLARE_WORK()-change-related compilation problems. Please apply, > > > > > > > > --- a/drivers/mmc/omap.c > > > > +++ b/drivers/mmc/omap.c > > > > @@ -2,7 +2,7 @@ > > > > * linux/drivers/media/mmc/omap.c > > > > * > > > > * Copyright (C) 2004 Nokia Corporation > > > > - * Written by Tuukka Tikkanen and Juha Yrjölä<[EMAIL PROTECTED]> > > > > + * Written by Tuukka Tikkanen and Juha Yrjölä <[EMAIL PROTECTED]> > > > > * Misc hacks here and there by Tony Lindgren <[EMAIL PROTECTED]> > > > > * Other hacks (DMA, SD, etc) by David Brownell > > > > * > > > > > > I already applied similar fixes to linux-omap for the workqueue changes, > > > so I only applied the MMC typo fix above. > > > > I thought I got pretty recent -git: > > > > omap git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git > > > > ...should I use another tree? > > > > Aha, I did another pull now and it seems to be better... no, it is > > not: > > > > Recovering from a previously interrupted fetch... > > Fetching pack (head and objects)... > > Fetching tags... > > Missing tag v2.6.20-rc1... > > Generating pack... > > Done counting 1 objects. > > Deltifying 1 objects. > > 100% (1/1) done > > Total 1, written 1 (delta 0), reused 1 (delta 0) > > Unpacking 1 objects > > 100% (1/1) done > > Up to date. > > > > Applying changes... > > Branch already fully merged. > > > > Plus it still does not compile: > > > > LD vmlinux > > arch/arm/plat-omap/built-in.o(.text+0xd470): In function > > `exmap_set_armmmu': > > : undefined reference to `set_pte' > > arch/arm/plat-omap/built-in.o(.text+0xd56c): In function > > `exmap_set_armmmu': > > : undefined reference to `set_pte' > > make: *** [vmlinux] Error 1 > > Is this still a problem? Sounds like the latest tree was not yet > mirrored from master.kernel.org when you pulled. Yep, it seems fixed. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
