Re: 2.6.24-rc6-mm1 - git-lblnet.patch and networking horkage
On Wed, 26 Dec 2007, [EMAIL PROTECTED] wrote: > I already checked, it's not a slam-dunk to just 'patch -R' as there's 3 or 4 > conflicts where later patches need massaging/reverting as well. > > It's a problem with both 'classic RCU' and 'preempt RCU' (that was my *first* > guess as to the cause). > > Any clues/hints/advice/patches? Can you post your .config ? Also, is that the plain upstream Tcl package you're compiling, or a distro package? -- James Morris <[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: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
Linus Torvalds wrote: > >> IMO, we should check which version of the specification we're supposed to >> follow, on the basis of FADT contents, for example, and follow this one. >> > > No, we should try to figure out what Windows does. *If* windows checks the > version, we should do that too. But we should absolutely *not* just assume > that the documentation is an accurate picture of reality. > > Does anybody know how we could find out? > > Run it in a virtual machine, with the ACPI methods of interest wired to output to some port, and log that I/O port in the monitor/emulator. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HSM violation errors
Jeff Mitchell wrote: I'm seeing errors in dmesg and the like. It appears to be somewhat similar to the issue reported here: http://kerneltrap.org/mailarchive/linux-kernel/2007/8/25/164711 except that my machine doesn't freeze, and everything seems normal -- hopefully nothing like silent corruption is going on. Also it's on brand new hardware...Intel ICH8 mobile chipset with AHCI. Output from dmesg, hdparm -I /dev/sda and hdparm --drq-hsm-error /dev/sda is below...please let me know if there's anything else that would be of use (and, of course, if this is something I should be worried about :-) ). Thanks. Jeff dmesg: ata1.00: exception Emask 0x2 SAct 0xfffd SErr 0x0 action 0x2 frozen ata1.00: spurious completions during NCQ issue=0x1 SAct=0xfffd FIS=005040a1:0002 You didn't say what kernel you were using, but in the latest kernels this spurious completion check was removed since it was broken, so this error shouldn't happen anymore. -- 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/
2.6.24-rc6-mm1 - git-lblnet.patch and networking horkage
On Sat, 22 Dec 2007 23:30:56 PST, Andrew Morton said: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/ I've bisected it down this far: kvm-ist-kaput.patch GOOD git-lblnet.patch git-lblnet-fixup.patch git-leds.patch git-libata-all.patch git-libata-all-fix-pata_winbond-borkage.patch git-libata-all-wtf.patchBAD and somehow, I doubt the leds or libata trees horked up networking. ;) Symptoms - semi-sporadic failures in making network connections. The test case that tripped it up was the 'make test' from the Tcl 8.5 - several of the test cases will create a listening socket, and then try to connect to it. Under 2.6.24-rc5-mm1, it works just fine, but I'm seeing hangs under -rc6-mm1. Doing a 'netstat -n -a -A inet -p' while it's hung shows me this: Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp0 0 127.0.0.1:34118 0.0.0.0:* LISTEN 2236/tcltest tcp0 1 127.0.0.1:59460 127.0.0.1:34118 SYN_SENT2236/tcltest Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp0 0 127.0.0.1:47842 0.0.0.0:* LISTEN 2352/tcltest tcp0 1 127.0.0.1:46510 127.0.0.1:47842 SYN_SENT2352/tcltest Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp0 0 127.0.0.1:47842 0.0.0.0:* LISTEN 2352/tcltest tcp0 1 127.0.0.1:46510 127.0.0.1:47842 SYN_SENT2352/tcltest Pretty consistent failure mode - a socket is in 'listen', and the connection gets hung in 'SYN_SENT'. There's 3 outputs listed - the first one from one run of the test case, the second 2 are some 20 seconds apart on the same run. It's pretty obvious that if you can't complete a 3-packet handshake to loopback in 20 seconds, something is hosed. However, it's apparently some sort of race/timing issue, as many *other* test cases in the Tcl test tree do in fact work OK. I already checked, it's not a slam-dunk to just 'patch -R' as there's 3 or 4 conflicts where later patches need massaging/reverting as well. It's a problem with both 'classic RCU' and 'preempt RCU' (that was my *first* guess as to the cause). Any clues/hints/advice/patches? pgpi5yFSX0Mho.pgp Description: PGP signature
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
Linus Torvalds wrote: IMO, we should check which version of the specification we're supposed to follow, on the basis of FADT contents, for example, and follow this one. No, we should try to figure out what Windows does. *If* windows checks the version, we should do that too. But we should absolutely *not* just assume that the documentation is an accurate picture of reality. Does anybody know how we could find out? Linus Well, it seems that if one had a checked (debug) build of Windows (or at least the acpi.sys driver) installed, as well as a copy of the Microsoft ASL compiler, they could compile and temporarily override the DSDT with a hacked one that would output what the device power states were in some fashion (maybe through the kernel debugger). Some info about this here: http://download.microsoft.com/download/1/8/f/18f8cee2-0b64-41f2-893d-a6f2295b40c8/TW04015_WINHEC2004.ppt I suspect that might require more Windows hacking skill and/or motivation than one might be likely to find on this list, though :-) -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ipv4: Update ip command line processing (take II)
On Tue, Dec 25, 2007 at 08:55:43PM -0800, David Miller wrote: > From: Simon Horman <[EMAIL PROTECTED]> > Date: Wed, 26 Dec 2007 11:59:05 +0900 > > > Recently the documentation in Documentation/nfsroot.txt was > > update to note that in fact ip=off and ip=::off as the > > latter is ignored and the default (on) is used. > > > > This was certainly a step in the direction of reducing confusion. > > But it seems to me that the code ought to be fixed up so that > > ip=::off actually turns off ip autoconfiguration. > > > > This patch also notes more specifically that ip=on (aka ip=::on) > > is the default. > > > > Cc: Amos Waterland <[EMAIL PROTECTED]> > > Signed-off-by: Simon Horman <[EMAIL PROTECTED]> > > I applied this to net-2.6 since I think it's a bug fix, and > I also tailored the changelog header to more it clear this > is a fix not just an "Update". :-) Ok, thanks. -- Horms -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ipv4: Update ip command line processing (take II)
From: Simon Horman <[EMAIL PROTECTED]> Date: Wed, 26 Dec 2007 11:59:05 +0900 > Recently the documentation in Documentation/nfsroot.txt was > update to note that in fact ip=off and ip=::off as the > latter is ignored and the default (on) is used. > > This was certainly a step in the direction of reducing confusion. > But it seems to me that the code ought to be fixed up so that > ip=::off actually turns off ip autoconfiguration. > > This patch also notes more specifically that ip=on (aka ip=::on) > is the default. > > Cc: Amos Waterland <[EMAIL PROTECTED]> > Signed-off-by: Simon Horman <[EMAIL PROTECTED]> I applied this to net-2.6 since I think it's a bug fix, and I also tailored the changelog header to more it clear this is a fix not just an "Update". :-) 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: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
On Tue, 25 Dec 2007, Rafael J. Wysocki wrote: > > > > Correct me if I'm wrong, but it appears ACPI 1.0 wants _PTS called > > before any devices are suspended, ACPI 2.0 is contradictory, and ACPI > > 3.0 says that you can't assume anything about device state. My guess is > > that unless Windows has different behavior depending on ACPI version, it > > probably has called _PTS before suspending devices all along. Therefore > > it would likely be safest to emulate that behavior, no? > > Well, I don't think so. It would *definitely* always be safest to emulate what Windows does. > In fact ACPI 3.0 repeats the 2.0 wording in section 9.1.6 (so the current > requirement seems to be to put devices into low power states before calling > _PTS) and I _guess_ there was a change in the default behavior of Windows that > caused the specification to be modified (I'd bet that was between 2000 and XP > or something like this). You seem to put a lot of trust in a piece of documentation. Do you realize how those pieces of paper are written? They are written by people who have absolutely *nothing* to do with the actual implementation, and whose job it is to write documentation. And while the people who actually do the programming etc are supposed to help them, the two parties generally detest each other. Technical writers hate the "real engineers" for not helping them, and the "real engineers" tend to dislike having to be pestered to explain their stuff and have to read through some document that isn't meant for them, but that they need to sign off on. In other words: please do *not* expect that the documentation actually matches reality. You seem to think that the documentation came first and/or is quite accurate. That's not at all likely to be true. > IMO, we should check which version of the specification we're supposed to > follow, on the basis of FADT contents, for example, and follow this one. No, we should try to figure out what Windows does. *If* windows checks the version, we should do that too. But we should absolutely *not* just assume that the documentation is an accurate picture of reality. Does anybody know how we could find out? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
On Tue, 25 Dec 2007, Andrew Morton wrote: > On Thu, 20 Dec 2007 15:11:40 +1100 (EST) James Morris <[EMAIL PROTECTED]> > wrote: > > > > > +#ifdef CONFIG_SECURITY > > > > +extern unsigned long mmap_min_addr; > > > > +#endif > > > > + > > > > #include > > > > #include > > > > #include > > > > > > Fine by me. > > > > I'll queue it for -mm & 2.6.25. > > I don't think we need the ifdef. If someone incorrectly refers to this > then they'll get a link-time error rather than a compile-time error (bad). > But we lose an ifdef (good). Done, & rebased the git branch. - James -- James Morris <[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: Suspend code ordering (again) (was: Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM)
On Tue, 25 Dec 2007, Rafael J. Wysocki wrote: > > the ACPI specification between versions 1.0x and 2.0. Namely, while ACPI > 2.0 and later wants us to put devices into low power states before calling > _PTS, ACPI 1.0x wants us to do that after calling _PTS. Since we're following > the 2.0 and later specifications right now, we're not doing the right thing > for > the (strictly) ACPI 1.0x-compliant systems. > > We ought to be able to fix things on the high level, by calling _PTS earlier > on > systems that claim to be ACPI 1.0x-compliant. That will require us to modify > the generic susped code quite a bit and will need to be tested for some time. That's insane. Are you really saying that ACPI wants totally different orderings for different versions of the spec? And does Windows really do that? Please don't make lots of modifications to the generic suspend code. The only thing that is worth doing is to just have a firmware callback before the "device_suspend()" thing (and then on a ACPI-1.0 system, call _PTS *there*), and on an ACPI-2.0 system, call _PTS *after* device_suspend(). Still, the fact is, some (most, I think) drivers *should* put themselves into D3 only in "late_suspend()", so if ACPI-2.0 really expects _PTS to be called after that, we're just screwed. That's when the system is really down, interrupts disabled etc, we don't want to call anything but the final ACPI "turn us off" stuff there! Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xip: fix get_zeroed_page with __GFP_HIGHMEM
On Tue, 25 Dec 2007, Akinobu Mita wrote:
> The use of get_zeroed_page() with __GFP_HIGHMEM is invalid.
> Use alloc_page() with __GFP_ZERO instead of invalid get_zeroed_page().
>
> (This patch is only compile tested)
>
> Cc: Carsten Otte <[EMAIL PROTECTED]>
> Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
Good find! You got me very worried, how this escaped testing before.
Presumed explanation: it hasn't been needed beyond s390, which has no
CONFIG_HIGHMEM; and it has never been tested with CONFIG_DEBUG_VM on.
Acked-by: Hugh Dickins <[EMAIL PROTECTED]>
But I haven't tested it either: let's wait for Carsten to report.
I believe Nick has changes on the way which will make it possible for
ordinary mortals to test XIP: here's a good argument to bring them on.
May I cross-reference my "prep_zero_page: remove bogus BUG_ON"
09f345da758fca1222b0971b65b2fddbdf78bb83 in 2.6.24-rc: that bogus
(actually VM_)BUG_ON would have stood in the way too, so there's
no point in backporting this without that. But if only non-HIGHMEM
architectures can have been using XIP, a backport is not essential.
Hugh
p.s. Nick's ZERO_PAGE changes, in 2.6.24-rc, actually cancel the need
for a special xip_sparse_page distinct from ZERO_PAGE. But let's not
become dependent on those: keep this doing it the way it does now.
>
> ---
> mm/filemap_xip.c |9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> Index: 2.6-git/mm/filemap_xip.c
> ===
> --- 2.6-git.orig/mm/filemap_xip.c
> +++ 2.6-git/mm/filemap_xip.c
> @@ -25,14 +25,15 @@ static struct page *__xip_sparse_page;
> static struct page *xip_sparse_page(void)
> {
> if (!__xip_sparse_page) {
> - unsigned long zeroes = get_zeroed_page(GFP_HIGHUSER);
> - if (zeroes) {
> + struct page *page = alloc_page(GFP_HIGHUSER | __GFP_ZERO);
> +
> + if (page) {
> static DEFINE_SPINLOCK(xip_alloc_lock);
> spin_lock(_alloc_lock);
> if (!__xip_sparse_page)
> - __xip_sparse_page = virt_to_page(zeroes);
> + __xip_sparse_page = page;
> else
> - free_page(zeroes);
> + __free_page(page);
> spin_unlock(_alloc_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: Can't disconnect a USB sound device and connect another
On Tue, 25 Dec 2007, Andrew Morton wrote: > On Sun, 23 Dec 2007 23:36:11 +0100 Victor Hahn <[EMAIL PROTECTED]> wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > ... because it causes lsusb to freeze and gives me this in > > /var/log/messages: > > Has this always happened, or is it something we introduced in a recent > kernel? > > > Dec 23 23:27:04 cabrio kernel: usb 2-2: USB disconnect, address 5 > > Dec 23 23:27:04 cabrio kernel: PGD 110f2067 PUD 110f3067 PMD 0 > > Dec 23 23:27:04 cabrio kernel: CPU 0 > > Dec 23 23:27:04 cabrio kernel: Modules linked in: videodev v4l2_common > > v4l1_compat snd_rtctimer binfmt_misc rfcomm l2cap bluetooth capability ... > > Dec 23 23:27:04 cabrio kernel: Pid: 2052, comm: khubd Not tainted 2.6.23.11 > > #1 > > Dec 23 23:27:04 cabrio kernel: RIP: 0010:[_end+130488219/2130651808] > > [_end+130488219/2130651808] :snd:snd_ctl_dev_disconnect+0x6b/0xb0 > > Dec 23 23:27:04 cabrio kernel: RSP: 0018:810037bfdc40 EFLAGS: 00010282 > > Dec 23 23:27:04 cabrio kernel: RAX: RBX: 00100100 > > RCX: 0018 > > Dec 23 23:27:04 cabrio kernel: RDX: 00020004 RSI: 001d > > RDI: 810013e98c08 > > Dec 23 23:27:04 cabrio kernel: RBP: 8100394631a8 R08: 810037bfc000 > > R09: ... > > Dec 23 23:27:04 cabrio kernel: Process khubd (pid: 2052, threadinfo > > 810037bfc000, task 81003d67d0c0) > > Dec 23 23:27:04 cabrio kernel: Stack: 810038850d00 > > 810039463000 810039463150 > > Dec 23 23:27:04 cabrio kernel: 88281e69 > > 810038850d00 882821ac > > Dec 23 23:27:04 cabrio kernel: > > 810039463000 8100394631e0 > > Dec 23 23:27:04 cabrio kernel: Call Trace: > > Dec 23 23:27:04 cabrio kernel: > > [_end+130500873/2130651808] :snd:snd_device_disconnect+0x59/0x90 > > Dec 23 23:27:04 cabrio kernel: ... > > Is there a way to exchange USB audio devices without rebooting? > > First we have to work out if it's a USB bug or an ALSA bug. I'd guess > ALSA, but not with a lot of confidence. > > Anyone? There have been similar reports of this bug. To me it looks like an ALSA problem. The routine in question, snd_ctl_dev_disconnect(), is an ALSA callback and doesn't contain any USB code. A good way to start would be to obtain a disassembly listing of that routine, so we can find out what C statement caused the bug. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] PM: Do not destroy/create devices while suspended
On Tue, 25 Dec 2007, Rafael J. Wysocki wrote: > > > Do we need to worry about the possibility that when the system wakes up > > > from hibernation, the set of usable CPUs might be smaller than it was > > > beforehand? > > > > This is possible in error conditions. > > > > > Is any special handling needed for this, or is it already accounted for? > > > > Hm, well. The cleanest thing would be to allow the drivers to remove the > > device objects on CPU_UP_CANCELED_FROZEN, which means that we weren't able > > to > > bring the CPU up during a resume, but still that will deadlock with > > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch. > > Hmm. In principle, device objects may be destroyed on CPU_UP_CANCELED_FROZEN > without acquiring the device locks, since in fact we know these objects won't > be accessed concurrently at that time (the locks are already held by the PM > core, but the PM core is not going to actually access the devices before the > subsequent resume). How about delaying the CPU_UP_CANCELED_FROZEN announcements until it's really safe to send them out? That is, after all devices have been resumed and the PM core no longer holds any of their locks. (Should this be before or after tasks leave the freezer? -- I'm not sure.) So the idea is send appropriate announcements at the usual time for CPUs that do come back up normally, and don't send anything right away for CPUs that fail to come up. Just keep track of which ones failed, and then later take care of them. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] netconsole: register cmdline netconsole configs to configfs
This patch intorduces cmdline netconsole configs to register to configfs with
dynamic netconsole. Satyam Sharma who designed shiny
dynamic reconfiguration for netconsole, mentioned about this issue already.
(http://lkml.org/lkml/2007/7/29/360)
But I think, without separately managing of two kind of netconsole target
objects, it's possible by using config_group instead of
config_item in the netconsole_target and default_groups feature of configfs.
Patch was tested with configuration creation/destruction by kernel and module.
And it makes possible to enable/disable, modify and review netconsole target
configs from cmdline.
Signed-off-by: Joonwoo Park <[EMAIL PROTECTED]>
---
drivers/net/netconsole.c | 91 --
1 files changed, 72 insertions(+), 19 deletions(-)
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index 5ffbb88..04e4555 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -93,7 +93,7 @@ static DEFINE_SPINLOCK(target_list_lock);
struct netconsole_target {
struct list_headlist;
#ifdef CONFIG_NETCONSOLE_DYNAMIC
- struct config_item item;
+ struct config_group group;
#endif
int enabled;
struct netpoll np;
@@ -103,16 +103,49 @@ struct netconsole_target {
static struct configfs_subsystem netconsole_subsys;
-static int __init dynamic_netconsole_init(void)
+static void netconsole_target_put(struct netconsole_target *nt);
+static struct config_item_type netconsole_target_type;
+
+static int __init dynamic_netconsole_init(int defaults)
{
+ int err;
+ unsigned long flags;
config_group_init(_subsys.su_group);
+
+ if (defaults > 0) {
+ struct list_head *pos;
+ struct config_group **groups;
+ int i = 0;
+
+ groups = kcalloc(defaults, sizeof(struct config_group *),
+ GFP_KERNEL);
+ if (!groups)
+ return -ENOMEM;
+
+ spin_lock_irqsave(_list_lock, flags);
+ list_for_each(pos, _list) {
+ struct netconsole_target *nt;
+ nt = list_entry(pos, struct netconsole_target, list);
+ groups[i] = >group;
+ i++;
+ }
+ spin_unlock_irqrestore(_list_lock, flags);
+ netconsole_subsys.su_group.default_groups = groups;
+ }
+
mutex_init(_subsys.su_mutex);
- return configfs_register_subsystem(_subsys);
+
+ err = configfs_register_subsystem(_subsys);
+ if (err)
+ kfree(netconsole_subsys.su_group.default_groups);
+
+ return err;
}
static void __exit dynamic_netconsole_exit(void)
{
configfs_unregister_subsystem(_subsys);
+ kfree(netconsole_subsys.su_group.default_groups);
}
/*
@@ -122,14 +155,23 @@ static void __exit dynamic_netconsole_exit(void)
*/
static void netconsole_target_get(struct netconsole_target *nt)
{
- if (config_item_name(>item))
- config_item_get(>item);
+ if (config_item_name(>group.cg_item))
+ config_item_get(>group.cg_item);
}
static void netconsole_target_put(struct netconsole_target *nt)
{
- if (config_item_name(>item))
- config_item_put(>item);
+ if (config_item_name(>group.cg_item))
+ config_item_put(>group.cg_item);
+}
+
+static void dynamic_netconsole_init_type_name(struct netconsole_target *nt,
+ int index)
+{
+ char name[16];
+ snprintf(name, sizeof(name), "netcon%d", index);
+ config_item_init_type_name(>group.cg_item, name,
+ _target_type);
}
#else /* !CONFIG_NETCONSOLE_DYNAMIC */
@@ -155,6 +197,11 @@ static void netconsole_target_put(struct netconsole_target
*nt)
{
}
+static void dynamic_netconsole_init_type_name(struct netconsole_target *nt,
+ int index)
+{
+}
+
#endif /* CONFIG_NETCONSOLE_DYNAMIC */
/* Allocate new target (from boot/module param) and setup netpoll for it */
@@ -236,8 +283,8 @@ struct netconsole_target_attr {
static struct netconsole_target *to_target(struct config_item *item)
{
return item ?
- container_of(item, struct netconsole_target, item) :
- NULL;
+ container_of(to_config_group(item), struct netconsole_target,
+ group) : NULL;
}
/*
@@ -368,7 +415,7 @@ static ssize_t store_dev_name(struct netconsole_target *nt,
if (nt->enabled) {
printk(KERN_ERR "netconsole: target (%s) is enabled, "
"disable to update parameters\n",
- config_item_name(>item));
+ config_item_name(>group.cg_item));
return
[PATCH 1/2] configfs: dir.c fix possible recursive locking
configfs_register_subsystem() with default_groups triggers recursive locking.
it seems that mutex_lock_nested is needed.
=
[ INFO: possible recursive locking detected ]
2.6.24-rc6 #141
-
swapper/1 is trying to acquire lock:
(>s_type->i_mutex_key#3){--..}, at: []
configfs_attach_group+0x4f/0x190
but task is already holding lock:
(>s_type->i_mutex_key#3){--..}, at: []
configfs_register_subsystem+0x55/0x130
other info that might help us debug this:
1 lock held by swapper/1:
#0: (>s_type->i_mutex_key#3){--..}, at: []
configfs_register_subsystem+0x55/0x130
stack backtrace:
Pid: 1, comm: swapper Not tainted 2.6.24-rc6 #141
[] show_trace_log_lvl+0x1a/0x30
[] show_trace+0x12/0x20
[] dump_stack+0x6e/0x80
[] __lock_acquire+0xe62/0x1120
[] lock_acquire+0x82/0xa0
[] mutex_lock_nested+0x98/0x2e0
[] configfs_attach_group+0x4f/0x190
[] configfs_register_subsystem+0xc6/0x130
[] init_netconsole+0x2b6/0x300
[] kernel_init+0x142/0x320
[] kernel_thread_helper+0x7/0x14
===
Signed-off-by: Joonwoo Park <[EMAIL PROTECTED]>
---
fs/configfs/dir.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index 50ed691..a48dc7d 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -546,7 +546,7 @@ static int populate_groups(struct config_group *group)
* That said, taking our i_mutex is closer to mkdir
* emulation, and shouldn't hurt.
*/
- mutex_lock(>d_inode->i_mutex);
+ mutex_lock_nested(>d_inode->i_mutex, I_MUTEX_CHILD);
for (i = 0; group->default_groups[i]; i++) {
new_group = group->default_groups[i];
@@ -1405,7 +1405,8 @@ int configfs_register_subsystem(struct configfs_subsystem
*subsys)
sd = configfs_sb->s_root->d_fsdata;
link_group(to_config_group(sd->s_element), group);
- mutex_lock(_sb->s_root->d_inode->i_mutex);
+ mutex_lock_nested(_sb->s_root->d_inode->i_mutex,
+ I_MUTEX_PARENT);
name.name = group->cg_item.ci_name;
name.len = strlen(name.name);
---
Thanks.
Joonwoo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/2] configfs: file.c fix possible recursive locking
configfs_register_subsystem() with default_groups triggers recursive locking.
it seems that mutex_lock_nested is needed.
=
[ INFO: possible recursive locking detected ]
2.6.24-rc6 #145
-
swapper/1 is trying to acquire lock:
(>s_type->i_mutex_key#3){--..}, at: []
configfs_add_file+0x2e/0x70
but task is already holding lock:
(>s_type->i_mutex_key#3){--..}, at: []
configfs_register_subsystem+0x55/0x130
other info that might help us debug this:
1 lock held by swapper/1:
#0: (>s_type->i_mutex_key#3){--..}, at: []
configfs_register_subsystem+0x55/0x130
stack backtrace:
Pid: 1, comm: swapper Not tainted 2.6.24-rc6 #145
[] show_trace_log_lvl+0x1a/0x30
[] show_trace+0x12/0x20
[] dump_stack+0x6e/0x80
[] __lock_acquire+0xe62/0x1120
[] lock_acquire+0x82/0xa0
[] mutex_lock_nested+0x98/0x2e0
[] configfs_add_file+0x2e/0x70
[] configfs_create_file+0x2c/0x40
[] configfs_attach_item+0x139/0x220
[] configfs_attach_group+0x14/0x140
[] configfs_attach_group+0xc9/0x140
[] configfs_register_subsystem+0xc6/0x130
[] init_netconsole+0x2b6/0x300
[] kernel_init+0x142/0x320
[] kernel_thread_helper+0x7/0x14
===
Signed-off-by: Joonwoo Park <[EMAIL PROTECTED]>
---
fs/configfs/file.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/configfs/file.c b/fs/configfs/file.c
index a3658f9..397cb50 100644
--- a/fs/configfs/file.c
+++ b/fs/configfs/file.c
@@ -320,7 +320,7 @@ int configfs_add_file(struct dentry * dir, const struct
configfs_attribute * att
umode_t mode = (attr->ca_mode & S_IALLUGO) | S_IFREG;
int error = 0;
- mutex_lock(>d_inode->i_mutex);
+ mutex_lock_nested(>d_inode->i_mutex, I_MUTEX_NORMAL);
error = configfs_make_dirent(parent_sd, NULL, (void *) attr, mode,
type);
mutex_unlock(>d_inode->i_mutex);
---
Thanks.
Joonwoo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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][PATCH -mm] bluetooth : rfcomm add get/put device in del_conn
On Tue, Dec 25, 2007 at 06:07:24PM +0800, Dave Young wrote:
> On Dec 25, 2007 6:03 PM, Dave Young <[EMAIL PROTECTED]> wrote:
> > Due to 2.6.24-rc6-mm1 kernel changes (maybe kobject or driver core), If I
> > exec:
> >
> > rfcomm connect 0 1
> >
> > kernel will oops after connect timeout.
> >
> > hand copy some oops text:
> >
> > EIP is at driver_sysfs_remove+0x1a/0x40
> > Call Trace:
> > show_trace_log_lvl+0x1a/0x30
> > show_stack_log_lvl+0x9a/0xc0
> > show_registers+0xc7/0x270
> > die+0x129/0x240
> > do_page_fault+0x3a1/0x670
> > error_code+0x72/0x78
> > __device_release_driver+0x1e/0xa0
> > device_release_driver+0x30/0x50
> > bus_remove_device+0x63/0x90
> > device_del+0x55/0x190
> > del_conn+0xb/0x10 [bluetooth]
> > run_workqueue+0xe1/0x210
> > worker_thread+0x99/0xf0
> > kthread+0x5c/0xa0
> > kernel_thread_helper+0x7/0x18
> >
> > (The remote bluetooth device is a mobile phone which is power off)
> >
> > The reason is that in bus_remobe_dev, the klist_del function will release
> > the device, so just add a get/put pair around the device_del in del_conn.
> >
> > Signed-off-by: Dave Young <[EMAIL PROTECTED]>
> >
> > ---
> > net/bluetooth/hci_sysfs.c |2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff -upr linux/net/bluetooth/hci_sysfs.c
> > linux.new/net/bluetooth/hci_sysfs.c
> > --- linux/net/bluetooth/hci_sysfs.c 2007-12-25 17:45:09.0 +0800
> > +++ linux.new/net/bluetooth/hci_sysfs.c 2007-12-25 17:45:51.0 +0800
> > @@ -319,7 +319,9 @@ void hci_conn_add_sysfs(struct hci_conn
> > static void del_conn(struct work_struct *work)
> > {
> > struct hci_conn *conn = container_of(work, struct hci_conn, work);
> > + get_device(>dev);
> > device_del(>dev);
> > + put_device(>dev);
> > }
> >
> > void hci_conn_del_sysfs(struct hci_conn *conn)
> >
>
> Hi greg,
>
> BTW, Is it a possible bug of driver core or kobject ?
>
In device_del
if(parent)
klist_del() will drop the kref of device
and then in bus_remove_device
klist_del() will drop it again, so the device would be released.
then the following works will oops.
So might my patch is a wrong fix. how about the below one:
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
drivers/base/core.c |2 ++
1 file changed, 2 insertions(+)
diff -upr linux/drivers/base/core.c linux.new/drivers/base/core.c
--- linux/drivers/base/core.c 2007-12-26 11:00:49.0 +0800
+++ linux.new/drivers/base/core.c 2007-12-26 11:01:18.0 +0800
@@ -926,6 +926,7 @@ void device_del(struct device * dev)
struct device * parent = dev->parent;
struct class_interface *class_intf;
+ dev = get_device(dev);
if (parent)
klist_del(>knode_parent);
if (MAJOR(dev->devt))
@@ -966,6 +967,7 @@ void device_del(struct device * dev)
cleanup_device_parent(dev);
kobject_del(>kobj);
put_device(parent);
+ put_device(dev);
}
/**
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] fs/dlm: get rid of unnecessary initialization
default_groups was allocated with kcalloc, so initialization to NULL is unnecessary. Signed-off-by: Joonwoo Park <[EMAIL PROTECTED]> --- fs/dlm/config.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/fs/dlm/config.c b/fs/dlm/config.c index 2f8e3c8..95085d1 100644 --- a/fs/dlm/config.c +++ b/fs/dlm/config.c @@ -414,7 +414,6 @@ static struct config_group *make_cluster(struct config_group *g, cl->group.default_groups = gps; cl->group.default_groups[0] = >ss_group; cl->group.default_groups[1] = >cs_group; - cl->group.default_groups[2] = NULL; cl->cl_tcp_port = dlm_config.ci_tcp_port; cl->cl_buffer_size = dlm_config.ci_buffer_size; @@ -483,7 +482,6 @@ static struct config_group *make_space(struct config_group *g, const char *name) sp->group.default_groups = gps; sp->group.default_groups[0] = >ns_group; - sp->group.default_groups[1] = NULL; INIT_LIST_HEAD(>members); mutex_init(>members_lock); --- Thanks. Joonwoo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/2] fs/ocfs2: get rid of unnecessary initialization
default_groups was allocated with kcalloc, so initialization to NULL is unnecessary. Signed-off-by: Joonwoo Park <[EMAIL PROTECTED]> --- fs/ocfs2/cluster/nodemanager.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/fs/ocfs2/cluster/nodemanager.c b/fs/ocfs2/cluster/nodemanager.c index af2070d..113ef6b 100644 --- a/fs/ocfs2/cluster/nodemanager.c +++ b/fs/ocfs2/cluster/nodemanager.c @@ -840,7 +840,6 @@ static struct config_group *o2nm_cluster_group_make_group(struct config_group *g cluster->cl_group.default_groups = defs; cluster->cl_group.default_groups[0] = >ns_group; cluster->cl_group.default_groups[1] = o2hb_group; - cluster->cl_group.default_groups[2] = NULL; rwlock_init(>cl_nodes_lock); cluster->cl_node_ip_tree = RB_ROOT; cluster->cl_reconnect_delay_ms = O2NET_RECONNECT_DELAY_MS_DEFAULT; --- Thanks. Joonwoo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] ipv4: Update ip command line processing (take II)
Recently the documentation in Documentation/nfsroot.txt was
update to note that in fact ip=off and ip=::off as the
latter is ignored and the default (on) is used.
This was certainly a step in the direction of reducing confusion.
But it seems to me that the code ought to be fixed up so that
ip=::off actually turns off ip autoconfiguration.
This patch also notes more specifically that ip=on (aka ip=::on)
is the default.
Cc: Amos Waterland <[EMAIL PROTECTED]>
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
---
Fri, 21 Dec 2007 16:48:16 +0900
* Removed check on if (name) in ic_proto_name().
It should have been if (*name == '\0'), but even then its
a bit bogus, providing an early exit for a code-path that
is called approximately once.
Index: net-2.6.25/net/ipv4/ipconfig.c
===
--- net-2.6.25.orig/net/ipv4/ipconfig.c 2007-12-26 11:56:20.0 +0900
+++ net-2.6.25/net/ipv4/ipconfig.c 2007-12-26 11:57:04.0 +0900
@@ -1417,6 +1417,10 @@ static int __init ic_proto_name(char *na
if (!strcmp(name, "on") || !strcmp(name, "any")) {
return 1;
}
+ if (!strcmp(name, "off") || !strcmp(name, "none")) {
+ ic_enable = 0;
+ return 1;
+ }
#ifdef CONFIG_IP_PNP_DHCP
else if (!strcmp(name, "dhcp")) {
ic_proto_enabled &= ~IC_RARP;
@@ -1451,12 +1455,6 @@ static int __init ip_auto_config_setup(c
ic_set_manually = 1;
- ic_enable = (*addrs &&
- (strcmp(addrs, "off") != 0) &&
- (strcmp(addrs, "none") != 0));
- if (!ic_enable)
- return 1;
-
if (ic_proto_name(addrs))
return 1;
Index: net-2.6.25/Documentation/nfsroot.txt
===
--- net-2.6.25.orig/Documentation/nfsroot.txt 2007-12-26 11:56:20.0
+0900
+++ net-2.6.25/Documentation/nfsroot.txt2007-12-26 11:57:04.0
+0900
@@ -97,10 +97,6 @@ ip=::: IP address of the client.
Default: Determined using autoconfiguration.
@@ -150,6 +146,7 @@ ip=:::http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: xfs|loop|raid: attempt to access beyond end of device
Hello list, - Original Message - From: "David Chinner" <[EMAIL PROTECTED]> To: "Janos Haar" <[EMAIL PROTECTED]> Cc: Sent: Tuesday, December 25, 2007 10:13 AM Subject: Re: xfs|loop|raid: attempt to access beyond end of device > On Sun, Dec 23, 2007 at 08:21:08PM +0100, Janos Haar wrote: > > Hello, list, > > > > I have a little problem on one of my productive system. > > > > The system sometimes crashed, like this: > > > > Dec 23 08:53:05 Albohacen-global kernel: attempt to access beyond end of > > device > > Dec 23 08:53:05 Albohacen-global kernel: loop0: rw=1, want=50552830649176, > > limit=3085523200 > > Dec 23 08:53:05 Albohacen-global kernel: Buffer I/O error on device loop0, > > logical block 6319103831146 > > Dec 23 08:53:05 Albohacen-global kernel: lost page write due to I/O error on > > loop0 > > So a long way beyond the end of the device. > > [snip soft lockup warnings] > > > Dec 23 09:08:19 Albohacen-global kernel: Filesystem "loop0": Access to block > > zero in inode 397821447 start_block: 0 start_off: 0 blkcnt: 0 extent-state: > > 0 lastx: e4 > > And that's to block zero of the filesystem. Sure signs of a corupted inode > extent btree. We've seen a few of these corruptions on loopback device > reported recently. > > You'll need to unmount and repair the filesystem to make this go away, > but it's hard to know what is causing the btree corruption. Yes, if i do that, the fs clean again, and works well until we moves big amount of data on the storage. But the problem comes out again, and again. If i can, i will try the latest stable kernel, with some loop fixes, but it is not too easy. This is a productive system. > > > Dec 23 09:08:22 Albohacen-global last message repeated 19 times > > > > some more info: > > > > [EMAIL PROTECTED] ~]# uname -a > > Linux Albohacen-global 2.6.21.1 #3 SMP Thu May 3 04:33:36 CEST 2007 x86_64 > > x86_64 x86_64 GNU/Linux > > [EMAIL PROTECTED] ~]# cat /proc/mdstat > > Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] > > [multipath] [faulty] > > md1 : active raid4 sdf2[1] sde2[0] sdd2[5] sdc2[4] sdb2[3] sda2[2] > > 19558720 blocks level 4, 64k chunk, algorithm 0 [6/6] [UU] > > bitmap: 8/239 pages [32KB], 8KB chunk > > > > md2 : active raid4 sdf3[1] sde3[0] sdd3[5] sdc3[4] sdb3[3] sda3[2] > > 1542761600 blocks level 4, 64k chunk, algorithm 0 [6/6] [UU] > > bitmap: 0/148 pages [0KB], 1024KB chunk > > > > md0 : active raid1 sdb1[1] sda1[0] > > 104320 blocks [2/2] [UU] > > > > unused devices: > > [EMAIL PROTECTED] ~]# losetup /dev/loop0 > > /dev/loop0: [0010]:6598 (/dev/md2), encryption blowfish (type 18) > > You're using an encrypted block device? Yes. > What mechanism are you using for > encryption (doesn't appear to be dmcrypt)? No, this is the "old way", not the dmcrypt. This is cryptoloop. > Does it handle readahead bio > cancellation correctly? I dont know exactly, but in my log it is always a write failures! ( i think from rw=1 and lost page write messages) It is the readahead important in this case? > We had similar XFS corruption problems on dmcrypt > between 2.6.14 and ~2.6.20 due to a bug in dmcrypt's failure to handle > aborted readahead I/O correctly Ok, what is the next step? :-) (i will try the latest kernel, if i can) Can i switch to dmcrypt from cryptoloop without rebuild the fs? Thanks a lot, Janos Haar > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.24-rc6-mm1] BUG() at check_irqs_on() in fs/buffer.c .
On Sun, 2007-12-23 at 16:16 +0100, Ingo Molnar wrote: > * Tetsuo Handa <[EMAIL PROTECTED]> wrote: > > > Hello. > > > > I encountered a BUG(). > > I didn't encounter this bug for 2.6.24-rc5-mm1 . > > I guess this bug was introduced between 2.6.24-rc5-mm1 and 2.6.24-rc6-mm1 . > > does the patch below help? > I had a slightly different stack trace, and the patch supplied fix the issue for me also. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Rationalise ACPI backlight implementation
The sysfs backlight class provides no mechanism for querying the
acceptable brightness for a backlight. The ACPI spec states that values
are only valid if they are reported as available by the firmware. Since
we can't provide that information to userspace, instead collapse the
range to the number of actual values that can be set.
Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]>
---
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 521645e..12b2adb 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -296,18 +296,26 @@ static int acpi_video_device_set_state(struct
acpi_video_device *device, int sta
static int acpi_video_get_brightness(struct backlight_device *bd)
{
unsigned long cur_level;
+ int i;
struct acpi_video_device *vd =
(struct acpi_video_device *)bl_get_data(bd);
acpi_video_device_lcd_get_level_current(vd, _level);
- return (int) cur_level;
+ for (i=2; ibrightness->count; i++) {
+ if (vd->brightness->levels[i] == cur_level)
+ /* The first two entries are special - see page 575
+ of the ACPI spec 3.0 */
+ return i-2;
+ }
+ return 0;
}
static int acpi_video_set_brightness(struct backlight_device *bd)
{
- int request_level = bd->props.brightness;
+ int request_level = bd->props.brightness+2;
struct acpi_video_device *vd =
(struct acpi_video_device *)bl_get_data(bd);
- acpi_video_device_lcd_set_level(vd, request_level);
+ acpi_video_device_lcd_set_level(vd,
+ vd->brightness->levels[request_level]);
return 0;
}
@@ -656,7 +664,6 @@ static void acpi_video_device_find_cap(struct
acpi_video_device *device)
kfree(obj);
if (device->cap._BCL && device->cap._BCM && device->cap._BQC &&
max_level > 0){
- unsigned long tmp;
static int count = 0;
char *name;
name = kzalloc(MAX_NAME_LEN, GFP_KERNEL);
@@ -664,11 +671,10 @@ static void acpi_video_device_find_cap(struct
acpi_video_device *device)
return;
sprintf(name, "acpi_video%d", count++);
- acpi_video_device_lcd_get_level_current(device, );
device->backlight = backlight_device_register(name,
NULL, device, _backlight_ops);
- device->backlight->props.max_brightness = max_level;
- device->backlight->props.brightness = (int)tmp;
+ device->backlight->props.max_brightness =
device->brightness->count-3;
+ device->backlight->props.brightness =
acpi_video_get_brightness(device->backlight);
backlight_update_status(device->backlight);
kfree(name);
--
Matthew Garrett | [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.24-rc5-mm 2/3] gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander
> > From: eric miao <[EMAIL PROTECTED]>
> >
> > This patch adds the generic IRQ support for the PCA9539 on-chip GPIOs.
>
> This one bothers me a bit on some technical grounds. One problem is
> that these chips are not designed for reliable IRQ management, so no
> matter what a driver does it can't deliver that. The other is with
> respect to what this code does.
>
>
> As background, here's what the TI docs say about IRQ support on this
> chip. In this area the pca953x parts closely resemble pcf857x ones,
> which I've looked at. I can say that I haven't (yet?) happened
> across boards that use the IRQ mechanism on those '857x parts ...
>
> | Interrupt (INT) Output
> |
> | An interrupt is generated by any rising or falling edge of the port
> | inputs in the input mode.
>
> That's an issue. Your code is trying to emulate all three edge trigger
> modes instead of just "both edges". I've come to believe such emulation
> is not a good thing, since it necessarily loses in some cases.
>
>
> | After time, T(iv), the signal INT is valid.
> | Resetting the interrupt circuit is achieved when data on the port is
> | changed to the original setting,
>
> Another issue. The IRQ will effectively clear by itself, leaving
> no record of exactly what triggered the IRQ.
>
> So IRQs on this chip are problematic at the hardware level, except
> as a lossy "something changed" notification to help avoid polling
> the chip for the current status of input pins.
>
>
> |data is read from the port that
> | generated the interrupt, or in a Stop event.
>
> Another issue. IRQ pulses can be arbitrarily short -- maybe too short
> to register at the host, given glitch removal circuitry! -- when a
> host is performing I/O to the chip while the signal is being raised.
>
>
> | Resetting occurs in the
> | read mode at the acknowledge (ACK) bit or not acknowledge (NACK) bit
> | after the falling edge of the SCL signal. In a Stop event, INT is cleared
> | after the rising edge of SDA. Interrupts that occur during the ACK or
> | NACK clock pulse can be lost (or be very short) due to the resetting
> | of the interrupt during this pulse. Each change of the I/Os after
> | resetting is detected and is transmitted as INT.
> |
> | Reading from or writing to another device does not affect the interrupt
> | circuit, and a pin configured as an output cannot cause an interrupt.
> | Changing an I/O from an output to an input may cause a false interrupt
> | to occur if the state of the pin does not match the contents of the
> | Input Port register. Because each 8-bit port is read independently, the
> | interrupt caused by port 0 is not cleared by a read of port 1, or vice
> versa.
> |
> | INT has an open-drain structure and requires a pullup resistor to VCC.
>
> Now, there *are* I2C GPIO expanders that have non-lossy IRQ support,
> but these '857x and '953x parts don't seem to be in that category.
>
Indeed, the chip does not provide reliable enough IRQ support, so it is
designed to cope with slow signals on our system, where the code below
works OK most of the time, but this is risky.
>
> > ---
> > drivers/gpio/Kconfig | 11 +++-
> > drivers/gpio/pca9539.c | 185
> >
> > 2 files changed, 195 insertions(+), 1 deletions(-)
> >
> > ...
> >
> > --- a/drivers/gpio/pca9539.c
> > +++ b/drivers/gpio/pca9539.c
>
> As to what this code does:
>
>
> > @@ -155,6 +174,158 @@ static int pca9539_init_gpio(struct pca9539_chip
> > *chip)
> > return gpiochip_add(gc);
> > }
> >
> > +#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
> > +/* FIXME: change to schedule_delayed_work() here if reading out of
> > + * registers does not reflect the actual pin levels
> > + */
>
> Docs say reading the input registers does reflect current signal
> levels -- no IRQ latches involved. So that FIXME should go.
>
Docs don't always tell the truth, especially when the chip is connected to
different possible signals, this issue is really observed several times,
though not very frequently. I can remove this til really necessary.
>
> > +
> > +static void pca9539_irq_work(struct work_struct *work)
> > +{
> > + struct pca9539_chip *chip;
> > + uint16_t input, mask, rising, falling;
> > + int ret, i;
> > +
> > + chip = container_of(work, struct pca9539_chip, irq_work);
> > +
> > + ret = pca9539_read_reg(chip, PCA9539_INPUT, );
> > + if (ret < 0)
> > + return;
> > +
> > + mask = (input ^ chip->last_input) & chip->irq_mask;
> > + rising = (input & mask) & chip->irq_rising_edge;
> > + falling = (~input & mask) & chip->irq_falling_edge;
>
> As noted above, this stuff is all lossy. You won't be able to
> issue some IRQs that should be issued.
>
Yes, and the work_queue schedule latency will make this worse, a level
change may have already gone and INT is cleared, while the code here
won't detect this.
>
Re: [PATCH - SH/Dreamcast] CD-Rom (GD-Rom) support for the SEGA Dreamcast
On Sun, Dec 23, 2007 at 07:43:24PM +, Adrian McMenamin wrote:
> This patch adds support for the CD-Rom (the so-called "GD-Rom") on the
> SEGA Dreamcast.
>
Looks quite a bit better. Just a few minor things.
> +static void gdrom_spicommand(void *spi_string, int buflen)
> +{
> + short *cmd = spi_string;
> + /* ensure IRQ_WAIT is set */
> + ctrl_outb(0x08, GDROM_ALTSTATUS_REG);
> + /* specify how many bytes we expect back */
> + ctrl_outb(buflen & 0xFF, GDROM_BCL_REG);
> + ctrl_outb((buflen >> 8) & 0xFF, GDROM_BCH_REG);
> + /* other parameters */
> + ctrl_outb(0, GDROM_INTSEC_REG);
> + ctrl_outb(0, GDROM_SECNUM_REG);
> + ctrl_outb(0, GDROM_ERROR_REG);
> + /* Wait until we can go */
> + gdrom_wait_clrbusy();
> + ctrl_outb(GDROM_COM_PACKET, GDROM_STATUSCOMMAND_REG);
> + while ((ctrl_inb(GDROM_ALTSTATUS_REG) & 0x88) != 8)
> + ; /* wait for DRQ to be set to 1 */
cpu_relax()
> +static int gdrom_get_last_session(struct cdrom_device_info *cd_info,
> struct cdrom_multisession *ms_info)
> +{
> + struct gdromtoc *tocA, *tocB;
> + int fentry, lentry, track, data, tocuse;
> + int err = -ENOMEM;
> + tocA = kzalloc(sizeof(struct gdromtoc), GFP_KERNEL);
> + if (!tocA)
> + goto exit;
> + tocB = kzalloc(sizeof(struct gdromtoc), GFP_KERNEL);
> + if (!tocB)
> + goto clean_tocA;
> + tocuse = 1;
> + err = gdrom_readtoc_cmd(tocB, 1);
> + if (err) {
> + tocuse = 0;
> + err = gdrom_readtoc_cmd(tocA, 0);
> + if (err) {
> + err = -ENXIO;
> + printk(KERN_INFO "Could not get CD table of
> contents\n");
> + goto clean_tocB;
> + }
> + } else
> + printk(KERN_DEBUG "Disk is GDROM\n");
> +
> + kfree(gd.toc);
> +
> + if (tocuse) {
> + gd.toc = tocB;
> + kfree(tocA);
> + } else {
> + gd.toc = tocA;
> + kfree(tocB);
> + }
tocA and tocB seem to be useless, as you're not using them for anything
but gd.toc assignment. If you're catching errors from gdrom_readtoc_cmd()
directly, then just pass in gd.toc in both cases, then you can skip all
of this temporary state stuff entirely.
> + sense_key = sense[1] & 0x0F;
> + switch (sense_key){
> + case 0xB:
> + printk(KERN_INFO "GDROM: Command aborted\n");
> + break;
> + case 0x7:
> + printk(KERN_INFO "GDROM: Data protection error\n");
> + break;
> + case 0x6:
> + printk(KERN_NOTICE "GDROM: Unit needs attention - possible disk
> switch\n");
> + break;
> + case 0x5:
> + printk(KERN_INFO "GDROM: Illegal request - command has
> failed\n");
> + break;
> + case 0x4:
> + printk(KERN_CRIT "GDROM: Hardware error\n");
> + break;
> + case 0x3:
> + printk(KERN_WARNING "GDROM: Disk read error\n");
> + break;
> + case 0x2:
> + printk(KERN_INFO "GDROM: Not ready\n");
> + break;
> + case 0x1:
> + printk(KERN_DEBUG "GDROM: Recovered from error\n");
> + break;
> + case 0x0:
> + /*success - stay silent*/
> + break;
> +
> + default:
> + printk(KERN_INFO "GDROM: Unknown error\n");
> + }
These are all pretty close together, maybe it would be cleaner to throw
these strings in to an array and just use the sense_key as the array
index. Some other drivers do this already.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] sg_ring for scsi
On Friday 21 December 2007 15:37:46 FUJITA Tomonori wrote:
> Some scsi drivers like ips access to sglist in a tricky way.
Indeed. I fail to see how this code works, in fact:
drivers/scsi/ips.c:ips_queue() line 1101
if (ips_is_passthru(SC)) {
ips_copp_wait_item_t *scratch;
/* A Reset IOCTL is only sent by the boot CD in extreme cases.
*/
/* There can never be any system activity ( network or disk ),
but check */
/* anyway just as a good practice.
*/
pt = (ips_passthru_t *) scsi_sglist(SC);
if ((pt->CoppCP.cmd.reset.op_code == IPS_CMD_RESET_CHANNEL) &&
(pt->CoppCP.cmd.reset.adapter_flag == 1)) {
Casting the scsi_sglist(SC) (which ips_is_passthrough treated as a
scatterlist) to an ips_passthrough_t seems completely bogus. It looks like
it wants to access the region mapped by the scatterlist.
There are many signs through the code that it needs a great deal of work:
what is the purpose of sg_break? Why does the code check if kmap_atomic
fails?
===
Convert the ips SCSI driver to sg_ring.
Slightly non-trivial conversion, will need testing.
The first issue is the standard one with "scsi_for_each_sg"
conversion: scsi_for_each_sg will always start i at 0 and increment it
each time around; "sg_ring_for_each" will start i at 0 but it will
return to zero for each new sg_ring entry; you need a separate counter
if you really want a simple increment.
Various flaws in the driver have been maintained.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r 63176a8a6ce3 drivers/scsi/ips.c
--- a/drivers/scsi/ips.cMon Dec 24 17:40:08 2007 +1100
+++ b/drivers/scsi/ips.cWed Dec 26 11:20:52 2007 +1100
@@ -1105,7 +1105,7 @@ static int ips_queue(struct scsi_cmnd *S
/* A Reset IOCTL is only sent by the boot CD in extreme cases.
*/
/* There can never be any system activity ( network or disk ),
but check */
/* anyway just as a good practice.
*/
- pt = (ips_passthru_t *) scsi_sglist(SC);
+ pt = (ips_passthru_t *) SC->sg;
if ((pt->CoppCP.cmd.reset.op_code == IPS_CMD_RESET_CHANNEL) &&
(pt->CoppCP.cmd.reset.adapter_flag == 1)) {
if (ha->scb_activelist.count != 0) {
@@ -1508,8 +1508,8 @@ static int ips_is_passthru(struct scsi_c
if ((SC->cmnd[0] == IPS_IOCTL_COMMAND) &&
(SC->device->channel == 0) &&
(SC->device->id == IPS_ADAPTER_ID) &&
- (SC->device->lun == 0) && scsi_sglist(SC)) {
-struct scatterlist *sg = scsi_sglist(SC);
+ (SC->device->lun == 0) && SC->sg) {
+struct scatterlist *sg = >sg->sg[0];
char *buffer;
/* kmap_atomic() ensures addressability of the user buffer.*/
@@ -1575,12 +1575,12 @@ ips_make_passthru(ips_ha_t *ha, struct s
ips_passthru_t *pt;
int length = 0;
int i, ret;
-struct scatterlist *sg = scsi_sglist(SC);
+struct sg_ring *sg;
METHOD_TRACE("ips_make_passthru", 1);
-scsi_for_each_sg(SC, sg, scsi_sg_count(SC), i)
-length += sg[i].length;
+ sg_ring_for_each(SC->sg, sg, i)
+length += sg->sg[i].length;
if (length < sizeof (ips_passthru_t)) {
/* wrong size */
@@ -2005,7 +2005,7 @@ ips_cleanup_passthru(ips_ha_t * ha, ips_
METHOD_TRACE("ips_cleanup_passthru", 1);
- if ((!scb) || (!scb->scsi_cmd) || (!scsi_sglist(scb->scsi_cmd))) {
+ if ((!scb) || (!scb->scsi_cmd) || (!scb->scsi_cmd->sg)) {
DEBUG_VAR(1, "(%s%d) couldn't cleanup after passthru",
ips_name, ha->host_num);
@@ -2758,16 +2758,18 @@ ips_next(ips_ha_t * ha, int intr)
scb->sg_count = scsi_dma_map(SC);
BUG_ON(scb->sg_count < 0);
if (scb->sg_count) {
- struct scatterlist *sg;
- int i;
+ struct sg_ring *sg;
+ int i, idx;
scb->flags |= IPS_SCB_MAP_SG;
-scsi_for_each_sg(SC, sg, scb->sg_count, i) {
+ idx = 0;
+ sg_ring_for_each(SC->sg, sg, i) {
if (ips_fill_scb_sg_single
- (ha, sg_dma_address(sg), scb, i,
-sg_dma_len(sg)) < 0)
- break;
+ (ha, sg_dma_address(>sg[i]), scb, idx,
+sg_dma_len(>sg[i])) < 0)
+ break;
+ idx++;
}
Re: [PATCH 0/16] lguest: introduce vcpu structure
On Friday 21 December 2007 00:33:40 Glauber de Oliveira Costa wrote: > this patch makes room for the vcpu structure in lguest, already used in > this very same way at lguest64. It's the first part of our plan to > have lguest and lguest64 unified too. Hi Glauber! These patches look really solid, thanks! A few minor things, then I'll apply them and push them for 2.6.25. My only question is whether we should go further and vpu-ify routines like lgread and kill_guest, so that we can avoid more "lg" temporary variables... > When two dogs hang out, you don't have new puppies right in the other day. > Some time has to be elapsed. They have to grow first. In this same spirit, > having these patches _do not_ mean smp guests can be launched (yet) > Much more work is to come, but this is the basic infrastructure. OK, that made me laugh... Thanks! Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [x86] is checkpatch.pl broken
Cyrill Gorcunov wrote: Hi list, by doing cleanup of arch/x86/boot/*.[ch] i found that checkpatch does ignore obvious things. For example, run it over edd.c showed only one warning: BTW, is there someone who is already involved in a such cleanup to eliminate double effort? BTW, it's more than a wee bit rude of you to Cc: a bunch of people but not the listed maintainer of the piece of code you're claiming to be cleaning up. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [x86] is checkpatch.pl broken
Cyrill Gorcunov wrote: Hi list, by doing cleanup of arch/x86/boot/*.[ch] i found that checkpatch does ignore obvious things. For example, run it over edd.c showed only one warning: I'm generally skeptical to the kind of "cleanups" that you seem to be referring to. More often then not they reduce legibility instead of the opposite. --- [EMAIL PROTECTED] linux-2.6.git $ scripts/checkpatch.pl --file arch/x86/boot/edd.c WARNING: externs should be avoided in .c files #45: FILE: x86/boot/edd.c:45: + extern char _end[]; total: 0 errors, 1 warnings, 167 lines checked Your patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. --- but on line 53 we have: mbr_base = (buf_base+sector_size-1) & ~(sector_size-1); so checkpatch should at least worn me about missed space btw math operators. Am I wrong? If checkpatch considered that line to be a problem, I would consider checkpatch to be utterly broken. That line is perfectly legible, and padding in a bunch of spaces would make it LESS so, especially since it would have to be split between lines. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/16] per-vcpu lguest task management
On Friday 21 December 2007 00:33:53 Glauber de Oliveira Costa wrote: > @@ -114,6 +116,19 @@ static int vcpu_start(struct lguest_vcpu *vcpu, int > vcpu_id, * address. */ > lguest_arch_setup_regs(vcpu, start_ip); > > + /* Initialize the queue for the waker to wait on */ > + init_waitqueue_head(>break_wq); > + > + /* We keep a pointer to the Launcher task (ie. current task) for when > + * other Guests want to wake this one (inter-Guest I/O). */ > + vcpu->tsk = current; > + > + /* We need to keep a pointer to the Launcher's memory map, because if > + * the Launcher dies we need to clean it up. If we don't keep a > + * reference, it is destroyed before close() is called. */ > + vcpu->mm = get_task_mm(vcpu->tsk); > + > + Nitpick: extra line? Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/16] map_switcher_in_guest() per-vcpu
On Friday 21 December 2007 00:33:49 Glauber de Oliveira Costa wrote: > The switcher needs to be mapped per-vcpu, because different vcpus > will potentially have different page tables (they don't have to, > because threads will share the same). > > So our first step is the make the function receive a vcpu struct Hmm, I wonder if we should call it lg_vcpu: lguest_vcpu is a little long, and in total adds a fair number of lines to the code :) Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][DOC] Console is utf-8 by default
Samuel Thibault wrote: The console is now by default in UTF-8 mode, so let's document this. BTW, document the needed "vt." prefix. - vt.default_blu= [VT] + default_blu=[VT] Reverse patch? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/16] per-cpu run guest
On Friday 21 December 2007 00:33:44 Glauber de Oliveira Costa wrote:
> @@ -55,11 +55,15 @@ static int user_send_irq(struct lguest *lg, const
> unsigned long __user *input) static ssize_t read(struct file *file, char
> __user *user, size_t size,loff_t*o) {
> struct lguest *lg = file->private_data;
> + struct lguest_vcpu *vcpu = NULL;
> + unsigned int vcpu_id = *o;
>
> /* You must write LHREQ_INITIALIZE first! */
> if (!lg)
> return -EINVAL;
>
> + vcpu = >vcpus[vcpu_id];
> +
Better do a bounds check here!
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/16] make write() operation smp aware
On Friday 21 December 2007 00:33:45 Glauber de Oliveira Costa wrote:
> --- a/drivers/lguest/lguest_user.c
> +++ b/drivers/lguest/lguest_user.c
> @@ -223,14 +223,21 @@ static ssize_t write(struct file *file, const char
...
> /* If you haven't initialized, you must do that first. */
> - if (req != LHREQ_INITIALIZE && !lg)
> - return -EINVAL;
> + if (req != LHREQ_INITIALIZE) {
> + if (!lg)
> + return -EINVAL;
> + vcpu = >vcpus[vcpu_id];
> + if (!vcpu)
> + return -EINVAL;
> + }
Bounds check again...
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/16] adapt lguest launcher to per-cpuness
On Friday 21 December 2007 00:33:42 Glauber de Oliveira Costa wrote:
> + if (!vcpu_id) {
> + /*
> + * Service input, then unset the BREAK to
> + * release the Waker.
> + */
> + handle_input(lguest_fd);
> + if (pwrite(lguest_fd, args, sizeof(args), 0) < 0)
> + err(1, "Resetting break");
> + }
I hate winged comments: those two extra lines, wasted!
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/16] introduce vcpu struct
On Friday 21 December 2007 00:33:41 Glauber de Oliveira Costa wrote:
> this patch introduces a vcpu struct for lguest. In upcoming patches,
> more and more fields will be moved from the lguest struct to the vcpu
Hi Glommer,
> +static inline struct lguest *lg_of_vcpu(struct lguest_vcpu *vcpu)
> +{
> + return container_of((vcpu - vcpu->vcpu_id), struct lguest, vcpus[0]);
> +}
I think this function is a bad idea: it contains implicit UP assumptions which
aren't obvious to the caller. vcpu->lg should do the same thing, no?
Rusty,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Testing RAM from userspace / question about memmap= arguments
On Sat 2007-12-22 12:09:59, Arjan van de Ven wrote: > On Tue, 18 Dec 2007 17:06:24 + > Matthew Bloch <[EMAIL PROTECTED]> wrote: > > > Hi - I'm trying to come up with a way of thoroughly testing every byte > > of RAM from within Linux on amd64 (so that it can be automated better > > than using memtest86+), and came up with an idea which I'm not sure is > > supported or practical. > > > > The obvious problem with testing memory from user space is that you > > can't mlock all of it, so the best you can do is about three quarters, > > and hope that the rest of the memory is okay. > > well... to be honest the more obvious problem will be that you won't be > testing the RAM, you'll be testing the CPU's cache.. over and over again. > > memtest86+ does various magic to basically bypass the caches (by disabling > them ;-)... > Doing that in a live kernel situation, and from userspace to boot.. > that's... and issue. Are you sure? I always assumed that memtest just used patterns bigger than L1/L2 caches... ... and IIRC my celeron testing confirmed it, if I disabled L2 cache in BIOS, memtest behave differently. Anyway, if you can do iopl(), we may as well let you disable caches, but you are right, that will need a kernel patch. 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/
[PATCH][DOC] Console is utf-8 by default
The console is now by default in UTF-8 mode, so let's document this. BTW, document the needed "vt." prefix. Signed-off-by: Samuel Thibault <[EMAIL PROTECTED]> --- Documentation/kernel-parameters.txt.orig2007-12-26 00:01:44.0 +0100 +++ Documentation/kernel-parameters.txt 2007-12-23 22:56:31.0 +0100 @@ -527,30 +527,29 @@ Format: [,] See also Documentation/networking/decnet.txt. - vt.default_blu= [VT] + default_blu=[VT] Format: ,,,..., Change the default blue palette of the console. This is a 16-member array composed of values ranging from 0-255. - vt.default_grn= [VT] + default_grn=[VT] Format: ,,,..., Change the default green palette of the console. This is a 16-member array composed of values ranging from 0-255. - vt.default_red= [VT] + default_red=[VT] Format: ,,,..., Change the default red palette of the console. This is a 16-member array composed of values ranging from 0-255. - vt.default_utf8= - [VT] + default_utf8= [VT] Format=<0|1> Set system-wide default UTF-8 mode for all tty's. - Default is 1, i.e. UTF-8 mode is enabled for all - newly opened terminals. + Default is 0 and by setting to 1, it enables UTF-8 + mode for all newly opened or allocated terminals. dhash_entries= [KNL] Set number of hash buckets for dentry cache. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] sleepy linux
This is RFC. It does not even work for me... it sleeps but it will not
wake up, because SATA wakeup code is missing. Code attached for illustration.
I wonder if this is the right approach? What is right interface to the
drivers?
Sleepy Linux
Copyright 2007 Pavel Machek <[EMAIL PROTECTED]>
GPLv2
Current Linux versions can enter suspend-to-RAM just fine, but only
can do it on explicit request. But suspend-to-RAM is important, eating
something like 10% of power needed for idle system. Starting suspend
manually is not too convinient; it is not an option on multiuser
machine, and even on single user machine, some things are not easy:
1) Download this big chunk in mozilla, then go to sleep
2) Compile this, then go to sleep
3) You can sleep now, but wake me up in 8:30 with mp3 player
Todays hardware is mostly capable of doing better: with correctly set
up wakeups, machine can sleep and successfully pretend it is not
sleeping -- by waking up whenever something interesting happens. Of
course, it is easier on machines not connected to the network, and on
notebook computers.
Requirements:
0) Working suspend-to-RAM, with kernel being able to bring video back.
1) RTC clock that can wake up system
2) Lid that can wake up a system,
or keyboard that can wake up system and does not loose keypress
or special screensaver setup
3) Network card that is either down
or can wake up system on any packet (and not loose too many packets)
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 9663c2a..0f65aa9 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -178,6 +178,7 @@ void cpu_idle(void)
/* endless idle loop with no priority at all */
while (1) {
tick_nohz_stop_sched_tick();
+ detect_idle();
while (!need_resched()) {
void (*idle)(void);
diff --git a/drivers/input/input-polldev.c b/drivers/input/input-polldev.c
index 92b3598..83a8046 100644
--- a/drivers/input/input-polldev.c
+++ b/drivers/input/input-polldev.c
@@ -151,7 +151,7 @@ int input_register_polled_device(struct
INIT_DELAYED_WORK(>work, input_polled_device_work);
if (!dev->poll_interval)
- dev->poll_interval = 500;
+ dev->poll_interval = 5;
input->private = dev;
input->open = input_open_polled_device;
input->close = input_close_polled_device;
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 307c7b5..2deca60 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -263,8 +263,14 @@ void input_event(struct input_dev *dev,
{
unsigned long flags;
- if (is_event_supported(type, dev->evbit, EV_MAX)) {
+ if ((type == EV_SW) && (code == SW_LID)) {
+ int is_closed = value;
+ printk("LID: %d\n", value);
+ if (is_closed) atomic_dec(_needed);
+ else atomic_inc(_needed);
+ }
+ if (is_event_supported(type, dev->evbit, EV_MAX)) {
spin_lock_irqsave(>event_lock, flags);
add_input_randomness(type, code, value);
input_handle_event(dev, type, code, value);
@@ -1575,6 +1581,8 @@ static int __init input_init(void)
goto fail2;
}
+ /* FIXME: should only inc it if LID is open */
+ atomic_inc(_needed);
return 0;
fail2:input_proc_exit();
diff --git a/drivers/rtc/rtc-sysfs.c b/drivers/rtc/rtc-sysfs.c
index 2ae0e83..ba5e806 100644
--- a/drivers/rtc/rtc-sysfs.c
+++ b/drivers/rtc/rtc-sysfs.c
@@ -149,16 +149,6 @@ rtc_sysfs_set_wakealarm(struct device *d
alarm = simple_strtoul(buf, NULL, 0);
if (alarm > now) {
- /* Avoid accidentally clobbering active alarms; we can't
-* entirely prevent that here, without even the minimal
-* locking from the /dev/rtcN api.
-*/
- retval = rtc_read_alarm(rtc, );
- if (retval < 0)
- return retval;
- if (alm.enabled)
- return -EBUSY;
-
alm.enabled = 1;
} else {
alm.enabled = 0;
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 09a309b..991af06 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -246,6 +246,10 @@ #define device_init_wakeup(dev,val) \
device_set_wakeup_enable(dev,val); \
} while(0)
+void detect_idle(void);
+void enter_auto_sleep(void);
+extern atomic_t cpu_needed;
+
#endif /* __KERNEL__ */
#endif /* _LINUX_PM_H */
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 3cdf95b..fc1c7c1 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -22,6 +22,8 @@ #include
#include
#include
+#include
+
#include "power.h"
BLOCKING_NOTIFIER_HEAD(pm_chain_head);
@@ -145,6 +147,8 @@
Re: [PATCH] AMD Thermal Interrupt Support
On Mon, 17 Dec 2007 10:54:53 -0800 (PST) [EMAIL PROTECTED] (Russell Leidich)
wrote:
> Hi,
>
> This patch to 2.6.24-rc5 enables AMD Barcelona CPUs to register thermal
> throttling events as machine checks, in the
> same fashion as the analogous Intel code.
>
> Changed files:
>
> arch/x86/kernel/cpu/mcheck/Makefile
> arch/x86/kernel/cpu/mcheck/mce_amd_64.c
> arch/x86/kernel/cpu/mcheck/mce_intel_64.c
> include/asm-x86/mce.h
>
> New files:
>
> arch/x86/kernel/cpu/mcheck/mce_thermal.c
>
> ...
>
> +extern int num_k8_northbridges;
> +extern struct pci_dev **k8_northbridges;
Please never add extern declarations in C files - find a suitable header
which is seen by the definition and by all users.
> -static int threshold_cpu_callback(struct notifier_block *nfb,
> +static int amd_cpu_callback(struct notifier_block *nfb,
> unsigned long action, void *hcpu)
> {
> /* cpu was unsigned int to begin with */
> unsigned int cpu = (unsigned long)hcpu;
>
> - if (cpu >= NR_CPUS)
> - goto out;
> -
> switch (action) {
> case CPU_ONLINE:
> case CPU_ONLINE_FROZEN:
> threshold_create_device(cpu);
> - break;
> + if (thermal_apic_init_allowed) {
> + /*
> + * We need to run thermal_apic_init() on the core that
> + * just came online. If we're already on that core,
> + * then directly run it. Otherwise
> + * smp_call_function_single() to that core.
> + */
> + if (cpu == get_cpu())
> + thermal_apic_init(NULL);
> + else
> + smp_call_function_single(cpu,
> + _apic_init, NULL, 1, 0);
> + put_cpu();
> + }
smp_call_function_single() already takes care of the
called-on-the-right-cpu case.
> + break;
> case CPU_DEAD:
> case CPU_DEAD_FROZEN:
> threshold_remove_device(cpu);
> @@ -665,12 +692,11 @@ static int threshold_cpu_callback(struct
> default:
> break;
> }
> - out:
> return NOTIFY_OK;
> }
>
> +
> +/*
> + * Enable the delivery of thermal interrupts via the local APIC.
> + */
> +static void thermal_apic_init(void *unused) {
eek, google coding "style" ;)
Please feed patches through scripts/checkpatch.pl.
> + unsigned int apic_lv_therm;
> +
> + /* Set up APIC_LVTTHMR to issue THERMAL_APIC_VECTOR. */
> + apic_lv_therm = apic_read(APIC_LVTTHMR);
> + /*
> + * See if some agent other than this routine has already initialized
> + * APIC_LVTTHMR, i.e. if it's unmasked, but not equal to the value that
> + * we would have programmed, had we been here before on this core.
> + */
> + if ((!(apic_lv_therm & APIC_LVT_MASKED)) && ((apic_lv_therm &
> + (APIC_MODE_MASK | APIC_VECTOR_MASK)) != (APIC_DM_FIXED |
> + THERMAL_APIC_VECTOR))) {
> + unsigned int cpu = smp_processor_id();
afaict this function is called while the calling thread is running
preemptibly. This smp_processor_id() call should have generated a runtime
warning if it was tested with all debug options enabled?
Please see Documentation/SumitChecklist.
> + printk(KERN_CRIT "CPU 0x%x: Thermal monitoring not "
> + "functional.\n", cpu);
> + if ((apic_lv_therm & APIC_MODE_MASK) == APIC_DM_SMI)
> + printk(KERN_DEBUG "Thermal interrupts already "
> + "handled by SMI according to (((local APIC "
> + "base) + 0x330) bit 0x9).\n");
> + else
> + printk(KERN_DEBUG "Thermal interrupts unexpectedly "
> + "enabled at (((local APIC base) + 0x330) bit "
> + "0x10).\n");
> + } else {
> + /*
> + * Configure the Local Thermal Vector Table Entry to issue
> + * issue thermal interrupts to THERMAL_APIC_VECTOR.
> + *
> + * Start by masking off Delivery Mode and Vector.
> + */
> + apic_lv_therm &= ~(APIC_MODE_MASK | APIC_VECTOR_MASK);
> + /* Fixed interrupt, masked for now. */
> + apic_lv_therm |= APIC_LVT_MASKED | APIC_DM_FIXED |
> + THERMAL_APIC_VECTOR;
> + apic_write(APIC_LVTTHMR, apic_lv_therm);
> + /*
> + * The Intel thermal kernel code implies that there may be a
> + * race involving the mask bit, so clear it only now, after
> + * the other bits have settled.
> + */
> + apic_write(APIC_LVTTHMR, apic_lv_therm & ~APIC_LVT_MASKED);
> + }
> +}
> +
> +
> +/*
> + *
Re: [BUG] at mm/slab.c:3320
On Thu, 20 Dec 2007 15:35:41 +0530 "Aneesh Kumar K.V" <[EMAIL PROTECTED]> wrote: > > Linux version 2.6.24-rc5-autokern1 ([EMAIL PROTECTED]) (gcc version 3.4.6 > 20060404 > (Red Hat 3.4.6-9)) #1 SMP PREEMPT Thu Dec 20 04:16:18 EST 2007 > BIOS-provided physical RAM map: > BIOS-e820: - 0009c400 (usable) > BIOS-e820: 0009c400 - 000a (reserved) > BIOS-e820: 000e - 0010 (reserved) > BIOS-e820: 0010 - dff91900 (usable) > BIOS-e820: dff91900 - dff9c340 (ACPI data) > BIOS-e820: dff9c340 - e000 (reserved) > BIOS-e820: fec0 - 0001 (reserved) > BIOS-e820: 0001 - 0002a000 (usable) > Node: 0, start_pfn: 0, end_pfn: 156 > Node: 0, start_pfn: 256, end_pfn: 917393 > Node: 0, start_pfn: 1048576, end_pfn: 2752512 > get_memcfg_from_srat: assigning address to rsdp > RSD PTR v0 [IBM ] > Begin SRAT table scan > CPU 0x00 in proximity domain 0x00 > CPU 0x02 in proximity domain 0x00 > CPU 0x10 in proximity domain 0x00 > CPU 0x12 in proximity domain 0x00 > Memory range 0x0 to 0xE (type 0x0) in proximity domain 0x00 enabled > Memory range 0x10 to 0x12 (type 0x0) in proximity domain 0x00 enabled > CPU 0x20 in proximity domain 0x01 > CPU 0x22 in proximity domain 0x01 > CPU 0x30 in proximity domain 0x01 > CPU 0x32 in proximity domain 0x01 > Memory range 0x12 to 0x2A (type 0x0) in proximity domain 0x01 enabled > acpi20_parse_srat: Entry length value is zero; can't parse any further! > pxm bitmap: 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 > Number of logical nodes in system = 2 > Number of memory chunks in system = 3 > chunk 0 nid 0 start_pfn end_pfn 000e > chunk 1 nid 0 start_pfn 0010 end_pfn 0012 > chunk 2 nid 1 start_pfn 0012 end_pfn 002a > Node: 0, start_pfn: 0, end_pfn: 1179648 > Node: 1, start_pfn: 1179648, end_pfn: 2752512 > Reserving 16384 pages of KVA for lmem_map of node 0 > Shrinking node 0 from 1179648 pages to 1163264 pages > Reserving 22016 pages of KVA for lmem_map of node 1 > Shrinking node 1 from 2752512 pages to 2730496 pages > Reserving total of 38400 pages for numa KVA remap > kva_start_pfn ~ 190464 find_max_low_pfn() ~ 229376 > max_pfn = 2752512 > 9856MB HIGHMEM available. > 896MB LOWMEM available. > min_low_pfn = 1945, max_low_pfn = 229376, highstart_pfn = 229376 > Low memory ends at vaddr f800 > node 0 will remap to vaddr ee80 - fc00 > node 1 will remap to vaddr f280 - 0160 > High memory starts at vaddr f800 > found SMP MP-table at 0009c540 > Zone PFN ranges: > DMA 0 -> 4096 > Normal 4096 -> 229376 > HighMem229376 -> 2752512 > Movable zone start PFN for each node > early_node_map[3] active PFN ranges > 0:0 -> 917504 > 0: 1048576 -> 1163264 > 1: 1179648 -> 2730496 > DMI 2.3 present. > Using APIC driver default > ACPI: RSDP 000FDFC0, 0014 (r0 IBM ) > ACPI: RSDT DFF9C2C0, 0034 (r1 IBMSERVIGIL 1000 IBM 45444F43) > ACPI: FACP DFF9C240, 0074 (r1 IBMSERVIGIL 1000 IBM 45444F43) > ACPI Warning (tbfadt-0442): Optional field "Gpe1Block" has zero address or > length: /4 [20070126] > ACPI: DSDT DFF91900, 4AE5 (r1 IBMSERVIGIL 1000 INTL 2002025) > ACPI: FACS DFF9BFC0, 0040 > ACPI: APIC DFF9C140, 00D2 (r1 IBMSERVIGIL 1000 IBM 45444F43) > ACPI: SRAT DFF9C000, 0128 (r1 IBMSERVIGIL 1000 IBM 45444F43) > ACPI: SSDT DFF96400, 5AE6 (r1 IBMVIGSSDT0 1000 INTL 2002025) > ACPI: PM-Timer IO Port: 0x508 > Marking TSC unstable due to: Summit based system. > Switched to APIC driver `summit'. > ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) > Processor #0 15:2 APIC version 20 > ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled) > Processor #2 15:2 APIC version 20 > ACPI: LAPIC (acpi_id[0x04] lapic_id[0x10] enabled) > Processor #16 15:2 APIC version 20 > ACPI: LAPIC (acpi_id[0x05] lapic_id[0x12] enabled) > Processor #18 15:2 APIC version 20 > ACPI: LAPIC (acpi_id[0x08] lapic_id[0x20] enabled) > Processor #32 15:2 APIC version 20 > ACPI: LAPIC (acpi_id[0x09] lapic_id[0x22] enabled) > Processor #34 15:2 APIC version 20 > ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x30] enabled) > Processor #48 15:2 APIC version 20 > ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x32] enabled) > Processor #50 15:2 APIC version 20 > ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1]) > ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1]) > ACPI: LAPIC_NMI (acpi_id[0x04] dfl dfl lint[0x1]) > ACPI: LAPIC_NMI (acpi_id[0x05] dfl dfl lint[0x1]) > ACPI: LAPIC_NMI (acpi_id[0x08] dfl dfl lint[0x1]) > ACPI: LAPIC_NMI (acpi_id[0x09] dfl dfl lint[0x1]) > ACPI: LAPIC_NMI (acpi_id[0x0c] dfl dfl lint[0x1]) > ACPI: LAPIC_NMI (acpi_id[0x0d] dfl dfl lint[0x1]) > ACPI: IOAPIC (id[0x0e] address[0xfec0] gsi_base[0]) > IOAPIC[0]: apic_id 14, version 17, address
Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
On Thu, 20 Dec 2007 15:11:40 +1100 (EST) James Morris <[EMAIL PROTECTED]> wrote: > > > +#ifdef CONFIG_SECURITY > > > +extern unsigned long mmap_min_addr; > > > +#endif > > > + > > > #include > > > #include > > > #include > > > > Fine by me. > > I'll queue it for -mm & 2.6.25. I don't think we need the ifdef. If someone incorrectly refers to this then they'll get a link-time error rather than a compile-time error (bad). But we lose an ifdef (good). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] add task handling notifier
On Sun, 23 Dec 2007 12:26:21 + Christoph Hellwig <[EMAIL PROTECTED]> wrote: > On Thu, Dec 20, 2007 at 01:11:24PM +, Jan Beulich wrote: > > With more and more sub-systems/sub-components leaving their footprint > > in task handling functions, it seems reasonable to add notifiers that > > these components can use instead of having them all patch themselves > > directly into core files. > > I agree that we probably want something like this. As do some others, > so we already had a few a few attempts at similar things. The first one > is from SGI and called PAGG (http://oss.sgi.com/projects/pagg/) and also > includes allocating per-task data for it's users. Then also from SGI > there has been a simplified version called pnotify that's also available > from the website above. > > Later Matt Helsley had something called "Task Watchers" which lwn has > an article on: http://lwn.net/Articles/208117/. > > For some reason neither ever made a lot of progess (performance > problems?). > I had it in -mm, sorted out all the problems but ended up not pulling the trigger. Problem is, it adds runtime overhead purely for the convenience of kernel programmers, and I don't think that's a good tradeoff. Sprinkling direct calls into a few well-known sites won't kill us, and we've survived this long. Why not keep doing that, and save everyone a few cycles? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/63] ide-cd: redux
On Thu, 20 Dec 2007 01:48:49 +0100 Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: > This patch series is a major rework of the ide-cd driver. woo-hoo. > PS ide-cd Maintainer position is still open... boo-hoo. I wish someone would fix that "The drive appears confused (ireason = 0x%02x)" thing. I had a go a while back but iirc the reporter disappeared on me. It is somewhat common. Or do you think this patch might indeed fix it? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Can't disconnect a USB sound device and connect another
On Sun, 23 Dec 2007 23:36:11 +0100 Victor Hahn <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > ... because it causes lsusb to freeze and gives me this in /var/log/messages: Has this always happened, or is it something we introduced in a recent kernel? > Dec 23 23:27:04 cabrio kernel: usb 2-2: USB disconnect, address 5 > Dec 23 23:27:04 cabrio kernel: PGD 110f2067 PUD 110f3067 PMD 0 > Dec 23 23:27:04 cabrio kernel: CPU 0 > Dec 23 23:27:04 cabrio kernel: Modules linked in: videodev v4l2_common > v4l1_compat snd_rtctimer binfmt_misc rfcomm l2cap bluetooth capability > commoncap ppdev powernow_k8 cpufreq_userspace cpufreq_stats cpufreq_powersave > cpufreq_ondemand freq_table cpufreq_conservative video output sbs container > dock ac battery ext3 jbd mbcache aes_x86_64 ipv6 it87 hwmon_vid parport_pc lp > parport loop snd_mpu401 snd_mpu401_uart snd_usb_audio snd_pcm_oss > snd_mixer_oss snd_pcm snd_seq_dummy snd_page_alloc snd_usb_lib snd_hwdep > snd_seq_oss analog gameport snd_seq_midi snd_rawmidi snd_seq_midi_event > snd_seq snd_timer snd_seq_device snd psmouse button soundcore serio_raw > i2c_nforce2 k8temp i2c_core pcspkr af_packet shpchp pci_hotplug evdev xfs > sha256 twofish_x86_64 twofish_common cbc blkcipher sg ide_cd cdrom sd_mod > usbhid hid sata_nv 8139too floppy ata_generic 8139cp mii libata scsi_mod > amd74xx ide_core forcedeth ehci_hcd ohci_hcd usbcore dm_crypt dm_mirror > dm_snapshot dm_mod thermal processor fan fuse > Dec 23 23:27:04 cabrio kernel: Pid: 2052, comm: khubd Not tainted 2.6.23.11 #1 > Dec 23 23:27:04 cabrio kernel: RIP: 0010:[_end+130488219/2130651808] > [_end+130488219/2130651808] :snd:snd_ctl_dev_disconnect+0x6b/0xb0 > Dec 23 23:27:04 cabrio kernel: RSP: 0018:810037bfdc40 EFLAGS: 00010282 > Dec 23 23:27:04 cabrio kernel: RAX: RBX: 00100100 > RCX: 0018 > Dec 23 23:27:04 cabrio kernel: RDX: 00020004 RSI: 001d > RDI: 810013e98c08 > Dec 23 23:27:04 cabrio kernel: RBP: 8100394631a8 R08: 810037bfc000 > R09: > Dec 23 23:27:04 cabrio kernel: R10: R11: 88281910 > R12: 810039463000 > Dec 23 23:27:04 cabrio kernel: R13: 810039463168 R14: > R15: 810039463000 > Dec 23 23:27:04 cabrio kernel: FS: 2b24912551e0() GS:80533000 > () knlGS:f74b16c0 > Dec 23 23:27:04 cabrio kernel: CS: 0010 DS: 0018 ES: 0018 CR0: > 8005003b > Dec 23 23:27:04 cabrio kernel: CR2: 00100100 CR3: 110f1000 > CR4: 06e0 > Dec 23 23:27:04 cabrio kernel: DR0: DR1: > DR2: > Dec 23 23:27:04 cabrio kernel: DR3: DR6: 0ff0 > DR7: 0400 > Dec 23 23:27:04 cabrio kernel: Process khubd (pid: 2052, threadinfo > 810037bfc000, task 81003d67d0c0) > Dec 23 23:27:04 cabrio kernel: Stack: 810038850d00 > 810039463000 810039463150 > Dec 23 23:27:04 cabrio kernel: 88281e69 > 810038850d00 882821ac > Dec 23 23:27:04 cabrio kernel: > 810039463000 8100394631e0 > Dec 23 23:27:04 cabrio kernel: Call Trace: > Dec 23 23:27:04 cabrio kernel: > [_end+130500873/2130651808] :snd:snd_device_disconnect+0x59/0x90 > Dec 23 23:27:04 cabrio kernel: > [_end+130501708/2130651808] :snd:snd_device_disconnect_all+0x3c/0x70 > Dec 23 23:27:04 cabrio kernel: > [_end+130481675/2130651808] :snd:snd_card_disconnect+0x15b/0x1a0 > Dec 23 23:27:04 cabrio kernel: > [_end+131093678/2130651808] :snd_usb_audio:usb_audio_disconnect+0xae/0x1a0 > Dec 23 23:27:04 cabrio kernel: > [_end+128211869/2130651808] :usbcore:usb_unbind_interface+0x6d/0xe0 > Dec 23 23:27:04 cabrio kernel: [__device_release_driver+130/192] > __device_release_driver+0x82/0xc0 > Dec 23 23:27:04 cabrio kernel: [device_release_driver+51/96] > device_release_driver+0x33/0x60 > Dec 23 23:27:04 cabrio kernel: [bus_remove_device+118/176] > bus_remove_device+0x76/0xb0 > Dec 23 23:27:04 cabrio kernel: [device_del+417/736] device_del+0x1a1/0x2e0 > Dec 23 23:27:04 cabrio kernel: > [_end+128198657/2130651808] :usbcore:usb_disable_device+0x91/0x110 > Dec 23 23:27:04 cabrio kernel: > [_end+128179466/2130651808] :usbcore:usb_disconnect+0xaa/0x150 > Dec 23 23:27:04 cabrio kernel: > [_end+128181649/2130651808] :usbcore:hub_thread+0x401/0xe30 > Dec 23 23:27:04 cabrio kernel: [thread_return+87/1463] > thread_return+0x57/0x5b7 > Dec 23 23:27:04 cabrio kernel: [autoremove_wake_function+0/48] > autoremove_wake_function+0x0/0x30 > Dec 23 23:27:04 cabrio kernel: > [_end+128180624/2130651808] :usbcore:hub_thread+0x0/0xe30 > Dec 23 23:27:04 cabrio kernel: [kthread+75/128] kthread+0x4b/0x80 > Dec 23 23:27:04 cabrio kernel: [child_rip+10/18] child_rip+0xa/0x12 > Dec 23 23:27:04 cabrio kernel: [kthread+0/128] kthread+0x0/0x80 > Dec 23
Re: NFS EINVAL on open(... | O_TRUNC) on 2.6.23.9
On Sun, 23 Dec 2007 12:35:17 +0100 Gianluca Alberici <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I can do better. I have investigated a bit the problem:
>
> 1) The problem arises only with the userspace nfsd (Universal nfsd 2.2).
> I have realized that the latest patches introduced in 2.6.22 have
> changed a lot of things into NFS.
>
> 2) The following code has been debugged with sunrpc.rpc_debug and
> sunrpc.nfs_debug
>
> #include
> #include
> #include
> #include
> #include
>
> int main(int argc, char *argv[]) {
> int fp;
> if ((fp=open("/mnt/tmp/test",O_WRONLY | O_CREAT | O_TRUNC, S_IRWXU ))
> == -1) printf("ERR: %d\n",errno);
> else {
> write(fp, argv[1], strlen(argv[1]));
> printf("OK\n");
> close(fp);
> };
> }
>
>
> 2b) The output
>
> [...]
>
> <8>NFS call setattr
> <8>RPC: new task initialized, procpid 18656
> <8>RPC: allocated task f7bec500
> <8>RPC: 0 looking up UNIX cred
> <8>RPC: 740 __rpc_execute flags=0x480
> <8>RPC: 740 call_start nfs2 proc 2 (sync)
> <8>RPC: 740 call_reserve (status 0)
> <8>RPC: 740 reserved req f1416000 xid 643f3c42
> <8>RPC: 740 call_reserveresult (status 0)
> <8>RPC: 740 call_allocate (status 0)
> <8>RPC: 740 allocated buffer of size 528 at e627b800
> <8>RPC: 740 call_bind (status 0)
> <8>RPC: 740 call_connect xprt f70d4000 is connected
> <8>RPC: 740 call_transmit (status 0)
> <8>RPC: 740 xprt_prepare_transmit
> <8>RPC: 740 xprt_cwnd_limited cong = 0 cwnd = 512
> <8>RPC: 740 call_encode (status 0)
> <8>RPC: 740 marshaling UNIX cred f4efcb40
> <8>RPC: 740 using AUTH_UNIX cred f4efcb40 to wrap rpc data
> <8>RPC: 740 xprt_transmit(148)
> <8>RPC: xs_udp_data_ready...
> <8>RPC: cong 256, cwnd was 512, now 512
> <8>RPC: 740 xid 643f3c42 complete (28 bytes received)
> <8>RPC: xs_udp_send_request(148) = 148
> <8>RPC: 740 xmit complete
> <8>RPC: wake_up_next(f70d4114 "xprt_resend")
> <8>RPC: wake_up_next(f70d40e4 "xprt_sending")
> <8>RPC: 740 call_status (status 28)
> <8>RPC: 740 call_decode (status 28)
> <8>RPC: 740 validating UNIX cred f4efcb40
> <8>RPC: 740 using AUTH_UNIX cred f4efcb40 to unwrap rpc data
> <8>RPC: 740 call_decode result -22
> <8>RPC: 740 return 0, status -22
> <8>RPC: 740 release task
> <8>RPC: freeing buffer of size 528 at e627b800
> <8>RPC: 740 release request f1416000
> <8>RPC: wake_up_next(f70d4174 "xprt_backlog")
> <8>RPC: 740 releasing UNIX cred f4efcb40
> <8>RPC: rpc_release_client(f6f1f880)
> <8>NFS reply setattr: -22
>
> [...]
>
> 3) It turns out the following:
>
> - setattr returns EINVAL due to...
> - RPC call_decode returns status 22
>
> 4) In conclusion in my understanding:
>
> - At present linux nfs filesystem support is not anymore compatible with
> old userspace servers like universal nfsd and crypto filesystems as cfsd
> (which is an nfs server pretty old fashioned).
> - This problem makes UNFSD and CFSD unusable on 2.6.22 and up (this
> doesnt sound good to me)
>
> The question are:
>
> - Is this wanted or is a bug ?
> - Can this be solved with some backwards compat stuff into the kernel or
> all the old packages as UNFSD have to be
> bugfixed/upgraded
> - I have found other strange behaviors of the new NFS filesystem support
> that i am investigating. All are bound to the user of
> old userspace servers onto the new NFS (since 2.6.22). What to do ?
>
I'm not sure what the NFS client's policy is regarding support for
userspace servers. But I'd certainly hope that it is "don't break them".
Which would make this an NFS client regression.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] pcmcia: Add support P2CCLK bit enabler for TI PC1520
On Tue, 18 Dec 2007 18:57:24 +0900 Nobuhiro Iwamatsu <[EMAIL PROTECTED]> wrote:
> There is a device that doesn't work when P2CCLK's bit of TI PC1520 was
> disable.
> This patch supports P2CCLK bit enabler for TI PC1520.
>
> ...
>
> config YENTA_TOSHIBA
> default y
> bool "Special initialization for Toshiba ToPIC bridges" if EMBEDDED
> diff --git a/drivers/pcmcia/ti113x.h b/drivers/pcmcia/ti113x.h
> index d29657b..ea749e8 100644
> --- a/drivers/pcmcia/ti113x.h
> +++ b/drivers/pcmcia/ti113x.h
> @@ -59,6 +59,7 @@
> #define TI122X_SCR_SER_STEP 0xc000
> #define TI122X_SCR_INTRTIE 0x2000
> #define TIXX21_SCR_TIEALL 0x1000
> +#define TI122X_SCR_P2CCLK 0x0800
> #define TI122X_SCR_CBRSVD 0x0040
> #define TI122X_SCR_MRBURSTDN0x8000
> #define TI122X_SCR_MRBURSTUP0x4000
> @@ -822,6 +823,13 @@ static int ti12xx_override(struct yenta_socket *socket)
> printk(KERN_INFO "Yenta: Enabling burst memory read
> transactions\n");
> val |= TI122X_SCR_MRBURSTUP;
> }
> +
> +#ifdef CONFIG_YENTA_TI_P2CCLK
> + if ( !(val & TI122X_SCR_P2CCLK)) {
> + printk(KERN_INFO "Yenta: Clock generated by internal
> oscillator\n");
> + val |= TI122X_SCR_P2CCLK;
> + }
> +#endif
> if (val_orig != val)
> config_writel(socket, TI113X_SYSTEM_CONTROL, val);
It would be much better if we cold do this without the config option: just
detect the appropriate device and make it work.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 004 of 7] md: Allow devices to be shared between md arrays.
On Fri, 14 Dec 2007 17:26:28 +1100 NeilBrown <[EMAIL PROTECTED]> wrote:
> + mddev_unlock(rdev->mddev);
> + ITERATE_MDDEV(mddev, tmp) {
> + mdk_rdev_t *rdev2;
> +
> + mddev_lock(mddev);
> + ITERATE_RDEV(mddev, rdev2, tmp2)
> + if (test_bit(AllReserved, >flags) ||
> + (rdev->bdev == rdev2->bdev &&
> + rdev != rdev2 &&
> + overlaps(rdev->data_offset, rdev->size,
> + rdev2->data_offset, rdev2->size))) {
> + overlap = 1;
> + break;
> + }
> + mddev_unlock(mddev);
> + if (overlap) {
> + mddev_put(mddev);
> + break;
> + }
> + }
eww, ITERATE_MDDEV() and ITERATE_RDEV() are an eyesore.
for_each_mddev() and for_each_rdev() would at least mean the reader doesn't
need to check the implementation when wondering what that `break' is
breaking from.
> #define In_sync 2 /* device is in_sync with rest
> of array */
> #define WriteMostly 4 /* Avoid reading if at all
> possible */
> #define BarriersNotsupp 5 /* BIO_RW_BARRIER is not
> supported */
> +#define AllReserved 6 /* If whole device is reserved
> for
The naming style here is inconsistent.
A task for the keen would be to convert these to an enum and add some
namespacing prefix to them.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 001 of 7] md: Support 'external' metadata for md arrays.
On Fri, 14 Dec 2007 17:26:08 +1100 NeilBrown <[EMAIL PROTECTED]> wrote:
> + if (strncmp(buf, "external:", 9) == 0) {
> + int namelen = len-9;
> + if (namelen >= sizeof(mddev->metadata_type))
> + namelen = sizeof(mddev->metadata_type)-1;
> + strncpy(mddev->metadata_type, buf+9, namelen);
> + mddev->metadata_type[namelen] = 0;
> + if (namelen && mddev->metadata_type[namelen-1] == '\n')
> + mddev->metadata_type[--namelen] = 0;
> + mddev->persistent = 0;
> + mddev->external = 1;
size_t would be a more appropriate type for `namelen'.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc6-mm1
Hi, another one most likely related to the recent NFS_V4 define build error saga: CC fs/nfs/super.o fs/nfs/super.c: In function 'nfs_sb_deactive': fs/nfs/super.c:338: error: 'TASK_NORMAL' undeclared (first use in this function) fs/nfs/super.c:338: error: (Each undeclared identifier is reported only once fs/nfs/super.c:338: error: for each function it appears in.) fs/nfs/super.c: In function 'nfs_put_super': fs/nfs/super.c:349: error: 'TASK_UNINTERRUPTIBLE' undeclared (first use in this function) fs/nfs/super.c:349: error: implicit declaration of function 'schedule' make[3]: *** [fs/nfs/super.o] Error 1 make[2]: *** [fs/nfs] Error 2 make[1]: *** [fs] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.24-rc6-mm1.system-gate-patch' make: *** [debian/stamp-build-kernel] Error 2 This was hand-patched from earlier kernel versions, however I wouldn't think there was any problem due to this (a cleanly extracted version doesn't show any md5sum difference for fs/nfs/super.c). [plus hotfix x86-fix-system-gate-related-crash.patch] I'm circa 120% sure there must be a sched.h include missing there, given the whereabouts of these APIs ;) CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_NFS_V3_ACL is not set CONFIG_NFS_V4=y # CONFIG_NFS_DIRECTIO is not set CONFIG_NFSD=y CONFIG_NFSD_V3=y # CONFIG_NFSD_V3_ACL is not set CONFIG_NFSD_V4=y CONFIG_NFSD_TCP=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=y CONFIG_NFS_COMMON=y i386 [EMAIL PROTECTED], gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) Thanks, Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
checkpatch false ERROR: trailing statements should be on next line
Using v2.6.24-rc6-125-g5356f66, code such as this: if (is_file)/* dirs can be unlinked but chdir'ed to */ err = -ESTALE; produces this false checkpatch error: foo.c:947: ERROR: trailing statements should be on next line I think comments such as the above should be allowed (plus a comment isn't a statement). It's often very useful to put them right on the affected line. Thanks, Erez. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc4 hwmon it87 probe fails
Hi Bjorn,
Le 23/12/2007, "Bjorn Helgaas" <[EMAIL PROTECTED]> a écrit:
>On Sunday 23 December 2007 2:28:05 am Jean Delvare wrote:
>> The problem is that the it87 driver is used on a variety of motherboards,
>> some where the hardware monitoring device I/O ports are reserved by the
>> BIOS, some where they aren't. How am I supposed to deal with this?
>
>I assume you mean some boards describe those ports in ACPI, and some
>don't?
Yes, that's what I meant.
>(...) I think the ideal solution would be to figure out how the
>BIOS writers intended the device to be used, and do that. But the
>documentation may be lacking, and it degenerates into an OEM-specific
>mess. Second-best seems like a PNP quirk that pokes enough to determine
>that a Super I/O device is present, and then reserves resources for
>it. Then we avoid the collision even if it87 isn't present.
I'm not sure what you mean here exactly. We have two different cases:
either the ACPI code did declare the PNP device, or it did not. How do
you unify both? And what "collision" are you talking about?
>> PCI is an entirely different beast. With PCI you know the PCI device ID
>> that is associated with the resources, and for a given device, the
>> resources are always declared (if standard BARs are used) or never
>> declared; there's no "may be". So it's much easier to handle the
>> resources properly.
>
>That's the way PNP is supposed to work, too (more about this below).
Not really. PNP devices may or may not be declared. PCI devices are
always declared. This is a fundamental difference. I'm also not sure
about the PNP IDs, see below.
>> That's not really safe, no. They may overlap with other device resources
>> and prevent those drivers from loading.
>
>True. If that happens, I think we definitely need some kind of DMI-
>based quirk to fix the resources. My points are (a) the quirk needs
>to be at the PNP level; it can't be in a driver, and (b) I'm lazy and
>would wait until a problem happens before implementing it, because I
>know so little about PNP and the specific board, and by waiting, there's
>a chance I'll learn enough to avoid a mistake :-)
But we _do_ have a problem to solve! That's what started this thread.
And we need to solve it before 2.6.24 is released. I'd rather (try to)
do the right thing now rather than going in one direction today and
doing something different next month.
I do agree that the quirks should be done at the PNP level and not in the
it87 driver.
>> Another problem is how do I connect this specific I/O port range of the
>> PNP0C02 device with the it87 driver? I am by far no PNP expert but it
>> looks to me like this PNP device covers more than one actual device, and
>> I/O port ranges do not have labels nor identifiers that would let me
>> find the one that corresponds to the IT87xxF device (if it exists at
>> all.)
>
>The general rule is that you have a PNP device with an identifier
>like PNP0500 that means "16550 UART" and some resources underneath
>it. The PNP ID ("PNP0500") tells the OS which driver to bind to the
>device, and the resources tell the driver where the device is. The
>serial driver in drivers/serial/8250_pnp.c is a good example of the
>"normal" way PNP drivers work.
>
>it87 doesn't fit the model very well because usually the BIOS
>doesn't describe the device explicitly. I think the expectation
>is that the OS will get sensor readings some other way, such as
>by evaluating ACPI "_TMP" methods, or by using some OEM-specific
>ACPI device.
If the IT87xxF device is declared, will it always the same PNP ID on
every system? I fear that the answer is no, in which case I see no
simple way to implement the it87 driver as a PNP driver.
>It's very irritating when ACPI is used to take some device that
>would otherwise be nicely generic and machine-independent, and
>wrap it up into some abstract device that requires an OEM-specific
>driver, but I think that's what's happening here. I suspect it
>has to do with the fact that the BIOS wants to retain some
>control over the device so it can deal with things like thermal
>emergencies, even if the OS driver is missing or broken.
Yes, very irritating. Especially when the ACPI way is not only
system-specific, but also very poor in terms of features compared to
what a native driver can do. This is the main reason why we still write
native drivers for hardware monitoring drivers despite the conflicts
with ACPI that arise on some systems.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH 4/4] [POWERPC] pci: Disable IO/Mem on a device when resources can't be allocated
> This is exactly what's supposed to be happening, but the code is buggy > and nobody noticed :-) (I'm mixing up IORESOURCE_* flags and > PCI_COMMAND_* flags). Thanks for reviewing ! Note that this patch isn't in the series Greg queued up anyway. The powerpc specific bits will be going in via Paulus an I already asked him to drop that specific one until I send a fixed version. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH 4/4] [POWERPC] pci: Disable IO/Mem on a device when resources can't be allocated
On Mon, 2007-12-24 at 00:23 -0700, Grant Grundler wrote:
> On Tue, Dec 18, 2007 at 10:01:15AM +1100, Benjamin Herrenschmidt wrote:
> > This patch changes the PowerPC PCI code to disable IO and/or Memory
> > decoding on a PCI device when a resource of that type failed to be
> > allocated. This is done to avoid having unallocated dangling BARs enabled
> > that might try to decode on top of other devices.
> >
> > If a proper resource is assigned later on, then pci_enable_device{,_io,_mem}
> > will take care of re-enabling decoding.
> >
> > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
>
> > @@ -1062,8 +1065,12 @@ static void __init pcibios_allocate_reso
> > disabled = !(command & PCI_COMMAND_IO);
> > else
> > disabled = !(command & PCI_COMMAND_MEMORY);
> > - if (pass == disabled)
> > - alloc_resource(dev, idx);
> > + if (pass == disabled && alloc_resource(dev, idx)) {
> > + command &= ~(r->flags & (IORESOURCE_IO |
> > +IORESOURCE_MEM));
>
> While this may be ok for PPC, in general, wouldn't we want to only disable
> which ever type of resource that couldn't be allocated?
This is exactly what's supposed to be happening, but the code is buggy
and nobody noticed :-) (I'm mixing up IORESOURCE_* flags and
PCI_COMMAND_* flags). Thanks for reviewing !
> ie make two calls: alloc_resource_io() and alloc_resource_mem() and disable
> the respective flag if the alloc call fails?
No need for 2 calls, just disable whatever type the resource is, but
using the right bits instead of what my code incorrectly does.
> Thus a device which was enable and programmed by BIOS could remain functional
> despite one resource not being allocated.
Yes, that's what intended by the above code, if I didn't have mixed up
the flags.
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH 3/4] pci: Remove pci_enable_device_bars()
On Mon, 2007-12-24 at 00:08 -0700, Grant Grundler wrote: > On Tue, Dec 18, 2007 at 10:01:14AM +1100, Benjamin Herrenschmidt wrote: > > Now that all in-tree users are gone, this removes pci_enable_device_bars() > > completely. > > Almost completely. > Patch below removes pci_enable_device_bars() from Documentation/pci.txt . > > (And I'd be happy to review patches to pci.txt that add > pci_enable_device_io() and _mmio() as well. ) > > Signed-off-by: Grant Grundler <[EMAIL PROTECTED]> Will do. Thanks ! Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] PM: Do not destroy/create devices while suspended
On Tuesday, 25 of December 2007, Rafael J. Wysocki wrote: > On Monday, 24 of December 2007, Alan Stern wrote: > > On Mon, 24 Dec 2007, Rafael J. Wysocki wrote: > > > > > Hi, > > > > > > Some device drivers register CPU hotplug notifiers and use them to destroy > > > device objects when removing the corresponding CPUs and to create these > > > objects > > > when adding the CPUs back. > > > > > > Unfortunately, this is not the right thing to do during > > > suspend/hibernation, > > > since in that cases the CPU hotplug notifiers are called after suspending > > > devices and before resuming them, so the operations in question are > > > carried > > > out on the objects representing suspended devices which shouldn't be > > > unregistered behing the PM core's back. Although right now it usually > > > doesn't > > > lead to any practical complications, it will predictably deadlock if > > > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch is > > > applied. > > > > > > The solution is to prevent drivers from removing/adding devices from > > > within > > > CPU hotplug notifiers during suspend/hibernation using the FROZEN bit > > > in the notifier's action argument. The following three patches modify the > > > MSR, x86-64 MCE and cpuid drivers along these lines. > > > > Do we need to worry about the possibility that when the system wakes up > > from hibernation, the set of usable CPUs might be smaller than it was > > beforehand? > > This is possible in error conditions. > > > Is any special handling needed for this, or is it already accounted for? > > Hm, well. The cleanest thing would be to allow the drivers to remove the > device objects on CPU_UP_CANCELED_FROZEN, which means that we weren't able to > bring the CPU up during a resume, but still that will deadlock with > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch. Hmm. In principle, device objects may be destroyed on CPU_UP_CANCELED_FROZEN without acquiring the device locks, since in fact we know these objects won't be accessed concurrently at that time (the locks are already held by the PM core, but the PM core is not going to actually access the devices before the subsequent resume). Comments? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
On Tuesday, 25 of December 2007, Robert Hancock wrote: > Carlos Corbacho wrote: > > On Tuesday 25 December 2007 13:26:12 Rafael J. Wysocki wrote: > >> Well, citing from the ACPI 2.0 specification, section 9.1.6 Transitioning > >> from the Working to the Sleeping State (which is what we're discussing > >> here): > >> > >> 3. OSPM places all device drivers into their respective Dx state. If the > >> device is enabled for wake, it enters the Dx state associated with the wake > >> capability. If the device is not enabled to wake the system, it enters the > >> D3 state. > >> 4. OSPM executes the _PTS control method, passing an argument that > >> indicates the desired sleeping state (1, 2, 3, or 4 representing S1, S2, > >> S3, and S4). > >> > >> My opinion is that we should follow this part of the specification and so > >> we do. > > > > This is that same section from ACPI 1.0B: > > > > 3. The OS executes the Prepare To Sleep (_PTS) control method, passing an > > argument that indicates the desired sleeping state (1, 2, 3, or 4 > > representing > > S1, S2, S3, and S4). > > > > 4. The OS places all device drivers into their respective Dx state. If the > > device is enabled for wakeup, it enters the Dx state associated with the > > wakeup capability. If the device is not enabled to wakeup the system, it > > enters the D3 state. > > > > The DSDTs in question also claim ACPI 1.0 compatiblity. > > > >> You're wrong, sorry. > > > > No, I'm not entirely wrong - read the 1.0 spec, and read section 7.3.2 of > > the > > ACPI 2.0 spec. > > > > * ACPI 1.0 is very clear - we are breaking the 1.0 spec > > > > * ACPI 2.0 is contradictory - section 7.3.2 repeats 1.0 ad verbatim (which > > is > > what I quote in reply to Robert Hancock), but as you point out, 9.3.2 says > > the opposite. > > > > So, 1.0 and 3.0 are very clear and rather different on this, and 2.0 is > > contradictory (and I presume this is one of the points ACPI 3.0 set out to > > clean up). > > > > I will rescind my point on ACPI 2.0 - I don't know what we should or > > shouldn't > > be doing there, the spec is unclear. > > > > But for ACPI 1.0, we are doing the wrong thing. > > Correct me if I'm wrong, but it appears ACPI 1.0 wants _PTS called > before any devices are suspended, ACPI 2.0 is contradictory, and ACPI > 3.0 says that you can't assume anything about device state. My guess is > that unless Windows has different behavior depending on ACPI version, it > probably has called _PTS before suspending devices all along. Therefore > it would likely be safest to emulate that behavior, no? Well, I don't think so. In fact ACPI 3.0 repeats the 2.0 wording in section 9.1.6 (so the current requirement seems to be to put devices into low power states before calling _PTS) and I _guess_ there was a change in the default behavior of Windows that caused the specification to be modified (I'd bet that was between 2000 and XP or something like this). IMO, we should check which version of the specification we're supposed to follow, on the basis of FADT contents, for example, and follow this one. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] USB serial ftdi_sio - enabling multiple ELV devices, adding EM1010PC
I work with a group of people on a free home automation tool called FHEM.
Some of the users own more than one USB-serial device by ELV. The ftdi_sio
driver has most of the ELV devices disabled by default and needs to be
re-enabled every time you get a new kernel. Additionally a new device (EM
1010 PC - enegry monitor) is missing in the list.
Currently our users have to follow the instructions we provide at
http://www.koeniglich.de/fhem/linux.html
... However, to some users it is too complicated to compile their own kernel
module.
We are aware that you can specify one additional device using the
vendor/product option of the module. But lot's of users own more than one
device.
Signed-off-by: Peter Stark <[EMAIL PROTECTED]>
---
diff -uprN -X linux-2.6.23.12-vanilla/Documentation/dontdiff
linux-2.6.23.12-vanilla/drivers/usb/serial/ftdi_sio.c
linux-2.6.23.12/drivers/usb/serial/ftdi_sio.c
--- linux-2.6.23.12-vanilla/drivers/usb/serial/ftdi_sio.c
2007-12-18 22:55:57.0 +0100
+++ linux-2.6.23.12/drivers/usb/serial/ftdi_sio.c 2007-12-25
17:41:20.0 +0100
@@ -17,6 +17,9 @@
* See http://ftdi-usb-sio.sourceforge.net for upto date testing info
* and extra documentation
*
+ * (25/Dec/2007) Peter Stark
+ * Made ELV devices included by default. Added EM1010PC.
+ *
* (21/Jul/2004) Ian Abbott
* Incorporated Steven Turner's code to add support for the
FT2232C chip.
* The prelimilary port to the 2.6 kernel was by Rus V.
Brushkoff. I have
@@ -471,30 +474,29 @@ static struct usb_device_id id_table_com
{ USB_DEVICE(FTDI_VID, FTDI_IBS_PEDO_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_IBS_PROD_PID) },
/*
-* These will probably use user-space drivers. Uncomment them if
-* you need them or use the user-specified vendor/product module
-* parameters (see ftdi_sio.h for the numbers). Make a fuss if
-* you think the driver should recognize any of them by default.
+* Due to many user requests for multiple ELV devices we enable
+* them by default.
*/
- /* { USB_DEVICE(FTDI_VID, FTDI_ELV_CLI7000_PID) }, */
- /* { USB_DEVICE(FTDI_VID, FTDI_ELV_PPS7330_PID) }, */
- /* { USB_DEVICE(FTDI_VID, FTDI_ELV_TFM100_PID) }, */
- /* { USB_DEVICE(FTDI_VID, FTDI_ELV_UDF77_PID) }, */
- /* { USB_DEVICE(FTDI_VID, FTDI_ELV_UIO88_PID) }, */
- /* { USB_DEVICE(FTDI_VID, FTDI_ELV_UAD8_PID) }, */
- /* { USB_DEVICE(FTDI_VID, FTDI_ELV_UDA7_PID) }, */
- /* { USB_DEVICE(FTDI_VID, FTDI_ELV_USI2_PID) }, */
- /* { USB_DEVICE(FTDI_VID, FTDI_ELV_T1100_PID) }, */
- /* { USB_DEVICE(FTDI_VID, FTDI_ELV_PCD200_PID) }, */
- /* { USB_DEVICE(FTDI_VID, FTDI_ELV_ULA200_PID) }, */
- /* { USB_DEVICE(FTDI_VID, FTDI_ELV_CSI8_PID) }, */
- /* { USB_DEVICE(FTDI_VID, FTDI_ELV_EM1000DL_PID) }, */
- /* { USB_DEVICE(FTDI_VID, FTDI_ELV_PCK100_PID) }, */
- /* { USB_DEVICE(FTDI_VID, FTDI_ELV_RFP500_PID) }, */
- /* { USB_DEVICE(FTDI_VID, FTDI_ELV_FS20SIG_PID) }, */
- /* { USB_DEVICE(FTDI_VID, FTDI_ELV_WS300PC_PID) }, */
- /* { USB_DEVICE(FTDI_VID, FTDI_ELV_FHZ1300PC_PID) }, */
- /* { USB_DEVICE(FTDI_VID, FTDI_ELV_WS500_PID) }, */
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_CLI7000_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_PPS7330_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_TFM100_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_UDF77_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_UIO88_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_UAD8_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_UDA7_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_USI2_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_T1100_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_PCD200_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_ULA200_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_CSI8_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_EM1000DL_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_PCK100_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_RFP500_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_FS20SIG_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_WS300PC_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_FHZ1300PC_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_WS500_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_EM1010PC_PID) },
{ USB_DEVICE(FTDI_VID, LINX_SDMUSBQSS_PID) },
{ USB_DEVICE(FTDI_VID, LINX_MASTERDEVEL2_PID) },
{ USB_DEVICE(FTDI_VID, LINX_FUTURE_0_PID) },
diff -uprN -X linux-2.6.23.12-vanilla/Documentation/dontdiff
linux-2.6.23.12-vanilla/drivers/usb/serial/ftdi_sio.h
linux-2.6.23.12/drivers/usb/serial/ftdi_sio.h
--- linux-2.6.23.12-vanilla/drivers/usb/serial/ftdi_sio.h
2007-12-18 22:55:57.0 +0100
+++ linux-2.6.23.12/drivers/usb/serial/ftdi_sio.h 2007-12-25
17:39:57.0 +0100
@@ -245,6 +245,7 @@
#define FTDI_ELV_WS300PC_PID 0xE0F6 /* PC-Wetterstation (WS 300 PC) */
#define FTDI_ELV_FHZ1300PC_PID
Re: [MIPS] MEM_SDREFCFG is not defined for Alchemy DB1550 (compile fail)
On 12/25/07, Sergei Shtylyov <[EMAIL PROTECTED]> wrote: > > So suspend modes on these boards are not supported? > > Only "Always On" configuration is supported? > > Sleep mode is supported according to the code. But as I've said PM bits > haven't been maintained -- probably since the submission. Thanks! Will it be maintained? Are there any plans? Is there, a missing features list (TODO)? Or this is completely unsupported board? Best Regards, Alon Bar-Lev. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [MIPS] MEM_SDREFCFG is not defined for Alchemy DB1550 (compile fail)
Alon Bar-Lev wrote: PM code is generally broken and unmaintained, so no wonder. I don't remember if anyone has fixed CPU context restoration code (it uses a "skewed" stack frame). So suspend modes on these boards are not supported? Only "Always On" configuration is supported? Sleep mode is supported according to the code. But as I've said PM bits haven't been maintained -- probably since the submission. Best Regards, Alon Bar-Lev. WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
Carlos Corbacho wrote: On Tuesday 25 December 2007 13:26:12 Rafael J. Wysocki wrote: Well, citing from the ACPI 2.0 specification, section 9.1.6 Transitioning from the Working to the Sleeping State (which is what we're discussing here): 3. OSPM places all device drivers into their respective Dx state. If the device is enabled for wake, it enters the Dx state associated with the wake capability. If the device is not enabled to wake the system, it enters the D3 state. 4. OSPM executes the _PTS control method, passing an argument that indicates the desired sleeping state (1, 2, 3, or 4 representing S1, S2, S3, and S4). My opinion is that we should follow this part of the specification and so we do. This is that same section from ACPI 1.0B: 3. The OS executes the Prepare To Sleep (_PTS) control method, passing an argument that indicates the desired sleeping state (1, 2, 3, or 4 representing S1, S2, S3, and S4). 4. The OS places all device drivers into their respective Dx state. If the device is enabled for wakeup, it enters the Dx state associated with the wakeup capability. If the device is not enabled to wakeup the system, it enters the D3 state. The DSDTs in question also claim ACPI 1.0 compatiblity. You're wrong, sorry. No, I'm not entirely wrong - read the 1.0 spec, and read section 7.3.2 of the ACPI 2.0 spec. * ACPI 1.0 is very clear - we are breaking the 1.0 spec * ACPI 2.0 is contradictory - section 7.3.2 repeats 1.0 ad verbatim (which is what I quote in reply to Robert Hancock), but as you point out, 9.3.2 says the opposite. So, 1.0 and 3.0 are very clear and rather different on this, and 2.0 is contradictory (and I presume this is one of the points ACPI 3.0 set out to clean up). I will rescind my point on ACPI 2.0 - I don't know what we should or shouldn't be doing there, the spec is unclear. But for ACPI 1.0, we are doing the wrong thing. Correct me if I'm wrong, but it appears ACPI 1.0 wants _PTS called before any devices are suspended, ACPI 2.0 is contradictory, and ACPI 3.0 says that you can't assume anything about device state. My guess is that unless Windows has different behavior depending on ACPI version, it probably has called _PTS before suspending devices all along. Therefore it would likely be safest to emulate that behavior, no? -- 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/
[x86] is checkpatch.pl broken
Hi list, by doing cleanup of arch/x86/boot/*.[ch] i found that checkpatch does ignore obvious things. For example, run it over edd.c showed only one warning: --- [EMAIL PROTECTED] linux-2.6.git $ scripts/checkpatch.pl --file arch/x86/boot/edd.c WARNING: externs should be avoided in .c files #45: FILE: x86/boot/edd.c:45: + extern char _end[]; total: 0 errors, 1 warnings, 167 lines checked Your patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. --- but on line 53 we have: mbr_base = (buf_base+sector_size-1) & ~(sector_size-1); so checkpatch should at least worn me about missed space btw math operators. Am I wrong? -- BTW, is there someone who is already involved in a such cleanup to eliminate double effort? - Cyrill - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [MIPS] MEM_SDREFCFG is not defined for Alchemy DB1550 (compile fail)
Thank you for your reply! On 12/25/07, Sergei Shtylyov <[EMAIL PROTECTED]> wrote: > PM code is generally broken and unmaintained, so no wonder. I don't > remember if anyone has fixed CPU context restoration code (it uses a "skewed" > stack frame). So suspend modes on these boards are not supported? Only "Always On" configuration is supported? Or there is another method to preserve power? Best Regards, Alon Bar-Lev. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/6] udf: convert UDF_SB_ALLOC_PARTMAPS macro to udf_sb_alloc_partition_maps function
Looks good, 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 0/3] PM: Do not destroy/create devices while suspended
On Monday, 24 of December 2007, Alan Stern wrote: > On Mon, 24 Dec 2007, Rafael J. Wysocki wrote: > > > Hi, > > > > Some device drivers register CPU hotplug notifiers and use them to destroy > > device objects when removing the corresponding CPUs and to create these > > objects > > when adding the CPUs back. > > > > Unfortunately, this is not the right thing to do during suspend/hibernation, > > since in that cases the CPU hotplug notifiers are called after suspending > > devices and before resuming them, so the operations in question are carried > > out on the objects representing suspended devices which shouldn't be > > unregistered behing the PM core's back. Although right now it usually > > doesn't > > lead to any practical complications, it will predictably deadlock if > > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch is applied. > > > > The solution is to prevent drivers from removing/adding devices from within > > CPU hotplug notifiers during suspend/hibernation using the FROZEN bit > > in the notifier's action argument. The following three patches modify the > > MSR, x86-64 MCE and cpuid drivers along these lines. > > Do we need to worry about the possibility that when the system wakes up > from hibernation, the set of usable CPUs might be smaller than it was > beforehand? This is possible in error conditions. > Is any special handling needed for this, or is it already accounted for? Hm, well. The cleanest thing would be to allow the drivers to remove the device objects on CPU_UP_CANCELED_FROZEN, which means that we weren't able to bring the CPU up during a resume, but still that will deadlock with gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch. Greetings, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Suspend code ordering (again) (was: Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM)
On Monday, 24 of December 2007, Linus Torvalds wrote: > > On Mon, 24 Dec 2007, Rafael J. Wysocki wrote: > > > > Well, having considered that for a longer while, I think the AML code is > > referring to a device that we have suspended already, and since it's in a > > low > > power state, it just can't handle the reference. > > > > If that is the case, we'll have to find the device (that should be possible > > using some code instrumentation) and move the suspending of it into the late > > stage. > > Yes. > > In general, I'm personally of the opinion that drivers should *not* > actually go into D3 at all in the regular "->suspend()" phase. It should > be done in ->suspend_late. The early suspend is for saving state and > returning errors. > > Sadly, we've made it a bit too inconvenient to actually do that. Almost > all drivers only do the "->suspend" thing, and the default PCI behaviour > doesn't help us in any way either. > > Anyway, I wonder if a patch like this could make it easier for driver > writers to handle things. It basically does: > > - if you don't have a regular "suspend()" function, we'll just save state >at suspend time. > > - if you don't have a "suspend_late()" function, we'll look at the >current state, and if it's still in PCI_D0, we'll suspend to PCI_D3hot >if it's a regular PCI device (ie not a bridge or something else odd). > > - then, at resume time, by default we don't do anything in the early >resume, but in the late resume we'll undo everything, of course. > > Anyway, with this, most drivers could just remove the > "pci_set_power_state()" call *entirely*, and let the default > suspend_late action power the device down. But if you want to override > that default action, you can either: > > - set the power state in your own ->suspend() routine (either by using >pci_set_power_state(), or by just explicitly setting the state to >unknown with "dev->current_state = PCI_UNKNOWN" > > - have a "late_suspend()" action, which obviously will override the >default action entirely. > > Hmm? Well, as Carlos correctly noticed, the problem is related to the change in the ACPI specification between versions 1.0x and 2.0. Namely, while ACPI 2.0 and later wants us to put devices into low power states before calling _PTS, ACPI 1.0x wants us to do that after calling _PTS. Since we're following the 2.0 and later specifications right now, we're not doing the right thing for the (strictly) ACPI 1.0x-compliant systems. We ought to be able to fix things on the high level, by calling _PTS earlier on systems that claim to be ACPI 1.0x-compliant. That will require us to modify the generic susped code quite a bit and will need to be tested for some time. I'm going to prepare patches to implement this idea targeted for the 2.6.25 time frame. Greetings, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/6] udf: convert UDF_SB_ALLOC_PARTMAPS macro to udf_sb_alloc_partition_maps function
On Tue, Dec 25, 2007 at 11:59:46AM +, Christoph Hellwig wrote:
> On Mon, Dec 24, 2007 at 01:10:19AM +0100, [EMAIL PROTECTED] wrote:
> > @@ -53,6 +53,7 @@
> > #include
> > #include
> > #include
> > +#include
>
> linux/*.h always before asm/*.h
>
> > +static int __must_check udf_sb_alloc_partition_maps(struct super_block
> > *sb, __u32 count)
>
> I think __must_check is primarily for public APIs. But if it really
> helps you here I won't complain.
>
> Also please use u32 over __u32 (dito for the other similar types)
>
> > +{
> > + struct udf_sb_info *sbi = UDF_SB(sb);
> > + sbi->s_partmaps = kzalloc(sizeof(struct udf_part_map) * count,
> > GFP_KERNEL);
> > + if (sbi->s_partmaps != NULL)
> > + sbi->s_partitions = count;
> > + else {
> > + sbi->s_partitions = 0;
> > + udf_error(sb, __FUNCTION__, "Unable to allocate space for %d
> > partition maps", count);
> > + }
> > + return sbi->s_partmaps != NULL ? 0 : -ENOMEM;
> > +}
>
> But please don't introduce new overlong lines in entirely new functions.
>
> Also the code look rather odd, I'd rather write it as:
>
> static int udf_sb_alloc_partition_maps(struct super_block *sb, u32 count)
> {
> struct udf_sb_info *sbi = UDF_SB(sb);
>
> sbi->s_partmaps = kcalloc(count, sizeof(struct udf_part_map),
> GFP_KERNEL);
> if (!sbi->s_partmaps) {
> udf_error(sb, __FUNCTION__,
> "Unable to allocate space for %d partition maps",
> count);
> sbi->s_partitions = 0;
> return -ENOMEM;
> }
>
> sbi->s_partitions = count;
> return 0;
> }
Ok, updated batch below:
--
- convert UDF_SB_ALLOC_PARTMAPS macro to udf_sb_alloc_partition_maps function
- convert kmalloc + memset to kcalloc
- check if kcalloc failed (partially)
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
CC: Christoph Hellwig <[EMAIL PROTECTED]>
---
fs/udf/super.c | 25 +++--
fs/udf/udf_sb.h | 13 -
2 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 246868c..3f5b632 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -52,6 +52,7 @@
#include
#include
#include
+#include
#include
#include
@@ -226,6 +227,24 @@ static void __exit exit_udf_fs(void)
module_init(init_udf_fs)
module_exit(exit_udf_fs)
+static int udf_sb_alloc_partition_maps(struct super_block *sb, u32 count)
+{
+ struct udf_sb_info *sbi = UDF_SB(sb);
+
+ sbi->s_partmaps = kcalloc(count, sizeof(struct udf_part_map),
+ GFP_KERNEL);
+ if (!sbi->s_partmaps) {
+ udf_error(sb, __FUNCTION__,
+ "Unable to allocate space for %d partition maps",
+ count);
+ sbi->s_partitions = 0;
+ return -ENOMEM;
+ }
+
+ sbi->s_partitions = count;
+ return 0;
+}
+
/*
* udf_parse_options
*
@@ -1037,7 +1056,9 @@ static int udf_load_logicalvol(struct super_block *sb,
struct buffer_head *bh,
lvd = (struct logicalVolDesc *)bh->b_data;
- UDF_SB_ALLOC_PARTMAPS(sb, le32_to_cpu(lvd->numPartitionMaps));
+ i = udf_sb_alloc_partition_maps(sb, le32_to_cpu(lvd->numPartitionMaps));
+ if (i != 0)
+ return i;
for (i = 0, offset = 0;
i < sbi->s_partitions && offset < le32_to_cpu(lvd->mapTableLength);
@@ -1242,7 +1263,7 @@ static int udf_process_sequence(struct super_block *sb,
long block,
if (i == VDS_POS_PRIMARY_VOL_DESC) {
udf_load_pvoldesc(sb, bh);
} else if (i == VDS_POS_LOGICAL_VOL_DESC) {
- udf_load_logicalvol(sb, bh, fileset);
+ udf_load_logicalvol(sb, bh, fileset); /* TODO:
check return value */
} else if (i == VDS_POS_PARTITION_DESC) {
struct buffer_head *bh2 = NULL;
if (udf_load_partdesc(sb, bh)) {
diff --git a/fs/udf/udf_sb.h b/fs/udf/udf_sb.h
index 92e6d75..4d3bd77 100644
--- a/fs/udf/udf_sb.h
+++ b/fs/udf/udf_sb.h
@@ -43,19 +43,6 @@ static inline struct udf_sb_info *UDF_SB(struct super_block
*sb)
struct logicalVolIntegrityDescImpUse *udf_sb_lvidiu(struct udf_sb_info *sbi);
-#define UDF_SB_ALLOC_PARTMAPS(X,Y)\
-{\
- struct udf_sb_info *sbi = UDF_SB(X);\
- sbi->s_partmaps = kmalloc(sizeof(struct udf_part_map) * Y, GFP_KERNEL);\
- if (sbi->s_partmaps != NULL) {\
- sbi->s_partitions = Y;\
- memset(sbi->s_partmaps, 0x00, sizeof(struct udf_part_map) * Y);\
- } else {\
- sbi->s_partitions = 0;\
- udf_error(X, __FUNCTION__, "Unable to allocate space for %d
partition maps", Y);\
- }\
[PATCH] ocfs2: convert byte order of constant instead of variable
convert byte order of constant instead of variable
it will be done at compile time (vs run time)
remove unused le32_and_cpu
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Mark Fasheh <[EMAIL PROTECTED]>
CC: Kurt Hackel <[EMAIL PROTECTED]>
---
fs/ocfs2/endian.h |5 -
fs/ocfs2/inode.c |2 +-
2 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/fs/ocfs2/endian.h b/fs/ocfs2/endian.h
index ff25762..1942e09 100644
--- a/fs/ocfs2/endian.h
+++ b/fs/ocfs2/endian.h
@@ -37,11 +37,6 @@ static inline void le64_add_cpu(__le64 *var, u64 val)
*var = cpu_to_le64(le64_to_cpu(*var) + val);
}
-static inline void le32_and_cpu(__le32 *var, u32 val)
-{
- *var = cpu_to_le32(le32_to_cpu(*var) & val);
-}
-
static inline void be32_add_cpu(__be32 *var, u32 val)
{
*var = cpu_to_be32(be32_to_cpu(*var) + val);
diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c
index ebb2bbe..ccea366 100644
--- a/fs/ocfs2/inode.c
+++ b/fs/ocfs2/inode.c
@@ -617,7 +617,7 @@ static int ocfs2_remove_inode(struct inode *inode,
}
di->i_dtime = cpu_to_le64(CURRENT_TIME.tv_sec);
- le32_and_cpu(>i_flags, ~(OCFS2_VALID_FL | OCFS2_ORPHANED_FL));
+ di->i_flags &= cpu_to_le32(~(OCFS2_VALID_FL | OCFS2_ORPHANED_FL));
status = ocfs2_journal_dirty(handle, di_bh);
if (status < 0) {
--
1.5.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ext2/3/4: convert byte order of constant instead of variable
convert byte order of constant instead of variable
it will be done at compile time (vs run time)
ext3/4 bits are #if 0'ed, but someone might copy this code into other places
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
---
fs/ext2/super.c |8 +++-
fs/ext3/super.c |2 +-
fs/ext4/super.c |2 +-
3 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/fs/ext2/super.c b/fs/ext2/super.c
index 154e25f..3ccbe32 100644
--- a/fs/ext2/super.c
+++ b/fs/ext2/super.c
@@ -51,8 +51,7 @@ void ext2_error (struct super_block * sb, const char *
function,
if (!(sb->s_flags & MS_RDONLY)) {
sbi->s_mount_state |= EXT2_ERROR_FS;
- es->s_state =
- cpu_to_le16(le16_to_cpu(es->s_state) | EXT2_ERROR_FS);
+ es->s_state |= cpu_to_le16(EXT2_ERROR_FS);
ext2_sync_super(sb, es);
}
@@ -1100,10 +1099,9 @@ void ext2_write_super (struct super_block * sb)
if (!(sb->s_flags & MS_RDONLY)) {
es = EXT2_SB(sb)->s_es;
- if (le16_to_cpu(es->s_state) & EXT2_VALID_FS) {
+ if (es->s_state & cpu_to_le16(EXT2_VALID_FS)) {
ext2_debug ("setting valid to 0\n");
- es->s_state = cpu_to_le16(le16_to_cpu(es->s_state) &
- ~EXT2_VALID_FS);
+ es->s_state &= cpu_to_le16(~EXT2_VALID_FS);
es->s_free_blocks_count =
cpu_to_le32(ext2_count_free_blocks(sb));
es->s_free_inodes_count =
cpu_to_le32(ext2_count_free_inodes(sb));
es->s_mtime = cpu_to_le32(get_seconds());
diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index cb14de1..92f03b6 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -1220,7 +1220,7 @@ static int ext3_setup_super(struct super_block *sb,
struct ext3_super_block *es,
inconsistencies, to force a fsck at reboot. But for
a plain journaled filesystem we can keep it set as
valid forever! :) */
- es->s_state = cpu_to_le16(le16_to_cpu(es->s_state) & ~EXT3_VALID_FS);
+ es->s_state &= cpu_to_le16(~EXT3_VALID_FS);
#endif
if (!(__s16) le16_to_cpu(es->s_max_mnt_count))
es->s_max_mnt_count = cpu_to_le16(EXT3_DFL_MAX_MNT_COUNT);
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 1ca0f54..cd354e5 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1284,7 +1284,7 @@ static int ext4_setup_super(struct super_block *sb,
struct ext4_super_block *es,
* a plain journaled filesystem we can keep it set as
* valid forever! :)
*/
- es->s_state = cpu_to_le16(le16_to_cpu(es->s_state) & ~EXT4_VALID_FS);
+ es->s_state &= cpu_to_le16(~EXT4_VALID_FS);
#endif
if (!(__s16) le16_to_cpu(es->s_max_mnt_count))
es->s_max_mnt_count = cpu_to_le16(EXT4_DFL_MAX_MNT_COUNT);
--
1.5.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] qla3xxx: convert byte order of constant instead of variable
convert byte order of constant instead of variable
it will be done at compile time (vs run time)
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
---
drivers/net/qla3xxx.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index a579111..c9f8ba4 100644
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -2497,8 +2497,7 @@ static int ql_send_map(struct ql3_adapter *qdev,
if (seg_cnt == 1) {
/* Terminate the last segment. */
- oal_entry->len =
- cpu_to_le32(le32_to_cpu(oal_entry->len) | OAL_LAST_ENTRY);
+ oal_entry->len |= cpu_to_le32(OAL_LAST_ENTRY);
} else {
oal = tx_cb->oal;
for (completed_segs=0; completed_segssize);
}
/* Terminate the last segment. */
- oal_entry->len =
- cpu_to_le32(le32_to_cpu(oal_entry->len) | OAL_LAST_ENTRY);
+ oal_entry->len |= cpu_to_le32(OAL_LAST_ENTRY);
}
return NETDEV_TX_OK;
--
1.5.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] udf: remove some ugly macros
On Tue, Dec 25, 2007 at 11:54:38AM +, Christoph Hellwig wrote: > Looks generally good, but it would be nice if you could avoid > introducing new overly long lines. Then again this really won't be > noticed in udf anyway and it looks like you plan to clean it up later > anyway. Yes, that's what I'm going to do. > (in case it wasn;'t clear count this as an ack from me) > Thanks for review! Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [MIPS] MEM_SDREFCFG is not defined for Alchemy DB1550 (compile fail)
On Tue, Dec 25, 2007 at 01:41:21PM +0300, Sergei Shtylyov wrote: >> When I have: >> CONFIG_MIPS_DB1550 >> CONFIG_SOC_AU1550 >> CONFIG_SOC_AU1X00 >> CONFIG_PM > >> MEM_SDREFCFG is used at: >> arch/mips/au1000/common/power.c::pm_do_freq() > >PM code is generally broken and unmaintained, so no wonder. I don't > remember if anyone has fixed CPU context restoration code (it uses a > "skewed" stack frame). > >> While the MEM_SDREFCFG constant is declare only for CONFIG_SOC_AU1000, >> CONFIG_SOC_AU1500, CONFIG_SOC_AU1100 at: >> include/asm-mips/mach-au1x00/au1000.h > >> Maybe MEM_SDREFCFG should be defined for CONFIG_SOC_AU1X00? > >I've just looked into the Au1550 datasheet and indeed it doesn't have > such register; its SDDRAM controller is not compatible with older SoCs. > >> Or there should be #ifdef for its usage in power.c? > >Looks like you'll have to invent something... ;-) > >> Best Regards, >> Alon Bar-Lev. So I guess it's time to mark the whole PM stuff as BROKEN? Ralf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI: _PTS ordering needs fixing for pre ACPI 3.0 systems (was: Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM)
On Tuesday 25 December 2007 14:07:22 Rafael J. Wysocki wrote: > OK, sorry, the approach is generally reasonable, IMO, but it needs to be a > bit more fine grained. I know, hence this was marked as a hack and not signed off; it's just a demonstration of the general idea with code instead of words. > I'll try to prepare some patches along these lines soon. Much appreciated - I'm much happier with someone who's more familiar with this code than I working on it. -Carlos (Now going back to unwrapping Christmas presents...) -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
On Tuesday, 25 of December 2007, Carlos Corbacho wrote: > On Tuesday 25 December 2007 13:26:12 Rafael J. Wysocki wrote: > > Well, citing from the ACPI 2.0 specification, section 9.1.6 Transitioning > > from the Working to the Sleeping State (which is what we're discussing > > here): > > > > 3. OSPM places all device drivers into their respective Dx state. If the > > device is enabled for wake, it enters the Dx state associated with the wake > > capability. If the device is not enabled to wake the system, it enters the > > D3 state. > > 4. OSPM executes the _PTS control method, passing an argument that > > indicates the desired sleeping state (1, 2, 3, or 4 representing S1, S2, > > S3, and S4). > > > > My opinion is that we should follow this part of the specification and so > > we do. > > This is that same section from ACPI 1.0B: > > 3. The OS executes the Prepare To Sleep (_PTS) control method, passing an > argument that indicates the desired sleeping state (1, 2, 3, or 4 representing > S1, S2, S3, and S4). > > 4. The OS places all device drivers into their respective Dx state. If the > device is enabled for wakeup, it enters the Dx state associated with the > wakeup capability. If the device is not enabled to wakeup the system, it > enters the D3 state. > > The DSDTs in question also claim ACPI 1.0 compatiblity. > > > You're wrong, sorry. > > No, I'm not entirely wrong - read the 1.0 spec, and read section 7.3.2 of the > ACPI 2.0 spec. > > * ACPI 1.0 is very clear - we are breaking the 1.0 spec By following the 2.0 and later ones. Well ... > * ACPI 2.0 is contradictory - section 7.3.2 repeats 1.0 ad verbatim (which is > what I quote in reply to Robert Hancock), but as you point out, 9.3.2 says > the opposite. > > So, 1.0 and 3.0 are very clear and rather different on this, and 2.0 is > contradictory (and I presume this is one of the points ACPI 3.0 set out to > clean up). > > I will rescind my point on ACPI 2.0 - I don't know what we should or > shouldn't > be doing there, the spec is unclear. I think we should follow section 9.3.2 that is explicit and has been reiterated in the 3.0 specification. > But for ACPI 1.0, we are doing the wrong thing. Yes, we are. OK, I think we can rearrange things to call _PTS early for ACPI 1.0x-compliant systems. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI: _PTS ordering needs fixing for pre ACPI 3.0 systems (was: Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM)
On Tuesday, 25 of December 2007, Rafael J. Wysocki wrote: > On Tuesday, 25 of December 2007, Carlos Corbacho wrote: > > Adding Linux-ACPI to CC. > > > > On Tuesday 25 December 2007 00:03:25 Carlos Corbacho wrote: > > > According to the earlier versions of the ACPI spec, Linux is doing the > > > wrong thing - we should call _PTS() before we start powerding down > > > devices, > > > or notifying device drivers to start suspending. > > > > > > So, my limited understanding of what we currently do for ACPI > > > suspend-to-RAM is: > > > > > > 1) Freeze processes/ devices > > > 2) Put all devices into low power mode > > > 3) Execute _PTS() > > > 4) Suspend system > > > > > > So the problem is - our current suspend order is fine for ACPI 3.0 and > > > above, but for pre-3.0 systems, this violates the older specs, where 2) > > > and > > > 3) should be reversed. > > > > The following is a hack to illustrate what I'm getting at (this is > > tested on x86-64) (it's a hack since it does all the ACPI prepare bits > > during set_target() for the pre ACPI 3.0 systems, rather than prepare() - > > whether this can be cleaned up to move out just the _PTS() call, I don't > > know). > > > > It abuses suspend_ops->set_target(), but was the easiest way to quickly > > demonstrate this (since the kerneldoc for set_target() says it will always > > be executed before we suspend the devices). > > Please, don't do that. OK, sorry, the approach is generally reasonable, IMO, but it needs to be a bit more fine grained. I'll try to prepare some patches along these lines soon. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: relation between mmc_request, mmc_data and mmc_command
On Sun, 23 Dec 2007 23:25:26 -0800 "raki john" <[EMAIL PROTECTED]> wrote: > > Does mmc_requeest->stop is equal to mmc_request->data->stop ? > > Does mmc_request is equal to mmc_request->data->mrq ? > > Does mmc_request->data is equal to mmc_request->cmd->data ? > > Does mmc_request is equal to mmc_request->cmd->mrq ? > Yes on all accounts. I don't know the reason for this extreme redundancy. It was there long before I got involved. > > I think Stop command which is part of mmc_request is used for sending stop > command after Multi Block write. is this correct. If stop command fails(CRC > fail, timeout), does this mean card write failed. > It is correct that it is used for multi block writes. But also other open ended transfers. If the stop command fails, then the card will be in an unknown state. The write should have been completed though. Rgds Pierre signature.asc Description: PGP signature
[PATCH] xip: fix get_zeroed_page with __GFP_HIGHMEM
The use of get_zeroed_page() with __GFP_HIGHMEM is invalid.
Use alloc_page() with __GFP_ZERO instead of invalid get_zeroed_page().
(This patch is only compile tested)
Cc: Carsten Otte <[EMAIL PROTECTED]>
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
---
mm/filemap_xip.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
Index: 2.6-git/mm/filemap_xip.c
===
--- 2.6-git.orig/mm/filemap_xip.c
+++ 2.6-git/mm/filemap_xip.c
@@ -25,14 +25,15 @@ static struct page *__xip_sparse_page;
static struct page *xip_sparse_page(void)
{
if (!__xip_sparse_page) {
- unsigned long zeroes = get_zeroed_page(GFP_HIGHUSER);
- if (zeroes) {
+ struct page *page = alloc_page(GFP_HIGHUSER | __GFP_ZERO);
+
+ if (page) {
static DEFINE_SPINLOCK(xip_alloc_lock);
spin_lock(_alloc_lock);
if (!__xip_sparse_page)
- __xip_sparse_page = virt_to_page(zeroes);
+ __xip_sparse_page = page;
else
- free_page(zeroes);
+ __free_page(page);
spin_unlock(_alloc_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: ACPI: _PTS ordering needs fixing for pre ACPI 3.0 systems (was: Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM)
On Tuesday, 25 of December 2007, Carlos Corbacho wrote:
> Adding Linux-ACPI to CC.
>
> On Tuesday 25 December 2007 00:03:25 Carlos Corbacho wrote:
> > According to the earlier versions of the ACPI spec, Linux is doing the
> > wrong thing - we should call _PTS() before we start powerding down devices,
> > or notifying device drivers to start suspending.
> >
> > So, my limited understanding of what we currently do for ACPI
> > suspend-to-RAM is:
> >
> > 1) Freeze processes/ devices
> > 2) Put all devices into low power mode
> > 3) Execute _PTS()
> > 4) Suspend system
> >
> > So the problem is - our current suspend order is fine for ACPI 3.0 and
> > above, but for pre-3.0 systems, this violates the older specs, where 2) and
> > 3) should be reversed.
>
> The following is a hack to illustrate what I'm getting at (this is
> tested on x86-64) (it's a hack since it does all the ACPI prepare bits
> during set_target() for the pre ACPI 3.0 systems, rather than prepare() -
> whether this can be cleaned up to move out just the _PTS() call, I don't
> know).
>
> It abuses suspend_ops->set_target(), but was the easiest way to quickly
> demonstrate this (since the kerneldoc for set_target() says it will always
> be executed before we suspend the devices).
Please, don't do that.
The current code is following the ACPI 2.0 specification (and later) quite
closely and while we can add a special case for the 1.0-copmpilant systems,
the failing ones tend to be supposed to follow ACPI 2.0 (or later).
> drivers/acpi/sleep/main.c | 26 ++
> 1 files changed, 22 insertions(+), 4 deletions(-)
>
>
> diff --git a/drivers/acpi/sleep/main.c b/drivers/acpi/sleep/main.c
> index 96d23b3..89e708b 100644
> --- a/drivers/acpi/sleep/main.c
> +++ b/drivers/acpi/sleep/main.c
> @@ -77,8 +77,19 @@ static int acpi_pm_set_target(suspend_state_t pm_state)
> } else {
> printk(KERN_ERR "ACPI does not support this state: %d\n",
> pm_state);
> - error = -ENOSYS;
> + return -ENOSYS;
> }
> +
> + /*
> + * For ACPI 1.0 and 2.0 systems, we must run the preparation methods
> + * before we put the devices into low power mode.
> + */
> + if (acpi_gbl_FADT.header.revision < 3) {
acpi_gbl_FADT.header.revision is equal to 3 for ACPI 2.0-compilant systems
(section 5.2.8 of the specification).
> + error = acpi_sleep_prepare(acpi_target_sleep_state);
> + if (error)
> + acpi_target_sleep_state = ACPI_STATE_S0;
> + }
> +
> return error;
> }
>
> @@ -91,10 +102,17 @@ static int acpi_pm_set_target(suspend_state_t pm_state)
>
> static int acpi_pm_prepare(void)
> {
> - int error = acpi_sleep_prepare(acpi_target_sleep_state);
> + int error = 0;
>
> - if (error)
> - acpi_target_sleep_state = ACPI_STATE_S0;
> + /*
> + * For ACPI 3.0 or newer systems, we must run the preparation methods
> + * after we put the devices into low power mode.
> + */
> + if (acpi_gbl_FADT.header.revision >= 3) {
Same here (so the comment is wrong).
> + error = acpi_sleep_prepare(acpi_target_sleep_state);
> + if (error)
> + acpi_target_sleep_state = ACPI_STATE_S0;
> + }
>
> return error;
> }
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
On Tuesday 25 December 2007 13:26:12 Rafael J. Wysocki wrote: > Well, citing from the ACPI 2.0 specification, section 9.1.6 Transitioning > from the Working to the Sleeping State (which is what we're discussing > here): > > 3. OSPM places all device drivers into their respective Dx state. If the > device is enabled for wake, it enters the Dx state associated with the wake > capability. If the device is not enabled to wake the system, it enters the > D3 state. > 4. OSPM executes the _PTS control method, passing an argument that > indicates the desired sleeping state (1, 2, 3, or 4 representing S1, S2, > S3, and S4). > > My opinion is that we should follow this part of the specification and so > we do. This is that same section from ACPI 1.0B: 3. The OS executes the Prepare To Sleep (_PTS) control method, passing an argument that indicates the desired sleeping state (1, 2, 3, or 4 representing S1, S2, S3, and S4). 4. The OS places all device drivers into their respective Dx state. If the device is enabled for wakeup, it enters the Dx state associated with the wakeup capability. If the device is not enabled to wakeup the system, it enters the D3 state. The DSDTs in question also claim ACPI 1.0 compatiblity. > You're wrong, sorry. No, I'm not entirely wrong - read the 1.0 spec, and read section 7.3.2 of the ACPI 2.0 spec. * ACPI 1.0 is very clear - we are breaking the 1.0 spec * ACPI 2.0 is contradictory - section 7.3.2 repeats 1.0 ad verbatim (which is what I quote in reply to Robert Hancock), but as you point out, 9.3.2 says the opposite. So, 1.0 and 3.0 are very clear and rather different on this, and 2.0 is contradictory (and I presume this is one of the points ACPI 3.0 set out to clean up). I will rescind my point on ACPI 2.0 - I don't know what we should or shouldn't be doing there, the spec is unclear. But for ACPI 1.0, we are doing the wrong thing. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
On Tuesday, 25 of December 2007, Carlos Corbacho wrote: > On Monday 24 December 2007 22:40:46 Robert Hancock wrote: > > The ACPI spec has the following to say about the _PTS method: > > > > "The platform must not make any assumptions about the state of the > > machine when _PTS is called. For example, operation region accesses that > > require devices to be configured and enabled may not succeed, as these > > devices may be in a non-decoding state due to plug and play or power > > management operations." > > That is from the 3.0 spec though. And it looks like the definition changed > from pre-3.0 to 3.0 and above. > > This is what the 1.0B spec says (and this is also repeated verbatim in 2.0, > 2.0a, 2.0b, and 2.0c): > > "The _PTS control method is executed by the operating system at the beginning > of the sleep process for S1, S2, S3, S4, and for orderly S5 shutdown. The > sleeping state value (1, 2, 3, 4, or 5) is passed to the _PTS control method. > Before the OS notifies native device drivers and prepares the system software > for a system sleeping state, it executes this ACPI control method. Thus, this > control method can be executed a relatively long time before actually > entering the desired sleeping state. In addition, the OS can abort the > sleeping operation without notification to the ACPI driver, in which case > another _PTS would occur some time before the next attempt by the OS to enter > a sleeping state. The _PTS control method cannot modify the current > configuration or power state of any device in the system. For example, _PTS > would simply store the sleep type in the embedded controller in sequencing > the system into a sleep state when the SLP_EN bit is set." > > According to the earlier versions of the ACPI spec, Linux is doing the wrong > thing - we should call _PTS() before we start powerding down devices, or > notifying device drivers to start suspending. Well, citing from the ACPI 2.0 specification, section 9.1.6 Transitioning from the Working to the Sleeping State (which is what we're discussing here): 3. OSPM places all device drivers into their respective Dx state. If the device is enabled for wake, it enters the Dx state associated with the wake capability. If the device is not enabled to wake the system, it enters the D3 state. 4. OSPM executes the _PTS control method, passing an argument that indicates the desired sleeping state (1, 2, 3, or 4 representing S1, S2, S3, and S4). My opinion is that we should follow this part of the specification and so we do. > So, my limited understanding of what we currently do for ACPI suspend-to-RAM > is: > > 1) Freeze processes/ devices > 2) Put all devices into low power mode > 3) Execute _PTS() > 4) Suspend system > > So the problem is - our current suspend order is fine for ACPI 3.0 and above, > but for pre-3.0 systems, this violates the older specs, where 2) and 3) > should be reversed. > > > I would guess some BIOS writers failed to heed this.. > > No, it looks like the BIOS is obeying the older specs, and Linux is at fault > here for breaking the suspend logic of pre ACPI 3.0 systems. You're wrong, sorry. Greetings, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] PM: Do not destroy/create devices while suspended in mce_64.c
On Mon 2007-12-24 01:57:17, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > The x86-64 MCE driver should not attempt to destroy/create a suspended > device. > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> ACK. -- (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: [PATCH 3/3] PM: Do not destroy/create devices while suspended in cpuid.c
On Mon 2007-12-24 01:57:57, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > The cpuid driver should not attempt to destroy/create a suspended > device. > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> ACK. -- (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: [PATCH 1/3] PM: Do not destroy/create devices while suspended in msr.c
On Mon 2007-12-24 01:56:34, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > The MSR driver should not attempt to destroy/create a suspended > device. > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> ACK. -- (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: [PATCH 0/3] PM: Do not destroy/create devices while suspended
On Mon 2007-12-24 10:51:15, Alan Stern wrote: > On Mon, 24 Dec 2007, Rafael J. Wysocki wrote: > > > Hi, > > > > Some device drivers register CPU hotplug notifiers and use them to destroy > > device objects when removing the corresponding CPUs and to create these > > objects > > when adding the CPUs back. > > > > Unfortunately, this is not the right thing to do during suspend/hibernation, > > since in that cases the CPU hotplug notifiers are called after suspending > > devices and before resuming them, so the operations in question are carried > > out on the objects representing suspended devices which shouldn't be > > unregistered behing the PM core's back. Although right now it usually > > doesn't > > lead to any practical complications, it will predictably deadlock if > > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch is applied. > > > > The solution is to prevent drivers from removing/adding devices from within > > CPU hotplug notifiers during suspend/hibernation using the FROZEN bit > > in the notifier's action argument. The following three patches modify the > > MSR, x86-64 MCE and cpuid drivers along these lines. > > Do we need to worry about the possibility that when the system wakes up > from hibernation, the set of usable CPUs might be smaller than it was > beforehand? Is any special handling needed for this, or is it already > accounted for? That should not happen... but it does in some error cases so handling it would be a bonus. Waking up with one cpu out of 8 is bad, but still way better than not waking up at all ;-). 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/
TOMOYO Linux Security Goal
This document is intended to specify the security goal that TOMOYO Linux is trying to achieve, so that users can evaluate whether TOMOYO Linux will meet their needs, and kernel developers can evaluate whether TOMOYO Linux deserved to be in-tree. 1. About TOMOYO Linux Project Homepage: http://tomoyo.sourceforge.jp/index.html.en Project Wiki: http://elinux.org/TomoyoLinux TOMOYO Linux is a DIY tool for understanding and protecting your system. TOMOYO Linux policy definitions are absolutely readable to Linux users, and TOMOYO Linux supports unique policy learning mechanism which automatically gathers information and arranges the results as policy definitions. These things made it possible for users to write policy from scratch. Troubleshooting can be done by users. We put some TOMOYO Linux policy examples on our web site. http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/etch/domain_policy.conf?v=policy-sample 2. TOMOYO Linux Security Goal The TOMOYO Linux's security goal is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool for security professional but for average users and administrators. 3. Our Approach To meet the above goal, TOMOYO Linux attempts to make the system where everything is prearranged in an easy-to-understand way. * Make the all subject's all access requests that will occur at least once during the lifetime of the kernel known in advance. * Let the administrator understand what access requests will each subject raise in his/her system and write policy which only allows expected and desirable access requests for his/her needs. Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications that the system hosts. The threat is that an attacker can cause a vulnerable application to do something unexpected and undesirable. TOMOYO Linux addresses this threat by recording all applications' behaviors in the test environment and forcing all applications behave within recorded behaviors in the production environment. TOMOYO Linux has a unique concept of "process invocation history" (in short, PIH). The PIH is a developmental lineage of a process. When a process executes a program, the process creates a copy with fork() and replace the copy with execve(). TOMOYO Linux appends the pathname of the executed program to the PIH of the replaced process, and associates process's PIH (stored in task_struct) with a domain. As a result, the context switching (a.k.a. domain transition) is unidirectional. This rule allows administrator distinguish and manage fine-grained context. Domain transition forms tree structure like a directory tree of filesystems. Each domain has different set of permissions that are essential for that domain. 4. Things you can do with TOMOYO Linux. Create policy from scratch. You want to use ready-made policy files supplied by somebody else because testing all paths needed for your usage sounds boring? OK, then you can choose other implementations that provide ready-made policy files, but you should check whether these files contain enough permissions for your usage or not. It is inevitable thing to test all paths needed for your usage if you want to use white listing access control. Also, ready-made policy files tend to contain redundant permissions for your usage which often leads to serious problem. TOMOYO Linux is a DIY tool for understanding and protecting your Linux box. TOMOYO Linux's "learning mode" will automatically generate policy files with necessary and sufficient permissions for you. Understand all possible requests. TOMOYO Linux reports what is happening within your Linux box. You can have the security of knowing that no unexpected requests arise, if you have tested all paths needed for your usage. Please remember, we are not saying that "You can have the security of knowing that no unexpected results happen". Although TOMOYO Linux attempts to filter the request as hard as possible, TOMOYO Linux can't guarantee the result. Analyze system's behavior. TOMOYO Linux resembles to /usr/bin/strace . TOMOYO Linux reports what programs are executed from each program and what files/networks are accessed by each program. You can use TOMOYO Linux for analyzing application's behavior if you want to know "which configuration file does this daemon read?", "what port numbers does this daemon require?" and so on. This helps debugging program's behaviors and writing manuals. TOMOYO Linux is also applicable for educational use. Provide per application firewall. It is userland applications' businesses to perform pathname based access control, but they sometimes make mistakes which are known as OS command injection vulnerability or buffer overflow vulnerability. TOMOYO Linux assists this access control in kernel space to reduce the damage by
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
Pavel, On Tuesday 25 December 2007 12:12:31 Pavel Machek wrote: > > The patch is fine by me, so if anyone has objections, please speak up. > > Just.. I have been running with very similar patch for few years... it > fixes few prototype machines I have here. I've withdrawn the patch since it doesn't actually fix the issue (turns out it's actually a bug in Linux's handling of suspend-to-RAM for ACPI 1.0 and 2.0 systems). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/38] arch/alpha: Use time_before, time_before_eq, etc.
On Mon 2007-12-24 15:16:46, Julia Lawall wrote:
> From: Julia Lawall <[EMAIL PROTECTED]>
>
> The functions time_before, time_before_eq, time_after, and time_after_eq
> are more robust for comparing jiffies against other values.
>
> A simplified version of the semantic patch making this change is as follows:
> (http://www.emn.fr/x-info/coccinelle/)
>
> //
> @ change_compare_np @
> expression E;
> @@
>
> (
> - jiffies <= E
> + time_before_eq(jiffies,E)
> |
> - jiffies >= E
> + time_after_eq(jiffies,E)
> |
> - jiffies < E
> + time_before(jiffies,E)
> |
> - jiffies > E
> + time_after(jiffies,E)
> )
Maybe you should create new macro so that you don't have to pass the
jiffies all the time?
> if (!test_thread_flag (TIF_UAC_NOPRINT)) {
> - if (cnt >= 5 && jiffies - last_time > 5*HZ) {
> + if (cnt >= 5 && time_after(jiffies, last_time + 5*HZ)) {
&& time_after_now(last_time + 5*HZ)
or something?
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: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
Hi! > On Sunday, 23 of December 2007, Carlos Corbacho wrote: > > Fix suspend-to-RAM on nForce 4 (CK804) boards by increasing > > PCIBIOS_MIN_IO. > > > > Fixes kernel bugzilla #9528 > > > > Problem: > > > > Linus' patch (52ade9b3b97fd3bea42842a056fe0786c28d0555) to re-order > > suspend (and fix fall out from Rafael's earlier suspend reordering work) > > broke suspend-to-RAM on nForce 4 (CK804) boards. > > > > Why: > > > > After debugging _PTS() in the DSDT, it turns out these nVidia boards are > > trying to write to an IO port > 0x1000 (0x142E) during suspend. Before the > > re-ordering, we got away with this. > > > > After the afore mentioned commit, we started hitting the PCIBIOS_MIN_IO > > limit and suspend then broke on these machines (the machine simply hangs > > when it reaches the 0x142E IO port write during suspend-to-RAM). > > > > There was some previous work in the PCIBIOS_MIN_IO area over two years ago > > (71db63acff69618b3d9d3114bd061938150e146b) which bumped this to 0x4000, > > but this was reverted (2ba84684e8cf6f980e4e95a2300f53a505eb794e) after > > causing new and entirely different problems on another nForce board. > > > > 0x1500 has been picked here as a nice, round and more conservative value > > than 0x4000, and which covers 0x142E. > > The patch is fine by me, so if anyone has objections, please speak up. Just.. I have been running with very similar patch for few years... it fixes few prototype machines I have here. > > diff --git a/include/asm-x86/pci.h b/include/asm-x86/pci.h > > index e883619..03cb123 100644 > > --- a/include/asm-x86/pci.h > > +++ b/include/asm-x86/pci.h > > @@ -46,7 +46,7 @@ extern unsigned int pcibios_assign_all_busses(void); > > #define pcibios_scan_all_fns(a, b) 0 > > > > extern unsigned long pci_mem_start; > > -#define PCIBIOS_MIN_IO 0x1000 > > +#define PCIBIOS_MIN_IO 0x1500 > > #define PCIBIOS_MIN_MEM(pci_mem_start) > > > > #define PCIBIOS_MIN_CARDBUS_IO 0x4000 -- (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: [PATCH 3/6] udf: convert UDF_SB_ALLOC_PARTMAPS macro to udf_sb_alloc_partition_maps function
On Mon, Dec 24, 2007 at 01:10:19AM +0100, [EMAIL PROTECTED] wrote:
> @@ -53,6 +53,7 @@
> #include
> #include
> #include
> +#include
linux/*.h always before asm/*.h
> +static int __must_check udf_sb_alloc_partition_maps(struct super_block *sb,
> __u32 count)
I think __must_check is primarily for public APIs. But if it really
helps you here I won't complain.
Also please use u32 over __u32 (dito for the other similar types)
> +{
> + struct udf_sb_info *sbi = UDF_SB(sb);
> + sbi->s_partmaps = kzalloc(sizeof(struct udf_part_map) * count,
> GFP_KERNEL);
> + if (sbi->s_partmaps != NULL)
> + sbi->s_partitions = count;
> + else {
> + sbi->s_partitions = 0;
> + udf_error(sb, __FUNCTION__, "Unable to allocate space for %d
> partition maps", count);
> + }
> + return sbi->s_partmaps != NULL ? 0 : -ENOMEM;
> +}
But please don't introduce new overlong lines in entirely new functions.
Also the code look rather odd, I'd rather write it as:
static int udf_sb_alloc_partition_maps(struct super_block *sb, u32 count)
{
struct udf_sb_info *sbi = UDF_SB(sb);
sbi->s_partmaps = kcalloc(count, sizeof(struct udf_part_map),
GFP_KERNEL);
if (!sbi->s_partmaps) {
udf_error(sb, __FUNCTION__,
"Unable to allocate space for %d partition maps",
count);
sbi->s_partitions = 0;
return -ENOMEM;
}
sbi->s_partitions = count;
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] udf: remove some ugly macros
Looks generally good, but it would be nice if you could avoid introducing new overly long lines. Then again this really won't be noticed in udf anyway and it looks like you plan to clean it up later anyway. (in case it wasn;'t clear count this as an ack from me) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in
From: Arjan van de Ven <[EMAIL PROTECTED]>
Subject: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in
On PCs, PCI extended configuration space (4Kb) is riddled with problems
associated with the memory mapped access method (MMCONFIG). At the same
time, there are very few machines that actually need or use this extended
configuration space.
At this point in time, the only sensible action is to make access to the
extended configuration space an opt-in operation for those device drivers
that need/want access to this space, as well as for those userland
diagnostics utilities that (on admin request) want to access this space.
It's inevitable that this is done per device rather than per bus; we'll
be needing per device PCI quirks to turn this extended config space off
over time no matter what; in addition, it gives the least amount of surprise:
loading a driver for a device only impacts that one device, not a whole bus
worth of devices (although it'll be common to have one physical device per
bus on PCI-E).
The (desireable) side-effect of this patch is that all enumeration is done
using normal configuration cycles.
The patch below splits the lower level PCI config space operation (which
operate on a bus) in two: one that normally only operates on traditional
space, and one that gets used after the driver has opted in to using the
extended configuration space. This has lead to a little code duplication,
but it's not all that bad (most of it is prototypes in headers and such).
Architectures that have a solid reliable way to get to extended configuration
space can just keep doing what they do now and allow extended space access
from the "traditional" bus ops, and just not fill in the new bus ops.
(This could include x86 for, say, BIOS year 2009 and later, but doesn't
right now)
This patch also adds a sysfs property for each device into which root can
write a '1' to enable extended configuration space. The kernel will print
a notice into dmesg when this happens (including the name of the app) so that
if the system crashes as a result of this action, the user can know what
action/tool caused it.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
arch/x86/pci/common.c | 23 ++
arch/x86/pci/init.c| 10 +
arch/x86/pci/mmconfig_32.c |2 -
arch/x86/pci/mmconfig_64.c |2 -
arch/x86/pci/pci.h |2 +
drivers/pci/access.c | 46
drivers/pci/pci-sysfs.c| 31 +
drivers/pci/pci.c | 28 ++
include/linux/pci.h| 47 +++--
9 files changed, 183 insertions(+), 8 deletions(-)
Index: linux-2.6.24-rc5/arch/x86/pci/common.c
===
--- linux-2.6.24-rc5.orig/arch/x86/pci/common.c
+++ linux-2.6.24-rc5/arch/x86/pci/common.c
@@ -26,6 +26,7 @@ int pcibios_last_bus = -1;
unsigned long pirq_table_addr;
struct pci_bus *pci_root_bus;
struct pci_raw_ops *raw_pci_ops;
+struct pci_raw_ops *raw_pci_ops_extcfg;
static int pci_read(struct pci_bus *bus, unsigned int devfn, int where, int
size, u32 *value)
{
@@ -39,9 +40,31 @@ static int pci_write(struct pci_bus *bus
devfn, where, size, value);
}
+static int pci_read_ext(struct pci_bus *bus, unsigned int devfn, int where,
int size, u32 *value)
+{
+ if (raw_pci_ops_extcfg)
+ return raw_pci_ops_extcfg->read(pci_domain_nr(bus), bus->number,
+devfn, where, size, value);
+ else
+ return raw_pci_ops->read(pci_domain_nr(bus), bus->number,
+devfn, where, size, value);
+}
+
+static int pci_write_ext(struct pci_bus *bus, unsigned int devfn, int where,
int size, u32 value)
+{
+ if (raw_pci_ops_extcfg)
+ return raw_pci_ops_extcfg->write(pci_domain_nr(bus),
bus->number,
+ devfn, where, size, value);
+ else
+ return raw_pci_ops->write(pci_domain_nr(bus), bus->number,
+ devfn, where, size, value);
+}
+
struct pci_ops pci_root_ops = {
.read = pci_read,
.write = pci_write,
+ .readext = pci_read_ext,
+ .writeext = pci_write_ext,
};
/*
Index: linux-2.6.24-rc5/drivers/pci/pci.c
===
--- linux-2.6.24-rc5.orig/drivers/pci/pci.c
+++ linux-2.6.24-rc5/drivers/pci/pci.c
@@ -752,6 +752,34 @@ int pci_enable_device(struct pci_dev *de
return pci_enable_device_bars(dev, (1 << PCI_NUM_RESOURCES) - 1);
}
+/**
+ * pci_enable_ext_config - Enable extended (4K) config space accesses
+ * @dev: PCI device to be changed
+ *
+ * Enable extended (4Kb) configuration space accesses for a device.
+ * Extended config space is available for PCI-E devices and can
Re: [MIPS] MEM_SDREFCFG is not defined for Alchemy DB1550 (compile fail)
Hello. Alon Bar-Lev wrote: When I have: CONFIG_MIPS_DB1550 CONFIG_SOC_AU1550 CONFIG_SOC_AU1X00 CONFIG_PM MEM_SDREFCFG is used at: arch/mips/au1000/common/power.c::pm_do_freq() PM code is generally broken and unmaintained, so no wonder. I don't remember if anyone has fixed CPU context restoration code (it uses a "skewed" stack frame). While the MEM_SDREFCFG constant is declare only for CONFIG_SOC_AU1000, CONFIG_SOC_AU1500, CONFIG_SOC_AU1100 at: include/asm-mips/mach-au1x00/au1000.h Maybe MEM_SDREFCFG should be defined for CONFIG_SOC_AU1X00? I've just looked into the Au1550 datasheet and indeed it doesn't have such register; its SDDRAM controller is not compatible with older SoCs. Or there should be #ifdef for its usage in power.c? Looks like you'll have to invent something... ;-) Best Regards, Alon Bar-Lev. WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ide: add ide_dump_identify() debug helper
Hello. Bartlomiej Zolnierkiewicz wrote: * Add ide_dump_identify() debug helper for dumping raw identify data in the hdparm friendly format (== the identify data can be extracted from dmesg output and passed to hdparm --Istdin). * Dump identify data in ide-probe.c::do_identify() if DEBUG is enabled. Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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][PATCH -mm] bluetooth : rfcomm add get/put device in del_conn
On Dec 25, 2007 6:03 PM, Dave Young <[EMAIL PROTECTED]> wrote:
> Due to 2.6.24-rc6-mm1 kernel changes (maybe kobject or driver core), If I
> exec:
>
> rfcomm connect 0 1
>
> kernel will oops after connect timeout.
>
> hand copy some oops text:
>
> EIP is at driver_sysfs_remove+0x1a/0x40
> Call Trace:
> show_trace_log_lvl+0x1a/0x30
> show_stack_log_lvl+0x9a/0xc0
> show_registers+0xc7/0x270
> die+0x129/0x240
> do_page_fault+0x3a1/0x670
> error_code+0x72/0x78
> __device_release_driver+0x1e/0xa0
> device_release_driver+0x30/0x50
> bus_remove_device+0x63/0x90
> device_del+0x55/0x190
> del_conn+0xb/0x10 [bluetooth]
> run_workqueue+0xe1/0x210
> worker_thread+0x99/0xf0
> kthread+0x5c/0xa0
> kernel_thread_helper+0x7/0x18
>
> (The remote bluetooth device is a mobile phone which is power off)
>
> The reason is that in bus_remobe_dev, the klist_del function will release the
> device, so just add a get/put pair around the device_del in del_conn.
>
> Signed-off-by: Dave Young <[EMAIL PROTECTED]>
>
> ---
> net/bluetooth/hci_sysfs.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff -upr linux/net/bluetooth/hci_sysfs.c linux.new/net/bluetooth/hci_sysfs.c
> --- linux/net/bluetooth/hci_sysfs.c 2007-12-25 17:45:09.0 +0800
> +++ linux.new/net/bluetooth/hci_sysfs.c 2007-12-25 17:45:51.0 +0800
> @@ -319,7 +319,9 @@ void hci_conn_add_sysfs(struct hci_conn
> static void del_conn(struct work_struct *work)
> {
> struct hci_conn *conn = container_of(work, struct hci_conn, work);
> + get_device(>dev);
> device_del(>dev);
> + put_device(>dev);
> }
>
> void hci_conn_del_sysfs(struct hci_conn *conn)
>
Hi greg,
BTW, Is it a possible bug of driver core or kobject ?
Regards
dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[BUG][PATCH -mm] bluetooth : rfcomm add get/put device in del_conn
Due to 2.6.24-rc6-mm1 kernel changes (maybe kobject or driver core), If I exec:
rfcomm connect 0 1
kernel will oops after connect timeout.
hand copy some oops text:
EIP is at driver_sysfs_remove+0x1a/0x40
Call Trace:
show_trace_log_lvl+0x1a/0x30
show_stack_log_lvl+0x9a/0xc0
show_registers+0xc7/0x270
die+0x129/0x240
do_page_fault+0x3a1/0x670
error_code+0x72/0x78
__device_release_driver+0x1e/0xa0
device_release_driver+0x30/0x50
bus_remove_device+0x63/0x90
device_del+0x55/0x190
del_conn+0xb/0x10 [bluetooth]
run_workqueue+0xe1/0x210
worker_thread+0x99/0xf0
kthread+0x5c/0xa0
kernel_thread_helper+0x7/0x18
(The remote bluetooth device is a mobile phone which is power off)
The reason is that in bus_remobe_dev, the klist_del function will release the
device, so just add a get/put pair around the device_del in del_conn.
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
net/bluetooth/hci_sysfs.c |2 ++
1 file changed, 2 insertions(+)
diff -upr linux/net/bluetooth/hci_sysfs.c linux.new/net/bluetooth/hci_sysfs.c
--- linux/net/bluetooth/hci_sysfs.c 2007-12-25 17:45:09.0 +0800
+++ linux.new/net/bluetooth/hci_sysfs.c 2007-12-25 17:45:51.0 +0800
@@ -319,7 +319,9 @@ void hci_conn_add_sysfs(struct hci_conn
static void del_conn(struct work_struct *work)
{
struct hci_conn *conn = container_of(work, struct hci_conn, work);
+ get_device(>dev);
device_del(>dev);
+ put_device(>dev);
}
void hci_conn_del_sysfs(struct hci_conn *conn)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc6 and earlier: "host bus error" after STR
On Mon, Dec 24, 2007 at 11:48:13PM +0300, Alexey Dobriyan wrote:
> Hi, I occasionally get those "soft resetting link" messages
> right after STR. Typical messages below (from photos):
>
>
> eth1: link up, 100Mbps, full-duplex, lpa 0x45E1
> i8042 kbd 00:0a: activation failed
> sd 0:0:0:0: [sda] Starting disk
> ata2.01: ACPI cmd ef/03:44:00:00:00:b0 filtered out
> ata2.01: ACPI cmd ef/03:44:00:00:00:b0 filtered out
> ata2.01: ACPI cmd ef/03:0c:00:00:00:b0 filtered out
> ata2.01: configured for UDMA/66
> ata2.01: ACPI cmd ef/03:45:00:00:00:b0 filtered out
> ata2.01: ACPI cmd ef/03:45:00:00:00:b0 filtered out
> ata2.01: ACPI cmd ef/03:0c:00:00:00:b0 filtered out
> ata2.01: configured for UDMA/133
> sd 2:0:0:0: [sdb] 312581808 512-byte hardware sectors (160042 MB)
> sd 2:0:0:0: [sdb] Write Protect is off
> sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
> sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support
> DPO or FUA
> ata2.01: ACPI cmd ef/03:42:00:00:00:a0 filtered out
> ata2.01: ACPI cmd ef/03:42:00:00:00:a0 filtered out
> ata2.01: ACPI cmd ef/03:0c:00:00:00:a0 filtered out
> ata1.00: configured for UDMA/33
> sd 2:0:0:0: [sdb] 234441648 512-byte hardware sectors (120034 MB)
> sd 2:0:0:0: [sdb] Write Protect is off
> sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
> sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support
> DPO or FUA
> sd 2:0:0:0: [sdb] Starting disk
> ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> ata3.00: cmd ca/00:28:ff:c0:00/00:00:00:00:00/e0 tag 0 dma 20480 out
>res 51/84:28:ff:c0:00/00:00:00:00:00/e0 Emask 0x30 (host bus error)
> ata3.00: status: { DRDY ERR }
> ata3.00: error: { ICRC ABRT }
>
> ...
>
> ata3: soft resetting link
> ata3: EH complete
> ata3.00: limiting speed to UDMA/100:PIO4
> ata3.00: BMDMA stat 0x6
> ata3.00: cmd ca/00:28:ff:c0:00/00:00:00:00:00/e0 tag 0 dma 20480 out
> res 51/84:28:ff:c0:00/00:00:00:00:00/e0 Emask 0x30 (host bus error)
> ata3.00: status: { DRDY ERR }
> ata3.00: error: { ICRC ABRT }
>
> ...
>
> ata3: soft resetting link
> ata3.00: configured for UDMA/100
> sd 2:0:0:0: [sdb] Result: hostbyte=0x00 driverbyte=0x08
> sd 2:0:0:0: [sdb] Sense Key: 0xb [current] [descriptor]
> Descriptor sense data with sense descriptors (in hex):
> 72 0b 47 00 00 00 00 0[ce] 00 0a 80 00 00 00 00 /* border of photo*/
>
> ...
>
> ata3.00: configured for UDMA/100
> ata3: EH complete
> sd 2:0:0:0: [sdb] ... 160G disk
> ...
> ata3.00: limiting speed to UDMA/33:PIO4
> ata3.00: exception Emask 0x0 Sact 0x0 Serr 0x0 action 0x2
> ata3.00: BMDMA stat 0x6
> ata3.00: cmd ca/00:08:47:66:6e/00:00:00:00:00/eb tag 0 dma 4096 out
>res 51/84:08:47:66:6e/00:00:00:00:00/eb Emask 0x30 (host bus error)
> ata3.00: status: { DRDY ERR }
> ata3.00: error: { ICRC ABRT }
> ata3: soft resetting link
host bus == PCI
So, your PCI bus is crapping itself in a major way.
One thing to try might be "libata.noacpi=1"
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
> Reading past the first 256 bytes of the sysfs file should be enough > -- only root can do that (other users get only 64 bytes anyway) and > problems with reading random registers have hopefully taught programs > not to read blindly a long time ago. ... except for lspci itself which reads the first few bytes of the extended space to see if there are any capabilities, which is generally safe, but it would always enable MMCONFIG. So an extra switch will be really needed. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth The best way to accelerate Windows is at 9.8 m / sec^2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Hello! > (and yes I realize this needs lspci to be expanded some to set the > flag if the admin really asks for it, but such is life) Reading past the first 256 bytes of the sysfs file should be enough -- only root can do that (other users get only 64 bytes anyway) and problems with reading random registers have hopefully taught programs not to read blindly a long time ago. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Never make any mistaeks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xfs|loop|raid: attempt to access beyond end of device
On Sun, Dec 23, 2007 at 08:21:08PM +0100, Janos Haar wrote: > Hello, list, > > I have a little problem on one of my productive system. > > The system sometimes crashed, like this: > > Dec 23 08:53:05 Albohacen-global kernel: attempt to access beyond end of > device > Dec 23 08:53:05 Albohacen-global kernel: loop0: rw=1, want=50552830649176, > limit=3085523200 > Dec 23 08:53:05 Albohacen-global kernel: Buffer I/O error on device loop0, > logical block 6319103831146 > Dec 23 08:53:05 Albohacen-global kernel: lost page write due to I/O error on > loop0 So a long way beyond the end of the device. [snip soft lockup warnings] > Dec 23 09:08:19 Albohacen-global kernel: Filesystem "loop0": Access to block > zero in inode 397821447 start_block: 0 start_off: 0 blkcnt: 0 extent-state: > 0 lastx: e4 And that's to block zero of the filesystem. Sure signs of a corupted inode extent btree. We've seen a few of these corruptions on loopback device reported recently. You'll need to unmount and repair the filesystem to make this go away, but it's hard to know what is causing the btree corruption. > Dec 23 09:08:22 Albohacen-global last message repeated 19 times > > some more info: > > [EMAIL PROTECTED] ~]# uname -a > Linux Albohacen-global 2.6.21.1 #3 SMP Thu May 3 04:33:36 CEST 2007 x86_64 > x86_64 x86_64 GNU/Linux > [EMAIL PROTECTED] ~]# cat /proc/mdstat > Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] > [multipath] [faulty] > md1 : active raid4 sdf2[1] sde2[0] sdd2[5] sdc2[4] sdb2[3] sda2[2] > 19558720 blocks level 4, 64k chunk, algorithm 0 [6/6] [UU] > bitmap: 8/239 pages [32KB], 8KB chunk > > md2 : active raid4 sdf3[1] sde3[0] sdd3[5] sdc3[4] sdb3[3] sda3[2] > 1542761600 blocks level 4, 64k chunk, algorithm 0 [6/6] [UU] > bitmap: 0/148 pages [0KB], 1024KB chunk > > md0 : active raid1 sdb1[1] sda1[0] > 104320 blocks [2/2] [UU] > > unused devices: > [EMAIL PROTECTED] ~]# losetup /dev/loop0 > /dev/loop0: [0010]:6598 (/dev/md2), encryption blowfish (type 18) You're using an encrypted block device? What mechanism are you using for encryption (doesn't appear to be dmcrypt)? Does it handle readahead bio cancellation correctly? We had similar XFS corruption problems on dmcrypt between 2.6.14 and ~2.6.20 due to a bug in dmcrypt's failure to handle aborted readahead I/O correctly Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: volanoMark 24% regression in 2.6.24-rc6: why a simple patch makes it
* Zhang, Yanmin <[EMAIL PROTECTED]> wrote: > The solution is just to revert patch > fbdcf18df73758b2e187ab94678b30cd5f6ff9f9, because other 2 patches > which fixed the same issue are already in 2.6.24-rc5. Linus, please revert fbdcf18df73758, as requested by Yanmin. It was noticed before (by Yinghai Lu) that this commit was not needed, but it looked a harmless duplication and we incorrectly thought it's only a NOP and wanted to fix it in v2.6.25 - but as Yanmin has analyzed it now, it creates a sub-optimal sched-domains hierarchy (not setting up the domain belonging to the core) when CONFIG_X86_HT=y. Acked-by: Ingo Molnar <[EMAIL PROTECTED]> nice work Yanmin! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
