Re: linux 2.6.19 still crashing
Sergio Monteiro Basto wrote:
Hi,
1st you should put this information on http://bugzilla.kernel.org/
ok, thanks.
your bug kept me the attention because on bad interrupts you have :
21: 10 IO-APIC-fasteoi ohci1394
Exactly oops on 10 interrupts, I had seen this before .
I have my bug on http://bugzilla.kernel.org/show_bug.cgi?id=6419
which one of the bugs looks like similar to yours.
So, You are saying with kernel 2.6.16.31 with xen 3.0.2, you don't have
this problem , I like to try it, how or where you build this Xenified
kernel ?
The package source were available at , but they no longer are :(
http://debian.thoughtcrime.co.nz/ubuntu/
I can send you my copies (either parts or all), if you don't mind
getting big emails
-rw-r--r-- 1 aj aj 342068 2006-04-19 12:14 libxen3.0_3.0.2-2r7_amd64.deb
-rw-r--r-- 1 aj aj 106440 2006-04-19 12:14 libxen-dev_3.0.2-2r7_amd64.deb
-rw-r--r-- 1 aj aj 155186 2006-04-19 12:14
libxen-python_3.0.2-2r7_amd64.deb
-rw-r--r-- 1 aj aj 620946 2006-04-19 12:14
linux-patch-xen_3.0.2-2r7_amd64.deb
drwxr-xr-x 10 aj aj4096 2006-04-19 12:14 xen-3.0.2
-rw-r--r-- 1 aj aj 12926 2006-04-19 12:14 xen_3.0.2-2r7_amd64.deb
-rw-r--r-- 1 aj aj 656745 2006-04-19 12:12 xen_3.0.2-2r7.diff.gz
-rw-r--r-- 1 aj aj 645 2006-04-19 12:12 xen_3.0.2-2r7.dsc
-rw-r--r-- 1 aj aj 0 2006-04-19 12:14 xen_3.0.2-2r7.dsc.asc
-rw-r--r-- 1 aj aj 4933621 2006-04-19 11:36 xen_3.0.2.orig.tar.gz
-rw-r--r-- 1 aj aj 531232 2006-04-19 12:14 xen-docs_3.0.2-2r7_all.deb
-rw-r--r-- 1 aj aj 1479866 2006-04-19 12:14
xen-hypervisor-3.0_3.0.2-2r7_amd64.deb
-rw-r--r-- 1 aj aj 180526 2006-04-19 12:14
xen-utils-3.0_3.0.2-2r7_amd64.deb
only *dsc *diff.gz and *orig.tar.gz are needed, then you can recompile
the rest yourself ("dpkg-source -x *dsc; cd xen-*/; dpkg-buildpackage
-rfakeroot").
or I can send you the kernel patch as file and the xen hypervisor:
-rw-r--r-- 1 root root 244694 2006-04-19 12:14 /boot/xen-3.0.2-2.gz
-rw-r--r-- 1 root root 604942 2006-04-19 12:14
/usr/src/kernel-patches/diffs/xen/linux-2.6.16-xen.patch.gz
it applies clean against 2.6.16, but if with 2.6.16.31 I had
to manually fix two rejects.
Regards, Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: la la la la ... swappiness
On Dec 03, 2006, at 20:54:41, Aucoin wrote: As a side note, even now, *hours* after the tar has completed and even though I have swappiness set to 0, cache pressure set to , all dirty timeouts set to 1 and all dirty ratios set to 1, I still have a 360+K inactive page count and my "free" memory is less than 10% of normal. The point you're missing is that an "inactive" page is a free page that happens to have known clean data on it corresponding to something on disk. If you need to use the inactive page for something all you have to do is either zero it or fill it with data from elsewhere. There is _no_ practical reason for the kernel to turn an "inactive" page into a "free" page. On my Linux systems after heavy local-disk and network intensive read-only load I have no more than 2% "free" memory, most of the rest is "inactive" (in one case some 2GB of it). There's nothing _wrong_ with that much "inactive" memory, it just means that you were using it for data at one point, then didn't need it anymore and haven't reused it since. I'm not pretending to understand what's happening here but shouldn't some kind of expiration have kicked in by now and freed up all those inactive pages? Nope; the pages will continue to contain valid data until you overwrite them with new data somehow. Now, if they were "dirty" pages, containing unwritten data, then you would be correct. The *instant* I manually push a "3" into drop_caches I have 100% of my normal free memory and the inactive page count drops below 2K. Maybe I completely misunderstood the purpose of all those dials but I really did get the feeling that twisting them all tight would make the housekeeping algorithms more aggressive. In this case you're telling the kernel to go beyond its normal housekeeping and delete perfectly good data from memory. The only reason to do that is usually to make benchmarks mildly more repeatable and doing it on a regular basis tends to kill performance. Cheers, Kyle Moffett [copy of long previous email snipped] PS: No need to put a copy of the entire message you are replying to at the end of your post, it just chews up space. If anything please quote inline immediately before the appropriate portion of your reply so we can get the gist, much as I have done above. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] mmc: fix au1xmmc build error
Yoichi Yuasa wrote: > Hi, > > This patch has fixed the following build error abou au1xmmc. > Thanks. Applied. -- -- 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: [RFC: 2.6 patch] MAINTAINERS remove the v850 entry
Adrian Bunk <[EMAIL PROTECTED]> writes: > One bouncing email address and two non-existing URLs - we need either > updated information or this patch applied... I don't know the status of that email address/website (the NEC network has moved around a lot recently), but I'm reachable the address you apparently already found: [EMAIL PROTECTED] That will do for now. -Miles -- .Numeric stability is probably not all that important when you're guessing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 in sysfs between sysfs_remove_file() and read()/write() #2
Am Montag, 4. Dezember 2006 05:43 schrieb Maneesh Soni:
> On Fri, Dec 01, 2006 at 11:43:06PM +0100, Oliver Neukum wrote:
> > Hi,
> >
> > Alan Stern has discovered a race in sysfs, whereby driver callbacks could be
> > called after sysfs_remove_file() has run. The attached patch should fix it.
> >
> > It introduces a new data structure acting as a collection of all
> > sysfs_buffers
> > associated with an attribute. Upon removal of an attribute the buffers are
> > marked orphaned and IO on them returns -ENODEV. Thus sysfs_remove_file()
> > makes sure that sysfs won't bother a driver after that call, making it safe
> > to free the associated data structures and to unload the driver.
> >
> > Regards
> > Oliver
>
> Hi Oliver,
>
> Thanks for the explaining the patch but some description about the race
> would also help here. At the least the callpath to the race would be useful.
>
>
> Thanks
> Maneesh
We have code like this:
static void tv_disconnect(struct usb_interface *interface)
{
struct trancevibrator *dev;
dev = usb_get_intfdata (interface);
device_remove_file(>dev, _attr_speed);
usb_set_intfdata(interface, NULL);
usb_put_dev(dev->udev);
kfree(dev);
}
This has a race:
CPU A CPU B
open sysfs
device_remove_file
kfree
reading attr
We cannot do refcounting as sysfs doesn't export open/close. Therefore
we must be sure that device_remove_file() makes sure that sysfs will
leave a driver alone after the return of device_remove_file(). Currently
open will fail, but IO on an already opened file will work. The patch makes
sure it will fail with -ENODEV without calling into the driver, which may
indeed be already unloaded.
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] prune_icache_sb
On Mon, 04 Dec 2006 00:57:50 -0500 Wendy Cheng <[EMAIL PROTECTED]> wrote: > > > > > >>>Did you look at improving that lock-lookup algorithm, btw? Core kernel has > >>>no problem maintaining millions of cached VFS objects - is there any reason > >>>why your lock lookup cannot be similarly efficient? > >>> > >>> > >>> > Yes, just found the new DLM uses "jhash" call (include/linux/jhash.h). > I'm on an older version of DLM that uses FNV hash algorithm > (http://www.isthe.com/chongo/tech/comp/fnv/). Will do some performance > test runs to compare these two methods. I'd be surprised if the choice of hash algorithm itself makes much difference. But we can't say much about it unless we can see the code (ie: your code). Is it a simple old hash-to-find-the-bucket-then-walk-a-list implementation? If so, what does the bucket count distribution look like? What is the average walk length? Does it use a single lock, or hashed locking, or a lock-per-bucket? etc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] prune_icache_sb
Andrew Morton wrote:
On Sun, 03 Dec 2006 12:49:42 -0500
Wendy Cheng <[EMAIL PROTECTED]> wrote:
I read this as "It is ok to give system admin(s) commands (that this
"drop_pagecache_sb() call" is all about) to drop page cache. It is,
however, not ok to give filesystem developer(s) this very same function
to trim their own page cache if the filesystems choose to do so" ?
If you're referring to /proc/sys/vm/drop_pagecache then no, that isn't for
administrators - it's a convenience thing for developers, to get repeatable
benchmarks. Attempts to make it a per-numa-node control for admin purposes have
been rejected.
Just saw you suggested the "next door" LKML thread ("la la la la ...
swappiness") to use "-o sync" ? Well, now I do see you're determined ...
anyway, I think I got my stuff working without this kernel patch ...
still under testing though.
The rename post will be done first thing tomorrow morning.
[snip] ...
hmm, I suppose that makes sense.
Are there dentries associated with these locks?
Yes, dentries are part of the logic (during lookup time) but
book-keepings (reference count, reclaim, delete, etc) are all done thru
inode structures.
Did you look at improving that lock-lookup algorithm, btw? Core kernel has
no problem maintaining millions of cached VFS objects - is there any reason
why your lock lookup cannot be similarly efficient?
Yes, just found the new DLM uses "jhash" call (include/linux/jhash.h).
I'm on an older version of DLM that uses FNV hash algorithm
(http://www.isthe.com/chongo/tech/comp/fnv/). Will do some performance
test runs to compare these two methods.
A final note on this subject - I may not agree with you (about various
things) but your comments and amazingly quick responses are very very
appreciated !
-- Wendy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: libata update?
Erik Ohrnberger wrote: Not to sound too dense or anything, but is there a HOWTO for this kernel to enable the libata code? I've read through the Documentation/kernel-parameters.txt file, and seems like all I have to do is include libata.atapi_enabled=1 combined_mode=libata on the grub.conf line to enable it, but when I boot that kernel with that option, I get an error message: 'Block device /dev/sda1 is not a valid root device' and a 'boot() ::' prompt. You shouldn't need atapi_enabled=1 anymore, and combined_mode only applies if you're using an Intel controller with that combined/legacy/AHCI selection braindamage. Did you select the right driver options in the kernel configuration? You'll either have to compile the driver(s) into the kernel or potentially do some distro-specific magic to ensure the modules get loaded in the initrd. -- 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/
About watch dog timer limit of CPU (Xscale ->IXP425) How can I set more long time ?
Hello all , My embeded board hardware configuration is like this : # cat /proc/cpuinfo Processor : XScale-IXP425/IXC1100 rev 1 (v5b) BogoMIPS: 266.24 Features: swp half thumb fastmult edsp Hardware: Intel IXDP425 Development Platform Revision: Serial : Through reading datasheet of ixp4xx ,I know it has own watchdog functions , please see attchment :15 Timer I find a driver by goole , see attachment . Watchdog timer counter is 32 bit register , its max value is 2<<32 -1 #define TIMER_FREQ 6600 /* 66 MHZ timer */ #define TIMER_KEY 0x482e #define TIMER_MARGIN 60 /* (secs) Default is 1 minute */ //I want to modify it ,I find its max value is 65 static int ixp425_margin = TIMER_MARGIN; /* in seconds */ static int ixp425wdt_users; //static int pre_margin; //IXP425 CPU 's watch dog timer is 32 bit , //so I define it to be unsigned int --bob static unsigned int pre_margin; pre_margin = TIMER_FREQ * TIMER_MARGIN *IXP425_OSWT = pre_margin; if I need one minutes , *IXP425_OSWT = 6600 * 60 = 39600 ,not overflow if I need two minutes , *IXP425_OSWT = 6600 * 120 = 79200 ( which has been > 2<<32-1 , overflow So I compute the max time I can set : T_max = 2<<32-1 / 6600= 65 seconds 。 My question: if need more seconds ( for example , 5 minutes ) ,what should I do ? I have a method based on datasheet (ixp4xx) ,but I don't know if it will successed when system crash How can I do to break the limit of hardware ? Thanks ahead ! -- Best Regards bob ixp425_wdt.c Description: Binary data
[RFC][PATCH 2/2] x86_64: earlyprintk usb debug device support.
This patch is still a little rough but it gets all of the major pieces
correct. With a little more work this should become a maintainable
driver.
In particular I believe the ehci debug port code is fairly solid
(with rough edges). However there are several nasty bits that
need to be resolved before we can push this upstream. Like
my include of ehci.h And general early kernel space dependency
problems.
But the code works for me so it should at least be a reasonable starting
point for others looking to make the debug port work in a reasonable fashion.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/early_printk.c | 574 +
drivers/usb/host/ehci.h |8 +
include/asm-x86_64/fixmap.h |1
3 files changed, 583 insertions(+), 0 deletions(-)
diff --git a/arch/x86_64/kernel/early_printk.c
b/arch/x86_64/kernel/early_printk.c
index d4050a5..cb5182d 100644
--- a/arch/x86_64/kernel/early_printk.c
+++ b/arch/x86_64/kernel/early_printk.c
@@ -3,9 +3,19 @@ #include
#include
#include
#include
+#include
+#include
+#include
+#include
#include
#include
#include
+#include
+#include
+#include
+#define EARLY_PRINTK
+#include "../../../drivers/usb/host/ehci.h"
+
/* Simple VGA output */
@@ -155,6 +165,558 @@ static struct console early_serial_conso
.index =-1,
};
+
+static struct ehci_caps __iomem *ehci_caps;
+static struct ehci_regs __iomem *ehci_regs;
+static struct ehci_dbg_port __iomem *ehci_debug;
+static unsigned dbgp_endpoint_out;
+
+#define USB_DEBUG_DEVNUM 127
+
+#define DBGP_DATA_TOGGLE 0x8800
+#define DBGP_PID_UPDATE(x, tok) \
+ x) ^ DBGP_DATA_TOGGLE) & 0x00) | ((tok) & 0xff))
+
+#define DBGP_LEN_UPDATE(x, len) (((x) & ~0x0f) | ((len) & 0x0f))
+/*
+ * USB Packet IDs (PIDs)
+ */
+
+/* token */
+#define USB_PID_OUT0xe1
+#define USB_PID_IN 0x69
+#define USB_PID_SOF0xa5
+#define USB_PID_SETUP 0x2d
+/* handshake */
+#define USB_PID_ACK0xd2
+#define USB_PID_NAK0x5a
+#define USB_PID_STALL 0x1e
+#define USB_PID_NYET 0x96
+/* data */
+#define USB_PID_DATA0 0xc3
+#define USB_PID_DATA1 0x4b
+#define USB_PID_DATA2 0x87
+#define USB_PID_MDATA 0x0f
+/* Special */
+#define USB_PID_PREAMBLE 0x3c
+#define USB_PID_ERR0x3c
+#define USB_PID_SPLIT 0x78
+#define USB_PID_PING 0xb4
+#define USB_PID_UNDEF_00xf0
+
+#define USB_PID_DATA_TOGGLE0x88
+#define DBGP_CLAIM (DBGP_OWNER | DBGP_ENABLED | DBGP_INUSE)
+
+#define PCI_CAP_ID_EHCI_DEBUG 0xa
+
+#define HUB_ROOT_RESET_TIME50 /* times are in msec */
+#define HUB_SHORT_RESET_TIME 10
+#define HUB_LONG_RESET_TIME200
+#define HUB_RESET_TIMEOUT 500
+
+#define DBGP_MAX_PACKET8
+
+static int dbgp_wait_until_complete(void)
+{
+ unsigned ctrl;
+ for (;;) {
+ ctrl = readl(_debug->control);
+ /* Stop when the transaction is finished */
+ if (ctrl & DBGP_DONE)
+ break;
+ }
+ /* Now that we have observed the completed transaction,
+* clear the done bit.
+*/
+ writel(ctrl | DBGP_DONE, _debug->control);
+ return (ctrl & DBGP_ERROR) ? -DBGP_ERRCODE(ctrl) : DBGP_LEN(ctrl);
+}
+
+static void dbgp_mdelay(int ms)
+{
+ int i;
+ while (ms--) {
+ for (i = 0; i < 1000; i++)
+ outb(0x1, 0x80);
+ }
+}
+
+static void dbgp_breath(void)
+{
+ /* Sleep to give the debug port a chance to breathe */
+}
+
+static int dbgp_wait_until_done(unsigned ctrl)
+{
+ unsigned pids, lpid;
+ int ret;
+
+retry:
+ writel(ctrl | DBGP_GO, _debug->control);
+ ret = dbgp_wait_until_complete();
+ pids = readl(_debug->pids);
+ lpid = DBGP_PID_GET(pids);
+
+ if (ret < 0)
+ return ret;
+
+ /* If the port is getting full or it has dropped data
+* start pacing ourselves, not necessary but it's friendly.
+*/
+ if ((lpid == USB_PID_NAK) || (lpid == USB_PID_NYET))
+ dbgp_breath();
+
+ /* If I get a NACK reissue the transmission */
+ if (lpid == USB_PID_NAK)
+ goto retry;
+
+ return ret;
+}
+
+static void dbgp_set_data(const void *buf, int size)
+{
+ const unsigned char *bytes = buf;
+ unsigned lo, hi;
+ int i;
+ lo = hi = 0;
+ for (i = 0; i < 4 && i < size; i++)
+ lo |= bytes[i] << (8*i);
+ for (; i < 8 && i < size; i++)
+ hi |= bytes[i] << (8*(i - 4));
+ writel(lo, _debug->data03);
+ writel(hi, _debug->data47);
+}
+
+static void dbgp_get_data(void *buf, int size)
+{
+ unsigned char *bytes = buf;
+ unsigned lo, hi;
+ int i;
+ lo = readl(_debug->data03);
+ hi =
[PATCH] Kexec / Kdump: Unify elf note code
[PATCH] Kexec / Kdump: Unify elf note code
The elf note saving code is currently duplicated over several architectures.
This cleanup patch simply adds code to a common file and then replaces
the arch-specific code with calls to the newly added code.
The only drawback with this approach is that s390 doesn't fully support
kexec-on-panic which for that arch leads to introduction of unused code.
Signed-Off-By: Magnus Damm <[EMAIL PROTECTED]>
---
Applies on top of linux-2.6.19.
Builds on i386 and x86_64.
arch/i386/kernel/crash.c| 66 +
arch/powerpc/kernel/crash.c | 59 +---
arch/x86_64/kernel/crash.c | 69 +--
include/linux/kexec.h |1
kernel/kexec.c | 56 ++
5 files changed, 63 insertions(+), 188 deletions(-)
--- 0001/arch/i386/kernel/crash.c
+++ work/arch/i386/kernel/crash.c 2006-12-04 11:40:16.0 +0900
@@ -31,68 +31,6 @@
/* This keeps a track of which one is crashing cpu. */
static int crashing_cpu;
-static u32 *append_elf_note(u32 *buf, char *name, unsigned type, void *data,
- size_t data_len)
-{
- struct elf_note note;
-
- note.n_namesz = strlen(name) + 1;
- note.n_descsz = data_len;
- note.n_type = type;
- memcpy(buf, , sizeof(note));
- buf += (sizeof(note) +3)/4;
- memcpy(buf, name, note.n_namesz);
- buf += (note.n_namesz + 3)/4;
- memcpy(buf, data, note.n_descsz);
- buf += (note.n_descsz + 3)/4;
-
- return buf;
-}
-
-static void final_note(u32 *buf)
-{
- struct elf_note note;
-
- note.n_namesz = 0;
- note.n_descsz = 0;
- note.n_type = 0;
- memcpy(buf, , sizeof(note));
-}
-
-static void crash_save_this_cpu(struct pt_regs *regs, int cpu)
-{
- struct elf_prstatus prstatus;
- u32 *buf;
-
- if ((cpu < 0) || (cpu >= NR_CPUS))
- return;
-
- /* Using ELF notes here is opportunistic.
-* I need a well defined structure format
-* for the data I pass, and I need tags
-* on the data to indicate what information I have
-* squirrelled away. ELF notes happen to provide
-* all of that, so there is no need to invent something new.
-*/
- buf = (u32*)per_cpu_ptr(crash_notes, cpu);
- if (!buf)
- return;
- memset(, 0, sizeof(prstatus));
- prstatus.pr_pid = current->pid;
- elf_core_copy_regs(_reg, regs);
- buf = append_elf_note(buf, "CORE", NT_PRSTATUS, ,
- sizeof(prstatus));
- final_note(buf);
-}
-
-static void crash_save_self(struct pt_regs *regs)
-{
- int cpu;
-
- cpu = safe_smp_processor_id();
- crash_save_this_cpu(regs, cpu);
-}
-
#if defined(CONFIG_SMP) && defined(CONFIG_X86_LOCAL_APIC)
static atomic_t waiting_for_crash_ipi;
@@ -121,7 +59,7 @@ static int crash_nmi_callback(struct not
crash_fixup_ss_esp(_regs, regs);
regs = _regs;
}
- crash_save_this_cpu(regs, cpu);
+ crash_save_cpu(regs, cpu);
disable_local_APIC();
atomic_dec(_for_crash_ipi);
/* Assume hlt works */
@@ -195,5 +133,5 @@ void machine_crash_shutdown(struct pt_re
#if defined(CONFIG_X86_IO_APIC)
disable_IO_APIC();
#endif
- crash_save_self(regs);
+ crash_save_cpu(regs, safe_smp_processor_id());
}
--- 0001/arch/powerpc/kernel/crash.c
+++ work/arch/powerpc/kernel/crash.c2006-12-04 11:43:20.0 +0900
@@ -46,61 +46,6 @@ int crashing_cpu = -1;
static cpumask_t cpus_in_crash = CPU_MASK_NONE;
cpumask_t cpus_in_sr = CPU_MASK_NONE;
-static u32 *append_elf_note(u32 *buf, char *name, unsigned type, void *data,
- size_t data_len)
-{
- struct elf_note note;
-
- note.n_namesz = strlen(name) + 1;
- note.n_descsz = data_len;
- note.n_type = type;
- memcpy(buf, , sizeof(note));
- buf += (sizeof(note) +3)/4;
- memcpy(buf, name, note.n_namesz);
- buf += (note.n_namesz + 3)/4;
- memcpy(buf, data, note.n_descsz);
- buf += (note.n_descsz + 3)/4;
-
- return buf;
-}
-
-static void final_note(u32 *buf)
-{
- struct elf_note note;
-
- note.n_namesz = 0;
- note.n_descsz = 0;
- note.n_type = 0;
- memcpy(buf, , sizeof(note));
-}
-
-static void crash_save_this_cpu(struct pt_regs *regs, int cpu)
-{
- struct elf_prstatus prstatus;
- u32 *buf;
-
- if ((cpu < 0) || (cpu >= NR_CPUS))
- return;
-
- /* Using ELF notes here is opportunistic.
-* I need a well defined structure format
-* for the data I pass, and I need tags
-* on the data to indicate what information I have
-* squirrelled away. ELF notes
[RFC][PATCH 1/2] x86_64: Preallocate the fixmap pud and pmd entries.
To use the debug device I need to work through a port so I need to call ioreamp or similar. Since we are doing this very early I chose to use a fixmap (because we are unlikely to free the mapping) and because it is simple. If we preallocate the fixmap pud and pmd entries the existing fixmap codes works anytime from power up without modifications or memory allocations. So we don't need a special case. --- arch/x86_64/kernel/head.S | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/arch/x86_64/kernel/head.S b/arch/x86_64/kernel/head.S index 2f65469..4004965 100644 --- a/arch/x86_64/kernel/head.S +++ b/arch/x86_64/kernel/head.S @@ -271,7 +271,16 @@ NEXT_PAGE(level3_kernel_pgt) .fill 510,8,0 /* (2^48-(2*1024*1024*1024)-((2^39)*511))/(2^30) = 510 */ .quad phys_level2_kernel_pgt | 0x007 - .fill 1,8,0 + .quad phys_level2_fixmap_pgt | 0x007 + +NEXT_PAGE(level2_fixmap_pgt) + .fill 506,8,0 + .quad phys_level1_fixmap_pgt | 0x007 + /* 8MB reserved for vsyscalls + a 2MB hole = 4 + 1 entries */ + .fill 5,8,0 + +NEXT_PAGE(level1_fixmap_pgt) + .fill 512,8,0 NEXT_PAGE(level2_ident_pgt) /* 40MB for bootup. */ -- 1.4.2.rc3.g7e18e-dirty - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: la la la la ... swappiness
On Sun, 3 Dec 2006, Andrew Morton wrote: > On Sun, 3 Dec 2006 17:56:30 -0600 > "Aucoin" <[EMAIL PROTECTED]> wrote: > > > I hope I haven't muddied things up even more but basically what we want to > > do is find a way to limit the number of cached pages for disk I/O on the OS > > filesystem, even if it drastically slows down the untar and verify process > > because the disk I/O we really care about is not on any of the OS > > partitions. > > Try mounting that fs with `-o sync'. Wouldn't it be much nicer to just lower the dirty-page limit? echo 1 > /proc/sys/vm/dirty_background_ratio echo 2 > /proc/sys/vm/dirty_ratio or something. Which we already discussed in another thread and almost already decided we should lower the values for big-mem machines.. Hmm? 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/
[RFC][PATCH 0/2] x86_64 Early usb debug port support.
With legacy free systems serial ports have stopped being an option to get early boot traces and other debug information out of a machine. EHCI USB controllers provide a relatively simple debug interface that can control port 1 of the root hub. This interface is limited to 8 byte packets so it can be used with most USB devices. But with a USB debug device this is sufficient to talk to another machine. When the special feature of the EHCI is not enabled the port 1 of the root hub acts just like any other USB port so machines with the necessary support are widely available. This debug device can be used to replace serial ports for kgdb, kdb, and console support. And gregkh has a simple usb serial driver for it so user space applications that control serial ports should work unmodified. Currently there only appears to be one manufacturer of debug devices see: http://www.plxtech.com/products/NET2000/NET20DC/default.asp I think simple RS232 serial ports provide a nicer and simpler interface but the usb debug port looks like a functional alternative when you don't have that. My code likely doesn't handle all of the corner cases yet, and needs a little more work to integrate cleanly into the build. But this is getting it out there so other people can look and help make clean drivers. When writing a polling driver you do have to be careful with your logic, because if you do things like reset a usb device at the wrong time you can completely confuse various EHCI controllers. My driver should be sufficient to work with any EHCI in a realatively clean state, and needs no special BIOS support just the hardware. This appears to be different than the way the windows drivers are using these debug devices. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CD oddities with VIA PATA
On 12/01/2006 02:42 PM, Ken Moffat wrote: > On Fri, Dec 01, 2006 at 10:01:34PM +, Ken Moffat wrote: >> (i.) cdparanoia (9.8) works for root, but for a user it complains >> that the ioctl isn't cooked and refuses to run. For test purposes, >> it runs ok for a user as suid root, but I imagine that increases >> the likelihood of unspeakable things happening. (Fortunately, I >> don't have a dachshund) For the record, cdparanoia III release 10pre0 (August 29, 2006) works for me. My particular IDE adapter is: 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) I have not tried older versions (yet). Could you try this and see if things are still broken? -- Joshua Kwan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 9/12] IPMI: add pigeonpoint poweroff
On Sun, 03 Dec 2006 20:35:05 -0600 Corey Minyard <[EMAIL PROTECTED]> wrote: > Do you prefer patches to fold into the existing patches or new versions? Incremental updates are preferred where it makes sense, please. That way we can see what changed. I often will convert updated patches into incremental patches just to see what happened. I've caught bugs that way.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: la la la la ... swappiness
On Sun, 3 Dec 2006 19:54:41 -0600 "Aucoin" <[EMAIL PROTECTED]> wrote: > What, if anything, besides manually echoing a "3" to drop_caches will cause > all those inactive pages to be put back on the free list ? There is no reason for the kernel to do that - a clean, inactive page is immediately reclaimable on demand. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: la la la la ... swappiness
On Sun, 3 Dec 2006 17:56:30 -0600 "Aucoin" <[EMAIL PROTECTED]> wrote: > I hope I haven't muddied things up even more but basically what we want to > do is find a way to limit the number of cached pages for disk I/O on the OS > filesystem, even if it drastically slows down the untar and verify process > because the disk I/O we really care about is not on any of the OS > partitions. Try mounting that fs with `-o sync'. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 in sysfs between sysfs_remove_file() and read()/write() #2
On Fri, Dec 01, 2006 at 11:43:06PM +0100, Oliver Neukum wrote:
> Hi,
>
> Alan Stern has discovered a race in sysfs, whereby driver callbacks could be
> called after sysfs_remove_file() has run. The attached patch should fix it.
>
> It introduces a new data structure acting as a collection of all sysfs_buffers
> associated with an attribute. Upon removal of an attribute the buffers are
> marked orphaned and IO on them returns -ENODEV. Thus sysfs_remove_file()
> makes sure that sysfs won't bother a driver after that call, making it safe
> to free the associated data structures and to unload the driver.
>
> Regards
> Oliver
Hi Oliver,
Thanks for the explaining the patch but some description about the race
would also help here. At the least the callpath to the race would be useful.
Thanks
Maneesh
> --- linux-2.6.19-rc6/fs/sysfs/file.c 2006-11-25 23:49:07.0 +0100
> +++ sysfs/fs/sysfs/file.c 2006-12-01 09:47:24.0 +0100
> @@ -7,6 +7,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -50,17 +51,29 @@
> .store = subsys_attr_store,
> };
>
> +/**
> + * add_to_collection - add buffer to a collection
> + * @buffer:buffer to be added
> + * @node inode of set to add to
> + */
>
> -struct sysfs_buffer {
> - size_t count;
> - loff_t pos;
> - char* page;
> - struct sysfs_ops* ops;
> - struct semaphoresem;
> - int needs_read_fill;
> - int event;
> -};
> +static inline void
> +add_to_collection(struct sysfs_buffer *buffer, struct inode *node)
> +{
> + struct sysfs_buffer_collection *set = node->i_private;
> +
> + mutex_lock(>i_mutex);
> + list_add(>associates, >associates);
> + mutex_unlock(>i_mutex);
> +}
>
> +static inline void
> +remove_from_collection(struct sysfs_buffer *buffer, struct inode *node)
> +{
> + mutex_lock(>i_mutex);
> + list_del(>associates);
> + mutex_unlock(>i_mutex);
> +}
>
> /**
> * fill_read_buffer - allocate and fill buffer from object.
> @@ -153,6 +166,10 @@
> ssize_t retval = 0;
>
> down(>sem);
> + if (buffer->orphaned) {
> + retval = -ENODEV;
> + goto out;
> + }
> if (buffer->needs_read_fill) {
> if ((retval = fill_read_buffer(file->f_dentry,buffer)))
> goto out;
> @@ -165,7 +182,6 @@
> return retval;
> }
>
> -
> /**
> * fill_write_buffer - copy buffer from userspace.
> * @buffer:data buffer for file.
> @@ -240,19 +256,25 @@
> ssize_t len;
>
> down(>sem);
> + if (buffer->orphaned) {
> + len = -ENODEV;
> + goto out;
> + }
> len = fill_write_buffer(buffer, buf, count);
> if (len > 0)
> len = flush_write_buffer(file->f_dentry, buffer, len);
> if (len > 0)
> *ppos += len;
> +out:
> up(>sem);
> return len;
> }
>
> -static int check_perm(struct inode * inode, struct file * file)
> +static int sysfs_open_file(struct inode * inode, struct file * file)
> {
> struct kobject *kobj = sysfs_get_kobject(file->f_dentry->d_parent);
> struct attribute * attr = to_attr(file->f_dentry);
> + struct sysfs_buffer_collection *set;
> struct sysfs_buffer * buffer;
> struct sysfs_ops * ops = NULL;
> int error = 0;
> @@ -282,6 +304,18 @@
> if (!ops)
> goto Eaccess;
>
> + /* make sure we have a collection to add our buffers to */
> + mutex_lock(>i_mutex);
> + if (!(set = inode->i_private)) {
> + if (!(set = inode->i_private = kmalloc(sizeof(struct
> sysfs_buffer_collection), GFP_KERNEL))) {
> + error = -ENOMEM;
> + goto Done;
> + } else {
> + INIT_LIST_HEAD(>associates);
> + }
> + }
> + mutex_unlock(>i_mutex);
> +
> /* File needs write support.
>* The inode's perms must say it's ok,
>* and we must have a store method.
> @@ -307,9 +341,11 @@
>*/
> buffer = kzalloc(sizeof(struct sysfs_buffer), GFP_KERNEL);
> if (buffer) {
> + INIT_LIST_HEAD(>associates);
> init_MUTEX(>sem);
> buffer->needs_read_fill = 1;
> buffer->ops = ops;
> + add_to_collection(buffer, inode);
> file->private_data = buffer;
> } else
> error = -ENOMEM;
> @@ -327,11 +363,6 @@
> return error;
> }
>
> -static int sysfs_open_file(struct inode * inode, struct file * filp)
> -{
> - return check_perm(inode,filp);
> -}
> -
> static int sysfs_release(struct inode * inode, struct file * filp)
> {
> struct kobject * kobj = to_kobj(filp->f_dentry->d_parent);
> @@ -339,6 +370,8 @@
> struct module * owner = attr->owner;
> struct
RE: libata update?
> -Original Message- > From: Robert Hancock [mailto:[EMAIL PROTECTED] > Sent: Sunday, December 03, 2006 10:52 AM > To: [EMAIL PROTECTED] > Cc: linux-kernel@vger.kernel.org > Subject: Re: libata update? > > Erik Ohrnberger wrote: > > It's been a number of months since I build a custom kernel with the > > libata incorporated to deal with multiple Promise EIDE controller > > card's 'DMA Expiry' errors. > > > > I'd like to re-build basically the same thing with an > updated kernel > > and updates libata. Could someone point me into the right > direction > > to achieve this? > > > > Thanks in advance > > Erik. > > All of the PATA stuff was merged in 2.6.19, if you want the > very latest and greatest you can try the -mm tree.. > > -- Not to sound too dense or anything, but is there a HOWTO for this kernel to enable the libata code? I've read through the Documentation/kernel-parameters.txt file, and seems like all I have to do is include libata.atapi_enabled=1 combined_mode=libata on the grub.conf line to enable it, but when I boot that kernel with that option, I get an error message: 'Block device /dev/sda1 is not a valid root device' and a 'boot() ::' prompt. Thanks in advance, Erik. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Openipmi-developer] [PATCH 9/12] IPMI: add pigeonpoint poweroff
Randy Dunlap wrote: > Bela Lubkin wrote: >> Andrew Morton wrote: >> >>> Sometime, please go through the IPMI code looking for all these >>> statically-allocated things which are initialised to 0 or NULL and remove >>> all those intialisations? They're unneeded, they increase the vmlinux >>> image size and there are quite a number of them. Thanks. >> Randy Dunlop replied: <>> I was just about to send that patch. Here it is, >>> on top of the series-of-12. >> ... >>> -static int bt_debug = BT_DEBUG_OFF; >>> +static int bt_debug; >> >> Is it wise to significantly degrade code readability to work around a minor >> compiler / linker bug? > > Is that the only one that is a problem? It was the most obvious one at a quick glance. I would argue that _every single one_ is a small problem because it makes the code murkier. Yes we "know" that statics are initialized to zero. Not every reader is perfectly versed in that. The fact that statics and dynamics are different is an added subtlety. Everywhere you've removed an initializer is a potential bug if someone needs to change that variable to a different storage class. Yes they "should" know better. > I don't think it's a problem. We *know* that static data areas > are init to 0. Everything depends on that. If that didn't work > it would all break. Agreed; that's why it's a compiler/linker bug if _explicit_ initialization to zero results in any difference in the final binary. So here you're submitting dozens of source level changes to repair a toolchain bug. > I could say that it's a nice coincidence that BT_DEBUG_OFF == 0, > but I think that it's more than coincidence. I agree, it's more than coincidence. But the new version tells you less. It ccertainly _could_ have been coded such that debug == 1 means no debug, 0 means debug. Dumb, but possible. It could also have been coded such that debug == BT_DEBUG_OFF means debug, but that's egregiously stupid. In other words, I believe the reader of: static int bt_debug = BT_DEBUG_OFF; _knows_ debug is off. The reader of: static int bt_debug = 0; has a _strong suspicion_ that debug is off. The reader of: static int bt_debug; has at best a _strong hint_ that debug is off. Any of those three statements could be shortly followed by: bt_debug = BT_DEBUG_ON; but this would be a moderately surprising construction after the first two; not at all surprising after the third. >Bela< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Openipmi-developer] [PATCH 9/12] IPMI: add pigeonpoint poweroff
Randy Dunlap wrote: Bela Lubkin wrote: Andrew Morton wrote: Sometime, please go through the IPMI code looking for all these statically-allocated things which are initialised to 0 or NULL and remove all those intialisations? They're unneeded, they increase the vmlinux image size and there are quite a number of them. Thanks. Randy Dunlop replied: I was just about to send that patch. Here it is, on top of the series-of-12. ... -static int bt_debug = BT_DEBUG_OFF; +static int bt_debug; Is it wise to significantly degrade code readability to work around a minor compiler / linker bug? Is that the only one that is a problem? I don't think it's a problem. We *know* that static data areas are init to 0. Everything depends on that. If that didn't work it would all break. I could say that it's a nice coincidence that BT_DEBUG_OFF == 0, but I think that it's more than coincidence. It's Corey's decision. However, while code readability is also very important to me, I disagree with "significantly" above. -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Openipmi-developer] [PATCH 11/12] IPMI: Fix BT long busy
Andrew Morton wrote:
> Corey Minyard <[EMAIL PROTECTED]> wrote:
>> +BT_CONTROL(BT_CLR_WR_PTR); /* always reset */
> argh.
>> #define BT_STATUSbt->io->inputb(bt->io, 0)
>> #define BT_CONTROL(x)bt->io->outputb(bt->io, 0, x)
>>
>> #define BMC2HOST bt->io->inputb(bt->io, 1)
>> #define HOST2BMC(x) bt->io->outputb(bt->io, 1, x)
>>
>> #define BT_INTMASK_R bt->io->inputb(bt->io, 2)
>> #define BT_INTMASK_W(x) bt->io->outputb(bt->io, 2, x)
> Please don't write macros which require that the caller have a particular
> local variable of a particular name.
>
> In fact, please don't write macros.
>
> All the above would be perfectly nice as
>
> static inline void bt_control(struct si_sm_data *bt, int val)
> {
> bt->io->outputb(bt->io, val);
> }
Well, needs an input and an output function to route through `inputb' /
`outputb'. But the important values here, which _should_ be macros, are the
register offsets:
#define BT_STATUS_REG 0 /* Read-only */
#define BT_CONTROL_REG 0 /* Write-only */
#define BT_DATA_REG1 /* Read/write */
#define BT_INTMASK_REG 2 /* Read/write */
static inline int bt_control_read(struct si_sm_data *bt, int reg)
{
return bt->io->inputb(bt->io, reg);
}
static inline void bt_control_write(struct si_sm_data *bt, int reg, int data)
{
bt->io->outputb(bt->io, reg, data);
}
bt_control_read(bt, BT_STATUS_REG);/* was BT_STATUS()*/
bt_control_write(bt, BT_CONTROL_REG, data);/* was BT_CONTROL() */
bt_control_read(bt, BT_DATA_REG); /* was BMC2HOST() */
bt_control_write(bt, BT_DATA_REG, data); /* was HOST2BMC() */
bt_control_read(bt, BT_INTMASK_REG); /* was BT_INTMASK_R() */
bt_control_write(bt, BT_INTMASK_REG, data);/* was BT_INTMASK_W() */
...
But the old macro names are more readable at the calling point. What about
making them into inlines (which call the generic _read / _write())? Maybe
with lowercased versions of the original macro names.
>Bela<
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Openipmi-developer] [PATCH 9/12] IPMI: add pigeonpoint poweroff
Bela Lubkin wrote: Andrew Morton wrote: Sometime, please go through the IPMI code looking for all these statically-allocated things which are initialised to 0 or NULL and remove all those intialisations? They're unneeded, they increase the vmlinux image size and there are quite a number of them. Thanks. Randy Dunlop replied: I was just about to send that patch. Here it is, on top of the series-of-12. ... -static int bt_debug = BT_DEBUG_OFF; +static int bt_debug; Is it wise to significantly degrade code readability to work around a minor compiler / linker bug? Is that the only one that is a problem? I don't think it's a problem. We *know* that static data areas are init to 0. Everything depends on that. If that didn't work it would all break. I could say that it's a nice coincidence that BT_DEBUG_OFF == 0, but I think that it's more than coincidence. -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Openipmi-developer] [PATCH 9/12] IPMI: add pigeonpoint poweroff
Andrew Morton wrote: > > Sometime, please go through the IPMI code looking for all these > > statically-allocated things which are initialised to 0 or NULL and remove > > all those intialisations? They're unneeded, they increase the vmlinux > > image size and there are quite a number of them. Thanks. Randy Dunlop replied: > I was just about to send that patch. Here it is, > on top of the series-of-12. ... > -static int bt_debug = BT_DEBUG_OFF; > +static int bt_debug; Is it wise to significantly degrade code readability to work around a minor compiler / linker bug? >Bela< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] IPMI: fix PROC_FS=n warnings
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix build warnings for PROC_FS=n.
drivers/char/ipmi/ipmi_poweroff.c:707: warning: label 'out_err' defined but not
used
drivers/char/ipmi/ipmi_msghandler.c:1774: warning: 'ipmb_file_read_proc'
defined but not used
drivers/char/ipmi/ipmi_msghandler.c:1790: warning: 'version_file_read_proc'
defined but not used
drivers/char/ipmi/ipmi_msghandler.c:1801: warning: 'stat_file_read_proc'
defined but not used
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/char/ipmi/ipmi_msghandler.c |2 ++
drivers/char/ipmi/ipmi_poweroff.c |2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
--- linux-2.6.19-git4.orig/drivers/char/ipmi/ipmi_poweroff.c
+++ linux-2.6.19-git4/drivers/char/ipmi/ipmi_poweroff.c
@@ -702,9 +702,9 @@ static int ipmi_poweroff_init (void)
printk(KERN_ERR PFX "Unable to register SMI watcher: %d\n", rv);
goto out_err;
}
-#endif
out_err:
+#endif
return rv;
}
--- linux-2.6.19-git4.orig/drivers/char/ipmi/ipmi_msghandler.c
+++ linux-2.6.19-git4/drivers/char/ipmi/ipmi_msghandler.c
@@ -1769,6 +1769,7 @@ int ipmi_request_supply_msgs(ipmi_user_t
-1, 0);
}
+#ifdef CONFIG_PROC_FS
static int ipmb_file_read_proc(char *page, char **start, off_t off,
int count, int *eof, void *data)
{
@@ -1857,6 +1858,7 @@ static int stat_file_read_proc(char *pag
return (out - ((char *) page));
}
+#endif /* CONFIG_PROC_FS */
int ipmi_smi_add_proc_entry(ipmi_smi_t smi, char *name,
read_proc_t *read_proc, write_proc_t *write_proc,
---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] remove ftape
[just pushed this to Andrew and Linus] As scheduled, remove long-unmaintained ftape driver subsystem. It's bitrotten, long unmaintained, long hidden under BROKEN_ON_SMP, etc. As scheduled in feature-removal-schedule.txt, and ack'd several times on lkml. Please pull from 'ftape-remove' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git ftape-remove to receive the following updates: Documentation/00-INDEX |2 Documentation/feature-removal-schedule.txt |8 Documentation/ftape.txt | 307 - Documentation/kernel-parameters.txt |3 MAINTAINERS |5 drivers/char/Kconfig| 33 - drivers/char/Makefile |1 drivers/char/ftape/Kconfig | 330 - drivers/char/ftape/Makefile | 28 drivers/char/ftape/README.PCI | 81 - drivers/char/ftape/RELEASE-NOTES| 966 drivers/char/ftape/compressor/Makefile | 31 - drivers/char/ftape/compressor/lzrw3.c | 743 drivers/char/ftape/compressor/lzrw3.h | 253 drivers/char/ftape/compressor/zftape-compress.c | 1203 drivers/char/ftape/compressor/zftape-compress.h | 83 - drivers/char/ftape/lowlevel/Makefile| 43 - drivers/char/ftape/lowlevel/fc-10.c | 175 --- drivers/char/ftape/lowlevel/fc-10.h | 39 - drivers/char/ftape/lowlevel/fdc-io.c| 1349 -- drivers/char/ftape/lowlevel/fdc-io.h| 252 drivers/char/ftape/lowlevel/fdc-isr.c | 1170 --- drivers/char/ftape/lowlevel/fdc-isr.h | 55 - drivers/char/ftape/lowlevel/ftape-bsm.c | 491 drivers/char/ftape/lowlevel/ftape-bsm.h | 66 - drivers/char/ftape/lowlevel/ftape-buffer.c | 130 -- drivers/char/ftape/lowlevel/ftape-buffer.h | 32 - drivers/char/ftape/lowlevel/ftape-calibr.c | 275 drivers/char/ftape/lowlevel/ftape-calibr.h | 37 - drivers/char/ftape/lowlevel/ftape-ctl.c | 896 --- drivers/char/ftape/lowlevel/ftape-ctl.h | 162 --- drivers/char/ftape/lowlevel/ftape-ecc.c | 853 -- drivers/char/ftape/lowlevel/ftape-ecc.h | 84 - drivers/char/ftape/lowlevel/ftape-format.c | 344 -- drivers/char/ftape/lowlevel/ftape-format.h | 37 - drivers/char/ftape/lowlevel/ftape-init.c| 160 --- drivers/char/ftape/lowlevel/ftape-init.h| 43 - drivers/char/ftape/lowlevel/ftape-io.c | 992 drivers/char/ftape/lowlevel/ftape-io.h | 90 - drivers/char/ftape/lowlevel/ftape-proc.c| 214 --- drivers/char/ftape/lowlevel/ftape-proc.h| 35 - drivers/char/ftape/lowlevel/ftape-read.c| 621 -- drivers/char/ftape/lowlevel/ftape-read.h| 51 - drivers/char/ftape/lowlevel/ftape-rw.c | 1092 -- drivers/char/ftape/lowlevel/ftape-rw.h | 111 -- drivers/char/ftape/lowlevel/ftape-setup.c | 104 -- drivers/char/ftape/lowlevel/ftape-tracing.c | 118 -- drivers/char/ftape/lowlevel/ftape-tracing.h | 179 --- drivers/char/ftape/lowlevel/ftape-write.c | 336 - drivers/char/ftape/lowlevel/ftape-write.h | 53 - drivers/char/ftape/lowlevel/ftape_syms.c| 87 - drivers/char/ftape/zftape/Makefile | 36 - drivers/char/ftape/zftape/zftape-buffers.c | 149 -- drivers/char/ftape/zftape/zftape-buffers.h | 55 - drivers/char/ftape/zftape/zftape-ctl.c | 1417 --- drivers/char/ftape/zftape/zftape-ctl.h | 58 - drivers/char/ftape/zftape/zftape-eof.c | 199 --- drivers/char/ftape/zftape/zftape-eof.h | 52 - drivers/char/ftape/zftape/zftape-init.c | 377 -- drivers/char/ftape/zftape/zftape-init.h | 77 - drivers/char/ftape/zftape/zftape-read.c | 377 -- drivers/char/ftape/zftape/zftape-read.h | 53 - drivers/char/ftape/zftape/zftape-rw.c | 375 -- drivers/char/ftape/zftape/zftape-rw.h | 101 -- drivers/char/ftape/zftape/zftape-vtbl.c | 757 drivers/char/ftape/zftape/zftape-vtbl.h | 227 drivers/char/ftape/zftape/zftape-write.c| 483 drivers/char/ftape/zftape/zftape-write.h| 38 - drivers/char/ftape/zftape/zftape_syms.c | 43 - include/linux/Kbuild|4 include/linux/ftape-header-segment.h| 122 -- include/linux/ftape-vendors.h | 137 -- include/linux/ftape.h | 201 --- include/linux/zftape.h | 87 - 74 files changed, 0
Re: [2.6 patch] arch/powerpc/Kconfig: fix the EMBEDDED6xx dependencies
Adrian Bunk writes: > This patch changes the EMBEDDED6xx dependencies to the equivalent > dependency that seems to have been intended. Nack - CONFIG_EMBEDDED6xx is going away entirely, soon. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 9/12] IPMI: add pigeonpoint poweroff
On Sun, 03 Dec 2006 20:35:05 -0600 Corey Minyard wrote: > Andrew Morton wrote: > > On Fri, 1 Dec 2006 22:37:46 -0600 > > Corey Minyard <[EMAIL PROTECTED]> wrote: > > > > > >> +static void (*atca_oem_poweroff_hook)(ipmi_user_t user) = NULL; > >> > > > > Sometime, please go through the IPMI code looking for all these > > statically-allocated things which are initialised to 0 or NULL and remove > > all those intialisations? They're unneeded, they increase the vmlinux > > image size and there are quite a number of them. Thanks. > > > I'll do that, thanks, and I'll work on the other changes you suggest. BTW, how about killing this comment or at least the email address part of it: ipmi_bt_sm.c: * Author:Rocky Craig <[EMAIL PROTECTED]> --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/12] IPMI: add pigeonpoint poweroff
On Sun, 03 Dec 2006 20:35:05 -0600 Corey Minyard wrote:
> Andrew Morton wrote:
> > On Fri, 1 Dec 2006 22:37:46 -0600
> > Corey Minyard <[EMAIL PROTECTED]> wrote:
> >
> >
> >> +static void (*atca_oem_poweroff_hook)(ipmi_user_t user) = NULL;
> >>
> >
> > Sometime, please go through the IPMI code looking for all these
> > statically-allocated things which are initialised to 0 or NULL and remove
> > all those intialisations? They're unneeded, they increase the vmlinux
> > image size and there are quite a number of them. Thanks.
> >
> I'll do that, thanks, and I'll work on the other changes you suggest.
>
> Do you prefer patches to fold into the existing patches or new versions?
I was just about to send that patch. Here it is,
on top of the series-of-12.
---
From: Randy Dunlap <[EMAIL PROTECTED]>
Remove all =0 and =NULL from static initializers.
They are not needed and removing them saves space in the object files.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/char/ipmi/ipmi_bt_sm.c |2 +-
drivers/char/ipmi/ipmi_devintf.c|2 +-
drivers/char/ipmi/ipmi_msghandler.c |6 +++---
drivers/char/ipmi/ipmi_poweroff.c |6 +++---
drivers/char/ipmi/ipmi_si_intf.c| 12 ++--
drivers/char/ipmi/ipmi_watchdog.c | 18 +-
6 files changed, 23 insertions(+), 23 deletions(-)
--- linux-2.6.19-git4.orig/drivers/char/ipmi/ipmi_bt_sm.c
+++ linux-2.6.19-git4/drivers/char/ipmi/ipmi_bt_sm.c
@@ -38,7 +38,7 @@
#define BT_DEBUG_MSG 2 /* Prints all request/response buffers */
#define BT_DEBUG_STATES4 /* Verbose look at state changes */
-static int bt_debug = BT_DEBUG_OFF;
+static int bt_debug;
module_param(bt_debug, int, 0644);
MODULE_PARM_DESC(bt_debug, "debug bitmask, 1=enable, 2=messages, 4=states");
--- linux-2.6.19-git4.orig/drivers/char/ipmi/ipmi_devintf.c
+++ linux-2.6.19-git4/drivers/char/ipmi/ipmi_devintf.c
@@ -834,7 +834,7 @@ static const struct file_operations ipmi
#define DEVICE_NAME "ipmidev"
-static int ipmi_major = 0;
+static int ipmi_major;
module_param(ipmi_major, int, 0);
MODULE_PARM_DESC(ipmi_major, "Sets the major number of the IPMI device. By"
" default, or if you set it to zero, it will choose the next"
--- linux-2.6.19-git4.orig/drivers/char/ipmi/ipmi_msghandler.c
+++ linux-2.6.19-git4/drivers/char/ipmi/ipmi_msghandler.c
@@ -53,10 +53,10 @@
static struct ipmi_recv_msg *ipmi_alloc_recv_msg(void);
static int ipmi_init_msghandler(void);
-static int initialized = 0;
+static int initialized;
#ifdef CONFIG_PROC_FS
-static struct proc_dir_entry *proc_ipmi_root = NULL;
+static struct proc_dir_entry *proc_ipmi_root;
#endif /* CONFIG_PROC_FS */
/* Remain in auto-maintenance mode for this amount of time (in ms). */
@@ -4041,7 +4041,7 @@ static void send_panic_events(char *str)
}
#endif /* CONFIG_IPMI_PANIC_EVENT */
-static int has_panicked = 0;
+static int has_panicked;
static int panic_event(struct notifier_block *this,
unsigned long event,
--- linux-2.6.19-git4.orig/drivers/char/ipmi/ipmi_poweroff.c
+++ linux-2.6.19-git4/drivers/char/ipmi/ipmi_poweroff.c
@@ -58,10 +58,10 @@ static int poweroff_powercycle;
static int ifnum_to_use = -1;
/* Our local state. */
-static int ready = 0;
+static int ready;
static ipmi_user_t ipmi_user;
static int ipmi_ifnum;
-static void (*specific_poweroff_func)(ipmi_user_t user) = NULL;
+static void (*specific_poweroff_func)(ipmi_user_t user);
/* Holds the old poweroff function so we can restore it on removal. */
static void (*old_poweroff_func)(void);
@@ -182,7 +182,7 @@ static int ipmi_request_in_rc_mode(ipmi_
#define IPMI_MOTOROLA_MANUFACTURER_ID 0xA1
#define IPMI_MOTOROLA_PPS_IPMC_PRODUCT_ID 0x0051
-static void (*atca_oem_poweroff_hook)(ipmi_user_t user) = NULL;
+static void (*atca_oem_poweroff_hook)(ipmi_user_t user);
static void pps_poweroff_atca (ipmi_user_t user)
{
--- linux-2.6.19-git4.orig/drivers/char/ipmi/ipmi_si_intf.c
+++ linux-2.6.19-git4/drivers/char/ipmi/ipmi_si_intf.c
@@ -845,7 +845,7 @@ static void request_events(void *send_in
atomic_set(_info->req_events, 1);
}
-static int initialized = 0;
+static int initialized;
static void smi_timeout(unsigned long data)
{
@@ -1018,13 +1018,13 @@ static int num_ports;
static int irqs[SI_MAX_PARMS];
static int num_irqs;
static int regspacings[SI_MAX_PARMS];
-static int num_regspacings = 0;
+static int num_regspacings;
static int regsizes[SI_MAX_PARMS];
-static int num_regsizes = 0;
+static int num_regsizes;
static int regshifts[SI_MAX_PARMS];
-static int num_regshifts = 0;
+static int num_regshifts;
static int slave_addrs[SI_MAX_PARMS];
-static int num_slave_addrs = 0;
+static int num_slave_addrs;
#define IPMI_IO_ADDR_SPACE 0
#define IPMI_MEM_ADDR_SPACE 1
@@ -1668,7 +1668,7 @@ static __devinit void hardcode_find_bmc(
/* Once we get an ACPI
Re: linux 2.6.19 still crashing
Hi, 1st you should put this information on http://bugzilla.kernel.org/ (choose enter a new bug, may choose Category ACPI with component config-interrupts ) for better organization, instead make your own bug documentation. The documentation is very good you should attach the same information on bugzilla your bug kept me the attention because on bad interrupts you have : 21: 10 IO-APIC-fasteoi ohci1394 Exactly oops on 10 interrupts, I had seen this before . I have my bug on http://bugzilla.kernel.org/show_bug.cgi?id=6419 which one of the bugs looks like similar to yours. So, You are saying with kernel 2.6.16.31 with xen 3.0.2, you don't have this problem , I like to try it, how or where you build this Xenified kernel ? Thanks, On Sat, 2006-12-02 at 17:55 +0100, Andreas Jellinghaus wrote: > my msi s270 laptop. but all vanilla kernel I ever tried do > that, also the debian and ubuntu kernel are instable too. > But: xen 3.0.2 plus xen'ified linux 2.6.16.31 are rock solid. > any idea what the issue could be? I'm running 64bit kernel, > 64bit userland (plus some 32bit apps), and the cpu is a turion > mt-40 (sempron users seem to not have this problem). > -- Sérgio M.B. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 9/12] IPMI: add pigeonpoint poweroff
Andrew Morton wrote: On Fri, 1 Dec 2006 22:37:46 -0600 Corey Minyard <[EMAIL PROTECTED]> wrote: +static void (*atca_oem_poweroff_hook)(ipmi_user_t user) = NULL; Sometime, please go through the IPMI code looking for all these statically-allocated things which are initialised to 0 or NULL and remove all those intialisations? They're unneeded, they increase the vmlinux image size and there are quite a number of them. Thanks. I'll do that, thanks, and I'll work on the other changes you suggest. Do you prefer patches to fold into the existing patches or new versions? -Corey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radix-tree.c:__lookup_slot() dead code removal
On Sun, Dec 03, 2006 at 06:02:31PM +0100, Frank van Maarseveen wrote: > --- a/lib/radix-tree.c2006-12-03 13:23:00.0 +0100 > +++ b/lib/radix-tree.c2006-12-03 17:57:03.0 +0100 > @@ -319,9 +319,6 @@ static inline void **__lookup_slot(struc > if (index > radix_tree_maxindex(height)) > return NULL; > > - if (height == 0 && root->rnode) > - return (void **)>rnode; > - > shift = (height-1) * RADIX_TREE_MAP_SHIFT; > slot = >rnode; Acked-by: Fengguang Wu <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] lock stat (rt/rtmutex.c mods) for 2.6.19-rt1
On Sun, Dec 03, 2006 at 06:00:09PM -0800, Bill Huey wrote: > Rudimentary annotations to the lock initializers to avoid the binary > tree search before attachment. For things like inodes that are created > and destroyed constantly this might be useful to get around some > overhead. > > Sorry, about the patch numbering order. I think I screwed up on it. I also screwed up on the title for the email contents. Sorry about that. bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] lock stat (rt/rtmutex.c mods) for 2.6.19-rt1
Rudimentary annotations to the lock initializers to avoid the binary
tree search before attachment. For things like inodes that are created
and destroyed constantly this might be useful to get around some
overhead.
Sorry, about the patch numbering order. I think I screwed up on it.
bill
--- arch/xtensa/platform-iss/network.c eee47b0ca011d1c327ce7aff0c9a7547695d3a1f
+++ arch/xtensa/platform-iss/network.c 76b16d29a46677a45d56b64983e0783959aa2160
@@ -648,6 +648,8 @@ static int iss_net_configure(int index,
.have_mac = 0,
});
+ spin_lock_init(>lock);
+
/*
* Try all transport protocols.
* Note: more protocols can be added by adding '&& !X_init(lp, eth)'.
--- fs/dcache.c 20226054e6d6b080847e7a892d0b47a7ad042288
+++ fs/dcache.c 64d2b2b78b50dc2da7e409f2a9721b80c8fbbaf3
@@ -884,7 +884,7 @@ struct dentry *d_alloc(struct dentry * p
atomic_set(>d_count, 1);
dentry->d_flags = DCACHE_UNHASHED;
- spin_lock_init(>d_lock);
+ spin_lock_init_annotated(>d_lock, &_lock_stat_d_alloc_entry);
dentry->d_inode = NULL;
dentry->d_parent = NULL;
dentry->d_sb = NULL;
--- fs/xfs/support/ktrace.c 1136cf72f9273718da47405b594caebaa59b66d3
+++ fs/xfs/support/ktrace.c 122729d6084fa84115b8f8f75cc55c585bfe3676
@@ -162,6 +162,7 @@ ktrace_enter(
ASSERT(ktp != NULL);
+ spin_lock_init(_lock); //--billh
/*
* Grab an entry by pushing the index up to the next one.
*/
--- include/linux/eventpoll.h bd142a622609d04952fac6215586fff353dab729
+++ include/linux/eventpoll.h 43271ded1a3b9f40beb37aaff9e02fadeecb4655
@@ -15,6 +15,7 @@
#define _LINUX_EVENTPOLL_H
#include
+#include
/* Valid opcodes to issue to sys_epoll_ctl() */
@@ -55,7 +56,7 @@ static inline void eventpoll_init_file(s
static inline void eventpoll_init_file(struct file *file)
{
INIT_LIST_HEAD(>f_ep_links);
- spin_lock_init(>f_ep_lock);
+ spin_lock_init_annotated(>f_ep_lock,
&_lock_stat_eventpoll_init_file_entry);
}
--- net/tipc/node.c d6ddb08c5332517b0eff3b72ee0adc48f47801ff
+++ net/tipc/node.c 9712633ceb8f939fc14a0a4861f7121840beff1d
@@ -77,7 +77,7 @@ struct node *tipc_node_create(u32 addr)
memset(n_ptr, 0, sizeof(*n_ptr));
n_ptr->addr = addr;
-spin_lock_init(_ptr->lock);
+ spin_lock_init(_ptr->lock);
INIT_LIST_HEAD(_ptr->nsub);
n_ptr->owner = c_ptr;
tipc_cltr_attach_node(c_ptr, n_ptr);
[PATCH] USB: fix ohci.h over-use warnings
When u132-hcd is built, it includes local header ohci.h, which appears
to have been intended only for use by ohci-hcd.
This throws warnings about functions which are defined and not used.
The warnings thrown are because three small functions are implemented in
the header, but not declared 'inline', a rather strange affair.
Since these functions are small, let's go ahead and define them as
'inline', just like the inline functions surrounding them. This makes
things more consistent, and kills the warnings.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
diff --git a/drivers/usb/host/ohci.h b/drivers/usb/host/ohci.h
index a2f42a2..fd93e7e 100644
--- a/drivers/usb/host/ohci.h
+++ b/drivers/usb/host/ohci.h
@@ -602,7 +602,7 @@ #define FSMP(fi)(0x7fff & ((6 * ((fi)
#defineFIT (1 << 31)
#define LSTHRESH 0x628 /* lowspeed bit threshold */
-static void periodic_reinit (struct ohci_hcd *ohci)
+static inline void periodic_reinit (struct ohci_hcd *ohci)
{
u32 fi = ohci->fminterval & 0x03fff;
u32 fit = ohci_readl(ohci, >regs->fminterval) & FIT;
@@ -626,11 +626,11 @@ #define read_roothub(hc, register, mask)
temp = ohci_readl (hc, >regs->roothub.register); \
temp; })
-static u32 roothub_a (struct ohci_hcd *hc)
+static inline u32 roothub_a (struct ohci_hcd *hc)
{ return read_roothub (hc, a, 0xfc0fe000); }
static inline u32 roothub_b (struct ohci_hcd *hc)
{ return ohci_readl (hc, >regs->roothub.b); }
static inline u32 roothub_status (struct ohci_hcd *hc)
{ return ohci_readl (hc, >regs->roothub.status); }
-static u32 roothub_portstatus (struct ohci_hcd *hc, int i)
+static inline u32 roothub_portstatus (struct ohci_hcd *hc, int i)
{ return read_roothub (hc, portstatus [i], 0xffe0fce0); }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/4] lock stat (rt/rtmutex.c mods) for 2.6.19-rt1
Mods to rt.c and rtmutex.c
bill
--- init/main.c 268ab0d5f5bdc422e2864cadf35a7bb95958de10
+++ init/main.c 9d14ac66cb0fe3b90334512c0659146aec5e241c
@@ -608,6 +608,7 @@ asmlinkage void __init start_kernel(void
#ifdef CONFIG_PROC_FS
proc_root_init();
#endif
+ lock_stat_sys_init(); //--billh
cpuset_init();
taskstats_init_early();
delayacct_init();
--- kernel/rt.c 5fc97ed10d5053f52488dddfefdb92e6aee2b148
+++ kernel/rt.c 3b86109e8e4163223f17c7d13a5bf53df0e04d70
@@ -66,6 +66,7 @@
#include
#include
#include
+#include
#include "rtmutex_common.h"
@@ -75,6 +76,42 @@
# include "rtmutex.h"
#endif
+#ifdef CONFIG_LOCK_STAT
+#define __LOCK_STAT_RT_MUTEX_LOCK(a) \
+ rt_mutex_lock_with_ip(a,\
+ (unsigned long) __builtin_return_address(0))
+#else
+#define __LOCK_STAT_RT_MUTEX_LOCK(a) \
+ rt_mutex_lock(a);
+#endif
+
+#ifdef CONFIG_LOCK_STAT
+#define __LOCK_STAT_RT_MUTEX_LOCK_INTERRUPTIBLE(a, b) \
+ rt_mutex_lock_interruptible_with_ip(a, b, \
+ (unsigned long) __builtin_return_address(0))
+#else
+#define __LOCK_STAT_RT_MUTEX_LOCK_INTERRUPTIBLE(a) \
+ rt_mutex_lock_interruptible(a, b);
+#endif
+
+#ifdef CONFIG_LOCK_STAT
+#define __LOCK_STAT_RT_MUTEX_TRYLOCK(a)\
+ rt_mutex_trylock_with_ip(a, \
+ (unsigned long) __builtin_return_address(0))
+#else
+#define __LOCK_STAT_RT_MUTEX_TRYLOCK(a)\
+ rt_mutex_trylock(a);
+#endif
+
+#ifdef CONFIG_LOCK_STAT
+#define __LOCK_STAT_RT_SPIN_LOCK(a)\
+ __rt_spin_lock_with_ip(a, \
+ (unsigned long) __builtin_return_address(0))
+#else
+#define __LOCK_STAT_RT_SPIN_LOCK(a)\
+ __rt_spin_lock(a);
+#endif
+
#ifdef CONFIG_PREEMPT_RT
/*
* Unlock these on crash:
@@ -88,7 +125,8 @@ void zap_rt_locks(void)
/*
* struct mutex functions
*/
-void _mutex_init(struct mutex *lock, char *name, struct lock_class_key *key)
+void _mutex_init(struct mutex *lock, char *name, struct lock_class_key *key
+ __COMMA_LOCK_STAT_NOTE_PARAM_DECL)
{
#ifdef CONFIG_DEBUG_LOCK_ALLOC
/*
@@ -97,14 +135,15 @@ void _mutex_init(struct mutex *lock, cha
debug_check_no_locks_freed((void *)lock, sizeof(*lock));
lockdep_init_map(>dep_map, name, key, 0);
#endif
- __rt_mutex_init(>lock, name);
+ __rt_mutex_init(>lock, name __COMMA_LOCK_STAT_NOTE_VARS);
}
EXPORT_SYMBOL(_mutex_init);
void __lockfunc _mutex_lock(struct mutex *lock)
{
mutex_acquire(>dep_map, 0, 0, _RET_IP_);
- rt_mutex_lock(>lock);
+
+ __LOCK_STAT_RT_MUTEX_LOCK(>lock);
}
EXPORT_SYMBOL(_mutex_lock);
@@ -124,14 +163,14 @@ void __lockfunc _mutex_lock_nested(struc
void __lockfunc _mutex_lock_nested(struct mutex *lock, int subclass)
{
mutex_acquire(>dep_map, subclass, 0, _RET_IP_);
- rt_mutex_lock(>lock);
+ __LOCK_STAT_RT_MUTEX_LOCK(>lock);
}
EXPORT_SYMBOL(_mutex_lock_nested);
#endif
int __lockfunc _mutex_trylock(struct mutex *lock)
{
- int ret = rt_mutex_trylock(>lock);
+ int ret = __LOCK_STAT_RT_MUTEX_TRYLOCK(>lock);
if (ret)
mutex_acquire(>dep_map, 0, 1, _RET_IP_);
@@ -152,7 +191,7 @@ int __lockfunc rt_write_trylock(rwlock_t
*/
int __lockfunc rt_write_trylock(rwlock_t *rwlock)
{
- int ret = rt_mutex_trylock(>lock);
+ int ret = __LOCK_STAT_RT_MUTEX_TRYLOCK(>lock);
if (ret)
rwlock_acquire(>dep_map, 0, 1, _RET_IP_);
@@ -179,7 +218,7 @@ int __lockfunc rt_read_trylock(rwlock_t
}
spin_unlock_irqrestore(>wait_lock, flags);
- ret = rt_mutex_trylock(lock);
+ ret = __LOCK_STAT_RT_MUTEX_TRYLOCK(lock);
if (ret)
rwlock_acquire_read(>dep_map, 0, 1, _RET_IP_);
@@ -190,7 +229,7 @@ void __lockfunc rt_write_lock(rwlock_t *
void __lockfunc rt_write_lock(rwlock_t *rwlock)
{
rwlock_acquire(>dep_map, 0, 0, _RET_IP_);
- __rt_spin_lock(>lock);
+ __LOCK_STAT_RT_SPIN_LOCK(>lock);
}
EXPORT_SYMBOL(rt_write_lock);
@@ -210,11 +249,44 @@ void __lockfunc rt_read_lock(rwlock_t *r
return;
}
spin_unlock_irqrestore(>wait_lock, flags);
- __rt_spin_lock(lock);
+ __LOCK_STAT_RT_SPIN_LOCK(lock);
}
EXPORT_SYMBOL(rt_read_lock);
+#ifdef CONFIG_LOCK_STAT
+void __lockfunc rt_write_lock_with_ip(rwlock_t *rwlock, unsigned long ip)
+{
+ rwlock_acquire(>dep_map, 0, 0, ip);
+ __rt_spin_lock_with_ip(>lock, ip);
+}
+EXPORT_SYMBOL(rt_write_lock_with_ip);
+
+void __lockfunc rt_read_lock_with_ip(rwlock_t *rwlock, unsigned
Re: data corruption with nvidia nForce 4 chipsets and IDE/SATA drives
On Sat, 2006-12-02 17:17:37, Kurtis D. Rader wrote:
> I'm also experiencing silent data corruption on writes to SATA disks
> connected to a Nvidia controller (nForce 4 chipset). The problem is
> 100% reproducible. Details of my configuration (mainboard model, lspci,
> etc.) are near the bottom of this message. What follows is a summation
> of my findings.
I ran more tests today. This is definitely not due to faulty memory.
Also, clearly this is not a problem with the nVidia SATA controller that
is part of the nForce 4 chipset since the problem can be reproduced with
a Promise TX2 controller in a PCI slot.
The key question is whether this is a HW quirk of the nForce 4 chipset
that the kernel can and should be working around? What tests can I run that
will help narrow the field of investigation or provide more useful data?
I put one disk on my Promise TX2 SATA controller and the other on the
onboard nVidia controller. As reported before corruption occurs when
writing to either disk but at a lower probability when writing to the
disk on the Promise TX2. Also, if I use a PATA disk as the source of the
copy the probabability of corruption is also greatly reduced (the PATA
disk has about 1/3 the throughput of the SATA disks).
I removed half the memory (two 1 GiB DIMMs from the second bank).
Corruption still occurs. I Replaced the DIMMs in the first bank with the
two removed from the second bank (leaving the second bank unpopulated as
before). Corruption still occurs. I verified by inspection of the e820
map that all memory is mapped below the 4 GiB boundary. I've also been
running prime95 all day with the options "-B2 -t". No errors have been
reported. Coupled with previous clean runs of memtest86 and the symptoms
there seems no reason to believe that faulty memory is the cause of
the corruption.
I should stress that my system is not overclocked. The memory is top of the
line matched pairs of Corsair CMX1024-3200PT DDR2 400 Mhz. The power supply
is an Antec True 380S (380 watts). According to the BIOS temperature
and voltage monitoring everthing is well within operational limits. All
components are less than a year old. I buy the best components and am very
conservative when building a system that I depend upon for doing my job.
I also performed some additional copies of the problematic files using
a program whose core is a direct read, write, verify loop:
ifd = open(source_path, O_RDONLY | O_DIRECT);
ofd = open(dest_path, O_RDWR | O_DIRECT);
while (1) {
if (read( ifd, buf1, blocksize ) != blocksize) exit(0);
again:
write( ofd, buf1, blocksize );
lseek( ofd, -blocksize, SEEK_CUR );
read( ofd, buf2, blocksize );
for (i = 0; i < blocksize; i++) {
if (buf1[i] != buf2[i]) {
fprintf( stderr, "blk %6d offset 0x%04x good %02x bad %02x\n",
blk, i, buf1[i], buf2[i] );
lseek( ofd, -blocksize, SEEK_CUR );
goto again;
}
}
}
It reports corruption at a very low rate (a single block out of 15 GiB).
Rewriting the corrupted block always succeeds on the first try. Note that
the test involves seven 2 GiB and one 1 GiB file (VMware Windows XP guest
image split on 2 GiB boundaries). Of the eight files four have never been
corrupted. Those four are mostly free space (i.e., blocks of nulls). The
four files which consistently show corruption have few free blocks.
Which is further evidence that this involves some subtle HW design fault
that requires a specific pattern of data and bus transactions.
It's interesting to note that running prime95 at the same time as the
disk write test reduces the number of corrupted bytes.
The test loop computes a md5sum for each copied file and compares that to
the known correct md5sum. If any md5sums don't match it then performs a
"cmp -l" of the original file and the copy.
In the "cmp -l" output below the middle column is the good value and the
right-hand column is the bad value from the just created copy of the file.
As reported before all corruption involves the second 32-bit word of a
16-byte aligned region. Note that the offsets reported by cmp(1) start
at one so you need to subtract one to get a proper offset from the start
of the file. So subtract one then convert to hex.
Below are the results of one test with 2 GiB of memory. I'll buy a beer
for the person who can find a pattern to the corruption. Results from
other test runs can be provided upon request. Most corruption involves
only a few bytes in a given 2 GiB file. But I've had a couple of runs
where hundreds, and in one case thousands, of bytes have been corrupted.
iteration 1
1c1
< 748b7ad615a62e41a88a6b5d47bb5581 Windows XP-f001.vmdk
---
> 8aff2d3a23e4f08d9a3145d011368e93 Windows XP-f001.vmdk
3,5c3,5
< 6bbe96c7da14487adab7e0c13b7e54f6 Windows XP-f003.vmdk
< bf7c45c7a6c24bda251a34e73b0cbe9c Windows XP-f004.vmdk
< 241c45aa023556d0bb0b864b3a83a800 Windows
[PATCH 1/4] lock stat for 2.6.19-rt1
This hooks into the preexisting lock definitions in the -rt kernel and
hijacks parts of lockdep for the object hash key.
bill
--- include/linux/mutex.h d231debc2848a8344e1b04055ef22e489702e648
+++ include/linux/mutex.h 734c89362a3d77d460eb20eec3107e7b76fed938
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
@@ -35,7 +36,8 @@ extern void
}
extern void
-_mutex_init(struct mutex *lock, char *name, struct lock_class_key *key);
+_mutex_init(struct mutex *lock, char *name, struct lock_class_key *key
+ __COMMA_LOCK_STAT_NOTE_PARAM_DECL);
extern void __lockfunc _mutex_lock(struct mutex *lock);
extern int __lockfunc _mutex_lock_interruptible(struct mutex *lock);
@@ -56,11 +58,15 @@ extern void __lockfunc _mutex_unlock(str
# define mutex_lock_nested(l, s) _mutex_lock(l)
#endif
+#define __mutex_init(l,n) __rt_mutex_init(&(l)->mutex,\
+ n \
+ __COMMA_LOCK_STAT_NOTE)
+
# define mutex_init(mutex) \
do { \
static struct lock_class_key __key; \
\
- _mutex_init((mutex), #mutex, &__key); \
+ _mutex_init((mutex), #mutex, &__key __COMMA_LOCK_STAT_NOTE);\
} while (0)
#else
--- include/linux/rt_lock.h d7515027865666075d3e285bcec8c36e9b6cfc47
+++ include/linux/rt_lock.h 297792307de5b4aef2c7e472e2a32c727e5de3f1
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_PREEMPT_RT
/*
@@ -28,8 +29,8 @@ typedef struct {
#ifdef CONFIG_DEBUG_RT_MUTEXES
# define __SPIN_LOCK_UNLOCKED(name) \
- (spinlock_t) { { .wait_lock = _RAW_SPIN_LOCK_UNLOCKED(name) \
- , .save_state = 1, .file = __FILE__, .line = __LINE__ } }
+ (spinlock_t) { .lock = { .wait_lock = _RAW_SPIN_LOCK_UNLOCKED(name) \
+ , .save_state = 1, .file = __FILE__, .line = __LINE__
__COMMA_LOCK_STAT_INITIALIZER} }
#else
# define __SPIN_LOCK_UNLOCKED(name) \
(spinlock_t) { { .wait_lock = _RAW_SPIN_LOCK_UNLOCKED(name) } }
@@ -92,7 +93,7 @@ typedef struct {
# ifdef CONFIG_DEBUG_RT_MUTEXES
# define __RW_LOCK_UNLOCKED(name) (rwlock_t) \
{ .lock = { .wait_lock = _RAW_SPIN_LOCK_UNLOCKED(name), \
-.save_state = 1, .file = __FILE__, .line = __LINE__ } }
+.save_state = 1, .file = __FILE__, .line = __LINE__
__COMMA_LOCK_STAT_INITIALIZER } }
# else
# define __RW_LOCK_UNLOCKED(name) (rwlock_t) \
{ .lock = { .wait_lock = _RAW_SPIN_LOCK_UNLOCKED(name) } }
@@ -139,14 +140,16 @@ struct semaphore name = \
*/
#define DECLARE_MUTEX_LOCKED COMPAT_DECLARE_MUTEX_LOCKED
-extern void fastcall __sema_init(struct semaphore *sem, int val, char *name,
char *file, int line);
+extern void fastcall __sema_init(struct semaphore *sem, int val, char *name
+ __COMMA_LOCK_STAT_FN_DECL, char *_file, int
_line);
#define rt_sema_init(sem, val) \
- __sema_init(sem, val, #sem, __FILE__, __LINE__)
+ __sema_init(sem, val, #sem __COMMA_LOCK_STAT_NOTE_FN, __FILE__,
__LINE__)
-extern void fastcall __init_MUTEX(struct semaphore *sem, char *name, char
*file, int line);
+extern void fastcall __init_MUTEX(struct semaphore *sem, char *name
+ __COMMA_LOCK_STAT_FN_DECL, char *_file, int
_line);
#define rt_init_MUTEX(sem) \
- __init_MUTEX(sem, #sem, __FILE__, __LINE__)
+ __init_MUTEX(sem, #sem __COMMA_LOCK_STAT_NOTE_FN, __FILE__,
__LINE__)
extern void there_is_no_init_MUTEX_LOCKED_for_RT_semaphores(void);
@@ -247,13 +250,14 @@ extern void fastcall __rt_rwsem_init(str
struct rw_semaphore lockname = __RWSEM_INITIALIZER(lockname)
extern void fastcall __rt_rwsem_init(struct rw_semaphore *rwsem, char *name,
-struct lock_class_key *key);
+struct lock_class_key *key
+ __COMMA_LOCK_STAT_NOTE_PARAM_DECL);
# define rt_init_rwsem(sem)\
do { \
static struct lock_class_key __key; \
\
- __rt_rwsem_init((sem), #sem, &__key); \
+ __rt_rwsem_init((sem), #sem, &__key __COMMA_LOCK_STAT_NOTE);
\
} while (0)
extern void fastcall rt_down_write(struct rw_semaphore *rwsem);
--- include/linux/rtmutex.h e6fa10297e6c20d27edba172aeb078a60c64488e
+++ include/linux/rtmutex.h 55cd2de44a52e049fa8a0da63bde6449cefeb8fe
[PATCH 0/4] lock stat for 2.6.19-rt1
Hello,
I'm please to announce the "lock stat" patch which instruments all locks in
the kernel tracking contention against the slow path of an a rt_mutex in -rt
kernels before blocking and possibly priority inheritence boosting. This is
for 2.6.19-rt1. In the real time patch, all locks such as a mutex, semaphore,
etc... are funneled through the rt_mutex as well as locks such as a spinlock
which preserve the semantics of BKL when hitting scheduler code.
On a contention, it increments a field atomically that's pointed in a variable
within the rt_mutex structure. It records the numbers of times the rt_mutex
is contented against during the lifetime of that lock.
By using a hash constructed out of __FILE__, __func__ and __LINE__ of the
actual lock initializer function (spin_lock_init() and friends) single
backing object within a red black tree based dictionary can serve to record
these statistics versus explicitly tracking the life and death of a lock
explicitly. This is more meaningful than having these statistics recorded
on an individual lock instance. It's a higher order of expression with how
lock statistics are represented since it's about the macro behavior of the
kernel and therefore is more meaningful.
I'll defer the other parts of the discussion to the comments in the patch
itself. I just want to get this patch right now with further delaying this.
It's quite similar to how lockdep also hooks into the kernel but I wasn't
aware of how lockdep worked when I was writing this code only to be told by
Peter Zijlstra after his review of the patch.
This is superior to lock meter for a number of reasons. First it's the -rt
kernel (and we all know how I love the -rt kernel :) ) it is Linux specific,
it hooks into lockdep closely and has a friendly proc interface to go with
it with the ability to reset stats during load testing runs by simply
writing to the file, /proc/lock_stat/contention.
Sample output is attached:
---
[1, 1, 0] {finish_wait, -, 0}
[1, 1, 0] {lru_add_drain, -, 0}
[1, 1, 0] {rt_down_read, -, 0}
[1, 1, 0] {__sync_inodes, -, 0}
[1, 1, 0] {unix_create1, -, 0}
[1110, 1, 0]{kmem_cache_free, -, 0}
[11, 1, 0] {pdflush, -, 0}
[1, 123148, 0] {init_buffer_head, fs/buffer.c, 2968}
[1, 2, 0] {__svc_create, net/sunrpc/svc.c, 328}
[14, 11446, 0] {sock_lock_init, net/core/sock.c, 809}
[14373, 1, 0] {ide_intr, -, 0}
[14878, 13, 0] {create_workqueue_thread, kernel/workqueue.c, 347}
[15, 123148, 0] {init_buffer_head, fs/buffer.c, 2969}
[153, 1, 0] {__free_pages_ok, -, 0}
[17, 1, 0] {init_timers_cpu, kernel/timer.c, 1834}
[17533, 1, 0] {_atomic_dec_and_spin_lock, -, 0}
[203, 1, 0] {release_pages, -, 0}
[2040, 1, 0]{do_wait, -, 0}
[2, 1, 0] {cache_alloc_refill, -, 0}
[2, 1, 0] {sys_setsid, -, 0}
[23, 996648, 0] {inode_init_once, fs/inode.c, 199}
[242, 996648, 0]{inode_init_once, fs/inode.c, 197}
[251, 1, 0] {get_zone_pcp, -, 0}
[25, 1248, 0] {anon_vma_ctor, mm/rmap.c, 168}
[2725, 1, 0]{lock_kernel, -, 0}
[3, 1, 0] {lock_timer_base, -, 0}
[3, 1, 0] {serio_thread, -, 0}
[31, 81, 0] {kmem_list3_init, mm/slab.c, 411}
[32, 1, 0] {lru_cache_add_active, -, 0}
[3, 256, 0] {init, kernel/futex.c, 2776}
[33, 1, 0] {get_page_from_freelist, -, 0}
[35, 1, 0] {do_lookup, -, 0}
[37, 1, 0] {file_kill, -, 0}
[39, 1, 0] {__cache_free, -, 0}
[403, 204, 0] {sighand_ctor, kernel/fork.c, 1469}
[4, 16, 0] {xprt_create_transport, net/sunrpc/xprt.c, 930}
[4, 29369, 0] {mm_init, kernel/fork.c, 368}
[49, 2, 0] {journal_init_common, fs/jbd/journal.c, 666}
[5, 1, 0] {mm_init, -, 0}
[52, 1, 0] {lookup_mnt, -, 0}
[549, 0, 1349567] {, d_alloc_string, 1}
[5871, 2, 0]{journal_init_common, fs/jbd/journal.c, 667}
[59, 1, 0] {nv_probe, drivers/net/forcedeth.c, 4241}
[6, 11443, 0] {sock_init_data, net/core/sock.c, 1503}
[8, 2, 0] {journal_init_revoke, fs/jbd/revoke.c, 261}
[8264, 996648, 0] {inode_init_once, fs/inode.c, 196}
[8552, 996648, 0] {inode_init_once, fs/inode.c, 193}
[86, 1, 0] {exit_mmap, -, 0}
[86, 86258, 0] {init_waitqueue_head, kernel/wait.c, 15}
[8968, 1, 0]{iget_locked, -, 0}
[9, 1, 0] {tty_ldisc_try, -, 0}
[9, 1, 0] {uart_set_options, drivers/serial/serial_core.c, 1876}
@contention events = 86925
@found = 9
---
The first column is the number of the times that object was contented against.
The second is the number of times this lock object
RE: la la la la ... swappiness
I should also have made it clear that under a full load OOM kills critical data moving processes because of (what appears to be) the out of control memory consumption by disk I/O cache related to the tar. As a side note, even now, *hours* after the tar has completed and even though I have swappiness set to 0, cache pressure set to , all dirty timeouts set to 1 and all dirty ratios set to 1, I still have a 360+K inactive page count and my "free" memory is less than 10% of normal. I'm not pretending to understand what's happening here but shouldn't some kind of expiration have kicked in by now and freed up all those inactive pages? The *instant* I manually push a "3" into drop_caches I have 100% of my normal free memory and the inactive page count drops below 2K. Maybe I completely misunderstood the purpose of all those dials but I really did get the feeling that twisting them all tight would make the housekeeping algorithms more aggressive. What, if anything, besides manually echoing a "3" to drop_caches will cause all those inactive pages to be put back on the free list ? -Original Message- From: Aucoin [mailto:[EMAIL PROTECTED] Sent: Sunday, December 03, 2006 5:57 PM To: 'Tim Schmielau' Cc: 'Andrew Morton'; '[EMAIL PROTECTED]'; 'linux-kernel@vger.kernel.org'; '[EMAIL PROTECTED]' Subject: RE: la la la la ... swappiness We want it to swap less for this particular operation because it is low priority compared to the rest of what's going on inside the box. We've considered both artificially manipulating swap on the fly similar to your suggestion as well a parallel thread that pumps a 3 into drop_caches every few seconds while the update is running, but these seem too much like hacks for our liking. Mind you, if we don't have a choice we'll do what we need to get the job done but there's a nagging voice in our conscience that says keep looking for a more elegant solution and work *with* the kernel rather than working against it or trying to trick it into doing what we want. We've already disabled OOM so we can at least keep our testing alive while searching for a more elegant solution. Although we want to avoid swap in this particular instance for this particular reason, in our hearts we agree with Andrew that swap can be your friend and get you out of a jam once in a while. Even more, we'd like to leave OOM active if we can because we want to be told when somebody's not being a good memory citizen. Some background, what we've done is carve up a huge chunk of memory that is shared between three resident processes as write cache for a proprietary block system layout that is part of a scalable storage architecture currently capable of RAID 0, 1, 5 (soon 6) virtualized across multiple chassis's, essentially treating each machine as a "disk" and providing multipath I/O to multiple iSCSI targets as part of a grid/array storage solution. Whew! We also have a version that leverages a battery backed write cache for higher performance at an additional cost. This software is installable on any commodity platform with 4-N disks supported by Linux, I've even put it on an Optiplex with 4 simulated disks. Yawn ... yet another iSCSI storage solution, but this one scales linearly in capacity as well as performance. As such, we have no user level apps on the boxes and precious little disk to spare for additional swap so our version of the swap manipulation solution is to turn swap completely off for the duration of the update. I hope I haven't muddied things up even more but basically what we want to do is find a way to limit the number of cached pages for disk I/O on the OS filesystem, even if it drastically slows down the untar and verify process because the disk I/O we really care about is not on any of the OS partitions. Louis Aucoin -Original Message- From: Tim Schmielau [mailto:[EMAIL PROTECTED] Sent: Sunday, December 03, 2006 2:47 PM To: Aucoin Cc: 'Andrew Morton'; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; [EMAIL PROTECTED] Subject: RE: la la la la ... swappiness On Sun, 3 Dec 2006, Aucoin wrote: > during tar extraction ... inactive pages reaches levels as high as ~375000 So why do you want the system to swap _less_? You need to find some free memory for the additional processes to run in, and you have lots of inactive pages, so I think you want to swap out _more_ pages. I'd suggest to temporarily add a swapfile before you update your system. This can even help in bringing your memory use to the state before if you do it like this - swapon additional swapfile - update your database software - swapoff swap partition - swapon swap partition - swapoff additional swapfile Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mmc: fix au1xmmc build error
Hi,
This patch has fixed the following build error abou au1xmmc.
drivers/mmc/au1xmmc.c: In function `au1xmmc_poll_event':
drivers/mmc/au1xmmc.c:835: warning: unused variable `status'
drivers/mmc/au1xmmc.c: At top level:
drivers/mmc/au1xmmc.c:878: error: parse error before "const"
drivers/mmc/au1xmmc.c: In function `au1xmmc_probe':
drivers/mmc/au1xmmc.c:909: error: `au1xmmc_ops' undeclared (first use in this
function)
drivers/mmc/au1xmmc.c:909: error: (Each undeclared identifier is reported only
once
drivers/mmc/au1xmmc.c:909: error: for each function it appears in.)
drivers/mmc/au1xmmc.c: At top level:
drivers/mmc/au1xmmc.c:659: warning: 'au1xmmc_request' defined but not used
drivers/mmc/au1xmmc.c:719: warning: 'au1xmmc_set_ios' defined but not used
make[2]: *** [drivers/mmc/au1xmmc.o] Error 1
make[1]: *** [drivers/mmc] Error 2
make: *** [drivers] Error 2
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -pruN -X linux-2.6.19-rc6-mm2/Documentation/dontdiff
linux-2.6.19-rc6-mm2-orig/drivers/mmc/au1xmmc.c
linux-2.6.19-rc6-mm2/drivers/mmc/au1xmmc.c
--- linux-2.6.19-rc6-mm2-orig/drivers/mmc/au1xmmc.c 2006-11-29
10:11:46.026275500 +0900
+++ linux-2.6.19-rc6-mm2/drivers/mmc/au1xmmc.c 2006-11-29 13:46:27.293077250
+0900
@@ -875,7 +875,7 @@ static void au1xmmc_init_dma(struct au1x
host->rx_chan = rxchan;
}
-struct const mmc_host_ops au1xmmc_ops = {
+static const struct mmc_host_ops au1xmmc_ops = {
.request= au1xmmc_request,
.set_ios= au1xmmc_set_ios,
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] SCSI/megaraid: fix MMIO casts
megaraid's MMIO RD*/WR* macros directly call readl() and writel() with
an 'unsigned long' argument. This throws a warning, but is otherwise OK
because the 'unsigned long' is really the result of ioremap(). This
setup is also OK because the variable can hold an ioremap cookie /or/ a
PCI I/O port (PIO).
However, to fix the warning thrown when readl() and writel() are passed
an unsigned long cookie, I introduce 'void __iomem *mmio_base', holding
the same value as 'base'. This will silence the warnings, and also
cause an oops whenever these MMIO-only functions are ever accidentally
passed an I/O address.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c
index 86099fd..77d9d38 100644
--- a/drivers/scsi/megaraid.c
+++ b/drivers/scsi/megaraid.c
@@ -73,10 +73,10 @@ static unsigned short int max_mbox_busy_
module_param(max_mbox_busy_wait, ushort, 0);
MODULE_PARM_DESC(max_mbox_busy_wait, "Maximum wait for mailbox in microseconds
if busy (default=MBOX_BUSY_WAIT=10)");
-#define RDINDOOR(adapter) readl((adapter)->base + 0x20)
-#define RDOUTDOOR(adapter) readl((adapter)->base + 0x2C)
-#define WRINDOOR(adapter,value)writel(value, (adapter)->base +
0x20)
-#define WROUTDOOR(adapter,value) writel(value, (adapter)->base + 0x2C)
+#define RDINDOOR(adapter) readl((adapter)->mmio_base + 0x20)
+#define RDOUTDOOR(adapter) readl((adapter)->mmio_base + 0x2C)
+#define WRINDOOR(adapter,value) writel(value, (adapter)->mmio_base +
0x20)
+#define WROUTDOOR(adapter,value) writel(value, (adapter)->mmio_base + 0x2C)
/*
* Global variables
@@ -1386,7 +1386,8 @@ megaraid_isr_memmapped(int irq, void *de
handled = 1;
- while( RDINDOOR(adapter) & 0x02 ) cpu_relax();
+ while( RDINDOOR(adapter) & 0x02 )
+ cpu_relax();
mega_cmd_done(adapter, completed, nstatus, status);
@@ -4668,6 +4669,8 @@ megaraid_probe_one(struct pci_dev *pdev,
host->host_no, mega_baseport, irq);
adapter->base = mega_baseport;
+ if (flag & BOARD_MEMMAP)
+ adapter->mmio_base = (void __iomem *) mega_baseport;
INIT_LIST_HEAD(>free_list);
INIT_LIST_HEAD(>pending_list);
diff --git a/drivers/scsi/megaraid.h b/drivers/scsi/megaraid.h
index 66529f1..c6e7464 100644
--- a/drivers/scsi/megaraid.h
+++ b/drivers/scsi/megaraid.h
@@ -801,7 +801,8 @@ typedef struct {
clustering is available */
u32 flag;
- unsigned long base;
+ unsigned long base;
+ void __iomem*mmio_base;
/* mbox64 with mbox not aligned on 16-byte boundry */
mbox64_t*una_mbox64;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] ISDN: fix warnings
* diva, sedlbauer: the 'ready' label is only used in certain configurations
* hfc_pci:
- cast 'arg' to proper size for testing and printing
- print out 'void __iomem *' variables with %p,
rather than using incorrect casts that throw warnings
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
diff --git a/drivers/isdn/hisax/diva.c b/drivers/isdn/hisax/diva.c
index 3dacfff..6eebeb4 100644
--- a/drivers/isdn/hisax/diva.c
+++ b/drivers/isdn/hisax/diva.c
@@ -1121,7 +1121,11 @@ #endif /* CONFIG_PCI */
bytecnt = 32;
}
}
+
+#ifdef __ISAPNP__
ready:
+#endif
+
printk(KERN_INFO
"Diva: %s card configured at %#lx IRQ %d\n",
(cs->subtyp == DIVA_PCI) ? "PCI" :
diff --git a/drivers/isdn/hisax/hfc_pci.c b/drivers/isdn/hisax/hfc_pci.c
index 93f60b5..463b8ac 100644
--- a/drivers/isdn/hisax/hfc_pci.c
+++ b/drivers/isdn/hisax/hfc_pci.c
@@ -1211,7 +1211,7 @@ #endif
break;
case (HW_TESTLOOP | REQUEST):
spin_lock_irqsave(>lock, flags);
- switch ((int) arg) {
+ switch ((long) arg) {
case (1):
Write_hfc(cs, HFCPCI_B1_SSL, 0x80);
/* tx slot */
Write_hfc(cs, HFCPCI_B1_RSL, 0x80);
/* rx slot */
@@ -1229,7 +1229,7 @@ #endif
default:
spin_unlock_irqrestore(>lock,
flags);
if (cs->debug & L1_DEB_WARN)
- debugl1(cs, "hfcpci_l1hw loop
invalid %4x", (int) arg);
+ debugl1(cs, "hfcpci_l1hw loop
invalid %4lx", (long) arg);
return;
}
cs->hw.hfcpci.trm |= 0x80; /* enable IOM-loop */
@@ -1709,9 +1709,9 @@ #ifdef CONFIG_PCI
pci_write_config_dword(cs->hw.hfcpci.dev, 0x80, (u_int)
virt_to_bus(cs->hw.hfcpci.fifos));
cs->hw.hfcpci.pci_io = ioremap((ulong) cs->hw.hfcpci.pci_io,
256);
printk(KERN_INFO
- "HFC-PCI: defined at mem %#x fifo %#x(%#x) IRQ %d HZ
%d\n",
- (u_int) cs->hw.hfcpci.pci_io,
- (u_int) cs->hw.hfcpci.fifos,
+ "HFC-PCI: defined at mem %p fifo %p(%#x) IRQ %d HZ %d\n",
+ cs->hw.hfcpci.pci_io,
+ cs->hw.hfcpci.fifos,
(u_int) virt_to_bus(cs->hw.hfcpci.fifos),
cs->irq, HZ);
spin_lock_irqsave(>lock, flags);
diff --git a/drivers/isdn/hisax/sedlbauer.c b/drivers/isdn/hisax/sedlbauer.c
index 9522141..030d162 100644
--- a/drivers/isdn/hisax/sedlbauer.c
+++ b/drivers/isdn/hisax/sedlbauer.c
@@ -677,7 +677,11 @@ #else
return (0);
#endif /* CONFIG_PCI */
}
+
+#ifdef __ISAPNP__
ready:
+#endif
+
/* In case of the sedlbauer pcmcia card, this region is in use,
* reserved for us by the card manager. So we do not check it
* here, it would fail.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] DRM: handle pci_enable_device failure
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
diff --git a/drivers/char/drm/drm_stub.c b/drivers/char/drm/drm_stub.c
index 7b1d4e8..35e5ff6 100644
--- a/drivers/char/drm/drm_stub.c
+++ b/drivers/char/drm/drm_stub.c
@@ -209,14 +209,16 @@ int drm_get_dev(struct pci_dev *pdev, co
if (!dev)
return -ENOMEM;
- pci_enable_device(pdev);
+ ret = pci_enable_device(pdev);
+ if (ret)
+ goto err_g1;
if ((ret = drm_fill_in_dev(dev, pdev, ent, driver))) {
printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
- goto err_g1;
+ goto err_g2;
}
if ((ret = drm_get_head(dev, >primary)))
- goto err_g1;
+ goto err_g2;
DRM_INFO("Initialized %s %d.%d.%d %s on minor %d\n",
driver->name, driver->major, driver->minor, driver->patchlevel,
@@ -224,7 +226,9 @@ int drm_get_dev(struct pci_dev *pdev, co
return 0;
- err_g1:
+err_g2:
+ pci_disable_device(pdev);
+err_g1:
drm_free(dev, sizeof(*dev), DRM_MEM_STUB);
return ret;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: held lock freed!" lock validator tripped by kswapd & xfs
On Fri, Dec 01, 2006 at 02:34:42PM -0800, Stephen Pollei wrote:
> On 12/1/06, Mike Mattie <[EMAIL PROTECTED]> wrote:
>
> >In an attempt to debug another kernel issue I turned on the lock validator
> >and
> >managed to generate this report.
> >
> >As a side note the first attempt to boot with the lock validator failed
> >with
> >a message indicating I had exceeded MAX_LOCK_DEPTH. To get this trace
> >I patched sched.h: MAX_LOCK_DEPTH to 60.
> >
> >Dec 1 08:35:41 reforged [ 3052.513931] =
> >Dec 1 08:35:41 reforged [ 3052.513937] [ BUG: held lock freed! ]
> >Dec 1 08:35:41 reforged [ 3052.513939] -
> >Dec 1 08:35:41 reforged [ 3052.513943] kswapd0/183 is freeing memory
> >c3458000-c3458fff, with a lock still held there! Dec 1 08:35:41
> >reforged [ 3052.513947] (&(>i_iolock)->mr_lock){}, at:
> >[] xfs_ilock+0x20/0x75 Dec 1 08:35:41 reforged
> >[ 3052.513959] 28 locks held by kswapd0/183: Dec 1 08:35:41 reforged
> >[ 3052.513961] #0: (&(>i_iolock)->mr_lock){}, at:
> >[] xfs_ilock+0x20/0x75 Dec 1 08:35:41 reforged
> >[ 3052.513968] #1: (&(>i_lock)->mr_lock){}, at: []
> >xfs_ilock+0x52/0x75 Dec 1 08:35:41 reforged [ 3052.513975]
>
> seems to alternate between same two locks. But both c089 and
> c0bb are not between the page(oxfff=4095 or about 4k) which kswapd
> is trying to get rid of.
> I think this trace is on crack somehow.
IIRC, lockdep doesn't understand the xfs inode locks yet. We've
got a patch to fix most of this, but I don't think it's been merged.
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/
[PATCH] ACPI: kill unused variable
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
diff --git a/drivers/acpi/events/evmisc.c b/drivers/acpi/events/evmisc.c
index ee2a10b..bf63edc 100644
--- a/drivers/acpi/events/evmisc.c
+++ b/drivers/acpi/events/evmisc.c
@@ -331,7 +331,6 @@ static void ACPI_SYSTEM_XFACE acpi_ev_gl
static u32 acpi_ev_global_lock_handler(void *context)
{
u8 acquired = FALSE;
- acpi_status status;
/*
* Attempt to get the lock
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 14/23] x86 microcode: dont check the size
On Mon, Dec 04, 2006 at 09:04:03AM +0800, Shaohua Li wrote: > On Sat, 2006-12-02 at 07:44 +0100, Willy Tarreau wrote: > > Shaohua, > > > > this one seems appropriate for 2.4 too. It is OK for you if I merge it ? > Yes, 2.4 and 2.6 use the same driver. It should be fine to merge it. > > Thanks, > Shaohua Queued, thank you ! Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 14/23] x86 microcode: dont check the size
On Sat, 2006-12-02 at 07:44 +0100, Willy Tarreau wrote:
> Shaohua,
>
> this one seems appropriate for 2.4 too. It is OK for you if I merge it ?
Yes, 2.4 and 2.6 use the same driver. It should be fine to merge it.
Thanks,
Shaohua
> On Wed, Nov 29, 2006 at 02:00:25PM -0800, Chris Wright wrote:
> > -stable review patch. If anyone has any objections, please let us know.
> > --
> >
> > From: Shaohua Li <[EMAIL PROTECTED]>
> >
> > IA32 manual says if micorcode update's size is 0, then the size is
> > default size (2048 bytes). But this doesn't suggest all microcode
> > update's size should be above 2048 bytes to me. We actually had a
> > microcode update whose size is 1024 bytes. The patch just removed the
> > check.
> >
> > Backported to 2.6.18 by Daniel Drake.
> >
> > Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
> > Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
> > ---
> > arch/i386/kernel/microcode.c |9 ++---
> > 1 file changed, 2 insertions(+), 7 deletions(-)
> >
> > --- linux-2.6.18.4.orig/arch/i386/kernel/microcode.c
> > +++ linux-2.6.18.4/arch/i386/kernel/microcode.c
> > @@ -250,14 +250,14 @@ static int find_matching_ucodes (void)
> > }
> >
> > total_size = get_totalsize(_header);
> > - if ((cursor + total_size > user_buffer_size) || (total_size <
> > DEFAULT_UCODE_TOTALSIZE)) {
> > + if (cursor + total_size > user_buffer_size) {
> > printk(KERN_ERR "microcode: error! Bad data in
> > microcode data file\n");
> > error = -EINVAL;
> > goto out;
> > }
> >
> > data_size = get_datasize(_header);
> > - if ((data_size + MC_HEADER_SIZE > total_size) || (data_size <
> > DEFAULT_UCODE_DATASIZE)) {
> > + if (data_size + MC_HEADER_SIZE > total_size) {
> > printk(KERN_ERR "microcode: error! Bad data in
> > microcode data file\n");
> > error = -EINVAL;
> > goto out;
> > @@ -460,11 +460,6 @@ static ssize_t microcode_write (struct f
> > {
> > ssize_t ret;
> >
> > - if (len < DEFAULT_UCODE_TOTALSIZE) {
> > - printk(KERN_ERR "microcode: not enough data\n");
> > - return -EINVAL;
> > - }
> > -
> > if ((len >> PAGE_SHIFT) > num_physpages) {
> > printk(KERN_ERR "microcode: too much data (max %ld pages)\n",
> > num_physpages);
> > return -EINVAL;
> >
> > --
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: la la la la ... swappiness
Aucoin <[EMAIL PROTECTED]> wrote: > We want it to swap less for this particular operation because it is low > priority compared to the rest of what's going on inside the box. The swapping is not a "operation" thing, it is global for /all/ what is going on in the box. And having it swap less means assigning it more RAM, i.e., giving it higher (not lower) priority than other stuff happening at the same time. I guess I don't understand what your needs are (not what you want to do to get there). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
drivers/atm throws weird build "error"
Running "make allmodconfig" on current linux-2.6.git top of tree on x86-64, I see the following when beginning a drivers/atm compile: make -f scripts/Makefile.build obj=drivers/atm include/asm/byteorder.h:5:28: error: linux/compiler.h: No such file or directory However, the build continues just fine. Here's the full KBUILD_VERBOSE=1 section in question: gcc -Wp,-MD,drivers/ata/.pata_triflex.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.1.1/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -march=k8 -m64 -mno-red-zone -mcmodel=kernel -pipe -fno-reorder-blocks -Wno-sign-compare -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -fstack-protector -fstack-protector-all -fno-omit-frame-pointer -fno-optimize-sibling-calls -fasynchronous-unwind-tables -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(pata_triflex)" -D"KBUILD_MODNAME=KBUILD_STR(pata_triflex)" -c -o drivers/ata/.tmp_pata_triflex.o drivers/ata/pata_triflex.c gcc -Wp,-MD,drivers/ata/.ata_generic.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.1.1/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -march=k8 -m64 -mno-red-zone -mcmodel=kernel -pipe -fno-reorder-blocks -Wno-sign-compare -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -fstack-protector -fstack-protector-all -fno-omit-frame-pointer -fno-optimize-sibling-calls -fasynchronous-unwind-tables -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(ata_generic)" -D"KBUILD_MODNAME=KBUILD_STR(ata_generic)" -c -o drivers/ata/.tmp_ata_generic.o drivers/ata/ata_generic.c make -f scripts/Makefile.build obj=drivers/atm include/asm/byteorder.h:5:28: error: linux/compiler.h: No such file or directory rm -f drivers/atm/built-in.o; ar rcs drivers/atm/built-in.o gcc -Wp,-MD,drivers/atm/.zatm.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.1.1/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -march=k8 -m64 -mno-red-zone -mcmodel=kernel -pipe -fno-reorder-blocks -Wno-sign-compare -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -fstack-protector -fstack-protector-all -fno-omit-frame-pointer -fno-optimize-sibling-calls -fasynchronous-unwind-tables -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(zatm)" -D"KBUILD_MODNAME=KBUILD_STR(zatm)" -c -o drivers/atm/.tmp_zatm.o drivers/atm/zatm.c Regards, Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: la la la la ... swappiness
We want it to swap less for this particular operation because it is low priority compared to the rest of what's going on inside the box. We've considered both artificially manipulating swap on the fly similar to your suggestion as well a parallel thread that pumps a 3 into drop_caches every few seconds while the update is running, but these seem too much like hacks for our liking. Mind you, if we don't have a choice we'll do what we need to get the job done but there's a nagging voice in our conscience that says keep looking for a more elegant solution and work *with* the kernel rather than working against it or trying to trick it into doing what we want. We've already disabled OOM so we can at least keep our testing alive while searching for a more elegant solution. Although we want to avoid swap in this particular instance for this particular reason, in our hearts we agree with Andrew that swap can be your friend and get you out of a jam once in a while. Even more, we'd like to leave OOM active if we can because we want to be told when somebody's not being a good memory citizen. Some background, what we've done is carve up a huge chunk of memory that is shared between three resident processes as write cache for a proprietary block system layout that is part of a scalable storage architecture currently capable of RAID 0, 1, 5 (soon 6) virtualized across multiple chassis's, essentially treating each machine as a "disk" and providing multipath I/O to multiple iSCSI targets as part of a grid/array storage solution. Whew! We also have a version that leverages a battery backed write cache for higher performance at an additional cost. This software is installable on any commodity platform with 4-N disks supported by Linux, I've even put it on an Optiplex with 4 simulated disks. Yawn ... yet another iSCSI storage solution, but this one scales linearly in capacity as well as performance. As such, we have no user level apps on the boxes and precious little disk to spare for additional swap so our version of the swap manipulation solution is to turn swap completely off for the duration of the update. I hope I haven't muddied things up even more but basically what we want to do is find a way to limit the number of cached pages for disk I/O on the OS filesystem, even if it drastically slows down the untar and verify process because the disk I/O we really care about is not on any of the OS partitions. Louis Aucoin -Original Message- From: Tim Schmielau [mailto:[EMAIL PROTECTED] Sent: Sunday, December 03, 2006 2:47 PM To: Aucoin Cc: 'Andrew Morton'; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; [EMAIL PROTECTED] Subject: RE: la la la la ... swappiness On Sun, 3 Dec 2006, Aucoin wrote: > during tar extraction ... inactive pages reaches levels as high as ~375000 So why do you want the system to swap _less_? You need to find some free memory for the additional processes to run in, and you have lots of inactive pages, so I think you want to swap out _more_ pages. I'd suggest to temporarily add a swapfile before you update your system. This can even help in bringing your memory use to the state before if you do it like this - swapon additional swapfile - update your database software - swapoff swap partition - swapon swap partition - swapoff additional swapfile Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] introduce put_pid_rcu() to fix unsafe put_pid(vc->vt_pid)
On 12/03, Eric W. Biederman wrote: > > Oleg Nesterov <[EMAIL PROTECTED]> writes: > > > Eric, what do you think? > > Anyway with a little luck I should be working on the pid namespace and > this stuff later today so I will try and send out the proper patch. > > Not that I'm really opposed to this infrastructure but I'd like to > avoid it until we really need it. Great! please CC me :) Oleg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH? rcu_do_batch: fix a pure theoretical memory ordering race
On 12/04, Eric Dumazet wrote:
>
> Oleg Nesterov a ?crit :
> >
> > int start_me_again;
> >
> > struct rcu_head rcu_head;
> >
> > void rcu_func(struct rcu_head *rcu)
> > {
> > start_me_again = 1;
> > }
> >
> > // could be called on arbitrary CPU
> > void check_start_me_again(void)
> > {
> > static spinlock_t lock;
> >
> > spin_lock(lock);
> > if (start_me_again) {
> > start_me_again = 0;
> > call_rcu(_head, rcu_func);
> > }
> > spin_unlock(lock);
> > }
> >
> >I'd say this code is not buggy.
>
> Are you sure ? Can you prove it ? :)
Looks like you think differently :)
> I do think your rcu_func() misses some sync primitive, *after*
> start_me_again=1;
> You seem to rely on some undocumented side effect.
> Adding smp_rmb() before calling rcu_func() wont help.
I guess you mean that check_start_me_again() can miss start_me_again != 0 ?
Yes, of course, it should check the condition from time to time. We can even
do
start_me_again = 1;
wake_up(_me_again_wq);
, this is still unsafe.
> >>A smp_rmb() wont avoid all possible bugs...
> >
> >For example?
>
> A smp_rmb() wont avoid stores pending on this CPU to be committed to memory
> after another cpu takes the object for itself. Those stores could overwrite
> stores done by the other cpu as well.
Yes. But RCU core doesn't write to rcu_head (except call_rcu). Callback _owns_
rcu_head, it should be ok to use it in any way without fear to break RCU.
Of course, callback should take care of its own locking/ordering.
> So in theory you could design a buggy callback function even after your
> patch applied.
So. Do you claim that rcu_func() above is buggy?
> Any function that can transfer an object from CPU A scope to CPU B scope
> must take care of memory barrier by itself. The caller *cannot* possibly do
> the job, especially if it used an indirect call. However, in some cases it
> is possible some clever algos are doing the reverse, ie doing the memory
> barrier in the callers.
>
> Kernel is full of such constructs :
>
> for (ptr = head; ptr != NULL ; ptr = next) {
> next = ptr->next;
> some_subsys_delete(ptr);
> }
>
> And we dont need to add smp_rmb() before the call to some_subsys_delete(),
> it would be a nightmare, and would slow down modern cpus.
Agreed.
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: why can't I remove a kernel module (or: what uses a given module)?
On 12/03/06 08:59:10PM +0100, Tomasz Chmielewski wrote: > Ross Vandegrift wrote: > >On Sun, Dec 03, 2006 at 12:58:24PM +0100, Tomasz Chmielewski wrote: > >>You mean the "Used by" column? No, it's not used by any other module > >>according to lsmod output. > >> > >>Any other methods of checking what uses /dev/sda*? > > > >There's a good chance that if it was loaded at system boot, hald or > >udev may be doing something with it. > > This machine doesn't have hal; when I kill udevd still doesn't help. > > Yes, something's using that drive, be it a program, a module (unlikely), > or something that is compiled directly in the kernel (for example, > md/raid1). > But what is it? > > Kernel knows it, as it refuses to remove the module (via rmmod), but how > to tell kernel to share this knowledge with me? > Have you checked to make sure there's no swap partitions on it being automatically activated at boot? Also, have you checked the output of lsof? Jim. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pata_via report
On Sunday 03 December 2006 21:36, Rudolf Marek wrote: > Hello Alan, > > I would like to report my experience with new pata_via driver. > > Short version: works (no data were trashed, during the investigation), but > the bits to detect the cable type are not set by BIOS. > There is also a bug in my BIOS, which kills the UDMA register. I have the same motherboard, but no SATA drives. I use the pata_via driver for a couple of months now and experienced no problems so far. now running 2.6.19-rc6-mm2 > Long version: > I have 80pin cable on primary master with western digital drive on it as > slave. No other device on primary master. Secondary master is NEC DVDRW. I > have two SATA drives, from which I boot the system. > > ata3: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xCC00 irq 14 > ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xCC08 irq 15 > scsi2 : pata_via > DEBUG ATA66: 0x07e1e607 > ATA: abnormal status 0x8 on port 0x1F7 > ATA: abnormal status 0x8 on port 0x1F7 1 Maxtor 6Y080P0 on primary IDE and 2 optical drives on secundary IDE (DVD-RW master, CD-RW slave). all are connected with 80pin cables: libata version 2.00 loaded. pata_via :00:0f.1: version 0.2.0 ata1: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xFC00 irq 14 ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xFC08 irq 15 scsi0 : pata_via ata1.00: ATA-7, max UDMA/133, 160086528 sectors: LBA ata1.00: ata1: dev 0 multi count 16 ata1.00: configured for UDMA/133 scsi1 : pata_via ata2.00: ATAPI, max UDMA/66 ata2.01: ATAPI, max UDMA/33 ata2.00: configured for UDMA/66 ata2.01: configured for UDMA/33 so as you can see, 80pin cable detection works for me. > 00:0f.1 IDE interface: VIA Technologies, Inc. > VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) > 00: 06 11 71 05 07 00 90 02 06 8a 01 01 00 20 00 00 > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 01 cc 00 00 00 00 00 00 00 00 00 00 43 10 ed 80 > 30: 00 00 00 00 c0 00 00 00 00 00 00 00 02 01 00 00 > 40: 3b f2 09 05 18 8c c0 00 5d 20 5d 20 ff 00 20 20 > 50: 07 e6 07 e1 0c 00 00 00 a8 a8 a8 a8 00 00 00 00 > 60: 00 02 00 00 00 00 00 00 00 02 00 00 00 00 00 00 > 70: 02 01 00 00 00 00 00 00 02 01 00 00 00 00 00 00 > 80: 00 a0 b9 3f 00 00 00 00 00 50 b2 3f 00 00 00 00 > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 06 00 71 05 43 10 ed 80 00 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 09 00 00 00 00 00 00 00 00 00 hexdump of my config space is different: 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00: 06 11 71 05 07 00 90 02 06 8a 01 01 00 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 fc 00 00 00 00 00 00 00 00 00 00 43 10 ed 80 30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 01 00 00 40: 3b f2 09 05 18 8c c0 00 20 20 a8 20 ff 00 20 20 50: e6 e2 17 e0 0c 00 00 00 a8 a8 a8 a8 00 00 00 00 60: 00 02 00 00 00 00 00 00 00 02 00 00 00 00 00 00 70: 02 01 00 00 00 00 00 00 02 01 00 00 00 00 00 00 80: 00 d0 63 3f 00 00 00 00 00 b0 63 3f 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 06 00 71 05 43 10 ed 80 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 09 00 00 00 00 00 00 00 00 00 hope this helps. Rudmer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device naming randomness (udev?)
On Sun, Dec 03, 2006 at 02:39:44PM -0800, Martin J. Bligh wrote: > This PC has 1 ethernet interface, an e1000. Ubuntu Dapper. > > On 2.6.14, my e1000 interface appears as eth0. > On 2.6.15 to 2.6.18, my e1000 interface appears as eth1. > > In both cases, there are no other ethX interfaces listed in > "ifconfig -a". There are no modules involved, just a static > kernel build. > > Is this a bug in udev, or the kernel? I'm presuming udev, > but seems odd it changes over a kernel release boundary. > Any ideas on how I get rid of it? Makes automatic switching > between kernel versions a royal pain in the ass. Have a look at /etc/iftab. Yours Tony linux.conf.au http://linux.conf.au/ || http://lca2007.linux.org.au/ Jan 15-20 2007 The Australian Linux Technical Conference! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] introduce put_pid_rcu() to fix unsafe put_pid(vc->vt_pid)
Oleg Nesterov <[EMAIL PROTECTED]> writes: >> task_struct* or something? > > I don't think this is good. It was converted from task_struct* to pid*. > > Eric, what do you think? I think I have a fix that uses the proper locking sitting in my queue that I haven't pushed because I have been got to look at just about every irq but present in 2.6.19-rcX. Then for some reason I had this stupid usb debug cable sitting on my desk and since I can't stand useful things going unused I just wrote a driver for that :) Anyway with a little luck I should be working on the pid namespace and this stuff later today so I will try and send out the proper patch. Not that I'm really opposed to this infrastructure but I'd like to avoid it until we really need it. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] timers, pointers to functions and type safety
On Sun 2006-12-03 23:52:54, Roman Zippel wrote: > Hi, > > On Sun, 3 Dec 2006, Pavel Machek wrote: > > > > What exactly is the pita here? Al only came up with some rather > > > theoretical problems with no practical relevance. > > > > Lack of type-checking in timers is ugly. > > It's a matter of perspective, a bit more type checking would be nice, but > breaking the API just for that is ugly as well. Unless there is a bad need > for it, I don't think it's worth it... I do not think Al is breaking anything. He's adding that typechecking, old interface can still stay for a while. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device naming randomness (udev?)
On 2006.12.03 14:39:44 -0800, Martin J. Bligh wrote: > This PC has 1 ethernet interface, an e1000. Ubuntu Dapper. > > On 2.6.14, my e1000 interface appears as eth0. > On 2.6.15 to 2.6.18, my e1000 interface appears as eth1. > > In both cases, there are no other ethX interfaces listed in > "ifconfig -a". There are no modules involved, just a static > kernel build. > > Is this a bug in udev, or the kernel? I'm presuming udev, > but seems odd it changes over a kernel release boundary. > Any ideas on how I get rid of it? Makes automatic switching > between kernel versions a royal pain in the ass. Just a wild guess here... Debian's (and I guess Ubuntu's) udev rules contain a generator for persistent interface name rules. Maybe these start working with 2.6.15 and thus the switch (ie. the kernel would call it eth0, but udev renames it to eth1). The generated rules are written to /etc/udev/rules.d/z25_persistent-net.rules on Debian, not sure if its the same for Ubuntu. Editing/removing the rules should fix your problem. HTH Björn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH? rcu_do_batch: fix a pure theoretical memory ordering race
Oleg Nesterov a écrit :
On 12/03, Eric Dumazet wrote:
Oleg Nesterov a ?crit :
Yes, but how is it related to RCU ?
I mean, rcu_do_batch() is just a loop like others in kernel.
The loop itself is not buggy, but can call a buggy function, you are right.
int start_me_again;
struct rcu_head rcu_head;
void rcu_func(struct rcu_head *rcu)
{
start_me_again = 1;
}
// could be called on arbitrary CPU
void check_start_me_again(void)
{
static spinlock_t lock;
spin_lock(lock);
if (start_me_again) {
start_me_again = 0;
call_rcu(_head, rcu_func);
}
spin_unlock(lock);
}
I'd say this code is not buggy.
Are you sure ? Can you prove it ? :)
I do think your rcu_func() misses some sync primitive, *after* start_me_again=1;
You seem to rely on some undocumented side effect.
Adding smp_rmb() before calling rcu_func() wont help.
In case it was not clear. I do not claim we need this patch (I don't know).
And yes, I very much doubt we can hit this problem in practice (even if I am
right).
What I don't agree with is that it is callback which should take care of this
problem.
A smp_rmb() wont avoid all possible bugs...
For example?
A smp_rmb() wont avoid stores pending on this CPU to be committed to memory
after another cpu takes the object for itself. Those stores could overwrite
stores done by the other cpu as well.
So in theory you could design a buggy callback function even after your patch
applied.
Any function that can transfer an object from CPU A scope to CPU B scope must
take care of memory barrier by itself. The caller *cannot* possibly do the
job, especially if it used an indirect call. However, in some cases it is
possible some clever algos are doing the reverse, ie doing the memory barrier
in the callers.
Kernel is full of such constructs :
for (ptr = head; ptr != NULL ; ptr = next) {
next = ptr->next;
some_subsys_delete(ptr);
}
And we dont need to add smp_rmb() before the call to some_subsys_delete(), it
would be a nightmare, and would slow down modern cpus.
When the callback function dont need a memory barrier, why should we force a
generic one in the caller ?
AFAIK most kfree() calls dont need a barrier, since slab just queue the
pointer into the cpu's array_cache if there is one available slot.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device
Peter Stuge <[EMAIL PROTECTED]> writes: > On Fri, Dec 01, 2006 at 04:02:03PM -0700, Eric W. Biederman wrote: >> >> Sure, I will send it out shortly. I currently have a working >> >> user space libusb thing (easy, but useful for my debug) >> > >> > Hm - for driving which end? >> >> Either. The specific device we are talking about doesn't care. > > Which device do you have? Well it is built by PLX, and from lsusb I see are: 0525:127a Netchip Technology, Inc. The hardware is a little rectangular pcb board a little smaller then a business card. Wrapped in a blue case, with vertical vents on both of the long sides, and gets a little warm when you have been running it for a while. The device has what appears to be 2 normal host to slave cables running into it. The picture at the bottom of: http://advdbg.org/blogs/advdbg_system/articles/64.aspx Looks like what I have. I'm curious about the whole plug both ends into the host before plugging it into the client, and about the strange target system BIOS requirements. I think I succeeded in making it work without out that by just putting in a reset. It does make the whole setup of the device a pain though. >> > The debug port isn't really supposed to be used with anything but >> > a debug device - which can't be enumerated normally anyway. >> >> It depends. If you have a debug cable with magic ends and a >> hardcoded address of 127 the normal enumeration doesn't work. I >> don't think anyone actually makes one of those. > > Only one of the ports on Stefan's PLX NET20DC that I had a look at > during the LinuxBIOS symposium enumerated for me. Very odd. I'm pretty certain we are talking same thing. But I do know it has a couple of weird quirks, so maybe you just ran up against that. >> Debug devices are also allowed to be normal devices that just >> support the debug descriptor. Which is what I'm working with. > > Aye. I would be happy if we could get something out, as you have > done! :) Looking forward to trying it, I hope I get my device soon. Well at least this means after it works I can probably forget about it and let someone else maintain the code ;) Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib: Convert kmalloc()+memset() to kzalloc()
On Sun, 3 Dec 2006 11:35:49 -0500 (EST) "Robert P. J. Day" <[EMAIL PROTECTED]> wrote: > > Convert the single obvious instance in lib/ of kmalloc() + memset() > to kzalloc(). > > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> Acked-by: Alan Cox <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] timers, pointers to functions and type safety
Hi, On Sun, 3 Dec 2006, Pavel Machek wrote: > > What exactly is the pita here? Al only came up with some rather > > theoretical problems with no practical relevance. > > Lack of type-checking in timers is ugly. It's a matter of perspective, a bit more type checking would be nice, but breaking the API just for that is ugly as well. Unless there is a bad need for it, I don't think it's worth it... bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Device naming randomness (udev?)
This PC has 1 ethernet interface, an e1000. Ubuntu Dapper. On 2.6.14, my e1000 interface appears as eth0. On 2.6.15 to 2.6.18, my e1000 interface appears as eth1. In both cases, there are no other ethX interfaces listed in "ifconfig -a". There are no modules involved, just a static kernel build. Is this a bug in udev, or the kernel? I'm presuming udev, but seems odd it changes over a kernel release boundary. Any ideas on how I get rid of it? Makes automatic switching between kernel versions a royal pain in the ass. M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Cluster-devel] Re: [GFS2] Change argument of gfs2_dinode_out [17/70]
> The right thing would have been to no put in gfs2 too early. According > to you it's unstable. I would note that Russell is expressing his own slightly odd view not a company one, nor afaik the view of any of the mainstream GFS2 team. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-git3 panics on boot - ata_piix/PCI related
On 12/3/06, Alan <[EMAIL PROTECTED]> wrote: > > ACPI: PCI Interrupt :00:1f.2[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ5 > > PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device :00:1f.2 > > ata_piix: probe of :00:1f.2 failed with error -16 > > [snip] > > mount: could not find filesystem '/dev/root' > > Same failure is also in 2.6.19-git4... Thats the PCI updates - you need the matching fix to libata-sff where it tries to reserve stuff it shouldn't. Thanks Alan. Indeed -git1 is where stuff breaks for me. I'll watch out for when libata-sff gets fixed in the -git snapshots and will then report back. --alessandro "...when I get it, I _get_ it" (Lara Eidemiller) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-git3 panics on boot - ata_piix/PCI related
> > ACPI: PCI Interrupt :00:1f.2[B] -> Link [LNKB] -> GSI 5 (level, low) -> > > IRQ5 > > PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device > > :00:1f.2 > > ata_piix: probe of :00:1f.2 failed with error -16 > > [snip] > > mount: could not find filesystem '/dev/root' > > Same failure is also in 2.6.19-git4... Thats the PCI updates - you need the matching fix to libata-sff where it tries to reserve stuff it shouldn't. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
rfkill with the fixes as suggested by Arjan.
- instead of a semaphore a mutex is now being used.
- open_count changing is now locked by the mutex.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ba0e88c..6986d59 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,19 @@ config HP_SDC_RTC
Say Y here if you want to support the built-in real time clock
of the HP SDC controller.
+config RFKILL
+ tristate "RF button support"
+ help
+ If you say yes here, the rfkill driver will be build
+ which allowed network devices to register their hardware
+ RF button which controls the radio state. This driver
+ will then create an input device for it.
+
+ When the input device is not used, the rfkill driver
+ will make sure that when the RF button is pressed the radio
+ is enabled or disabled accordingly. When the input device
+ has been opened by the user this radio control will be left
+ to the user, and rfkill will only send the RF button status
+ change to userspace.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e788a1b 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
+obj-$(CONFIG_RFKILL) += rfkill.o
diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
new file mode 100644
index 000..4777d73
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,887 @@
+/*
+ Copyright (C) 2006 Ivo van Doorn
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("Ivo van Doorn <[EMAIL PROTECTED]>");
+MODULE_VERSION("1.0");
+MODULE_DESCRIPTION("RF key support");
+MODULE_LICENSE("GPL");
+
+/*
+ * rfkill key structure.
+ */
+struct rfkill_key {
+ /*
+* For sysfs representation.
+*/
+ struct class_device *cdev;
+
+ /*
+* Pointer to rfkill structure
+* that was filled in by key driver.
+*/
+ struct rfkill *rfkill;
+
+ /*
+* Pointer to type structure that this key belongs to.
+*/
+ struct rfkill_type *type;
+
+ /*
+* Once key status change has been detected, the toggled
+* field should be set to indicate a notification to
+* user or driver should be performed.
+*/
+ int toggled;
+
+ /*
+* Current state of the device radio, this state will
+* change after the radio has actually been toggled since
+* receiving the radio key event.
+*/
+ int radio_status;
+
+ /*
+* Current status of the key which controls the radio,
+* this value will change after the key state has changed
+* after polling, or the key driver has send the new state
+* manually.
+*/
+ int key_status;
+
+ /*
+* Input device for this key,
+* we also keep track of the number of
+* times this input device is open. This
+* is important for determining to whom we
+* should report key events.
+*/
+ struct input_dev *input;
+ unsigned int open_count;
+
+ /*
+* Key index number.
+*/
+ unsigned int key_index;
+
+ /*
+* List head structure to be used
+* to add this structure to the list.
+*/
+ struct list_head entry;
+};
+
+/*
+ * rfkill key type structure.
+ */
+struct rfkill_type {
+ /*
+* For sysfs representation.
+*/
+ struct class_device *cdev;
+
+ /*
+* Name of this radio type.
+*/
+ char *name;
+
+ /*
+* Key type identification. Value must be any
+* in the key_type enum.
+*/
+ unsigned int key_type;
+
+ /*
+* Number of
Re: [linux-usb-devel] [GIT PATCH] USB patches for 2.6.19
On Sun, 3 Dec 2006, Marcel Holtmann wrote: > about the USBHID part. Jiri Kosina is just about to finally split the > HID parser and make it available for Bluetooth and USB as an independent > subsystem. This might conflict with any autosuspend changes for the > USBHID. It might be better that this waits until Jiri's patches are > merged. Yup, thanks, I think so. Just for the record - I am planning to push these patches just after 2.6.20-rc1 either to Andrew or Greg. Thanks, -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ppc: cs4218_tdm remove extra brace
old-2.6-bkcvs says this trivial compile error was introduced by:
commit 196819fdfaf3b38965f9dade80a19fdc6225120a
Author: akpm
Date: Tue Nov 5 22:54:51 2002 +
[PATCH] initialize timers under arch/
This completes the kernel-wide audit.
Considering that noone seems to have tried to compile this driver during
the last 4 years, are there any objections against removing it?
cu
Adrian
On Thu, Nov 30, 2006 at 01:48:58PM +0100, Mariusz Kozlowski wrote:
> Hello,
>
> I tried to find where does this line come from. Googled a bit with
> no luck. Probably somewhere between 2.5.10 and 2.5.20 some patch generated
> this leftover.
>
>
> static struct timer_list beep_timer = {
> function: cs_nosound
> };
>
> changed to:
>
> static struct timer_list beep_timer = TIMER_INITIALIZER(cs_nosound, 0, 0);
> };
>
>
> The patch below removes this extra line.
>
> Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
>
> arch/ppc/8xx_io/cs4218_tdm.c |1 -
> 1 file changed, 1 deletion(-)
>
> --- linux-2.6.19-rc6-mm2-a/arch/ppc/8xx_io/cs4218_tdm.c 2006-11-28
> 12:16:29.0 +0100
> +++ linux-2.6.19-rc6-mm2-b/arch/ppc/8xx_io/cs4218_tdm.c 2006-11-29
> 16:12:22.0 +0100
> @@ -1379,7 +1379,6 @@ static void cs_nosound(unsigned long xx)
> }
>
> static DEFINE_TIMER(beep_timer, cs_nosound, 0, 0);
> -};
>
> static void cs_mksound(unsigned int hz, unsigned int ticks)
> {
>
>
> --
> Regards,
>
> Mariusz Kozlowski
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] rfkill - Add support for input key to control wireless radio
Hi, > > This patch is a resend of a patch I has been send to the linux kernel > > and netdev list earlier. The most recent version of a few weeks back > > didn't compile since I missed 1 line in my patch that changed > > include/linux/input.h. > > > > This patch will offer the handling of radiokeys on a laptop. > > Such keys often control the wireless devices on the radio > > like the wifi, bluetooth and irda. > > Ok, what was the conclusion on the following issues? > > 1) What about rfkill keys that aren't routed via software? There are > two modes here: (a) the key is not hardwired to the module and the > driver is responsible for disabling the radio, (b) the key is hardwired > to the module and firmware or some other mechanism disables the radio > without driver interaction. I thought I'd heard of some (b) hardware, > mostly on older laptops, but does anyone know how prevalent (b) hardware > is? If there isn't any, do we care about it for now? On condition a) The driver is supposed to read the button status by the method provided by the device. (i.e. reading the register) the rfkill will periodically poll the driver (if the polling method has been provided by the driver) and the rfkill will do its work when the status of the register has changed. With the input device open, the user can listen to the events and switch off the radio manually (by using a tool like ifconfig or through the sysfs field) When the input device is not open, rfkill will use the driver provided callback functions to enable or disable the radio. b) In this case an interrupt is usually send to the driver about the event, or still the register will be possible. On both occassions the signal can still be caught by rfkill and handled further. If the event is send to userspace so the user can still perform tasks, the user can however not use the sysfs field to change the radio status since it is only allowed to switch the radio to the status that the button indicates. But the user can still perform tasks that should be handled (like stopping programs that need the network). I have heard that the broadcom chipsets toggle the radio state without intervention of the driver, and instead only send an interrupt event. > 2) Is there hardware that has separate keys for separate radios? i.e., > one key for Bluetooth, and one key for WiFi? I know Bastien has a > laptop where the same rfkill key handles _both_ ipw2200 and the BT > module, but in different ways: it actually removes the BT USB device > from the USB bus, but uses the normal ipw rfkill mechanism. Don't know about this hardware, my laptop has 2 seperate buttons for wifi and bluetooth. But it would be quite hard to caught such events cleanly, in this case the option would be to register 2 seperate rfkill_key structures. That way the key is represented twice to the user. But the enable_radio and disable _radio callback functions from the driver would make the callback for the wifi and bluetooth radio individually possibly. > 3) How does this interact with HAL? What's the userspace interface that > HAL will listen to to receive the signals? NetworkManager will need to > listen to HAL for these, as rfkill switches are one big thing that NM > does not handle now due to lack of a standard mechanism. In userspace there are 2 ways to listen, either regularly check the sysfs entry for the status. Or the prefered way listen to the input device that is created for each key. > In any case, any movement on rfkill interface/handling standardization > is quite welcome :) True, there are currently a lot of methods floating around. And a single way to notify the user would be a nice idea. :) Ivo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Kbuild: add 3 more header files to get properly "unifdef"ed
On Thu, Nov 30, 2006 at 05:03:56AM -0500, Robert P. J. Day wrote: > > Add 3 more files to get "unifdef"ed when creating sanitized headers > with "make headers_install". Your patch should also remove them from header-y. > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> > > --- > > diff --git a/include/linux/Kbuild b/include/linux/Kbuild > index a1155a2..b6bc50c 100644 > --- a/include/linux/Kbuild > +++ b/include/linux/Kbuild > @@ -225,6 +225,7 @@ unifdef-y += if_bridge.h > unifdef-y += if_ec.h > unifdef-y += if_eql.h > unifdef-y += if_ether.h > +unifdef-y += if_fddi.h > unifdef-y += if_frad.h > unifdef-y += if_ltalk.h > unifdef-y += if_pppox.h > @@ -286,6 +287,7 @@ unifdef-y += nvram.h > unifdef-y += parport.h > unifdef-y += patchkey.h > unifdef-y += pci.h > +unifdef-y += personality.h > unifdef-y += pktcdvd.h > unifdef-y += pmu.h > unifdef-y += poll.h > @@ -341,6 +343,7 @@ unifdef-y += videodev.h > unifdef-y += wait.h > unifdef-y += wanrouter.h > unifdef-y += watchdog.h > +unifdef-y += wireless.h > unifdef-y += xfrm.h > unifdef-y += zftape.h cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH? rcu_do_batch: fix a pure theoretical memory ordering race
On 12/03, Eric Dumazet wrote:
>
> Oleg Nesterov a ?crit :
>
> Yes, but how is it related to RCU ?
> I mean, rcu_do_batch() is just a loop like others in kernel.
> The loop itself is not buggy, but can call a buggy function, you are right.
int start_me_again;
struct rcu_head rcu_head;
void rcu_func(struct rcu_head *rcu)
{
start_me_again = 1;
}
// could be called on arbitrary CPU
void check_start_me_again(void)
{
static spinlock_t lock;
spin_lock(lock);
if (start_me_again) {
start_me_again = 0;
call_rcu(_head, rcu_func);
}
spin_unlock(lock);
}
I'd say this code is not buggy.
In case it was not clear. I do not claim we need this patch (I don't know).
And yes, I very much doubt we can hit this problem in practice (even if I am
right).
What I don't agree with is that it is callback which should take care of this
problem.
> A smp_rmb() wont avoid all possible bugs...
For example?
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Sunday 03 December 2006 20:20, Arjan van de Ven wrote: > this open_count thing smells fishy to me; what are the locking rules for > it? What guarantees that the readers of it don't get the value changed > underneath them between looking at the value and doing whatever action > depends on it's value ? Good point, a race condition could indeed occur in the only reader that sends the signal to the userspace through the input device. I'll fix this immediately. Thanks, Ivo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] rfkill - Add support for input key to control wireless radio
On Sunday 03 December 2006 20:18, Arjan van de Ven wrote: > On Sun, 2006-12-03 at 19:36 +0100, Ivo van Doorn wrote: > > + > > + down(>key_sem); > > + > > Hi, > > this one seems to be used as a mutex only, please consider using a mutex > instead, as is the default for new code since 2.6.16 or so It was indeed intended to be a mutex, I had however missed the presence of the mutex header in the kernel. Will fix this immediately. Thanks, Ivo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.19 git 2b5f6dcce...: current_is_keventd() AWOL?
Trying to compile that kernel on i686 the build fails in drivers/net/phy/libphy.ko (drivers/net/phy/phy.c, line 590) due to current_is_keventd() missing. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/12] IPMI: Fix device model name
On Fri, 1 Dec 2006 22:20:53 -0600
Corey Minyard <[EMAIL PROTECTED]> wrote:
>
> This patch adds the product id to the driver model platform device
> name, in addition to the device id. The IPMI spec does not require
> that individual BMCs in a system have unique devices IDs, but it
> does require that the product id/device id combination be unique.
>
> This also removes a redundant check and cleans up error handling
> when the sysfs registration fails.
>
> Signed-off-by: Corey Minyard <[EMAIL PROTECTED]>
> Cc: Carol Hebert <[EMAIL PROTECTED]>
>
> Index: linux-2.6.19/drivers/char/ipmi/ipmi_msghandler.c
> ===
> --- linux-2.6.19.orig/drivers/char/ipmi/ipmi_msghandler.c
> +++ linux-2.6.19/drivers/char/ipmi/ipmi_msghandler.c
> @@ -1817,13 +1817,12 @@ static int __find_bmc_prod_dev_id(struct
> struct bmc_device *bmc = dev_get_drvdata(dev);
>
> return (bmc->id.product_id == id->product_id
> - && bmc->id.product_id == id->product_id
> && bmc->id.device_id == id->device_id);
> }
>
> static struct bmc_device *ipmi_find_bmc_prod_dev_id(
> struct device_driver *drv,
> - unsigned char product_id, unsigned char device_id)
> + unsigned int product_id, unsigned char device_id)
> {
> struct prod_dev_id id = {
> .product_id = product_id,
> @@ -1940,6 +1939,9 @@ static ssize_t guid_show(struct device *
>
> static void remove_files(struct bmc_device *bmc)
> {
> + if (!bmc->dev)
> + return;
> +
> device_remove_file(>dev->dev,
> >device_id_attr);
> device_remove_file(>dev->dev,
> @@ -1973,7 +1975,8 @@ cleanup_bmc_device(struct kref *ref)
> bmc = container_of(ref, struct bmc_device, refcount);
>
> remove_files(bmc);
> - platform_device_unregister(bmc->dev);
> + if (bmc->dev)
> + platform_device_unregister(bmc->dev);
platform_device_unregister(NULL) appears to be legal.
> kfree(bmc);
> }
>
> @@ -1990,6 +1993,7 @@ static void ipmi_bmc_unregister(ipmi_smi
>
> mutex_lock(_mutex);
> kref_put(>refcount, cleanup_bmc_device);
> + intf->bmc = NULL;
> mutex_unlock(_mutex);
> }
>
> ...
>
> } else {
> - bmc->dev = platform_device_alloc("ipmi_bmc",
> - bmc->id.device_id);
> + char name[14];
> + unsigned char orig_dev_id = bmc->id.device_id;
> + int warn_printed = 0;
> +
> + snprintf(name, sizeof(name),
> + "ipmi_bmc.%4.4x", bmc->id.product_id);
> +
> + while (ipmi_find_bmc_prod_dev_id(,
> + bmc->id.product_id,
> + bmc->id.device_id))
> + {
The brace should be on the previous line.
> + if (!warn_printed) {
> + printk(KERN_WARNING PFX
> +"This machine has two different BMCs"
> +" with the same product id and device"
> +" id. This is an error in the"
> +" firmware, but incrementing the"
> +" device id to work around the problem."
> +" Prod ID = 0x%x, Dev ID = 0x%x\n",
> +bmc->id.product_id, bmc->id.device_id);
> + warn_printed = 1;
Perhaps warn_printed should be static
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] PM: suspend/resume debugging should depend on SOFTWARE_SUSPEND
On Nov 19, 2006, at 17:04:23, Christer Weinigel wrote: With suspend-to-disk I can remove the battery (to put in a fresh battery when traveling), try doing that with suspend-to-ram. My PowerBook can do this with suspend-to-ram too; it has an internal capacitor or battery of some sort which charges in a few minutes and holds enough power to keep the RAM alive for around a minute while I swap batteries. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] introduce put_pid_rcu() to fix unsafe put_pid(vc->vt_pid)
On 12/03, Andrew Morton wrote: > > On Sat, 2 Dec 2006 02:48:26 +0300 > Oleg Nesterov <[EMAIL PROTECTED]> wrote: > > > drivers/char/vt_ioctl.c changes vc->vt_pid doing > > > > put_pid(xchg(>vt_pid, ...)); > > > > This is unsafe, put_pid() can actually free the memory while vc->vt_pid is > > still used by kill_pid(vc->vt_pid). > > > > Add a new helper, put_pid_rcu(), which frees "struct pid" via rcu callback > > and convert vt_ioctl.c to use it. > > > > > I'm a bit reluctant to go adding more tricky infrastructure (especially > 100% undocumented infrastructure) on behalf of a single usage site in a > place as creepy as the VT ioctl code. > If we envisage future users of this infrastructure (and if it gets > documented) then OK. It is a shame we can't use "struct pid*" lockless, note that "struct pid" itself is rcu-protected. I hope we can find another usage for put_pid_rcu (in fact I suggested it before, but didn't have a reason). However, I don't see any other example immediately. > Otherwise I'd rather just stick another bandaid into > the vt code. Can we add some locking there, Yes, this is possible, and probably we should do just this. > or change it to use a > task_struct* or something? I don't think this is good. It was converted from task_struct* to pid*. Eric, what do you think? Oleg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-git3 panics on boot - ata_piix/PCI related
On 12/3/06, Alessandro Suardi <[EMAIL PROTECTED]> wrote: FC6-latest running on a Latitude D610, SATA hard disk; 2.6.19 is okay, kernel built with oldconfig from the known-working setup fails to boot not recognizing the root partition, which is due to ata_piix not loading due to a PCI I/O reserve error. Happens both with and without CONFIG_SYSFS_DEPRECATED (I first had it to N then thought it might have had something to do with the boot error so I rebuilt with Y - no change). Messages hand-copied from the screen on the 2nd try: Loading ata_piix.ko module ata_piix :00:1f.2: MAP [ P0 P2 IDE IDE ] ACPI: PCI Interrupt :00:1f.2[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ5 PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device :00:1f.2 ata_piix: probe of :00:1f.2 failed with error -16 [snip] mount: could not find filesystem '/dev/root' Same failure is also in 2.6.19-git4... I'll download -git1 and -git2 to see which one broke my setup first. This is what is in the dmesg ring of 2.6.19: ata_piix :00:1f.2: version 2.00ac6 ata_piix :00:1f.2: MAP [ P0 P2 IDE IDE ] ACPI: PCI Interrupt :00:1f.2[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5 PCI: Setting latency timer of device :00:1f.2 to 64 ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xBFA0 irq 14 ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xBFA8 irq 15 scsi0 : ata_piix ata1.00: ATA-6, max UDMA/100, 117210240 sectors: LBA ata1.00: ata1: dev 0 multi count 8 ata1.00: applying bridge limits ata1.00: configured for UDMA/100 scsi1 : ata_piix ata2.00: ATAPI, max UDMA/33 ata2.00: configured for UDMA/33 --alessandro "...when I get it, I _get_ it" (Lara Eidemiller) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 8/12] IPMI: system interface hotplug
On Fri, 1 Dec 2006 22:36:55 -0600
Corey Minyard <[EMAIL PROTECTED]> wrote:
>
> Add the ability to hot add and remove interfaces in the ipmi_si
> driver. Any users who have the device open will get errors if they
> try to send a message.
>
> ...
>
> +static int ipmi_strcasecmp(const char *s1, const char *s2)
> +{
> + while (*s1 || *s2) {
> + if (!*s1)
> + return -1;
> + if (!*s2)
> + return 1;
> + if (*s1 != *s2)
> + return *s1 - *s2;
> + s1++;
> + s2++;
> + }
> + return 0;
> +}
Please put a newline between functions.
> +static int parse_str(struct hotmod_vals *v, int *val, char *name, char
> **curr)
> +{
> + char *s;
> + int i;
> +
> + s = strchr(*curr, ',');
> + if (!s) {
> + printk(KERN_WARNING PFX "No hotmod %s given.\n", name);
> + return -EINVAL;
> + }
> + *s = '\0';
> + s++;
> + for (i = 0; hotmod_ops[i].name; i++) {
> + if (ipmi_strcasecmp(*curr, v[i].name) == 0) {
> + *val = v[i].val;
> + *curr = s;
> + return 0;
> + }
> + }
> +
> + printk(KERN_WARNING PFX "Invalid hotmod %s '%s'\n", name, *curr);
> + return -EINVAL;
> +}
Does this driver really need case-insensitive string comparision?
That doesn't look like a case-insensitive string compare to me. What's up?
> ...
>
> + while (s) {
> + curr = s;
> + s = strchr(curr, ',');
> + if (s) {
> + *s = '\0';
> + s++;
> + }
> + o = strchr(curr, '=');
> + if (o) {
> + *o = '\0';
> + o++;
> + }
> +#define HOTMOD_INT_OPT(name, val) \
> + if (ipmi_strcasecmp(curr, name) == 0) { \
> + if (!o) { \
> + printk(KERN_WARNING PFX \
> +"No option given for '%s'\n", \
> + curr); \
> + goto out; \
> + } \
> + val = simple_strtoul(o, , 0); \
> + if ((*n != '\0') || (*o == '\0')) { \
> + printk(KERN_WARNING PFX \
> +"Bad option given for '%s'\n", \
> +curr); \
> + goto out; \
> + } \
> + }
> +
> + HOTMOD_INT_OPT("rsp", regspacing)
> + else HOTMOD_INT_OPT("rsi", regsize)
> + else HOTMOD_INT_OPT("rsh", regshift)
> + else HOTMOD_INT_OPT("irq", irq)
> + else HOTMOD_INT_OPT("ipmb", ipmb)
oh yuk. Can't this be done via a function or something?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 9/12] IPMI: add pigeonpoint poweroff
On Fri, 1 Dec 2006 22:37:46 -0600 Corey Minyard <[EMAIL PROTECTED]> wrote: > +static void (*atca_oem_poweroff_hook)(ipmi_user_t user) = NULL; Sometime, please go through the IPMI code looking for all these statically-allocated things which are initialised to 0 or NULL and remove all those intialisations? They're unneeded, they increase the vmlinux image size and there are quite a number of them. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 11/12] IPMI: Fix BT long busy
On Fri, 1 Dec 2006 22:39:21 -0600
Corey Minyard <[EMAIL PROTECTED]> wrote:
>
> The IPMI BT subdriver has been patched to survive "long busy"
> timeouts seen during firmware upgrades and resets. The patch
> never returns the HOSED state, synthesizes response messages with
> meaningful completion codes, and recovers gracefully when the
> hardware finishes the long busy. The subdriver now issues a "Get BT
> Capabilities" command and properly uses those results.
> More informative completion codes are returned on error from
> transaction starts; this logic was propogated to the KCS and
> SMIC subdrivers. Finally, indent and other style quirks were
> normalized.
>
> ...
>
> + BT_CONTROL(BT_CLR_WR_PTR); /* always reset */
argh.
#define BT_STATUS bt->io->inputb(bt->io, 0)
#define BT_CONTROL(x) bt->io->outputb(bt->io, 0, x)
#define BMC2HOSTbt->io->inputb(bt->io, 1)
#define HOST2BMC(x) bt->io->outputb(bt->io, 1, x)
#define BT_INTMASK_Rbt->io->inputb(bt->io, 2)
#define BT_INTMASK_W(x) bt->io->outputb(bt->io, 2, x)
Please don't write macros which require that the caller have a particular
local variable of a particular name.
In fact, please don't write macros.
All the above would be perfectly nice as
static inline void bt_control(struct si_sm_data *bt, int val)
{
bt->io->outputb(bt->io, val);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 7/12] IPMI: add poll delay
On Fri, 1 Dec 2006 22:35:20 -0600
Corey Minyard <[EMAIL PROTECTED]> wrote:
> Make sure to delay a little in the IPMI poll routine so we can pass in
> a timeout time and thus time things out.
>
> Signed-off-by: Corey Minyard <[EMAIL PROTECTED]>
>
> Index: linux-2.6.19-rc6/drivers/char/ipmi/ipmi_si_intf.c
> ===
> --- linux-2.6.19-rc6.orig/drivers/char/ipmi/ipmi_si_intf.c
> +++ linux-2.6.19-rc6/drivers/char/ipmi/ipmi_si_intf.c
> @@ -807,7 +807,12 @@ static void poll(void *send_info)
> {
> struct smi_info *smi_info = send_info;
>
> - smi_event_handler(smi_info, 0);
> + /*
> + * Make sure there is some delay in the poll loop so we can
> + * drive time forward and timeout things.
> + */
> + udelay(10);
> + smi_event_handler(smi_info, 10);
> }
I don't understand what this patch is doing. It looks fishy. More
details, please?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/12] IPMI: remove interface number limits
On Fri, 1 Dec 2006 22:24:22 -0600
Corey Minyard <[EMAIL PROTECTED]> wrote:
>
> This patch removes the arbitrary limit of number of IPMI interfaces.
> This has been tested with 8 interfaces.
>
> Signed-off-by: Corey Minyard <[EMAIL PROTECTED]>
> Cc: Carol Hebert <[EMAIL PROTECTED]>
>
> ..
>
> +struct watcher_entry {
> + struct list_head link;
> + int intf_num;
> +};
> +
> int ipmi_smi_watcher_register(struct ipmi_smi_watcher *watcher)
> {
> - int i;
> - unsigned long flags;
> + ipmi_smi_t intf;
> + struct list_head to_deliver = LIST_HEAD_INIT(to_deliver);
> + struct watcher_entry *e, *e2;
> +
> + mutex_lock(_interfaces_mutex);
> +
> + list_for_each_entry_rcu(intf, _interfaces, link) {
> + if (intf->intf_num == -1)
> + continue;
> + e = kmalloc(sizeof(*e), GFP_KERNEL);
> + if (!e)
> + goto out_err;
You miss a mutex_unlock(_interfaces_mutex) here
> + e->intf_num = intf->intf_num;
> + list_add_tail(>link, _deliver);
> + }
>
> down_write(_watchers_sem);
> list_add(&(watcher->link), _watchers);
> up_write(_watchers_sem);
> - spin_lock_irqsave(_lock, flags);
> - for (i = 0; i < MAX_IPMI_INTERFACES; i++) {
> - ipmi_smi_t intf = ipmi_interfaces[i];
> - if (IPMI_INVALID_INTERFACE(intf))
> - continue;
> - spin_unlock_irqrestore(_lock, flags);
> - watcher->new_smi(i, intf->si_dev);
> - spin_lock_irqsave(_lock, flags);
> +
> + mutex_unlock(_interfaces_mutex);
> +
> + list_for_each_entry_safe(e, e2, _deliver, link) {
> + list_del(>link);
> + watcher->new_smi(e->intf_num, intf->si_dev);
> + kfree(e);
> }
> - spin_unlock_irqrestore(_lock, flags);
> +
> +
> return 0;
> +
> + out_err:
> + list_for_each_entry_safe(e, e2, _deliver, link) {
> + list_del(>link);
> + kfree(e);
> + }
> + return -ENOMEM;
> }
>
> ...
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/12] IPMI: Allow hot system interface remove
On Fri, 1 Dec 2006 22:56:06 -0600 Corey Minyard <[EMAIL PROTECTED]> wrote: > > This modifies the IPMI driver so that a lower-level interface can be > dynamically removed while in use so it can support hot-removal of > hardware. > > It also adds the ability to specify and dynamically change the > IPMI interface the watchdog timer and the poweroff code use. > Lots of new code here. Has it all been runtime-tested under full debug mode and lockdep, as per Documentation/SubmitChecklist? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bulk] [MMC] Fix syntax error
On Sun, Dec 03, 2006 at 12:22:31PM -0800, David Brownell wrote: > On Sunday 03 December 2006 11:37 am, Ralf Baechle wrote: > > Fix syntax error introduced in ab7aefd0b38297e6d2d71f43e8f81f9f4a36cdae. > > Whoops, sorry -- my bad. However: Undercaffeination ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Compile Error - 2.6.19-rc6-mm2
I tried compiling 2.6.19-rc6-mm2 and got an error: CC [M] drivers/input/serio/parkbd.o CC [M] drivers/input/serio/serport.o CC [M] drivers/input/serio/serio_raw.o LD drivers/kvm/built-in.o CC [M] drivers/kvm/vmx.o CC [M] drivers/kvm/kvm_main.o drivers/kvm/kvm_main.c:739:32: macro "flush_tlb" passed 1 arguments, but takes just 0 drivers/kvm/kvm_main.c: In function `kvm_dev_ioctl_get_dirty_log': drivers/kvm/kvm_main.c:739: warning: statement with no effect make[2]: *** [drivers/kvm/kvm_main.o] Error 1 make[1]: *** [drivers/kvm] Error 2 make: *** [drivers] Error 2 Config is attached. My compiler is gcc-3.4.6. Matt config.bz2 Description: BZip2 compressed data
Re: [PATCH] introduce put_pid_rcu() to fix unsafe put_pid(vc->vt_pid)
On Sat, 2 Dec 2006 02:48:26 +0300 Oleg Nesterov <[EMAIL PROTECTED]> wrote: > drivers/char/vt_ioctl.c changes vc->vt_pid doing > > put_pid(xchg(>vt_pid, ...)); > > This is unsafe, put_pid() can actually free the memory while vc->vt_pid is > still used by kill_pid(vc->vt_pid). > > Add a new helper, put_pid_rcu(), which frees "struct pid" via rcu callback > and convert vt_ioctl.c to use it. > I'm a bit reluctant to go adding more tricky infrastructure (especially 100% undocumented infrastructure) on behalf of a single usage site in a place as creepy as the VT ioctl code. If we envisage future users of this infrastructure (and if it gets documented) then OK. Otherwise I'd rather just stick another bandaid into the vt code. Can we add some locking there, or change it to use a task_struct* or something? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] timers, pointers to functions and type safety
On Sun 2006-12-03 16:21:25, Roman Zippel wrote: > Hi, > > On Sun, 3 Dec 2006, Russell King wrote: > > > I agree with Al, Matthew and Pavel. The current timer stuff is a pita > > and needs fixing, and it seems Al has come up with a good way to do it > > without adding additional crap into every single user of timers. > > What exactly is the pita here? Al only came up with some rather > theoretical problems with no practical relevance. Lack of type-checking in timers is ugly. > > Al - I look forward to your changes. > > I don't. The current API is maybe not perfect, but changing the API for no > practical benefit would be an even bigger pita. I'd rather keep it as is. Al is trying to add type-checking in pretty nice & straightforward manner. Please let him do it. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bad PCI function mask in atiixp driver (was: Re: Linux 2.6.19)
On Sat, 2 Dec 2006 23:06:57 -0500 Chuck Ebbert wrote:
>
>> In-Reply-To: <[EMAIL PROTECTED]>
>>
>> On Sat, 02 Dec 2006 20:54:38 +0100, Matthijs wrote:
>>
>> > make modules gives me these warnings in modpost and then errors out:
>> > WARNING: Can't handle masks in drivers/ide/pci/atiixp:05
>>
>> Message is from scripts/file2alias.c::do_pci_entry():
>>
>> if ((baseclass_mask != 0 && baseclass_mask != 0xFF)
>> || (subclass_mask != 0 && subclass_mask != 0xFF)
>> || (interface_mask != 0 && interface_mask != 0xFF)) {
>> warn("Can't handle masks in %s:%04X\n",
>> filename, id->class_mask);
>> return 0;
>> }
>>
>> and it is complaining about this recent addition to atiixp.c:
>>
>> @@ -348,6 +368,7 @@ static struct pci_device_id atiixp_pci_t
>> { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP300_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
>> { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP400_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
>> { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP600_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
>> + { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP600_SATA, PCI_ANY_ID,
PCI_ANY_ID, (PCI_CLASS_STORAGE_IDE<<8)|0x8a, 0x05, 1},
>> { 0, },
>> };
>> MODULE_DEVICE_TABLE(pci, atiixp_pci_tbl);
>> --
>
>http://lkml.org/lkml/2006/11/01/199
>
>However, I'm still dubious.
>
>---
>~Randy
I made the same observation here when installing 2.6.19 :
[EMAIL PROTECTED] linux]# make modules
CHK include/linux/version.h
CHK include/linux/utsrelease.h
Building modules, stage 2.
MODPOST 573 modules
WARNING: Can't handle masks in drivers/ide/pci/atiixp:05
[EMAIL PROTECTED] linux]#
Hardware is quite oldfashioned.
Is there any relashionship ?
00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host
bridge (rev 03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP
bridge (rev 03)
00:04.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02)
00:04.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
00:04.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01)
00:04.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
00:0c.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06)
00:0d.0 Mass storage controller: Promise Technology, Inc. PDC20262
(FastTrak66/Ultra66) (rev 01)
01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP
1X/2X (rev 5c)
Bernard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] prune_icache_sb
On Sun, 03 Dec 2006 12:49:42 -0500 Wendy Cheng <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > >On Thu, 30 Nov 2006 11:05:32 -0500 > >Wendy Cheng <[EMAIL PROTECTED]> wrote: > > > > > > > >> > >>The idea is, instead of unconditionally dropping every buffer associated > >>with the particular mount point (that defeats the purpose of page > >>caching), base kernel exports the "drop_pagecache_sb()" call that allows > >>page cache to be trimmed. More importantly, it is changed to offer the > >>choice of not randomly purging any buffer but the ones that seem to be > >>unused (i_state is NULL and i_count is zero). This will encourage > >>filesystem(s) to pro actively response to vm memory shortage if they > >>choose so. > >> > >> > > > >argh. > > > > > I read this as "It is ok to give system admin(s) commands (that this > "drop_pagecache_sb() call" is all about) to drop page cache. It is, > however, not ok to give filesystem developer(s) this very same function > to trim their own page cache if the filesystems choose to do so" ? If you're referring to /proc/sys/vm/drop_pagecache then no, that isn't for administrators - it's a convenience thing for developers, to get repeatable benchmarks. Attempts to make it a per-numa-node control for admin purposes have been rejected. > >In Linux a filesystem is a dumb layer which sits between the VFS and the > >I/O layer and provides dumb services such as reading/writing inodes, > >reading/writing directory entries, mapping pagecache offsets to disk > >blocks, etc. (This model is to varying degrees incorrect for every > >post-ext2 filesystem, but that's the way it is). > > > > > Linux kernel, particularly the VFS layer, is starting to show signs of > inadequacy as the software components built upon it keep growing. I have > doubts that it can keep up and handle this complexity with a development > policy like you just described (filesystem is a dumb layer ?). Aren't > these DIO_xxx_LOCKING flags inside __blockdev_direct_IO() a perfect > example why trying to do too many things inside vfs layer for so many > filesystems is a bad idea ? That's not a very well-chosen example, but yes, the old ext2-based model has needed to be extended as new filesystems come along. > By the way, since we're on this subject, > could we discuss a little bit about vfs rename call (or I can start > another new discussion thread) ? > > Note that linux do_rename() starts with the usual lookup logic, followed > by "lock_rename", then a final round of dentry lookup, and finally comes > to filesystem's i_op->rename call. Since lock_rename() only calls for > vfs layer locks that are local to this particular machine, for a cluster > filesystem, there exists a huge window between the final lookup and > filesystem's i_op->rename calls such that the file could get deleted > from another node before fs can do anything about it. Is it possible > that we could get a new function pointer (lock_rename) in > inode_operations structure so a cluster filesystem can do proper locking ? That would need a new thread, and probably (at least pseudo-) code, and cc's to the appropriate maintainers (although that part of the kernel isn't really maintained any more - it has fallen into the patch-and-run model). > >>From our end (cluster locks are expensive - that's why we cache them), > >>one of our kernel daemons will invoke this newly exported call based on > >>a set of pre-defined tunables. It is then followed by a lock reclaim > >>logic to trim the locks by checking the page cache associated with the > >>inode (that this cluster lock is created for). If nothing is attached to > >>the inode (based on i_mapping->nrpages count), we know it is a good > >>candidate for trimming and will subsequently drop this lock (instead of > >>waiting until the end of vfs inode life cycle). > >> > >> > > > >Again, I don't understand why you're tying the lifetime of these locks to > >the VFS inode reclaim mechanisms. Seems odd. > > > > > Cluster locks are expensive because: > > 1. Every node in the cluster has to agree about it upon granting the > request (communication overhead). > 2. It involves disk flushing if bouncing between nodes. Say one node > requests a read lock after another node's write... before the read lock > can be granted, the write node needs to flush the data to the disk (disk > io overhead). > > For optimization purpose, we want to refrain the disk flush after writes > and hope (and encourage) the next person who requests the lock to be on > the very same node (to take the advantage of OS write-back logic). > That's why the locks are cached on the very same node. It will not get > removed unless necessary. > What would be better to build the lock caching on top of the existing > inode cache logic - since these are the objects that the cluster locks > are created for in the first place. hmm, I suppose that makes sense. Are there dentries
RE: la la la la ... swappiness
On Sun, 3 Dec 2006, Aucoin wrote: > during tar extraction ... inactive pages reaches levels as high as ~375000 So why do you want the system to swap _less_? You need to find some free memory for the additional processes to run in, and you have lots of inactive pages, so I think you want to swap out _more_ pages. I'd suggest to temporarily add a swapfile before you update your system. This can even help in bringing your memory use to the state before if you do it like this - swapon additional swapfile - update your database software - swapoff swap partition - swapon swap partition - swapoff additional swapfile Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH? rcu_do_batch: fix a pure theoretical memory ordering race
Oleg Nesterov a écrit :
On 12/03, Eric Dumazet wrote:
Oleg Nesterov a ?crit :
On top of rcu-add-a-prefetch-in-rcu_do_batch.patch
rcu_do_batch:
struct rcu_head *next, *list;
while (list) {
next = list->next; <-- [1]
list->func(list);
list = next;
}
We can't trust *list after list->func() call, that is why we load
list->next
beforehand. However I suspect in theory this is not enough, suppose that
- [1] is stalled
- list->func() marks *list as unused in some way
- another CPU re-uses this rcu_head and dirties it
- [1] completes and gets a wrong result
This means we need a barrier in between. mb() looks more suitable, but I
think
rmb() should suffice.
Well, hopefully the "list->func()" MUST do the right thing [*], so your
patch is not necessary.
Yes, I don't claim it is necessary, note the "pure theoretical".
For example, most structures are freed with kfree()/kmem_cache_free() and
these functions MUST imply an smp_mb() [if/when exchanging data with other
cpus], or else many uses in the kernel should be corrected as well.
Yes, mb() is enough (wmb() isn't) and kfree()/kmem_cache_free() are ok.
And I don't know any example of "unsafe" code in that sense.
However I believe it is easy to make the code which is correct from the
RCU's API pov, but unsafe.
Yes, but how is it related to RCU ?
I mean, rcu_do_batch() is just a loop like others in kernel.
The loop itself is not buggy, but can call a buggy function, you are right.
A smp_rmb() wont avoid all possible bugs...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
pata_via report
Hello Alan, I would like to report my experience with new pata_via driver. Short version: works (no data were trashed, during the investigation), but the bits to detect the cable type are not set by BIOS. There is also a bug in my BIOS, which kills the UDMA register. Long version: I have 80pin cable on primary master with western digital drive on it as slave. No other device on primary master. Secondary master is NEC DVDRW. I have two SATA drives, from which I boot the system. ata3: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xCC00 irq 14 ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xCC08 irq 15 scsi2 : pata_via DEBUG ATA66: 0x07e1e607 ATA: abnormal status 0x8 on port 0x1F7 ATA: abnormal status 0x8 on port 0x1F7 When kernel boots it produces this messages. I already found out why, the BIOS incorrectly programs the 0x50 DWORD in PCI space (the UDMA register) so its value is somewhat mirrored like it is above. (I know it is a BIOS bug, I tried to dump the register in PCI init function) If I set the drive to master, then it is programmed correctly. However my BIOS do not program the 80wire cable info, so I receive: ata3.01: ATA-6, max UDMA/100, 390721968 sectors: LBA48 ata3.01: ata3: dev 1 multi count 16 ata3.01: configured for UDMA/33 I checked docs if VIA has some internal register/pin for the cable sense, but it does not. It is routed to some GPIO and the BIOS did not update this register. My board is A8V-E SE, ASUS, I already wrote to their support, so I may have some news on this in future. I think I'm not the only one with buggy BIOS, maybe the old is >UDMA33 active method will work for more people. Other solution would be to test the cable status via WORD 93 in IDENTIFY command, but this must be done "post" somehow, I dont know if this is even possible or planed feature of libsata. As for the wrong PCI register value, I think I would be able to develop some code test to detect this, but I dont know if you will accept it into the driver. Do we care about sane values? There is no problem with secondary DVDRW drive, thanks to libsata, it recovers from media errors nicely. Oh and one more thing. The cable sensing stuff is supported from newer VIA chipsets, older datasheets says "read as 0" but do NOT trust them. Often many VIA registers "read as 0" read as whatever. Maybe some check for chipset version is necessary. I hope it helps, Rudolf Please CC me on LKML posts. 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00: 06 11 71 05 07 00 90 02 06 8a 01 01 00 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 cc 00 00 00 00 00 00 00 00 00 00 43 10 ed 80 30: 00 00 00 00 c0 00 00 00 00 00 00 00 02 01 00 00 40: 3b f2 09 05 18 8c c0 00 5d 20 5d 20 ff 00 20 20 50: 07 e6 07 e1 0c 00 00 00 a8 a8 a8 a8 00 00 00 00 60: 00 02 00 00 00 00 00 00 00 02 00 00 00 00 00 00 70: 02 01 00 00 00 00 00 00 02 01 00 00 00 00 00 00 80: 00 a0 b9 3f 00 00 00 00 00 50 b2 3f 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 06 00 71 05 43 10 ed 80 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 09 00 00 00 00 00 00 00 00 00 Version: ASUS A8V-E SE ACPI BIOS Revision 1010 _NEC DVD_RW ND-3520AW 3.06 ATA WDC WD2000JB-00G 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
What's in ocfs2.git
This e-mail describes the OCFS2 patches which I intend to push
upstream to Linus for 2.6.20.
* Various ocfs2 cleanups, including a patchset by me intended to clean up
some of the internal ocfs2 journal api. Mostly this revolves around
removing the ocfs2_journal_handle wrapper around handle_t. The immediate
benefits are better readability and a slightly smaller memory footprint
for open journal transactions.
* Configfs gets some small cleanups and some mutex annotations.
* Atime updates - thanks to Tiger Yang <[EMAIL PROTECTED]>, ocfs2 now
writes to the inode atime field. This doesn't require any disk changes,
and is completely backwards compatible with older ocfs2 versions. An
inodes Atime is only updated if it hasn't changed within a certain
quantum. The user can define their own value at mount time, with 0
indicating that atime should always be updated. This is very similar to
the scheme implemented by gfs2. In the future, I'd like to see a "relative
atime" mode, which functions in the manner described by Valerie Henson at:
http://lkml.org/lkml/2006/8/25/380
* sys_splice - ocfs2 now has splice read and write support. Thanks again to
Tiger for the bulk of this functionality. Mostly we make use of the
generic_splice_read() and generic_file_splice_write_nolock() functions
provided already in fs/splice.c.
- There is one patch in the ocfs2 splice() series external to fs/ocfs2 - a
simple export of should_remove_suid(). This is done for code reuse
purposes. That particular patch can be seen at:
http://ftp.kernel.org/pub/linux/kernel/people/mfasheh/ocfs2/ocfs2_git_patches/ocfs2-upstream-linus-20061201/0025-Export-should_remove_suid.txt
I'll also attach it to this mail for review purposes.
* Last in the list of notable patches is a somewhat involved fix by Kurt
Hackel <[EMAIL PROTECTED]> within the ocfs2 dlm. We had temporarily
disable automatic migration of certain lock types because it was causing
us problems during stress testing. This patch fixes those problems and
re-enables migration. Overall this should reduce memory usage of the ocfs2
dlm.
The patches can be found in
git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2.git upstream-linus
Additionally, broken out patches are available at:
http://ftp.kernel.org/pub/linux/kernel/people/mfasheh/ocfs2/ocfs2_git_patches/ocfs2-upstream-linus-20060924/
Thanks,
--Mark
--
Mark Fasheh
Senior Software Developer, Oracle
[EMAIL PROTECTED]
[PATCH] Export should_remove_suid()
This helps us avoid replicating the same logic within file system drivers.
Signed-off-by: Mark Fasheh <[EMAIL PROTECTED]>
---
mm/filemap.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
d23a147bb6e8d467e8df73b6589888717da3b9ce
diff --git a/mm/filemap.c b/mm/filemap.c
index 7b84dc8..13df01c 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1893,6 +1893,7 @@ int should_remove_suid(struct dentry *de
return 0;
}
+EXPORT_SYMBOL(should_remove_suid);
int __remove_suid(struct dentry *dentry, int kill)
{
--
1.3.3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bulk] [MMC] Fix syntax error
On Sunday 03 December 2006 11:37 am, Ralf Baechle wrote:
> Fix syntax error introduced in ab7aefd0b38297e6d2d71f43e8f81f9f4a36cdae.
Whoops, sorry -- my bad. However:
> Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
>
> diff --git a/drivers/mmc/au1xmmc.c b/drivers/mmc/au1xmmc.c
> index 447fba5..6aac498 100644
> --- a/drivers/mmc/au1xmmc.c
> +++ b/drivers/mmc/au1xmmc.c
> @@ -875,7 +875,7 @@ static void au1xmmc_init_dma(struct au1x
> host->rx_chan = rxchan;
> }
>
> -struct const mmc_host_ops au1xmmc_ops = {
> +const struct mmc_host_ops au1xmmc_ops = {
This would normally be "static const struct" ...
> .request= au1xmmc_request,
> .set_ios= au1xmmc_set_ios,
> };
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Cluster-devel] Re: [GFS2] Change argument of gfs2_dinode_out [17/70]
Pavel Machek wrote: Feel free to keep rhel5 ugly, Oh no he won't. We review patches internally, too :) -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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? rcu_do_batch: fix a pure theoretical memory ordering race
On 12/03, Eric Dumazet wrote:
>
> Oleg Nesterov a ?crit :
> >On top of rcu-add-a-prefetch-in-rcu_do_batch.patch
> >
> >rcu_do_batch:
> >
> > struct rcu_head *next, *list;
> >
> > while (list) {
> > next = list->next; <-- [1]
> > list->func(list);
> > list = next;
> > }
> >
> >We can't trust *list after list->func() call, that is why we load
> >list->next
> >beforehand. However I suspect in theory this is not enough, suppose that
> >
> > - [1] is stalled
> >
> > - list->func() marks *list as unused in some way
> >
> > - another CPU re-uses this rcu_head and dirties it
> >
> > - [1] completes and gets a wrong result
> >
> >This means we need a barrier in between. mb() looks more suitable, but I
> >think
> >rmb() should suffice.
> >
>
> Well, hopefully the "list->func()" MUST do the right thing [*], so your
> patch is not necessary.
Yes, I don't claim it is necessary, note the "pure theoretical".
> For example, most structures are freed with kfree()/kmem_cache_free() and
> these functions MUST imply an smp_mb() [if/when exchanging data with other
> cpus], or else many uses in the kernel should be corrected as well.
Yes, mb() is enough (wmb() isn't) and kfree()/kmem_cache_free() are ok.
And I don't know any example of "unsafe" code in that sense.
However I believe it is easy to make the code which is correct from the
RCU's API pov, but unsafe.
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
