Re: [PATCH] Re: Cleaning up the Documentation directory.
On Wednesday 23 May 2007 12:56 am, Paul Mundt wrote: > On Wed, May 23, 2007 at 12:25:44AM -0400, Rob Landley wrote: > >mv arm cris blackfin parisc powerpc s390 x86_64 uml arch > > You missed sh, mips, fujitsu/frv, m68k, ia64, i386, and sparc. Yup. I'll add 'em to the next pass. Thanks. There's plenty more to do. (Why is smart-config.txt not in kbuild? Why is rpc-cache.txt not in filesystems with nfs? Why is xterm-linux.xpm in there at all, it's a graphic, not documentation...) This was just me trying to figure out how to move files without big add/remove patches. (I'd never set up git before, I use mercurial.) A small and hopefully non-controversial set. I'm trying to do a web version of the Documentation directory. I've been reading through this on and off for a month now and I'm still trying to figure out where everything is. The top level directory mixes together tons of obscure serial drivers, advice about how to submit, copies of standards documents like unicode.txt, administrative files like feature-removal-schedule.txt, debugging advice, userspace API documentation, datastructure documentation, design docs, a pointer to where to download the firmware for a Cyclades Z (still dunno what that is, but google probably would. README.cycladesZ sure doesn't say...), historical notes like highuid.txt... I'm also trying to figure out what is and isn't documented, so I can fill in some of the gaps. (Or at least _identify_ them.) Having a great unsorted heap of documentation doesn't help this, I need to categorize it to figure out the coverage. (Let alone triaging the quality of what's there and figuring out if Linux Weekly News or Kerneltrap or somebodydid a way better writeup than what the kernel comes with, and maybe I can poke 'em into signing off on putting their version in the kernel.) Yeah, I've got to read through "make htmldocs" too. I'm working on it... > Is there really enough documentation for these that another directory > level is worthwhile? You note that my first quick run-through missed half of this category of documentation, and then you ask whether or not the grouping is already obvious. Yes, I think there's enough documentation to make another directory level worthwhile. And as long as we're going there please explain why directories like "uml" and "telephony" only have one file each in them, but there's five "sched-*.txt" files at the root level? Why is there an ioctl directory but ioctl-number.txt isn't in it? (Maybe there are good answers for this other than "different people did different things without talking to each other, and documentation is an afterthought anyway". I don't know.) > 00-INDEX already covers most of these things, so > it's not like there's any measurable confusion.. Following that to its logical conclusion, why do we need subdirectories at all? No, that's not sarcasm, I've actually pondered just making an index.html file that bears no relation to the underlying directory structure but lets people see "ok, these seven files are about locking, these six files are about the development model, these files describe development tools, this describes kernel infrastructure, these are busses, these are block devices..." I thought reorganizing Documentation (so people who didn't already know everything in it could find things) would be more generally helpful, but if that's not the case I'm happy to do my own out-of-tree index instead. Let me know what you prefer. As to "why start here", the multiport serial drivers are each things that 99% of the audience will never use. Few things even have serial anymore, those that do seldom use multiport cards, and when you _do_ have a multiport card you're looking for documentation on a specific one and the other half-dozen won't help you. So having them at the root level is just clutter in anything remotely like the common case, and there's already a "serial" directory (another example of a directory with just one thing in it). As for architectures, most people manage to avoid caring about the ones they don't use (as long as their changes don't break them, something they often can't test anyway). Personally, I do embedded development and play with half a dozen architectures (plug: http://landley.net/code/firmware), but most people only look at one or two. Files like "zorro.txt" are something that there are probably less than 100 people on the planet who still use it, which doesn't mean it's not _valuable_, just that having it at the root level is clutter to the vast majority of the userbase and arch/amiga seems like a better place for it. Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: section mismatches
* Chris Wright ([EMAIL PROTECTED]) wrote: > I tracked down a bunch of these a little while back. It's not really > iret_exc, but since there is no _sfixup/_efixup markers iret_exc is the > closest symbol to pick on. All the [iret_exc, _etext] warnings I found > were completely harmless from things that used, for example, mfn_to_pfn > in an __init function (which sucks in a fixup via __get_user). Took a moment to check current -mm allmodconfig as Andrew did. $ make ARCH=i386 O=obj-mod allmodconfig $ make -j8 ARCH=i386 O=obj-mod > obj-mod/build.out 2>&1 $ objdump -dr -j.text obj-mod/vmlinux > obj-mod/objdump.out $ grep iret_exc obj-mod/build.out | sed 's/.*(at offset 0x\(.*\)).*/\1/' | while read addr; do grep -B1 $addr obj-mod/objdump.out; done c0306935: e9 41 7e 19 00 jmpc049e77b c0306936: R_386_PC32.init.text c0306941: e9 83 7e 19 00 jmpc049e7c9 c0306942: R_386_PC32.init.text c030694d: e9 8e 85 19 00 jmpc049eee0 c030694e: R_386_PC32.init.text c0306959: e9 93 86 19 00 jmpc049eff1 c030695a: R_386_PC32.init.text c0306fd4: e9 bc c6 1a 00 jmpc04b3695 c0306fd5: R_386_PC32.init.text c0307120: e9 2c f3 1a 00 jmpc04b6451 c0307121: R_386_PC32.init.text Each of these is indeed from __get_user called from an __init function. - romsignature calls __get_user via probe_kernel_address - romchecksum calls __get_user via probe_kernel_address - request_standard_resources inlines probe_roms which twice calls __get_user via probe_kernel_address - xenbus_probe_init calls __get_user via mfn_to_pfn - pci_pcbios_init calls __get_user via probe_kernel_address We could simply hush it up, by forcing that call to be out of line from the __init function. That's not really robust, since each callsite needs attention (meaning new ones will sneak in over time). Or fix the linker script (and possibly modpost.c). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] USB fixes for 2.6.22-rc2
Here are some USB fixes against your 2.6.22-rc2 tree. They fix a number of minor and semi-major issues (suspend to ram should now work properly for everyone that was hitting the "USB can't suspend" error) and add a number of new device ids to various USB drivers. All of these, except for the new device ids, have been in the -mm releses for a while. Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/ The full patches will be sent to the linux-usb-devel mailing list, if anyone wants to see them. thanks, greg k-h Documentation/DocBook/gadget.tmpl |2 +- Documentation/DocBook/usb.tmpl | 28 drivers/net/usb/cdc_ether.c| 16 ++ drivers/net/usb/rndis_host.c |1 + drivers/net/usb/usbnet.c | 25 +- drivers/net/usb/usbnet.h |1 + drivers/usb/class/usblp.c |2 +- drivers/usb/core/config.c | 10 +--- drivers/usb/core/driver.c | 18 --- drivers/usb/core/hcd.c |6 + drivers/usb/core/hub.c | 21 +++--- drivers/usb/core/message.c |9 +-- drivers/usb/core/sysfs.c |7 ++ drivers/usb/core/usb.c |6 - drivers/usb/gadget/fsl_usb2_udc.c |8 -- drivers/usb/host/ohci-pci.c|2 +- drivers/usb/host/pci-quirks.c |9 drivers/usb/host/u132-hcd.c| 12 ++ drivers/usb/misc/auerswald.c | 10 +--- drivers/usb/misc/ftdi-elan.c | 12 +++--- drivers/usb/misc/ldusb.c | 35 +++--- drivers/usb/serial/ark3116.c |3 +- drivers/usb/serial/ftdi_sio.c | 40 ++- drivers/usb/serial/ftdi_sio.h | 12 ++ drivers/usb/serial/mos7840.c |5 drivers/usb/serial/omninet.c |2 - drivers/usb/serial/option.c|1 - drivers/usb/serial/sierra.c|2 + drivers/usb/storage/onetouch.c |9 --- drivers/usb/storage/unusual_devs.h | 10 +++- 30 files changed, 222 insertions(+), 102 deletions(-) --- Alan Stern (9): EHCI: fix problem with BIOS handoff USB: more autosuspend timer stuff USB: remove unneeded WARN_ON USB: set the correct Interrupt interval in usb_bulk_msg USB: remove short initial timeout for device descriptor fetch USB: don't try to kzalloc 0 bytes USB: make the autosuspend workqueue thread freezable USB: handle errors in power/level attribute USB: fix ratelimit call semantics Andrew Morton (1): USB: auerswald: fix file release handler Andrey Borzenkov (1): USB: Fix USB OHCI Subvendor for Toshiba Portege 4000 Ben Collins (1): USB: Remove duplicate IDs from option card driver Danny Budik (1): USB: Add support for Sierra Wireless Aircard 595U David Brownell (3): USB: fix more ftdi-elan/u132-hcd #include lossage USB: handle more rndis_host oddities USB: remove usb DocBook warnings Dmitry Torokhov (1): USB: Onetouch - switch to using input_dev->dev.parent Guido Scholz (1): USB: ftdi_sio: Add USB Product Id for OpenDCC Jan Engelhardt (1): USB: Fix debug output of ark3116 Li Yang (1): USB: fsl_usb2_udc: Fix UMTI_WIDE support and a compile warning Matthew Davidson (1): usb-storage: ignore Sitecom WL-117 USB-WLAN Neil \"Superna\" ARMSTRONG (1): USB: New device PID for ftdi_sio driver Oliver Neukum (4): USB: fix omninet memory leak found by coverity USB: remove useless check in mos7840 found by coverity USB: address FIXME in usbnet w.r.t drivers claiming multiple interfaces USB: ldusb bugfix Pete Zaitcev (2): USB: Deref URB after usbmon is done with it USB: usblp: Use correct DMA address in case of probe error Tony Lindgren (1): USB: Add support for Olimex arm-usb-ocd JTAG interface serial port - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Current utrace breaks UML
> This chunk from linux-2.6-utrace.patch breaks PTRACE_SYSEMU, which UML > rather relies on. PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP are implemented in a different way (see kernel/ptrace.c), which does not require that assembly code. (It also works for free on other arch's if you want to #define the constants there.) Do you have a test case for PTRACE_SYSEMU that does not work right? 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] ata: pata_platform: Disable prereset logic.
On a number of boards the current prereset logic seems to misbehave:
scsi0 : pata_platform
ata1: PATA max PIO0 cmd 0xb06001f0 ctl 0xb06003f6 bmdma 0x irq 0
ata1: device not ready (errno=-19), forcing hardreset
ata1: BUG: prereset() requested invalid reset type
This triggers when there is no card inserted in the slot.
Simply disabling the prereset gets rid of this, and doesn't seem to cause
any problems for either PCMCIA or CF cards when they're actually present.
Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>
--
drivers/ata/pata_platform.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/pata_platform.c b/drivers/ata/pata_platform.c
index cbb7866..8a569c7 100644
--- a/drivers/ata/pata_platform.c
+++ b/drivers/ata/pata_platform.c
@@ -1,7 +1,7 @@
/*
* Generic platform device PATA driver
*
- * Copyright (C) 2006 Paul Mundt
+ * Copyright (C) 2006 - 2007 Paul Mundt
*
* Based on pata_pcmcia:
*
@@ -22,7 +22,7 @@
#include
#define DRV_NAME "pata_platform"
-#define DRV_VERSION "1.0"
+#define DRV_VERSION "1.1"
static int pio_mask = 1;
@@ -30,7 +30,8 @@ static int pio_mask = 1;
* Provide our own set_mode() as we don't want to change anything that has
* already been configured..
*/
-static int pata_platform_set_mode(struct ata_port *ap, struct ata_device
**unused)
+static int pata_platform_set_mode(struct ata_port *ap,
+ struct ata_device **unused)
{
int i;
@@ -48,6 +49,12 @@ static int pata_platform_set_mode(struct ata_port *ap,
struct ata_device **unuse
return 0;
}
+static void pata_platform_error_handler(struct ata_port *ap)
+{
+ ata_bmdma_drive_eh(ap, NULL, ata_std_softreset, NULL,
+ ata_std_postreset);
+}
+
static int ata_dummy_ret0(struct ata_port *ap) { return 0; }
static struct scsi_host_template pata_platform_sht = {
@@ -80,7 +87,7 @@ static struct ata_port_operations pata_platform_port_ops = {
.freeze = ata_bmdma_freeze,
.thaw = ata_bmdma_thaw,
- .error_handler = ata_bmdma_error_handler,
+ .error_handler = pata_platform_error_handler,
.post_internal_cmd = ata_bmdma_post_internal_cmd,
.cable_detect = ata_cable_unknown,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: sleeping function called from invalid context at kernel/fork.c:385
On Wed, 23 May 2007 16:31:54 +1000 David Chinner <[EMAIL PROTECTED]> wrote: > Saw this when running strace -f on a script on 2.6.21 on ia64: > > BUG: sleeping function called from invalid context at kernel/fork.c:385 > in_atomic():1, irqs_disabled():0 > > Call Trace: > [] show_stack+0x80/0xa0 > sp=e0306e6f7a00 bsp=e0306e6f0ef8 > [] dump_stack+0x30/0x60 > sp=e0306e6f7bd0 bsp=e0306e6f0ee0 > [] __might_sleep+0x1f0/0x260 > sp=e0306e6f7bd0 bsp=e0306e6f0eb8 > [] mmput+0x20/0x220 > sp=e0306e6f7bd0 bsp=e0306e6f0e90 > [] sys_ptrace+0x460/0x1600 > sp=e0306e6f7bd0 bsp=e0306e6f0d80 > [] ia64_ret_from_syscall+0x0/0x20 > sp=e0306e6f7e30 bsp=e0306e6f0d80 > [] __kernel_syscall_via_break+0x0/0x20 > sp=e0306e6f8000 bsp=e0306e6f0d80 > BUG: sleeping function called from invalid context at kernel/fork.c:385 > in_atomic():1, irqs_disabled():0 > > Call Trace: > [] show_stack+0x80/0xa0 > sp=e0306e6f7a00 bsp=e0306e6f0ef8 > [] dump_stack+0x30/0x60 > sp=e0306e6f7bd0 bsp=e0306e6f0ee0 > [] __might_sleep+0x1f0/0x260 > sp=e0306e6f7bd0 bsp=e0306e6f0eb8 > [] mmput+0x20/0x220 > sp=e0306e6f7bd0 bsp=e0306e6f0e90 > [] sys_ptrace+0x460/0x1600 > sp=e0306e6f7bd0 bsp=e0306e6f0d80 > [] ia64_ret_from_syscall+0x0/0x20 > sp=e0306e6f7e30 bsp=e0306e6f0d80 > [] __kernel_syscall_via_break+0x0/0x20 > sp=e0306e6f8000 bsp=e0306e6f0d80 > > I could reproduce it via 'strace -f sleep 1' > I'd say this is specific to ia64. Someone would have spotted it on x86 by now. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] file as directory
> > Others might suggest accessing streams, resource forks or extended > > attributes through such an interface. However this patch only deals > > with the non-directory case, so directories would be excluded from > > that interface. > > here's a possibly stupid question. What about symlinks to dirs? namely > the shells tend to treat them differently if postfixed with a slash or not. Right. So it only works on non-directory, non-symlink objects. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] file as directory
> > When a non-directory object is accessed without a trailing slash, then > > path resolution returns the object itself as usual. > > > > If a non-directory object is accessed with a trailing slash, then the > > filesystem may opt to let the file be accessed as a directory. In > > this case "something" (as supplied by the filesystem) is mounted on > > top of the non-directory object. > > > > This mount will have special properties: > > > > - If there's no trailing slash is after the file name, the mount > >won't be followed, even if the path resolution would otherwise > >follow mounts. > > > > - The mount only stays there while it is referenced by some external > >object, like a pwd or an open file. When it is no longer > >referenced, it is automatically unmounted. > > > > - Unlike "real" mounts, this won't block unlink(2) or rename(2) on > >the underlying object. > > Interesting... How do you deal with mount propagation and things like > mount --move? Moving (or doing other mount operations on) an ancestor shouldn't be a problem. Moving this mount itself is not allowed, and neither is doing bind or pivot_root. Maybe bind could be allowed... When doing recursive bind on ancestor, these mounts are skipped. > As for unlink... How do you deal with having that thing > mounted, mounting something _under_ it (so that vfsmount would be kept > busy) and then unlinking that sucker? Yeah, that's a good point. Current patch doesn't deal with that. Simplest solution could be to disallow submounting these. Don't think it makes much sense anyway. > I'll look through the patch tonight; it sounds interesting, assuming that > we don't run into serious crap with locking and revalidation > logics. Revalidation shouln't be a problem. We'll just end up with an unhashed dentry with a mount over it, which will be detached when the vfsmount ref is dropped. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix/add raw1394 CONFIG_COMPAT code
Dan Dennedy wrote:
> On Sunday 20 May 2007 08:28, Stefan Richter wrote:
>> maybe we should change
...
>> struct raw1394_cycle_timer {
[to consist of two u64 to get same alignment on all architectures]
...
>> before a libraw1394 with get-cycle-timer support is released.
>> Shall I prepare according patches for raw1394 and libraw1394?
>
> This seems like a good idea, and I have forwarded it to the ffado (formerly
> freebob) developers, specifically Pieter Palmers--the submitter of
> raw1394_read_cycle_timer--to get his feedback.
I'll post the patches tonight to see how it will look like. Even though
I already posted the kernel-only patch which adjusts
raw1394_iso_packets32 per architecture, the 2x u64 variant may overall
be nicer: a) it eliminates the need for raw1394_cycle_timer32, b) the
get-cycle-timer ABI still has to be duplicated in Juju, and Juju so far
did not require different struct types for 32bit compatibility ioctls.
--
Stefan Richter
-=-=-=== -=-= =-===
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
BUG: sleeping function called from invalid context at kernel/fork.c:385
Saw this when running strace -f on a script on 2.6.21 on ia64: BUG: sleeping function called from invalid context at kernel/fork.c:385 in_atomic():1, irqs_disabled():0 Call Trace: [] show_stack+0x80/0xa0 sp=e0306e6f7a00 bsp=e0306e6f0ef8 [] dump_stack+0x30/0x60 sp=e0306e6f7bd0 bsp=e0306e6f0ee0 [] __might_sleep+0x1f0/0x260 sp=e0306e6f7bd0 bsp=e0306e6f0eb8 [] mmput+0x20/0x220 sp=e0306e6f7bd0 bsp=e0306e6f0e90 [] sys_ptrace+0x460/0x1600 sp=e0306e6f7bd0 bsp=e0306e6f0d80 [] ia64_ret_from_syscall+0x0/0x20 sp=e0306e6f7e30 bsp=e0306e6f0d80 [] __kernel_syscall_via_break+0x0/0x20 sp=e0306e6f8000 bsp=e0306e6f0d80 BUG: sleeping function called from invalid context at kernel/fork.c:385 in_atomic():1, irqs_disabled():0 Call Trace: [] show_stack+0x80/0xa0 sp=e0306e6f7a00 bsp=e0306e6f0ef8 [] dump_stack+0x30/0x60 sp=e0306e6f7bd0 bsp=e0306e6f0ee0 [] __might_sleep+0x1f0/0x260 sp=e0306e6f7bd0 bsp=e0306e6f0eb8 [] mmput+0x20/0x220 sp=e0306e6f7bd0 bsp=e0306e6f0e90 [] sys_ptrace+0x460/0x1600 sp=e0306e6f7bd0 bsp=e0306e6f0d80 [] ia64_ret_from_syscall+0x0/0x20 sp=e0306e6f7e30 bsp=e0306e6f0d80 [] __kernel_syscall_via_break+0x0/0x20 sp=e0306e6f8000 bsp=e0306e6f0d80 I could reproduce it via 'strace -f sleep 1' Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bad networking related lag in v2.6.22-rc2
* Anant Nitya <[EMAIL PROTECTED]> wrote: > > could you also apply the fix for the softirq problem below, to make > > sure it does not interact? > Above patch does solve __ soft_irq_pending __ problem. I am running > this patch with kernel 2.6.21.1 since last day doing all kinda things > but haven't encountered any __ NOHZ: local_softirq_pending __. But > network lag that I am seeing since 2.6.22-rc1 is still there even with > this patch applied. If you need any more information please do ask. > Meanwhile I will do gitbisect as suggested by linus to find out the > specific commit that introduced this problem and will inform once I > find it. Its good to see system running without any __ > local_softirq_problem __ :) thanks. if you feel inclined to try the git-bisection then by all means please do it (it will certainly be helpful and educative), but it's optional: i dont think you should 'need' to go through extra debugging chores, my analysis based on the excellent trace you provided still holds and whoever modified htb_dequeue()'s logic recently ought to be able to figure that out (or send you a debug patch to further narrow the problem down). The trace shows a _clearly_ anomalous loop: for example there's 56396 (!) calls to rb_first() in htb_dequeue() [without the kernel ever exiting that function]: earth4:~/s> grep rb_first trace-to-ingo.txt | wc -l 56396 and the set of rules you are using are alot simpler and the networking load you are using is not large by any means. Here's the trace analysis below again. Ingo ---> > http://cybertek.info/taitai/trace-to-ingo.txt.bz2 This trace indeed includes the smoking gun, htb_dequeue() and __qdisc_run(): privoxy-12926 1.Ns1 1597us : rb_first (htb_dequeue) this goes on, non-preemptible, for 160 milliseconds (!): privoxy-12926 1.Ns1 161568us : rb_first (htb_dequeue) privoxy-12926 1.Ns1 161568us : qdisc_watchdog_schedule (htb_dequeue) and finally manages to escape the loop: privoxy-12926 1.Ns1 161597us : rb_first (htb_dequeue) privoxy-12926 1.Ns1 161597us : rb_first (htb_dequeue) privoxy-12926 1.Ns1 161599us : htb_safe_rb_erase (htb_dequeue) privoxy-12926 1.Ns1 161599us : rb_erase (htb_safe_rb_erase) privoxy-12926 1.Ns1 161600us : htb_change_class_mode (htb_dequeue) privoxy-12926 1.Ns1 161601us : htb_activate_prios (htb_change_class_mode) and the system recovers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LOCKDEP: possible irq lock inversion dependency detected
* Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> Hmm. That's the code in question:
>
> void __init timekeeping_init(void)
>
> {
>
> unsigned long flags;
>
> unsigned long sec = read_persistent_clock();
>
>
>
> write_seqlock_irqsave(&xtime_lock, flags);
>
> The rtc_lock is never taken inside the xtime_lock.
>
> Looks like code reordering due to gcc extra magic. Which compiler ?
i dont think it's due to code reordering. The code that lockdep flagged
is the new code in arch/i386/kernel/bootflag.c, sbf_read() and
sbf_write(). It does:
spin_lock_irqsave(&rtc_lock, flags);
CMOS_WRITE(v, sbf_port);
spin_unlock_irqrestore(&rtc_lock, flags);
and:
spin_lock_irqsave(&rtc_lock, flags);
v = CMOS_READ(sbf_port);
spin_unlock_irqrestore(&rtc_lock, flags);
and is apparently called with the xtime_lock held. Was that code ever
booted with CONFIG_PROVE_LOCKING enabled?
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/
[Doc] spelling fix for fs/sysfs/file.c
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> --- commit 966fef8404d59056d8524bf94d7dff790fe1fa82 tree 1adc274bc9b8e7e420db0b0023c8b70bd294e84e parent 0cbdc367b144a95709852c642a069ed652989520 author Rolf Eike Beer <[EMAIL PROTECTED]> Mon, 21 May 2007 22:55:30 +0200 committer Rolf Eike Beer <[EMAIL PROTECTED]> Mon, 21 May 2007 22:55:30 +0200 fs/sysfs/file.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c index b502c71..dcb8e83 100644 --- a/fs/sysfs/file.c +++ b/fs/sysfs/file.c @@ -370,7 +370,7 @@ static int sysfs_release(struct inode * inode, struct file * filp) * again will not get new data, or reset the state of 'poll'. * Reminder: this only works for attributes which actively support * it, and it is not possible to test an attribute from userspace - * to see if it supports poll (Nether 'poll' or 'select' return + * to see if it supports poll (Neither 'poll' nor 'select' return * an appropriate error code). When in doubt, set a suitable timeout value. */ static unsigned int sysfs_poll(struct file *filp, poll_table *wait) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RFC SLUB: Add statistics support for other kernel subsystems.
I am not sure if this is useful or if this should take a different form
But Eric and Peter asked me for some of the functionality included here.
Cleanup and export the statistics support that is current used to
generate the numbers available via sysfs.
Add a function kmem_cache_count() that can determine slabs, pages and objects
in the various types of slab pages.
Also add a function estimate the amount of memory in pages needed in order to
allocate a given number of objects.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
include/linux/slub_def.h | 27 +
mm/slub.c| 215 +--
2 files changed, 160 insertions(+), 82 deletions(-)
Index: slub/include/linux/slub_def.h
===
--- slub.orig/include/linux/slub_def.h 2007-05-22 22:46:24.0 -0700
+++ slub/include/linux/slub_def.h 2007-05-22 22:49:06.0 -0700
@@ -172,4 +172,31 @@ static inline void *kmalloc_node(size_t
}
#endif
+/*
+ * Statistics for slabcaches. Calls to kmem_cache_count must specify what
+ * is to be counted and may specify in what units the counting should be
+ * done. If no type is specified then we return counts of slabs.
+ *
+ * Note that -ENOSYS may be returned if a slab is merged with others.
+ * If the combined counts of multiple slabs are acceptable then
+ * KMEM_CACHE_ALIAS may be specified and then the amounts of the
+ * merged slab will be returned.
+ */
+#define KMEM_CACHE_FULL0x0001 /* Count full slabs */
+#define KMEM_CACHE_PARTIAL 0x0002 /* Count partial slabs */
+#define KMEM_CACHE_PER_CPU 0x0004 /* Count cpu slabs */
+#define KMEM_CACHE_OBJECTS 0x0010 /* Return object counts */
+#define KMEM_CACHE_PAGES 0x0020 /* Return page counts */
+#define KMEM_CACHE_ALIAS 0x0100 /* Allow aliased slabs */
+
+#define KMEM_CACHE_ALL (KMEM_CACHE_FULL|KMEM_CACHE_PARTIAL|\
+ KMEM_CACHE_PER_CPU)
+
+/* Estimate the worst case of pages needed for a given number of objects */
+unsigned long kmem_cache_estimate_pages(struct kmem_cache *s, int objects);
+
+/* Determine the amount of slabs/pages/objects */
+long kmem_cache_count(struct kmem_cache *s,
+ unsigned long stat_flags, unsigned long *nodes);
+
#endif /* _LINUX_SLUB_DEF_H */
Index: slub/mm/slub.c
===
--- slub.orig/mm/slub.c 2007-05-22 22:46:24.0 -0700
+++ slub/mm/slub.c 2007-05-22 22:56:31.0 -0700
@@ -2398,6 +2398,114 @@ int kmem_cache_shrink(struct kmem_cache
}
EXPORT_SYMBOL(kmem_cache_shrink);
+/*
+ * Determine counts of objects / pages
+ */
+static unsigned long count_partial(struct kmem_cache_node *n)
+{
+ unsigned long flags;
+ unsigned long x = 0;
+ struct page *page;
+
+ spin_lock_irqsave(&n->list_lock, flags);
+ list_for_each_entry(page, &n->partial, lru)
+ x += page->inuse;
+ spin_unlock_irqrestore(&n->list_lock, flags);
+ return x;
+}
+
+long kmem_cache_count(struct kmem_cache *s, unsigned long flags,
+ unsigned long *nodes)
+{
+ unsigned long total = 0;
+ int cpu;
+ int node;
+ unsigned long x;
+ unsigned long *per_cpu;
+
+ if (s->refcount > 1 && !(flags & KMEM_CACHE_ALIAS))
+ return -ENOSYS;
+
+ per_cpu = kzalloc(nr_node_ids * sizeof(unsigned long), GFP_KERNEL);
+ if (!per_cpu)
+ return -ENOMEM;
+
+ if (nodes)
+ memset(nodes, 0, nr_node_ids * sizeof(unsigned long));
+
+
+ for_each_possible_cpu(cpu) {
+ struct page *page = s->cpu_slab[cpu];
+ int node;
+
+ if (page) {
+ node = page_to_nid(page);
+ if (flags & KMEM_CACHE_PER_CPU) {
+ int x = 0;
+
+ if (flags & KMEM_CACHE_OBJECTS)
+ x = page->inuse;
+ else
+ x = 1;
+ total += x;
+ if (nodes)
+ nodes[node] += x;
+ }
+ per_cpu[node]++;
+ }
+ }
+
+ for_each_online_node(node) {
+ struct kmem_cache_node *n = get_node(s, node);
+
+ if (flags & KMEM_CACHE_PARTIAL) {
+ if (flags & KMEM_CACHE_OBJECTS)
+ x = count_partial(n);
+ else
+ x = n->nr_partial;
+ total += x;
+ if (nodes)
+ nodes[node] += x;
+ }
+
+ if (flags & KMEM_CACHE_FULL) {
+ int full_slabs = atomic_rea
Re: [patch] CFS scheduler, -v13
On Wednesday 23 May 2007 03:36:27 Bill Davidsen wrote: > Anant Nitya wrote: > > On Thursday 17 May 2007 23:15:33 Ingo Molnar wrote: > >> i'm pleased to announce release -v13 of the CFS scheduler patchset. > >> > >> The CFS patch against v2.6.22-rc1, v2.6.21.1 or v2.6.20.10 can be > >> downloaded from the usual place: > >> > >> http://people.redhat.com/mingo/cfs-scheduler/ > >> > >> -v13 is a fixes-only release. It fixes a smaller accounting bug, so if > >> you saw small lags during desktop use under certain workloads then > >> please re-check that workload under -v13 too. It also tweaks SMP > >> load-balancing a bit. (Note: the load-balancing artifact reported by > >> Peter Williams is not a CFS-specific problem and he reproduced it in > >> v2.6.21 too. Nevertheless -v13 should be less prone to such artifacts.) > >> > >> I know about no open CFS regression at the moment, so please re-test > >> -v13 and if you still see any problem please re-report it. Thanks! > >> > >> Changes since -v12: > >> > >> - small tweak: made the "fork flow" of reniced tasks zero-sum > >> > >> - debugging update: /proc//sched is now seqfile based and echoing > >>0 to it clears the maximum-tracking counters. > >> > >> - more debugging counters > >> > >> - small rounding fix to make the statistical average of rounding errors > >>zero > >> > >> - scale both the runtime limit and the granularity on SMP too, and make > >>it dependent on HZ > >> > >> - misc cleanups > >> > >> As usual, any sort of feedback, bugreport, fix and suggestion is more > >> than welcome, > >> > >>Ingo > >> - > > > > Hi > > Been testing this version of CFS from last an hour or so and still facing > > same lag problems while browsing sites with heavy JS and or flash usage. > > Mouse movement is pathetic and audio starts to skip. I haven't face this > > behavior with CFS till v11. > > 'm not seeing this, do have a site or two as examples? Please disregard the above post, lag problem I am experiencing got introduced in 2.6.22-rcX and is network QoS specific and its not related to CFS. Regards Ananitya -- Out of many thousands, one may endeavor for perfection, and of those who have achieved perfection, hardly one knows Me in truth. -- Gita Sutra Of Mysticism - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Race free attributes in sysfs
Greg KH wrote: > If you can come up with a wrapper that will work, please let me know and > I'll be glad to add it. Right now, it's pretty darn simple to do this > (look at the USB and PCI core code for examples if you need it.) > > I guess we have different views on "simple" :) I had a look at the usb code, which is why I think the current method is a bit indirect. Right now I instead copied the function that adds the device attributes given in the bus_type structure. Couldn't that be used in a more general manner to get device attribute groups? > Anyway, groups are what you want and need, please use them and then you > don't have to worry about triggering an event later after you have > created your files on your own. > I take it I can supply an array of groups somewhere? -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.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: bad networking related lag in v2.6.22-rc2
On Tuesday 22 May 2007 11:52:33 Ingo Molnar wrote:
> * Anant Nitya <[EMAIL PROTECTED]> wrote:
> > > I think I already found the bug, please try if this patch helps.
> >
> > Sorry, but this patch is not helping here. I recompiled the kernel
> > with this patch but same load pattern still make system to crawl.
> >
> > Here is the link for script I use to shape traffic.
> >
> > http://cybertek.info/taitai/adslbwopt.sh
>
> could you also apply the fix for the softirq problem below, to make sure
> it does not interact?
>
> Ingo
>
> Index: linux/kernel/sched.c
> ===
> --- linux.orig/kernel/sched.c
> +++ linux/kernel/sched.c
> @@ -4212,9 +4212,7 @@ int __sched cond_resched_softirq(void)
> BUG_ON(!in_softirq());
>
> if (need_resched() && system_state == SYSTEM_RUNNING) {
> - raw_local_irq_disable();
> - _local_bh_enable();
> - raw_local_irq_enable();
> + local_bh_enable();
> __cond_resched();
> local_bh_disable();
> return 1;
Hi Ingo
Above patch does solve __ soft_irq_pending __ problem. I am running this patch
with kernel 2.6.21.1 since last day doing all kinda things but haven't
encountered any __ NOHZ: local_softirq_pending __. But network lag that I am
seeing since 2.6.22-rc1 is still there even with this patch applied. If you
need any more information please do ask. Meanwhile I will do gitbisect as
suggested by linus to find out the specific commit that introduced this
problem and will inform once I find it. Its good to see system running
without any __ local_softirq_problem __ :)
Regards
Ananitya
--
Out of many thousands, one may endeavor for perfection, and of
those who have achieved perfection, hardly one knows Me in truth.
-- Gita Sutra Of Mysticism
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [realtime kernel 2.6.21-rt2 and up] Extremely slow bootup for x86_64
2.6.21-rt6 is working normally as far as i can see. Maarten. On 5/21/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote: On Mon, 2007-05-21 at 10:11 -0500, Frank Sorenson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Thomas Gleixner wrote: > > On Mon, 2007-05-21 at 00:00 -0500, Frank Sorenson wrote: > > > >> I see the slow bootup as well, even with 2.6.22-rc2-hrt1. It takes at > >> least 5 times as long to boot, for X to start, to login, etc. > > > > Can you provide me your .config and a boot log (please enable > > CONFIG_PRINTK_TIME and add "apic=verbose" to the kernel command line). > > > > Can you also try with "hpet=disable" ? > > All attached. With "hpet=disable", it's still slow (clocksource becomes > acpi_pm). > [ 23.159166] Bluetooth: HCI device and connection manager initialized > [ 23.159170] Bluetooth: HCI socket layer initialized > [ 23.159179] BUG: at mm/slab.c:777 __find_general_cachep() > [ 23.159181] > [ 23.159182] Call Trace: > [ 23.159190] [] __kmalloc+0xa7/0xe0 > [ 23.159195] [] cache_k8_northbridges+0x9d/0x120 > [ 23.159200] [] gart_iommu_init+0x33/0x5b0 > [ 23.159205] [] class_register+0x177/0x180 > [ 23.159210] [] pci_iommu_init+0x9/0x20 > [ 23.159214] [] kernel_init+0x14c/0x320 > [ 23.159218] [] child_rip+0xa/0x12 > [ 23.159223] [] acpi_ds_init_one_object+0x0/0x7c > [ 23.159227] [] kernel_init+0x0/0x320 > [ 23.159230] [] child_rip+0x0/0x12 Hmm, other than this gem there is nothing obvious in the boot log. Does the box boot normal with 2.6.22-rc2 ? Where does the slowness start ? Right from the beginning or later in the boot process ? tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] /sys/block -> /sys/class/block (Fedora 3 & 4 testers wanted)
On Tue, 22 May 2007 17:32:55 -0700, Greg KH <[EMAIL PROTECTED]> wrote: > On Tue, May 22, 2007 at 06:28:12PM +0200, Cornelia Huck wrote: > > On Tue, 22 May 2007 10:25:01 +0200, > > Cornelia Huck <[EMAIL PROTECTED]> wrote: > > > > > I tried this on one of our internal drivers, which is based on FC 3 (or > > > 4, can look this up). With s390 defconfig, it is unable to open the > > > root device /dev/dasda1 (which is unsurprising, considering udev (063) > > > decided to create /dev/dasda(1) as a character node instead of a block > > > node). > > > > Just to be clear, it's fsck that complains: > > > > Checking filesystems > > Checking all file systems. > > [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/dasda1 > > fsck.ext3: No such device or address while trying to open /dev/dasda1 > > Possibly non-existent or swap device? > > [FAILED] > > > > (so that is after udev has been started and obviously dasda1 could be > > accessed) > > But /dev/dasda1 isn't present? Or why would fsck be complaining here? See above. /dev/dasda1 exists, but strangely as a character device, which makes fsck unhappy. > > > > When I look at the system, /sys/block/ and /sys/class/block/ look sane > > > at first glance (working on a 3270 console is usally PITA...) > > > > > > Even more surprisingly, the system comes up fine (once I added ptmx to > > > makedev.d/) with CONFIG_SYSFS_DEPRECATED not set. /sys/block/ > > > and /sys/class/block/ look just like expected. (Unfortunately, our > > > lsdasd tool breaks with this...) > > > > > > I'll see if I can find out more. > > > > I currently have the inkling that > > > > lrwxrwxrwx 1 root root0 May 22 15:59 block:dasda1-> > > ../../../class/block/dasda1 > > > > in /sys/block/dasda/ is the culprit. > > Why? See the paragraph just below, but it's more like a hunch currently. > > > In all other versions I've tried (without CONFIG_SYSFS_DEPRECATED, and > > on an older kernel with and without CONFIG_SYSFS_DEPRECATED), it's > > always dasda1. > > That's just a back symlink, the real device should still be there. It is, but somehow udev seems confused. > > Oh, and yes, you will probably have to have CONFIG_SYSFS_DEPRECATED > enabaled to have a chance for these to work on Fedora 4 or 3. Hmpf. That's just the problem :) - enable CONFIG_SYSFS_DEPRECATED: fails as described - disable CONFIG_SYSFS_DEPRECATED: works If one of the two was to fail, I'd rather expect it the other way around... > > > I can continue investigating tomorrow, unless someone has a good idea :) > > I don't, but any information you can find out would be greatly > appreciated, especially as it seems like it is working, but something is > still a little bit wrong. It's not really according to my definition of "working" :) But yes, I'll see what I can do. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sched - graphic smoothness under load - cfs-v13 sd-0.48
> That's because the whole premise of your benchmark relies on a workload that > yield()s itself to the eyeballs on most graphic card combinations when using > glxgears. Your test remains a test of sched_yield in the presence of your > workloads rather than anything else. If people like ck2 it's because in the > real world with real workloads it is better, rather than on a yield() based > benchmark. Repeatedly the reports are that 3d apps and games in normal usage > under -ck are better than mainline and cfs. While I can't comment on the technical/implementational details of Con's claim I definitely have to agree from a users POV. All my recent CPU intensive benchmarks show that both ck/sd and cfs are very decent scheduler and IMO superior to mainline for all _my_ usecases. In particular playing supertux while otherwise fully utilizing both CPUs on a dualcore works without any glitch and better than on mainline for both sd and cfs. For me the huge difference you have for sd to the others increases the likelyhood the glxgears benchmark does not measure scheduling of graphic but something else. Anyway, I'm still in the process of collecting data or more precisely until recently constantly refined what data to collect and how. I plan to provide new benchmark results on CPU intensive tasks in a couple of days. Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part.
Re: [PATCH] Re: Cleaning up the Documentation directory.
On Wed, May 23, 2007 at 12:25:44AM -0400, Rob Landley wrote: >mv arm cris blackfin parisc powerpc s390 x86_64 uml arch You missed sh, mips, fujitsu/frv, m68k, ia64, i386, and sparc. Is there really enough documentation for these that another directory level is worthwhile? 00-INDEX already covers most of these things, so it's not like there's any measurable confusion.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix/add raw1394 CONFIG_COMPAT code
On Sunday 20 May 2007 08:28, Stefan Richter wrote:
> Arnd Bergmann wrote:
> > On Sunday 20 May 2007, Stefan Richter wrote:
> >>> Note that this data structure only needs conversion on x86_64 and ia64,
but
> >>> not on powerpc and other 64 bit architectures that align __u64 also in
> >>> 32 bit mode.
> >> Is this conversion just unnecessary or actually harmful on ppc64 and
others?
> >
> > With the current patch, the compat_ioctl function does not handle the
ppc32
> > version of the structure at all, so it's broken there, it would at least
> > need a
> >
> > case RAW1394_IOC_GET_CYCLE_TIMER:
> > err = raw1394_ioctl(NULL, file, cmd, arg);
> > break;
>
> Dan,
>
> maybe we should change
>
> /* argument to RAW1394_IOC_GET_CYCLE_TIMER ioctl */
> struct raw1394_cycle_timer {
> /* contents of Isochronous Cycle Timer register,
> as in OHCI 1.1 clause 5.13 (also with non-OHCI hosts) */
> __u32 cycle_timer;
>
> /* local time in microseconds since Epoch,
> simultaneously read with cycle timer */
> __u64 local_time;
> };
>
> to
>
> /* argument to RAW1394_IOC_GET_CYCLE_TIMER ioctl */
> struct raw1394_cycle_timer {
> /*
>* least significant 32 bits are contents of Isochronous Cycle
>* Timer register, as in OHCI 1.1 clause 5.13 (also with
>* non-OHCI hosts)
>*/
> __u64 cycle_timer;
>
> /*
>* local time in microseconds since Epoch,
>* simultaneously read with cycle timer
>*/
> __u64 local_time;
> };
>
> before a libraw1394 with get-cycle-timer support is released.
> Shall I prepare according patches for raw1394 and libraw1394?
This seems like a good idea, and I have forwarded it to the ffado (formerly
freebob) developers, specifically Pieter Palmers--the submitter of
raw1394_read_cycle_timer--to get his feedback.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On 5/22/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > I shouldn't have to upgrade my BIOS to work with a new kernel any more > than I should have to upgrade my browser. We don't agree there, as you are not talking about a stable kernel series. Ah, so you're planning on submitting these patches for 2.7 then? 2.6 is perpetually stable. Matt is quite correct; feel free to ask for clarifications from Linus et al if you need guidance. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: Cleaning up the Documentation directory.
On Tuesday 22 May 2007 10:38 pm, Roland Dreier wrote: > > > I could send a patch to do this, but moving files via patch is icky. Would it > > be better to start a git tree and ask people to pull from it, or to send in > > script snippets like the above? > > Actually a git patch would express that very nicely -- just pass -M to > git-format-patch and it should do the right thing. Ok. Signed-off-by: Rob Landley <[EMAIL PROTECTED]> Move architecture documentation into "arch" and move multiport serio IO cards into serial. -- Equivalent to: cd Documentation mkdir -p arch/amiga mv zorro.txt arch/amiga mv arm cris blackfin parisc powerpc s390 x86_64 uml arch mv sx.txt stallion.txt specialix.txt rocket.txt riscom8.txt \ computone.txt hayes-esp.txt moxa-smartio serial diff --git a/Documentation/zorro.txt b/Documentation/arch/amiga/zorro.txt similarity index 100% rename from Documentation/zorro.txt rename to Documentation/arch/amiga/zorro.txt diff --git a/Documentation/arm/00-INDEX b/Documentation/arch/arm/00-INDEX similarity index 100% rename from Documentation/arm/00-INDEX rename to Documentation/arch/arm/00-INDEX diff --git a/Documentation/arm/Booting b/Documentation/arch/arm/Booting similarity index 100% rename from Documentation/arm/Booting rename to Documentation/arch/arm/Booting diff --git a/Documentation/arm/IXP2000 b/Documentation/arch/arm/IXP2000 similarity index 100% rename from Documentation/arm/IXP2000 rename to Documentation/arch/arm/IXP2000 diff --git a/Documentation/arm/IXP4xx b/Documentation/arch/arm/IXP4xx similarity index 100% rename from Documentation/arm/IXP4xx rename to Documentation/arch/arm/IXP4xx diff --git a/Documentation/arm/Interrupts b/Documentation/arch/arm/Interrupts similarity index 100% rename from Documentation/arm/Interrupts rename to Documentation/arch/arm/Interrupts diff --git a/Documentation/arm/Netwinder b/Documentation/arch/arm/Netwinder similarity index 100% rename from Documentation/arm/Netwinder rename to Documentation/arch/arm/Netwinder diff --git a/Documentation/arm/Porting b/Documentation/arch/arm/Porting similarity index 100% rename from Documentation/arm/Porting rename to Documentation/arch/arm/Porting diff --git a/Documentation/arm/README b/Documentation/arch/arm/README similarity index 100% rename from Documentation/arm/README rename to Documentation/arch/arm/README diff --git a/Documentation/arm/SA1100/ADSBitsy b/Documentation/arch/arm/SA1100/ADSBitsy similarity index 100% rename from Documentation/arm/SA1100/ADSBitsy rename to Documentation/arch/arm/SA1100/ADSBitsy diff --git a/Documentation/arm/SA1100/Assabet b/Documentation/arch/arm/SA1100/Assabet similarity index 100% rename from Documentation/arm/SA1100/Assabet rename to Documentation/arch/arm/SA1100/Assabet diff --git a/Documentation/arm/SA1100/Brutus b/Documentation/arch/arm/SA1100/Brutus similarity index 100% rename from Documentation/arm/SA1100/Brutus rename to Documentation/arch/arm/SA1100/Brutus diff --git a/Documentation/arm/SA1100/CERF b/Documentation/arch/arm/SA1100/CERF similarity index 100% rename from Documentation/arm/SA1100/CERF rename to Documentation/arch/arm/SA1100/CERF diff --git a/Documentation/arm/SA1100/FreeBird b/Documentation/arch/arm/SA1100/FreeBird similarity index 100% rename from Documentation/arm/SA1100/FreeBird rename to Documentation/arch/arm/SA1100/FreeBird diff --git a/Documentation/arm/SA1100/GraphicsClient b/Documentation/arch/arm/SA1100/GraphicsClient similarity index 100% rename from Documentation/arm/SA1100/GraphicsClient rename to Documentation/arch/arm/SA1100/GraphicsClient diff --git a/Documentation/arm/SA1100/GraphicsMaster b/Documentation/arch/arm/SA1100/GraphicsMaster similarity index 100% rename from Documentation/arm/SA1100/GraphicsMaster rename to Documentation/arch/arm/SA1100/GraphicsMaster diff --git a/Documentation/arm/SA1100/HUW_WEBPANEL b/Documentation/arch/arm/SA1100/HUW_WEBPANEL similarity index 100% rename from Documentation/arm/SA1100/HUW_WEBPANEL rename to Documentation/arch/arm/SA1100/HUW_WEBPANEL diff --git a/Documentation/arm/SA1100/Itsy b/Documentation/arch/arm/SA1100/Itsy similarity index 100% rename from Documentation/arm/SA1100/Itsy rename to Documentation/arch/arm/SA1100/Itsy diff --git a/Documentation/arm/SA1100/LART b/Documentation/arch/arm/SA1100/LART similarity index 100% rename from Documentation/arm/SA1100/LART rename to Documentation/arch/arm/SA1100/LART diff --git a/Documentation/arm/SA1100/PLEB b/Documentation/arch/arm/SA1100/PLEB similarity index 100% rename from Documentation/arm/SA1100/PLEB rename to Documentation/arch/arm/SA1100/PLEB diff --git a/Documentation/arm/SA1100/Pangolin b/Documentation/arch/arm/SA1100/Pangolin similarity index 100% rename from Documentation/arm/SA1100/Pangolin rename to Documentation/arch/arm/SA1100/Pangolin diff --git a/Documentation/arm/SA1100/Tifon b/Documentation/arch/arm/SA1100/Tifon similarity index 100% rename from Documentation/arm/SA1100/Tifon renam
Re: Race free attributes in sysfs
On Tue, May 22, 2007 at 10:38:57AM +0200, Cornelia Huck wrote: > On Mon, 21 May 2007 21:28:15 +0200, > Kay Sievers <[EMAIL PROTECTED]> wrote: > > > We could change the driver-core to suppress the creation of an attribute > > if the attribute's show() or store() method returns something like > > -ENOENT at registration time? > > The driver would pass _all_ possible attributes of the device at > > registration time, but the core would only create the attributes which > > are implemented for this particular device? Would that work for you? > > > > There are already subsystems who need to do similar things internally > > (firewire), and it may be nice to add such functionality to the core. > > This sounds a bit hackish (overloading the meaning of the show() and > store() methods). Firewire already does this today, it's actually really nice :) > > You can assign any number of attribute groups to the device. If they > > don't have a group name, they will all be created directly at the device > > level. Would that work for you? > > What about generic "conditional attribute groups"? Add a check() method > which is called just before adding them, and only add them if check() > returned 0 (or doesn't exist)? People want this on a per-attribute basis, if you did it on a group level, we would have a bunch of groups with only one attribute in it, which would be messy. 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: Race free attributes in sysfs
On Tue, May 22, 2007 at 05:40:50PM +0200, Pierre Ossman wrote: > Kay Sievers wrote: > > We could change the driver-core to suppress the creation of an attribute > > if the attribute's show() or store() method returns something like > > -ENOENT at registration time? > > The driver would pass _all_ possible attributes of the device at > > registration time, but the core would only create the attributes which > > are implemented for this particular device? Would that work for you? > > > > Not sure. Not in an obvious way at least. > > It also doesn't feel like "the kernel way". Generally you can > create/allocate an object, assign attributes to it, then activate it. > Couldn't it be done so that I can add sysfs stuff to a device after I > just initialized it? (but before I add it). No, unfortunatly it doesn't work that way today, sorry. > > You can assign any number of attribute groups to the device. If they > > don't have a group name, they will all be created directly at the device > > level. Would that work for you? > > > > > > I've had a look at sysfs groups and the biggest beef I have with those > is that they're too low level. In order to use them I first need to > create device attributes, then create an array of pointers to each attr > member. It would be nice if I could just feed an array of device > attributes (i.e. I want wrappers). If you can come up with a wrapper that will work, please let me know and I'll be glad to add it. Right now, it's pretty darn simple to do this (look at the USB and PCI core code for examples if you need it.) Anyway, groups are what you want and need, please use them and then you don't have to worry about triggering an event later after you have created your files on your own. I'll try to get the time to add the "create a group and test the files before adding them" variant soon so that firewire and others can use them easier instead of having to roll their own code for it. 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: Race free attributes in sysfs
On Tue, May 22, 2007 at 10:43:55PM -0400, Dmitry Torokhov wrote: > On Tuesday 22 May 2007 17:24, Mark Lord wrote: > > Dmitry Torokhov wrote: > > > 1. dev->uevent_suppress = 1; > > > 2. device_register(dev); > > > 3. device_create_file(dev, ...); > > > 4. dev->uevent_suppress = 0; > > > 5. kobject_uevent(&dev->kobj, KOBJ_ADD); > > > > I don't see how that prevents an already-running udevd > > from seeing the partially filled in /sys/ entry, > > if it were.. say.. already doing a /sys scan, > > or even just during initial startup. > > I tought udev relies on uevents and does not hunt through sysfs on > its own... Actually, udev can run without sysfs at all these days :) And yes, it only starts to look for things when it recieves an event, it does not "scan" sysfs at all. 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: 2.6.21-mm2: ACPI exception on resume
On Tue, 22 May 2007, Matt Mackall wrote: > Whether the 'bug' is in the firmware or the kernel, it is the kernel > that has regressed. Suspend worked fine for 2+ years before this. That means something, but not that much. The kernel could have been doing broken things for two years in ACPI that happened to not trigger a bug in someone's firmware, for example. And when the kernel was fixed (to, e.g., do it right by the spec or unbreak other firmwares that did it by the spec) and that triggered the bug. We really need to find the cause of the regression to know. > Breaking working systems, either software or hardware, is a bad idea. We shouldn't do it for frivoulous reasons, of course. > I shouldn't have to upgrade my BIOS to work with a new kernel any more > than I should have to upgrade my browser. We don't agree there, as you are not talking about a stable kernel series. And btw, unless you hunt down someone that also has the bug and uses an up-to-date BIOS (or something else to give an extra data point that discards a possible firmware bug in your version of the BIOS), or bissect to pinpoint what caused the regression, this thread will go nowhere. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sched - graphic smoothness under load - cfs-v13 sd-0.48
On Wednesday 23 May 2007 10:28, Bill Davidsen wrote: >>> kernel2.6.21-cfs-v132.6.21-ck2 >>> a)194464254669 >>> b)54159124 >> Everyone seems to like ck2, this makes it look as if the video display >> would be really pretty unusable. While sd-0.48 does show an occasional >> video glitch when watching video under heavy load, it's annoying rather >> than unusable. On Thu, May 24, 2007 at 10:36:44AM +1000, Con Kolivas wrote: > That's because the whole premise of your benchmark relies on a workload that > yield()s itself to the eyeballs on most graphic card combinations when using > glxgears. Your test remains a test of sched_yield in the presence of your > workloads rather than anything else. If people like ck2 it's because in the > real world with real workloads it is better, rather than on a yield() based > benchmark. Repeatedly the reports are that 3d apps and games in normal usage > under -ck are better than mainline and cfs. Maybe people should explicitly hack on sched_yield() for these things and do comparative benchmarking of sched_yield() implementations. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] Input updates ofr 2.6.22-rc2
Hi Linus, Please consider pulling from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus or master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for input subsystem. You will get bugfixes for ALPS touchpad, iforce force feedback support, ads7846 touchscreen and several small cleanups. Changelog: -- David Brownell (1): Input: ads7846 - document that it handles tsc2046 too Dmitry Torokhov (3): Input: adbhid - do not access input_dev->private directly Input: ALPS - force stream mode Input: ucb1x00-ts - remove commented out code Eric Piel (1): Input: input-polldev - add module info Johann Deneux (2): Input: iforce - fix force feedback not working Input: iforce - minor clean-ups Peter Samuelson (1): Input: logips2pp - add type 72 (PS/2 TrackMan Marble) Satoru Takeuchi (1): Input: ucb1400_ts - use sched_setscheduler() Semih Hazar (1): Input: ads7846 - SPI_CPHA mode bugfix drivers/input/joystick/iforce/iforce-main.c|4 +- drivers/input/joystick/iforce/iforce-packets.c | 10 +++- drivers/input/joystick/iforce/iforce-usb.c |5 +- drivers/input/misc/input-polldev.c |5 ++ drivers/input/mouse/alps.c | 58 +--- drivers/input/mouse/logips2pp.c|1 + drivers/input/touchscreen/Kconfig |8 ++-- drivers/input/touchscreen/ads7846.c|3 +- drivers/input/touchscreen/ucb1400_ts.c |4 +- drivers/macintosh/adbhid.c | 16 +++--- drivers/mfd/ucb1x00-ts.c | 11 + 11 files changed, 66 insertions(+), 59 deletions(-) -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LOCKDEP: possible irq lock inversion dependency detected
On Tue, 2007-05-22 at 17:19 -0700, Sven-Thorsten Dietrich wrote:
> swapper/1 just changed the state of lock:
>
> (rtc_lock#2){-...}, at: [] sbf_init+0x25/0xe0
>
> but this lock was taken by another, hard-irq-safe lock in the past:
>
> (xtime_lock){+...}
>
>
>
> and interrupts could create inverse lock ordering between them.
>
>
>
>
>
> other info that might help us debug this:
>
> no locks held by swapper/1.
>
>
>
> the first lock's dependencies:
>
> -> (rtc_lock#2){-...} ops: 2 {
>
>initial-use at:
>
> [] mark_lock+0xf3/0x5b0
>
> [] __lock_acquire+0x664/0xf80
>
> [] lock_acquire+0x88/0xc0
>
> [] rt_spin_lock+0x35/0x40
>
> [] read_persistent_clock+0x22/0x1b0
>
> [] timekeeping_init+0x86/0x100
>
> [] start_kernel+0x1bf/0x350
>
> [] _sinittext+0x179/0x180
>
> [] 0x
Hmm. That's the code in question:
void __init timekeeping_init(void)
{
unsigned long flags;
unsigned long sec = read_persistent_clock();
write_seqlock_irqsave(&xtime_lock, flags);
The rtc_lock is never taken inside the xtime_lock.
Looks like code reordering due to gcc extra magic. Which compiler ?
Thanks,
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: class_device_create() and the mode of the device file in /dev.
On 5/23/07, Y Khan <[EMAIL PROTECTED]> wrote: I am porting a driver from 2.4 to 2.6. I have replaced the call devfs_register() with class_create() and class_device_create(). Now, udev is automatically creating the device file in /dev. Please use device_create(), class_device_* will go away in the future. The device file being created has a default mode of 0600. Is it possible to override this default mode from inside the kernel. I do not want to do anything in the configuration file for udev. I could modify the attribute of the class and the class device but I do not think that they will change the default permissions for the /dev device file. devfs_register() used to take a mode argument. No, the kernel is not involved in specifying /dev permissions. You have to add a udev rule to assign a mode that isn't the default. Thanks, Kay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.21-rt6
On Tue, 2007-05-22 at 16:36 -0700, Sven-Thorsten Dietrich wrote: > On Tue, 2007-05-22 at 15:59 -0700, Sven-Thorsten Dietrich wrote: > > Add > > > header and export for rt_write_trylock_irqsave. > > Disregard the last patch, flags parameter was missing in the header. Signed-off-by is missing as well as a useful subject line :) Applied. Thanks, tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 -rt] ARM TLB flush fix: don't forget to re-enable preemption
On Tue, 2007-05-22 at 16:01 -0700, Kevin Hilman wrote: > Add a preempt_enable() to flush_tlb_kernel_page() since -rt4 patch > adds a preempt_disable but no preempt_enable(). > > Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]> Good catch. Applied. Thanks, tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [patch 00/69] -stable review
On Tue, May 22, 2007 at 09:28:34PM -0400, Fortier,Vincent [Montreal] wrote: > > -Message d'origine- > > De : [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] De la part de Chuck Ebbert > > Envoy? : 21 mai 2007 18:24 > > > > Adrian Bunk wrote: > > > On Mon, May 21, 2007 at 12:31:48PM -0700, Andrew Morton wrote: > > >> On Mon, 21 May 2007 12:16:12 -0700 > > >> Chris Wright <[EMAIL PROTECTED]> wrote: > > >> > > >>> This is the start of the stable review cycle for the 2.6.21.2 release. > > >> Gee a lot of these are fixing recently-added regressions :( ... > > > > > > If only it would fix all of them... > > > > > > Michal's list [1] currently contains 51 different regressions in > > > 2.6.21 compared to 2.6.20 (12 of them were already reported before > > > 2.6.21 was released). > > > > Yeah, 2.6.21 seems awfully buggy, and patches to fix many of > > the bugs haven't appeared. > > > > Another 2.6.20 update seems to be in order... > > Hi, > > If there is a new stable 2.6.20 / 2.6.21, would it be possible that they both > contain also this patch to keep the same behaviour between 2.6.20 -> 2.6.22 > kernels regarding paravirt_ops GPL export? > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=21564fd2a3deb48200b595332f9ed4c9f311f2a7 Why? Is there an in-kernel use for that export? 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/
[PATCH] powerpc: Fix Section mismatch warnings
This patch fix the following Section mismatch warnings
in powerpc code.
WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to
.init.data:mv643xx_eth_pd_devs from .text between 'mv643xx_eth_add_pds' (at
offset 0x9ed2) and 'gg2_read_config'
WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to
.init.data:mv643xx_eth_pd_devs from .text between 'mv643xx_eth_add_pds' (at
offset 0x9ed6) and 'gg2_read_config'
WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to
.init.text:note_scsi_host from __ksymtab between '__ksymtab_note_scsi_host' (at
offset 0x8) and '__ksymtab_sys_ctrler'
Signed-off-by: Li Yang <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/chrp/pegasos_eth.c |2 +-
arch/powerpc/platforms/powermac/setup.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/chrp/pegasos_eth.c
b/arch/powerpc/platforms/chrp/pegasos_eth.c
index 7104567..5bcc58d 100644
--- a/arch/powerpc/platforms/chrp/pegasos_eth.c
+++ b/arch/powerpc/platforms/chrp/pegasos_eth.c
@@ -169,7 +169,7 @@ static int Enable_SRAM(void)
/***/
/***/
-int mv643xx_eth_add_pds(void)
+static int __init mv643xx_eth_add_pds(void)
{
int ret = 0;
static struct pci_device_id pci_marvell_mv64360[] = {
diff --git a/arch/powerpc/platforms/powermac/setup.c
b/arch/powerpc/platforms/powermac/setup.c
index a410bc7..07b1c4e 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -384,7 +384,7 @@ int boot_part;
static dev_t boot_dev;
#ifdef CONFIG_SCSI
-void __init note_scsi_host(struct device_node *node, void *host)
+void note_scsi_host(struct device_node *node, void *host)
{
int l;
char *p;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 cifs_mount oops
On Wed, 23 May 2007 02:59:07 + "young dave" <[EMAIL PROTECTED]> wrote:
> Hi,
> maybe we can add if sentence before kthread_stop.
>
> diff -ur linux/fs/cifs/connect.c linux.new/fs/cifs/connect.c
> --- linux/fs/cifs/connect.c 2007-05-23 10:59:13.0 +
> +++ linux.new/fs/cifs/connect.c 2007-05-23 10:58:39.0 +
> @@ -2070,7 +2070,8 @@
> spin_unlock(&GlobalMid_Lock);
> if (srvTcp->tsk) {
> send_sig(SIGKILL,srvTcp->tsk,1);
> - kthread_stop(srvTcp->tsk);
> + if(srvTcp->tsk)
> + kthread_stop(srvTcp->tsk);
> }
> }
Yeah, that's racy: once we've sent the signal, the kernel thread can write
NULL to srvTcp->tsk at any time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 cifs_mount oops
Hi,
maybe we can add if sentence before kthread_stop.
diff -ur linux/fs/cifs/connect.c linux.new/fs/cifs/connect.c
--- linux/fs/cifs/connect.c 2007-05-23 10:59:13.0 +
+++ linux.new/fs/cifs/connect.c 2007-05-23 10:58:39.0 +
@@ -2070,7 +2070,8 @@
spin_unlock(&GlobalMid_Lock);
if (srvTcp->tsk) {
send_sig(SIGKILL,srvTcp->tsk,1);
- kthread_stop(srvTcp->tsk);
+ if(srvTcp->tsk)
+ kthread_stop(srvTcp->tsk);
}
}
Regards
dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [INPUT] i8042 not detecting AUX port
Hi, On Tuesday 22 May 2007 18:23, Emmanuel Fusté wrote: > Hello, > > Just to let you know that since I jumped from 2.6.16 to > 2.6.20.7 and 2.6.21, I need the i8042.noloop option to get the > AUX port detected. > Without this option, the kernel silently omit the AUX port, > only the KBD port is detected. > > If Dmitry is interested by a debug log, I will recompile a > kernel with i8042.debug support. You do not need to recompile anymore, just boot with i8042.debug. > I will try first to add the patch from Roland Scheidegger > witch is in the Linus tree. I doubt it will help, but I'd appreciate a dmesg with debug information from 2.6.21 or 2.6.22-rc2. Thannk you. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.21-rt6]
On Tue, 22 May 2007 19:01:27 -0700 Sven-Thorsten Dietrich wrote: > Restore the declaration of rcu_batches_completed_bh > > It is needed to compile with Classic RCU Please use a descriptive (and different) Subject: for each patch. Thanks. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Race free attributes in sysfs
On Tuesday 22 May 2007 17:24, Mark Lord wrote: > Dmitry Torokhov wrote: > > 1. dev->uevent_suppress = 1; > > 2. device_register(dev); > > 3. device_create_file(dev, ...); > > 4. dev->uevent_suppress = 0; > > 5. kobject_uevent(&dev->kobj, KOBJ_ADD); > > I don't see how that prevents an already-running udevd > from seeing the partially filled in /sys/ entry, > if it were.. say.. already doing a /sys scan, > or even just during initial startup. I tought udev relies on uevents and does not hunt through sysfs on its own... -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [scsi] Remove __GFP_DMA
On 5/23/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
On Mon, 21 May 2007, Bernhard Walle wrote:
> [PATCH] [scsi] Remove __GFP_DMA
>
> After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to alloate
a
> DMA buffer any more in sd.c.
>
> Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>
Great that avoids a DMA kmalloc slab. Any other GFP_DMAs left in the scsi
layer?
Acked-by: Christoph Lameter <[EMAIL PROTECTED]>
Yes, here is another patch
Signed-off-by: Aubrey.Li <[EMAIL PROTECTED]>
---
drivers/scsi/aacraid/commctrl.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/aacraid/commctrl.c b/drivers/scsi/aacraid/commctrl.c
index 72b0393..405722d 100644
--- a/drivers/scsi/aacraid/commctrl.c
+++ b/drivers/scsi/aacraid/commctrl.c
@@ -580,8 +580,8 @@ static int aac_send_raw_srb(struct aac_dev* dev,
void __user * arg)
for (i = 0; i < upsg->count; i++) {
u64 addr;
void* p;
- /* Does this really need to be GFP_DMA? */
- p =
kmalloc(upsg->sg[i].count,GFP_KERNEL|__GFP_DMA);
+
+ p = kmalloc(upsg->sg[i].count,GFP_KERNEL);
if(p == 0) {
dprintk((KERN_DEBUG"aacraid: Could not
allocate SG buffer - size
= %d buffer number %d of %d\n",
upsg->sg[i].count,i,upsg->count));
@@ -624,8 +624,8 @@ static int aac_send_raw_srb(struct aac_dev* dev,
void __user * arg)
for (i = 0; i < usg->count; i++) {
u64 addr;
void* p;
- /* Does this really need to be GFP_DMA? */
- p =
kmalloc(usg->sg[i].count,GFP_KERNEL|__GFP_DMA);
+
+ p = kmalloc(usg->sg[i].count,GFP_KERNEL);
if(p == 0) {
kfree (usg);
dprintk((KERN_DEBUG"aacraid: Could not
allocate SG buffer - size
= %d buffer number %d of %d\n",
@@ -666,8 +666,8 @@ static int aac_send_raw_srb(struct aac_dev* dev,
void __user * arg)
for (i = 0; i < upsg->count; i++) {
u64 addr;
void* p;
- /* Does this really need to be GFP_DMA? */
- p =
kmalloc(usg->sg[i].count,GFP_KERNEL|__GFP_DMA);
+
+ p = kmalloc(usg->sg[i].count,GFP_KERNEL);
if(p == 0) {
dprintk((KERN_DEBUG"aacraid: Could not
allocate SG buffer - size
= %d buffer number %d of %d\n",
usg->sg[i].count,i,usg->count));
--
1.5.1.1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Cleaning up the Documentation directory.
> cd Documentation > mkdir -p arch/amiga > mv zorro.txt arch/amiga > mv arm cris blackfin parisc powerpc s390 x86_64 uml arch > mv sx.txt stallion.txt specialix.txt rocket.txt riscom8.txt \ > computone.txt hayes-esp.txt moxa-smartio serial > I could send a patch to do this, but moving files via patch is icky. Would > it > be better to start a git tree and ask people to pull from it, or to send in > script snippets like the above? Actually a git patch would express that very nicely -- just pass -M to git-format-patch and it should do the right thing. - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 with 2.6.20 based kernels on SUSE 9.3
Sorry it has taken me so long to get back to this. I did finally make some time to dig into this more. roland wrote: >> Waiting for mandatory devices: eth-id-00:01:6c:ad:2b:c9 >> 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 1 0 >>eth-id-00:01:6c:ad:2b:c9No interface found >> failedSetting up service network . . . . . . . > > I had such issues when using suse 9.3 inside vmware very often - > typically removing network configuration completely in yast and > re-adding it fixed it for me - but sometimes it re-appeared, though - > and i never knew, why. > > Due to lack of time, i never dug into the device detection routines in > depth, but i assume there must be some issue in older suse with that > routines around "Waiting for mandatory devices" . > It seems, that this has gone better in more recent distros, but i see > that problem from time to time. > > You may also try setting MODULE_LOADED_ON_BOOT in /etc/sysconfig/kernel > , please report if this helps It does resolve the issue to add the modules to MODULES_LOADED_ON_BOOT. It also works to add hal and dbus to the dependencies of /etc/init.d/network like they are in SUSE 10.1. Thanks again. > > ## Path:System/Kernel > ## Description: Modules to load after initial boot > ## Type:string > ## ServiceRestart: boot.loadmodules > # > # This variable contains the list of modules to be loaded > # once the main filesystem is active > # > MODULES_LOADED_ON_BOOT="" > > > Just came across this one - maybe it`s worth taking a look: > http://en.opensuse.org/SDB:Waiting_for_Mandatory_Device > > regards > roland > > > > > > > List: linux-kernel > Subject:Problem with 2.6.20 based kernels on SUSE 9.3 > From: "K.R. Foley" > Date: 2007-02-12 15:51:51 > Message-ID: 45D08D17.8050808 () cybsft ! com > [Download message RAW] > > I am having a problem with 2.6.20 based kernels on SUSE 9.3. It boots > fine except that the network card is not detected at boot time. After > the system boots I can "modprobe " and the network comes up > fine. > > I am having this same problem on two different Suse 9.3 systems, one is > a a dual Xeon the other is an AMD Athlon. I have no such problems on > Suse 10.1 systems on similar hardware. Kernels prior to 2.6.20-rc? work > fine on these systems. > > The dual Xeon is using a 3Com card with the sk98lin driver. > :06:00.0 Ethernet controller: 3Com Corporation 3c940 > 10/100/1000Base-T [Marvell] (rev 10) > > The Athlon is using a SIS900 with the sis900 driver. > :00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] > SiS900 PCI Fast Ethernet (rev 91) > > I get the following when the system is booting: > > Setting up network interfaces: >lo >loIP address: 127.0.0.1/8 > doneWaiting for mandatory devices: eth-id-00:01:6c:ad:2b:c9 > 19 18 17 startproc: execve (/opt/kde3/bin/kdm) [ > /opt/kde3/bin/kdm ], [ LC_MONETARY= CONSOLE=/dev/console > ROOTFS_FSTYPE=reiserfs SHELL=/bin/sh TERM=linux ROOTFS_FSCK=0 > LC_NUMERIC= QTDIR=/usr/lib/qt3 LC_ALL= INIT_VERSION=sysvinit-2.85 > INIT=/sbin/init KDEROOTHOME=/root/.kdm REDIRECT=/dev/tty1 COLUMNS=128 > PATH=/sbin:/usr/sbin:/bin:/usr/bin:/lib/klibc/bin LC_MESSAGES= vga=0x317 > RUNLEVEL=5 LC_COLLATE= SPLASHCFG= PWD=/ LANG=en_US.UTF-8 > ROOTFS_REALDEV=/lib/klibc//dev/hda2 PREVLEVEL=N LINES=48 SHLVL=2 HOME=/ > XCURSOR_THEME=crystalwhite WINDOWMANAGER=/usr/X11R6/bin/kde > LC_CTYPE=en_US.UTF-8 SPLASH=no splash=silent LC_TIME= > ROOTFS_BLKDEV=/dev/hda2 _=/sbin/startproc DAEMON=/opt/kde3/bin/kdm ] > checkproc: /opt/kde3/bin/kdm 4094 > 16 15 14 13 12 11 10 9 8 7 6 5 4 3 1 0 >eth-id-00:01:6c:ad:2b:c9No interface found > failedSetting up service network . . . . . . . . . . . . . > . . .failed > > > I am attaching my config for the SMP system. Any ideas? Pointers? > > Thanks, > -- kr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Cleaning up the Documentation directory.
I would like to reorganize the Documentation directory, starting with the following: cd Documentation mkdir -p arch/amiga mv zorro.txt arch/amiga mv arm cris blackfin parisc powerpc s390 x86_64 uml arch mv sx.txt stallion.txt specialix.txt rocket.txt riscom8.txt \ computone.txt hayes-esp.txt moxa-smartio serial I could send a patch to do this, but moving files via patch is icky. Would it be better to start a git tree and ask people to pull from it, or to send in script snippets like the above? Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 cifs_mount oops
On Wed, 23 May 2007 00:50:13 + "young dave" <[EMAIL PROTECTED]> wrote:
> Hi,
> when I use mount -t cifs , the kernel oops, seems break at
> kthread_stop, I'm not sure.
>
> But if I add the CONFIG_CIFS_DEBUG2=y to config file, rebuild kernel,
> then the oops disappeared.
>
> Below is the oops message:
>
> BUG: unable to handle kernel NULL pointer dereference at virtual
> address 0008
> printing eip:
> c012e910
> *pde =
> Oops: 0002 [#1]
> PREEMPT
> Modules linked in: cifs smbfs radeon drm ipv6 snd_seq_dummy
> snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
> snd_mixer_oss capability commoncap e100 mii psmouse sg evdev serio_raw
> snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc intel_agp
> agpgart i2c_i801 pcspkr
> CPU:0
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00210246 (2.6.22-rc1-mm1 #3)
> EIP is at kthread_stop+0x10/0x90
> eax: c051bde0 ebx: ecx: c1fba000 edx: c1fef040
> esi: edi: 0064 ebp: c2a36c80 esp: c1fbbd58
> ds: 007b es: 007b fs: gs: 0033 ss: 0068
> Process mount.cifs (pid: 3955, ti=c1fba000 task=c2b38540 task.ti=c1fba000)
> Stack: c1fef040 ff90 ff90 f8a7a328 c285a504 f8a9a9fb 0083 00cf
>00dc 000b c2b38540 c2af5740 c292c540 c285a4c0
> c411b400 c3a4f500 c3cec200 c1fef052 c291c1e0 c1fef037 c291c940
> Call Trace:
> [] cifs_mount+0xbe8/0xf10 [cifs]
> [] idr_get_new_above_int+0x3e/0x50
> [] cifs_read_super+0x4e/0x160 [cifs]
> [] set_anon_super+0x0/0xd0
> [] cifs_get_sb+0x60/0xd0 [cifs]
> [] vfs_kern_mount+0x91/0x130
> [] permit_mount+0x28/0xa0
> [] do_new_mount+0x8a/0x140
> [] do_mount+0x25e/0x280
> [] schedule+0x2e0/0x680
> [] exact_copy_from_user+0x32/0x70
> [] copy_mount_options+0x5a/0xc0
> [] sys_mount+0x79/0xc0
> [] syscall_call+0x7/0xb
> ===
> Code: 88 d1 d3 e0 89 43 5c 83 c4 18 5b c3 eb 0d 90 90 90 90 90 90 90
> 90 90 90 90 90 90 53 83 ec 08 89 c3 b8 e0 bd 51 c0 e8 90 26 31 00
> 43 08 31 c9 b8 f0 c1 58 c0 89 0d ec c1 58 c0 e8 3b 01 00 00
> EIP: [] kthread_stop+0x10/0x90 SS:ESP 0068:c1fbbd58
>
I assume cifs_demultiplex_thread() took the SIGKILL, zeroed server->tsk
then exitted. Then, cifs_mount() did a kthread_stop() on the now-NULL
pointer.
I don't see a non-racy way of fixing this as the code stands at present.
This:
--- a/fs/cifs/connect.c~cifs-oops-fix
+++ a/fs/cifs/connect.c
@@ -2086,7 +2086,6 @@ cifs_mount(struct super_block *sb, struc
if ((temp_rc == -ESHUTDOWN) &&
(pSesInfo->server) &&
(pSesInfo->server->tsk)) {
send_sig(SIGKILL,pSesInfo->server->tsk,1);
-
kthread_stop(pSesInfo->server->tsk);
}
} else
cFYI(1, ("No session or bad tcon"));
_
has a decent chance of fixing it. But it's now racy against thread
*startup*: if we send SIGKILL to that task before it has done its
allow_signal(), it will presumably never get shut down.
Steve, can we just pull all the signal stuff out of there and use the
kthread machinery alone?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.21-rt6]
Restore the declaration of rcu_batches_completed_bh It is needed to compile with Classic RCU signed-off-by: Sven-Thorsten Dietrich <[EMAIL PROTECTED]> Index: linux-2.6.21-rt-patched/include/linux/rcupdate.h === --- linux-2.6.21-rt-patched.orig/include/linux/rcupdate.h +++ linux-2.6.21-rt-patched/include/linux/rcupdate.h @@ -227,6 +227,7 @@ extern void rcu_barrier(void); extern void rcu_init(void); extern void rcu_advance_callbacks(int cpu, int user); extern void rcu_check_callbacks(int cpu, int user); +extern long rcu_batches_completed_bh(void); #endif /* __KERNEL__ */ #endif /* __LINUX_RCUPDATE_H */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22-rc2
On Tue, 22 May 2007, Stephen Hemminger wrote: > > It looks like the chip reads the wrong memory sometimes. The problem happens > only on the on-board NIC's and only on this kind of motherboard. Do you know if it happens for particular addresses? (Ie, can you tell what the physical address of the descriptor is for the errors?) > For testing, I have put code in to check that the receive data actually > arrived before the IRQ, it triggered on my Gigabyte 925 motherboard. It > appears that DMA access is messed up. Yes, that certainly would also explain memory corruption. Either because writes went to the wrong address, or because writes went to the right address, but because an earlier IO descriptor read had gotten corrupted, the "right address" was in fact the wrong one ;) The reason I ask whether you have some way of telling the pattern for the physical address is that one traditional cause of DMA errors is due to broken RAM remapping setup. As an example of that - imagine that you have 1GB of RAM in the machine, and realize that the memory behind the 640kB -> 1MB area isn't accessible, because it's taken up by the legacy ISA region. You have two possible outcomes: either (a) the memory is just "gone", and you lost it, or (b) there is some RAM remapping in the core chipset that makes the lost 384kB show up _above_ the 1GB mark instead. The same "legacy ISA" hole situation happens for the "legacy PCI" hole, which is why if you have 4GB of RAM in the machine, usually you'll see 3GB at addresses 0-3GB (roughly), and then you'll see the rest at above the 4GB mark, in order to have a nice PCI hole in the 32-bit access range. There's also the "legacy 286" hole at the 15-16MB mark (which nobody uses any more, but chipsets still inexplicably support), and the SMM remapping. Anyway, core chipsets generally do CPU memory accesses _differently_ from DMA accesses from the PCI bus (at a minimum, SMM is something that only the CPU can do), so I could see a situation where the remapping was set up correctly for the CPU (and perhaps for "core chipset" devices like the integrated southbridge), but devices that do DMA from the outside get screwed over. But it might not happen for all addresses. Non-remapped stuff might work well, so if there is some way of figuring out what the bad DMA address was for an erreneous access, that might offer some clues. > This board has lots of "overclocker" friendly stuff; maybe the BIOS > never really sets up the PCI bridges and clocks properly. It's hard to set up a normal PCI-PCI bridge subtly incorrectly. But special RAM timing or remapping stuff for the host bridge - sure. > It doesn't seem like a software or driver problem. I have tried tweaking PCI > registers but nothing worked in this case. Yeah, the PCI registers that would affect things like this tend to be in the host bridge, not on the normal device. That said, Intel doesn't generally do the really insane things. And a lot of the old remapping stuff is simply not done any more. For example, I doubt that the 925 chipset even supports remapping the 640k-1M range any more: 384kB just isn't worth it when people talk about gigs of RAM, the way it was when 16MB was considered a lot. And looking quickly at the Intel 925X MCH (memory controller hub) registers, nothing jumps out as a good candidate for some obvious bug. 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: 2.6.21-mm2: ACPI exception on resume
On Tue, May 22, 2007 at 09:19:43PM -0300, Henrique de Moraes Holschuh wrote: > On Tue, 22 May 2007, Matt Mackall wrote: > > On Mon, May 21, 2007 at 08:03:49PM -0300, Henrique de Moraes Holschuh wrote: > > > On Mon, 21 May 2007, Matt Mackall wrote: > > > > BIOS Information > > > > Vendor: IBM > > > > Version: 1RETDHWW (3.13 ) > > > > Release Date: 10/29/2004 > > > > > > > > No sign of any EC version in the output. > > > > > > This is a buggy, ancient version of the BIOS, which probably means you > > > have > > > an old and slightly buggy EC firmware. I recommend you to upgrade to BIOS > > > 3.21 and EC 3.04. See http://thinkwiki.org/wiki/BIOS_Upgrade for more > > > details. > > > > Really, I'd much prefer my kernel not regress instead. Updating > > firmware is just introducing more potential instability and ignoring > > the problem. > > We can't very much know if the kernel is really buggy, then. Whether the 'bug' is in the firmware or the kernel, it is the kernel that has regressed. Suspend worked fine for 2+ years before this. Breaking working systems, either software or hardware, is a bad idea. I shouldn't have to upgrade my BIOS to work with a new kernel any more than I should have to upgrade my browser. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.21-rt6]
This patch properly exports __spin_lock_irqsave_nested. signed-off-by: Sven-Thorsten Dietrich <[EMAIL PROTECTED]> Index: linux-2.6.21/kernel/spinlock.c === --- linux-2.6.21.orig/kernel/spinlock.c +++ linux-2.6.21/kernel/spinlock.c @@ -366,7 +366,7 @@ __spin_lock_irqsave_nested(raw_spinlock_ #endif return flags; } -EXPORT_SYMBOL(_spin_lock_irqsave_nested); +EXPORT_SYMBOL(__spin_lock_irqsave_nested); #endif - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [patch 00/69] -stable review
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Chuck Ebbert > Envoyé : 21 mai 2007 18:24 > > Adrian Bunk wrote: > > On Mon, May 21, 2007 at 12:31:48PM -0700, Andrew Morton wrote: > >> On Mon, 21 May 2007 12:16:12 -0700 > >> Chris Wright <[EMAIL PROTECTED]> wrote: > >> > >>> This is the start of the stable review cycle for the 2.6.21.2 release. > >> Gee a lot of these are fixing recently-added regressions :( ... > > > > If only it would fix all of them... > > > > Michal's list [1] currently contains 51 different regressions in > > 2.6.21 compared to 2.6.20 (12 of them were already reported before > > 2.6.21 was released). > > Yeah, 2.6.21 seems awfully buggy, and patches to fix many of > the bugs haven't appeared. > > Another 2.6.20 update seems to be in order... Hi, If there is a new stable 2.6.20 / 2.6.21, would it be possible that they both contain also this patch to keep the same behaviour between 2.6.20 -> 2.6.22 kernels regarding paravirt_ops GPL export? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=21564fd2a3deb48200b595332f9ed4c9f311f2a7 Thnx! - vin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1
Hi,
I have tried the patch, it works.
could you explain it for me? thanks very much.
Regards
dave
2007/5/22, H. Peter Anvin <[EMAIL PROTECTED]>:
Could you try the attached patch for me?
-hpa
diff --git a/arch/i386/boot/edd.c b/arch/i386/boot/edd.c
index 84a0302..9697a56 100644
--- a/arch/i386/boot/edd.c
+++ b/arch/i386/boot/edd.c
@@ -47,8 +47,9 @@ static int read_sector(u8 devno, u64 lba, void *buf)
si = (size_t)&dapa;
dx = devno;
asm("pushfl; stc; int $0x13; setc %%al; popfl"
- : "+a" (ax), "+S" (si), "+d" (devno)
- : : "ebx", "ecx", "edi");
+ : "+a" (ax), "+S" (si), "+d" (dx)
+ : "m" (dapa)
+ : "ebx", "ecx", "edi", "memory");
if (!(u8)ax)
return 0; /* OK */
@@ -59,7 +60,7 @@ static int read_sector(u8 devno, u64 lba, void *buf)
bx = (size_t)buf;
asm("pushfl; stc; int $0x13; setc %%al; popfl"
: "+a" (ax), "+c" (cx), "+d" (dx), "+b" (bx)
- : : "esi", "edi");
+ : : "esi", "edi", "memory");
return -(u8)ax; /* 0 or -1 */
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/32] Blackfin update for 2.6.22-rc2
On Tue, May 22, 2007 at 08:28:28PM -0400, Mike Frysinger wrote: > On 5/21/07, Paul Mundt <[EMAIL PROTECTED]> wrote: > >On Mon, May 21, 2007 at 10:35:08AM -0400, Robin Getz wrote: > >> On Mon 21 May 2007 06:09, Bryan Wu pondered: > >> > Lots of update for 2.6.22-rc2 and tested on STAMP537 board. > >> > > >> > >> One of the things I noticed when trying out 2.6.22-rc1, on blackfin was: > >> > >> CALLscripts/checksyscalls.sh > >[snip syscalls] > >> > >> since there is noMMU, are we better: > >> - putting stubs (return ENOSYS - give runtime errors), or > >> - just ignore the errors - and give compile errors? (Is there any way > >to put > >> something into the syscall table, as not to get the warnings?) > > > >No, you'd be better of figuring out which ones you can support and which > >ones you have to -ENOSYS. CONFIG_MMU=n is not a "get out of syscalls > >free" card. Many of these have no dependency on CONFIG_MMU, anyways. > > when you say -ENOSYS, do you mean we need sys_foo() that simply does > return -ENOSYS or do we just let the default syscall code go "__NR_foo > is not registered, return -ENOSYS" The checksyscalls.sh errors come from the fact you have missing definitions in asm-blackfin/unistd.h, however, you still have reserved slots for most of these syscalls (and explicit sys_ni_syscall wrapping in the syscall table), just no __NR_foo definition. It's also not clear which of these you are explicitly never going to support versus the ones that simply haven't been implemented yet (ie, kexec support, restartable system calls -- how do you even do ppoll/pselect6 without supporting these?, and so on). I would suggest simply defining the __NR_foo values based on the reserved slots that they already occupy in order to silence these warnings, at least that's a closer approximation of "we've actually looked at these syscalls" than "new or otherwise unintentionally unimplemented", which is what the script aims to help with. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PCI MMCONFIG: add validation against ACPI motherboard resources
Jesse Barnes wrote: On Tuesday, May 22, 2007, Robert Hancock wrote: Eww. I don't see where we disable the decode at all while we probe the BARs on the device. That seems like a bad thing, especially with the way we probe 64-bit BARs (do the low 32 bits first and then the high 32 bits). This means the base address effectively gets set to 0xfff0 momentarily, which might cause some issues. I'm a bit shocked that things work as well as they do without the disabling... I'd try adding some code inside pci_setup_device (drivers/pci/probe.c) to disable PCI_COMMAND_IO and PCI_COMMAND_MEMORY on the device when probing devices with the standard header type and then restoring the previous command bits afterwards, and see what effect that has. It'll be interesting if it does, since obviously it seems to work as it is with non-MMCONFIG access methods. Maybe the base address being set like that interferes with MMCONFIG access itself somehow? I tried that, and it seems to get past probing the graphics device at least, but it hangs a bit later. It could be that the enable/disable I added wasn't correct though, I didn't check to see which one I should disable in the command word, which may be a problem (just disabled them both every probe). I'll try again with more precise enable/disable semantics. There was a big discussion about this back in 2002, in which Linus wasn't overly enthused about disabling the decode during probing due to risk of causing problems with some devices: http://lkml.org/lkml/2002/12/19/145 In this particular case (64-bit BAR) we might be able to avoid the problem by changing the order in which we probe the two halves of the address, i.e. change the top half to 0x before messing with the bottom half and then change it back last. That way, we end up mapping it way to the top of 64-bit address space, which hopefully is less likely to conflict.. -- 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: [RFC PATCH] PCI MMCONFIG: add validation against ACPI motherboard resources
On Tuesday, May 22, 2007, Robert Hancock wrote: > Jesse Barnes wrote: > > On Tuesday, May 22, 2007, Robert Hancock wrote: > >> Eww. I don't see where we disable the decode at all while we probe > >> the BARs on the device. That seems like a bad thing, especially with > >> the way we probe 64-bit BARs (do the low 32 bits first and then the > >> high 32 bits). This means the base address effectively gets set to > >> 0xfff0 momentarily, which might cause some issues. > > > > I'm a bit shocked that things work as well as they do without the > > disabling... > > > >> I'd try adding some code inside pci_setup_device > >> (drivers/pci/probe.c) to disable PCI_COMMAND_IO and > >> PCI_COMMAND_MEMORY on the device when probing devices with the > >> standard header type and then restoring the previous command bits > >> afterwards, and see what effect that has. It'll be interesting if it > >> does, since obviously it seems to work as it is with non-MMCONFIG > >> access methods. Maybe the base address being set like that interferes > >> with MMCONFIG access itself somehow? > > > > I tried that, and it seems to get past probing the graphics device at > > least, but it hangs a bit later. It could be that the enable/disable > > I added wasn't correct though, I didn't check to see which one I > > should disable in the command word, which may be a problem (just > > disabled them both every probe). I'll try again with more precise > > enable/disable semantics. > > It'd be interesting to see at what access it ran into trouble next, at > least if it's consistent. Could be that some device doesn't like having > the decode disabled.. I think it actually gets through the probing but hangs elsewhere, but I'll have to test again to be sure. Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PCI MMCONFIG: add validation against ACPI motherboard resources
Jesse Barnes wrote: On Tuesday, May 22, 2007, Robert Hancock wrote: Eww. I don't see where we disable the decode at all while we probe the BARs on the device. That seems like a bad thing, especially with the way we probe 64-bit BARs (do the low 32 bits first and then the high 32 bits). This means the base address effectively gets set to 0xfff0 momentarily, which might cause some issues. I'm a bit shocked that things work as well as they do without the disabling... I'd try adding some code inside pci_setup_device (drivers/pci/probe.c) to disable PCI_COMMAND_IO and PCI_COMMAND_MEMORY on the device when probing devices with the standard header type and then restoring the previous command bits afterwards, and see what effect that has. It'll be interesting if it does, since obviously it seems to work as it is with non-MMCONFIG access methods. Maybe the base address being set like that interferes with MMCONFIG access itself somehow? I tried that, and it seems to get past probing the graphics device at least, but it hangs a bit later. It could be that the enable/disable I added wasn't correct though, I didn't check to see which one I should disable in the command word, which may be a problem (just disabled them both every probe). I'll try again with more precise enable/disable semantics. It'd be interesting to see at what access it ran into trouble next, at least if it's consistent. Could be that some device doesn't like having the decode disabled.. -- 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: [PATCH 1/2] allow console unregistration
On Tue, 2007-05-22 at 14:43 -0700, Jesse Barnes wrote: > On Thursday, May 17, 2007, Antonino A. Daplas wrote: > > On Thu, 2007-05-17 at 15:32 -0700, Jesse Barnes wrote: > > > Randy just informed me that the patch limits are bigger now, so here > > > are the actual patches. > > > > > > This patch allows for proper console unregistration via the VT layer, > > > and updates the FB layer to use it. This makes debugging new console > > > drivers much easier, since you can properly clean them up before > > > unloading. Antonio already checked it out (and suggested a tweak for > > > the fbcon side) so I think it's on its way already via the FB tree. > > > > Sorry, I was busy and got sidetracked so I wasn't able to work on this > > for 2 weeks. Yes, this should work for now, at least for debugging > > purposes. I'll work on refining on fbcon side, hopefully for > > 2.6.22-2.6.23 time frame. > > Btw, here's an updated console unregister patchset with signoff in the > off chance you like it right away. :) > > When rmmod'd, some drivers might like to unregister the console they have > registered (e.g. the fbcon driver), so export unbind_con_driver. It > properly cleans up console references and takes care of switching to > one of the other registered drivers as needed. > I'm working on something that will need these functions (unbind/bind_con_driver) to be exposed, so I'm fine with this. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.22-rc1-mm1 cifs_mount oops
Hi, when I use mount -t cifs , the kernel oops, seems break at kthread_stop, I'm not sure. But if I add the CONFIG_CIFS_DEBUG2=y to config file, rebuild kernel, then the oops disappeared. Below is the oops message: BUG: unable to handle kernel NULL pointer dereference at virtual address 0008 printing eip: c012e910 *pde = Oops: 0002 [#1] PREEMPT Modules linked in: cifs smbfs radeon drm ipv6 snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss capability commoncap e100 mii psmouse sg evdev serio_raw snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc intel_agp agpgart i2c_i801 pcspkr CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00210246 (2.6.22-rc1-mm1 #3) EIP is at kthread_stop+0x10/0x90 eax: c051bde0 ebx: ecx: c1fba000 edx: c1fef040 esi: edi: 0064 ebp: c2a36c80 esp: c1fbbd58 ds: 007b es: 007b fs: gs: 0033 ss: 0068 Process mount.cifs (pid: 3955, ti=c1fba000 task=c2b38540 task.ti=c1fba000) Stack: c1fef040 ff90 ff90 f8a7a328 c285a504 f8a9a9fb 0083 00cf 00dc 000b c2b38540 c2af5740 c292c540 c285a4c0 c411b400 c3a4f500 c3cec200 c1fef052 c291c1e0 c1fef037 c291c940 Call Trace: [] cifs_mount+0xbe8/0xf10 [cifs] [] idr_get_new_above_int+0x3e/0x50 [] cifs_read_super+0x4e/0x160 [cifs] [] set_anon_super+0x0/0xd0 [] cifs_get_sb+0x60/0xd0 [cifs] [] vfs_kern_mount+0x91/0x130 [] permit_mount+0x28/0xa0 [] do_new_mount+0x8a/0x140 [] do_mount+0x25e/0x280 [] schedule+0x2e0/0x680 [] exact_copy_from_user+0x32/0x70 [] copy_mount_options+0x5a/0xc0 [] sys_mount+0x79/0xc0 [] syscall_call+0x7/0xb === Code: 88 d1 d3 e0 89 43 5c 83 c4 18 5b c3 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 90 53 83 ec 08 89 c3 b8 e0 bd 51 c0 e8 90 26 31 00 43 08 31 c9 b8 f0 c1 58 c0 89 0d ec c1 58 c0 e8 3b 01 00 00 EIP: [] kthread_stop+0x10/0x90 SS:ESP 0068:c1fbbd58 Regards dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] make fbcon unregister when unloaded
On Tue, 2007-05-22 at 15:14 -0700, Jesse Barnes wrote:
> On Tuesday, May 22, 2007 3:05 pm Randy Dunlap wrote:
> > On Tue, 22 May 2007 14:44:52 -0700 Jesse Barnes wrote:
> > > When unloaded, the fbcon driver should unregister itself from the
> > > VT subsystem using unbind_con_driver. This patch makes it use the
> > > newly exported function to do just that.
> > >
> > > Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
> > >
> > > diff -Napur -X /home/jbarnes/dontdiff --exclude=Makefile
> > > linux-2.6.22-rc2/drivers/video/console/fbcon.c
> > > linux-2.6.22-rc2-modesetting/drivers/video/console/fbcon.c ---
> > > linux-2.6.22-rc2/drivers/video/console/fbcon.c2007-05-18
> > > 21:06:17.0 -0700 +++
> > > linux-2.6.22-rc2-modesetting/drivers/video/console/fbcon.c2007-05-
> > >22 14:26:20.0 -0700 @@ -2937,6 +2937,21 @@ static int
> > > fbcon_mode_deleted(struct fb_ return found;
> > > }
> > >
> > > +static int fbcon_fb_unbind(int idx)
> > > +{
> > > + int i;
> > > +
> > > +for (i = 0; i < MAX_NR_CONSOLES; i++) {
> > > +/* Assure we do not unbind other drivers */
> > > +if (idx == con2fb_map[i])
> > > +/* can be optimize to minimize multiple
> > > calls to + unbind_con_driver() */
> >
> > /*
> > * can be optimized to minimize multiple calls
> > * to unbind_con_driver()
> > */
> >
> > > +unbind_con_driver(&fb_con, i, i, 0);
> > > +}
> > > +
> > > + return 0;
> > > +}
> >
> > Lots of whitespace mangling there (mostly spaces instead of tabs).
>
> Oops, thanks for looking. Somehow my emacs configuration broke and I
> don't see this as readily as I used to. If Antonio is ok with the
> patch otherwise, I'll respin it with the cleanups.
This should be a lot safer than the previous patch. This is fine as long
as only a single driver is driving the console. For multiple drivers, it
will need the change that I promised weeks ago :-). (And I will work on
it soon).
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] /sys/block -> /sys/class/block (Fedora 3 & 4 testers wanted)
On Tue, May 22, 2007 at 06:28:12PM +0200, Cornelia Huck wrote: > On Tue, 22 May 2007 10:25:01 +0200, > Cornelia Huck <[EMAIL PROTECTED]> wrote: > > > I tried this on one of our internal drivers, which is based on FC 3 (or > > 4, can look this up). With s390 defconfig, it is unable to open the > > root device /dev/dasda1 (which is unsurprising, considering udev (063) > > decided to create /dev/dasda(1) as a character node instead of a block > > node). > > Just to be clear, it's fsck that complains: > > Checking filesystems > Checking all file systems. > [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/dasda1 > fsck.ext3: No such device or address while trying to open /dev/dasda1 > Possibly non-existent or swap device? > [FAILED] > > (so that is after udev has been started and obviously dasda1 could be > accessed) But /dev/dasda1 isn't present? Or why would fsck be complaining here? > > When I look at the system, /sys/block/ and /sys/class/block/ look sane > > at first glance (working on a 3270 console is usally PITA...) > > > > Even more surprisingly, the system comes up fine (once I added ptmx to > > makedev.d/) with CONFIG_SYSFS_DEPRECATED not set. /sys/block/ > > and /sys/class/block/ look just like expected. (Unfortunately, our > > lsdasd tool breaks with this...) > > > > I'll see if I can find out more. > > I currently have the inkling that > > lrwxrwxrwx 1 root root0 May 22 15:59 block:dasda1-> > ../../../class/block/dasda1 > > in /sys/block/dasda/ is the culprit. Why? > In all other versions I've tried (without CONFIG_SYSFS_DEPRECATED, and > on an older kernel with and without CONFIG_SYSFS_DEPRECATED), it's > always dasda1. That's just a back symlink, the real device should still be there. Oh, and yes, you will probably have to have CONFIG_SYSFS_DEPRECATED enabaled to have a chance for these to work on Fedora 4 or 3. > I can continue investigating tomorrow, unless someone has a good idea :) I don't, but any information you can find out would be greatly appreciated, especially as it seems like it is working, but something is still a little bit wrong. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] enhancing the kernel's graphics subsystem
On Tue, 2007-05-22 at 16:36 -0700, Jesse Barnes wrote: > On Tuesday, May 22, 2007, Benjamin Herrenschmidt wrote: > > On Tue, 2007-05-22 at 08:39 -0700, Jesse Barnes wrote: > > > The current code does its best to figure out what modes are available > > > and tries to pick a good one for each display. It sounds like you're > > > mainly concerned with the actual mode picking, not the mode and output > > > detection and enumeration? If so, that's a pretty easy change to > > > make. But if you're also worried about the kernel building mode > > > lists, then we'll have bigger changes to make... > > > > I'm worried that the EDID we get from the monitor is bogus and needs to > > be overriden. > > > > Now, if the kernel builds a mode list, that's find if we have a call to > > "feed" it with a replacement one later on from userland. > > > > In addition, there are all those monitors that cannot be probed (no > > DDC/EDID) and for which only userland can reasonably provide a mode or a > > mode list. > > Yeah, we already have a call to add modes to the kernel's list, so we > should be covered. > We actually have a function that will replace the entire mode list with a new one safely. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sched - graphic smoothness under load - cfs-v13 sd-0.48
On Wednesday 23 May 2007 10:28, Bill Davidsen wrote: > > kernel2.6.21-cfs-v132.6.21-ck2 > > a)194464254669 > > b)54159124 > > Everyone seems to like ck2, this makes it look as if the video display > would be really pretty unusable. While sd-0.48 does show an occasional > video glitch when watching video under heavy load, it's annoying rather > than unusable. That's because the whole premise of your benchmark relies on a workload that yield()s itself to the eyeballs on most graphic card combinations when using glxgears. Your test remains a test of sched_yield in the presence of your workloads rather than anything else. If people like ck2 it's because in the real world with real workloads it is better, rather than on a yield() based benchmark. Repeatedly the reports are that 3d apps and games in normal usage under -ck are better than mainline and cfs. -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PCI MMCONFIG: add validation against ACPI motherboard resources
On Tuesday, May 22, 2007, Robert Hancock wrote: > Eww. I don't see where we disable the decode at all while we probe the > BARs on the device. That seems like a bad thing, especially with the way > we probe 64-bit BARs (do the low 32 bits first and then the high 32 > bits). This means the base address effectively gets set to 0xfff0 > momentarily, which might cause some issues. I'm a bit shocked that things work as well as they do without the disabling... > I'd try adding some code inside pci_setup_device (drivers/pci/probe.c) > to disable PCI_COMMAND_IO and PCI_COMMAND_MEMORY on the device when > probing devices with the standard header type and then restoring the > previous command bits afterwards, and see what effect that has. It'll be > interesting if it does, since obviously it seems to work as it is with > non-MMCONFIG access methods. Maybe the base address being set like that > interferes with MMCONFIG access itself somehow? I tried that, and it seems to get past probing the graphics device at least, but it hangs a bit later. It could be that the enable/disable I added wasn't correct though, I didn't check to see which one I should disable in the command word, which may be a problem (just disabled them both every probe). I'll try again with more precise enable/disable semantics. Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] joydev.c automatic re-calibration
This small patch adds the automatic recalibration feature without
spoiling previously calibrated devices. It's a fix for those joysticks
that report faulty range, specially Saitek Cyborg Evo Force.
File: drivers/input/joydev.c
Fix:
- extracted code from joydev_connect to method
joydev_calculate_correction to be able to call it from both
joydev_event upon recalibration and joydev_connect during first
connection.
- on joydev_connect check ranges and zero calibration if found out of range
- on joydev_event, every time found out of range, update min/max and
recalculate the correction
Patch below and attached.
cheers,
--renato
== PATCH BEGIN ==
--- joydev.c.original 2007-05-22 22:23:43.0 +0100
+++ joydev.c2007-05-23 01:24:04.0 +0100
@@ -53,6 +53,8 @@
__u8 absmap[ABS_MAX + 1];
__u8 abspam[ABS_MAX + 1];
__s16 abs[ABS_MAX + 1];
+ __s16 absmin[ABS_MAX + 1];
+ __s16 absmax[ABS_MAX + 1];
};
struct joydev_list {
@@ -67,6 +69,19 @@
static struct joydev *joydev_table[JOYDEV_MINORS];
+static void joydev_calculate_correction(int min, int max, int axis,
struct joydev *joydev)
+{
+ int t, j = joydev->abspam[axis];
+ int flat = joydev->handle.dev->absflat[j];
+
+ joydev->corr[axis].coef[0] = (max + min) / 2 - flat;
+ joydev->corr[axis].coef[1] = (max + min) / 2 + flat;
+ if (!(t = ((max - min) / 2 - 2 * flat)))
+ return;
+ joydev->corr[axis].coef[2] = (1 << 29) / t;
+ joydev->corr[axis].coef[3] = (1 << 29) / t;
+}
+
static int joydev_correct(int value, struct js_corr *corr)
{
switch (corr->type) {
@@ -103,6 +118,14 @@
case EV_ABS:
event.type = JS_EVENT_AXIS;
event.number = joydev->absmap[code];
+ /* recalibration if needed */
+ if (value < joydev->absmin[code]) {
+ joydev->absmin[code] = value;
+ joydev_calculate_correction(value,
joydev->absmax[code], code, joydev);
+ } else if (value > joydev->absmax[code]) {
+ joydev->absmax[code] = value;
+
joydev_calculate_correction(joydev->absmin[code], value, code,
joydev);
+ }
event.value = joydev_correct(value,
joydev->corr + event.number);
if (event.value == joydev->abs[event.number])
return;
@@ -470,7 +493,7 @@
{
struct joydev *joydev;
struct class_device *cdev;
- int i, j, t, minor;
+ int i, j, minor;
for (minor = 0; minor < JOYDEV_MINORS && joydev_table[minor]; minor++);
if (minor == JOYDEV_MINORS) {
@@ -515,19 +538,21 @@
for (i = 0; i < joydev->nabs; i++) {
j = joydev->abspam[i];
- if (dev->absmax[j] == dev->absmin[j]) {
+ joydev->absmin[i] = dev->absmin[j];
+ joydev->absmax[i] = dev->absmax[j];
+ if (joydev->absmax[i] == joydev->absmin[i]) {
joydev->corr[i].type = JS_CORR_NONE;
joydev->abs[i] = dev->abs[j];
continue;
}
joydev->corr[i].type = JS_CORR_BROKEN;
joydev->corr[i].prec = dev->absfuzz[j];
- joydev->corr[i].coef[0] = (dev->absmax[j] +
dev->absmin[j]) / 2 - dev->absflat[j];
- joydev->corr[i].coef[1] = (dev->absmax[j] +
dev->absmin[j]) / 2 + dev->absflat[j];
- if (!(t = ((dev->absmax[j] - dev->absmin[j]) / 2 - 2 *
dev->absflat[j])))
- continue;
- joydev->corr[i].coef[2] = (1 << 29) / t;
- joydev->corr[i].coef[3] = (1 << 29) / t;
+
+ if (dev->abs[j] > joydev->absmax[i] || dev->abs[j] <
joydev->absmin[i]) {
+ printk("Joydev: Bad axis range, recalibrating
automatically\n");
+ joydev_calculate_correction(0, 0, i, joydev);
+ } else
+ joydev_calculate_correction(joydev->absmin[i],
joydev->absmax[i], i, joydev);
joydev->abs[i] = joydev_correct(dev->abs[j], joydev->corr + i);
}
== PATCH END ==
--- joydev.c.original 2007-05-22 22:23:43.0 +0100
+++ joydev.c 2007-05-23 01:24:04.0 +0100
@@ -53,6 +53,8 @@
__u8 absmap[ABS_MAX + 1];
__u8 abspam[ABS_MAX + 1];
__s16 abs[ABS_MAX + 1];
+ __s16 absmin[ABS_MAX + 1];
+ __s16 absmax[ABS_MAX + 1];
};
struct joydev_list {
@@ -67,6 +69,19 @@
static struct joydev *joydev_table[JOYDEV_MINORS];
+static void joydev_calculate_correction(int min, int max, int axis, struct joydev *joydev)
+{
+ int t, j = joydev->abspam[axis];
+ int flat = joydev->handle.dev->absflat[j];
+
+ joydev->corr[axis].coef[0] = (max + min) / 2 - flat;
+ joydev->corr[axis].coef[1] = (max + min) / 2 + flat;
+ if (!(t = ((max - min) / 2 - 2 * flat)))
+ return;
+ joydev->corr[axis]
Re: [RFC PATCH] PCI MMCONFIG: add validation against ACPI motherboard resources
Jesse Barnes wrote: On Monday, May 21, 2007, Jesse Barnes wrote: Yeah, I've got that data... just a sec while I make sure it's reproducable... Aha, I hadn't decoded the devfn before, looks like it's dying on an access to the graphics device (bus 0, slot 2, device 0): ... pci_mmcfg_read: 0, 0, 0x10, 0x18, 4 = 0xc00c pci_mmcfg_read: 0, 0, 0x10, 0x18, 4 = ... Offset 0x18 into the graphics config space should be the graphics memory range address, and 0xc00c is the correct value. But for some reason it hangs on the second access. It hangs here everytime. That register is in the config space BAR region, so it should be ok to write 0x to it and read it back to size the register. However, it's after writing the 0x to it and trying to read it back that the machine hangs. I didn't see any accesses to the command register to disable decoding (at least not via the mmconfig methods), so maybe that's broken during MCFG based probing? Eww. I don't see where we disable the decode at all while we probe the BARs on the device. That seems like a bad thing, especially with the way we probe 64-bit BARs (do the low 32 bits first and then the high 32 bits). This means the base address effectively gets set to 0xfff0 momentarily, which might cause some issues. I'd try adding some code inside pci_setup_device (drivers/pci/probe.c) to disable PCI_COMMAND_IO and PCI_COMMAND_MEMORY on the device when probing devices with the standard header type and then restoring the previous command bits afterwards, and see what effect that has. It'll be interesting if it does, since obviously it seems to work as it is with non-MMCONFIG access methods. Maybe the base address being set like that interferes with MMCONFIG access itself somehow? -- 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: [PATCH 00/32] Blackfin update for 2.6.22-rc2
On 5/21/07, Paul Mundt <[EMAIL PROTECTED]> wrote: On Mon, May 21, 2007 at 10:35:08AM -0400, Robin Getz wrote: > On Mon 21 May 2007 06:09, Bryan Wu pondered: > > Lots of update for 2.6.22-rc2 and tested on STAMP537 board. > > > > One of the things I noticed when trying out 2.6.22-rc1, on blackfin was: > > CALLscripts/checksyscalls.sh [snip syscalls] > > since there is noMMU, are we better: > - putting stubs (return ENOSYS - give runtime errors), or > - just ignore the errors - and give compile errors? (Is there any way to put > something into the syscall table, as not to get the warnings?) No, you'd be better of figuring out which ones you can support and which ones you have to -ENOSYS. CONFIG_MMU=n is not a "get out of syscalls free" card. Many of these have no dependency on CONFIG_MMU, anyways. when you say -ENOSYS, do you mean we need sys_foo() that simply does return -ENOSYS or do we just let the default syscall code go "__NR_foo is not registered, return -ENOSYS" -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: Linux 2.6.22-rc2
Linus Torvalds wrote: On Tue, 22 May 2007, Mike Houston wrote: In this case I actually had the kernel crash. First time for me ever having a kernel oops! System locked up with keyboard LED's blinking. Not sure if anyone wants to see all of it (maybe some screwy userland stuff involved), so I won't include that mess in the message. It's here: http://www.mikeserv.org/files/kernelcrash.txt I think you have major memory corruption. That first oops disassembles to mov0x10(%eax),%esi mov$0xfdfd,%eax test %esi,%esi je after_call mov%edx,%ecx mov%edi,%eax mov%ebx,%edx call *%esi after_call: which is (from net/ipv4/af_inet.c, inet_ioctl()): default: if (sk->sk_prot->ioctl) err = sk->sk_prot->ioctl(sk, cmd, arg); else err = -ENOIOCTLCMD; break; and the load off "sk->sk_prot->ioctl" oopses, because "sk->sk_prot" is corrupt and contains 0x8e3cad42, which is not a valid kernel pointer. The other oops is even worse. I also think it meshes with sky2 eth0: descriptor error q=0x280 get=285 [800042375e2e5e] put=285 Descriptor error means, the driver told it to do something but the OWNER bit wasn't set. Only ever saw this on the Gigabyte motherboard. It looks like the chip reads the wrong memory sometimes. The problem happens only on the on-board NIC's and only on this kind of motherboard. For testing, I have put code in to check that the receive data actually arrived before the IRQ, it triggered on my Gigabyte 925 motherboard. It appears that DMA access is messed up. This board has lots of "overclocker" friendly stuff; maybe the BIOS never really sets up the PCI bridges and clocks properly. It doesn't seem like a software or driver problem. I have tried tweaking PCI registers but nothing worked in this case. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sched - graphic smoothness under load - cfs-v13 sd-0.48
Miguel Figueiredo wrote:
Bill Davidsen wrote:
Miguel Figueiredo wrote:
Ray Lee wrote:
On 5/20/07, Miguel Figueiredo <[EMAIL PROTECTED]> wrote:
As I tryied myself kernels 2.6.21, 2.6.21-cfs-v13, and 2.6.21-ck2
on the
same machine i found *very* odd those numbers you posted, so i tested
myself those kernels to see the numbers I get instead of talking
about
the usage of kernel xpto feels like.
I did run glxgears with kernels 2.6.21, 2.6.21-cfs-v13 and 2.6.21-ck2
inside Debian's GNOME environment. The hardware is an AMD
Sempron64 3.0
GHz, 1 GB RAM, Nvidia 6800XT.
Average and standard deviation from the gathered data:
* 2.6.21: average = 11251.1; stdev = 0.172
* 2.6.21-cfs-v13: average = 11242.8; stdev = 0.033
* 2.6.21-ck2: average = 11257.8; stdev = 0.067
Keep in mind those numbers don't mean anything we all know
glxgears is
not a benchmark, their purpose is only to be used as comparison under
the same conditions.
Uhm, then why are you trying to use them to compare against Bill's
numbers? You two have completely different hardware setups, and this
is a test that is dependent upon hardware. Stated differently, this is
a worthless comparison between your results and his as you are
changing multiple variables at the same time. (At minimum: the
scheduler, cpu, and video card.)
The only thing i want to see it's the difference between the
behaviour of the different schedulers on the same test setup. In my
test -ck2 was a bit better, not 200% worse as in Bill's
measurements. I don't compare absolute values on different test setups.
Since I didn't test ck2 I'm sure your numbers are unique, I only
tested the sd-0.48 patch set. I have the ck2 patch, just haven't
tried it yet... But since there are a lot of other things in it, I'm
unsure how it relates to what I was testing.
One odd thing i noticed, with 2.6.21-cfs-v13 the gnome's time
applet in
the bar skipped some minutes (e.g. 16:23 -> 16:25) several times.
The data is available on:
http://www.debianPT.org/~elmig/pool/kernel/20070520/
How did you get your data? I am affraid your data it's wrong,
there's no
such big difference between the schedulers...
It doesn't look like you were running his glitch1 script which starts
several in glxgears parallel. Were you, or were you just running one?
No i'm not, i'm running only one instance of glxgears inside the
GNOME's environment.
If you test the same conditions as I did let me know your results.
Hi Bill,
if i've understood correctly the script runs glxgears for 43 seconds
and in that time generates random numbers in a random number of times
(processes, fork and forget), is that it?
No, I haven't made it clear. A known number (default four) of xterms are
started, each of which calculates random numbers and prints them, using
much CPU time and causing a lot of scrolling. At the same time glxgears
is running, and the smoothness (or not) is observed manually. The script
records raw data on the number of frames per second and the number of
random numbers calculated by each shell. Since these are FAIR
schedulers, the variance between the scripts, and between multiple
samples from glxgears is of interest. To avoid startup effects the
glxgears value from the first sample is reported separately and not
included in the statistics.
I looked at your results, and they are disturbing to say the least, it
appears that using the ck2 scheduler glxgears stopped for all practical
purposes. You don't have quite the latest glitch1, the new one runs
longer and allows reruns to get several datasets, but the results still
show very slow gears and a large difference between the work done by the
four shells. That's not a good result, how did the system feel?
You find the data, for 2.6.21-{cfs-v13, ck2} in
http://www.debianpt.org/~elmig/pool/kernel/20070522/
Thank you, these results are very surprising, and I would not expect the
system to be pleasing the use under load, based on this.
Here's the funny part...
Lets call:
a) to "random number of processes run while glxgears is running",
gl_fairloops file
It's really the relative work done by identical processes, hopefully
they are all nearly the same, magnitude is interesting but related to
responsiveness rather than fairness.
b) to "generated frames while running a burst of processes" aka
"massive and uknown amount of operations in one process", gl_gears file
Well, top or ps will give you a good idea of processing, but it tried to
use all of one CPU if allowed. Again, similarity of samples reflects
fairness and magnitude reflects work done.
kernel2.6.21-cfs-v132.6.21-ck2
a)194464254669
b)54159124
Everyone seems to like ck2, this makes it look as if the video display
would be really pretty
RE: 2.6.22-rc1-mm1 - s390 vs. md
> From: Cornelia Huck [mailto:[EMAIL PROTECTED]
> On Fri, 18 May 2007 09:30:09 -0700,
> "Williams, Dan J" <[EMAIL PROTECTED]> wrote:
>
> > When CONFIG_DMA_ENGINE=n async_tx_find_channel takes the form:
> > ... async_tx_find_channel( ... )
> > {
> > return NULL;
> > }
> >
> > So in the S390 case the entire asynchronous path will be compiled
away.
>
> Unfortunately, do_async_xor() (and others) is not ifdef'ed and
contains
> dma_map_page(), which led to the compile failure...
The approach I have taken is to add the missing definitions to
include/asm-s390/dma-mapping.h [ a non-outlook-mangled version of the
patch is pushed out in my rebased git tree ]. I was not able to fully
compile-test this change as the three s390-cross-toolchains I tried each
died early in the kernel build process. The most common error was:
"s390-unknown-linux-gnu-ld: unrecognised emulation mode: elf64_s390"
---
s390: add dma mapping api stub definitions for async_tx
From: Dan Williams <[EMAIL PROTECTED]>
The asynchronous path in async_tx is meant to be compiled away on
platforms
like s390 with CONFIG_DMA_ENGINE=n. However, it is difficult to compile
something away if it does not compile in the first place. This patch
adds
the missing dma api definitions as BUG() stubs.
Cc: Cornelia Huck <[EMAIL PROTECTED]>
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
---
include/asm-s390/dma-mapping.h | 78
1 files changed, 78 insertions(+), 0 deletions(-)
diff --git a/include/asm-s390/dma-mapping.h
b/include/asm-s390/dma-mapping.h
index 3f8c12f..33a3c82 100644
--- a/include/asm-s390/dma-mapping.h
+++ b/include/asm-s390/dma-mapping.h
@@ -4,9 +4,87 @@
* S390 version
*
* This file exists so that #include doesn't break
anything.
+ * It also includes stub definitions of the API so common code like
async_tx
+ * can compile.
*/
#ifndef _ASM_DMA_MAPPING_H
#define _ASM_DMA_MAPPING_H
+#include
+#include
+
+static inline dma_addr_t
+dma_map_single(struct device *dev, void *cpu_addr, size_t size,
+ enum dma_data_direction dir)
+{
+ BUG();
+ return 0;
+}
+
+static inline dma_addr_t
+dma_map_page(struct device *dev, struct page *page,
+unsigned long offset, size_t size,
+enum dma_data_direction dir)
+{
+ BUG();
+ return 0;
+}
+
+static inline void
+dma_unmap_single(struct device *dev, dma_addr_t handle, size_t size,
+ enum dma_data_direction dir)
+{
+ BUG();
+}
+
+static inline void
+dma_unmap_page(struct device *dev, dma_addr_t handle, size_t size,
+ enum dma_data_direction dir)
+{
+ BUG();
+}
+
+static inline int
+dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
+ enum dma_data_direction dir)
+{
+ BUG();
+ return 0;
+}
+
+static inline void
+dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
+enum dma_data_direction dir)
+{
+ BUG();
+}
+
+static inline void
+dma_sync_single_for_cpu(struct device *dev, dma_addr_t handle, size_t
size,
+ enum dma_data_direction dir)
+{
+ BUG();
+}
+
+static inline void
+dma_sync_single_for_device(struct device *dev, dma_addr_t handle,
size_t size,
+ enum dma_data_direction dir)
+{
+ BUG();
+}
+
+static inline void
+dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, int
nents,
+ enum dma_data_direction dir)
+{
+ BUG();
+}
+
+static inline void
+dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int
nents,
+ enum dma_data_direction dir)
+{
+ BUG();
+}
#endif /* _ASM_DMA_MAPPING_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: [stable] Wanted: Allow adding new device IDs during the -stable cycle
* Jeff Garzik ([EMAIL PROTECTED]) wrote: > Chris Wright wrote: > >2) In theory new hardware can seem to work with a simple PCI ID > >update, and later we find it needs extra quirk handling or specific > >driver support. This could mean adding buggy support for new hardware > >to -stable. In practice, hopefully this isn't a real issue. > > No need to worry about theory. Since you are (or should be???) taking > stuff solely from upstream, you should already know what is needed, or not. Yup, it's definitely handwavy. If it's a problem we can address it then. thanks, -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 2/3] kernel-doc: fix unnamed struct/union warning
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix kernel-doc warning:
Warning(linux-2.6.22-rc2-git2/include/linux/skbuff.h:316): No description found
for parameter '}'
which is caused by nested anonymous structs/unions ending with:
};
};
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
scripts/kernel-doc | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
--- linux-2.6.22-rc2-git2.orig/scripts/kernel-doc
+++ linux-2.6.22-rc2-git2/scripts/kernel-doc
@@ -154,6 +154,7 @@ use strict;
my $errors = 0;
my $warnings = 0;
+my $anon_struct_union = 0;
# match expressions used to find embedded type information
my $type_constant = '\%([-_\w]+)';
@@ -1510,8 +1511,13 @@ sub push_parameter($$$) {
my $param = shift;
my $type = shift;
my $file = shift;
- my $anon = 0;
+ if (($anon_struct_union == 1) && ($type eq "") &&
+ ($param eq "}")) {
+ return; # ignore the ending }; from anon. struct/union
+ }
+
+ $anon_struct_union = 0;
my $param_name = $param;
$param_name =~ s/\[.*//;
@@ -1530,16 +1536,16 @@ sub push_parameter($$$) {
# handle unnamed (anonymous) union or struct:
{
$type = $param;
- $param = "{unnamed_" . $param. "}";
+ $param = "{unnamed_" . $param . "}";
$parameterdescs{$param} = "anonymous\n";
- $anon = 1;
+ $anon_struct_union = 1;
}
# warn if parameter has no description
# (but ignore ones starting with # as these are not parameters
# but inline preprocessor statements);
# also ignore unnamed structs/unions;
- if (!$anon) {
+ if (!$anon_struct_union) {
if (!defined $parameterdescs{$param_name} && $param_name !~ /^#/) {
$parameterdescs{$param_name} = $undescribed;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] kernel-doc: add tools doc in Makefile
From: Randy Dunlap <[EMAIL PROTECTED]> Add kernel-doc tools info in Makefile. Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- Documentation/DocBook/Makefile | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) --- linux-2.6.22-rc2-git2.orig/Documentation/DocBook/Makefile +++ linux-2.6.22-rc2-git2/Documentation/DocBook/Makefile @@ -15,11 +15,11 @@ DOCBOOKS := wanbook.xml z8530book.xml mc ### # The build process is as follows (targets): -# (xmldocs) -# file.tmpl --> file.xml +--> file.ps (psdocs) -#+--> file.pdf (pdfdocs) -#+--> DIR=file (htmldocs) -#+--> man/ (mandocs) +# (xmldocs) [by docproc] +# file.tmpl --> file.xml +--> file.ps (psdocs) [by db2ps or xmlto] +#+--> file.pdf (pdfdocs) [by db2pdf or xmlto] +#+--> DIR=file (htmldocs) [by xmlto] +#+--> man/ (mandocs) [by xmlto] # for PDF and PS output you can choose between xmlto and docbook-utils tools - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 3/3] kernel-doc: strip C99 comments
From: Randy Dunlap <[EMAIL PROTECTED]>
Strip C99-style comments from the input stream.
/*...*/ comments are already stripped.
C99 comments confuse the kernel-doc script.
Also update some comments.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
scripts/kernel-doc |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- linux-2.6.22-rc2-git2.orig/scripts/kernel-doc
+++ linux-2.6.22-rc2-git2/scripts/kernel-doc
@@ -719,6 +719,7 @@ sub output_struct_xml(%) {
# pointer-to-function
print " $1 $parameter) ($2);\n";
} elsif ($type =~ m/^(.*?)\s*(:.*)/) {
+ # bitfield
print " $1 $parameter$2;\n";
} else {
print " ".$type." ".$parameter.";\n";
@@ -1261,6 +1262,7 @@ sub output_struct_text(%) {
# pointer-to-function
print "\t$1 $parameter) ($2);\n";
} elsif ($type =~ m/^(.*?)\s*(:.*)/) {
+ # bitfield
print "\t$1 $parameter$2;\n";
} else {
print "\t".$type." ".$parameter.";\n";
@@ -1697,6 +1699,8 @@ sub process_state3_function($$) {
my $x = shift;
my $file = shift;
+$x =~ [EMAIL PROTECTED]/\/.*$@@gos; # strip C99-style comments to end of
line
+
if ($x =~ m#\s*/\*\s+MACDOC\s*#io || ($x =~ /^#/ && $x !~ /^#define/)) {
# do nothing
}
@@ -1719,6 +1723,8 @@ sub process_state3_type($$) {
$x =~ [EMAIL PROTECTED]@ @gos; # strip newlines/cr's.
$x =~ [EMAIL PROTECTED]@@gos; # strip leading spaces
$x =~ [EMAIL PROTECTED]@@gos; # strip trailing spaces
+$x =~ [EMAIL PROTECTED]/\/.*$@@gos; # strip C99-style comments to end of
line
+
if ($x =~ /^#/) {
# To distinguish preprocessor directive from regular declaration later.
$x .= ";";
@@ -1802,7 +1808,7 @@ sub process_file($) {
$state = 2;
if (/-(.*)/) {
- # strip leading/trailing/multiple spaces #RDD:T:
+ # strip leading/trailing/multiple spaces
$descr= $1;
$descr =~ s/^\s*//;
$descr =~ s/\s*$//;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On Tue, 22 May 2007, Matt Mackall wrote: > On Mon, May 21, 2007 at 08:03:49PM -0300, Henrique de Moraes Holschuh wrote: > > On Mon, 21 May 2007, Matt Mackall wrote: > > > BIOS Information > > > Vendor: IBM > > > Version: 1RETDHWW (3.13 ) > > > Release Date: 10/29/2004 > > > > > > No sign of any EC version in the output. > > > > This is a buggy, ancient version of the BIOS, which probably means you have > > an old and slightly buggy EC firmware. I recommend you to upgrade to BIOS > > 3.21 and EC 3.04. See http://thinkwiki.org/wiki/BIOS_Upgrade for more > > details. > > Really, I'd much prefer my kernel not regress instead. Updating > firmware is just introducing more potential instability and ignoring > the problem. We can't very much know if the kernel is really buggy, then. I'd say we need a report from someone with another thinkpad that uses the 1R BIOS that has an up-to-date BIOS, to know for sure. Since that includes the T41 and T42, chances are others would have spoken up about it already if it affected the more recent versions of the 1R BIOS. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: section mismatches
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote: > Andrew Morton wrote: > > WARNING: vmlinux(.text+0xc02fe884): Section mismatch: reference to > > .init.text: (between 'iret_exc' and '_etext') > > WARNING: vmlinux(.data+0xc0439099): Section mismatch: reference to > > .init.text:xen_start_kernel (between 'startup_xen' and 'boot_gdt_descr') > > > > This is safe, but I'll clean it up. I'll also have a look at iret_exc, > some of which might be Xen-related. Actually, iret_exc is in the fixup > section, but it gets used from several places, so it might be worth just > making it .text. I tracked down a bunch of these a little while back. It's not really iret_exc, but since there is no _sfixup/_efixup markers iret_exc is the closest symbol to pick on. All the [iret_exc, _etext] warnings I found were completely harmless from things that used, for example, mfn_to_pfn in an __init function (which sucks in a fixup via __get_user). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/32] Blackfin update for 2.6.22-rc2
On Mon, May 21, 2007 at 10:35:08AM -0400, Robin Getz wrote: > On Mon 21 May 2007 06:09, Bryan Wu pondered: > > Lots of update for 2.6.22-rc2 and tested on STAMP537 board. > > > > One of the things I noticed when trying out 2.6.22-rc1, on blackfin was: > > CALLscripts/checksyscalls.sh [snip syscalls] > > since there is noMMU, are we better: > - putting stubs (return ENOSYS - give runtime errors), or > - just ignore the errors - and give compile errors? (Is there any way to put > something into the syscall table, as not to get the warnings?) > No, you'd be better of figuring out which ones you can support and which ones you have to -ENOSYS. CONFIG_MMU=n is not a "get out of syscalls free" card. Many of these have no dependency on CONFIG_MMU, anyways. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] CFS scheduler, -v12
Dmitry Adamushko wrote: On 22/05/07, Peter Williams <[EMAIL PROTECTED]> wrote: > [...] > Hum.. I guess, a 0/4 scenario wouldn't fit well in this explanation.. No, and I haven't seen one. Well, I just took one of your calculated probabilities as something you have really observed - (*) below. "The probabilities for the 3 split possibilities for random allocation are: 2/2 (the desired outcome) is 3/8 likely, 1/3 is 4/8 likely, and 0/4 is 1/8 likely.<-- (*) " These are the theoretical probabilities for the outcomes based on the random allocation of 4 tasks to 2 CPUs. There are, in fact, 16 different ways that 4 tasks can be assigned to 2 CPUs. 6 of these result in a 2/2 split, 8 in a 1/3 split and 2 in a 0/4 split. The split that I see is 3/1 and neither CPU seems to be favoured with respect to getting the majority. However, top, gkrellm and X seem to be always on the CPU with the single spinner. The CPU% reported by top is approx. 33%, 33%, 33% and 100% for the spinners. Yes. That said, idle_balance() is out of work in this case. Which is why I reported the problem. If I renice the spinners to -10 (so that there load weights dominate the run queue load calculations) the problem goes away and the spinner to CPU allocation is 2/2 and top reports them all getting approx. 50% each. I wonder what would happen if X gets reniced to -10 instead (and spinners are at 0).. I guess, something I described in my previous mail (and dubbed "unlikely cospiracy" :) could happen, i.e. 0/4 and then idle_balance() comes into play.. Probably the same as I observed but it's easier to renice the spinners. I see the 0/4 split for brief moments if I renice the spinners to 10 instead of -10 but the idle balancer quickly restores it to 2/2. ok, I see. You have probably achieved a similar effect with the spinners being reniced to 10 (but here both "X" and "top" gain additional "weight" wrt the load balancing). I'm playing with some jitter experiments at the moment. The amount of jitter needs to be small (a few tenths of a second) as the synchronization (if it's happening) is happening at the seconds level as the intervals for top and gkrellm will be in the 1 to 5 second range (I guess -- I haven't checked) and the load balancing is every 60 seconds. Hum.. the "every 60 seconds" part puzzles me quite a bit. Looking at the run_rebalance_domain(), I'd say that it's normally overwritten by the following code if (time_after(next_balance, sd->last_balance + interval)) next_balance = sd->last_balance + interval; the "interval" seems to be *normally* shorter than "60*HZ" (according to the default params in topology.h).. moreover, in case of the CFS if (interval > HZ*NR_CPUS/10) interval = HZ*NR_CPUS/10; so it can't be > 0.2 HZ in your case (== once in 200 ms at max with HZ=1000).. am I missing something? TIA No, I did. But it's all academic as my synchronization theory is now dead -- see separate e-mail. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-rc2 prepatch breaks compile on Dreamcast
On Sat, May 19, 2007 at 01:07:00PM +0100, Adrian McMenamin wrote: > The patch includes: > > -#if OFFCHIP_NR_IRQS > 0 > -# define OFFCHIP_IRQ_BASE (ONCHIP_NR_IRQS + PINT_NR_IRQS) > -#endif > > > but the OFFCHIP_IRQ_BASE symbol is still referenced in the Dreamcast > code, so a compile generates this: > This will fix it, queued for -rc3: diff --git a/include/asm-sh/dreamcast/sysasic.h b/include/asm-sh/dreamcast/sysasic.h index 7874e3d..f334266 100644 --- a/include/asm-sh/dreamcast/sysasic.h +++ b/include/asm-sh/dreamcast/sysasic.h @@ -23,7 +23,7 @@ takes. */ -#define HW_EVENT_IRQ_BASE OFFCHIP_IRQ_BASE /* 48 */ +#define HW_EVENT_IRQ_BASE 48 /* IRQ 13 */ #define HW_EVENT_VSYNC (HW_EVENT_IRQ_BASE + 5) /* VSync */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sh updates for 2.6.22-rc3
Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git Which contains: Christoph Hellwig (1): sh: revert addition of page fault notifiers Kristoffer Ericson (1): input: hp680_ts compile fixes. Paul Mundt (12): sh: Shut up compiler warnings in __do_page_fault(). sh: Fix up psw build rules for r7780rp. sh: Kill off pmb slab cache destructor. sh: Wire up signalfd/timerfd/eventfd syscalls. sh: Fix up various compile warnings for SE boards. sh: Fix page size alignment in __copy_user_page(). sh: Disable psw support for R7785RP. fs: Kill sh dependency for binfmt_flat. sh: disable genrtc support. sh: sr.bl toggling around idle sleep. sh: Wire up kdump crash kernel exec in die(). sh: Fix dreamcast build for IRQ changes. Simon Arlott (1): spelling fixes: arch/sh/ dmitry pervushin (1): sh: Fix clock multiplier on SH7722. kogiidena (2): sh: landisk: rtc-rs5c313 support. sh: landisk: Header cleanups. arch/sh/boards/landisk/gio.c |2 +- arch/sh/boards/landisk/setup.c |6 ++ arch/sh/boards/renesas/r7780rp/Makefile|5 ++- arch/sh/boards/snapgear/rtc.c |2 +- arch/sh/boards/superh/microdev/io.c|6 +- arch/sh/boards/superh/microdev/irq.c |6 +- arch/sh/boards/superh/microdev/setup.c |2 +- arch/sh/boards/unknown/setup.c |2 +- arch/sh/drivers/dma/dma-api.c |2 +- arch/sh/drivers/dma/dma-isa.c |2 +- arch/sh/drivers/dma/dmabrg.c |2 +- arch/sh/drivers/pci/ops-dreamcast.c|2 +- arch/sh/drivers/pci/pci-st40.c |6 +- arch/sh/drivers/pci/pci-st40.h |2 +- arch/sh/drivers/superhyway/ops-sh4-202.c |2 +- arch/sh/kernel/cf-enabler.c|2 +- arch/sh/kernel/cpu/clock.c |7 +++ arch/sh/kernel/cpu/irq/maskreg.c |2 +- arch/sh/kernel/cpu/sh4/fpu.c |2 +- arch/sh/kernel/cpu/sh4/setup-sh7750.c |2 + arch/sh/kernel/cpu/sh4a/clock-sh7722.c | 34 arch/sh/kernel/kgdb_stub.c |4 +- arch/sh/kernel/process.c | 33 ++-- arch/sh/kernel/syscalls.S |3 + arch/sh/kernel/traps.c | 13 - arch/sh/math-emu/math.c|2 +- arch/sh/mm/copy_page.S |1 + arch/sh/mm/fault.c | 39 +- arch/sh/mm/init.c |3 +- arch/sh/mm/pmb.c | 79 +-- arch/sh/tools/mach-types |5 +- drivers/char/Kconfig |2 +- drivers/input/touchscreen/hp680_ts_input.c |7 +-- fs/Kconfig.binfmt |2 +- include/asm-sh/dreamcast/sysasic.h |2 +- include/asm-sh/kdebug.h|4 -- include/asm-sh/landisk/gio.h | 10 +--- include/asm-sh/landisk/iodata_landisk.h| 37 - include/asm-sh/unistd.h|5 ++- 39 files changed, 164 insertions(+), 185 deletions(-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata: implement ata_wait_after_reset()
On Sat, May 19, 2007 at 09:04:56PM +0200, Tejun Heo wrote: > Tejun Heo wrote: > > Yeah, if SCR registers are accessible, 0xff doesn't indicate the device > > isn't there, so the whole skip-0xff logic probably shouldn't apply in > > such cases, but we can also achieve pretty good result by just making > > the first reset tries a bit more aggressive. > > So, here's the patch. > > Paul, can you please test this patch without the previous patch? Indan, > this should reduce the resume delay. Please test. But you'll still > feel some added delay compared to 2.6.20 due to the mentioned > suspend/resume change. > Seems to work ok: [0.977254] scsi0 : sata_sil [0.980243] scsi1 : sata_sil [0.983207] ata1: SATA max UDMA/100 cmd 0xfd000280 ctl 0xfd00028a bmdma 0xfd000200 irq 0 [0.991183] ata2: SATA max UDMA/100 cmd 0xfd0002c0 ctl 0xfd0002ca bmdma 0xfd000208 irq 0 [2.578436] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [2.586828] ata1.00: ata_hpa_resize 1: sectors = 39070080, hpa_sectors = 39070080 [2.591596] ata1.00: ATA-5: HHD424020F7SV00, 00MLA0A5, max UDMA/100 [2.598094] ata1.00: 39070080 sectors, multi 0: LBA [2.603248] ata1.00: applying bridge limits [2.614710] ata1.00: ata_hpa_resize 1: sectors = 39070080, hpa_sectors = 39070080 [2.619489] ata1.00: configured for UDMA/100 [2.933096] ata2: SATA link down (SStatus 0 SControl 310) [2.936265] scsi 0:0:0:0: Direct-Access ATA HHD424020F7SV00 00ML PQ: 0 ANSI: 5 [2.945002] sd 0:0:0:0: [sda] 39070080 512-byte hardware sectors (20004 MB) [2.951473] sd 0:0:0:0: [sda] Write Protect is off - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] Wanted: Allow adding new device IDs during the -stable cycle
On Tue, May 22, 2007 at 06:56:40PM -0400, Dave Jones wrote: > On Tue, May 22, 2007 at 03:17:18PM -0700, Greg Kroah-Hartman wrote: > > > > > > I haven't found a single distro that (a) makes it trivial to add > PCI IDs at > > > > > install time, and then (b) ensures those PCI IDs remain persistent > for each > > > > > boot. We are not at all to the "just works" stage yet. > > > > > > > > Well, SuSE handles this just fine, but I do notice that RHEL 5 > disables > > > > the new_id stuff entirely, so I can see why you might get this > > > > impression :) > > > > > > That's news to me. I didn't even realise it was possible to disable > this. > > > Pointer? > > > > Jon Masters told me this last week at FreedomHEC, so I don't have a > > pointer to the patch that disables it, sorry. > > Either there's some miscommunication, or bonghits. > > (18:54:00:[EMAIL PROTECTED]:kernel-2.6.18)$ kdiff > vanilla/drivers/pci/pci-driver.c linux-2.6.18.noarch/drivers/pci/pci-driver.c > (18:54:10:[EMAIL PROTECTED]:kernel-2.6.18)$ > > And as there's no CONFIG option other than CONFIG_HOTPLUG (which we obviously > enable) > I don't see any reason why this wouldn't be enabled in RHEL5. > (And I think mdomsch would have probably had a fit if he found out we were > disabling it, but that's another story ;-) I thought so too, which is why I was so surprised when Jon said it. Jon, is this really true, or was it the symptom of the 3rd pot of coffee you were on that day? :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22-rc2
On Tue, 22 May 2007, Mike Houston wrote: > > In this case I actually had the kernel crash. First time for me ever > having a kernel oops! System locked up with keyboard LED's blinking. > > Not sure if anyone wants to see all of it (maybe some screwy > userland stuff involved), so I won't include that mess in the > message. It's here: > http://www.mikeserv.org/files/kernelcrash.txt I think you have major memory corruption. That first oops disassembles to mov0x10(%eax),%esi mov$0xfdfd,%eax test %esi,%esi je after_call mov%edx,%ecx mov%edi,%eax mov%ebx,%edx call *%esi after_call: which is (from net/ipv4/af_inet.c, inet_ioctl()): default: if (sk->sk_prot->ioctl) err = sk->sk_prot->ioctl(sk, cmd, arg); else err = -ENOIOCTLCMD; break; and the load off "sk->sk_prot->ioctl" oopses, because "sk->sk_prot" is corrupt and contains 0x8e3cad42, which is not a valid kernel pointer. The other oops is even worse. I also think it meshes with sky2 eth0: descriptor error q=0x280 get=285 [800042375e2e5e] put=285 and I suspect your memory got corrupted by sky2 reading the wrong descriptors, and overwriting kernel memory. So it's almost certainly some DMA problem. Now, _why_ you have DMA problems, I have no idea. But can you try: - disable CONFIG_PREEMPT - disable CONFIG_HIGHMEM if you have it on - just in general see if you can disable any kernel config options that might be unnecessary. to see if it changes the situation at all.. 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/
patch usb-hub.c-loops-forever-on-resume-from-ram-due-to-bluetooth.patch added to gregkh-2.6 tree
This is a note to let you know that I've just added the patch titled
Subject: USB: hub.c loops forever on resume from ram due to bluetooth
to my gregkh-2.6 tree. Its filename is
usb-hub.c-loops-forever-on-resume-from-ram-due-to-bluetooth.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
>From [EMAIL PROTECTED] Mon May 14 16:48:14 2007
From: Mark Lord <[EMAIL PROTECTED]>
Date: Mon, 14 May 2007 19:48:02 -0400
Subject: USB: hub.c loops forever on resume from ram due to bluetooth
To: Greg KH <[EMAIL PROTECTED]>
Cc: Linux Kernel , Andrew Morton <[EMAIL
PROTECTED]>, [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Okay, found it. The root cause here was a missing CONFIG_USB_SUSPEND=y,
which means the hci_usb device never got marked as USB_STATE_SUSPENDED,
which then caused the loop to go on forever.
The system works fine now with CONFIG_USB_SUSPEND=y in the .config.
Here's the patch to prevent future lockups for this or other causes.
I no longer need it, but it does still seem a good idea.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/core/hub.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -403,9 +403,10 @@ static void hub_tt_kevent (struct work_s
struct usb_hub *hub =
container_of(work, struct usb_hub, tt.kevent);
unsigned long flags;
+ int limit = 100;
spin_lock_irqsave (&hub->tt.lock, flags);
- while (!list_empty (&hub->tt.clear_list)) {
+ while (--limit && !list_empty (&hub->tt.clear_list)) {
struct list_head*temp;
struct usb_tt_clear *clear;
struct usb_device *hdev = hub->hdev;
Patches currently in gregkh-2.6 which might be from [EMAIL PROTECTED] are
usb/usb-hub.c-loops-forever-on-resume-from-ram-due-to-bluetooth.patch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -rt] ARM TLB flush fix: don't forget to re-enable preemption
On Tue, 2007-05-22 at 16:41 -0700, Kevin Hilman wrote: > > Individually, yes. But the point of the preempt_disable/enable is to > make the whole sequence atomic. I was under the impression that only one of those mcr lines is called per board type, the rest just compile away? 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: [xfs-masters] Re: 2.6.22-rc1-mm1
On Tue, 2007-05-22 at 20:44 +1000, David Chinner wrote: > > > xfs_buf_associate_memory is a mess. My original plan was to get rid > of > > it, but I kept that out to keep that patchset small and easily > reviable, > > but it seems like that was a mistake. My plan is the following: > > > > - xlog_bread and thus the whole buffer I/O path grows an iooffset > >paramater that specifies at which offset into the buffer we start > >the actual I/O. That gets rid of all the > xfs_buf_associate_memory > >memory uses in the log recovery code > > Perhaps a new field in the xfs_buf structure - that way call paths > don't need to grow extra parameters and potentially increase Thatd be unfortunate - there are very few iclog buffers relative to every other metadata buffer, so growing the struct for all of those too would not be ideal (I remember Steve going on pagebuf shrinking exercises in the distant past, to fit more of em in memory at once, I can't remember what benchmark in particular he was using though). cheers. -- Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 -rt] Resolve -rt OMAP conflicts
This patch removes all the OMAP clocksource/clockevent stuff from the
-rt patch since it is now all in the OMAP tree.
It also removes the few raw_spinlock additions to OMAP specific files
which will be revisited/resumitted if necessary. I currently believe
that all of these raw spinlocks are no longer necessary.
Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
--- linux/arch/arm/Kconfig
+++ linux.orig/arch/arm/Kconfig
@@ -363,7 +363,6 @@
config ARCH_OMAP
bool "TI OMAP"
select GENERIC_GPIO
- select GENERIC_TIME
help
Support for TI's OMAP platform (OMAP1 and OMAP2).
reverted:
--- linux/arch/arm/mach-omap1/pm.c
+++ linux.orig/arch/arm/mach-omap1/pm.c
@@ -120,7 +120,7 @@
local_irq_disable();
local_fiq_disable();
+ if (need_resched()) {
- if (need_resched() || need_resched_delayed()) {
local_fiq_enable();
local_irq_enable();
return;
reverted:
--- linux/arch/arm/mach-omap1/time.c
+++ linux.orig/arch/arm/mach-omap1/time.c
@@ -39,10 +39,6 @@
#include
#include
#include
-#include
-#include
-#include
-#include
#include
#include
@@ -52,7 +48,13 @@
#include
#include
+struct sys_timer omap_timer;
+/*
+ * ---
+ * MPU timer
+ * ---
+ */
#define OMAP_MPU_TIMER_BASEOMAP_MPU_TIMER1_BASE
#define OMAP_MPU_TIMER_OFFSET 0x100
@@ -86,6 +88,21 @@
return (cyc * cyc2ns_scale) >> CYC2NS_SCALE_FACTOR;
}
+/*
+ * MPU_TICKS_PER_SEC must be an even number, otherwise machinecycles_to_usecs
+ * will break. On P2, the timer count rate is 6.5 MHz after programming PTV
+ * with 0. This divides the 13MHz input by 2, and is undocumented.
+ */
+#if defined(CONFIG_MACH_OMAP_PERSEUS2) || defined(CONFIG_MACH_OMAP_FSAMPLE)
+/* REVISIT: This ifdef construct should be replaced by a query to clock
+ * framework to see if timer base frequency is 12.0, 13.0 or 19.2 MHz.
+ */
+#define MPU_TICKS_PER_SEC (1300 / 2)
+#else
+#define MPU_TICKS_PER_SEC (1200 / 2)
+#endif
+
+#define MPU_TIMER_TICK_PERIOD ((MPU_TICKS_PER_SEC / HZ) - 1)
typedef struct {
u32 cntl; /* CNTL_TIMER, R/W */
@@ -103,164 +120,98 @@
return timer->read_tim;
}
+static inline void omap_mpu_timer_start(int nr, unsigned long load_val)
-static inline void omap_mpu_set_autoreset(int nr)
-{
- volatile omap_mpu_timer_regs_t* timer = omap_mpu_timer_base(nr);
-
- timer->cntl = timer->cntl | MPU_TIMER_AR;
-}
-
-static inline void omap_mpu_remove_autoreset(int nr)
-{
- volatile omap_mpu_timer_regs_t* timer = omap_mpu_timer_base(nr);
-
- timer->cntl = timer->cntl & ~MPU_TIMER_AR;
-}
-
-static inline void omap_mpu_timer_start(int nr, unsigned long load_val,
- int autoreset)
{
volatile omap_mpu_timer_regs_t* timer = omap_mpu_timer_base(nr);
- unsigned int timerflags = (MPU_TIMER_CLOCK_ENABLE | MPU_TIMER_ST);
-
- if (autoreset) timerflags |= MPU_TIMER_AR;
timer->cntl = MPU_TIMER_CLOCK_ENABLE;
udelay(1);
timer->load_tim = load_val;
udelay(1);
+ timer->cntl = (MPU_TIMER_CLOCK_ENABLE | MPU_TIMER_AR | MPU_TIMER_ST);
- timer->cntl = timerflags;
-}
-
-/*
- * ---
- * MPU timer 1 ... count down to zero, interrupt, reload
- * ---
- */
-static int omap_mpu_set_next_event(unsigned long cycles,
- struct clock_event_device *evt)
-{
- omap_mpu_timer_start(0, cycles, 0);
- return 0;
}
+unsigned long omap_mpu_timer_ticks_to_usecs(unsigned long nr_ticks)
-static void omap_mpu_set_mode(enum clock_event_mode mode,
- struct clock_event_device *evt)
-{
- switch (mode) {
- case CLOCK_EVT_MODE_PERIODIC:
- omap_mpu_set_autoreset(0);
- break;
- case CLOCK_EVT_MODE_ONESHOT:
- omap_mpu_remove_autoreset(0);
- break;
- case CLOCK_EVT_MODE_UNUSED:
- case CLOCK_EVT_MODE_SHUTDOWN:
- break;
- }
-}
-
-static struct clock_event_device clockevent_mpu_timer1 = {
- .name = "mpu_timer1",
- .features = CLOCK_EVT_FEAT_PERIODIC, CLOCK_EVT_FEAT_ONESHOT,
- .shift = 32,
- .set_next_event = omap_mpu_set_next_event,
- .set_mode = omap_mpu_set_mode,
-};
-
-static irqreturn_t omap_mpu_timer1_interrupt(int irq, void *dev_id)
{
+ unsigned long long nsec;
- struct clock_event_device *evt = &clockevent_mpu_timer1;
-
- evt->event_handler(evt);
+ nsec = cycles_2_ns((unsigned long long)nr_ticks);
+ return (unsigned
[PATCH] 2.6.21-rt6 genapic
Add declaration for setup_apic_routing
This duplicates the declaration from i386 to x86_64 in the header.
The code, in genapic.c is shared between i386/x86_64.
Steven was trying to clean up that mess a while back, and this adds to
it.
In any case this gets compiling with
-Werror-implicit-function-declaration
Sven
Index: linux-2.6.21/arch/i386/kernel/acpi/boot.c
===
--- linux-2.6.21.orig/arch/i386/kernel/acpi/boot.c
+++ linux-2.6.21/arch/i386/kernel/acpi/boot.c
@@ -35,6 +35,7 @@
#include
#include
+#include
#include
#include
#include
Index: linux-2.6.21/arch/x86_64/kernel/mpparse.c
===
--- linux-2.6.21.orig/arch/x86_64/kernel/mpparse.c
+++ linux-2.6.21/arch/x86_64/kernel/mpparse.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
/* Have we found an MP table */
int smp_found_config;
Index: linux-2.6.21/include/asm-x86_64/genapic.h
===
--- linux-2.6.21.orig/include/asm-x86_64/genapic.h
+++ linux-2.6.21/include/asm-x86_64/genapic.h
@@ -29,6 +29,7 @@ struct genapic {
unsigned int (*phys_pkg_id)(int index_msb);
};
+void setup_apic_routing(void);
extern struct genapic *genapic;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.6.21-rt6
On Tue, 2007-05-22 at 15:59 -0700, Sven-Thorsten Dietrich wrote:
> Add
> header and export for rt_write_trylock_irqsave.
Disregard the last patch, flags parameter was missing in the header.
Index: linux-2.6.21/include/linux/spinlock.h
===
--- linux-2.6.21.orig/include/linux/spinlock.h
+++ linux-2.6.21/include/linux/spinlock.h
@@ -294,6 +294,8 @@ do {
\
extern void __lockfunc rt_write_lock(rwlock_t *rwlock);
extern void __lockfunc rt_read_lock(rwlock_t *rwlock);
extern int __lockfunc rt_write_trylock(rwlock_t *rwlock);
+extern int __lockfunc rt_write_trylock_irqsave(rwlock_t *trylock,
+ unsigned long *flags);
extern int __lockfunc rt_read_trylock(rwlock_t *rwlock);
extern void __lockfunc rt_write_unlock(rwlock_t *rwlock);
extern void __lockfunc rt_read_unlock(rwlock_t *rwlock);
Index: linux-2.6.21/kernel/rt.c
===
--- linux-2.6.21.orig/kernel/rt.c
+++ linux-2.6.21/kernel/rt.c
@@ -178,6 +178,7 @@ int __lockfunc rt_write_trylock_irqsave(
*flags = 0;
return rt_write_trylock(rwlock);
}
+EXPORT_SYMBOL(rt_write_trylock_irqsave);
int __lockfunc rt_read_trylock(rwlock_t *rwlock)
{
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 -rt] ARM TLB flush fix: don't forget to re-enable preemption
On Tue, 2007-05-22 at 16:25 -0700, Daniel Walker wrote:
> On Tue, 2007-05-22 at 16:01 -0700, Kevin Hilman wrote:
> > Add a preempt_enable() to flush_tlb_kernel_page() since -rt4 patch
> > adds a preempt_disable but no preempt_enable().
> >
> > Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
> >
> >
> > ---
> > include/asm-arm/tlbflush.h |1 +
> > 1 file changed, 1 insertion(+)
> >
> > Index: linux-2.6.21/include/asm-arm/tlbflush.h
> > ===
> > --- linux-2.6.21.orig/include/asm-arm/tlbflush.h
> > +++ linux-2.6.21/include/asm-arm/tlbflush.h
> > @@ -378,6 +378,7 @@ static inline void local_flush_tlb_kerne
> > asm("mcr p15, 0, %0, c8, c6, 1" : : "r" (kaddr) : "cc");
> > if (tlb_flag(TLB_V6_I_PAGE))
> > asm("mcr p15, 0, %0, c8, c5, 1" : : "r" (kaddr) : "cc");
>
> Aren't these mcr operations atomic?
>
Individually, yes. But the point of the preempt_disable/enable is to
make the whole sequence atomic.
Kevin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] enhancing the kernel's graphics subsystem
On Tuesday, May 22, 2007, Benjamin Herrenschmidt wrote: > On Tue, 2007-05-22 at 08:39 -0700, Jesse Barnes wrote: > > The current code does its best to figure out what modes are available > > and tries to pick a good one for each display. It sounds like you're > > mainly concerned with the actual mode picking, not the mode and output > > detection and enumeration? If so, that's a pretty easy change to > > make. But if you're also worried about the kernel building mode > > lists, then we'll have bigger changes to make... > > I'm worried that the EDID we get from the monitor is bogus and needs to > be overriden. > > Now, if the kernel builds a mode list, that's find if we have a call to > "feed" it with a replacement one later on from userland. > > In addition, there are all those monitors that cannot be probed (no > DDC/EDID) and for which only userland can reasonably provide a mode or a > mode list. Yeah, we already have a call to add modes to the kernel's list, so we should be covered. > So it's a bit of both :-) Building an "initial" mode list from the EDID > might be fair enough if we can replace it soon enough, but we still need > to be very conservative about whatever boot mode we choose. Right. > > I'm not really sure how much of a problem broken EDIDs will be. The X > > server only has a few quirks for broken EDIDs now, nothing major > > afaict, and apparently the FB layer already has some code for handling > > EDID quirks, so I don't think that'll be our biggest problem. So far, > > it looks like handling laptop panels is a bit trickier (at least for > > Intel chips)... > > Well, I've seen my share of broken EDID.. Last time I looked at Darwin, > I think I saw Apple maintaining a fairly huge database of EDID > replacements in userland... Interesting... I wonder how the distro monitor databases compare. Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI device problem - MMCONFIG, cannot allocate resource region, resource collisions
On Tuesday, May 22, 2007, Wayne Sherman wrote:
> So these devices are already occupying the space that the D-Link wants:
>
> 00:01.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge
> 01:05.0 VGA compatible controller: ATI Technologies Inc RS482 [Radeon
> Xpress 200]
>
> But, the D-Link NIC is behind the bridge at
> ff50-ff5f : PCI Bus #02
>
> Is a PCI device behind a bridge supposed to be mapped into memory that
> its bridge encompasses?
Yes.
> If so, the D-Link is not being mapped into the
> right region, and the bridge it is behind does not have enough memory
> assigned to it (ff50-ff5f : PCI Bus #02).
Sounds familiar. There are lots of cases where bridge windows aren't
allocated properly so devices behind them are invisible or can't work.
Check out the attached patch from Ivan, if you
pass 'pci=assign-bus-resources' to your kernel at boot time, the code will
try to reallocate bridge space for you if needed.
Jesse
From [EMAIL PROTECTED] Tue May 15 15:39:53 2007
Received: from virtuous by box128.bluehost.com with local-bsmtp (Exim 4.63)
(envelope-from <[EMAIL PROTECTED]>)
id 1Ho5gr-0001rh-22
for [EMAIL PROTECTED]; Tue, 15 May 2007 16:40:21 -0600
X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on box128.bluehost.com
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=no
version=3.2.0
Received: from vger.kernel.org ([209.132.176.167])
by box128.bluehost.com with esmtp (Exim 4.63)
(envelope-from <[EMAIL PROTECTED]>)
id 1Ho5gq-0001rT-HJ
for [EMAIL PROTECTED]; Tue, 15 May 2007 16:40:20 -0600
Received: ([EMAIL PROTECTED]) by vger.kernel.org via listexpand
id S1759714AbXEOWja (ORCPT );
Tue, 15 May 2007 18:39:30 -0400
Received: ([EMAIL PROTECTED]) by vger.kernel.org id S1756955AbXEOWjU
(ORCPT );
Tue, 15 May 2007 18:39:20 -0400
Received: from jurassic.park.msu.ru ([195.208.223.243]:4396 "EHLO
jurassic.park.msu.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S1756838AbXEOWjT (ORCPT
);
Tue, 15 May 2007 18:39:19 -0400
Received: by jurassic.park.msu.ru (Postfix, from userid 500)
id 424A411E9A1; Wed, 16 May 2007 02:39:53 +0400 (MSD)
Date: Wed, 16 May 2007 02:39:53 +0400
From: Ivan Kokshaysky <[EMAIL PROTECTED]>
To: Jesse Barnes <[EMAIL PROTECTED]>
Cc: Linus Torvalds <[EMAIL PROTECTED]>,
Greg KH <[EMAIL PROTECTED]>,
Adam Jackson <[EMAIL PROTECTED]>,
linux-kernel@vger.kernel.org
Subject: Re: PCI bridge range sizing bug
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain;
charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Mon, May 14, 2007 at 10:45:43AM -0700
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
X-Length: 8940
X-UID: 118711
On Mon, May 14, 2007 at 10:45:43AM -0700, Jesse Barnes wrote:
> Any update on this, Ivan? Maybe I missed your post, but I haven't seen
> anything yet...
No, I didn't post anything, sorry. This turned out to be not as trivial
as I thought - I've played with that code on amd64, and results were rather
discouraging. For example, I forced reassignment of video card resources
and initially this failed because of the way how pci/setup-* allocates ROM
addresses: ROMs are obviously prefetchable, so we're always trying to put
them in prefetchable windows of the bridge. Technically, this is correct,
but leads to the waste of PCI address space due to size/alignment
requirements, especially when ROM is assigned to the same window as
a prefetchable framebuffer resource (typically 64-256M).
On the other hand, we could allocate ROMs in non-prefetch ranges just
for free, as minimal memory window of the bridges is 1M and both MMIO
register blocks and ROMs are usually much smaller.
Probably we need some global variable to control this (and some other things)
in pci/setup-*, just like pci_probe on i386...
Another funny thing found on x86_64 - if we ran out of PCI address space
below 4G, resources get happily assigned above 4G, even if respective BARs
are 32-bit.
Anyway, here's what I have so far, though I doubt that it's a breakthrough
for Adam...
Ivan.
--- orig/arch/i386/pci/common.c Sat Apr 21 21:55:30 2007
+++ linux/arch/i386/pci/common.c Sat Apr 21 21:55:33 2007
@@ -290,6 +290,12 @@ static struct dmi_system_id __devinitdat
{}
};
+static struct resource pci_mem32 = {
+ .name = "PCI 32-bit memory space",
+ .end = 0x,
+ .flags = IORESOURCE_MEM,
+};
+
struct pci_bus * __devinit pcibios_scan_root(int busnum)
{
struct pci_bus *bus = NULL;
@@ -305,7 +311,13 @@ struct pci_bus * __devinit pcibios_scan_
printk(KERN_DEBUG "PCI: Probing PCI hardware (bus %02x)\n", busnum);
- return pci_scan_bus_parented(NULL, busnum, &pci_root_ops, NULL);
+ bus = pci_scan_bus_parented(NULL, busnum, &pci_root_ops, NULL);
+ if (bus && bus->resource[1] == &iomem_resource) {
+ pci_mem32.sta
Re: [RFC PATCH] file as directory
Miklos Szeredi wrote: Why do we want this? That depends on who you ask. My answer is this: 'foo.tar.gz/foo/bar' or 'foo.tar.gz/contents/foo/bar' or something similar. Others might suggest accessing streams, resource forks or extended attributes through such an interface. However this patch only deals with the non-directory case, so directories would be excluded from that interface. here's a possibly stupid question. What about symlinks to dirs? namely the shells tend to treat them differently if postfixed with a slash or not. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lguest broken in 2.6.22-rc1-mm1
On Tue, 2007-05-22 at 17:38 -0500, Matt Mackall wrote:
> [0.120007] EIP is at resync_sc_freq+0x4b/0x56
Hi Matt,
Thanks for the report! Andrew should have these two patches queued,
but here they are again:
If you set tsc_disable (eg "notsc" on cmdline), sched-clock.c gives a
divide by zero on boot.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
arch/i386/kernel/sched-clock.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
===
--- a/arch/i386/kernel/sched-clock.c
+++ b/arch/i386/kernel/sched-clock.c
@@ -103,7 +103,7 @@ static void resync_sc_freq(struct sc_dat
static void resync_sc_freq(struct sc_data *sc, unsigned int newfreq)
{
sc->sync_base = jiffies;
- if (!cpu_has_tsc) {
+ if (!cpu_has_tsc || tsc_disable) {
sc->unstable = 1;
return;
}
Lguest guests don't use the TSC, and so we must disable it otherwise
sched-clock.c barfs.
Also, we no longer need to explicitly set the PGE feature bit:
cpu_detect->cpuid->lguest_cpuid does that for us now that cpu_detect
uses paravirt_ops (IIRC it used to do a direct cpuid from assembler).
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/lguest/lguest.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
===
--- a/drivers/lguest/lguest.c
+++ b/drivers/lguest/lguest.c
@@ -504,10 +504,10 @@ __init void lguest_init(void *boot)
reserve_top_address(lguest_data.reserve_mem);
cpu_detect(&new_cpu_data);
- /* Need this before paging_init. */
- set_bit(X86_FEATURE_PGE, new_cpu_data.x86_capability);
/* Math is always hard! */
new_cpu_data.hard_math = 1;
+
+ tsc_disable = 1;
#ifdef CONFIG_X86_MCE
mce_disabled = 1;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] enhancing the kernel's graphics subsystem
On Tue, 2007-05-22 at 08:39 -0700, Jesse Barnes wrote: > > The current code does its best to figure out what modes are available and > tries to pick a good one for each display. It sounds like you're mainly > concerned with the actual mode picking, not the mode and output detection > and enumeration? If so, that's a pretty easy change to make. But if > you're also worried about the kernel building mode lists, then we'll have > bigger changes to make... I'm worried that the EDID we get from the monitor is bogus and needs to be overriden. Now, if the kernel builds a mode list, that's find if we have a call to "feed" it with a replacement one later on from userland. In addition, there are all those monitors that cannot be probed (no DDC/EDID) and for which only userland can reasonably provide a mode or a mode list. So it's a bit of both :-) Building an "initial" mode list from the EDID might be fair enough if we can replace it soon enough, but we still need to be very conservative about whatever boot mode we choose. > I'm not really sure how much of a problem broken EDIDs will be. The X > server only has a few quirks for broken EDIDs now, nothing major afaict, > and apparently the FB layer already has some code for handling EDID > quirks, so I don't think that'll be our biggest problem. So far, it looks > like handling laptop panels is a bit trickier (at least for Intel > chips)... Well, I've seen my share of broken EDID.. Last time I looked at Darwin, I think I saw Apple maintaining a fairly huge database of EDID replacements in userland... Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -rt] ARM TLB flush fix: don't forget to re-enable preemption
On Tue, 2007-05-22 at 16:01 -0700, Kevin Hilman wrote:
> Add a preempt_enable() to flush_tlb_kernel_page() since -rt4 patch
> adds a preempt_disable but no preempt_enable().
>
> Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
>
>
> ---
> include/asm-arm/tlbflush.h |1 +
> 1 file changed, 1 insertion(+)
>
> Index: linux-2.6.21/include/asm-arm/tlbflush.h
> ===
> --- linux-2.6.21.orig/include/asm-arm/tlbflush.h
> +++ linux-2.6.21/include/asm-arm/tlbflush.h
> @@ -378,6 +378,7 @@ static inline void local_flush_tlb_kerne
> asm("mcr p15, 0, %0, c8, c6, 1" : : "r" (kaddr) : "cc");
> if (tlb_flag(TLB_V6_I_PAGE))
> asm("mcr p15, 0, %0, c8, c5, 1" : : "r" (kaddr) : "cc");
Aren't these mcr operations atomic?
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/
[PATCH -rt] ARM TLB flush fix: don't forget to re-enable preemption
Add a preempt_enable() to flush_tlb_kernel_page() since -rt4 patch
adds a preempt_disable but no preempt_enable().
Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
---
include/asm-arm/tlbflush.h |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.21/include/asm-arm/tlbflush.h
===
--- linux-2.6.21.orig/include/asm-arm/tlbflush.h
+++ linux-2.6.21/include/asm-arm/tlbflush.h
@@ -378,6 +378,7 @@ static inline void local_flush_tlb_kerne
asm("mcr p15, 0, %0, c8, c6, 1" : : "r" (kaddr) : "cc");
if (tlb_flag(TLB_V6_I_PAGE))
asm("mcr p15, 0, %0, c8, c5, 1" : : "r" (kaddr) : "cc");
+ preempt_enable();
if (tlb_flag(TLB_V6_I_FULL | TLB_V6_D_FULL |
TLB_V6_I_PAGE | TLB_V6_D_PAGE |
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PCI device problem - MMCONFIG, cannot allocate resource region, resource collisions
Jesse Barnes wrote: Can you dump the memory BAR for this device? I guess lspci hides it by default. You may also be able to see it using 'od -t x4 /sys/devices/pci\:00/:02:02.0/config'. The D-Link NIC is sitting behind this bridge: "00:14.4 PCI bridge: ATI Technologies Inc SB600 PCI to PCI Bridge" These are the devices behind the bridge: :02:00.0 - FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev c0) :02:02.0 - D-Link NIC :02:06.0 - Ethernet controller: Realtek Semiconductor Co., Ltd. Unknown device 8167 (rev 10) Here is the D-LINK NIC: # od -t x4 /sys/devices/pci:00/:00:14.4/:02:02.0/config 000 49011186 80b00117 0011 4010 020 fd5f8000 b801 040 49011186 060 fd5c 0048 1d17010b 100 05f0 01a08000 fc025001 11002000 120 8003 0100 0104 140 # cat /sys/devices/pci:00/:00:14.4/:02:02.0/resource 0x 0x3fff 0x0200 0xb800 0xb8ff 0x0101 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x0001 0x7200 In that same folder, "resource0" is 16384 bytes long and "resource1" is 256 bytes. I assume my error "Cannot allocate resource region 0" refers to the first base address register (config space offset 0x10). That value indicates it is supposed to be memory mapped at address 0xfd5f8000. I am guessing here, but does the length of "resource0" represent how long this region is supposed to be (16384 bytes)? Now looking at the system memory map: # cat /proc/iomem -00097fff : System RAM 00098000-0009 : reserved 000a-000b : Video RAM area 000c-000cefff : Video ROM 000cf000-000c : Adapter ROM 000f-000f : System ROM 0010-3dfb : System RAM 0010-003dd103 : Kernel code 003dd104-004de0ff : Kernel data 3dfc-3dfcdfff : ACPI Tables 3dfce000-3dff : ACPI Non-volatile Storage 4000-400f : PCI Bus #02 4000-4001 : :02:06.0 fab0-feaf : PCI Bus #01 <<< offending memory region fc00-fdff : :01:05.0 <<< offending memory region fed0-fed003ff : HPET 2 ff40-ff4f : PCI Bus #01 ff4c-ff4d : :01:05.0 ff4f-ff4f : :01:05.0 ff50-ff5f : PCI Bus #02 ff5ff400-ff5ff4ff : :02:06.0 ff5ff400-ff5ff4ff : r8169 ff5ff800-ff5f : :02:00.0 ff5ff800-ff5f : ohci1394 ff6fa000-ff6fafff : :00:13.4 ff6fa000-ff6fafff : ohci_hcd ff6fb000-ff6fbfff : :00:13.3 ff6fb000-ff6fbfff : ohci_hcd ff6fc000-ff6fcfff : :00:13.2 ff6fc000-ff6fcfff : ohci_hcd ff6fd000-ff6fdfff : :00:13.1 ff6fd000-ff6fdfff : ohci_hcd ff6fe000-ff6fefff : :00:13.0 ff6fe000-ff6fefff : ohci_hcd ff6ff800-ff6ff8ff : :00:13.5 ff6ff800-ff6ff8ff : ehci_hcd ff6ffc00-ff6f : :00:12.0 ff6ffc00-ff6f : ahci ff78- : reserved So these devices are already occupying the space that the D-Link wants: 00:01.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge 01:05.0 VGA compatible controller: ATI Technologies Inc RS482 [Radeon Xpress 200] But, the D-Link NIC is behind the bridge at ff50-ff5f : PCI Bus #02 Is a PCI device behind a bridge supposed to be mapped into memory that its bridge encompasses? If so, the D-Link is not being mapped into the right region, and the bridge it is behind does not have enough memory assigned to it (ff50-ff5f : PCI Bus #02). Thanks, Wayne - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RESEND] PIE randomization
On Thu, 17 May 2007 22:24:11 +0200 (CEST) Jan Kratochvil <[EMAIL PROTECTED]> wrote: > This patch is using mmap()'s randomization functionality in such a way > that it maps the main executable of (specially compiled/linked -pie/-fpie) > ET_DYN binaries onto a random address (in cases in which mmap() is allowed > to perform a randomization). ia64: arch/ia64/ia32/binfmt_elf32.c:265: error: conflicting types for 'elf32_map' arch/ia64/ia32/../../../fs/binfmt_elf.c:48: error: previous declaration of 'elf32_map' was here arch/ia64/ia32/binfmt_elf32.c:265: error: conflicting types for 'elf32_map' arch/ia64/ia32/../../../fs/binfmt_elf.c:48: error: previous declaration of 'elf32_map' was here arch/ia64/ia32/../../../fs/binfmt_elf.c:48: warning: 'elf32_map' declared `static' but never defined arch/ia64/ia32/binfmt_elf32.c:265: warning: 'elf32_map' defined but not used - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [PATCH] - fix oops in sysfs_readdir
On Mon, May 21, 2007 at 01:11:21PM -0500, Eric Sandeen wrote: > This is a non-ida backport of Tejun's patch in -mm at: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc1/2.6.22-rc1-mm1/broken-out/gregkh-driver-sysfs-allocate-inode-number-using-ida.patch > for the 2.6.16 -stable tree - it follows the same scheme of using s_ino to > safely > store & retrieve the inode number of sysfs entries for use in sysfs_readdir, > but uses a brain-dead-simple inode nr allocator rather than ida, which would > bring along a lot of newer, more complex code. > > No, this doesn't guarantee uniqueness of sysfs inode numbers, but then > the code in -stable today doesn't either - and with this change, at least > it shouldn't oops. > > Comments? First of all, thanks for any contributions to 2.6.16. My biggest problem with this patch is: It's not yet fixed in Linus' tree - and if it isn't important enough for being fixed in 2.6.22, it can't be important enough for 2.6.16. And no matter whether this might include adding ida to 2.6.16, I'd prefer to apply something as near as possible to whatever gets into 2.6.22. > Thanks, > > -Eric >... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: section mismatches
Andrew Morton wrote: > WARNING: vmlinux(.text+0xc02fe884): Section mismatch: reference to > .init.text: (between 'iret_exc' and '_etext') > WARNING: vmlinux(.data+0xc0439099): Section mismatch: reference to > .init.text:xen_start_kernel (between 'startup_xen' and 'boot_gdt_descr') > This is safe, but I'll clean it up. I'll also have a look at iret_exc, some of which might be Xen-related. Actually, iret_exc is in the fixup section, but it gets used from several places, so it might be worth just making it .text. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
