Re: lmbench ctxsw regression with CFS
* Nick Piggin <[EMAIL PROTECTED]> wrote: > Oh good. Thanks for getting to the bottom of it. We have normally > disliked too much runtime tunables in the scheduler, so I assume these > are mostly going away or under a CONFIG option for 2.6.23? Or...? yeah, they are all already under CONFIG_SCHED_DEBUG. (it's just that the add-on optimization is not upstream yet - the tunings are still being tested) Btw., with SCHED_DEBUG we now also have your domain-tree sysctl patch upstream, which has been in -mm for a near eternity. > What CPU did you get these numbers on? Do the indirect calls hurt much > on those without an indirect predictor? (I'll try running some tests). it was on an older Athlon64 X2. I never saw indirect calls really hurting on modern x86 CPUs - dont both CPU makers optimize them pretty efficiently? (as long as the target function is always the same - which it is here.) > I must say that I don't really like the indirect calls a great deal, > and they could be eliminated just with a couple of branches and direct > calls. yeah - i'll try that too. We can make the indirect call the uncommon case and a NULL pointer be the common case, combined with a 'default', direct function call. But i doubt it makes a big (or even measurable) difference. 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] Use ERESTART_RESTARTBLOCK if poll() is interrupted by a signal (was: Re: [PATCH] Use ERESTARTNOHAND if poll() is interrupted by a signal)
* Oleg Nesterov ([EMAIL PROTECTED]) wrote:
> What we need is ERESTART_RESTARTBLOCK, and restart_block.arg2 should
> have the new timeout value, which takes the time we already slept
> into account.
This passes my simple 32-bit and 64-bit testing. See any issues with
this one?
thanks,
-chris
--
Subject: [PATCH] Use ERESTART_RESTARTBLOCK if poll() is interrupted by a signal
From: Chris Wright <[EMAIL PROTECTED]>
Lomesh reported poll returning EINTR during suspend/resume cycle.
This is caused by the STOP/CONT cycle that the freezer uses, generating
a pending signal for what in effect is an ignored signal. In general
poll is a little eager in returning EINTR, when it could try not bother
userspace and simply restart the syscall. Both select and ppoll do use
ERESTARTNOHAND to restart the syscall. Oleg points out that simply using
ERESTARTNOHAND will cause poll to restart with original timeout value.
which could ultimately lead to process never returning to userspace.
Instead use ERESTART_RESTARTBLOCK, and restart poll with updated timeout
value. Inspired by Manfred's use ERESTARTNOHAND in poll patch.
Cc: Manfred Spraul <[EMAIL PROTECTED]>
Cc: Oleg Nesterov <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Cc: Roland McGrath <[EMAIL PROTECTED]>
Cc: "Agarwal, Lomesh" <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
Patch against git-7a883eaf
fs/select.c | 34 +-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/fs/select.c b/fs/select.c
index a974082..50e6d8e 100644
--- a/fs/select.c
+++ b/fs/select.c
@@ -736,10 +736,29 @@ out_fds:
return err;
}
+long do_restart_poll(struct restart_block *restart_block)
+{
+ struct pollfd __user *ufds = (struct pollfd __user*)restart_block->arg0;
+ int nfds = restart_block->arg1;
+ s64 timeout = ((s64)restart_block->arg3<<32) | (s64)restart_block->arg2;
+ int ret;
+
+ restart_block->fn = do_no_restart_syscall;
+ ret = do_sys_poll(ufds, nfds, &timeout);
+ if (ret == -EINTR) {
+ restart_block->fn = do_restart_poll;
+ restart_block->arg2 = timeout & 0x;
+ restart_block->arg3 = timeout >> 32;
+ ret = -ERESTART_RESTARTBLOCK;
+ }
+ return ret;
+}
+
asmlinkage long sys_poll(struct pollfd __user *ufds, unsigned int nfds,
long timeout_msecs)
{
s64 timeout_jiffies;
+ int ret;
if (timeout_msecs > 0) {
#if HZ > 1000
@@ -754,7 +773,20 @@ asmlinkage long sys_poll(struct pollfd __user *ufds,
unsigned int nfds,
timeout_jiffies = timeout_msecs;
}
- return do_sys_poll(ufds, nfds, &timeout_jiffies);
+ ret = do_sys_poll(ufds, nfds, &timeout_jiffies);
+ if (ret == -EINTR) {
+ if (timeout_msecs > 0) {
+ struct restart_block *restart_block;
+ restart_block = ¤t_thread_info()->restart_block;
+ restart_block->fn = do_restart_poll;
+ restart_block->arg0 = (unsigned long)ufds;
+ restart_block->arg1 = nfds;
+ restart_block->arg2 = timeout_jiffies & 0x;
+ restart_block->arg3 = timeout_jiffies >> 32;
+ ret = -ERESTART_RESTARTBLOCK;
+ }
+ }
+ return ret;
}
#ifdef TIF_RESTORE_SIGMASK
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/23] per device dirty throttling -v8
* Linus Torvalds <[EMAIL PROTECTED]> wrote: > On Fri, 3 Aug 2007, Peter Zijlstra wrote: > > > > These patches aim to improve balance_dirty_pages() and directly address > > three > > issues: > > 1) inter device starvation > > 2) stacked device deadlocks > > 3) inter process starvation > > Ok, the patches certainly look pretty enough, and you fixed the only > thing I complained about last time (naming), so as far as I'm > concerned it's now just a matter of whether it *works* or not. I guess > being in -mm will help somewhat, but it would be good to have people > with several disks etc actively test this out. There are positive reports in the never-ending "my system crawls like an XT when copying large files" bugzilla entry: http://bugzilla.kernel.org/show_bug.cgi?id=7372 " vfs_cache_pressure=1 TCQ nr_requests 8 128not that bad 1 128snappiest configuration, almost no pauses (or unnoticable ones) " " 1) vfs_cache_pressure at 100, 2.6.21.5+per bdi throttling patch Result is good, not as snappier as I'd want during a large copy but still usable. No process seems stuck for agen, but there seems to be some short (second or subsecond) moment where everything is stuck (like if you run a top d 0.5, the screen is not updated on a regular basis). 2) vfs_cache_pressure at 1, 2.6.21.5+per bdi throttling patch Result is at 2.6.17 level. It is the better combination since 2.6.17. " " 1) I've applied the patches posted by Peter Zijlstra in comment #76 to the 2.6.21-mm2 kernel to check if it removes the problem. My impression is that the problem is still there with those patches, although less visible then with the clean 2.6.21 kernel. " so the whole problem area seems to be a "perfect storm" created by a combination of TCQ, IO scheduling and VM dirty handling weaknesses. Per device dirty throttling is a good step forward and it makes a very visible positive difference. 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: Oops in 2.6.23-rc1-git9, arch/x86_64/pci/k8-bus.c::fill_mp_bus_to_cpumask()
On Fri, Aug 03, 2007 at 03:50:35PM -0700, Andrew Morton wrote: > On Fri, 03 Aug 2007 18:10:03 -0400 > Chuck Ebbert <[EMAIL PROTECTED]> wrote: > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250859 > > > > at line 74: > > > > [EMAIL PROTECTED]: > > [EMAIL PROTECTED]: sd = bus->sysdata; > > [EMAIL PROTECTED]: sd->node = node; > > <= > > > > bus->sysdata is NULL. > > > > Last changed by this hunk of > > "x86-64: introduce struct pci_sysdata to facilitate sharing of ->sysdata": > > > > @@ -67,7 +69,9 @@ fill_mp_bus_to_cpumask(void) > > continue; > > if (!node_online(node)) > > node = 0; > > - bus->sysdata = (void *)node; > > + > > + sd = bus->sysdata; > > + sd->node = node; > > } > > } > > } > > > > Andy keeps trotting out a patch which will probably fix this, but > for some reason it doesn't seem to make progress. Hmm, looks like we're missing one of the paths where sd gets allocated. Andy can you please point me to the latest version of your patch? I recall thinking that it papers over the bug rather than fixing it but would like to take a second look. Thanks, Muli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ICH8 CF timeout (regression)...
Daniel J Blueman wrote: > Tejun, > > On 03/08/07, Tejun Heo <[EMAIL PROTECTED]> wrote: >> Daniel J Blueman wrote: >>> The ICH8 south-bridge I have is the mobile variant and does come >>> equipped with native parallel IDE - see page 447: >>> http://download.intel.com/design/chipsets/datashts/31305603.pdf . I do >>> see 35MB/s with DMA enabled from my CF on the 1 in 15 times the >>> libata-kernel does work. >>> >>> I can dump off and decode the configuration registers for the timing >>> and bus master registers in the working and non-working libata cases, >>> and the legacy ATA working case and see what's different. >> Does the attached patch change anything? > > This addresses the issue 100%! > > Due to the differences between the ICH8 non-mobile and mobile > variants, I've cooked the change into a new initialisation structure > for the ICH8M in the attached patch, if that helps at all. > > The changes thus affect (correct) behaviour on the ICH8M in IDE mode > only...so should be safe for inclusion. There may be a similar > situation with ICH9Ms also. [cc'ing Kristen, hello] I think [P0 P2 IDE IDE] is correct for MAP 01b but can't find anything about it in the datasheet or spec update. Kristen, can you please verify this. The following bug is also fixed by using [P0 P2 IDE IDE]. http://bugzilla.kernel.org/show_bug.cgi?id=8809 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: Linux 2.6.23-rc2
On 8/4/07, Jeff Chua <[EMAIL PROTECTED]> wrote: > On 8/4/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > After resume from s2ram or switching to console from X, my console is > messed up on rc1 and rc2. Is there a fix for this? This is on IBM X60. i915 chipset. No problem on 2.6.22. If this is a known problem, than I don't need to bisect all over again. Thanks, 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: [PATCH x86-64] Calgary - Fix mis-handled PCI topology
On Thu, 2 Aug 2007 16:39:26 +0300 Muli Ben-Yehuda <[EMAIL PROTECTED]> wrote: > Andrew, can you please push this Calgary bug-fix to 2.6.23 in your > next merge? it fixes a showstopper bug in the recently merged CalIOC2 > support that hits machines with multiple levels of PCI-to-PCI bridges. > > Thanks, > Muli > --- > From: Murillo Fernandes Bernardes <[EMAIL PROTECTED]> > Subject: x86-64: Calgary - Fix mis-handled PCI topology > > Current code assumed that devices were directly connected to a Calgary > bridge, as it tried to get the iommu table directly from the parent bus > controller. > > When we have another bridge between the Calgary/CalIOC2 bridge and the > device we should look upwards until we get to the top (Calgary/CalIOC2 > bridge), where the iommu table resides. > > Signed-off-by: Murillo Fernandes Bernardes <[EMAIL PROTECTED]> > Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]> > > -- > diff -ruN linux-2.6.23-rc1.orig/arch/x86_64/kernel/pci-calgary.c > linux-2.6.23-rc1/arch/x86_64/kernel/pci-calgary.c > --- linux-2.6.23-rc1.orig/arch/x86_64/kernel/pci-calgary.c2007-08-01 > 15:37:04.0 -0300 > +++ linux-2.6.23-rc1/arch/x86_64/kernel/pci-calgary.c 2007-08-01 > 15:48:55.0 -0300 > @@ -367,16 +367,15 @@ > > pdev = to_pci_dev(dev); > > - /* is the device behind a bridge? */ > - if (unlikely(pdev->bus->parent)) > - pbus = pdev->bus->parent; > - else > - pbus = pdev->bus; > + pbus = pdev->bus; > + > + /* is the device behind a bridge? Look for the root bus */ > + while (pbus->parent) > + pbus = pbus->parent; > > tbl = pci_iommu(pbus); > > - BUG_ON(pdev->bus->parent && > -(tbl->it_busno != pdev->bus->parent->number)); > + BUG_ON(tbl && (tbl->it_busno != pbus->number)); > > return tbl; > } > hmm, sorry, I missed the this-is-urgent factor. Andi, should I include this in my next batch to Linus? btw, my list of "patches which should be in 2.6.23 but go via subsystem maintainers" is presently dma_free_coherent-needs-irqs-enabled-sigh.patch usb-serial-fix-oti6858c-segfault-in-termios-handling.patch sparsemem-ensure-we-initialise-the-node-mapping-for-sparsemem_static.patch sparsemem-ensure-we-initialise-the-node-mapping-for-sparsemem_static-fix.patch tpmdd-maintainers.patch nfs-fix-put_nfs_open_context.patch make-oprofile-call-shutdown-only-once-per-session.patch perfctr_watchdog-do-not-bug_on-when-msr-is-unknown.patch acpi-bay-send-envp-with-uevent-fix.patch acpi-dock-send-key=value-pair-instead-of-plain-value.patch acpi_ec_remove-fix-use-after-free.patch acpi_battery_add-use-after-free.patch kernel-auditscc-fix-an-off-by-one.patch document-linux-memory-policy-v3.patch futex_unlock_pi-hurts-my-brain-and-may-cause.patch block-hide-the-contents-of-linux-bioh-if-config_block=n.patch cdc-acm-fix-sysfs-attribute-registration-bug.patch rtc-periodic-irq-fix.patch at91-include-atmel_lcdch-in-at91sam92613_devicesc.patch fix-local_irq_-macro-definition-thinkos-for-the-trace_irqflags_support-case.patch calgary-fix-mis-handled-pci-topology.patch several of which are x86-related. Please consider... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] request_firmware: skip timeout if userspace was not notified
On Fri, 3 Aug 2007, Javier Pello wrote: Hi, I have prepared a patch that makes request_firmware skip the usual grace period that it gives firmware images to show up, if it determines that userspace was not notified at all. When request_firmware is called, it sends an event to userspace to ask for the firmware image that is needed, and then it installs a timeout so that it will not wait forever for the image. However, if userspace did not receive the event at all (no /sbin/hotplug, for instance), then having the kernel wait is pointless. This is particularly true during boot, when the wait is done synchronously and the whole kernel freezes for a minute. The attached patch fixes this by making _request_firmware check whether the firmware loading event was succesfully sent to userspace, and skip the timeout if it has not. The patch comes in two parts: 1. The first part changes kobject_uevent_env in lib/kobject_uevent.c to report a failure if both netlink_broadcast (if applicable) and call_usermodehelper fail to send the event to userspace. Nothing in the kernel seems to care about the return value of kobject_uevent_env, so this should not break anything. 2. The second part changes _request_firmware in drivers/base/firmware_class.c to actually check the return value of kobject_uevent and skip the loading_timeout delay if the loading event was not delivered to userspace at all. The patches apply cleanly against 2.6.23-rc1. Any suggestions or feedback will be welcome. Javier PS Please CC: me on replies, as I am not subscribed to the list. I've been told that it's possible to have the kernel pull the firmware off of an initrd (or was it initramfs, I keep confusing the two) without having any userspace, just put the right file in the right place (unfortunantly I've never gotten around to testing this) will this patch break this feature? David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc2
On 8/4/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > A lot of the changes are small, and a lot of them really are fixes, but > there's a MIPS merge in there too, and some absolutely _huge_ diffs due to > some drivers undergoing Lindent cleanups (28 _thousand_ lines changes in > advansys.c, and the PNP files got Lindented too, although those weren't > nearly as big). After resume from s2ram or switching to console from X, my console is messed up on rc1 and rc2. Is there a fix for this? Thanks, 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: Vmware crashes if compress/misc.c scrolls?
H. Peter Anvin wrote:
I just got the following message on the syslinux mailing list:
2. On some platforms (vmware for example :), READING from the video memory
in the 32bit mode is impossible (causes an exeption). Taking in to account
that the scroll function in ilinux/arch/i386/boot/compressed/misc.c
works using a memcpy of the video memory, when the linux bootsector is given
control and the cursor is at the end of the screen (-1-2 lines) an exception
is
arisen and in the presence of it's handler in the bootloader the system
halts.
Both lilo and grub handle this situation - the cursor is always somewhere at
the
middle of the screen when the control is given to the linux bootsector.
When using pxelinux taking in to account that the PXE bios prints out the
presence of the second initramfs which causes the screen to scroll and the
bug
to appear :)
A very simple solution - the screen is cleared before giving control to the
linux bootsector (in the patch).
First of all, is this actually true? This seems like a monumental screwup.
Second, assuming it is true, what should be done about it? The notion
that the bootloader should erase the screen is ridiculous since we spend
a lot of effort maintaining the screen context from 16-bit code.
I see a couple of options:
a. Do nothing. It's a Vmware bug, let the users bug Vmware and get an
updated version.
b. Detect Vmware versions that are affected (how?) and suppress output.
c. Don't attempt to scroll in this code, and instead wrap around the
screen (presumably clearing the rest of the line.)
d. Blindly assume hardware scrolling works, instead of doing
copy-to-scroll. Although I have seen craptops on which hardware
scrolling is broken, it's hardly critical messages we're dealing with
here. A bug for a bug...
Sorry it took me so long to follow up on this.
It's not a VMware bug. Video memory operates just fine under VMware.
This led me to put the bug on the back-burner.
Today it came back to the front, and I did some investigation. It's
also not a syslinux bug, although it is triggered by syslinux.
Depending on how much information is on the screen, you can trigger a
Linux bug caused by a compiler problem.
In the boot decompressor for the kernel in the image Iouri provided, I
find the following code present in memory before the first kernel
instruction executes:
Here is Linux function scroll, which calls memcpy to scroll vga memory:
0x104131 : mov%edx,0x4(%esp,1)
0x104135 : mov%ecx,(%esp,1)
0x104138 : mov%eax,0x8(%esp,1)
0x10413c : call 0x1040d0
Here is Linux function memcpy:
(gdb) x/40i 0x1040d0
0x1040d0 : push %ebp
0x1040d1 : test %ecx,%ecx
0x1040d3 : mov%esp,%ebp
0x1040d5 : push %edi
0x1040d6 : mov%eax,%edi
0x1040d8 : push %esi
0x1040d9 : mov%edx,%esi
0x1040db : push %ebx
0x1040dc : mov%ecx,%ebx
0x1040de : je 0x1040f4
0x1040e0 : xor%ecx,%ecx
0x1040e2 : xor%edx,%edx
0x1040e4 : movzbl (%esi,%edx,1),%eax
0x1040e8 : add$0x1,%ecx
0x1040eb : cmp%ebx,%ecx
0x1040ed : mov%al,(%edi,%edx,1)
0x1040f0 : mov%ecx,%edx
0x1040f2 : jne0x1040e4
0x1040f4 : mov%edi,%eax
0x1040f6 : pop%ebx
0x1040f7 : pop%esi
0x1040f8 : pop%edi
0x1040f9 : pop%ebp
0x1040fa : ret
As you can plainly see, the call to memcpy (which is redefined in
boot/compressed/misc.c) is made using stack calling convention.
Unfortunately, the compiler generated the memcpy function itself using
regparm(3) convention. I am guessing this happened because a leftover
prototype declaring memcpy as regparm got pulled in from somewhere, but
gcc ignored it in the callsite because the function was declared static
in the same file.
The net result of this is the parameters to memcpy get swapped, causing
a memcpy from 0xb80a0 to destination (in register edx, 80x24 * 2) 0xa00,
of size 0xb8000.
This corrupts all usable memory below 640k, including the GDT which is
currently loaded.
But since the compressed kernel is running in high memory, above 1Mb,
the kernel is fine. The compress loader head.S then proceeds to copy
the move routine to address 0x11000, and executes the following instruction:
ljmp $(__KERNEL_CS), $0x1000 # and jump to the move routine
This reloads CS descriptor from the GDT, which is now garbage, and
contains an invalid segment. The ljmp then generates a #GP. Since
there is no IDT setup to handle the GDT (and even if there were, the
destination CS would again be reloaded, causing a fault), a double fault
is generated. Since the double-fault also hits the same problem, the
machine then triple faults and proceeds to reboot.
Since the SCREEN_INFO passed to the kernel in the bad case has orig_y is
set to 22, when we print 3 newlines:
putstr(".\nDecompressing Linux...");
Re: renaming kernel devices [was: VIA EPIA EK: strange eth dev numbering]
On Fri, 3 Aug 2007, Stefan Richter wrote: [EMAIL PROTECTED] wrote: On Thu, 2 Aug 2007, Ondrej Zajicek wrote: On Thu, Aug 02, 2007 at 01:47:23PM +0200, Jan Engelhardt wrote: It does not rename ethX to the "next free" one, but to a _persistent_ one. If it were a "next free" thing, then removing a card would shuffle all your eth around again (and invalidate your iptables rules at the same time, to note). It is questionable what is _persistent_ . MAC-based names are persistent with regard to adding and removing of other cards, 'Plain' names are persistent with regard to replacing that card with different item (of a same kind). I am very happy that (using 'plain' names) i can send technician to replace broken NIC in our routers without need for configuration change. this is a very important point, and with the distros (and many kernel people) treating udev as a requirement this is going to bite a lot of people. Two notes: 1. Udev doesn't restrict you to any one naming scheme. If you want something else than a MAC based scheme, e.g. a PCI topology based scheme, udev most certainly can do that for you. But the kernel can't. 2. Consider udev a kernel extension in userspace, with the benefit of configurability and scriptability, features that kernel extensions in kernelspace can't offer. Of course this gain of features doesn't come at zero cost: You need a minimal userspace environment at boot time. Quoting myself from http://marc.info/?l=linux-scsi&m=118613786003162: There is a variety of possible naming schemes: - Naming by order of discovery. - Naming by vendor/model name strings. - Naming by universally unique identifier. - Naming by topology. - ... Only the simplest of these schemes (naming by order of discovery) is hardwired into the kernel portion of the Linux OS. The other naming schemes are (or can be) implemented in the userland portion of the Linux OS. There is only the most primitive naming scheme implemented in the kernel because naming policy, like most other kinds of policy, is better left to userland. The kernel is a too restricted framework to implement such things. The kernel lacks runtime-configuration files, scripting interfaces, et cetera. I understand the flexibility that this provides, unfortunantly (IMHO) default udev rules (or at least what many distros are shipping by default) changes from this simple naming scheme in a way that hides the fact from the user. This means that many users will not even realize the change in policy until the hardware changes and things don't act the way they were expected to. In my case it was removing 3 quad cards from a machine and finding that there was no eth0 on the box, instead there was a eth12, this is fairly benign. what would have caused me significant problems would have been having a card fail in a production box, have it replaced and then found that the interfaces were now eth4-eth22 instead of eth0-eth18. having the interfaces named differently on different boxes with identical hardware based on the history of what has been plugged into the boxes in the past is not what sysadmins expect. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc2
On Fri, 3 Aug 2007, Linus Torvalds wrote: So I tried to hold people to the merge window, and said no to a few pull requests, but this whole "-rc2 is the new -rc1" thing is a disease, and not only is -rc2 late, it's bigger than it should be. Oh, well. I don't think this is new, -rc1 has always been a mid-merge sync point as much as (or more then) a release candidate. I can't think of any -rc2s that haven't included fairly significant merges since -rc1. now some of the -rc1s have been more useable then others, and this series does look like it's going to be rougher and longer then most (due in large part to the scheduler changes), but it's more a difference in degree then in type. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pci_get_device call from interrupt in reboot fixups
On Fri, Aug 03, 2007 at 02:39:24PM +0400, Denis V. Lunev wrote: > The following calltrace is possible now: > handle_sysrq >machine_emergency_restart > mach_reboot_fixups >pci_get_device > pci_get_subsys > down_read > The patch obtains PCI device during initialization to avoid bothering PCI > search engine in interrupt. Devices used in this code are not supposed to > be pluggable, so it looks safe to keep them. What devices are supposed to be affected here? Are you sure that they can't be removed later? Grabbing references here might mess with them in the future. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM: Fix dependencies of CONFIG_SUSPEND and CONFIG_HIBERNATION
On Friday 03 August 2007 18:47, Rafael J. Wysocki wrote: > On Saturday, 4 August 2007 00:01, Linus Torvalds wrote: > > > > On Fri, 3 Aug 2007, Rafael J. Wysocki wrote: > > > depends on PM > > > - depends on !SMP || SUSPEND_SMP_POSSIBLE > > > + depends on SUSPEND_SMP_POSSIBLE || ((BLACKFIN || MIPS || SUPERH || FRV \ > > > + || (PPC32 && PPC_MPC52xx)) && !SMP) > > > > Please, do that as SUSPEND_UP_POSSIBLE, and make it look like > > > > config SUSPEND_UP_POSSIBLE > > depends on BLACKFIN || MIPS || SUPERH || FRV || ((PPC32 && > > PPC_MPC52xx) > > depends on !SMP > > default y > > OK > > > and now you can write the above thing as > > > > depends on SUSPEND_SMP_POSSIBLE || SUSPEND_UP_POSSIBLE > > > > and it's all much nicer. > > > > I would say that doing a similar setup for HIBERNATE would be nice too, > > but the SUSPEND case is more noticeable because the SMP case is so nice > > already. > > I did it symmetrically for suspend and hibernation and renamed SUSPEND_SMP to > PM_SLEEP_SMP. Patch follows. > > Greetings, > Rafael > > > --- > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > Dependencies of CONFIG_SUSPEND and CONFIG_HIBERNATION introduced by commit > 296699de6bdc717189a331ab6bbe90e05c94db06 "Introduce CONFIG_SUSPEND for > suspend-to-Ram and standby" are incorrect, as they don't cover the facts that > (1) not all architectures support suspend and (2) SMP hibernation is only > possible on X86 and PPC64 (if PPC64_SWSUSP is set). > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > --- > kernel/power/Kconfig | 40 ++-- > 1 file changed, 30 insertions(+), 10 deletions(-) > > Index: linux-2.6/kernel/power/Kconfig > === > --- linux-2.6.orig/kernel/power/Kconfig 2007-07-30 07:58:48.0 > +0200 > +++ linux-2.6/kernel/power/Kconfig2007-08-04 00:39:21.0 +0200 > @@ -72,15 +72,10 @@ config PM_TRACE > CAUTION: this option will cause your machine's real-time clock to be > set to an invalid time after a resume. > > -config SUSPEND_SMP_POSSIBLE > - bool > - depends on (X86 && !X86_VOYAGER) || (PPC64 && (PPC_PSERIES || PPC_PMAC)) > - depends on SMP > - default y > - > -config SUSPEND_SMP > +config PM_SLEEP_SMP > bool > - depends on SUSPEND_SMP_POSSIBLE && PM_SLEEP > + depends on SUSPEND_SMP_POSSIBLE || HIBERNATION_SMP_POSSIBLE > + depends on PM_SLEEP > select HOTPLUG_CPU > default y > > @@ -89,20 +84,45 @@ config PM_SLEEP > depends on SUSPEND || HIBERNATION > default y > > +config SUSPEND_UP_POSSIBLE > + bool > + depends on BLACKFIN || MIPS || SUPERH || FRV || (PPC32 && PPC_MPC52xx) please include (X86 && !X86_VOYAGER) here -- else you'll disable SUSPEND from all X86 when built UP. thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION] tg3 dead after s2ram
From: "Michael Chan" <[EMAIL PROTECTED]> Date: Thu, 02 Aug 2007 12:10:29 -0700 > [TG3]: Fix suspend/resume problem. > > Joachim Deguara <[EMAIL PROTECTED]> reported that tg3 devices > would not resume properly if the device was shutdown before the system > was suspended. In such scenario where the netif_running state is 0, > tg3_suspend() would not save the PCI state and so the memory enable bit > and bus master enable bit would be lost. > > We fix this by always saving and restoring the PCI state in > tg3_suspend() and tg3_resume() regardless of netif_running() state. > > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> Patch applied. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.6.23-rc2
So I tried to hold people to the merge window, and said no to a few pull requests, but this whole "-rc2 is the new -rc1" thing is a disease, and not only is -rc2 late, it's bigger than it should be. Oh, well. A lot of the changes are small, and a lot of them really are fixes, but there's a MIPS merge in there too, and some absolutely _huge_ diffs due to some drivers undergoing Lindent cleanups (28 _thousand_ lines changes in advansys.c, and the PNP files got Lindented too, although those weren't nearly as big). But if you ignore the Lindent changes, the MIPS merge, the lguest documentation updates, and the MPT fusion driver changes, and the removal of the broken arm26 support, the rest of the changes really aren't that big. But there's still a lot of those mostly small things all over. And the ShortLog is too large to post. But the full log along with the customary tar-balls and patches are out there on kernel.org. And as usual, the git tree gives you the goods if you just do git shortlog v2.6.23-rc1.. (the most interesting statistic from there is that we apparently had more than 250 people involved in just the -rc1 to -rc2 timeframe. Impressively spread out, in other words) 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: Documentation of kernel messages (Summary)
On Fri, Aug 03, 2007 at 03:32:04PM -0400, Rob Landley wrote: > > These days I'm trying to create an html index that links into Documentation > in > a coherent order (with categories and everything), and using automated tools > to detect files that aren't linked to, or links that point to a file that > isn't there anymore. This is obviously still a work in progress, but I think > it's a better approach. Better than cleaning up what we have in the kernel source tree? Why not work on that first, then the "automated" type stuff would be much easier to do later, right? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation of kernel messages (Summary)
On Fri, Aug 03, 2007 at 03:32:04PM -0400, Rob Landley wrote: > On Friday 03 August 2007 1:11:55 pm Randy Dunlap wrote: > > On Mon, 16 Jul 2007 15:53:06 -0400 Rob Landley wrote: > > > On Sunday 15 July 2007 12:28:06 pm Randy Dunlap wrote: > > > > On Sat, 14 Jul 2007 21:56:15 -0400 Rob Landley wrote: > > > > > On Friday 13 July 2007 11:54:41 pm Randy Dunlap wrote: > > > > > > > If there's interest, I can push some patches to clean up > > > > > > > Documentation by moving files into subdirectories, but > > > > > > > Documentation's not well-suited to link out to the web. (You > > > > > > > need html for that, and it's text.) > > > > > > > > > > > > I think that you should start moving Documentation/ files around > > > > > > and adding subdirectories -- if you are pretty sure of where they > > > > > > should go (i.e., they won't likely be moved again later on). > > > > > > > > > > You mean like these? > > > > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0705.3/2925.html > > > > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0705.3/2924.html > > > > > > > > Yes. Have any of these been merged? > > > > > > Not that I know of. They seemed to meet with resounding indifference, so > > > I went on to other things... > > > > You need to be persistent. Please re-submit this. > > Greg KH thinks it's a good idea to add language directories to the top level > of Documentation, and there are slightly more than two of those: > http://www.translatorscafe.com/cafe/Help.asp?HelpID=59 > > Since you think it's worth doing, I'll resubmit the work I've already done > here, but I no longer think trying to shovel Documentation into some > semblance of order against the will of people like Greg is a good use of > time. My "will" is only that some of these documents be translated _and_ put in the main kernel source tree. I really have no opinion on where they need to go within that directory. If you have a better place for them, please let me know. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Distributed storage.
On 8/4/07, Dave Dillow <[EMAIL PROTECTED]> wrote: > On Fri, 2007-08-03 at 09:04 +0400, Manu Abraham wrote: > > On 7/31/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > > > TODO list currently includes following main items: > > > * redundancy algorithm (drop me a request of your own, but it is > > > highly > > > unlikley that Reed-Solomon based will ever be used - it is too > > > slow > > > for distributed RAID, I consider WEAVER codes) > > > > > > LDPC codes[1][2] have been replacing Turbo code[3] with regards to > > communication links and we have been seeing that transition. (maybe > > helpful, came to mind seeing the mention of Turbo code) Don't know how > > weaver compares to LDPC, though found some comparisons [4][5] But > > looking at fault tolerance figures, i guess Weaver is much better. > > > > [1] http://www.ldpc-codes.com/ > > [2] http://portal.acm.org/citation.cfm?id=1240497 > > [3] http://en.wikipedia.org/wiki/Turbo_code > > [4] > > http://domino.research.ibm.com/library/cyberdig.nsf/papers/BD559022A190D41C85257212006CEC11/$File/rj10391.pdf > > [5] http://hplabs.hp.com/personal/Jay_Wylie/publications/wylie_dsn2007.pdf > > Searching Google for Dr. Plank's work at the University of TN turns up > some analysis of using LDPC codes in storage systems. > > http://www.google.com/search?hl=en&q=plank+ldpc&btnG=Google+Search > > Patents are an issue to watch out for around the use of Tornado/Raptor > codes. I've not researched it, but I believe there be dragons there. > We don't use the code in the driver straight away [2] (in the case that i mentioned), since that happens in the hardware (demodulator chip) [1], but we have an interface for selecting the code-rate [2] (LDPC/BCH) for DVB-S2 and the new papers for DVB-T2 looks geared that the base decision is to use LDPC. Though i now see a patent application for it [3]. Not sure whether it is a registered patent, i am under an agreement of Non-Disclosure with STM. Will ask the relevant person there, whether they have it registered. (Most probably they may have it registered). There are a few people from STM on LK, if not they can possibly confirm whether the patent is regsitered or not. [1] http://www2.dac.com/data2/42nd/42acceptedpapers.nsf/0c4c09c6ffa905c487256b7b007afb72/998f93e4b29e99fa87256fc400714617/$FILE/33_1.pdf [2] http://linuxtv.org/hg/~manu/stb0899-c5/file/760cb230695c/linux/include/linux/dvb/frontend.h [3] http://www.freepatentsonline.com/20060206779.html http://www.freepatentsonline.com/20060206778.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] sched: Simplify move_tasks()
The move_tasks() function is currently multiplexed with two distinct
capabilities:
1. attempt to move a specified amount of weighted load from one run
queue to another; and
2. attempt to move a specified number of tasks from one run queue to
another.
The first of these capabilities is used in two places, load_balance()
and load_balance_idle(), and in both of these cases the return value of
move_tasks() is used purely to decide if tasks/load were moved and no
notice of the actual number of tasks moved is taken.
The second capability is used in exactly one place,
active_load_balance(), to attempt to move exactly one task and, as
before, the return value is only used as an indicator of success or failure.
This multiplexing of sched_task() was introduced, by me, as part of the
smpnice patches and was motivated by the fact that the alternative, one
function to move specified load and one to move a single task, would
have led to two functions of roughly the same complexity as the old
move_tasks() (or the new balance_tasks()). However, the new modular
design of the new CFS scheduler allows a simpler solution to be adopted
and this patch addresses that solution by:
1. adding a new function, move_one_task(), to be used by
active_load_balance(); and
2. making move_tasks() a single purpose function that tries to move a
specified weighted load and returns 1 for success and 0 for failure.
One of the consequences of these changes is that neither move_one_task()
or the new move_tasks() care how many tasks sched_class.load_balance()
moves and this enables its interface to be simplified by returning the
amount of load moved as its result and removing the load_moved pointer
from the argument list. This helps simplify the new move_tasks() and
slightly reduces the amount of work done in each of
sched_class.load_balance()'s implementations.
Further simplification, e.g. changes to balance_tasks(), are possible
but (slightly) complicated by the special needs of load_balance_fair()
so I've left them to a later patch (if this one gets accepted).
NB Since move_tasks() gets called with two run queue locks held even
small reductions in overhead are worthwhile.
Signed-off-by: Peter Williams <[EMAIL PROTECTED]>
--
Peter Williams [EMAIL PROTECTED]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
diff -r b97e7dab8f7b include/linux/sched.h
--- a/include/linux/sched.h Thu Aug 02 14:08:53 2007 -0700
+++ b/include/linux/sched.h Fri Aug 03 15:56:41 2007 +1000
@@ -866,11 +866,11 @@ struct sched_class {
struct task_struct * (*pick_next_task) (struct rq *rq, u64 now);
void (*put_prev_task) (struct rq *rq, struct task_struct *p, u64 now);
- int (*load_balance) (struct rq *this_rq, int this_cpu,
+ unsigned long (*load_balance) (struct rq *this_rq, int this_cpu,
struct rq *busiest,
unsigned long max_nr_move, unsigned long max_load_move,
struct sched_domain *sd, enum cpu_idle_type idle,
- int *all_pinned, unsigned long *total_load_moved);
+ int *all_pinned);
void (*set_curr_task) (struct rq *rq);
void (*task_tick) (struct rq *rq, struct task_struct *p);
diff -r b97e7dab8f7b kernel/sched.c
--- a/kernel/sched.c Thu Aug 02 14:08:53 2007 -0700
+++ b/kernel/sched.c Sat Aug 04 10:06:42 2007 +1000
@@ -2231,32 +2231,49 @@ out:
}
/*
- * move_tasks tries to move up to max_nr_move tasks and max_load_move weighted
- * load from busiest to this_rq, as part of a balancing operation within
- * "domain". Returns the number of tasks moved.
+ * move_tasks tries to move up to max_load_move weighted load from busiest to
+ * this_rq, as part of a balancing operation within domain "sd".
+ * Returns 1 if successful and 0 otherwise.
*
* Called with both runqueues locked.
*/
static int move_tasks(struct rq *this_rq, int this_cpu, struct rq *busiest,
- unsigned long max_nr_move, unsigned long max_load_move,
+ unsigned long max_load_move,
struct sched_domain *sd, enum cpu_idle_type idle,
int *all_pinned)
{
struct sched_class *class = sched_class_highest;
- unsigned long load_moved, total_nr_moved = 0, nr_moved;
- long rem_load_move = max_load_move;
+ unsigned long total_load_moved = 0;
do {
- nr_moved = class->load_balance(this_rq, this_cpu, busiest,
-max_nr_move, (unsigned long)rem_load_move,
-sd, idle, all_pinned, &load_moved);
- total_nr_moved += nr_moved;
- max_nr_move -= nr_moved;
- rem_load_move -= load_moved;
+ total_load_moved +=
+ class->load_balance(this_rq, this_cpu, busiest,
+ULONG_MAX, max_load_move - total_load_moved,
+sd, idle, all_pinned);
class = class->next;
- } while (class && max_nr_move && rem_load_move > 0);
-
- return total_nr_moved;
+ } while (class && max_load_move > total_load_moved);
+
+ return total_load_moved > 0;
+}
+
+/*
+ * move_one_task tries to move exactly one task from busiest to this_rq, as
+ * part of active balancing oper
Re: [PATCH] SH: add machine-ops and Dreamcast specific fix-up
On Fri, Aug 03, 2007 at 08:26:17PM +0100, Adrian McMenamin wrote:
> diff --git a/arch/sh/boards/dreamcast/Makefile
> b/arch/sh/boards/dreamcast/Makefile
> index e6fcd3d..7b97546 100644
> --- a/arch/sh/boards/dreamcast/Makefile
> +++ b/arch/sh/boards/dreamcast/Makefile
> @@ -2,5 +2,5 @@
> # Makefile for the Sega Dreamcast specific parts of the kernel
> #
>
> -obj-y := setup.o irq.o rtc.o reboot.o
> +obj-y := setup.o irq.o rtc.o
>
You've created this diff against a bogus kernel.
> diff --git a/arch/sh/kernel/Makefile b/arch/sh/kernel/Makefile
> index bdb30ba..7ab2359 100644
> --- a/arch/sh/kernel/Makefile
> +++ b/arch/sh/kernel/Makefile
> @@ -5,15 +5,11 @@
> extra-y := head.o init_task.o vmlinux.lds
>
> obj-y:= debugtraps.o io.o io_generic.o irq.o machvec.o process.o
> ptrace.o \
> -semaphore.o setup.o signal.o sys_sh.o syscalls.o \
> +reboot.o semaphore.o setup.o signal.o sys_sh.o syscalls.o \
> time.o topology.o traps.o
>
> obj-y+= cpu/ timers/
>
> -ifneq ($(CONFIG_SH_DREAMCAST),y)
> - obj-y += reboot.o
> -endif
> -
> obj-$(CONFIG_VSYSCALL) += vsyscall/
>
> obj-$(CONFIG_SMP)+= smp.o
> diff --git a/arch/sh/kernel/machine_kexec.c b/arch/sh/kernel/machine_kexec.c
> index 790ed69..201b370 100644
> --- a/arch/sh/kernel/machine_kexec.c
> +++ b/arch/sh/kernel/machine_kexec.c
> @@ -29,9 +29,6 @@ extern const unsigned char relocate_new_kernel[];
> extern const unsigned int relocate_new_kernel_size;
> extern void *gdb_vbr_vector;
>
> -void machine_shutdown(void)
> -{
> -}
>
> void machine_crash_shutdown(struct pt_regs *regs)
> {
You've missed machine_crash_shutdown().
> +static void mach_reboot_fixups(void)
> +{
> + if (mach_is_dreamcast()) {
> + writel(0x7611, 0xA05F6890);
> + }
> +}
> +
Whether it's only the dreamcast or not is irrelevant, why bother adding
abstraction if you intend to add pointless hacks that completely
side-steps it?
> diff --git a/include/asm-sh/emergency-restart.h
> b/include/asm-sh/emergency-restart.h
> index 108d8c4..d6bec92 100644
> --- a/include/asm-sh/emergency-restart.h
> +++ b/include/asm-sh/emergency-restart.h
> @@ -1,6 +1,6 @@
> -#ifndef _ASM_EMERGENCY_RESTART_H
> -#define _ASM_EMERGENCY_RESTART_H
> +#ifndef _ASM_SH_EMERGENCY_RESTART_H
> +#define _ASM_SH_EMERGENCY_RESTART_H
>
> -#include
> +extern void machine_emergency_restart(void);
>
> -#endif /* _ASM_EMERGENCY_RESTART_H */
> +#endif /* _ASM_SH_EMERGENCY_RESTART_H */
>
Pointless. Separating out machine_emergency_restart() buys us nothing,
leave this alone and just kill it off from the machine_ops entirely.
You've also ignored my earlier mail where I suggested this and killing
off some of the other ops we had no use for (as well as consolidating
machine_crash_shutdown()). I do wish you would read these things and wait
until there's been a resolution one way or another.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Categorize GFP flags
The function of GFP_LEVEL_MASK seems to be unclear. In order to clear up the mystery we get rid of it and replace GFP_LEVEL_MASK with 3 sets of GFP flags: GFP_RECLAIM_MASKFlags used to control page allocator reclaim behavior. GFP_CONSTRAINT_MASK Flags used to limit where allocations can occur. GFP_SLAB_BUG_MASK Flags that the slab allocator BUG()s on. These replace the uses of GFP_LEVEL mask in the slab allocators and in vmalloc.c. The use of the flags not included in these sets may occur as a result of a slab allocation standing in for a page allocation when constructing scatter gather lists. Extraneous flags are cleared and not passed through to the page allocator. __GFP_MOVABLE/RECLAIMABLE, __GFP_COLD and __GFP_COMP will now be ignored if passed to a slab allocator. Change the allocation of allocator meta data in SLAB and vmalloc to not pass through flags listed in GFP_CONSTRAINT_MASK. SLAB already removes the __GFP_THISNODE flag for such allocations. Generalize that to also cover vmalloc. The use of GFP_CONSTRAINT_MASK also includes __GFP_HARDWALL. The impact of allocator metadata placement on access latency to the cachelines of the object itself is minimal since metadata is only referenced on alloc and free. The attempt is still made to place the meta data optimally but we consistently allow fallback both in SLAB and vmalloc (SLUB does not need to allocate metadata like that). Allocator metadata may serve multiple in kernel users and thus should not be subject to the limitations arising from a single allocation context. Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- include/linux/gfp.h | 23 +-- mm/slab.c |6 +++--- mm/slub.c |5 +++-- mm/vmalloc.c|5 +++-- 4 files changed, 22 insertions(+), 17 deletions(-) Index: linux-2.6.23-rc1-mm2/include/linux/gfp.h === --- linux-2.6.23-rc1-mm2.orig/include/linux/gfp.h 2007-08-03 18:55:29.0 -0700 +++ linux-2.6.23-rc1-mm2/include/linux/gfp.h2007-08-03 19:21:07.0 -0700 @@ -54,16 +54,6 @@ struct vm_area_struct; #define __GFP_BITS_SHIFT 21/* Room for 21 __GFP_FOO bits */ #define __GFP_BITS_MASK ((__force gfp_t)((1 << __GFP_BITS_SHIFT) - 1)) -/* if you forget to add the bitmask here kernel will crash, period */ -#define GFP_LEVEL_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_FS| \ - __GFP_COLD|__GFP_NOWARN|__GFP_REPEAT| \ - __GFP_NOFAIL|__GFP_NORETRY|__GFP_COMP| \ - __GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_THISNODE| \ - __GFP_RECLAIMABLE|__GFP_MOVABLE) - -/* This mask makes up all the page movable related flags */ -#define GFP_MOVABLE_MASK (__GFP_RECLAIMABLE|__GFP_MOVABLE) - /* This equals 0, but use constants in case they ever change */ #define GFP_NOWAIT (GFP_ATOMIC & ~__GFP_HIGH) /* GFP_ATOMIC means both !wait (__GFP_WAIT not set) and use emergency pool */ @@ -92,6 +82,19 @@ struct vm_area_struct; #define GFP_THISNODE ((__force gfp_t)0) #endif +/* This mask makes up all the page movable related flags */ +#define GFP_MOVABLE_MASK (__GFP_RECLAIMABLE|__GFP_MOVABLE) + +/* Control page allocator reclaim behavior */ +#define GFP_RECLAIM_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_FS|\ + __GFP_NOWARN|__GFP_REPEAT|__GFP_NOFAIL|\ + __GFP_NORETRY|__GFP_NOMEMALLOC) + +/* Control allocation constraints */ +#define GFP_CONSTRAINT_MASK (__GFP_HARDWALL|__GFP_THISNODE) + +/* Do not use these with a slab allocator */ +#define GFP_SLAB_BUG_MASK (__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK) /* Flag - indicates that the buffer will be suitable for DMA. Ignored on some platforms, used as appropriate on others */ Index: linux-2.6.23-rc1-mm2/mm/slab.c === --- linux-2.6.23-rc1-mm2.orig/mm/slab.c 2007-08-03 18:55:27.0 -0700 +++ linux-2.6.23-rc1-mm2/mm/slab.c 2007-08-03 18:55:45.0 -0700 @@ -2768,9 +2768,9 @@ static int cache_grow(struct kmem_cache * Be lazy and only check for valid flags here, keeping it out of the * critical path in kmem_cache_alloc(). */ - BUG_ON(flags & ~(GFP_DMA | __GFP_ZERO | GFP_LEVEL_MASK)); + BUG_ON(flags & GFP_SLAB_BUG_MASK); + local_flags = (flags & (GFP_CONSTRAINT_MASK|GFP_RECLAIM_MASK)); - local_flags = (flags & GFP_LEVEL_MASK); /* Take the l3 list lock to change the colour_next on this node */ check_irq_off(); l3 = cachep->nodelists[nodeid]; @@ -2807,7 +2807,7 @@ static int cache_grow(struct kmem_cache /* Get slab management. */ slabp = alloc_slabmgmt(cachep, objp, offset, - local_flags & ~GFP_THISNODE, nodeid); + local_flags & ~GFP_CONSTRAINT_MASK, nodeid); if (!slabp) goto
Re: [PATCH] msleep() with hrtimers
Hi, On Fri, 3 Aug 2007, Arjan van de Ven wrote: > > Actually the hrsleep() function would allow for submillisecond sleeps, > > which might be what some of the 450 users really want and they only use > > msleep(1) because it's the next best thing. > > A hrsleep() function is really what makes most sense from an API > > perspective. > > I respectfully disagree. The power of msleep is that the unit of sleep > time is in the name; so in your proposal it would be hr_msleep or > somesuch. I much rather do the opposite in that case; make the "short" > name be the best implementation of the requested behavior, and have > qualifiers for allowing exceptions to that... least surprise and all > that. hr_msleep makes no sense. Why should we tie this interface to millisecond resolution? Your suggested msleep_approx makes not much sense to me either, since neither interface guarantees anything and may "approximate" the sleep (and if the user is surprised by that something else already went wrong). If you don't like the hrsleep name, we can also call it nanosleep and so match what we already do for userspace. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Distributed storage.
On Fri, 2007-08-03 at 09:04 +0400, Manu Abraham wrote: > On 7/31/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > TODO list currently includes following main items: > > * redundancy algorithm (drop me a request of your own, but it is highly > > unlikley that Reed-Solomon based will ever be used - it is too slow > > for distributed RAID, I consider WEAVER codes) > > > LDPC codes[1][2] have been replacing Turbo code[3] with regards to > communication links and we have been seeing that transition. (maybe > helpful, came to mind seeing the mention of Turbo code) Don't know how > weaver compares to LDPC, though found some comparisons [4][5] But > looking at fault tolerance figures, i guess Weaver is much better. > > [1] http://www.ldpc-codes.com/ > [2] http://portal.acm.org/citation.cfm?id=1240497 > [3] http://en.wikipedia.org/wiki/Turbo_code > [4] > http://domino.research.ibm.com/library/cyberdig.nsf/papers/BD559022A190D41C85257212006CEC11/$File/rj10391.pdf > [5] http://hplabs.hp.com/personal/Jay_Wylie/publications/wylie_dsn2007.pdf Searching Google for Dr. Plank's work at the University of TN turns up some analysis of using LDPC codes in storage systems. http://www.google.com/search?hl=en&q=plank+ldpc&btnG=Google+Search Patents are an issue to watch out for around the use of Tornado/Raptor codes. I've not researched it, but I believe there be dragons there. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] DMA engine kconfig improvements
On 7/25/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Wed, Jul 25, 2007 at 04:03:04AM -0700, Andrew Morton wrote: > >... > > Changes since 2.6.22-rc6-mm1: > >... > > +dma-arch-fix.patch > > > > Fix git-dma.patch > >... > > This results in an ARM-only driver in an X86-only menu... > > What about the patch below instead that also improves a few other things? I like it, just a few nits: > -menu "DMA Engine support" > - depends on HAS_DMA > +menuconfig DMADEVICES > + bool "DMA Engine support" > + depends on (PCI && X86) || ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX > + help > + Intel(R) DMA engines > + Perhaps we should go ahead and define ARCH_HAS_DMA_OFFLOAD and have DMADEVICES depend on that option. A ppc32 driver is in the works: http://marc.info/?l=linux-raid&m=117400143317440&w=2 > +if DMADEVICES > + > +comment "DMA Devices" > + > +config INTEL_IOATDMA > + tristate "Intel I/OAT DMA support" > + depends on PCI && X86 > + select DMA_ENGINE > + select DCA > + help > + Enable support for the Intel(R) I/OAT DMA engine present > + in recent Intel Xeon CPUs. > + > + Say yes if you have such a CPU. It is actually in recent chipsets, not the CPU, but yes the user should have more help making this decision. Regards, Dan (for Shannon while he is on vacation) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Distributed storage.
On Friday 03 August 2007 03:26, Evgeniy Polyakov wrote: > On Thu, Aug 02, 2007 at 02:08:24PM -0700, I wrote: > > I see bits that worry me, e.g.: > > > > + req = mempool_alloc(st->w->req_pool, GFP_NOIO); > > > > which seems to be callable in response to a local request, just the > > case where NBD deadlocks. Your mempool strategy can work reliably > > only if you can prove that the pool allocations of the maximum > > number of requests you can have in flight do not exceed the size of > > the pool. In other words, if you ever take the pool's fallback > > path to normal allocation, you risk deadlock. > > mempool should be allocated to be able to catch up with maximum > in-flight requests, in my tests I was unable to force block layer to > put more than 31 pages in sync, but in one bio. Each request is > essentially dealyed bio processing, so this must handle maximum > number of in-flight bios (if they do not cover multiple nodes, if > they do, then each node requires own request). It depends on the characteristics of the physical and virtual block devices involved. Slow block devices can produce surprising effects. Ddsnap still qualifies as "slow" under certain circumstances (big linear write immediately following a new snapshot). Before we added throttling we would see as many as 800,000 bios in flight. Nice to know the system can actually survive this... mostly. But memory deadlock is a clear and present danger under those conditions and we did hit it (not to mention that read latency sucked beyond belief). Anyway, we added a simple counting semaphore to throttle the bio traffic to a reasonable number and behavior became much nicer, but most importantly, this satisfies one of the primary requirements for avoiding block device memory deadlock: a strictly bounded amount of bio traffic in flight. In fact, we allow some bounded number of non-memalloc bios *plus* however much traffic the mm wants to throw at us in memalloc mode, on the assumption that the mm knows what it is doing and imposes its own bound of in flight bios per device. This needs auditing obviously, but the mm either does that or is buggy. In practice, with this throttling in place we never saw more than 2,000 in flight no matter how hard we hit it, which is about the number we were aiming at. Since we draw our reserve from the main memalloc pool, we can easily handle 2,000 bios in flight, even under extreme conditions. See: http://zumastor.googlecode.com/svn/trunk/ddsnap/kernel/dm-ddsnap.c down(&info->throttle_sem); To be sure, I am not very proud of this throttling mechanism for various reasons, but the thing is, _any_ throttling mechanism no matter how sucky solves the deadlock problem. Over time I want to move the throttling up into bio submission proper, or perhaps incorporate it in device mapper's queue function, not quite as high up the food chain. Only some stupid little logistical issues stopped me from doing it one of those ways right from the start. I think Peter has also tried some things in this area. Anyway, that part is not pressing because the throttling can be done in the virtual device itself as we do it, even if it is not very pretty there. The point is: you have to throttle the bio traffic. The alternative is to die a horrible death under conditions that may be rare, but _will_ hit somebody. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: snd-au8830: dead after software suspend
Have you reported this to the ALSA people? No, I thought this might as well be something for PCI or PM people, and I expected some ALSA people are also reading this list. If not, where else should I report this exactly? alsa-devel [...] the author of the driver Done (original message below). Thanks again :) Gert Robben wrote: After a suspend-resume cycle (using Suspend2), my sound card doesn't work anymore. It works again after reloading the module. dmesg, initial boot: Linux version 2.6.22-ck1 8< PCI driver au8830 lacks driver specific resume support. dmesg, after resume, trying to use the card: vortex: ac97 codec stuck busy Thanks for any help! Gert Robben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Distributed storage.
Hi Mike, On Thursday 02 August 2007 21:09, Mike Snitzer wrote: > But NBD's synchronous nature is actually an asset when coupled with > MD raid1 as it provides guarantees that the data has _really_ been > mirrored remotely. And bio completion doesn't? Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Distributed storage.
Hi Evgeniy, Nit alert: On Tuesday 31 July 2007 10:13, Evgeniy Polyakov wrote: > * storage can be formed on top of remote nodes and be exported > simultaneously (iSCSI is peer-to-peer only, NBD requires device > mapper and is synchronous) In fact, NBD has nothing to do with device mapper. I use it as a physical target underneath ddraid (a device mapper plugin) just like I would use your DST if it proves out. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Apply memory policies to top two highest zones when highest zone is ZONE_MOVABLE
On (04/08/07 00:02), Andi Kleen didst pronounce: > On Thursday 02 August 2007 19:21:18 Mel Gorman wrote: > > The NUMA layer only supports NUMA policies for the highest zone. When > > ZONE_MOVABLE is configured with kernelcore=, the the highest zone becomes > > ZONE_MOVABLE. The result is that policies are only applied to allocations > > like anonymous pages and page cache allocated from ZONE_MOVABLE when the > > zone is used. > > > > This patch applies policies to the two highest zones when the highest zone > > is ZONE_MOVABLE. As ZONE_MOVABLE consists of pages from the highest "real" > > zone, it's always functionally equivalent. > > > > The patch has been tested on a variety of machines both NUMA and non-NUMA > > covering x86, x86_64 and ppc64. No abnormal results were seen in kernbench, > > tbench, dbench or hackbench. It passes regression tests from the numactl > > package with and without kernelcore= once numactl tests are patched to > > wait for vmstat counters to update. > > I must honestly say I really hate the patch. It's a horrible hack and makes > fast paths > slower. When I designed mempolicies I especially tried to avoid things > like that, please don't add them through the backdoor now. > It only affects hot paths in the NUMA case so non-NUMA users will not care. For NUMA users, I have posted patches that eliminate multiple zonelists altogether which will reduce cache footprint (something like 7K per node on x86_64) and make things like MPOL_BIND behave in a consistent manner. That would cost on CPU but save on cache which would (hopefully) result in a net gain in most cases. I would like to go with this patch for now just for policies but for 2.6.23, we could leave it as "policies only apply to ZONE_MOVABLE when it is used" if you really insisted on it. It's less than ideal though for sure. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: snd-au8830: dead after software suspend
On 04/08/07, Gert Robben <[EMAIL PROTECTED]> wrote: > Robert Hancock wrote: > > Have you reported this to the ALSA people? > No, I thought this might as well be something for PCI or PM people, and > I expected some ALSA people are also reading this list. > If not, where else should I report this exactly? > alsa-devel would seem to be a good starting point - see http://www.alsa-project.org/mailing-lists.php Also, the author of the driver, Manuel Jander <[EMAIL PROTECTED]>, would probably be a good person to add to Cc. And keeping LKML on Cc while sending to above people usually never hurts :-) -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: snd-au8830: dead after software suspend
Robert Hancock wrote: Have you reported this to the ALSA people? No, I thought this might as well be something for PCI or PM people, and I expected some ALSA people are also reading this list. If not, where else should I report this exactly? Gert Robben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] au88x0: mem leak fix in snd_vortex_create()
Hi, In sound/pci/au88x0/au88x0.c::snd_vortex_create() : The Coverity checker found that if we allocate storage for 'chip' but then leave via the regions_out: label, then we end up leaking the storage allocated for 'chip'. I believe simply freeing 'chip' before the "return err;" line is all we need to fix this, but please double-check me :) Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- diff --git a/sound/pci/au88x0/au88x0.c b/sound/pci/au88x0/au88x0.c index 5ec1b6f..f70286a 100644 --- a/sound/pci/au88x0/au88x0.c +++ b/sound/pci/au88x0/au88x0.c @@ -232,6 +232,7 @@ snd_vortex_create(struct snd_card *card, struct pci_dev *pci, vortex_t ** rchip) pci_disable_device(chip->pci_dev); //FIXME: this not the right place to unregister the gameport vortex_gameport_unregister(chip); + kfree(chip); return err; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
custom baud rates with serial core
is there a method for setting custom baud rates that doesnt cause a "deprecated" message from showing up ? for example: # setserial -a /dev/ttyBF0 divisor 9 spd_cust setserial sets custom speed on ttyBF0. This is deprecated. my reading of the serial core code is that the only way to specify a baud rate that does not appear in the B* define list is by setting your baud to B38400 and utilizing UPF_SPD_CUST. this ends up in the deprecated warning code though in uart_set_info(). if it's deprecated in favor of something nicer, that's fine, but i cant find out what that "nicer" thing is ... -mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] msleep() with hrtimers
> > Actually the hrsleep() function would allow for submillisecond sleeps, > which might be what some of the 450 users really want and they only use > msleep(1) because it's the next best thing. > A hrsleep() function is really what makes most sense from an API > perspective. I respectfully disagree. The power of msleep is that the unit of sleep time is in the name; so in your proposal it would be hr_msleep or somesuch. I much rather do the opposite in that case; make the "short" name be the best implementation of the requested behavior, and have qualifiers for allowing exceptions to that... least surprise and all that. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dev->priv to netdev_priv(dev)
Yoann Padioleau <[EMAIL PROTECTED]> writes:
> drivers/net/wan/hdlc_fr.c
hdlc_fr (PVC device) uses dev->priv for N:1 mappings (a single pvc
structure may be referenced as dev->priv by multiple (up to 2
currently) PVC devs).
> drivers/net/wan/hdlc_ppp.c
hdlc_ppp obviously has to do some tricks to use syncppp:
static int ppp_open(struct net_device *dev)
{
hdlc_device *hdlc = dev_to_hdlc(dev);
void *old_ioctl;
int result;
dev->priv = &state(hdlc)->syncppp_ptr;
^^
state(hdlc)->syncppp_ptr = &state(hdlc)->pppdev;
state(hdlc)->pppdev.dev = dev;
old_ioctl = dev->do_ioctl;
state(hdlc)->old_change_mtu = dev->change_mtu;
sppp_attach(&state(hdlc)->pppdev);
Perhaps I should remove that and make a sane interface in syncppp.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] UBI: Don't use signed int as array index before testing if it is negative
Hi,
I can't find anything guaranteeing that 'ubi_num' cannot be <0 in
drivers/mtd/ubi/kapi.c::ubi_open_volume(), and in fact the code
even tests for that and errors out if so. Unfortunately the test
for "ubi_num < 0" happens after we've already used 'ubi_num' as
an array index - bad thing to do if it is negative.
This patch moves the test earlier in the function and then moves
the indexing using that variable after the check. A bit safer :-)
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/mtd/ubi/kapi.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/ubi/kapi.c b/drivers/mtd/ubi/kapi.c
index 4a458e8..5130e54 100644
--- a/drivers/mtd/ubi/kapi.c
+++ b/drivers/mtd/ubi/kapi.c
@@ -99,16 +99,21 @@ struct ubi_volume_desc *ubi_open_volume(int ubi_num, int
vol_id, int mode)
{
int err;
struct ubi_volume_desc *desc;
- struct ubi_device *ubi = ubi_devices[ubi_num];
+ struct ubi_device *ubi;
struct ubi_volume *vol;
dbg_msg("open device %d volume %d, mode %d", ubi_num, vol_id, mode);
err = -ENODEV;
+ if (ubi_num < 0)
+ return ERR_PTR(err);
+
+ ubi = ubi_devices[ubi_num];
+
if (!try_module_get(THIS_MODULE))
return ERR_PTR(err);
- if (ubi_num < 0 || ubi_num >= UBI_MAX_DEVICES || !ubi)
+ if (ubi_num >= UBI_MAX_DEVICES || !ubi)
goto out_put;
err = -EINVAL;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] powerpc: Use linux/elfcore-compat.h
This makes powerpc64's compat code use the new linux/elfcore-compat.h,
reducing some hand-copied duplication.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/binfmt_elf32.c | 67 ---
include/asm-powerpc/elf.h | 38 +++--
2 files changed, 51 insertions(+), 54 deletions(-)
diff --git a/arch/powerpc/kernel/binfmt_elf32.c
b/arch/powerpc/kernel/binfmt_elf32.c
index 5cb5875..1d45d77 100644
--- a/arch/powerpc/kernel/binfmt_elf32.c
+++ b/arch/powerpc/kernel/binfmt_elf32.c
@@ -13,49 +13,44 @@
* 2 of the License, or (at your option) any later version.
*/
-#define ELF_ARCH EM_PPC
-#define ELF_CLASS ELFCLASS32
-#define ELF_DATA ELFDATA2MSB;
-
#include
#include
-#include
#include
+#include
+
+#undef ELF_ARCH
+#undef ELF_CLASS
+#define ELF_CLASS ELFCLASS32
+#define ELF_ARCH EM_PPC
+
+#undef elfhdr
+#undef elf_phdr
+#undef elf_note
+#undef elf_addr_t
+#define elfhdr elf32_hdr
+#define elf_phdr elf32_phdr
+#define elf_note elf32_note
+#define elf_addr_t Elf32_Off
-#define elf_prstatus elf_prstatus32
-struct elf_prstatus32
+#define elf_prstatus compat_elf_prstatus
+#define elf_prpsinfo compat_elf_prpsinfo
+
+#define elf_core_copy_regs compat_elf_core_copy_regs
+static inline void compat_elf_core_copy_regs(compat_elf_gregset_t *elf_regs,
+struct pt_regs *regs)
{
- struct elf_siginfo pr_info; /* Info associated with signal */
- short pr_cursig; /* Current signal */
- unsigned int pr_sigpend;/* Set of pending signals */
- unsigned int pr_sighold;/* Set of held signals */
- pid_t pr_pid;
- pid_t pr_ppid;
- pid_t pr_pgrp;
- pid_t pr_sid;
- struct compat_timeval pr_utime; /* User time */
- struct compat_timeval pr_stime; /* System time */
- struct compat_timeval pr_cutime;/* Cumulative user time */
- struct compat_timeval pr_cstime;/* Cumulative system time */
- elf_gregset_t pr_reg; /* General purpose registers. */
- int pr_fpvalid; /* True if math co-processor being used. */
-};
+ PPC_ELF_CORE_COPY_REGS((*elf_regs), regs);
+}
-#define elf_prpsinfo elf_prpsinfo32
-struct elf_prpsinfo32
+#define elf_core_copy_task_regs compat_elf_core_copy_task_regs
+static int compat_elf_core_copy_task_regs(struct task_struct *tsk,
+ compat_elf_gregset_t *elf_regs)
{
- charpr_state; /* numeric process state */
- charpr_sname; /* char for pr_state */
- charpr_zomb;/* zombie */
- charpr_nice;/* nice val */
- unsigned int pr_flag; /* flags */
- u32 pr_uid;
- u32 pr_gid;
- pid_t pr_pid, pr_ppid, pr_pgrp, pr_sid;
- /* Lots missing */
- charpr_fname[16]; /* filename of executable */
- charpr_psargs[ELF_PRARGSZ]; /* initial part of arg list */
-};
+ struct pt_regs *regs = tsk->thread.regs;
+ if (regs)
+ compat_elf_core_copy_regs(elf_regs, regs);
+ return 1;
+}
#include
diff --git a/include/asm-powerpc/elf.h b/include/asm-powerpc/elf.h
index de50799..b6a1aef 100644
--- a/include/asm-powerpc/elf.h
+++ b/include/asm-powerpc/elf.h
@@ -101,6 +101,7 @@ typedef elf_greg_t64 elf_gregset_t64[ELF_NGREG];
typedef unsigned int elf_greg_t32;
typedef elf_greg_t32 elf_gregset_t32[ELF_NGREG];
+typedef elf_gregset_t32 compat_elf_gregset_t;
/*
* ELF_ARCH, CLASS, and DATA are used to set parameters in the core dumps.
@@ -175,26 +176,27 @@ typedef elf_vrreg_t elf_vrregset_t32[ELF_NVRREG32];
#define ELF_ET_DYN_BASE (0x2000)
-/* Common routine for both 32-bit and 64-bit processes */
+/*
+ * Our registers are always unsigned longs, whether we're a 32 bit
+ * process or 64 bit, on either a 64 bit or 32 bit kernel.
+ *
+ * This macro relies on elf_regs[i] having the right type to truncate to,
+ * either u32 or u64. It defines the body of the elf_core_copy_regs
+ * function, either the native one with elf_gregset_t elf_regs or
+ * the 32-bit one with elf_gregset_t32 elf_regs.
+ */
+#define PPC_ELF_CORE_COPY_REGS(elf_regs, regs) \
+ int i, nregs = min(sizeof(*regs) / sizeof(unsigned long), \
+ (size_t)ELF_NGREG);\
+ for (i = 0; i < nregs; i++) \
+ elf_regs[i] = ((unsigned long *) regs)[i]; \
+ memset(&elf_regs[i], 0, (ELF_NGREG - i) * sizeof(elf_regs[0]))
+
+/* Common routine for both 32-bit and 64-bit native processes */
static inline void ppc_elf_core_copy_regs(elf_gregset_t elf_regs,
- struct pt_regs *regs)
+ struct pt_regs *regs)
{
- int i, nregs;
-
- memset((void *)elf_regs,
[PATCH] x86_64: Use linux/elfcore-compat.h
This makes x86-64's ia32 code use the new linux/elfcore-compat.h,
reducing some hand-copied duplication.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86_64/ia32/ia32_binfmt.c | 123 +++-
include/asm-x86_64/compat.h|6 ++
2 files changed, 51 insertions(+), 78 deletions(-)
diff --git a/arch/x86_64/ia32/ia32_binfmt.c b/arch/x86_64/ia32/ia32_binfmt.c
index 90b37fc..57de329 100644
--- a/arch/x86_64/ia32/ia32_binfmt.c
+++ b/arch/x86_64/ia32/ia32_binfmt.c
@@ -5,10 +5,6 @@
* This tricks binfmt_elf.c into loading 32bit binaries using lots
* of ugly preprocessor tricks. Talk about very very poor man's inheritance.
*/
-#define __ASM_X86_64_ELF_H 1
-
-#undef ELF_CLASS
-#define ELF_CLASS ELFCLASS32
#include
#include
@@ -19,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -31,6 +28,20 @@
#include
#include
+#undef ELF_ARCH
+#undef ELF_CLASS
+#define ELF_CLASS ELFCLASS32
+#define ELF_ARCH EM_386
+
+#undef elfhdr
+#undef elf_phdr
+#undef elf_note
+#undef elf_addr_t
+#define elfhdr elf32_hdr
+#define elf_phdr elf32_phdr
+#define elf_note elf32_note
+#define elf_addr_t Elf32_Off
+
#define ELF_NAME "elf/i386"
#define AT_SYSINFO 32
@@ -48,70 +59,14 @@ int sysctl_vsyscall32 = 1;
} while(0)
struct file;
-struct elf_phdr;
#define IA32_EMULATOR 1
+#undef ELF_ET_DYN_BASE
#define ELF_ET_DYN_BASE(TASK_UNMAPPED_BASE + 0x100)
-#undef ELF_ARCH
-#define ELF_ARCH EM_386
-
-#define ELF_DATA ELFDATA2LSB
-
-#define USE_ELF_CORE_DUMP 1
-
-/* Override elfcore.h */
-#define _LINUX_ELFCORE_H 1
-typedef unsigned int elf_greg_t;
-
-#define ELF_NGREG (sizeof (struct user_regs_struct32) / sizeof(elf_greg_t))
-typedef elf_greg_t elf_gregset_t[ELF_NGREG];
-
-struct elf_siginfo
-{
- int si_signo; /* signal number */
- int si_code;/* extra code */
- int si_errno; /* errno */
-};
-
#define jiffies_to_timeval(a,b) do { (b)->tv_usec = 0; (b)->tv_sec = (a)/HZ;
}while(0)
-struct elf_prstatus
-{
- struct elf_siginfo pr_info; /* Info associated with signal */
- short pr_cursig; /* Current signal */
- unsigned int pr_sigpend;/* Set of pending signals */
- unsigned int pr_sighold;/* Set of held signals */
- pid_t pr_pid;
- pid_t pr_ppid;
- pid_t pr_pgrp;
- pid_t pr_sid;
- struct compat_timeval pr_utime; /* User time */
- struct compat_timeval pr_stime; /* System time */
- struct compat_timeval pr_cutime;/* Cumulative user time */
- struct compat_timeval pr_cstime;/* Cumulative system time */
- elf_gregset_t pr_reg; /* GP registers */
- int pr_fpvalid; /* True if math co-processor being used. */
-};
-
-#define ELF_PRARGSZ(80)/* Number of chars for args */
-
-struct elf_prpsinfo
-{
- charpr_state; /* numeric process state */
- charpr_sname; /* char for pr_state */
- charpr_zomb;/* zombie */
- charpr_nice;/* nice val */
- unsigned int pr_flag; /* flags */
- __u16 pr_uid;
- __u16 pr_gid;
- pid_t pr_pid, pr_ppid, pr_pgrp, pr_sid;
- /* Lots missing */
- charpr_fname[16]; /* filename of executable */
- charpr_psargs[ELF_PRARGSZ]; /* initial part of arg list */
-};
-
#define __STR(x) #x
#define STR(x) __STR(x)
@@ -119,6 +74,7 @@ struct elf_prpsinfo
({ __u32 seg; asm("movl %%" STR(x) ",%0" : "=r"(seg)); seg; })
/* Assumes current==process to be dumped */
+#undef ELF_CORE_COPY_REGS
#define ELF_CORE_COPY_REGS(pr_reg, regs) \
pr_reg[0] = regs->rbx; \
pr_reg[1] = regs->rcx; \
@@ -138,36 +94,41 @@ struct elf_prpsinfo
pr_reg[15] = regs->rsp; \
pr_reg[16] = regs->ss;
-#define user user32
+
+#define elf_prstatus compat_elf_prstatus
+#define elf_prpsinfo compat_elf_prpsinfo
+#define elf_fpregset_t struct user_i387_ia32_struct
+#defineelf_fpxregset_t struct user32_fxsr_struct
+#define user user32
#undef elf_read_implies_exec
#define elf_read_implies_exec(ex, executable_stack) (executable_stack !=
EXSTACK_DISABLE_X)
-//#include
-#include
-
-typedef struct user_i387_ia32_struct elf_fpregset_t;
-typedef struct user32_fxsr_struct elf_fpxregset_t;
-
-static inline void elf_core_copy_regs(elf_gregset_t *elfregs, struct pt_regs
*regs)
+#define elf_core_copy_regs elf32_core_copy_regs
+static inline void elf32_core_copy_regs(compat_elf_gregset_t *elfregs,
+ struct pt_regs *regs)
{
- ELF_CORE_COPY_REGS((*elfregs), regs)
+ ELF_CORE_COPY_REGS((&elfregs->ebx), regs)
}
-static i
[PATCH] Add linux/elfcore-compat.h
This adds the linux/elfcore-compat.h header file, which is the
CONFIG_COMPAT analog of the linux/elfcore.h header. Each arch
that needs to fake out fs/binfmt_elf.c for its compat code can
use this header to replace the hand-copied definitions of the
compat variants of struct elf_prstatus et al. Only the pr_reg
field varies by arch, so asm/{compat,elf}.h must define
compat_elf_gregset_t before linux/elfcore-compat.h can be used.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
include/linux/elfcore-compat.h | 55
1 files changed, 55 insertions(+), 0 deletions(-)
create mode 100644 include/linux/elfcore-compat.h
diff --git a/include/linux/elfcore-compat.h b/include/linux/elfcore-compat.h
new file mode 100644
index 000..532d13a
--- /dev/null
+++ b/include/linux/elfcore-compat.h
@@ -0,0 +1,55 @@
+#ifndef _LINUX_ELFCORE_COMPAT_H
+#define _LINUX_ELFCORE_COMPAT_H
+
+#include
+#include
+#include
+
+/*
+ * Make sure these layouts match the linux/elfcore.h native definitions.
+ */
+
+struct compat_elf_siginfo
+{
+ compat_int_tsi_signo;
+ compat_int_tsi_code;
+ compat_int_tsi_errno;
+};
+
+struct compat_elf_prstatus
+{
+ struct compat_elf_siginfo pr_info;
+ short pr_cursig;
+ compat_ulong_t pr_sigpend;
+ compat_ulong_t pr_sighold;
+ compat_pid_tpr_pid;
+ compat_pid_tpr_ppid;
+ compat_pid_tpr_pgrp;
+ compat_pid_tpr_sid;
+ struct compat_timeval pr_utime;
+ struct compat_timeval pr_stime;
+ struct compat_timeval pr_cutime;
+ struct compat_timeval pr_cstime;
+ compat_elf_gregset_tpr_reg;
+#ifdef CONFIG_BINFMT_ELF_FDPIC
+ compat_ulong_t pr_exec_fdpic_loadmap;
+ compat_ulong_t pr_interp_fdpic_loadmap;
+#endif
+ compat_int_tpr_fpvalid;
+};
+
+struct compat_elf_prpsinfo
+{
+ charpr_state;
+ charpr_sname;
+ charpr_zomb;
+ charpr_nice;
+ compat_ulong_t pr_flag;
+ compat_uid_tpr_uid;
+ compat_gid_tpr_gid;
+ compat_pid_tpr_pid, pr_ppid, pr_pgrp, pr_sid;
+ charpr_fname[16];
+ charpr_psargs[ELF_PRARGSZ];
+};
+
+#endif /* _LINUX_ELFCORE_COMPAT_H */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] libata: add human-readable error value decoding v3
On 08/03/2007 02:00 PM, Robert Hancock wrote: > This adds human-readable decoding of the ATA status and error registers > (similar to what drivers/ide does) as well as the SATA Serror register to > libata error handling output. This prevents the need to pore through > standards documents to figure out the meaning of the bits in these > registers when looking at error reports. Some bits that drivers/ide > decoded are not decoded here, since the bits are either command-dependent > or obsolete, and properly parsing them would add too much complexity. > This is really nice. Maybe make it configurable, though? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.23-rc1-git9, arch/x86_64/pci/k8-bus.c::fill_mp_bus_to_cpumask()
On Fri, 03 Aug 2007 18:10:03 -0400 Chuck Ebbert <[EMAIL PROTECTED]> wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250859 > > at line 74: > > [EMAIL PROTECTED]: > [EMAIL PROTECTED]:sd = bus->sysdata; > [EMAIL PROTECTED]:sd->node = node; > <= > > bus->sysdata is NULL. > > Last changed by this hunk of > "x86-64: introduce struct pci_sysdata to facilitate sharing of ->sysdata": > > @@ -67,7 +69,9 @@ fill_mp_bus_to_cpumask(void) > continue; > if (!node_online(node)) > node = 0; > - bus->sysdata = (void *)node; > + > + sd = bus->sysdata; > + sd->node = node; > } > } > } > Andy keeps trotting out a patch which will probably fix this, but for some reason it doesn't seem to make progress. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: snd-au8830: dead after software suspend
Gert Robben wrote: After a suspend-resume cycle (using Suspend2), my sound card doesn't work anymore. It works again after reloading the module. dmesg, initial boot: Linux version 2.6.22-ck1 8< PCI driver au8830 lacks driver specific resume support. dmesg, after resume, trying to use the card: vortex: ac97 codec stuck busy Thanks for any help! That driver will have to be updated to reinitialize the card properly after resume.. Have you reported this to the ALSA people? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ICH8 CF timeout (regression)...
Tejun,
On 03/08/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Daniel J Blueman wrote:
> > The ICH8 south-bridge I have is the mobile variant and does come
> > equipped with native parallel IDE - see page 447:
> > http://download.intel.com/design/chipsets/datashts/31305603.pdf . I do
> > see 35MB/s with DMA enabled from my CF on the 1 in 15 times the
> > libata-kernel does work.
> >
> > I can dump off and decode the configuration registers for the timing
> > and bus master registers in the working and non-working libata cases,
> > and the legacy ATA working case and see what's different.
>
> Does the attached patch change anything?
This addresses the issue 100%!
Due to the differences between the ICH8 non-mobile and mobile
variants, I've cooked the change into a new initialisation structure
for the ICH8M in the attached patch, if that helps at all.
The changes thus affect (correct) behaviour on the ICH8M in IDE mode
only...so should be safe for inclusion. There may be a similar
situation with ICH9Ms also.
Thanks once again to all who helped!
Daniel
--
Daniel J Blueman
diff -urN linux-2.6.23-rc1.orig/drivers/ata/ata_piix.c linux-2.6.23-rc1/drivers/ata/ata_piix.c
--- linux-2.6.23-rc1.orig/drivers/ata/ata_piix.c 2007-08-03 21:29:02.0 +0100
+++ linux-2.6.23-rc1/drivers/ata/ata_piix.c 2007-08-03 21:24:53.0 +0100
@@ -128,7 +128,8 @@
ich6_sata_ahci = 7,
ich6m_sata_ahci = 8,
ich8_sata_ahci = 9,
- piix_pata_mwdma = 10, /* PIIX3 MWDMA only */
+ ich8m_sata_ahci = 10,
+ piix_pata_mwdma = 11, /* PIIX3 MWDMA only */
/* constants for mapping table */
P0 = 0, /* port 0 */
@@ -232,7 +233,7 @@
/* SATA Controller 2 IDE (ICH8) */
{ 0x8086, 0x2825, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
/* Mobile SATA Controller IDE (ICH8M) */
- { 0x8086, 0x2828, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
+ { 0x8086, 0x2828, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8m_sata_ahci },
/* SATA Controller IDE (ICH9) */
{ 0x8086, 0x2920, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
/* SATA Controller IDE (ICH9) */
@@ -428,7 +429,19 @@
/* PM PS SM SS MAP */
{ P0, P2, P1, P3 }, /* 00b (hardwired when in AHCI) */
{ RV, RV, RV, RV },
- { IDE, IDE, NA, NA }, /* 10b (IDE mode) */
+ { IDE, IDE, NA, NA }, /* 10b (IDE mode) */
+ { RV, RV, RV, RV },
+ },
+};
+
+static const struct piix_map_db ich8m_map_db = {
+ .mask = 0x3,
+ .port_enable = 0x3,
+ .map = {
+ /* PM PS SM SS MAP */
+ { P0, P2, P1, P3 }, /* 00b (hardwired when in AHCI) */
+ { RV, RV, RV, RV },
+ { P0, P2, IDE, IDE }, /* 10b (IDE mode) */
{ RV, RV, RV, RV },
},
};
@@ -439,6 +452,7 @@
[ich6_sata_ahci] = &ich6_map_db,
[ich6m_sata_ahci] = &ich6m_map_db,
[ich8_sata_ahci] = &ich8_map_db,
+ [ich8m_sata_ahci] = &ich8m_map_db,
};
static struct ata_port_info piix_port_info[] = {
@@ -544,7 +558,18 @@
.port_ops = &piix_sata_ops,
},
- /* piix_pata_mwdma: 10: PIIX3 MWDMA only */
+ /* ich8m_sata_ahci: 10 */
+ {
+ .sht = &piix_sht,
+ .flags = PIIX_SATA_FLAGS | PIIX_FLAG_SCR |
+ PIIX_FLAG_AHCI,
+ .pio_mask = 0x1f, /* pio0-4 */
+ .mwdma_mask = 0x07, /* mwdma0-2 */
+ .udma_mask = ATA_UDMA6,
+ .port_ops = &piix_sata_ops,
+ },
+
+ /* piix_pata_mwdma: 11: PIIX3 MWDMA only */
{
.sht = &piix_sht,
.flags = PIIX_PATA_FLAGS,
Re: [PATCH] PM: Fix dependencies of CONFIG_SUSPEND and CONFIG_HIBERNATION
On Saturday, 4 August 2007 00:01, Linus Torvalds wrote: > > On Fri, 3 Aug 2007, Rafael J. Wysocki wrote: > > depends on PM > > - depends on !SMP || SUSPEND_SMP_POSSIBLE > > + depends on SUSPEND_SMP_POSSIBLE || ((BLACKFIN || MIPS || SUPERH || FRV \ > > + || (PPC32 && PPC_MPC52xx)) && !SMP) > > Please, do that as SUSPEND_UP_POSSIBLE, and make it look like > > config SUSPEND_UP_POSSIBLE > depends on BLACKFIN || MIPS || SUPERH || FRV || ((PPC32 && > PPC_MPC52xx) > depends on !SMP > default y OK > and now you can write the above thing as > > depends on SUSPEND_SMP_POSSIBLE || SUSPEND_UP_POSSIBLE > > and it's all much nicer. > > I would say that doing a similar setup for HIBERNATE would be nice too, > but the SUSPEND case is more noticeable because the SMP case is so nice > already. I did it symmetrically for suspend and hibernation and renamed SUSPEND_SMP to PM_SLEEP_SMP. Patch follows. Greetings, Rafael --- From: Rafael J. Wysocki <[EMAIL PROTECTED]> Dependencies of CONFIG_SUSPEND and CONFIG_HIBERNATION introduced by commit 296699de6bdc717189a331ab6bbe90e05c94db06 "Introduce CONFIG_SUSPEND for suspend-to-Ram and standby" are incorrect, as they don't cover the facts that (1) not all architectures support suspend and (2) SMP hibernation is only possible on X86 and PPC64 (if PPC64_SWSUSP is set). Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> --- kernel/power/Kconfig | 40 ++-- 1 file changed, 30 insertions(+), 10 deletions(-) Index: linux-2.6/kernel/power/Kconfig === --- linux-2.6.orig/kernel/power/Kconfig 2007-07-30 07:58:48.0 +0200 +++ linux-2.6/kernel/power/Kconfig 2007-08-04 00:39:21.0 +0200 @@ -72,15 +72,10 @@ config PM_TRACE CAUTION: this option will cause your machine's real-time clock to be set to an invalid time after a resume. -config SUSPEND_SMP_POSSIBLE - bool - depends on (X86 && !X86_VOYAGER) || (PPC64 && (PPC_PSERIES || PPC_PMAC)) - depends on SMP - default y - -config SUSPEND_SMP +config PM_SLEEP_SMP bool - depends on SUSPEND_SMP_POSSIBLE && PM_SLEEP + depends on SUSPEND_SMP_POSSIBLE || HIBERNATION_SMP_POSSIBLE + depends on PM_SLEEP select HOTPLUG_CPU default y @@ -89,20 +84,45 @@ config PM_SLEEP depends on SUSPEND || HIBERNATION default y +config SUSPEND_UP_POSSIBLE + bool + depends on BLACKFIN || MIPS || SUPERH || FRV || (PPC32 && PPC_MPC52xx) + depends on !SMP + default y + +config SUSPEND_SMP_POSSIBLE + bool + depends on (X86 && !X86_VOYAGER) \ + || (PPC64 && (PPC_PSERIES || PPC_PMAC)) || ARM + depends on SMP + default y + config SUSPEND bool "Suspend to RAM and standby" depends on PM - depends on !SMP || SUSPEND_SMP_POSSIBLE + depends on SUSPEND_UP_POSSIBLE || SUSPEND_SMP_POSSIBLE default y ---help--- Allow the system to enter sleep states in which main memory is powered and thus its contents are preserved, such as the suspend-to-RAM state (i.e. the ACPI S3 state). +config HIBERNATION_UP_POSSIBLE + bool + depends on X86 || PPC64_SWSUSP || FRV || PPC32 + depends on !SMP + default y + +config HIBERNATION_SMP_POSSIBLE + bool + depends on (X86 && !X86_VOYAGER) || PPC64_SWSUSP + depends on SMP + default y + config HIBERNATION bool "Hibernation (aka 'suspend to disk')" depends on PM && SWAP - depends on ((X86 || PPC64_SWSUSP || FRV || PPC32) && !SMP) || SUSPEND_SMP_POSSIBLE + depends on HIBERNATION_UP_POSSIBLE || HIBERNATION_SMP_POSSIBLE ---help--- Enable the suspend to disk (STD) functionality, which is usually called "hibernation" in user interfaces. STD checkpoints the - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 RFC -rt] Allow rcutorture to handle synchronize_sched()
On Fri, 2007-08-03 at 11:44 -0700, Paul E. McKenney wrote: > The rcutorture module uses a random-number generator that periodically > calls get_random_bytes() to add entropy. This random-number generator > is invoked from within the RCU read-side critical section, which, in the > case of the synchronize_sched() variant of RCU, has preeemption disabled. > Unfortunately, get_random_bytes() ends up acquiring normal spinlocks, > which can block in -rt, resulting in very large numbers of "scheduling > while atomic" messages. > > This patch takes a very crude approach, simply substituting the time > of day for get_random_bytes(). > > Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]> Acked-by: Josh Triplett <[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-usb-devel] [PATCH] USB BIOS early handoff only when the we the driver is configured
On Thu, Aug 02, 2007 at 09:43:29AM -0700, Greg KH wrote: ... > It wasn't just MIPS. IBM has a very popular blade system that has huge > issues with this, and I think there are some other IBM systems based on > the same BIOS that also do bad things if we don't grab the USB > controller away from the BIOS as soon as possible (nasty interrupt and > other messes happen...) PA-RISC has the same problem with USB. We can't reprogram the IOMMU windows at boot time unless the USB controller is forcefully stopped from doing DMA. "BIOS" leaves the USB DMA enabled to avoid loosing activity between polls for input. PA-RISC solves this by calling back into the "BIOS" (aka PDC) to cleanly stop all possible DMA devices. Other arches probably don't have this luxury. grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/23] per device dirty throttling -v8
On Fri, 3 Aug 2007, Peter Zijlstra wrote: > > These patches aim to improve balance_dirty_pages() and directly address three > issues: > 1) inter device starvation > 2) stacked device deadlocks > 3) inter process starvation Ok, the patches certainly look pretty enough, and you fixed the only thing I complained about last time (naming), so as far as I'm concerned it's now just a matter of whether it *works* or not. I guess being in -mm will help somewhat, but it would be good to have people with several disks etc actively test this out. 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/
PROBLEM: snd-au8830: dead after software suspend
After a suspend-resume cycle (using Suspend2), my sound card doesn't work anymore. It works again after reloading the module. dmesg, initial boot: Linux version 2.6.22-ck1 8< PCI driver au8830 lacks driver specific resume support. dmesg, after resume, trying to use the card: vortex: ac97 codec stuck busy Thanks for any help! Gert Robben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + remove-current-defines-and-uses-of-pr_err-add-pr_emerg.patch added to -mm tree
On Fri, 2007-08-03 at 17:05 +0200, Jean Delvare wrote:
> Fine with me, but this first patch should still be correct per se.
Add new pr_ printk(KERN_ fmt "\n", ##arg) to kernel.h
pr_info and pr_debug are unchanged
Remove local pr_err #defines
Convert current uses of pr_err
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 4300bb4..6447072 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -229,20 +229,24 @@ extern void print_hex_dump_bytes(const char *prefix_str,
int prefix_type,
void *buf, size_t len);
#define hex_asc(x) "0123456789abcdef"[x]
+#define pr_emerg(fmt, arg...) printk(KERN_EMERG fmt "\n", ##arg)
+#define pr_alert(fmt, arg...) printk(KERN_ALERT fmt "\n", ##arg)
+#define pr_crit(fmt, arg...) printk(KERN_CRIT fmt "\n", ##arg)
+#define pr_err(fmt, arg...)printk(KERN_ERR fmt "\n", ##arg)
+#define pr_warn(fmt, arg...) printk(KERN_WARNING fmt "\n", ##arg)
+#define pr_notice(fmt, arg...) printk(KERN_NOTICE fmt "\n", ##arg)
+#define pr_info(fmt, arg...) printk(KERN_INFO fmt, ##arg)
+
#ifdef DEBUG
/* If you are writing a driver, please use dev_dbg instead */
-#define pr_debug(fmt,arg...) \
- printk(KERN_DEBUG fmt,##arg)
+#define pr_debug(fmt, arg...) printk(KERN_DEBUG fmt, ##arg)
#else
-static inline int __attribute__ ((format (printf, 1, 2))) pr_debug(const char
* fmt, ...)
+static inline int __attribute__ ((format (printf, 1, 2))) pr_debug(const char
*fmt, ...)
{
return 0;
}
#endif
-#define pr_info(fmt,arg...) \
- printk(KERN_INFO fmt,##arg)
-
/*
* Display an IP address in readable format.
*/
diff --git a/drivers/i2c/chips/menelaus.c b/drivers/i2c/chips/menelaus.c
index 48a7e2f..055a7b4 100644
--- a/drivers/i2c/chips/menelaus.c
+++ b/drivers/i2c/chips/menelaus.c
@@ -49,8 +49,7 @@
#include
#define DRIVER_NAME"menelaus"
-
-#define pr_err(fmt, arg...)printk(KERN_ERR DRIVER_NAME ": ", ## arg);
+#define PFX DRIVER_NAME ": "
#define MENELAUS_I2C_ADDRESS 0x72
@@ -156,7 +155,7 @@ static int menelaus_write_reg(int reg, u8 value)
int val = i2c_smbus_write_byte_data(the_menelaus->client, reg, value);
if (val < 0) {
- pr_err("write error");
+ pr_err(PFX "write error");
return val;
}
@@ -168,7 +167,7 @@ static int menelaus_read_reg(int reg)
int val = i2c_smbus_read_byte_data(the_menelaus->client, reg);
if (val < 0)
- pr_err("read error");
+ pr_err(PFX "read error");
return val;
}
@@ -1178,7 +1177,7 @@ static int menelaus_probe(struct i2c_client *client)
/* If a true probe check the device */
rev = menelaus_read_reg(MENELAUS_REV);
if (rev < 0) {
- pr_err("device not found");
+ pr_err(PFX "device not found");
err = -ENODEV;
goto fail1;
}
@@ -1259,7 +1258,7 @@ static int __init menelaus_init(void)
res = i2c_add_driver(&menelaus_i2c_driver);
if (res < 0) {
- pr_err("driver registration failed\n");
+ pr_err(PFX "driver registration failed");
return res;
}
diff --git a/drivers/net/spider_net.c b/drivers/net/spider_net.c
index 590b12c..ce0417c 100644
--- a/drivers/net/spider_net.c
+++ b/drivers/net/spider_net.c
@@ -1238,14 +1238,14 @@ spider_net_decode_one_descr(struct spider_net_card
*card)
if (hwdescr->dmac_cmd_status & SPIDER_NET_DESCR_BAD_STATUS) {
dev_err(&card->netdev->dev, "bad status, cmd_status=x%08x\n",
hwdescr->dmac_cmd_status);
- pr_err("buf_addr=x%08x\n", hw_buf_addr);
- pr_err("buf_size=x%08x\n", hwdescr->buf_size);
- pr_err("next_descr_addr=x%08x\n", hwdescr->next_descr_addr);
- pr_err("result_size=x%08x\n", hwdescr->result_size);
- pr_err("valid_size=x%08x\n", hwdescr->valid_size);
- pr_err("data_status=x%08x\n", hwdescr->data_status);
- pr_err("data_error=x%08x\n", hwdescr->data_error);
- pr_err("which=%ld\n", descr - card->rx_chain.ring);
+ pr_err("buf_addr=x%08x", hw_buf_addr);
+ pr_err("buf_size=x%08x", hwdescr->buf_size);
+ pr_err("next_descr_addr=x%08x", hwdescr->next_descr_addr);
+ pr_err("result_size=x%08x", hwdescr->result_size);
+ pr_err("valid_size=x%08x", hwdescr->valid_size);
+ pr_err("data_status=x%08x", hwdescr->data_status);
+ pr_err("data_error=x%08x", hwdescr->data_error);
+ pr_err("which=%ld", descr - card->rx_chain.ring);
card->spider_stats.rx_desc_error++;
goto bad_desc;
diff --git a/drivers/net/spider_net.h b/drivers/net/spider_net.h
index dbbdb8c..c6
Oops in 2.6.23-rc1-git9, arch/x86_64/pci/k8-bus.c::fill_mp_bus_to_cpumask()
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250859 at line 74: [EMAIL PROTECTED]: [EMAIL PROTECTED]: sd = bus->sysdata; [EMAIL PROTECTED]: sd->node = node; <= bus->sysdata is NULL. Last changed by this hunk of "x86-64: introduce struct pci_sysdata to facilitate sharing of ->sysdata": @@ -67,7 +69,9 @@ fill_mp_bus_to_cpumask(void) continue; if (!node_online(node)) node = 0; - bus->sysdata = (void *)node; + + sd = bus->sysdata; + sd->node = node; } } } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dynamic major/minor numbers (or dropping them completely)
On Fri, Aug 03, 2007 at 05:13:51PM -0400, Chris Snook wrote: > You're correct that dynamic major/minor numbers are sufficient for most > purposes, but embedded users really need their static numbers. As for > ripping out major/minor numberings, that's a non-starter. Too much of our > device management infrastructure is based around this numbering scheme, and > there isn't really anything wrong with it to justify breaking everything in > the change. > > As a rule of thumb, if you ever find yourself wondering why we still > support doing statically something we can now do dynamically, the answer is > generally that doing it dynamically sucks for embedded. And not only embedded. I'm quite happy _not_ running udev on anything I have root on, except for one test box set exactly to make sure that patches do not break things for udev-infested boxen. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] kill an obsolete sub-thread-ptrace stuff
> However, I disagree. exit_notify() doesn't check the ptrace-same-group > case. So, unless I missed something, we set EXIT_DEAD in any case, even > if ptracer doesn't belong to our thread group. Oh, you're right. I was reading the other line you changed. Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM: Fix dependencies of CONFIG_SUSPEND and CONFIG_HIBERNATION
On Fri, 3 Aug 2007, Rafael J. Wysocki wrote: > depends on PM > - depends on !SMP || SUSPEND_SMP_POSSIBLE > + depends on SUSPEND_SMP_POSSIBLE || ((BLACKFIN || MIPS || SUPERH || FRV \ > + || (PPC32 && PPC_MPC52xx)) && !SMP) Please, do that as SUSPEND_UP_POSSIBLE, and make it look like config SUSPEND_UP_POSSIBLE depends on BLACKFIN || MIPS || SUPERH || FRV || ((PPC32 && PPC_MPC52xx) depends on !SMP default y and now you can write the above thing as depends on SUSPEND_SMP_POSSIBLE || SUSPEND_UP_POSSIBLE and it's all much nicer. I would say that doing a similar setup for HIBERNATE would be nice too, but the SUSPEND case is more noticeable because the SMP case is so nice already. 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: [PATCH] Apply memory policies to top two highest zones when highest zone is ZONE_MOVABLE
On Thursday 02 August 2007 19:21:18 Mel Gorman wrote: > The NUMA layer only supports NUMA policies for the highest zone. When > ZONE_MOVABLE is configured with kernelcore=, the the highest zone becomes > ZONE_MOVABLE. The result is that policies are only applied to allocations > like anonymous pages and page cache allocated from ZONE_MOVABLE when the > zone is used. > > This patch applies policies to the two highest zones when the highest zone > is ZONE_MOVABLE. As ZONE_MOVABLE consists of pages from the highest "real" > zone, it's always functionally equivalent. > > The patch has been tested on a variety of machines both NUMA and non-NUMA > covering x86, x86_64 and ppc64. No abnormal results were seen in kernbench, > tbench, dbench or hackbench. It passes regression tests from the numactl > package with and without kernelcore= once numactl tests are patched to > wait for vmstat counters to update. I must honestly say I really hate the patch. It's a horrible hack and makes fast paths slower. When I designed mempolicies I especially tried to avoid things like that, please don't add them through the backdoor now. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kill an obsolete sub-thread-ptrace stuff
On 08/03, Roland McGrath wrote: > > > There is a couple of subtle checks which were needed to handle ptracing from > > the same thread group. This was deprecated a long ago, imho this code just > > complicates the understanding. > > Looks ok to me. Thanks! > > And, the "->parent->signal->flags & SIGNAL_GROUP_EXIT" check in > > exit_notify() > > is not right. SIGNAL_GROUP_EXIT can mean exec(), not exit_group(). This > > means > > ptracer can lose a ptraced zombie on exec(). Minor problem, but still the > > bug. > > This bug never happens because this check is only in the now-impossible > ptrace-same-group case. This means that changelog is wrong and should be changed. However, I disagree. exit_notify() doesn't check the ptrace-same-group case. So, unless I missed something, we set EXIT_DEAD in any case, even if ptracer doesn't belong to our thread group. No? Oleg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI on Averatec 2370
On Thu, 2 Aug 2007, Cal Peake wrote: > On Thu, 2 Aug 2007, Linus Torvalds wrote: > > > > That said, the "AMD Turion(tm) 64 X2 Mobile Technology TL-52" _should_ be > > a REV-F CPU afaik, and it should have thus fallen through to the > > "ENABLE_C1E_MASK" logic. Afaik that's broken. > > > > Cal - can you > > (a) test that forcing a "return 1" from that amd_apic_timer_broken() > > function fixes it for you. > > ACK > > > (b) make that function print out the values it uses for debugging (ie the > > xtended family and model numbers, and the MSR_K8_ENABLE_C1E MSR > > values)? > > eax & CPUID_XFAM == 0x > eax & CPUID_XMOD == 0x0004 Yeah, that's a REV-F > MSR_K8_ENABLE_C1E lo == 0x04c14015 > MSR_K8_ENABLE_C1E hi == 0x > lo & ENABLE_C1E_MASK == 0 And yeah, that claims that C1E is not on, but: > amd_apic_timer_broken: forcing return value of 1 since this makes it all work for you, it does appear that the AMD local timer stops in C1 even when that isn't true, and as such is not useful. Sad. It probably means that we have to disable the local timer for *all* modern AMD CPU's. Thomas/Ingo - did something change in the local apic programming? Or why did this work before? Was it just that we didn't use the local timer apic for some other reason? 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: [PATCH] kill an obsolete sub-thread-ptrace stuff
> There is a couple of subtle checks which were needed to handle ptracing from > the same thread group. This was deprecated a long ago, imho this code just > complicates the understanding. Looks ok to me. > And, the "->parent->signal->flags & SIGNAL_GROUP_EXIT" check in exit_notify() > is not right. SIGNAL_GROUP_EXIT can mean exec(), not exit_group(). This means > ptracer can lose a ptraced zombie on exec(). Minor problem, but still the bug. This bug never happens because this check is only in the now-impossible ptrace-same-group case. The code can certainly go. Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PM: Fix dependencies of CONFIG_SUSPEND and CONFIG_HIBERNATION
From: Rafael J. Wysocki <[EMAIL PROTECTED]> Dependencies of CONFIG_SUSPEND and CONFIG_HIBERNATION introduced by commit 296699de6bdc717189a331ab6bbe90e05c94db06 "Introduce CONFIG_SUSPEND for suspend-to-Ram and standby" are incorrect, as they don't cover the facts that (1) not all architectures support suspend and (2) SMP hibernation is only possible on X86 and PPC64 (if PPC64_SWSUSP is set). Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> --- kernel/power/Kconfig |9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) Index: linux-2.6/kernel/power/Kconfig === --- linux-2.6.orig/kernel/power/Kconfig 2007-07-30 07:58:48.0 +0200 +++ linux-2.6/kernel/power/Kconfig 2007-08-03 23:29:57.0 +0200 @@ -74,7 +74,8 @@ config PM_TRACE config SUSPEND_SMP_POSSIBLE bool - depends on (X86 && !X86_VOYAGER) || (PPC64 && (PPC_PSERIES || PPC_PMAC)) + depends on (X86 && !X86_VOYAGER) \ + || (PPC64 && (PPC_PSERIES || PPC_PMAC)) || ARM depends on SMP default y @@ -92,7 +93,8 @@ config PM_SLEEP config SUSPEND bool "Suspend to RAM and standby" depends on PM - depends on !SMP || SUSPEND_SMP_POSSIBLE + depends on SUSPEND_SMP_POSSIBLE || ((BLACKFIN || MIPS || SUPERH || FRV \ + || (PPC32 && PPC_MPC52xx)) && !SMP) default y ---help--- Allow the system to enter sleep states in which main memory is @@ -102,7 +104,8 @@ config SUSPEND config HIBERNATION bool "Hibernation (aka 'suspend to disk')" depends on PM && SWAP - depends on ((X86 || PPC64_SWSUSP || FRV || PPC32) && !SMP) || SUSPEND_SMP_POSSIBLE + depends on ((X86 || PPC64_SWSUSP || FRV || PPC32) && !SMP) \ + || ((X86 || PPC64_SWSUSP) && SUSPEND_SMP_POSSIBLE) ---help--- Enable the suspend to disk (STD) functionality, which is usually called "hibernation" in user interfaces. STD checkpoints the - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] libata: add human-readable error value decoding v3
On Fri, 03 Aug 2007 12:00:57 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote: > This adds human-readable decoding of the ATA status and error registers > (similar to what drivers/ide does) as well as the SATA Serror register to > libata error handling output. This prevents the need to pore through > standards documents to figure out the meaning of the bits in these > registers when looking at error reports. Some bits that drivers/ide > decoded are not decoded here, since the bits are either command-dependent > or obsolete, and properly parsing them would add too much complexity. Not sure its really worth it. Does "ABRT IDNF" actually tell you any more than the hex code ? In fact I find the hex code clearer because its usually the combination of state (0x51) etc that tells the story. No objection to it going in and on a correctness basis Acked-by: Alan Cox <[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-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes
On Fri, Aug 03, 2007 at 05:17:24PM -0400, Alan Stern wrote: > On Fri, 3 Aug 2007, Dave Jones wrote: > > > here's a head start for you. > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243038 > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246713 > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243953 > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242359 > > > > That's just the ones that were handy.. > > The last report appears to be related more to the EHCI-cpufreq problem, > for which a patch was recently posted. I was a bit iffy about including that one, but decided to because some of the reporters noted that the problem 'went away' after we pushed out a kernel disabling usb suspend by default. See comments 16 & 17. Clearly not the problem everyone was seeing, but it looks like a few people piled on one bug with the same symptom from multiple problems. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes
On Fri, Aug 03, 2007 at 05:17:24PM -0400, Alan Stern wrote: > The last report appears to be related more to the EHCI-cpufreq problem, > for which a patch was recently posted. There seem to be multiple issues there, with at least one of them being autosuspend related. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/3] 2.6.23-rc1: known regressions v3
On Tuesday 31 July 2007 00:07, Alexey Starikovskiy wrote: > Meelis Roos wrote: > >>> Subject : New ACPI error/warning with Linus' latest GIT > >>> References : http://lkml.org/lkml/2007/7/26/395 > >>> Last known good : ? > >>> Submitter : Ismail Dönmez <[EMAIL PROTECTED]> > >>> Caused-By : ? > >>> Handled-By : ? > >>> Status : unknown > >> This started to happen after the second ACPI merge which was for > >> 2.6.23-rc2. > > > > It appeared after new Embedded Controller code was merged into ACPI. It > > might as well be just a debug message or a remainder to add support for > > new queries (whatever these are), but I do not know. The message itself > > seems harmless. > > > This _is_ a debug message. EC asks us to perform query which was never > defined in DSDT. > Previously I thought it would be rare error report, but now it seems that > every machine > has at least one unregistered query... It is not a functional regression, as > we just > ignored errors from query execution before. > > Len already has a patch to remove this printk. yes, this verbose message has been removed. thanks, -Len commit f1cd1fe61b96e4312312d42c0a9784dfab12e007 Author: Alexey Starikovskiy <[EMAIL PROTECTED]> Date: Fri Aug 3 17:28:17 2007 -0400 ACPI: EC: Remove noisy debug printk fron EC driver. ACPI: EC: Handler for query 0x57 is not found! Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c index 469f3f5..dd384ec 100644 --- a/drivers/acpi/ec.c +++ b/drivers/acpi/ec.c @@ -471,7 +471,6 @@ static void acpi_ec_gpe_query(void *ec_cxt) } } mutex_unlock(&ec->lock); - printk(KERN_ERR PREFIX "Handler for query 0x%x is not found!\n", value); } static u32 acpi_ec_gpe_handler(void *data) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch maintainers: define O_CLOEXEC correctly!
From: Ulrich Drepper <[EMAIL PROTECTED]> Date: Fri, 03 Aug 2007 10:09:16 -0700 > Affected as far as I know: > > Alpha: probably needs value 01000 > > Sparc*: -"- 0x40 I've fixed sparc, thanks for reporting this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes
On Fri, 3 Aug 2007, Dave Jones wrote: > here's a head start for you. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243038 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246713 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243953 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242359 > > That's just the ones that were handy.. The last report appears to be related more to the EHCI-cpufreq problem, for which a patch was recently posted. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dynamic major/minor numbers (or dropping them completely)
Eduard-Gabriel Munteanu wrote: *This message was transferred with a trial version of CommuniGate(r) Pro* Currently, the kernel has the following properties: 1) initramfs can be used to boot the system. We don't need any predefined /dev entries. 2) udev can be started from the initramfs to create the required entries in /dev. udev doesn't care about major/minor numbers. 3) Most distros already use udev and maybe initramfs. If there are exceptions, they can be easily converted. For the first part, I'm asking: is there any reason why new char/block drivers shouldn't use dynamic major/minor numbers? Is there any reason against converting the whole kernel to dynamic major/minor numbers? Okay, maybe the previous questions looked useless from a pragmatic POV. But why shouldn't the whole major/minor numbering system be dropped completely? sysfs already maintains a hierachy of device drivers and kernel subsystems, one which is better than the major/minor system. The current system could be replaced by a single-numbered, dynamically-allocated scheme. Device files could be stored on a tmpfs filesystem, so that we don't make any changes to current filesystems. Apps won't need to be modified, since they access /dev entries by name, provided udev maintains the current naming scheme. Any thoughts on this? You're correct that dynamic major/minor numbers are sufficient for most purposes, but embedded users really need their static numbers. As for ripping out major/minor numberings, that's a non-starter. Too much of our device management infrastructure is based around this numbering scheme, and there isn't really anything wrong with it to justify breaking everything in the change. As a rule of thumb, if you ever find yourself wondering why we still support doing statically something we can now do dynamically, the answer is generally that doing it dynamically sucks for embedded. -- 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] kill an obsolete sub-thread-ptrace stuff
There is a couple of subtle checks which were needed to handle ptracing from the same thread group. This was deprecated a long ago, imho this code just complicates the understanding. And, the "->parent->signal->flags & SIGNAL_GROUP_EXIT" check in exit_notify() is not right. SIGNAL_GROUP_EXIT can mean exec(), not exit_group(). This means ptracer can lose a ptraced zombie on exec(). Minor problem, but still the bug. Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]> --- t/kernel/exit.c~PT_TG 2007-08-03 18:05:52.0 +0400 +++ t/kernel/exit.c 2007-08-03 21:10:40.0 +0400 @@ -802,7 +802,7 @@ static void exit_notify(struct task_stru __kill_pgrp_info(SIGCONT, SEND_SIG_PRIV, pgrp); } - /* Let father know we died + /* Let father know we died * * Thread signals are configurable, but you aren't going to use * that to send signals to arbitary processes. @@ -815,9 +815,7 @@ static void exit_notify(struct task_stru * If our self_exec id doesn't match our parent_exec_id then * we have changed execution domain as these two values started * the same after a fork. -* */ - if (tsk->exit_signal != SIGCHLD && tsk->exit_signal != -1 && ( tsk->parent_exec_id != t->self_exec_id || tsk->self_exec_id != tsk->parent_exec_id) @@ -837,9 +835,7 @@ static void exit_notify(struct task_stru } state = EXIT_ZOMBIE; - if (tsk->exit_signal == -1 && - (likely(tsk->ptrace == 0) || -unlikely(tsk->parent->signal->flags & SIGNAL_GROUP_EXIT))) + if (tsk->exit_signal == -1 && likely(!tsk->ptrace)) state = EXIT_DEAD; tsk->exit_state = state; --- t/kernel/signal.c~PT_TG 2007-07-28 16:58:17.0 +0400 +++ t/kernel/signal.c 2007-08-03 21:11:59.0 +0400 @@ -1561,10 +1561,6 @@ static inline int may_ptrace_stop(void) (current->ptrace & PT_ATTACHED))) return 0; - if (unlikely(current->signal == current->parent->signal) && - unlikely(current->signal->flags & SIGNAL_GROUP_EXIT)) - return 0; - /* * Are we in the middle of do_coredump? * If so and our tracer is also part of the coredump stopping - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] lro: myri10ge example how to use LRO
Kok, Auke wrote: Andrew Gallatin wrote: To follow up on Jan-Bernd Themann's LRO patch earlier today, this patch shows how the generic LRO interface can be used for page based drivers. Again, many thanks to Jan-Bernd Themann for leading this effort. Drew Singed off by: Andrew Gallatin <[EMAIL PROTECTED]> please take a look at my lro patch for ethtool and see if it works for you, instead of adding another generic module parameter that doesn't need to be there. That looks very nice, and will indeed work for me. Thanks, Drew - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Oops when using dm-crypt with dpt_i2o
On Fri, 03 Aug 2007 22:46:14 +0200 Philipp T__lke <[EMAIL PROTECTED]> wrote: > Hi Andrew, hi everybody! > > Thanks for the reply! > > Andrew Morton wrote: > >> The oopses: > >> > >> #v+ > >> BUG: unable to handle kernel paging request at virtual address 14001000 > >> [...] > > > > So it looks like q->request_fn points at 0x14001000, which is in outer > > space. > > > > I wonder how that could happen, in the middle of heavy IO operations. > > Possibly a memory scribble. I'd suggest you enable CONFIG_SLAB, > > CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC. > > That doesn't change anything, apart from adding a line "DEBUG_PAGEALLOC" > to the oopses. drat. > Do I have to enable the debugging manually? After a quick > grep over the sources and a google-session I think not but I'm no > kernel-hacker. No, just enable it. > > You could also try switching > > from CONFIG_SLAB to CONFIG_SLUB, then enable CONFIG_SLUB_DEBUG. > > Unfortunately the only change seems to be, that the Keyboard-Leds don't > flash after the crash. Everything else is the same. drat. > Could a hardware-error cause this? It sounds unlikely. One wouldn't expect it to crash in the same way each time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix local_irq_* macro definition thinkos for the !TRACE_IRQFLAGS_SUPPORT case
From: George G. Davis <[EMAIL PROTECTED]> Fix local_irq_* macro definition errors for the !TRACE_IRQFLAGS_SUPPORT case in which the macros are errantly "redefined" rather than defined. Signed-off-by: George G. Davis <[EMAIL PROTECTED]> diff --git a/include/linux/irqflags.h b/include/linux/irqflags.h index 412e025..49a3df8 100644 --- a/include/linux/irqflags.h +++ b/include/linux/irqflags.h @@ -67,10 +67,10 @@ * The local_irq_*() APIs are equal to the raw_local_irq*() * if !TRACE_IRQFLAGS. */ -# define raw_local_irq_disable() local_irq_disable() -# define raw_local_irq_enable()local_irq_enable() -# define raw_local_irq_save(flags) local_irq_save(flags) -# define raw_local_irq_restore(flags) local_irq_restore(flags) +# define local_irq_disable() raw_local_irq_disable() +# define local_irq_enable()raw_local_irq_enable() +# define local_irq_save(flags) raw_local_irq_save(flags) +# define local_irq_restore(flags) raw_local_irq_restore(flags) #endif /* CONFIG_TRACE_IRQFLAGS_SUPPORT */ #ifdef CONFIG_TRACE_IRQFLAGS_SUPPORT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
spurious NCQ completions from FUJITSU MHW2120BH
Todays git gave me some EH errors during fsck (30 times mounted and time to check), then recovered and works fine. Seems to be spurious NCQ completion. The disk is Device Model: FUJITSU MHW2120BH Firmware Version: 0012 User Capacity:120 034 123 776 bytes Tried Debian 2.6.22-1-686 and yes, I can trigger the spurious NCQ there too during fsck. So does this fujitsu disk have buggy NCQ? Linux version 2.6.23-rc1 ([EMAIL PROTECTED]) (gcc version 4.1.3 20070718 (prerelease) (Debian 4.1.2-14)) #1 SMP PREEMPT Thu Aug 2 19:31:18 EEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 3fed (usable) BIOS-e820: 3fed - 3fee3000 (ACPI NVS) BIOS-e820: 3fee3000 - 4000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fed0 - fed00400 (reserved) BIOS-e820: fed14000 - fed1a000 (reserved) BIOS-e820: fed1c000 - fed9 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ff00 - 0001 (reserved) 126MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000f7c80 Entering add_active_range(0, 0, 261840) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 HighMem229376 -> 261840 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -> 261840 On node 0 totalpages: 261840 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 HighMem zone: 253 pages used for memmap HighMem zone: 32211 pages, LIFO batch:7 Movable zone: 0 pages used for memmap DMI present. ACPI: RSDP 000F7C00, 0024 (r2 Compal) ACPI: XSDT 3FED88D3, 008C (r1 Compal CRESTLNE 604 LTP0) ACPI: FACP 3FEDFBD2, 00F4 (r3 INTEL CRESTLNE 604 ALAN1) ACPI: DSDT 3FED9C80, 5EDE (r2 Compal CRESTLNE 604 INTL 20061109) ACPI: FACS 3FEE2FC0, 0040 ACPI: APIC 3FEDFCC6, 0068 (r1 INTEL CRESTLNE 604 LOHR 5A) ACPI: HPET 3FEDFD2E, 0038 (r1 Compal CRESTLNE 604 LOHR 5A) ACPI: MCFG 3FEDFD66, 003C (r1 INTEL CRESTLNE 604 LOHR 5A) ACPI: TCPA 3FEDFDA2, 0032 (r1 Intel CRESTLNE 604 LOHR 5A) ACPI: TMOR 3FEDFDD4, 0026 (r1 PTLTD604 PTL 3) ACPI: SLIC 3FEDFDFA, 0176 (r1 Compal CRESTLNE 604 TBD 1) ACPI: APIC 3FEDFF70, 0068 (r1 PTLTD APIC604 LTP0) ACPI: BOOT 3FEDFFD8, 0028 (r1 PTLTD $SBFTBL$ 604 LTP1) ACPI: SSDT 3FED99BB, 02C5 (r1 SataRe SataAhci 1000 INTL 20050624) ACPI: SSDT 3FED8EEB, 025F (r1 PmRef Cpu0Tst 3000 INTL 20050624) ACPI: SSDT 3FED8E45, 00A6 (r1 PmRef Cpu1Tst 3000 INTL 20050624) ACPI: SSDT 3FED895F, 04E6 (r1 PmRefCpuPm 3000 INTL 20050624) ACPI: BIOS bug: multiple APIC/MADT found, using 0 ACPI: If "acpi_apic_instance=2" works better, notify [EMAIL PROTECTED] ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 6:15 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs ACPI: HPET id: 0x8086a201 base: 0xfed0 Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 5000 (gap: 4000:bec0) swsusp: Registered nosave memory region: 0009f000 - 000a swsusp: Registered nosave memory region: 000a - 000dc000 swsusp: Registered nosave memory region: 000dc000 - 0010 Built 1 zonelists in Zone order. Total pages: 259795 Kernel command line: root=/dev/sda1 ro resume=/dev/sda2 mapped APIC to b000 (fee0) mapped IOAPIC to a000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c03df000 soft=c03d7000 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 1995.062 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1027676k/1047360k available (1978k ker
Re: PROBLEM: Oops when using dm-crypt with dpt_i2o
Hi Andrew, hi everybody! Thanks for the reply! Andrew Morton wrote: >> The oopses: >> >> #v+ >> BUG: unable to handle kernel paging request at virtual address 14001000 >> [...] > > So it looks like q->request_fn points at 0x14001000, which is in outer > space. > > I wonder how that could happen, in the middle of heavy IO operations. > Possibly a memory scribble. I'd suggest you enable CONFIG_SLAB, > CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC. That doesn't change anything, apart from adding a line "DEBUG_PAGEALLOC" to the oopses. Do I have to enable the debugging manually? After a quick grep over the sources and a google-session I think not but I'm no kernel-hacker. > You could also try switching > from CONFIG_SLAB to CONFIG_SLUB, then enable CONFIG_SLUB_DEBUG. Unfortunately the only change seems to be, that the Keyboard-Leds don't flash after the crash. Everything else is the same. Could a hardware-error cause this? Thanks again, -- Philipp Tölke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Asus A8N-SLI Deluxe latest BIOS wants acpi_use_timer_override
> Is it possible to open a bugzilla and drop the acpidump and dmesg > from both the new and old BIOS in it? My guess is that they changed some bits outside the DSDT. But ok makes sense. > Assuming the override in both cases is identical, I'm really baffled > by this failure. It seems that the new BIOS is playing some tricks > that we have not seen before, as your hardware didn't change... There is some flexibility in how the interrupt gets delivered, since it gets converted to a HT message and the Northbridge has a few tweaks for processing those. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lro: myri10ge example how to use LRO
Andrew Gallatin wrote: To follow up on Jan-Bernd Themann's LRO patch earlier today, this patch shows how the generic LRO interface can be used for page based drivers. Again, many thanks to Jan-Bernd Themann for leading this effort. Drew Singed off by: Andrew Gallatin <[EMAIL PROTECTED]> please take a look at my lro patch for ethtool and see if it works for you, instead of adding another generic module parameter that doesn't need to be there. Thanks. Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] lro: eHEA example how to use LRO
Jan-Bernd Themann wrote: This patch shows how the generic LRO interface is used for SKB mode Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]> --- drivers/net/Kconfig |1 + drivers/net/ehea/ehea.h |9 - drivers/net/ehea/ehea_ethtool.c | 15 +++ drivers/net/ehea/ehea_main.c| 84 +++--- 4 files changed, 101 insertions(+), 8 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index f8a602c..fec4004 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig +module_param(use_lro, int, 0); Have you looked at my generic lro get/set patch that I posted this week? this adds a useless module parameter while ethtool has all the structure already to accomodate setting lro on/off. Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Asus A8N-SLI Deluxe latest BIOS wants acpi_use_timer_override
On Friday 03 August 2007 16:01, Andi Kleen wrote: > On Friday 03 August 2007 20:38:17 Robert Hancock wrote: > > It appears that the latest BIOS version 1805 for the ASUS A8N-SLI Deluxe > > board fixes the broken ACPI timer override that was in earlier versions, > > and which the kernel ignores on nForce4 chipsets. Now the same override: > > > > ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > > > > seems to be needed, since without acpi_use_timer_override we end up > > getting this (with apic=verbose): > > That's really bad. > > > ..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1 > > ..MP-BIOS bug: 8254 timer not connected to IO-APIC > > ...trying to set up timer (IRQ0) through the 8259A ... failed. > > ...trying to set up timer as Virtual Wire IRQ... failed. > > ...trying to set up timer as ExtINT IRQ... works. > > > > and the timer IRQ ends up routed as XT-PIC instead of IO-APIC-edge. With > > acpi_use_timer_override we just get: > > > > ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 > > > > and it works through the IO-APIC. > > > > I should think there must be a better way to handle this automatically.. > > I have pending patches to key the NF5 case on the PCI-ID, but > that obviously cannot be done for NF4. > > I cannot think of anything good but putting DMI BIOS version > checks in for that specific board. > > > Is there some way we can tell, given we have a chipset with a > > potentially broken BIOS, from the configuration of the IOAPIC whether > > the timer override is needed or not? Unfortunately I don't have output > > from apic=verbose with the old BIOS with the broken override, but maybe > > somebody else can provide that.. > > We don't really know which pins are connected where. This means they > likely have some bits they tweaked to get the different behaviour, but > they're > unknown. There are also some northbridge bits that can be tweaked > (e.g. some of the ATI BIOS workarounds used to use that) > but it's still unknown what the Nvidia chipset actually does and if > they really help here. > > Ok in theory you could diff config space dumps between the two BIOS > versions to try to figure it out, but that would be still pretty risky > and I don't think it would be a good idea to trust such results. Is it possible to open a bugzilla and drop the acpidump and dmesg from both the new and old BIOS in it? Assuming the override in both cases is identical, I'm really baffled by this failure. It seems that the new BIOS is playing some tricks that we have not seen before, as your hardware didn't change... thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pxa2xx PCMCIA timing issue on iPAQ H5550
Good day,
recently I've been trying to get working PCMCIA interface on H5000
ipaq series, using dual PCMCIA sleeve. So far things work correctly, but
I had to do one modification to drivers/pcmcia/pxa2xx_base.c to get the
interface working with orinoco gold PCMCIA card (wired pcnet_cs ethernet
card worked even without this modification). Patch attached.
The issue has something to do with assert time on PCMCIA bus, but I'm
not really sure what -- I found the working value just by trial&error
approach. I'm not sure how is the assert value in pxa2xx_mcxx_asst
calculated (I know, simple formula, but the reason why is it calculated
that way is not obvious for me), neither that my modification is
correct. It just works with iPAQ.
Please include me in Cc, as I'm not subscribed to neither of mailing
lists.
Best regards,
Milan Plzik
Index: drivers/pcmcia/pxa2xx_base.c
===
RCS file: /cvs/linux/kernel26/drivers/pcmcia/pxa2xx_base.c,v
retrieving revision 1.12
diff -a -u -r1.12 pxa2xx_base.c
--- drivers/pcmcia/pxa2xx_base.c 10 Mar 2007 11:46:02 - 1.12
+++ drivers/pcmcia/pxa2xx_base.c 3 Aug 2007 20:04:10 -
@@ -59,7 +59,7 @@
u_int mem_clk_10khz)
{
u_int code = pcmcia_cycle_ns * mem_clk_10khz;
- return (code / 30) + ((code % 30) ? 1 : 0) - 1;
+ return (code / 30) + ((code % 30) ? 1 : 0) + 1;
}
static inline u_int pxa2xx_mcxx_setup(u_int pcmcia_cycle_ns,
Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes
On Fri, Aug 03, 2007 at 10:44:35AM -0700, Greg KH wrote: > On Fri, Aug 03, 2007 at 01:32:53PM +0100, Matthew Garrett wrote: > > On Fri, Aug 03, 2007 at 02:26:43PM +0200, Rogan Dawes wrote: > > > > > Compare that to: > > > > > > "My USB printer broke, guess I'd better report it to LKML". > > > > But while this is still a likely probability, the chances are no > > distribution is going to ship with CONFIG_USB_SUSPEND enabled. > > I wouldn't be so sure, I was thinking of doing just that based on an > internal conversation I had yesterday. > > Let's see what breaks and what happens :) here's a head start for you. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243038 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246713 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243953 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242359 That's just the ones that were handy.. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc] balance-on-fork NUMA placement
On Fri, Aug 03, 2007 at 02:20:10AM +0200, Nick Piggin wrote: > On Thu, Aug 02, 2007 at 11:33:39AM -0700, Martin Bligh wrote: > > Nick Piggin wrote: > > >On Wed, Aug 01, 2007 at 03:52:11PM -0700, Martin Bligh wrote: > > >>>And so forth. Initial forks will balance. If the children refuse to > > >>>die, forks will continue to balance. If the parent starts seeing short > > >>>lived children, fork()s will eventually start to stay local. > > >>Fork without exec is much more rare than without. Optimising for > > >>the uncommon case is the Wrong Thing to Do (tm). What we decided > > > > > >It's only the wrong thing to do if it hurts the common case too > > >much. Considering we _already_ balance on exec, then adding another > > >balance on fork is not going to introduce some order of magnitude > > >problem -- at worst it would be 2x but it really isn't too slow > > >anyway (at least nobody complained when we added it). > > > > > >One place where we found it helps is clone for threads. > > > > > >If we didn't do such a bad job at keeping tasks together with their > > >local memory, then we might indeed reduce some of the balance-on-crap > > >and increase the aggressiveness of periodic balancing. > > > > > >Considering we _already_ balance on fork/clone, I don't know what > > >your argument is against this patch is? Doing the balance earlier > > >and allocating more stuff on the local node is surely not a bad > > >idea. > > > > I don't know who turned that on ;-( I suspect nobody bothered > > actually measuring it at the time though, or used some crap > > benchmark like stream to do so. It should get reverted. > > So you have numbers to show it hurts? I tested some things where it > is not supposed to help, and it didn't make any difference. Nobody > else noticed either. > > If the cost of doing the double balance is _really_ that painful, > then we ccould skip balance-on-exec for domains with balance-on-fork > set. Nick, Even if it is not painful, can we skip balance-on-exec if balance-on-fork is set. There is no need for double balance, right? Especially with the optimization you are trying to do with this patch, balance-on-exec may lead to wrong decision making this optimization not work as expected. or perhaps do balance-on-fork based on clone_flags.. thanks, suresh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Processes spinning forever, apparently in lock_timer_base()?
Chuck Ebbert wrote:
>
> Looks like the same problem with spinlock unfairness we've seen
> elsewhere: it seems to be looping here? Or is everyone stuck
> just waiting for writeout?
>
> lock_timer_base():
> for (;;) {
> tvec_base_t *prelock_base = timer->base;
> base = tbase_get_base(prelock_base);
> if (likely(base != NULL)) {
> spin_lock_irqsave(&base->lock, *flags);
> if (likely(prelock_base == timer->base))
> return base;
> /* The timer has migrated to another CPU */
> spin_unlock_irqrestore(&base->lock, *flags);
> }
> cpu_relax();
> }
I don't think there is an unfairness problem. We are looping only
if timer->base changes in between. IOW, there is no "lock + unlock
+ lock(same_lock)" here, we take another lock on each iteration.
And:
> [] do_IRQ+0xbd/0xd1
> [] lock_timer_base+0x19/0x35
> [] __mod_timer+0x9a/0xa4
> [] schedule_timeout+0x70/0x8f
>
> ...
>
> [] do_IRQ+0xbd/0xd1
> [] lock_timer_base+0x19/0x35
> [] __mod_timer+0x9a/0xa4
> [] schedule_timeout+0x70/0x8f
>
> ...
>
> [] lock_timer_base+0x19/0x35
> [] __mod_timer+0x9a/0xa4
> [] schedule_timeout+0x70/0x8f
All traces start from schedule_timeout()->mod_timer(). This timer
is local, nobody can see it, its ->base can't be NULL or changed.
This means that lock_timer_base() can't loop, but can't take the
tvec_t_base_s.lock. But in that case the trace should different,
strange.
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes
On Fri, Aug 03, 2007 at 06:08:11PM +0200, Oliver Neukum wrote: > Am Freitag 03 August 2007 schrieb Matthew Garrett: > > > Which is why I didn't suggest doing that, of course. The only > > > one making that kind of straw man argument seems to be you. > > > > But however you phrase it, that's effectively what it is. "Does your > > device work?" just makes users wonder why the damn computer doesn't know > > already. "This option may prevent your device from working. Click here > > to switch it off" results in them wondering why it was switched on in > > the first place. Many of our users aren't technical - they don't care > > about saving 200mW, they just care about their printer working when they > > plug it in. > > Devices rarely simply crash. Although Windows doesn't do runtime power > management, it certainly will suspend all devices when the system goes > into suspension. Buggy devices typically disconnect and reconnect when > resumed. This is testable for in software without user intervention. The printer I mentioned earlier this thread wouldn't work again until I physically unplugged and replugged the usb cable. It spewed descriptor read errors every time I tried to talk to it. Even unloading and reloading the usb modules didn't bring it back to life. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch v2] fuse: fix permission checking on sticky directories
From: Miklos Szeredi <[EMAIL PROTECTED]>
The VFS checks sticky bits on the parent directory even if the
filesystem defines it's own ->permission(). In some situations
(sshfs, mountlo, etc) the user does have permission to delete a file
even if the attribute based checking would not allow it.
So work around this by storing the permission bits separately and
returning them in stat(), but cutting the permission bits off from
inode->i_mode.
This is slightly hackish, but it's probably not worth it to add new
infrastructure in VFS and a slight performance penalty for all
filesystems, just for the sake of fuse.
[Jan Engelhardt] cosmetic fixes
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
---
Index: linux/fs/fuse/dir.c
===
--- linux.orig/fs/fuse/dir.c2007-08-03 21:57:53.0 +0200
+++ linux/fs/fuse/dir.c 2007-08-03 21:57:58.0 +0200
@@ -1054,8 +1054,10 @@ static int fuse_getattr(struct vfsmount
if (fi->i_time < get_jiffies_64())
err = fuse_do_getattr(inode);
- if (!err)
+ if (!err) {
generic_fillattr(inode, stat);
+ stat->mode = fi->orig_i_mode;
+ }
return err;
}
Index: linux/fs/fuse/fuse_i.h
===
--- linux.orig/fs/fuse/fuse_i.h 2007-08-03 21:57:53.0 +0200
+++ linux/fs/fuse/fuse_i.h 2007-08-03 21:58:23.0 +0200
@@ -63,6 +63,10 @@ struct fuse_inode {
/** Time in jiffies until the file attributes are valid */
u64 i_time;
+
+ /** The sticky bit in inode->i_mode may have been removed, so
+ preserve the original mode */
+ mode_t orig_i_mode;
};
/** FUSE specific file data */
Index: linux/fs/fuse/inode.c
===
--- linux.orig/fs/fuse/inode.c 2007-08-03 21:57:53.0 +0200
+++ linux/fs/fuse/inode.c 2007-08-03 21:58:23.0 +0200
@@ -120,10 +120,18 @@ static void fuse_truncate(struct address
void fuse_change_attributes(struct inode *inode, struct fuse_attr *attr)
{
struct fuse_conn *fc = get_fuse_conn(inode);
+ struct fuse_inode *fi = get_fuse_inode(inode);
loff_t oldsize;
inode->i_ino = attr->ino;
- inode->i_mode= (inode->i_mode & S_IFMT) + (attr->mode & 0);
+ fi->orig_i_mode = (inode->i_mode & S_IFMT) | (attr->mode & 0);
+ /*
+* Don't set the mode bits in i_mode, unless we want the VFS
+* to check permissions. This prevents failures due to the
+* sticky bit check in may_delete().
+*/
+ if (fc->flags & FUSE_DEFAULT_PERMISSIONS)
+ inode->i_mode = fi->orig_i_mode;
inode->i_nlink = attr->nlink;
inode->i_uid = attr->uid;
inode->i_gid = attr->gid;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: Only enable autosuspend by default on certain device classes
On Fri, 3 Aug 2007 15:45:32 -0400, Dave Jones <[EMAIL PROTECTED]> wrote: > > > My experience suggests the opposite. Of the several I've tried so far, > > > none have worked with usb suspend. > > > > All of mine work. I'm wondering if this has something to do with > > a hub or motherboard... How should we test it? Tried plugging elsewhere? > > no hubs involved, directly plugged them into the mainboard. > Fairly recent Intel chipsets on all the systems I tested. Sounds bad. BTW, when I took over from Vojtech, I looked at the suspend methods for the printer and it seemed possible that they can only work if the device is not open when suspend occurs. I was going to look at that at the first opportunity. So, I'd rather keep at least some kind of capability to suspend printers, even if disabled by default. I thought Matthew's patch was too harsh. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: Only enable autosuspend by default on certain device classes
On Fri, 03 Aug 2007 15:29:21 -0400, Chuck Ebbert <[EMAIL PROTECTED]> wrote: > > Well, we did - with hindsight it may not have been such a great plan :) > > I believe that Fedora did as well, but have disabled it in an update > > kernel. > > Yeah, autosuspend broke too many devices. Way too many. Glad you chimed in, Chuck. I was wondering about it... I saw something like 3 reports about broken printers, two of them for the same printer, Samsung ML-2010. It's on the installed base of 300,000 to 500,000. People simply do not report squat. Today DaveJ said that none of his printers work, which sounds bad, and was news to me. But the point is, we are trying to extrapolate from too few cases. I am wondering if Ubuntu has better user reporting, so if Matthew complains, it really means something. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Asus A8N-SLI Deluxe latest BIOS wants acpi_use_timer_override
On Friday 03 August 2007 20:38:17 Robert Hancock wrote: > It appears that the latest BIOS version 1805 for the ASUS A8N-SLI Deluxe > board fixes the broken ACPI timer override that was in earlier versions, > and which the kernel ignores on nForce4 chipsets. Now the same override: > > ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > > seems to be needed, since without acpi_use_timer_override we end up > getting this (with apic=verbose): That's really bad. > ..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1 > ..MP-BIOS bug: 8254 timer not connected to IO-APIC > ...trying to set up timer (IRQ0) through the 8259A ... failed. > ...trying to set up timer as Virtual Wire IRQ... failed. > ...trying to set up timer as ExtINT IRQ... works. > > and the timer IRQ ends up routed as XT-PIC instead of IO-APIC-edge. With > acpi_use_timer_override we just get: > > ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 > > and it works through the IO-APIC. > > I should think there must be a better way to handle this automatically.. I have pending patches to key the NF5 case on the PCI-ID, but that obviously cannot be done for NF4. I cannot think of anything good but putting DMI BIOS version checks in for that specific board. > Is there some way we can tell, given we have a chipset with a > potentially broken BIOS, from the configuration of the IOAPIC whether > the timer override is needed or not? Unfortunately I don't have output > from apic=verbose with the old BIOS with the broken override, but maybe > somebody else can provide that.. We don't really know which pins are connected where. This means they likely have some bits they tweaked to get the different behaviour, but they're unknown. There are also some northbridge bits that can be tweaked (e.g. some of the ATI BIOS workarounds used to use that) but it's still unknown what the Nvidia chipset actually does and if they really help here. Ok in theory you could diff config space dumps between the two BIOS versions to try to figure it out, but that would be still pretty risky and I don't think it would be a good idea to trust such results. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] msleep() with hrtimers
Hi, On Fri, 3 Aug 2007, Arjan van de Ven wrote: > On Fri, 2007-08-03 at 21:19 +0200, Roman Zippel wrote: > > Hi, > > > > On Fri, 3 Aug 2007, Jonathan Corbet wrote: > > > > > Most comments last time were favorable. The one dissenter was Roman, > > > who worries about the overhead of using hrtimers for this operation; my > > > understanding is that he would rather see a really_msleep() function for > > > those who actually want millisecond resolution. I'm not sure how to > > > characterize what the cost could be, but it can only be buried by the > > > fact that every call sleeps for some number of milliseconds. On my > > > system, the several hundred total msleep() calls can't cause any real > > > overhead, and almost all happen at initialization time. > > > > The main point is still that these are two _different_ APIs for different > > usages, so I still prefer to add a hrsleep() instead. > > > I would actually prefer it the other way around; call the > not-so-accurate one "msleep_approx()" or somesuch, to make it explicit > that the sleep is only approximate... Actually the hrsleep() function would allow for submillisecond sleeps, which might be what some of the 450 users really want and they only use msleep(1) because it's the next best thing. A hrsleep() function is really what makes most sense from an API perspective. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Distributed storage.
On Friday 03 August 2007 07:53, Peter Zijlstra wrote: > On Fri, 2007-08-03 at 17:49 +0400, Evgeniy Polyakov wrote: > > On Fri, Aug 03, 2007 at 02:27:52PM +0200, Peter Zijlstra wrote: > > ...my main position is to > > allocate per socket reserve from socket's queue, and copy data > > there from main reserve, all of which are allocated either in > > advance (global one) or per sockoption, so that there would be no > > fairness issues what to mark as special and what to not. > > > > Say we have a page per socket, each socket can assign a reserve for > > itself from own memory, this accounts both tx and rx side. Tx is > > not interesting, it is simple, rx has global reserve (always > > allocated on startup or sometime way before reclaim/oom)where data > > is originally received (including skb, shared info and whatever is > > needed, page is just an exmaple), then it is copied into per-socket > > reserve and reused for the next packet. Having per-socket reserve > > allows to have progress in any situation not only in cases where > > single action must be received/processed, and allows to be > > completely fair for all users, but not only special sockets, thus > > admin for example would be allowed to login, ipsec would work and > > so on... > > Ah, I think I understand now. Yes this is indeed a good idea! > > It would be quite doable to implement this on top of that I already > have. We would need to extend the socket with a sock_opt that would > reserve a specified amount of data for that specific socket. And then > on socket demux check if the socket has a non zero reserve and has > not yet exceeded said reserve. If so, process the packet. > > This would also quite neatly work for -rt where we would not want > incomming packet processing to be delayed by memory allocations. At this point we need "anything that works" in mainline as a starting point. By erring on the side of simplicity we can make this understandable for folks who haven't spent the last two years wallowing in it. The page per socket approach is about as simple as it gets. I therefore propose we save our premature optimizations for later. It will also help our cause if we keep any new internal APIs to strictly what is needed to make deadlock go away. Not a whole lot more than just the flag to mark a socket as part of the vm writeout path when you get right down to essentials. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] msleep() with hrtimers
On Fri, 2007-08-03 at 21:19 +0200, Roman Zippel wrote: > Hi, > > On Fri, 3 Aug 2007, Jonathan Corbet wrote: > > > Most comments last time were favorable. The one dissenter was Roman, > > who worries about the overhead of using hrtimers for this operation; my > > understanding is that he would rather see a really_msleep() function for > > those who actually want millisecond resolution. I'm not sure how to > > characterize what the cost could be, but it can only be buried by the > > fact that every call sleeps for some number of milliseconds. On my > > system, the several hundred total msleep() calls can't cause any real > > overhead, and almost all happen at initialization time. > > The main point is still that these are two _different_ APIs for different > usages, so I still prefer to add a hrsleep() instead. I would actually prefer it the other way around; call the not-so-accurate one "msleep_approx()" or somesuch, to make it explicit that the sleep is only approximate... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes
On Fri, Aug 03, 2007 at 12:34:47PM -0700, Pete Zaitcev wrote: > On Fri, 3 Aug 2007 10:24:16 -0400, Dave Jones <[EMAIL PROTECTED]> wrote: > > On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote: > > > > > Kernel developers are a diverser lot than you think ;-) > > > We don't enable autosuspend in drivers we can't test, except where > > > the lack of a kernel driver forces us to use a broad swipe. Printers > > > were tested, too, and most printers seem to work. > > > > My experience suggests the opposite. Of the several I've tried so far, > > none have worked with usb suspend. > > All of mine work. I'm wondering if this has something to do with > a hub or motherboard... How should we test it? Tried plugging elsewhere? no hubs involved, directly plugged them into the mainboard. Fairly recent Intel chipsets on all the systems I tested. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Distributed storage.
On Friday 03 August 2007 06:49, Evgeniy Polyakov wrote: > ...rx has global reserve (always allocated on > startup or sometime way before reclaim/oom)where data is originally > received (including skb, shared info and whatever is needed, page is > just an exmaple), then it is copied into per-socket reserve and > reused for the next packet. Having per-socket reserve allows to have > progress in any situation not only in cases where single action must > be received/processed, and allows to be completely fair for all > users, but not only special sockets, thus admin for example would be > allowed to login, ipsec would work and so on... And when the global reserve is entirely used up your system goes back to dropping vm writeout acknowledgements, not so good. I like your approach, and specifically the copying idea cuts out considerable complexity. But I believe the per-socket flag to mark a socket as part of the vm writeout path is not optional, and in this case it will be a better world if it is a slightly unfair world in favor of vm writeout traffic. Ssh will still work fine even with vm getting priority access to the pool. During memory crunches, non-vm ssh traffic may get bumped till after the crunch, but vm writeout is never supposed to hog the whole machine. If vm writeout hogs your machine long enough to delay an ssh login then that is a vm bug and should be fixed at that level. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
lvcreate on 2.6.22.1: kernel tried to execute NX-protected page
Hi, I got the appended BUG from a 32-bit 2.6.22.1 kernel (with exec-shield patch and PAE enabled) on an Athlon64 with dmsetup 1.02.03 and lvm2 v2.02.02. (Note, the message comes from the vanilla kernel, not from the exec-shiled patch.) I wasn't able to reproduce the problem so far. The machine creates several snapshot volumes every 4 hours and worked fine with the new kernel for several days. It had 2.6.16.12+exec-shield before and ran flawlessy for over a year. kernel tried to execute NX-protected page - exploit attempt? (uid: 0) BUG: unable to handle kernel paging request at virtual address f551df78 printing eip: f551df78 *pdpt = 1001 *pde = 8000354001e3 *pte = 9293396c5d22e546 Oops: 0011 [#1] CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010286 (2.6.22.1-jk1-exec-shield #1) EIP is at 0xf551df78 eax: f551df4c ebx: f551df4c ecx: edx: f551df78 esi: f551df78 edi: ebp: esp: e8ee5db4 ds: 007b es: 007b fs: gs: 0033 ss: 0068 Process lvcreate (pid: 25916, ti=e8ee4000 task=f7358a00 task.ti=e8ee4000) Stack: c02088c4 f551df64 c02088d0 c03dd95e c64ccf00 c0209118 0287 c03dd95e 0287 c018e38b c03dd952 d3e460e8 c018e393 c192a90c c192b900 c03dd952 f557a600 f59bbcc0 c0157664 f557a64c f557a600 c01575be Call Trace: [kobject_cleanup+116/128] kobject_cleanup+0x74/0x80 [kobject_release+0/16] kobject_release+0x0/0x10 [kref_put+56/160] kref_put+0x38/0xa0 [sysfs_hash_and_remove+267/320] sysfs_hash_and_remove+0x10b/0x140 [sysfs_hash_and_remove+275/320] sysfs_hash_and_remove+0x113/0x140 [sysfs_slab_alias+100/128] sysfs_slab_alias+0x64/0x80 [sysfs_slab_add+174/208] sysfs_slab_add+0xae/0xd0 [kmem_cache_create+236/320] kmem_cache_create+0xec/0x140 [jobs_init+46/128] jobs_init+0x2e/0x80 [kcopyd_init+45/176] kcopyd_init+0x2d/0xb0 [kcopyd_client_create+28/208] kcopyd_client_create+0x1c/0xd0 [init_hash_tables+142/192] init_hash_tables+0x8e/0xc0 [snapshot_ctr+506/752] snapshot_ctr+0x1fa/0x2f0 [dm_split_args+47/272] dm_split_args+0x2f/0x110 [dm_table_add_target+252/400] dm_table_add_target+0xfc/0x190 [vmalloc+32/48] vmalloc+0x20/0x30 [populate_table+98/192] populate_table+0x62/0xc0 [table_load+82/240] table_load+0x52/0xf0 [table_load+0/240] table_load+0x0/0xf0 [ctl_ioctl+209/288] ctl_ioctl+0xd1/0x120 [ctl_ioctl+0/288] ctl_ioctl+0x0/0x120 [do_ioctl+59/96] do_ioctl+0x3b/0x60 [vfs_ioctl+94/416] vfs_ioctl+0x5e/0x1a0 [sys_ioctl+61/128] sys_ioctl+0x3d/0x80 [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85 === Code: 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <78> df 51 f5 78 df 51 f5 74 1b 8b f7 00 00 00 00 00 00 00 00 32 EIP: [] 0xf551df78 SS:ESP 0068:e8ee5db4 Juergen config-2.6.22.1-jk1-exec-shield.gz Description: Binary data -- Juergen Kreileder, Blackdown Java-Linux Team http://blog.blackdown.de/
Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes
On Fri, 3 Aug 2007 10:24:16 -0400, Dave Jones <[EMAIL PROTECTED]> wrote: > On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote: > > > Kernel developers are a diverser lot than you think ;-) > > We don't enable autosuspend in drivers we can't test, except where > > the lack of a kernel driver forces us to use a broad swipe. Printers > > were tested, too, and most printers seem to work. > > My experience suggests the opposite. Of the several I've tried so far, > none have worked with usb suspend. All of mine work. I'm wondering if this has something to do with a hub or motherboard... How should we test it? Tried plugging elsewhere? -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation of kernel messages (Summary)
On Friday 03 August 2007 1:11:55 pm Randy Dunlap wrote: > On Mon, 16 Jul 2007 15:53:06 -0400 Rob Landley wrote: > > On Sunday 15 July 2007 12:28:06 pm Randy Dunlap wrote: > > > On Sat, 14 Jul 2007 21:56:15 -0400 Rob Landley wrote: > > > > On Friday 13 July 2007 11:54:41 pm Randy Dunlap wrote: > > > > > > If there's interest, I can push some patches to clean up > > > > > > Documentation by moving files into subdirectories, but > > > > > > Documentation's not well-suited to link out to the web. (You > > > > > > need html for that, and it's text.) > > > > > > > > > > I think that you should start moving Documentation/ files around > > > > > and adding subdirectories -- if you are pretty sure of where they > > > > > should go (i.e., they won't likely be moved again later on). > > > > > > > > You mean like these? > > > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0705.3/2925.html > > > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0705.3/2924.html > > > > > > Yes. Have any of these been merged? > > > > Not that I know of. They seemed to meet with resounding indifference, so > > I went on to other things... > > You need to be persistent. Please re-submit this. Greg KH thinks it's a good idea to add language directories to the top level of Documentation, and there are slightly more than two of those: http://www.translatorscafe.com/cafe/Help.asp?HelpID=59 Since you think it's worth doing, I'll resubmit the work I've already done here, but I no longer think trying to shovel Documentation into some semblance of order against the will of people like Greg is a good use of time. These days I'm trying to create an html index that links into Documentation in a coherent order (with categories and everything), and using automated tools to detect files that aren't linked to, or links that point to a file that isn't there anymore. This is obviously still a work in progress, but I think it's a better approach. > and since it's just file & dir moves and done via git, it should go to > Linus. However, he may not want it right now since the primary > merge window for 2.6.23 has closed (although he has been merging > some other doc updates recently). If moving text files from one location to another in the Documentation directory breaks the build or causes bugs in the kernel, we have bigger problems. :) Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] timer.h
On Fri, 03 Aug 2007 10:41:39 +0200 Christian Sch__fer <[EMAIL PROTECTED]> wrote: > Christian Sch__fer wrote: > > today I got the following kernel bug while wpa_supplicant tried to > > connect to my AP. Kernel is a self-compiled 2.6.22 running under Ubuntu > > Feisty. > > The wireless device is a r8187 USB, the driver is patched for injection > > capability taken from www.aircrack-ng.org. > > Don't know if this bug is related to the driver or to the kernel, I'm no > > expert. > > > > Attached is the full dmesg and .config. Please CC to me, I'm not on the > > list. > > I was able to reproduce the bug without a tainted kernel (i.e. without > the nvidia binary module). Please let me know if you need more infos. > > > [ cut here ] > kernel BUG at include/linux/timer.h:153! > invalid opcode: [#1] > PREEMPT > Modules linked in: ieee80211_crypt_wep_rtl ieee80211_crypt_tkip_rtl > ieee80211_crypt_ccmp_rtl r8187 ieee80211_rtl ieee80211_crypt_rtl > speedstep_ich speedstep_lib dm_crypt dm_mod fuse firewire_sbp2 ehci_hcd > ohci_hcd pcmcia firmware_class usbhid firewire_ohci firewire_core > yenta_socket rsrc_nonstatic pcmcia_core crc_itu_t floppy uhci_hcd usbcore > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010286 (2.6.22 #3) > EIP is at ieee80211_associate_step1_rtl7+0x257/0x28d [ieee80211_rtl] > eax: f74cfae8 ebx: c045c030 ecx: f74cfcf8 edx: > esi: f74cf3a0 edi: e8fd2e80 ebp: 0202 esp: f0d5ff68 > ds: 007b es: 007b fs: gs: ss: 0068 > Process Ieee80211/0 (pid: 2733, ti=f0d5e000 task=f176c0b0 task.ti=f0d5e000) > Stack: e9ee0410 f74cfb88 f74cf3a0 f4c6fc40 f8e4600c f8e4606e > f74cfb8c > f74cfb88 c01276a6 001a c0456198 f4c6fc48 > f4c6fc40 > c0127c55 c0127cf2 f176c0b0 c012a784 f0d5ffc0 > f0d5ffc0 > Call Trace: > [] ieee80211_associate_procedure_wq_rtl7+0x0/0x78 > [ieee80211_rtl] > [] ieee80211_associate_procedure_wq_rtl7+0x62/0x78 > [ieee80211_rtl] > [] run_workqueue+0x84/0x135 > [] worker_thread+0x0/0xfb > [] worker_thread+0x9d/0xfb > [] autoremove_wake_function+0x0/0x37 > [] worker_thread+0x0/0xfb > [] kthread+0x33/0x54 > [] kthread+0x0/0x54 > [] kernel_thread_helper+0x7/0x18 > === > Code: 51 c7 e9 5b ff ff ff 66 c7 86 c4 05 00 00 00 00 e9 2b ff ff ff 89 > fa 89 f0 e8 b8 c3 ff ff eb c5 66 c7 86 c4 05 00 00 00 00 eb 9d <0f> 0b > eb fe b9 fd 5c e4 f8 ba 1e 00 > 00 00 89 f8 e8 13 ca 4a c7 > EIP: [] ieee80211_associate_step1_rtl7+0x257/0x28d > [ieee80211_rtl] SS:ESP 0068:f0d5ff68 > You'll need to hunt down the authors of ieee80211_rtl (where'd that come from?) and tell them not do do add_timer() or an already-pending timer. Presumably ieee80211_associate_procedure_wq_rtl7() has an add_timer() in it. Converting that to mod_timer() would maek the crash go away, but there might still be deeper problems. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: Only enable autosuspend by default on certain device classes
On 08/03/2007 01:48 PM, Matthew Garrett wrote: > On Fri, Aug 03, 2007 at 10:44:35AM -0700, Greg KH wrote: >> On Fri, Aug 03, 2007 at 01:32:53PM +0100, Matthew Garrett wrote: >>> But while this is still a likely probability, the chances are no >>> distribution is going to ship with CONFIG_USB_SUSPEND enabled. >> I wouldn't be so sure, I was thinking of doing just that based on an >> internal conversation I had yesterday. > > Well, we did - with hindsight it may not have been such a great plan :) > I believe that Fedora did as well, but have disabled it in an update > kernel. Yeah, autosuspend broke too many devices. Way too many. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] SH: add machine-ops and Dreamcast specific fix-up
(This code is closely modelled on the i386 machine-ops, though
currently the only board specific fixup is for the Dreamcast and so
there is not a separate set of mach fixups.)
This needs to be tested against a wide range of SH boards and would be
good to go in -mm if Paul acks it.
Add machine-ops code to the SH code base, allowing board specific
reboot and halt code. Currently only Dreamcast specific warm reboot
fixup in code.
Signed-off by: Adrian McMenamin <[EMAIL PROTECTED]>
diff --git a/arch/sh/boards/dreamcast/Makefile
b/arch/sh/boards/dreamcast/Makefile
index e6fcd3d..7b97546 100644
--- a/arch/sh/boards/dreamcast/Makefile
+++ b/arch/sh/boards/dreamcast/Makefile
@@ -2,5 +2,5 @@
# Makefile for the Sega Dreamcast specific parts of the kernel
#
-obj-y := setup.o irq.o rtc.o reboot.o
+obj-y := setup.o irq.o rtc.o
diff --git a/arch/sh/kernel/Makefile b/arch/sh/kernel/Makefile
index bdb30ba..7ab2359 100644
--- a/arch/sh/kernel/Makefile
+++ b/arch/sh/kernel/Makefile
@@ -5,15 +5,11 @@
extra-y:= head.o init_task.o vmlinux.lds
obj-y := debugtraps.o io.o io_generic.o irq.o machvec.o process.o ptrace.o \
- semaphore.o setup.o signal.o sys_sh.o syscalls.o \
+ reboot.o semaphore.o setup.o signal.o sys_sh.o syscalls.o \
time.o topology.o traps.o
obj-y += cpu/ timers/
-ifneq ($(CONFIG_SH_DREAMCAST),y)
- obj-y += reboot.o
-endif
-
obj-$(CONFIG_VSYSCALL) += vsyscall/
obj-$(CONFIG_SMP) += smp.o
diff --git a/arch/sh/kernel/machine_kexec.c b/arch/sh/kernel/machine_kexec.c
index 790ed69..201b370 100644
--- a/arch/sh/kernel/machine_kexec.c
+++ b/arch/sh/kernel/machine_kexec.c
@@ -29,9 +29,6 @@ extern const unsigned char relocate_new_kernel[];
extern const unsigned int relocate_new_kernel_size;
extern void *gdb_vbr_vector;
-void machine_shutdown(void)
-{
-}
void machine_crash_shutdown(struct pt_regs *regs)
{
diff --git a/arch/sh/kernel/reboot.c b/arch/sh/kernel/reboot.c
new file mode 100644
index 000..c6247ae
--- /dev/null
+++ b/arch/sh/kernel/reboot.c
@@ -0,0 +1,107 @@
+/*
+ * linux/arch/sh/kernel/reboot.c
+ *
+ * Essentially copied from i386 code
+ * and process.c
+ *
+ * Copyright (C) 1995 Linus Torvalds
+ *
+ * SuperH version: Copyright (C) 1999, 2000 Niibe Yutaka & Kaz Kojima
+ * Copyright (C) 2006 Lineo Solutions Inc. support SH4A UBC
+ * Copyright (C) 2002 - 2007 Paul Mundt
+ * Copyright 2007 Adrian McMenamin
+ *
+ * Licensed under the terms of version 2 of GNU GPL
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Power off function, if any
+ */
+void (*pm_power_off)(void);
+EXPORT_SYMBOL(pm_power_off);
+
+/* fixups for individual machines -
+ * in i386 this is in a file of its own
+ * but we only have the Dreamcast for now.
+ */
+
+static void mach_reboot_fixups(void)
+{
+ if (mach_is_dreamcast()) {
+ writel(0x7611, 0xA05F6890);
+ }
+}
+
+static void native_machine_shutdown(void)
+{
+}
+
+static void native_machine_emergency_restart(void)
+{
+ mach_reboot_fixups();
+ /* SR.BL=1 and invoke address error to let CPU reset (manual reset) */
+ asm volatile("ldc %0, sr\n\t"
+"mov.l @%1, %0" : : "r" (0x1000), "r" (0x8001));
+}
+
+static void native_machine_restart(char * __unused)
+{
+ native_machine_shutdown();
+ native_machine_emergency_restart();
+}
+
+static void native_machine_halt(void)
+{
+ local_irq_disable();
+
+ while (1)
+ cpu_sleep();
+}
+
+static void native_machine_power_off(void)
+{
+ if (pm_power_off) {
+ native_machine_shutdown();
+ pm_power_off();
+ }
+}
+
+struct machine_ops machine_ops = {
+ .power_off = native_machine_power_off,
+ .shutdown = native_machine_shutdown,
+ .emergency_restart = native_machine_emergency_restart,
+ .restart = native_machine_restart,
+ .halt = native_machine_halt,
+};
+
+void machine_power_off(void)
+{
+ machine_ops.power_off();
+}
+
+void machine_shutdown(void)
+{
+ machine_ops.shutdown();
+}
+
+void machine_emergency_restart(void)
+{
+ machine_ops.emergency_restart();
+}
+
+void machine_restart(char *cmd)
+{
+ machine_ops.restart(cmd);
+}
+
+void machine_halt(void)
+{
+ machine_ops.halt();
+}
diff --git a/include/asm-sh/emergency-restart.h
b/include/asm-sh/emergency-restart.h
index 108d8c4..d6bec92 100644
--- a/include/asm-sh/emergency-restart.h
+++ b/include/asm-sh/emergency-restart.h
@@ -1,6 +1,6 @@
-#ifndef _ASM_EMERGENCY_RESTART_H
-#define _ASM_EMERGENCY_RESTART_H
+#ifndef _ASM_SH_EMERGENCY_RESTART_H
+#define _ASM_SH_EMERGENCY_RESTART_H
-#include
+extern void machine_emergency_restart(void);
-#endif /* _ASM_EMERGENCY_RESTART_H */
+#endif /* _ASM_SH_EMERGENCY_RESTART_H */
-
To unsubscribe from this list: send the line "unsubscribe
Re: [PATCH] create CONFIG_SUSPEND_UP_POSSIBLE
On Tuesday 31 July 2007 02:38, Pavel Machek wrote: > Hi! > > > Without this change, it is possible to build CONFIG_HIBERNATE > > on all !SMP architectures, but not necessarily their SMP versions. > > Did you want to say "CONFIG_SUSPEND"? Yes. > > I don't know for sure if the architecture list under SUSPEND_UP_POSSIBLE > > is correct. For now it simply matches the list for > > SUSPEND_SMP_POSSIBLE. > > I do not think it is. > > > Signed-off-by: Len Brown <[EMAIL PROTECTED]> > > --- > > Kconfig |7 ++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig > > index 412859f..ccf6576 100644 > > --- a/kernel/power/Kconfig > > +++ b/kernel/power/Kconfig > > @@ -72,6 +72,11 @@ config PM_TRACE > > CAUTION: this option will cause your machine's real-time clock to be > > set to an invalid time after a resume. > > > > +config SUSPEND_UP_POSSIBLE > > + bool > > + depends on (X86 && !X86_VOYAGER) || (PPC64 && (PPC_PSERIES || > > At least ARM can do suspend, too... probably others. I was under > impression that SUSPEND is "supported" by all the architectures, just > some of them veto it at runtime (using pm_ops or how was it renamed). The reason this entire thread started is because Linus, Jeff and others said that they didn't want code magically compiled into their kernel that they did not explicitly ask for -- even if the savings were small and that kernel was already something rather beefy, such as ACPI+SMP. The current code is simply broken, because it allows SUSPEND on IA64 if UP, but not on SMP. It should really be neither. Further, the only requirement to enable CONFIG_SUSPEND by default is PM && CONFIG_SMP=n, and that doesn't make much sense -- particularly since many of the non X86 architectures are small and according to the logic above, if SUSPEND (and PM_SLEEP, which it enables) adds any code to those kernels when they don't need it, then it would be a regression. thus my patch, if there is a list for SMP, there should be a list for !SMP. If the list is incomplete, we need to fix it. -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22.1: hang with forcedeth driver?
On Thu, 2 Aug 2007 11:57:21 +0300 (EEST) Timo Jantunen <[EMAIL PROTECTED]> wrote: > Heip! > > I have had few total hangs with 2.6.22.1 kernel. Everything suddenly > freezes and nothing works (SysRq keys, pinging the machine from the > network.) Neither syslog nor netconsole have any relevant messages. I'm 99% > sure this didn't happen in 2.6.21.x kernels. Try enabling the NMI watchdog? (boot with nmi_watchdog=1 on the kernel command line) (or maybe nmi_watchdog=2). otoh, I think NMI watchdog is always enabled on x86_64. But the counts aren't going up. I forget what the story is there, apart from lets-be-as-different-from-i386-as-we-can :( > All hangs happened with relatively high network traffic (twice with mplayer > using remote display, once with high network fs activity). I copied > gigabytes of files over nfs but couldn't dupicatate the problem that way, > but OTOH I have also watched hours of video without problems so the problem > doesn't occur often. (In the mplayer case, the file I play is usually on > remote nfs disk, too.) > > I started using mplayer from a text console and today I finally managed to > catch first bit of information. The machine hanged like before (even SysRq > keys don't print anything) but there was one console message: > > eth0: too many iterations (6) in nv_nic_irq. > > Looking at the sources, it seems when too much works happens in a single > interrupt, the driver tries to disable device interrupts (and prints above > message). It doesn't seem to be expecting the machine to hang afterwards. > > I guess the quick fix for me is to increase max_interrupt_work value so it > doesn't get hit as easily. > Well. A Key piece of information would be: did that help? > > I have nForce3 board and Athlon 64 X2 CPU (but using 32-bit kernel). I'm > using the built in ethernet with forcedeth driver. I also have ATI/AMD > binary drivers loaded, and at least in some of the cases, VMware host > drivers, too. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] msleep() with hrtimers
Hi, On Fri, 3 Aug 2007, Jonathan Corbet wrote: > Most comments last time were favorable. The one dissenter was Roman, > who worries about the overhead of using hrtimers for this operation; my > understanding is that he would rather see a really_msleep() function for > those who actually want millisecond resolution. I'm not sure how to > characterize what the cost could be, but it can only be buried by the > fact that every call sleeps for some number of milliseconds. On my > system, the several hundred total msleep() calls can't cause any real > overhead, and almost all happen at initialization time. The main point is still that these are two _different_ APIs for different usages, so I still prefer to add a hrsleep() instead. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFSv4 poops itself
On Fri, Jul 27, 2007 at 01:29:00PM -0400, Trond Myklebust wrote: > On Fri, 2007-07-27 at 13:16 -0400, Jeff Garzik wrote: > > Trond Myklebust wrote: > > > Jeff and Bruce, could you please try to reproduce the problem after > > > either applying patches 001 to 004 or just the single NFS_ALL patch > > > from > > > > > >http://client.linux-nfs.org/Linux-2.6.x/2.6.23-rc1/ > > > > > > It's not easily reproducible here. Any hints on triggering the behavior? > > I suspect that the problem may involve mixing O_RDWR with O_RDONLY > and/or O_WRONLY file access. Bruce might have a better suggestion, > though. I haven't done any more work to identify when exactly the problem is triggered, but I did confirm that I could reproduce the problem reliably with current git, but *not* with current git plus your 4-patch nfs-all. --b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
