Re: [PATCH 4/7][TAKE5] support new modes in fallocate
Amit K. Arora wrote: FA_FL_NO_MTIME 0x10 /* keep same mtime (default change on size, data change) */ FA_FL_NO_CTIME 0x20 /* keep same ctime (default change on size, data change) */ NACK to these aswell. If i_size changes c/mtime need updates, if the size doesn't chamge they don't. No need to add more flags for this. This requirement was from the point of view of HSM applications. Hope you saw Andreas previous post and are keeping that in mind. We use this capability in XFS at the moment. I think this is mainly for DMF (HSM) but is done via the xfs handle interface (xfs_open_by_handle) AFAICT. This sets up a set of invisible operations (xfs_invis_file_operations). xfs_file_ioctl_invis goes on to set IO_INVIS which goes on to set ATTR_DMI which is then tested in xfs_change_file_space() (which handles XFS_IOC_RESVSP & friends) for whether xfs_ichgtime(ip, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG) is called or not. --Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fusion MPT regression, fixed or not?
Matt Sealey wrote: Hello World, I re-stumbled on this installing Gentoo on VMware today; http://lkml.org/lkml/2007/3/23/312 It doesn't seem to be fixed in 2.6.22-rc7, but I might be mistaken somehow. Has anyone done any work on this or looked at the problem in more detail? The trail seems to die at that thread. Not that it is relevant to LKML, but you need either upgrade to VMware Workstation 6.0, or you need patch later in that thread: http://lkml.org/lkml/2007/3/23/345 It is affecting VMware for me mainly but a lot of heavy server hardware seems to use the chip, in fact some I am looking at right now to recommend purchasing on.. I'd really like to use the latest kernel because virtualisation is the key (dynamic ticks and tickless hz and the latest virtualisation options would help eke out more value ;) It affects only VMware's emulation, not real hardware (at least unless you hit one with broken firmware). Petr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Alan Stern writes: > USB already implements runtime PM. If a device is suspended at runtime > and a task tries to access it, the device is automatically resumed. > No problem there. > > The problem comes when the system is doing a STR. Right now the code > doesn't keep track of the difference between a runtime suspend and a > system suspend -- once the device is suspended, it's suspended, period. Whether or not to resume a suspended device when an I/O request comes in is a policy decision, and there could be cases where the user wants I/O requests to be blocked, or to fail, or to be dropped while the device is suspended, even for runtime power management. For example, a sound card could be suspended due to a low-battery condition, and in that case you would want the driver to just drop any data that userspace tries to write to the soundcard. > Yes, the code could be changed to keep track of the reason for a device > suspend. But that just raises the old problem of what to do when > there's an I/O request for a suspended device during STR. Is this actually a real problem? I would think the policy would be "block" for block devices (pun not intended :), "drop" for network devices, etc. > Consider a particularly troublesome case: During STR, a non-frozen task > writes to /sys/bus/BBB/drivers/DDD/bind. The sysfs core grabs the > device semaphore and calls the driver's probe routine. If the driver > isn't PM-aware it simply tries to initialize the device and fails > because the device is already suspended. That's no good; it isn't > transparent. How did the device get suspended if it didn't have a driver? If it did have a driver, why didn't the bind attempt fail? > So assume the driver is PM-aware. It tries to resume the device, which > fails because STR is underway. Now what can it do? There's only one > possibility: It must block until the resume call can succeed. But when > is that? > > It has to be before the PM core tries to resume the device, because the > core will try to acquire the device semaphore and will block waiting > for the probe call to complete. But it has to be after the PM core > resumes the device's parent, because obviously the device can't resume > until its parent is awake. Suppose the device-model core code simply blocked all bind and unbind requests while suspend is under way, until resume is finished. Wouldn't that solve the problem? Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Alan Stern writes: > I disagree. The problem isn't the kernel calling userspace; it's > userspace trying to do I/O at a time when everything is supposed to be > quiescing. Detecting that and blocking it in drivers is hard and > error-prone; preventing it by freezing userspace is easy and cheap. And unreliable, and prone to deadlocks, and invasive - requiring changes to kernel threads that have nothing to do with drivers or suspend/resume. > The reasons why the PPC people dislike the whole idea aren't clear to > me. Our experience is that it isn't necessary. It's extra code that in practice causes deadlocks and added maintenance burden for no discernable benefit. > If it were necessary to have some user task running in order to > carry out the STR then their objection would make sense -- obviously > that task couldn't do its job if it were frozen. But it isn't > necessary, or at least it should not be. The freezer doesn't achieve its stated goal of preventing drivers from getting I/O requests after suspend, since kernel threads can (and do) initiate I/O. So then we say that some kernel threads need to be frozen and others don't, but making that decision is difficult and error-prone. Besides, any kernel thread that does I/O is potentially doing that in order to complete some other I/O request. So we want to freeze it in order to prevent new I/O requests from being initiated, but we don't want to freeze it so that existing I/O requests can be completed. Thus we have a fundamental conflict in the notion of the freezer. In fact I believe that making a distinction between user and kernel threads is wrong and likely to lead to problems, since userspace can be involved in doing I/O (e.g. FUSE or the user-space driver framework). So the argument of the previous paragraph also applies to some userspace processes. > Userspace will be effectively "frozen" while the system as a whole is > suspended. So what's wrong with freezing it a little early? Despite > Ben's comments, it seems to me that the freezer doesn't hide problems > -- it prevents them. No, it appears to prevent them, but doesn't in fact. I remain convinced that the right approach is to fix the drivers to do one of two things; either do something in the suspend call to block further requests to the device, or use a late-suspend call to put their device into a low-power state. Of course, correctly-written frameworks can do a lot to help the chipset drivers here. > Now people may claim that the freezer implementation itself is buggy. > I wouldn't dispute it. But the bugs should be fixable; nobody has > pointed out anything fundamentally wrong with the idea AFAICT. The fundamental problem is the kernel threads and user processes that we need running to complete existing I/O requests, but which may initiate new I/O requests in doing so. The right way to solve the problem is to do the request blocking in the drivers. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Alan Stern writes: > > Most drivers suspended their hardware in the second call. If they are > > in the middle of a conversation with their device that *has* to be > > completed, they can do that by polling. > > Ugh. That will cause problems when you try to integrate runtime > suspend. In fact this whole approach is unsuitable for runtime PM and > it obscures the similarities between runtime PM and STR. Yes there are similarities, but it would be a big mistake to say that a requirement for STR is that all drivers do runtime PM. If a driver does runtime PM, that's great, and it is useful for implementing STR. However, there are a class of devices for which runtime PM is not possible or not useful, but which can suspend/resume just fine as part of suspending/resuming the complete system, and for which all that is needed is some small amount of simple hardware poking just before the system as a whole is put into suspend. For those a late-suspend call with interrupts off is the simplest and best way to go. Think of a serial port on a motherboard for instance, where the only power control is the overall power control for the system. All that is needed is to poll for the transmitter being empty (with timeout, of course) in the late-suspend call (and possibly also turn off output drivers, perhaps), and to reinitialize some registers in an early-resume call. The main attraction of the late-suspend call is that it really does, reliably, guarantee that the driver's I/O request methods won't get called between the late-suspend call and the early-resume call. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway
Rafael J. Wysocki writes: > Now, please tell me how many driver writers even thought that something > might try to access their devices after .suspend() had been executed (or > even whilie it was being executed)? Well, I believe that the USB framework copes with this, except possibly for some corner cases like the example that Alan Stern posted. The fact that powerbooks suspend and resume without the freezer implies that the IDE framework, the console code and the framebuffer code cope correctly (though possibly not all chipset drivers). So I think that a lot of the frameworks already get it right. Of course the quality of the low-level chipset drivers has always been pretty variable. :) Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Rafael J. Wysocki writes: > Still, do you really think that we're ready to drop it _right_ _now_ (I'm > referring to suspend only) and if so than on what basis (except that you > don't like it, which falls short of being a techical argument)? The basis is that it (the freezer) causes more deadlocks and other problems than it avoids, so it's a net win to remove it. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pci hidden behind transparent bridge
Dave Jones wrote: On Tue, Jul 03, 2007 at 06:00:14PM +0200, Michal Piotrowski wrote: > Hi, > > On 02/07/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi! I noticed such message: > > > > "PCI: Bus #07 (-#0a) is hidden behind transparent bridge #06 (-#06) > > (try 'pci=assign-busses') > > Please report the result to linux-kernel to fix this permanently" > > > > on my > > Linux niam 2.6.22-rc6-cfs-v18 #6 Mon Jul 2 20:19:25 EEST 2007 i686 > > Intel(R) Celeron(R) M processor 1.50GHz GenuineIntel GNU/Linux > > > > What does it mean?? > > Is this a regressions? There's about 8 gazillion of these reports that have been in bugzilla since the dinosaurs roamed the lands. Just ripping the printk out would be my preference. Dave It seems like whoever added the message saying to report this to LKML hasn't responded to these reports. Any patches adding such messages in the future should really include details of what they expect to be done with the reports.. -- 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: pci hidden behind transparent bridge
On Tue, Jul 03, 2007 at 01:25:06PM -0400, Dave Jones wrote: > On Tue, Jul 03, 2007 at 06:00:14PM +0200, Michal Piotrowski wrote: > > Hi, > > > > On 02/07/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Hi! I noticed such message: > > > > > > "PCI: Bus #07 (-#0a) is hidden behind transparent bridge #06 (-#06) > > > (try 'pci=assign-busses') > > > Please report the result to linux-kernel to fix this permanently" > > > > > > on my > > > Linux niam 2.6.22-rc6-cfs-v18 #6 Mon Jul 2 20:19:25 EEST 2007 i686 > > > Intel(R) Celeron(R) M processor 1.50GHz GenuineIntel GNU/Linux > > > > > > What does it mean?? > > > > Is this a regressions? > > There's about 8 gazillion of these reports that have been in bugzilla > since the dinosaurs roamed the lands. Just ripping the printk out > would be my preference. There is a patch in -mm and in my queue for 2.6.23 to revise the message to send the information to the correct person responsible for it. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 -- Problems with suspend/resume.
On Tue, 3 Jul 2007 20:45:41 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote: > Should I not report stuff like this when it is > generated after an OOPS? All bets are off if the kernel has oopsed. Reboot, see if the bug still happens without the earlier oops, perhaps. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata_sil, writing bug with multiple cards?
[EMAIL PROTECTED] wrote: > Apologies for the chain-replying to myself, just replying as I think of > things to try. > [EMAIL PROTECTED] writes: >> Here's an odd data point. >> I just broke that array, formatted all three of those partitions >> seperately, mounted and did my ISO copy test. >> All three drives, run one at a time, function fine. No corruption. > > Here's another odd one. I did the following: > # Mount all 3 drives as individuals... > mount /dev/sda1 /mnt/a > mount /dev/sdb1 /mnt/b > mount /dev/sdc1 /mnt/c > # Copy the same file to all three drives at the same time > cp KNOPPIX_V5.1.0CD-2006-12-30-EN.iso a/kn10.iso & > cp KNOPPIX_V5.1.0CD-2006-12-30-EN.iso b/kn10.iso & > cp KNOPPIX_V5.1.0CD-2006-12-30-EN.iso c/kn10.iso & > Got massive corruption. Hmmm... I don't think this is sata_sil driver bug. cc'ing Andi Kleen and lkml. Andi, the original thread can be read from http://thread.gmane.org/gmane.linux.ide/20213 Any ideas? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata_acpi: A different strategy for using ACPI information
Alan Cox wrote: > Lots of BIOSen simply return the BIOS set modes via the ACPI methods and > pass back the values you give it across suspend/resume. Thus instead of > trying to do clever stuff with this data we instead use it as a way to > take a sneak peak at cable type information when viable. This should help > us catch more of the laptops that do weird stuff, the VIA SATA bridges > and the totally horked Nvidia cable handling. > > For now its only used by the VIA and AMD/NV driver until we get a better > idea of whether this is a sensible idea or not. > > Opinions ? If you don't do _STM first, it basically boils down to reading BIOS setting during boot. Over suspend/resume cycle, the values are preserved by libata-acpi. At this point, I think honoring the BIOS setting is the right thing to do. It just took us too long and I'm not too sure about using ACPI for this. It's generic so it's certainly better in some aspect. It's just a bit obfuscating, IMHO. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/3] Generic Trace Setup and Control (GTSC) code
* Tom Zanussi ([EMAIL PROTECTED]) wrote:
> The Generic Tracing and Control Interface (GTSC) code.
>
> Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]>
> Signed-off-by: David Wilder <[EMAIL PROTECTED]>
> ---
> include/linux/gtsc.h | 104 +
> lib/Kconfig | 10
> lib/Makefile |2
> lib/gtsc.c | 558
> +++
> 4 files changed, 674 insertions(+)
>
> +static ssize_t reset_consumed_write(struct file *filp,
> + const char __user *buffer,
> + size_t count,
> + loff_t *ppos)
> +{
> + struct trace_info *trace = filp->private_data;
> +
> + relay_reset_consumed(trace->rchan);
> +
> + return count;
> +}
> +
> +struct file_operations reset_consumed_fops = {
> + .owner = THIS_MODULE,
> + .open = reset_consumed_open,
> + .write = reset_consumed_write
> +};
> +
Quoting the header of relay_reset_consumed:
+ * NOTE: Care should be taken that the channel isn't actually
+ * being used by anything when this call is made.
I can imagine relay saying "locking is not my problem", while GTSC
whistle and looks away... ;)
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 -- Problems with suspend/resume.
On 7/3/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Tue, 3 Jul 2007 18:09:29 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote: > Sorry. I don't know who else to include in the To: list. Should I > send this again with .config information? Would ps -Af help? Gosh, what a lot of output we generated. It's pretty digestible though. It looks like these are the problem: cat D 002B 0 5603 1 (NOTLB) c8102e4c 0096 80cc15ad 002b c1176c2c c8102e38 0046 c7fb2bc0 c7fb2d50 c265c100 80cc15ad 002b c8102e4c c7f12d00 c014b438 0001 c036759c c63b6914 c8102e68 c63b68e0 0246 c8102e88 c0367416 Call Trace: [] __mutex_lock_slowpath+0x1c7/0x32c [] mutex_lock+0x21/0x24 [] drm_vma_info+0x1f/0x310 [drm] [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === INFO: lockdep is turned off. tail D 002C 0 5646 1 (NOTLB) c811ce4c 0096 7137dc36 002c c1175f98 c811ce38 0046 c80e15e0 c80e1770 c265c100 7137dc36 002c c811ce4c c7f11e00 c014b438 0001 c036759c c63b6914 c811ce68 c63b68e0 0246 c811ce88 c0367416 Call Trace: [] __mutex_lock_slowpath+0x1c7/0x32c [] mutex_lock+0x21/0x24 [] drm_vma_info+0x1f/0x310 [drm] [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === INFO: lockdep is turned off. cat D 0033 0 5910 1 (NOTLB) c8107e4c 0096 24ccdd52 0033 c014b438 0001 c8107e14 c7e9ed60 c7e9eef0 c265c100 24ccdd52 0033 c8107e4c c7f11b80 c014b438 0001 c036759c c63b6914 c8107e68 c63b68e0 0246 c8107e88 c0367416 Call Trace: [] __mutex_lock_slowpath+0x1c7/0x32c [] mutex_lock+0x21/0x24 [] drm_vma_info+0x1f/0x310 [drm] [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === INFO: lockdep is turned off. cat D 0033 0 5926 1 (NOTLB) c8160e4c 0096 8cc85f27 0033 c117483c c8160e38 0046 c80e0af0 c80e0c80 c265c100 8cc85f27 0033 c8160e4c c7f13480 c014b438 0001 c036759c c63b6914 c8160e68 c63b68e0 0246 c8160e88 c0367416 Call Trace: [] __mutex_lock_slowpath+0x1c7/0x32c [] mutex_lock+0x21/0x24 [] drm_vma_info+0x1f/0x310 [drm] [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === INFO: lockdep is turned off. cat D 0034 0 5950 1 (NOTLB) c8084e4c 0096 39b9c536 0034 c117afbc c8084e38 0046 c6ce15e0 c6ce1770 c265c100 39b9c536 0034 c8084e4c c7f13200 c014b438 0001 c036759c c63b6914 c8084e68 c63b68e0 0246 c8084e88 c0367416 Call Trace: [] __mutex_lock_slowpath+0x1c7/0x32c [] mutex_lock+0x21/0x24 [] drm_vma_info+0x1f/0x310 [drm] [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === and I'm guessing that this kernel is one which has already oopsed in drm_vma_info()? If so, then problem solved: it oopsed with the lock held. If not, then perhaps we have another problem in DRM. Or the same one remanifesting. Yes, it is. Thanks. Should I not report stuff like this when it is generated after an OOPS? Sorry to trouble you. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 2/3] Generic Trace Setup and Control (GTSC) code
Please see comments below,
* Tom Zanussi ([EMAIL PROTECTED]) wrote:
> The Generic Tracing and Control Interface (GTSC) code.
>
> Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]>
> Signed-off-by: David Wilder <[EMAIL PROTECTED]>
> ---
> include/linux/gtsc.h | 104 +
> lib/Kconfig | 10
> lib/Makefile |2
> lib/gtsc.c | 558
> +++
> 4 files changed, 674 insertions(+)
>
> diff --git a/include/linux/gtsc.h b/include/linux/gtsc.h
> new file mode 100644
> index 000..cbb2601
> --- /dev/null
> +++ b/include/linux/gtsc.h
> @@ -0,0 +1,104 @@
> +/*
> + * GTSC defines and function prototypes
> + *
> + * Copyright (C) 2006 IBM Inc.
> + *
> + * Tom Zanussi <[EMAIL PROTECTED]>
> + * Martin Hunt <[EMAIL PROTECTED]>
> + * David Wilder <[EMAIL PROTECTED]>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
> + *
> + */
> +#ifndef _LINUX_GTSC_H
> +#define _LINUX_GTSC_H
> +
> +#include
> +
> +/*
> + * GTSC channel flags
> + */
> +#define TRACE_GLOBAL_CHANNEL 0x01
> +#define TRACE_FLIGHT_CHANNEL 0x02
> +#define TRACE_DISABLE_STATE 0x04
> +
> +enum trace_state {
> + TRACE_SETUP,
> + TRACE_RUNNING,
> + TRACE_STOPPED,
> +};
> +
> +#define TRACE_ROOT_NAME_SIZE 64 /* Max root dir identifier */
> +#define TRACE_NAME_SIZE 64 /* Max trace identifier */
> +
> +/*
> + * Global root user information
> + */
> +struct trace_root {
> + struct list_head list;
> + char name[TRACE_ROOT_NAME_SIZE];
> + struct dentry *root;
> + unsigned int users;
> +};
> +
> +/*
> + * Client information
> + */
> +struct trace_info {
> + enum trace_state state;
> + struct dentry *state_file;
> + struct rchan *rchan;
> + struct dentry *dir;
> + struct dentry *dropped_file;
> + struct dentry *reset_consumed_file;
> + struct dentry *nr_sub_file;
> + struct dentry *sub_size_file;
> + atomic_t dropped;
> + struct trace_root *root;
> + void *private_data;
> + unsigned int flags;
> + unsigned int buf_size;
> + unsigned int buf_nr;
> +};
> +
> +#ifdef CONFIG_GTSC
> +static inline int trace_running(struct trace_info *trace)
> +{
> + return trace->state == TRACE_RUNNING;
> +}
> +struct trace_info *trace_setup(const char *root, const char *name,
> +u32 buf_size, u32 buf_nr, u32 flags);
> +int trace_start(struct trace_info *trace);
> +int trace_stop(struct trace_info *trace);
> +void trace_cleanup_channel(struct trace_info *gt);
> +void trace_cleanup(struct trace_info *gt);
> +unsigned long long trace_timestamp(void);
> +#else
> +static inline struct trace_info *trace_setup(const char *root,
> + const char *name,
> + u32 buf_size,
> + u32 buf_nr,
> + u32 flags)
> +{
> + return NULL;
> +}
> +static inline int trace_running(struct trace_info *trace) { return 0; }
> +static inline int trace_start(struct trace_info *trace) { return -EINVAL; }
> +static inline int trace_stop(struct trace_info *trace) {}
> +static inline void trace_cleanup_channel(struct trace_info *trace) {}
> +static inline void trace_cleanup(struct trace_info *trace) {}
> +static inline unsigned long long trace_timestamp(void) { return 0; }
> +#endif
> +
I don't see any correct case where functions such as trace_start or
trace_stop should be declared empty. Correct dependencies on CONFIG_GTSC
should probably be used.
> +#endif
> diff --git a/lib/Kconfig b/lib/Kconfig
> index 2e7ae6b..b3931f3 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -124,4 +124,14 @@ config HAS_DMA
> depends on !NO_DMA
> default y
>
> +config GTSC
> + bool "Generic Trace Setup and Control"
> + select RELAY
> + select DEBUG_FS
> + help
> + This option provides support for the setup, teardown and control
> + of tracing channels from kernel code. It also provides trace
> + information and control to userspace via a set of debugfs control
> + files. If unsure, say N.
> +
> endmenu
> diff --git a/lib/Makefile b/lib/Makefile
> index c8c8e20..d9e68fa 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -62,6 +62,8 @@ obj-$(CONFIG_FAULT_INJECTION)
Re: [RFC PATCH 1/3] Generic Trace Setup and Control (GTSC) Documentation
* Tom Zanussi ([EMAIL PROTECTED]) wrote: > This is the documentation for the Generic Trace Setup and Control > patchset, first submitted a couple of weeks ago. See > > http://marc.info/?l=linux-kernel=118214274912586=2 > > for a more detailed description. > > I've updated this patch to incorporate the suggestions made by Alexey > Dobriyan in that thread. > It would be nice, since it claims to be "generic", to support things brought forward by other tracers like LTTng, such as : multiple channels (for low, medium and high event rate data, with user-selectable sizes), hybrid trace mode (combined normal trace channels and flight recorder channels). Please see comments below, > Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]> > Signed-off-by: David Wilder <[EMAIL PROTECTED]> > --- > gtsc.txt | 247 > +++ > 1 file changed, 247 insertions(+) > > diff --git a/Documentation/gtsc.txt b/Documentation/gtsc.txt > new file mode 100644 > index 000..470d1fc > --- /dev/null > +++ b/Documentation/gtsc.txt > @@ -0,0 +1,247 @@ > +Generic Trace Setup and Control (GTSC) > +== > +In the kernel, GTSC provides a simple API for starting and managing > +data channels to user space. GTSC builds on the relay interface. For a > +complete description of the relay interface, please see: > +Documentation/filesystems/relay.txt. > + > +GTSC provides one layer in a complete tracing application. The idea of > +the GTSC is to provide a kernel API for the setup and control of tracing > +channels. User of GTSC must provide a data layer responsible for formatting > +and writing data into the trace channels. > + > +A layered approach to tracing > += > +A complete kernel tracing application consists of a data provider and a data > +consumer. Both provider and consumer contain three layers; each layer works > +in tandem with the corresponding layer in the opposite side. The layers are > +represented in the following diagram. > + > +Provider Data layer > + Formats raw trace data and provides data-related service. > + For example, adding timestamps used by consumer to sort data. > + > +Provider Control layer > + Provided by GTSC. Creates trace channels and informs the data layer > + and consumer of the current state of the trace channels. > + > +Provider Buffering layer > + Provided by relay. This layer buffers data in the > + kernel for consumption by the consumer's buffer > + layer. > + > +Provider (in-kernel facility) > +- > +Consumer (user application) > + > + > +Consumer Buffer layer > + Reads/consumes data from the provider's data buffers. > + > +Consumer Control layer > + Communicates to the provider's control layer to control the state > + of the trace channels. > + > +Consumer Data layer > + Sorts and formats data as provided by the provider's data layer. > + > +The provider is coded as a kernel facility. The consumer is coded as > +a user application. > + > + > +GTSC - Features > +== > +The GTSC exploits services and features provided by relay. These features > are: > +- The creation and destruction of relay channels. > +- Buffer management. Overwrite or non-overwrite modes can be selected > + as well as global or per-CPU buffering. > + > +Overwrite mode can be called "flight recorder mode". Flight recorder > +mode is selected by setting the TRACE_FLIGHT_CHANNEL flag when > +creating trace channels. In flight mode when a tracing buffer is > +full, the oldest records in the buffer will be discarded to make room > +as new records arrive. In the default non-overwrite mode, new records > +may be written only if the buffer has room. In either case, to > +prevent data loss, a user space reader must keep the buffers > +drained. GTSC provides a means to detect the number of records that > +have been dropped due to a buffer-full condition (non-overwrite mode > +only). > + > +When per-CPU buffers are used, relay creates one debugfs file for each > +running CPU. The user-space consumer of the data is responsible for > +reading the per-CPU buffers and collating the records presumably using > +a time stamp or sequence number included in the trace records. The > +use of global buffers eliminates this extra work of sequencing > +records; however the provider's data layer must hold a lock when > +writing records. The lock prevents writers running on different CPUs > +from overwriting each other's data. However, buffering may be slower > +because write to the buffer are serialized. Global buffering is > +selected by setting the TRACE_GLOBAL_CHANNEL flag when creating trace > +channels. > + > +GTSC User Interface > +=== > +When a GTSC channel is created and tracing has been started, the following > +directories and files are created in the root of the
Re: [PATCH] Re: Sparc32: random invalid instruction occourances on sparc32 (sun4c)
On Wed, 2007-07-04 at 04:27 +0100, Mark Fortescue wrote: > I tried the previous patch and it looks like it fixes the issue however > one of the test builds I did caused depmod to use up all available memory > (40M - kernel memory) before taking out the kernel with the oom killer. > At present, I do not know if it is a depmod issue or a kernel issue. > I will have to do some more tests later on to day. That's almost certain to be an unrelated issue. > I have looked at the latest patch below and am I am still not sure about > two areas. Please take a look at my offering based on your latest > patch (included here to it will probably get mangled). > > Note the change to lines 2178 to 2185. I have also changed/moved the > alignment of size (see lines 2197 to 2206) based on your changes. The first looks correct; well spotted. The second is just cosmetic but also seems correct. I might be inclined to make the #define 'RED_ZONE_ALIGN' and use it in the other places too. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Re: Sparc32: random invalid instruction occourances on sparc32 (sun4c)
Hi David,
I tried the previous patch and it looks like it fixes the issue however
one of the test builds I did caused depmod to use up all available memory
(40M - kernel memory) before taking out the kernel with the oom killer.
At present, I do not know if it is a depmod issue or a kernel issue.
I will have to do some more tests later on to day.
I have looked at the latest patch below and am I am still not sure about
two areas. Please take a look at my offering based on your latest
patch (included here to it will probably get mangled).
Note the change to lines 2178 to 2185. I have also changed/moved the
alignment of size (see lines 2197 to 2206) based on your changes.
--- linux-2.6/mm/slab.c 2007-07-03 19:09:48.0 +0100
+++ linux-test/mm/slab.c2007-07-04 04:14:15.0 +0100
@@ -137,6 +137,7 @@
/* Shouldn't this be in a header file somewhere? */
#defineBYTES_PER_WORD sizeof(void *)
+#define RED_ZONE_ALIGN_MASK(max(__alignof__(void *), __alignof(unsigned
long long)) - 1)
#ifndef cache_line_size
#define cache_line_size() L1_CACHE_BYTES
@@ -547,7 +548,7 @@ static unsigned long long *dbg_redzone2(
if (cachep->flags & SLAB_STORE_USER)
return (unsigned long long *)(objp + cachep->buffer_size -
sizeof(unsigned long long) -
- BYTES_PER_WORD);
+ max(BYTES_PER_WORD,
__alignof__(unsigned long long)));
return (unsigned long long *) (objp + cachep->buffer_size -
sizeof(unsigned long long));
}
@@ -2178,7 +2179,8 @@ kmem_cache_create (const char *name, siz
* above the next power of two: caches with object sizes just above a
* power of two have a significant amount of internal fragmentation.
*/
- if (size < 4096 || fls(size - 1) == fls(size-1 + 3 * BYTES_PER_WORD))
+ if (size < 4096 || fls(size - 1) == fls(size-1 + 2 * sizeof(unsigned
long long) +
+ max(BYTES_PER_WORD,
__alignof__(unsigned long long
flags |= SLAB_RED_ZONE | SLAB_STORE_USER;
if (!(flags & SLAB_DESTROY_BY_RCU))
flags |= SLAB_POISON;
@@ -2197,9 +2199,9 @@ kmem_cache_create (const char *name, siz
* unaligned accesses for some archs when redzoning is used, and makes
* sure any on-slab bufctl's are also correctly aligned.
*/
- if (size & (BYTES_PER_WORD - 1)) {
- size += (BYTES_PER_WORD - 1);
- size &= ~(BYTES_PER_WORD - 1);
+ if (size & RED_ZONE_ALIGN_MASK) {
+ size += RED_ZONE_ALIGN_MASK;
+ size &= ~RED_ZONE_ALIGN_MASK;
}
/* calculate the final buffer alignment: */
@@ -2261,9 +2263,14 @@ kmem_cache_create (const char *name, siz
}
if (flags & SLAB_STORE_USER) {
/* user store requires one word storage behind the end of
-* the real object.
+* the real object. But if the second red zone must be
+* aligned 'better' than that, allow for it.
*/
- size += BYTES_PER_WORD;
+ if (flags & SLAB_RED_ZONE
+ && BYTES_PER_WORD < __alignof__(unsigned long long))
+ size += __alignof__(unsigned long long);
+ else
+ size += BYTES_PER_WORD;
}
#if FORCED_DEBUG && defined(CONFIG_DEBUG_PAGEALLOC)
if (size >= malloc_sizes[INDEX_L3 + 1].cs_size
---
Let me know if you would like an un-mangled copy of the patch as an
attachement.
Regards
Mark Fortescue.
On Tue, 3 Jul 2007, David Woodhouse wrote:
On Tue, 2007-07-03 at 23:47 +0100, Mark Fortescue wrote:
Hi David,
I will try out your patch shortly.
Thanks.
I may be wrong about the size calculations but if you take a look at lines
2174 to 2188 and 2207 to 2203, reading the comments suggest to me that
these need to be changed to match the changes to the RedZone words.
Failing to change these means that 32bit aligned access of the 64bit
RedZone words is still posible and this will kill sun4c.
Why do we need more than the existing:
if (flags & SLAB_RED_ZONE || flags & SLAB_STORE_USER)
ralign = __alignof__(unsigned long long);
For the 64bit RedZone word to be 64bit aligned (required by sun4c), the
User word must be 64bit aligned. I don't see where in your patch, this is
enforced.
Where __alignof__(long long) > BYTES_PER_WORD my patch should lead to
this layout (32-bit words):
[ redzone1 bits 63-32 ]
[ redzone1 bits 31-0 ]
[... object ... ]
[... object ... ]
[ redzone2 bits 63-32 ]
[ redzone2 bits 31-0 ]
[unused ]
[ user word ]
The user word is a 32-bit value; there's no requirement for _it_ to be
aligned.
Hm,
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Oliver Neukum writes: > That's why we have the problem of freezing the kernel threads or not. That problem is a symptom of the deeper conceptual problem, as is the problem with FUSE. > You want to have all that pain for fuse? I'd certainly rather get the drivers right, and maybe have an occasional deadlock if I miss something, than have a GUARANTEED deadlock every time I suspend with a FUSE filesystem mounted (which is pretty much every time, since I use encfs regularly). Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/6] Driver Tracing Interface (DTI) code
Please see comments below,
* Tom Zanussi ([EMAIL PROTECTED]) wrote:
> The Driver Tracing Interface (DTI) code.
>
> Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]>
> Signed-off-by: David Wilder <[EMAIL PROTECTED]>
> ---
> drivers/base/Kconfig | 11
> drivers/base/Makefile |1
> drivers/base/dti.c | 836
> +
> drivers/base/dti_merged_view.c | 332
> include/linux/dti.h| 293 ++
> 5 files changed, 1473 insertions(+)
>
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index 5d6312e..fbc9c0e 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -49,6 +49,17 @@ config DEBUG_DEVRES
>
> If you are unsure about this, Say N here.
>
> +config DTI
> + bool "Driver Tracing Interface (DTI)"
> + select GTSC
> + help
> + Provides functions to write variable length trace records
> + into a wraparound memory trace buffer. One purpose of
> + this is to inspect the debug traces after a system crash in order to
> + analyze the reason for the failure. The traces are accessable from
> + system dumps via dump analysis tools like crash or lcrash. In live
> + systems the traces can be read via a debugfs interface.
> +
> config SYS_HYPERVISOR
> bool
> default n
> diff --git a/drivers/base/Makefile b/drivers/base/Makefile
> index b39ea3f..7caa5f5 100644
> --- a/drivers/base/Makefile
> +++ b/drivers/base/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_NUMA) += node.o
> obj-$(CONFIG_MEMORY_HOTPLUG_SPARSE) += memory.o
> obj-$(CONFIG_SMP)+= topology.o
> obj-$(CONFIG_SYS_HYPERVISOR) += hypervisor.o
> +obj-$(CONFIG_DTI) += dti.o dti_merged_view.o
>
> ifeq ($(CONFIG_DEBUG_DRIVER),y)
> EXTRA_CFLAGS += -DDEBUG
> diff --git a/drivers/base/dti.c b/drivers/base/dti.c
> new file mode 100644
> index 000..2feec11
> --- /dev/null
> +++ b/drivers/base/dti.c
> @@ -0,0 +1,836 @@
> +/*
> + *Linux Driver Tracing Interface.
> + *
> + *Copyright (C) IBM Corp. 2007
> + *Author(s): Tom Zanussi <[EMAIL PROTECTED]>
> + * Dave Wilder <[EMAIL PROTECTED]>
> + * Michael Holzheu <[EMAIL PROTECTED]>
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +extern int dti_create_merged_views(struct dti_info *dti);
> +extern void dti_remove_merged_views(struct dti_info *dti);
> +struct file_operations level_fops;
> +
> +static inline int nr_sub(int size)
> +{
> + if (size < 4)
> + return 0;
> +
> + if (size >= 8 * PAGE_SIZE)
> + return 8;
> + else
> + return 4;
> +}
> +
> +static inline int sub_size(int size)
> +{
> + if (size < 4)
> + return 0;
> +
> + if (size >= 8 * PAGE_SIZE)
> + return size / 8;
> + else
> + return size / 4;
> +}
> +
> +/*
> + * For dti_printk, maximum size of klog formatting buffer beyond which
> + * truncation will occur
> + */
> +#define DTI_PRINTF_TMPBUF_SIZE (1024)
> +
> +/* per-cpu dti_printf formatting temporary buffer */
> +static char dti_printf_tmpbuf[NR_CPUS][DTI_PRINTF_TMPBUF_SIZE];
> +
Why do you do a supplementary copy of this data? It could be written
directly to the buffers.
> +/*
> + * Low-level registration functions
> + */
> +
> +static struct dti_info *__dti_register_level(const char *name, int level,
> + int sub_size, int nr_sub,
> + struct dti_handle *handle)
> +{
> + struct dti_info *dti;
> +
> + dti = kzalloc(sizeof(*dti), GFP_KERNEL);
> + if(!dti)
> + return NULL;
> +
> + dti->trace = trace_setup("dti", name, sub_size, nr_sub,
> + TRACE_FLIGHT_CHANNEL | TRACE_DISABLE_STATE);
> + if (!dti->trace)
> + goto setup_failed;
> +
> + dti->handle = handle;
> + dti->level = level;
> + dti->level_ctrl = debugfs_create_file("level", 0,
> + dti->trace->dir, dti,
> + _fops);
> + if (!dti->level_ctrl) {
> + printk("Couldn't create level control file\n");
> + goto level_failed;
> + }
> +
> + strncpy(dti->name, name, NAME_MAX);
> +
> + return dti;
> +
> +level_failed:
> + trace_cleanup(dti->trace);
> +setup_failed:
> + kfree(dti);
> +
> + return NULL;
> +}
> +
> +/**
> + * dti_register_level: create trace dir and level ctrl file
> + *
> + * Internal - exported for setup macros.
> + */
> +struct dti_info *dti_register_level(const char *name, int level,
> + struct dti_handle *handle)
> +{
> + return __dti_register_level(name, level, sub_size(handle->size),
> + nr_sub(handle->size), handle);
> +}
> +EXPORT_SYMBOL_GPL(dti_register_level);
> +
> +static void
Re: [RFC PATCH 4/6] relay: add relay_reserve_cpu()
* Tom Zanussi ([EMAIL PROTECTED]) wrote:
> This patch adds the ability to explicitly specify the per-cpu buffer
> to reserve space in. Needed for early DTI tracing.
>
This should come with the ability to tell relay where the already
allocated static buffers are. Can you tell me a little more on why the
standard relay_reserve would not do the job? Is smp_processor_id() not
ready to output a sensible CPU id yet ?
> Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]>
> Signed-off-by: David Wilder <[EMAIL PROTECTED]>
> ---
> relay.h | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/include/linux/relay.h b/include/linux/relay.h
> index 6caedef..37a7306 100644
> --- a/include/linux/relay.h
> +++ b/include/linux/relay.h
> @@ -269,6 +269,39 @@ static inline void *relay_reserve(struct rchan *chan,
> size_t length)
> }
>
> /**
> + * relay_reserve_cpu - reserve slot in given cpu's channel buffer
> + * @chan: relay channel
> + * @length: number of bytes to reserve
> + * @cpu: cpu to log to
> + *
> + * Returns pointer to reserved slot, NULL if full.
> + *
> + * Reserves a slot in the given cpu's channel buffer.
> + * Does not protect the buffer at all - caller must provide
> + * appropriate synchronization.
> + *
> + * NOTE: this is almost certainly not the function you want -
> + * use relay_reserve() instead for normal logging. This version
> + * is specialized for things like early tracing.
> + */
> +static inline void *relay_reserve_cpu(struct rchan *chan, size_t length,
> + unsigned int cpu)
> +{
> + void *reserved;
> + struct rchan_buf *buf = chan->buf[cpu];
> +
> + if (unlikely(buf->offset + length > buf->chan->subbuf_size)) {
> + length = relay_switch_subbuf(buf, length);
> + if (!length)
> + return NULL;
> + }
> + reserved = buf->data + buf->offset;
> + buf->offset += length;
> +
> + return reserved;
> +}
> +
> +/**
> * subbuf_start_reserve - reserve bytes at the start of a sub-buffer
> * @buf: relay channel buffer
> * @length: number of bytes to reserve
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 1/6] Driver Tracing Interface (DTI) Documentation
Hi Tom, I'm glad to see that other people are tackling the tracing task. I must say that there is a lot here that was already out there in LTTng. I will be happy to review the code you present. Please see comments below. * Tom Zanussi ([EMAIL PROTECTED]) wrote: > Hi, > > This patchset contains the code for a tracing and debugging facility > named 'The Driver Tracing Interface (DTI)' after the title of our OLS > paper, to be presented tomorrow. ;-) > > It was originally based on ideas from a useful s390 tracing utility > called s390dbf (see Documentation/s390/s390dbf.txt), which allows > driver writers to set up and continually log to a small (or large) > circular 'flight-recording' buffer. When something goes wrong, the > buffer can be cat'ed from userspace and the contents analyzed to help > determine the source of the problem. > > The s390dbf facility supports multiple log levels, so the level of > detail being logged can be dynamically controlled (again in user space > via a control file). which in turn provides even more help in > determining the source of the problem. This facility has apparently > proven itself very useful in the field and has helped solve driver > problems on production systems. > > The Driver Tracing Interface introduced here does essentially the same > thing, but makes the functionality available to all architectures, not > just s390. It's built on top of the relay interface, and so makes > per-cpu logging available to users of the interface, something which > the s390dbf facility currently lacks. > > Because the data is logged to per-cpu buffers, there needs to be an > easy way for users to easily view it without having to read and merge > the individual per-cpu buffers themselves. To solve this problem, DTI > provides a merged 'view' via a debugfs file, which merges and presents > the per-cpu data when read. > > DTI is also very useful as a debugging tool for kernel development. I > personally use the klog example in the relay-apps user code all the > time for quick-and-dirty tracing, and I know that other people use > similar home-grown tracing tools (and even post them here). > Hopefully, the DTI interface provides a decent enough simplification > of the relay API that using it for these types of tracing applications > would be attractive to people put off by the bare relay API. > > I created a DTI sourceforge site earlier today, but it hasn't been > approved yet. Once it's available, I'll put a few example patches up > there along with some user tools (for binary tracing). But in the > meantime, here's a short description of the examples: > > - dti-ext2-example.patch - ext2 contains some debugging code that uses > printk(). Redefining ext2_debug() in ext2_fs.h to use dti_printk() > basically turns the existing debugging code into a flight-recording > DTI channel. > > - dti-systrace-example.patch - does binary tracing of all interrupts, > system calls and schedule changes (x86). This demonstrates using a > single DTI channel across multiple 'subsystems' as well as custom > formatting and presentation of the binary data (using the DTI user > code). > > - dti-early-example.patch - does early tracing i.e. before initcalls. > Logs data starting from the beginning of start_kernel() and when the > system comes up, boot data is available in a DTI debugfs file. > > This patchset includes a few additions to relay, and also a patch that > converts some of the s390 drivers from s390dbf to DTI. > > DTI uses the Generic Tracing Setup and Control (GTSC) API, which was > posted a couple of weeks ago and which I'll post an updated version of > following this patchset. > > For maximum satisfaction, you should also make sure your kernel has > these two relay patches applied: > > http://marc.info/?l=linux-kernel=118214275032484=2 > http://marc.info/?l=linux-kernel=118232840921694=2 > > Thanks also to Michael Ellerman for some useful suggestions on the > interface. > > Tom > > Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]> > Signed-off-by: David Wilder <[EMAIL PROTECTED]> > --- > dti.txt | 272 > > 1 file changed, 272 insertions(+) > > diff --git a/Documentation/drivers/dti.txt b/Documentation/drivers/dti.txt > new file mode 100644 > index 000..e071167 > --- /dev/null > +++ b/Documentation/drivers/dti.txt > @@ -0,0 +1,272 @@ > +Driver Tracing Interface (DTI) > +== > + > +The Driver Tracing Interface provides easy-to-use interfaces for > +logging per-cpu 'flight recorder' data in the kernel and merging and > +presenting it to userspace. > + > +On the kernel side, data can be logged as text using a printk()-like > +logging function, or it can be logged in binary form using a couple of > +special binary event logging functions. > + > +On the user side, the combined contents of all the data present in the > +per-cpu relay files can be read from a single
Re: Libata PATA status
On Jul 03, 2007, at 13:51:16, Alan Cox wrote: Libata General with respect to PATA [...snip...] Chipsets [...snip...] I'd love to try to poke holes in the libata PATA support, but sadly it doesn't look like any of my systems built-in ATA chipsets are supported yet. Has anyone started a rewrite of the PPC/PowerMac IDE driver? The current one is in "drivers/ide/ppc/pmac.c", and supports these chipsets: OHare ATA Heathrow ATA KeyLargo ATA-3 KeyLargo ATA-4 UniNorth ATA-6 (IE: Kauai) K2 ATA-6 Shasta ATA-6 I'd be willing to test drivers for the UniNorth ATA-6 and K2 ATA-6, as well as possibly the KeyLargo ATA-3/4, depending on what the old MDD G4 in my closet has. Sadly my libata-foo is insufficient for me to do anything useful (other than thoroughly testing my backup- restoration procedure, maybe :-D). Cheers, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
LZMA error on 2.6.16
Hi, . While compiling kernel on FC7, kernel-2.6.16 with LZMA compression utilily, we got the following compile error message. I already applied two pathes,lzma-init-2.6.16.patch5 , lzma-vmlinuz-2.6.16.patch5. And during compressing vmlinuz, I meet an error like the following messages. I also tried this on kernle-2.6.20, but got the same result. Could you please give me some tips ? . AR arch/i386/lib/lib.a GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 KSYM .tmp_kallsyms1.S AS .tmp_kallsyms1.o LD .tmp_vmlinux2 KSYM .tmp_kallsyms2.S AS .tmp_kallsyms2.o LD .tmp_vmlinux3 KSYM .tmp_kallsyms3.S AS .tmp_kallsyms3.o LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map AS arch/i386/boot/bootsect.o LD arch/i386/boot/bootsect AS arch/i386/boot/setup.o LD arch/i386/boot/setup AS arch/i386/boot/compressed/head.o CC arch/i386/boot/compressed/lzma_misc.o OBJCOPY arch/i386/boot/compressed/vmlinux.bin LZMA arch/i386/boot/compressed/vmlinux.bin.lzma make[2]: *** [arch/i386/boot/compressed/vmlinux.bin.lzma] Error 1 make[1]: *** [arch/i386/boot/compressed/vmlinux] Error 2 make: *** [bzImage] Error 2 [EMAIL PROTECTED] linux-2.6.16]# . Warm regards, Nobel 180도 달라진 야후! 메일 - 탄탄한 보안! 새로운 야후! 메일의 ‘안전주소'기능으로 스팸을 차단하세요. http://kr.content.mail.yahoo.com/cgland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tifm] Infinite loop
--- "Renato S. Yamane" <[EMAIL PROTECTED]> wrote: > When I insert a SDCard in my laptop M45-S355 my system crash because > tifm start a infinite loop. See below more detail about SD/MMC Card and > infinite loop. If you are using the built-in version found in 2.6.21 then it is a known problem. You can use the driver from here, to fix this: https://developer.berlios.de/project/showfiles.php?group_id=5510 (or wait for 2.6.22) Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail=graduation+gifts=bz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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][Documentation][resend] Add missing files and dirs to 00-INDEX in Documentation/
On Tue, 3 Jul 2007 21:21:02 -0400 Rob Landley wrote: > On Tuesday 03 July 2007 21:08:32 Jesper Juhl wrote: > > > That's Rob's problem, I guess. > > > > Let's leave final judgement of the patch to Rob then. That's fine by me. > > I plan to obsolete it within the next month, but for 2.6.22 you might as well > update it. I'll integrate that data that's there into http://kernel.org/doc > when I get a little less buried. (I might set up a git tree and queue up > Documentation reorganization patches too. But probably not this week.) > > So: > Signed-off-by: Rob Landley <[EMAIL PROTECTED]> ITYM Acked-by: I agree, go ahead and update it. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PKTCDVD related bugzilla bugs
Hello, Peter. Peter Osterlund wrote: > On Mon, 2 Jul 2007, Tejun Heo wrote: > >> Hello, it's me again. >> >> We have another bug which reportedly is related to pktcdvd. Please >> respond. >> >> http://bugzilla.kernel.org/show_bug.cgi?id=7547 >> http://bugzilla.kernel.org/show_bug.cgi?id=7805 > > The problem is that when you run pktsetup, the driver will open the > cdrom device and keep it open. A very long time ago, the driver didn't > do that, but that caused other problems, see for example: > > http://herbie.ucs.indiana.edu/hypermail/linux/kernel/0407.0/0761.html > > I don't know how to fix these problems in the kernel, but I know that an > old idea from Jens Axboe was to merge pktsetup and mount in user space > so that pktsetup only needs to run when you are actually going to use > packet writing. In bug 7547[1], somebody is issuing START_STOP to the ODD repeatedly which times out if the drive is empty. Is this coming from PKTCDVD or from userland polling? Also, do you mind adding yourself to the bug so that I don't have to relay? Thanks. -- tejun [1] http://bugzilla.kernel.org/show_bug.cgi?id=7547 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 -- Problems with suspend/resume.
On Tue, 3 Jul 2007 18:09:29 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote: > Sorry. I don't know who else to include in the To: list. Should I > send this again with .config information? Would ps -Af help? Gosh, what a lot of output we generated. It's pretty digestible though. It looks like these are the problem: cat D 002B 0 5603 1 (NOTLB) c8102e4c 0096 80cc15ad 002b c1176c2c c8102e38 0046 c7fb2bc0 c7fb2d50 c265c100 80cc15ad 002b c8102e4c c7f12d00 c014b438 0001 c036759c c63b6914 c8102e68 c63b68e0 0246 c8102e88 c0367416 Call Trace: [] __mutex_lock_slowpath+0x1c7/0x32c [] mutex_lock+0x21/0x24 [] drm_vma_info+0x1f/0x310 [drm] [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === INFO: lockdep is turned off. tail D 002C 0 5646 1 (NOTLB) c811ce4c 0096 7137dc36 002c c1175f98 c811ce38 0046 c80e15e0 c80e1770 c265c100 7137dc36 002c c811ce4c c7f11e00 c014b438 0001 c036759c c63b6914 c811ce68 c63b68e0 0246 c811ce88 c0367416 Call Trace: [] __mutex_lock_slowpath+0x1c7/0x32c [] mutex_lock+0x21/0x24 [] drm_vma_info+0x1f/0x310 [drm] [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === INFO: lockdep is turned off. cat D 0033 0 5910 1 (NOTLB) c8107e4c 0096 24ccdd52 0033 c014b438 0001 c8107e14 c7e9ed60 c7e9eef0 c265c100 24ccdd52 0033 c8107e4c c7f11b80 c014b438 0001 c036759c c63b6914 c8107e68 c63b68e0 0246 c8107e88 c0367416 Call Trace: [] __mutex_lock_slowpath+0x1c7/0x32c [] mutex_lock+0x21/0x24 [] drm_vma_info+0x1f/0x310 [drm] [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === INFO: lockdep is turned off. cat D 0033 0 5926 1 (NOTLB) c8160e4c 0096 8cc85f27 0033 c117483c c8160e38 0046 c80e0af0 c80e0c80 c265c100 8cc85f27 0033 c8160e4c c7f13480 c014b438 0001 c036759c c63b6914 c8160e68 c63b68e0 0246 c8160e88 c0367416 Call Trace: [] __mutex_lock_slowpath+0x1c7/0x32c [] mutex_lock+0x21/0x24 [] drm_vma_info+0x1f/0x310 [drm] [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === INFO: lockdep is turned off. cat D 0034 0 5950 1 (NOTLB) c8084e4c 0096 39b9c536 0034 c117afbc c8084e38 0046 c6ce15e0 c6ce1770 c265c100 39b9c536 0034 c8084e4c c7f13200 c014b438 0001 c036759c c63b6914 c8084e68 c63b68e0 0246 c8084e88 c0367416 Call Trace: [] __mutex_lock_slowpath+0x1c7/0x32c [] mutex_lock+0x21/0x24 [] drm_vma_info+0x1f/0x310 [drm] [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === and I'm guessing that this kernel is one which has already oopsed in drm_vma_info()? If so, then problem solved: it oopsed with the lock held. If not, then perhaps we have another problem in DRM. Or the same one remanifesting. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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][Documentation][resend] Add missing files and dirs to 00-INDEX in Documentation/
On Tuesday 03 July 2007 21:08:32 Jesper Juhl wrote: > > That's Rob's problem, I guess. > > Let's leave final judgement of the patch to Rob then. That's fine by me. I plan to obsolete it within the next month, but for 2.6.22 you might as well update it. I'll integrate that data that's there into http://kernel.org/doc when I get a little less buried. (I might set up a git tree and queue up Documentation reorganization patches too. But probably not this week.) So: Signed-off-by: Rob Landley <[EMAIL PROTECTED]> Thanks, Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Some NCQ numbers...
Hello, Michael Tokarev wrote: > Well. It looks like the results does not depend on the > elevator. Originally I tried with deadline, and just > re-ran the test with noop (hence the long delay with > the answer) - changing linux elevator changes almost > nothing in the results - modulo some random "fluctuations". I see. Thanks for testing. > In any case, NCQ - at least in this drive - just does > not work. Linux with its I/O elevator may help to > speed things up a bit, but the disk does nothing in > this area. NCQ doesn't slow things down either - it > just does not work. > > The same's for ST3250620NS "enterprise" drives. > > By the way, Seagate announced Barracuda ES 2 series > (in range 500..1200Gb if memory serves) - maybe with > those, NCQ will work better? No one would know without testing. > Or maybe it's libata which does not implement NCQ > "properly"? (As I shown before, with almost all > ol'good SCSI drives TCQ helps alot - up to 2x the > difference and more - with multiple I/O threads) Well, what the driver does is minimal. It just passes through all the commands to the harddrive. After all, NCQ/TCQ gives the harddrive more responsibility regarding request scheduling. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Don't miss the ARM-scsi fix.
On Tuesday 03 July 2007 15:31:04 Russell King - ARM Linux wrote: > > > http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=4454/1 > > > > > > It fixes a regression that occurred between 2.6.20 and 2.6.20-rc1. > > > Without it, qemu-system-arm can't use emulated SCSI drives. It wasn't > > > in -rc7, and the attached patch Works For Me (tm). > > > > Should have cc'ed Russell? > > It's been applied and is in my tree since yesterday. I've no idea why > Rob feels that he needs to pull patches out of the patch system. Just trying to point at it and make sure that one doesn't miss 2.6.22 final, and let you all know that it fixes a real bug I've been seeing and complaining about for a while. Reported in May: http://lkml.org/lkml/2007/5/10/670 Reported again in June: http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.2/0429.html Also poked at the qemu guys a few times. If you've got it under control already, life is good... Thanks, Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc7: known regressions with patches
On Wed, 4 Jul 2007, Andi Kleen wrote: > > Linus, also what about the revert of the HPET reservation? That would > fix a clear regression too. Thanks for reminding me. It probably isn't much of a regression any more (since we added the code to not use the HPET when it doesn't seem to be working), but yes, that should go in too. Applied and pushed out. Now we just need people to test and verify that the regressions are gone.. 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/
2.6.22-rc6-mm1: BUG_ON() mm/memory.c, vm_insert_pfn(), filemap_xip.c, and spufs
Recently there has been some discussion of the possiblity of reworking
some of filemap_xip.c to be pfn oriented. This would allow an XIP
fork of cramfs to use the filemap_xip framework. Today this is not
possible.
I've been trying out vm_insert_pfn() to start down that road. I used
spufs as a reference for how to use it. The include patch to cramfs
is my hack at it.
When I try to execute an XIP binary I get a BUG() on 2.6.22-rc6-mm1 at
mm/memory.c line 2334. The way I read this is says that spufs might
not work. I can't test it.
In spufs_mem_mmap() line 196 the vma is flagged as VM_PFNMAP:
vma->vm_flags |= VM_IO | VM_PFNMAP;
When you get a fault in a vma __do_fault() will get this vma and
BUG() on line 2334:
BUG_ON(vma->vm_flags & VM_PFNMAP);
What happened to the functionality of do_no_pfn()?
diff -r 74bad9e01817 fs/Kconfig
--- a/fs/KconfigThu Jun 28 13:49:43 2007 -0700
+++ b/fs/KconfigMon Jul 02 15:47:16 2007 -0700
@@ -65,8 +65,7 @@ config FS_XIP
config FS_XIP
# execute in place
bool
- depends on EXT2_FS_XIP
- default y
+ default n
config EXT3_FS
tristate "Ext3 journalling file system support"
@@ -1399,8 +1398,8 @@ endchoice
config CRAMFS
tristate "Compressed ROM file system support (cramfs)"
- depends on BLOCK
select ZLIB_INFLATE
+ select FS_XIP
help
Saying Y here includes support for CramFs (Compressed ROM File
System). CramFs is designed to be a simple, small, and compressed
diff -r 74bad9e01817 fs/cramfs/inode.c
--- a/fs/cramfs/inode.c Thu Jun 28 13:49:43 2007 -0700
+++ b/fs/cramfs/inode.c Tue Jul 03 17:45:42 2007 -0700
@@ -24,15 +24,21 @@
#include
#include
#include
-
+#include
#include
+static const struct file_operations cramfs_xip_fops;
static const struct super_operations cramfs_ops;
static const struct inode_operations cramfs_dir_inode_operations;
static const struct file_operations cramfs_directory_operations;
static const struct address_space_operations cramfs_aops;
+static const struct address_space_operations cramfs_xip_aops;
static DEFINE_MUTEX(read_mutex);
+
+static struct backing_dev_info cramfs_backing_dev_info = {
+ .ra_pages = 0,/* No readahead */
+};
/* These two macros may change in future, to provide better st_ino
@@ -77,19 +83,31 @@ static int cramfs_iget5_set(struct inode
/* Struct copy intentional */
inode->i_mtime = inode->i_atime = inode->i_ctime = zerotime;
inode->i_ino = CRAMINO(cramfs_inode);
+
+ if (CRAMFS_INODE_IS_XIP(inode))
+ inode->i_mapping->backing_dev_info = _backing_dev_info;
+
/* inode->i_nlink is left 1 - arguably wrong for directories,
but it's the best we can do without reading the directory
contents. 1 yields the right result in GNU find, even
without -noleaf option. */
if (S_ISREG(inode->i_mode)) {
- inode->i_fop = _ro_fops;
- inode->i_data.a_ops = _aops;
+ if (CRAMFS_INODE_IS_XIP(inode)) {
+ inode->i_fop = _xip_fops;
+ inode->i_data.a_ops = _xip_aops;
+ } else {
+ inode->i_fop = _ro_fops;
+ inode->i_data.a_ops = _aops;
+ }
} else if (S_ISDIR(inode->i_mode)) {
inode->i_op = _dir_inode_operations;
inode->i_fop = _directory_operations;
} else if (S_ISLNK(inode->i_mode)) {
inode->i_op = _symlink_inode_operations;
- inode->i_data.a_ops = _aops;
+ if (CRAMFS_INODE_IS_XIP(inode))
+ inode->i_data.a_ops = _xip_aops;
+ else
+ inode->i_data.a_ops = _aops;
} else {
inode->i_size = 0;
inode->i_blocks = 0;
@@ -111,34 +129,6 @@ static struct inode *get_cramfs_inode(st
return inode;
}
-/*
- * We have our own block cache: don't fill up the buffer cache
- * with the rom-image, because the way the filesystem is set
- * up the accesses should be fairly regular and cached in the
- * page cache and dentry tree anyway..
- *
- * This also acts as a way to guarantee contiguous areas of up to
- * BLKS_PER_BUF*PAGE_CACHE_SIZE, so that the caller doesn't need to
- * worry about end-of-buffer issues even when decompressing a full
- * page cache.
- */
-#define READ_BUFFERS (2)
-/* NEXT_BUFFER(): Loop over [0..(READ_BUFFERS-1)]. */
-#define NEXT_BUFFER(_ix) ((_ix) ^ 1)
-
-/*
- * BLKS_PER_BUF_SHIFT should be at least 2 to allow for "compressed"
- * data that takes up more space than the original and with unlucky
- * alignment.
- */
-#define BLKS_PER_BUF_SHIFT (2)
-#define BLKS_PER_BUF (1 << BLKS_PER_BUF_SHIFT)
-#define BUFFER_SIZE(BLKS_PER_BUF*PAGE_CACHE_SIZE)
-
-static unsigned char read_buffers[READ_BUFFERS][BUFFER_SIZE];
-static unsigned
Re: [PATCH][Documentation][resend] Add missing files and dirs to 00-INDEX in Documentation/
On 03/07/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Sun, 1 Jul 2007 01:05:59 +0200 Jesper Juhl <[EMAIL PROTECTED]> wrote: > This patch adds descriptions for a number of missing files and directories > to the Documentation/00-INDEX file. > People really should learn to keep this file up-to-date when adding or > moving documentation... Or just delete it. Does anyone use it? I know I use it (that's partly why I noticed that stuff was missing). Sure we could just delete it and the loss wouldn't be too great, but in any case, as long as we do have that file in there I feel that it ought to be up-to-date. That's Rob's problem, I guess. Let's leave final judgement of the patch to Rob then. That's fine by me. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.21.5 june 30th to july 1st date hang?
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Chuck Ebbert > Envoyé : 3 juillet 2007 17:03 > > On 07/03/2007 03:28 PM, Chris Friesen wrote: > > Arne Georg Gleditsch wrote: > > > >> An interesting exercise might be to > >> code up a small program to call adjtimex with timex.status |= > >> STA_INS, to see if this can trigger the problem. > > > > Setting the date to just before midnight June 30 UTC and then running > > the following as root triggered the crash on a modified 2.6.10. > > Anyone see anything wrong with the code below, or is this a valid > > indication of a bug in the leap second code? > > > > Fixed: > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2 > .6.git;a=commitdiff;h=746976a301ac9c9aa10d7d42454f8d6cdad8ff2b Thanx a lot! This was fast! (beat that closed source!) - vin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] remove mm/backing-dev.c:congestion_wait_interruptible()
On Tue, Jul 03, 2007 at 06:35:36PM -0400, Trond Myklebust wrote:
> On Tue, 2007-07-03 at 14:48 -0700, Andrew Morton wrote:
> > On Sun, 1 Jul 2007 22:20:51 +0200
> > Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > > congestion_wait_interruptible() is no longer used.
> >
> > We might as well just delete it?
>
> I agree. We're better off deleting it, but either would be fine by me.
Updated patch below.
> Trond
cu
Adrian
<-- snip -->
congestion_wait_interruptible() is no longer used.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Trond Myklebust <[EMAIL PROTECTED]>
---
include/linux/backing-dev.h |1 -
mm/backing-dev.c| 16
2 files changed, 17 deletions(-)
--- linux-2.6.22-rc4-mm2/include/linux/backing-dev.h.old2007-06-12
01:21:52.0 +0200
+++ linux-2.6.22-rc4-mm2/include/linux/backing-dev.h2007-06-12
01:22:00.0 +0200
@@ -93,7 +93,6 @@
void clear_bdi_congested(struct backing_dev_info *bdi, int rw);
void set_bdi_congested(struct backing_dev_info *bdi, int rw);
long congestion_wait(int rw, long timeout);
-long congestion_wait_interruptible(int rw, long timeout);
void congestion_end(int rw);
#define bdi_cap_writeback_dirty(bdi) \
--- linux-2.6.22-rc6-mm1/mm/backing-dev.c.old 2007-07-04 00:44:10.0
+0200
+++ linux-2.6.22-rc6-mm1/mm/backing-dev.c 2007-07-04 00:44:24.0
+0200
@@ -55,22 +55,6 @@
}
EXPORT_SYMBOL(congestion_wait);
-long congestion_wait_interruptible(int rw, long timeout)
-{
- long ret;
- DEFINE_WAIT(wait);
- wait_queue_head_t *wqh = _wqh[rw];
-
- prepare_to_wait(wqh, , TASK_INTERRUPTIBLE);
- if (signal_pending(current))
- ret = -ERESTARTSYS;
- else
- ret = io_schedule_timeout(timeout);
- finish_wait(wqh, );
- return ret;
-}
-EXPORT_SYMBOL(congestion_wait_interruptible);
-
/**
* congestion_end - wake up sleepers on a congested backing_dev_info
* @rw: READ or WRITE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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][isapnp] Fix a potential NULL pointer dereference in isapnp_read_tag()
On 03/07/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Sun, 1 Jul 2007 01:38:31 +0200 Jesper Juhl <[EMAIL PROTECTED]> wrote: > The Coverity checker spotted (as bug #809) that we dereference 'type' > long before we actually test it against NULL in > drivers/pnp/isapnp/core.c::isapnp_read_tag() - both branches of the > 'if (tag & 0x80)' dereference type, and since this 'if' is before the test > against NULL and the return of -1, this will blow up is ever type is NULL. > This is easy to fix by simply moving the NULL test to the beginning of > the function. > [snip] dood, look at the callers. NULL is not possible here. You are right, there's absolutely no way that we could get a NULL pointer there - that was sloppy of me :-( I guess we should just get rid of the check completely. I'll cook up a patch for that tomorrow. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][Documentation][resend] Add missing files and dirs to 00-INDEX in Documentation/
On Tuesday 03 July 2007 15:58:52 Andrew Morton wrote: > On Sun, 1 Jul 2007 01:05:59 +0200 > > Jesper Juhl <[EMAIL PROTECTED]> wrote: > > This patch adds descriptions for a number of missing files and > > directories to the Documentation/00-INDEX file. > > People really should learn to keep this file up-to-date when adding or > > moving documentation... > > Or just delete it. Does anyone use it? > > That's Rob's problem, I guess. Documentation/* is a gigantic mess, currently organized based on where random passers-by put things down last. I posted a couple of patches to do minor cleanups to it last month, but since then I've put that on the back burner, because Documentation/* can't do what I need. I spent the first month of the documentation fellowship trying to find all the kernel documentation I could, and figure out how to organize it. It would be easy to pile up a big heap (that's sort of what http://kernel.org/docs has now, and that's less than half of what I've tracked down), but the hard part is _organizing_ it. I can't figure out what _isn't_ documented until I have a handle on what _is_ documented. (And then I can worry about documentation being stale, incomplete, or simply wrong...) I was looking at the Documentation directory in the kernel as the primary source of documentation and the core around which the rest could be organized: but it isn't. Out on the internet there are 8 gazillion other sources of documentation for the Linux kernel: OLS papers, the LWN kernel article index, wikis, developer blogs, specifications, online books, things on sourceforge... most of that is NEVER getting indexed into Documentation/* because it's HTML or PDF under various different non-gpl licenses, and the Documentation directory contains text files. The fact that Documentation is text means it can't easily link out to resources that live on the web. The index I need to organize all this stuff with must be HTML because huge chunks of it simply aren't local. The kernel generates HTML documentation via "make htmldocs", but that can't even coherently link to everything in the Documentation directory today, let alone the whole web, because it's generated by grepping through the kernel sources and that imposes a strong structure on it that makes it bad for indexing things outside itself. It can be linked _into_ by an external index, but it can't easily BE an index composed primarily of external references. That's not what it's for. So that's out too. I intend to integrate the existing 00-index into the new index (the bare skeleton of which just went up at http://kernel.org/doc earlier today, although expect it to change a lot as links and sub-pages get added and I generally go "what was I THINKING?"). And I'll be adding in all the stuff that ISN'T in 00-index, too. I need to set up a link checker to detect 404 and also detect files that aren't linked from anywhere in my local set of directories... I have a mercurial archive at http://landley.net/hg/kdocs which I'll accept patches into (it's deeply unimpressive at the moment, I'm working on it), and I'd like said patches cc:'d to [EMAIL PROTECTED] which I'm trying to resurrect. I also might shuffle all the stuff I'm mirroring (like http://kernel.org/doc/ols) into its own mirror/* subdirectory for easier mirroring if other people want a local copy of this stuff, I'm still trying to figure out the best way to organize all this. (I'd prefer not to confuse google by having multiple live mirrors out on the web, but hey: it's a free country.) Keep in mind my previous laptop died a month ago, and my new one arrived the monday before OLS, at which my todo list got much longer. I'm still catching up. Organizing is the hard part. Just _writing_ documentation is comparatively easy... Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] usb: allocated usb releated dma buffer with kmalloc_node
[PATCH 4/4] usb: allocated usb releated dma buffer with kmalloc_node
For amd64 based two way system. USB always on node0. but dma buffer for urb
allocated via kmalloc always get ram on node1. So change to kmalloc_node to
get dma_buffer on corresponding node.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index dd34823..604a262 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -504,7 +504,8 @@ int usb_get_configuration(struct usb_device *dev)
if (!dev->rawdescriptors)
goto err2;
- buffer = kmalloc(USB_DT_CONFIG_SIZE, GFP_KERNEL);
+ buffer = kmalloc_node(USB_DT_CONFIG_SIZE, GFP_KERNEL,
+ dev_to_node(>dev));
if (!buffer)
goto err2;
desc = (struct usb_config_descriptor *)buffer;
@@ -531,7 +532,8 @@ int usb_get_configuration(struct usb_device *dev)
USB_DT_CONFIG_SIZE);
/* Now that we know the length, get the whole thing */
- bigbuffer = kmalloc(length, GFP_KERNEL);
+ bigbuffer = kmalloc_node(length, GFP_KERNEL,
+dev_to_node(>dev));
if (!bigbuffer) {
result = -ENOMEM;
goto err;
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 927a181..99dc0c3 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -718,7 +718,8 @@ static int proc_bulk(struct dev_state *ps, void __user *arg)
len1 = bulk.len;
if (len1 > MAX_USBFS_BUFFER_SIZE)
return -EINVAL;
- if (!(tbuf = kmalloc(len1, GFP_KERNEL)))
+ tbuf = kmalloc_node(len1, GFP_KERNEL, dev_to_node(>dev));
+ if (!tbuf)
return -ENOMEM;
tmo = bulk.timeout;
if (bulk.ep & 0x80) {
@@ -938,7 +939,9 @@ static int proc_do_submiturb(struct dev_state *ps, struct
usbdevfs_urb *uurb,
/* min 8 byte setup packet, max 8 byte setup plus an arbitrary
data stage */
if (uurb->buffer_length < 8 || uurb->buffer_length > (8 +
MAX_USBFS_BUFFER_SIZE))
return -EINVAL;
- if (!(dr = kmalloc(sizeof(struct usb_ctrlrequest), GFP_KERNEL)))
+ dr = kmalloc_node(sizeof(struct usb_ctrlrequest), GFP_KERNEL,
+ dev_to_node(>dev->dev));
+ if (!dr)
return -ENOMEM;
if (copy_from_user(dr, uurb->buffer, 8)) {
kfree(dr);
@@ -990,7 +993,9 @@ static int proc_do_submiturb(struct dev_state *ps, struct
usbdevfs_urb *uurb,
!= USB_ENDPOINT_XFER_ISOC)
return -EINVAL;
isofrmlen = sizeof(struct usbdevfs_iso_packet_desc) *
uurb->number_of_packets;
- if (!(isopkt = kmalloc(isofrmlen, GFP_KERNEL)))
+ isopkt = kmalloc_node(isofrmlen, GFP_KERNEL,
+ dev_to_node(>dev->dev));
+ if (!isopkt)
return -ENOMEM;
if (copy_from_user(isopkt, iso_frame_desc, isofrmlen)) {
kfree(isopkt);
@@ -1032,7 +1037,9 @@ static int proc_do_submiturb(struct dev_state *ps, struct
usbdevfs_urb *uurb,
kfree(dr);
return -ENOMEM;
}
- if (!(as->urb->transfer_buffer = kmalloc(uurb->buffer_length,
GFP_KERNEL))) {
+ as->urb->transfer_buffer = kmalloc_node(uurb->buffer_length,
+GFP_KERNEL, dev_to_node(>dev->dev));
+ if (!as->urb->transfer_buffer) {
kfree(isopkt);
kfree(dr);
free_async(as);
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 24f10a1..ec49ce5 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -449,7 +449,9 @@ void usb_hub_tt_clear_buffer (struct usb_device *udev, int
pipe)
* since each TT has "at least two" buffers that can need it (and
* there can be many TTs per hub). even if they're uncommon.
*/
- if ((clear = kmalloc (sizeof *clear, GFP_ATOMIC)) == NULL) {
+ clear = kmalloc_node(sizeof *clear, GFP_ATOMIC,
+dev_to_node(>dev));
+ if (clear == NULL) {
dev_err (>dev, "can't save CLEAR_TT_BUFFER state\n");
/* FIXME recover somehow ... RESET_TT? */
return;
@@ -611,7 +613,8 @@ static int hub_configure(struct usb_hub *hub,
goto fail;
}
- hub->status = kmalloc(sizeof(*hub->status), GFP_KERNEL);
+ hub->status = kmalloc_node(sizeof(*hub->status), GFP_KERNEL,
+ dev_to_node(>dev));
if (!hub->status) {
message = "can't kmalloc hub status buffer";
ret = -ENOMEM;
@@ -619,7 +622,8 @@ static
Re: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway
On Tue, Jul 03, 2007 at 06:17:04PM -0600, Robert Hancock wrote: > Matthew Garrett wrote: > >Leave the process blocked and defer any i/o until after resume. Why does > >it need to be any more complicated than that? > > It gets complicated when this has to be added and TESTED in EVERY > driver. The implied contract for drivers previously was that their > device would not get accessed after it was suspended until it had been > resumed first. This proposed change violates that. No, that's only ever been true for ACPI systems. It's never been true elsewhere, and it won't be true for anything implementing any sort of runtime power management. > I don't think this sort of handling is something that individual drivers > should have to deal with (at least not ones that are part of a framework > like USB, libata, etc.) I'd agree there. Driver midlayers (where they exist) are the appropriate place to handle this. -- 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/
[PATCH 1/4] try parent numa_node at first before using default
[PATCH 1/4] try parent numa_node at first before using default
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/drivers/base/core.c b/drivers/base/core.c
index dd40d78..c344d82 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -547,6 +547,8 @@ static void klist_children_put(struct klist_node *n)
void device_initialize(struct device *dev)
{
+ int node;
+
kobj_set_kset_s(dev, devices_subsys);
kobject_init(>kobj);
klist_init(>klist_children, klist_children_get,
@@ -557,7 +559,9 @@ void device_initialize(struct device *dev)
spin_lock_init(>devres_lock);
INIT_LIST_HEAD(>devres_head);
device_init_wakeup(dev, 0);
- set_dev_node(dev, -1);
+
+ node = dev->parent ? dev_to_node(dev->parent) : -1;
+ set_dev_node(dev, node);
}
#ifdef CONFIG_SYSFS_DEPRECATED
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] net: make forcedeth to use kmalloc_node and __netdev_alloc_skb for skb allocation
[PATCH 3/4] net: make forcedeth to use kmalloc_node and __netdev_alloc_skb for
skb allocation
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 42ba1c0..aa188f4 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -1383,7 +1383,8 @@ static int nv_alloc_rx(struct net_device *dev)
less_rx = np->last_rx.orig;
while (np->put_rx.orig != less_rx) {
- struct sk_buff *skb = dev_alloc_skb(np->rx_buf_sz +
NV_RX_ALLOC_PAD);
+ struct sk_buff *skb = __netdev_alloc_skb(dev, np->rx_buf_sz +
+ NV_RX_ALLOC_PAD, GFP_ATOMIC);
if (skb) {
np->put_rx_ctx->skb = skb;
np->put_rx_ctx->dma = pci_map_single(np->pci_dev,
@@ -1415,7 +1416,8 @@ static int nv_alloc_rx_optimized(struct net_device *dev)
less_rx = np->last_rx.ex;
while (np->put_rx.ex != less_rx) {
- struct sk_buff *skb = dev_alloc_skb(np->rx_buf_sz +
NV_RX_ALLOC_PAD);
+ struct sk_buff *skb = __netdev_alloc_skb(dev, np->rx_buf_sz +
+ NV_RX_ALLOC_PAD, GFP_ATOMIC);
if (skb) {
np->put_rx_ctx->skb = skb;
np->put_rx_ctx->dma = pci_map_single(np->pci_dev,
@@ -3976,8 +3978,10 @@ static int nv_set_ringparam(struct net_device *dev,
struct ethtool_ringparam* ri
sizeof(struct ring_desc_ex) *
(ring->rx_pending + ring->tx_pending),
_addr);
}
- rx_skbuff = kmalloc(sizeof(struct nv_skb_map) * ring->rx_pending,
GFP_KERNEL);
- tx_skbuff = kmalloc(sizeof(struct nv_skb_map) * ring->tx_pending,
GFP_KERNEL);
+ rx_skbuff = kmalloc_node(sizeof(struct nv_skb_map) * ring->rx_pending,
+GFP_KERNEL, dev_to_node(>dev));
+ tx_skbuff = kmalloc_node(sizeof(struct nv_skb_map) * ring->tx_pending,
+GFP_KERNEL, dev_to_node(>dev));
if (!rxtx_ring || !rx_skbuff || !tx_skbuff) {
/* fall back to old rings */
if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) {
@@ -4372,7 +4376,7 @@ static int nv_loopback_test(struct net_device *dev)
/* setup packet for tx */
pkt_len = ETH_DATA_LEN;
- tx_skb = dev_alloc_skb(pkt_len);
+ tx_skb = __netdev_alloc_skb(dev, pkt_len, GFP_ATOMIC);
if (!tx_skb) {
printk(KERN_ERR "dev_alloc_skb() failed during loopback test"
" of %s\n", dev->name);
@@ -4976,6 +4980,8 @@ static int __devinit nv_probe(struct pci_dev *pci_dev,
const struct pci_device_i
dev->base_addr = (unsigned long)np->base;
dev->irq = pci_dev->irq;
+ printk(KERN_INFO "nv_probe: numa_node : %02d\n",
+ dev_to_node(_dev->dev));
np->rx_ring_size = RX_RING_DEFAULT;
np->tx_ring_size = TX_RING_DEFAULT;
@@ -4995,8 +5001,11 @@ static int __devinit nv_probe(struct pci_dev *pci_dev,
const struct pci_device_i
goto out_unmap;
np->tx_ring.ex = >rx_ring.ex[np->rx_ring_size];
}
- np->rx_skb = kmalloc(sizeof(struct nv_skb_map) * np->rx_ring_size,
GFP_KERNEL);
- np->tx_skb = kmalloc(sizeof(struct nv_skb_map) * np->tx_ring_size,
GFP_KERNEL);
+ np->rx_skb = kmalloc_node(sizeof(struct nv_skb_map) * np->rx_ring_size,
+ GFP_KERNEL, dev_to_node(_dev->dev));
+ np->tx_skb = kmalloc_node(sizeof(struct nv_skb_map) * np->tx_ring_size,
+ GFP_KERNEL, dev_to_node(_dev->dev));
+
if (!np->rx_skb || !np->tx_skb)
goto out_freering;
memset(np->rx_skb, 0, sizeof(struct nv_skb_map) * np->rx_ring_size);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] net: use numa_node in net_devcice->dev instead of parent
[PATCH 2/4] net: use numa_node in net_devcice->dev instead of parent
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 27cfe5f..005cc1c 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -217,7 +217,7 @@ nodata:
struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
unsigned int length, gfp_t gfp_mask)
{
- int node = dev->dev.parent ? dev_to_node(dev->dev.parent) : -1;
+ int node = dev_to_node(>dev);
struct sk_buff *skb;
skb = __alloc_skb(length + NET_SKB_PAD, gfp_mask, 0, node);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
I'd like to reference a paper titled "FASS : A Flash-Aware Swap System". (http://kernel.kaist.ac.kr/~jinsoo/publication/iwssps05.pdf) The paper describes a technique that uses NAND flash as a swap device without FTL (Flash Translation Layer) or filesystem. It is not related with XIP, however. On 7/3/07, Jörn Engel <[EMAIL PROTECTED]> wrote: On Mon, 2 July 2007 17:46:40 -0700, Jared Hulbert wrote: > > Right, the solution to swap problem is identical to the rw XIP > filesystem problem.Jörn, that's why you're the self-appointed > subject matter expert! All right. I'll try to make an important face whenever the subject comes up. Nick, do you have a problem if LogFS occupies two brainslots at the meeting? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Remove unneeded lock_kernel() in drivers/block/loop.c
This patch remove the unneeded lock_kernel() in drivers/block/loop.c. I
read the code as this lock_kernel() doesn't protect anything. Loopback
code use lo_ctl_mutex for syncronization.
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 0ed5470..1cc004e 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1286,7 +1286,6 @@ static long lo_compat_ioctl(struct file *file, unsigned
int cmd, unsigned long a
struct loop_device *lo = inode->i_bdev->bd_disk->private_data;
int err;
- lock_kernel();
switch(cmd) {
case LOOP_SET_STATUS:
mutex_lock(>lo_ctl_mutex);
@@ -1312,7 +1311,6 @@ static long lo_compat_ioctl(struct file *file, unsigned
int cmd, unsigned long a
err = -ENOIOCTLCMD;
break;
}
- unlock_kernel();
return err;
}
#endif
--
--
Diego Woitasen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Two trivial whitespace fixes in lockdep/spinlock code
On Wed, 4 Jul 2007 02:14:42 +0200 (CEST) Jiri Kosina <[EMAIL PROTECTED]> wrote:
> From: Jiri Kosina <[EMAIL PROTECTED]>
>
> Two trivial whitespace fixes in lockdep/spinlock code
>
> Cc: Ingo Molnar <[EMAIL PROTECTED]>
> Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
>
> diff --git a/kernel/lockdep.c b/kernel/lockdep.c
> index 1a5ff22..12ca5fd 100644
> --- a/kernel/lockdep.c
> +++ b/kernel/lockdep.c
> @@ -1222,7 +1222,7 @@ register_lock_class(struct lockdep_map *lock, unsigned
> int subclass, int force)
>
> /*
>* Debug-check: all keys must be persistent!
> - */
> + */
> if (!static_obj(lock->key)) {
> debug_locks_off();
> printk("INFO: trying to register non-static key.\n");
> diff --git a/kernel/spinlock.c b/kernel/spinlock.c
> index 2c6c2bf..5386d7e 100644
> --- a/kernel/spinlock.c
> +++ b/kernel/spinlock.c
> @@ -28,7 +28,7 @@ int __lockfunc _spin_trylock(spinlock_t *lock)
> spin_acquire(>dep_map, 0, 1, _RET_IP_);
> return 1;
> }
> -
> +
> preempt_enable();
> return 0;
> }
Too trivial, sorry: we could generate 8 million patches like this.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway
Matthew Garrett wrote: On Tue, Jul 03, 2007 at 06:21:42PM -0400, Alan Stern wrote: On Tue, 3 Jul 2007, Matthew Garrett wrote: We're used to the idea of applications blocking when a resource they're using goes away - NFS has done it forever. You persist in evading my point. I'm not worried about applications; I'm worried about drivers. Let me put it explicitly: You're writing a driver. You're working on the read, write, or probe method. You add code to check if a system sleep is underway. Suppose the answer is Yes -- what does your driver do next? Leave the process blocked and defer any i/o until after resume. Why does it need to be any more complicated than that? It gets complicated when this has to be added and TESTED in EVERY driver. The implied contract for drivers previously was that their device would not get accessed after it was suspended until it had been resumed first. This proposed change violates that. I don't think this sort of handling is something that individual drivers should have to deal with (at least not ones that are part of a framework like USB, libata, etc.) -- 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: New systems: eu.kernel.org
Michal Piotrowski wrote: > > Can you fix diff view feature? > > "diffview is looping on the cached resource: > /home/httpd/cache/diffview/_I/_IeThHWuB2t0pJl1sQoV2px2OXY/index" > Fixed, thanks for the note. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [RESEND] X86_64: fix wrong comment regarding set_fixmap()
[ still no comment to it, another resend together with the rest of my queue ] From: Jiri Kosina <[EMAIL PROTECTED]> X86_64: fix wrong comment regarding set_fixmap() The function name is set_fixmap(), not fixmap_set() as stated in the comment. Also fix a typo, punctuation and lower/uppercase a bit. Cc: Andi Kleen <[EMAIL PROTECTED]> Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]> diff --git a/include/asm-x86_64/fixmap.h b/include/asm-x86_64/fixmap.h index e90e167..c3574e5 100644 --- a/include/asm-x86_64/fixmap.h +++ b/include/asm-x86_64/fixmap.h @@ -22,9 +22,9 @@ * compile time, but to set the physical address only * in the boot process. * - * these 'compile-time allocated' memory buffers are - * fixed-size 4k pages. (or larger if used with an increment - * highger than 1) use fixmap_set(idx,phys) to associate + * These 'compile-time allocated' memory buffers are + * fixed-size 4k pages (or larger if used with an increment + * higher than 1). Use set_fixmap(idx,phys) to associate * physical memory with fixmap indices. * * TLB entries of such buffers will not be flushed across - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] kernel/printk.c: document possible deadlock against scheduler
From: Jiri Kosina <[EMAIL PROTECTED]> kernel/printk.c: document possible deadlock against scheduler The printk's comment states that it can be called from every context, which might lead to false illusion that it could be called from everywhere without any restrictions. This is however not true - a call to printk() could deadlock if called from scheduler code (namely from schedule(), wake_up(), etc) on runqueue lock when it tries to wake up klogd. Document this. Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]> diff --git a/kernel/printk.c b/kernel/printk.c index 0bbdeac..a3a7d53 100644 --- a/kernel/printk.c +++ b/kernel/printk.c @@ -483,6 +483,9 @@ static int have_callable_console(void) * @fmt: format string * * This is printk(). It can be called from any context. We want it to work. + * Be aware of the fact that if oops_in_progress is not set, we might try to + * wake klogd up which could deadlock on runqueue lock if printk() is called + * from scheduler code. * * We try to grab the console_sem. If we succeed, it's easy - we log the output and * call the console drivers. If we fail to get the semaphore we place the output - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Two trivial whitespace fixes in lockdep/spinlock code
From: Jiri Kosina <[EMAIL PROTECTED]>
Two trivial whitespace fixes in lockdep/spinlock code
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
diff --git a/kernel/lockdep.c b/kernel/lockdep.c
index 1a5ff22..12ca5fd 100644
--- a/kernel/lockdep.c
+++ b/kernel/lockdep.c
@@ -1222,7 +1222,7 @@ register_lock_class(struct lockdep_map *lock, unsigned
int subclass, int force)
/*
* Debug-check: all keys must be persistent!
-*/
+*/
if (!static_obj(lock->key)) {
debug_locks_off();
printk("INFO: trying to register non-static key.\n");
diff --git a/kernel/spinlock.c b/kernel/spinlock.c
index 2c6c2bf..5386d7e 100644
--- a/kernel/spinlock.c
+++ b/kernel/spinlock.c
@@ -28,7 +28,7 @@ int __lockfunc _spin_trylock(spinlock_t *lock)
spin_acquire(>dep_map, 0, 1, _RET_IP_);
return 1;
}
-
+
preempt_enable();
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: New systems: eu.kernel.org
Hi Peter, On 04/07/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote: Hi all, Thanks to HP, ISC and Umeå Universitet, kernel.org now has official servers in Europe. Specifically, we have www1.eu.kernel.org hosted at ISC Amsterdam, and www2.eu.kernel.org at UMU (Umeå, Sweden.) They are collectively accessible as www.eu.kernel.org. This is a full service of kernel.org and not a mirror. Can you fix diff view feature? "diffview is looping on the cached resource: /home/httpd/cache/diffview/_I/_IeThHWuB2t0pJl1sQoV2px2OXY/index" http://eu.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv2.6%2Fsnapshots%2Fpatch-2.6.22-rc7-git2.bz2 In the future, we hope to add some sort of smart DNS to automatically redirect traffic, as well as additional services in Europe. -hpa Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata_acpi: A different strategy for using ACPI information
Alan Cox wrote: Lots of BIOSen simply return the BIOS set modes via the ACPI methods and pass back the values you give it across suspend/resume. Thus instead of trying to do clever stuff with this data we instead use it as a way to take a sneak peak at cable type information when viable. This should help us catch more of the laptops that do weird stuff, the VIA SATA bridges and the totally horked Nvidia cable handling. For now its only used by the VIA and AMD/NV driver until we get a better idea of whether this is a sensible idea or not. Opinions ? Signed-off-by: Alan Cox <[EMAIL PROTECTED]> Looks fairly reasonable to me. However, I suspect any use of _GTM is somewhat dangerous (at least after the resume) unless we use the _STM and _GTF methods in the proper sequence when resuming. (Is that in the -mm tree now?) Keep in mind that in the pata_acpi case where we don't do anything to program the hardware directly, we can still use _STM to program a lower speed than the BIOS chose if we decide to do this. Windows does indeed do this (you can force PIO mode in the control panel, and it will also reduce UDMA speeds or drop to PIO if there are too many CRC errors or timeouts), so this should be safe. We just had better be sure that the speed we give it is valid, since there is no sane way for the function to indicate failure. (Thus the problem with the "cram in all possible values to see what it supports" strategy for determining mode limits..) -- 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: 2.6.22-rc7: known regressions with patches
On Wednesday 04 July 2007 00:12:10 Björn Steinbrink wrote:
> On 2007.07.03 14:42:25 -0700, Linus Torvalds wrote:
> >
> >
> > On Tue, 3 Jul 2007, Bj?rn Steinbrink wrote:
> > > Andi said that one of the regression fixes wasn't critical for .22 and
> > > that he wants to do a stopgap for the other regression (my patch
> > > sucked), reverting the code to the .21 version. So you can drop the
> > > patches and/or me here.
> >
> > Can you say which patch should be reverted. This thing really shouldn't
> > have gone on this long, I would have hopef we had the oprofile thing
> > sorted out already..
>
> That would be commit 09198e68501a7e34737cd9264d266f42429abcdc, for which
> there are already a few fixes in your tree. Andi, did you intent to
> fully revert that, or just certain parts of it?
Just two functions, but in a different file. Here's the patch.
Linus, also what about the revert of the HPET reservation? That would
fix a clear regression too.
-Andi
Revert perfctr reservation to 2.6.21 state
With this change it works again when the nmi watchdog is disabled.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linux/arch/i386/kernel/cpu/perfctr-watchdog.c
===
--- linux.orig/arch/i386/kernel/cpu/perfctr-watchdog.c
+++ linux/arch/i386/kernel/cpu/perfctr-watchdog.c
@@ -55,14 +55,45 @@ static DEFINE_PER_CPU(struct nmi_watchdo
/* converts an msr to an appropriate reservation bit */
static inline unsigned int nmi_perfctr_msr_to_bit(unsigned int msr)
{
- return wd_ops ? msr - wd_ops->perfctr : 0;
+ /* returns the bit offset of the performance counter register */
+ switch (boot_cpu_data.x86_vendor) {
+ case X86_VENDOR_AMD:
+ return (msr - MSR_K7_PERFCTR0);
+ case X86_VENDOR_INTEL:
+ if (cpu_has(_cpu_data, X86_FEATURE_ARCH_PERFMON))
+ return (msr - MSR_ARCH_PERFMON_PERFCTR0);
+
+ switch (boot_cpu_data.x86) {
+ case 6:
+ return (msr - MSR_P6_PERFCTR0);
+ case 15:
+ return (msr - MSR_P4_BPU_PERFCTR0);
+ }
+ }
+ return 0;
}
/* converts an msr to an appropriate reservation bit */
/* returns the bit offset of the event selection register */
static inline unsigned int nmi_evntsel_msr_to_bit(unsigned int msr)
{
- return wd_ops ? msr - wd_ops->evntsel : 0;
+ /* returns the bit offset of the event selection register */
+ switch (boot_cpu_data.x86_vendor) {
+ case X86_VENDOR_AMD:
+ return (msr - MSR_K7_EVNTSEL0);
+ case X86_VENDOR_INTEL:
+ if (cpu_has(_cpu_data, X86_FEATURE_ARCH_PERFMON))
+ return (msr - MSR_ARCH_PERFMON_EVENTSEL0);
+
+ switch (boot_cpu_data.x86) {
+ case 6:
+ return (msr - MSR_P6_EVNTSEL0);
+ case 15:
+ return (msr - MSR_P4_BSU_ESCR0);
+ }
+ }
+ return 0;
+
}
/* checks for a bit availability (hack for oprofile) */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Re: Sparc32: random invalid instruction occourances on sparc32 (sun4c)
On Tue, 2007-07-03 at 23:47 +0100, Mark Fortescue wrote:
> Hi David,
>
> I will try out your patch shortly.
Thanks.
> I may be wrong about the size calculations but if you take a look at lines
> 2174 to 2188 and 2207 to 2203, reading the comments suggest to me that
> these need to be changed to match the changes to the RedZone words.
> Failing to change these means that 32bit aligned access of the 64bit
> RedZone words is still posible and this will kill sun4c.
Why do we need more than the existing:
if (flags & SLAB_RED_ZONE || flags & SLAB_STORE_USER)
ralign = __alignof__(unsigned long long);
> For the 64bit RedZone word to be 64bit aligned (required by sun4c), the
> User word must be 64bit aligned. I don't see where in your patch, this is
> enforced.
Where __alignof__(long long) > BYTES_PER_WORD my patch should lead to
this layout (32-bit words):
[ redzone1 bits 63-32 ]
[ redzone1 bits 31-0 ]
[... object ... ]
[... object ... ]
[ redzone2 bits 63-32 ]
[ redzone2 bits 31-0 ]
[unused ]
[ user word ]
The user word is a 32-bit value; there's no requirement for _it_ to be
aligned.
Hm, actually I think my patch may be incomplete -- I need to adjust the
size of the actual object too. This patch should be better...
diff --git a/mm/slab.c b/mm/slab.c
index a9c4472..8081c07 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -547,7 +547,7 @@ static unsigned long long *dbg_redzone2(struct kmem_cache
*cachep, void *objp)
if (cachep->flags & SLAB_STORE_USER)
return (unsigned long long *)(objp + cachep->buffer_size -
sizeof(unsigned long long) -
- BYTES_PER_WORD);
+ max(BYTES_PER_WORD,
__alignof__(unsigned long long)));
return (unsigned long long *) (objp + cachep->buffer_size -
sizeof(unsigned long long));
}
@@ -2223,8 +2223,11 @@ kmem_cache_create (const char *name, size_t size, size_t
align,
* overridden by architecture or caller mandated alignment if either
* is greater than BYTES_PER_WORD.
*/
- if (flags & SLAB_RED_ZONE || flags & SLAB_STORE_USER)
+ if (flags & SLAB_RED_ZONE || flags & SLAB_STORE_USER) {
ralign = __alignof__(unsigned long long);
+ size += (__alignof__(unsigned long long) - 1);
+ size &= ~(__alignof__(unsigned long long) - 1);
+ }
/* 2) arch mandated alignment */
if (ralign < ARCH_SLAB_MINALIGN) {
@@ -2261,9 +2264,14 @@ kmem_cache_create (const char *name, size_t size, size_t
align,
}
if (flags & SLAB_STORE_USER) {
/* user store requires one word storage behind the end of
-* the real object.
+* the real object. But if the second red zone must be
+* aligned 'better' than that, allow for it.
*/
- size += BYTES_PER_WORD;
+ if (flags & SLAB_RED_ZONE
+ && BYTES_PER_WORD < __alignof__(unsigned long long))
+ size += __alignof__(unsigned long long);
+ else
+ size += BYTES_PER_WORD;
}
#if FORCED_DEBUG && defined(CONFIG_DEBUG_PAGEALLOC)
if (size >= malloc_sizes[INDEX_L3 + 1].cs_size
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 -- BUG - EIP: [] drm_vma_info+0x2a5/0x310 [drm] SS:ESP 0068:c80cde9c
On Tue, 3 Jul 2007 15:59:08 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote: > I ran the command: > find /proc | xargs grep a > > BUG: unable to handle kernel NULL pointer dereference at virtual > address > printing eip: > f8ac1350 > *pde = > Oops: [#1] > SMP > Modules linked in: arc4 ecb blkcipher cryptomgr crypto_algapi > ieee80211_crypt_wep bluetooth i915 drm acpi_cpufreq > cpufreq_conservative cpufreq_powersave cpufreq_performance ac battery > video output button processor container firewire_sbp2 parport_pc lp > parport pcmcia snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss > snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss yenta_socket > rsrc_nonstatic sdhci snd_seq_midi_event ipw2200 tifm_7xx1 mmc_core > pcmcia_core ieee80211 ieee80211_crypt tifm_core snd_seq snd_timer > snd_seq_device evdev shpchp snd iTCO_wdt iTCO_vendor_support > pci_hotplug soundcore snd_page_alloc firewire_ohci firewire_core > crc_itu_t 8139too ehci_hcd uhci_hcd usbcore fan > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010283 (2.6.22-rc6-mm1 #5) > EIP is at drm_vma_info+0x2a5/0x310 [drm] > eax: ebx: c80cdf38 ecx: edx: > esi: 8000 edi: c467e000 ebp: c80cdf0c esp: c80cde9c > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > Process grep (pid: 5172, ti=c80cd000 task=c7e9ed60 task.ti=c80cd000) > Stack: c467e000 f8ac595a f800 3800 c0526e9c c80cdefc >c0165700 0044 0001 c7e9ed60 c467e000 c63b68e0 >c1195548 0035 c7e9f328 0001 000800d0 > Call Trace: > [] proc_file_read+0x108/0x222 > [] proc_reg_read+0x63/0x76 > [] vfs_read+0xb0/0x139 > [] sys_read+0x3d/0x72 > [] sysenter_past_esp+0x6b/0xb5 > [] 0xe410 > === > INFO: lockdep is turned off. > Code: 24 04 c9 59 ac f8 8b 45 c8 01 d8 89 04 24 e8 3c 66 74 c7 01 c3 > 89 5d d8 81 fb b0 0f 00 00 77 4a 8b 45 d4 8b 00 89 45 d4 8b 55 d4 <8b> > 02 0f 18 00 90 8b 45 10 05 98 01 00 00 39 c2 0f 85 e7 fd ff > EIP: [] drm_vma_info+0x2a5/0x310 [drm] SS:ESP 0068:c80cde9c Dave, your code is being bad. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [EXT4 set 4][PATCH 1/5] i_version:64 bit inode version
On Jul 03, 2007 18:15 -0400, J. Bruce Fields wrote: > How will nfsd tell whether it can really on a given filesystem's > i_version, or whether it should fall back on ctime? Good question. > > As to performance concerns that raise before the inode version counter > > (at least for ext4) is done inside ext4_mark_inode_dirty), so there is > > no extra IO work to store this counter to disk. > > So what's the motivation for the "noversion" mount option? Lustre needs to be able to control the version number directly (version number needs to be ordered between all inodes, is set by Lustre to be a transaction number). Instead of trying to incorporate this unused code into ext4 we just turn off the ext4 version code and let Lustre control this directly. It may even be that NFSv4 will need to control the version numbers itself... Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.21 3/3] x86_64 EFI64 support Try #2
On Mon, 02 Jul 2007 10:06:17 -0700
Chandramouli Narayanan <[EMAIL PROTECTED]> wrote:
> EFI x86_64 support Patch 3 of 3 (try #2)
>
> - Fixed redundant check in efifb_init().
>
> This patch depends on the EFI x86_64 patches 1/3 and 2/3.
>
> This patch adds Graphics Output Protocol support to the kernel.
> x86_64 systems with UEFI2.0 firmware conform to UEFI 2.0 specification.
> UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and
> only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader
> needs to query the UEFI firmware with appropriate Output Protocol and
> pass the video information to the kernel. As a result of GOP
> protocol, an EFI framebuffer driver is needed for displaying console messages.
> Patch 3 of 3 adds a EFI framebuffer driver. The EFI frame buffer driver in
> this
> patch is based on the Intel Mac framebuffer driver.
>
> The x86_64 ELILO bootloader takes care of passing the video information
> as appropriate for EFI firmware.
>
That's more like a changelog.
Please cc [EMAIL PROTECTED] and "Antonino A. Daplas"
<[EMAIL PROTECTED]> on framebuffer driver patches.
>
> +config FB_EFI
> + bool "EFI-based Framebuffer Support"
> + depends on (FB = y) && X86 && EFI
So this is selectable on i386 as well. Has it been tested there?
> + select FB_CFB_FILLRECT
> + select FB_CFB_COPYAREA
> + select FB_CFB_IMAGEBLIT
> + help
> + This is the EFI frame buffer device driver. If the firmware on
> + your platform is UEFI2.0, select Y to add support for
> + Graphics Output Protocol for early console messages to appear.
> +
> config FB_IMAC
> bool "Intel-based Macintosh Framebuffer Support"
> depends on (FB = y) && X86 && EFI
>
> ...
>
> --- linux-2.6.21-orig/drivers/video/efifb.c 1969-12-31 16:00:00.0
> -0800
> +++ linux-2.6.21-uefi-finaltest4/drivers/video/efifb.c2007-06-12
> 16:16:12.0 -0700
> @@ -0,0 +1,249 @@
> +/*
> + * framebuffer driver for Intel Based Mac's
> + *
> + * (c) 2006 Edgar Hucek <[EMAIL PROTECTED]>
> + * Original efi driver written by Gerd Knorr <[EMAIL PROTECTED]>
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
checkpatch.pl will save me work.
> +#ifndef __i386__
> + //screen_info.imacpm_seg = 0;
> +#endif
hmm.
> +
> + if (!request_mem_region(efifb_fix.smem_start, size_total, "efifb")) {
> + printk(KERN_WARNING
> +"efifb: cannot reserve video memory at 0x%lx\n",
> + efifb_fix.smem_start);
KERN_ERR?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.21 2/3] x86_64 EFI64 support Try #2
On Mon, 02 Jul 2007 10:06:16 -0700 Chandramouli Narayanan <[EMAIL PROTECTED]> wrote: > EFI x86_64 support Patch 2 of 3 (try #2) > > - E820 conversion integration implemented > - A way to override machine_emergency_restart is implemented so that > EFI support can provide its own implementation. > - The variable efi_enabled is still retained as it is used across > archictures with CONFIG_EFI option. > Does the above text completely describe this patch? > > diff -uprN -X linux-2.6.21-orig/Documentation/dontdiff > linux-2.6.21-orig/arch/x86_64/kernel/aperture.c > linux-2.6.21-uefi-finaltest4/arch/x86_64/kernel/aperture.c > --- linux-2.6.21-orig/arch/x86_64/kernel/aperture.c 2007-04-25 > 20:08:32.0 -0700 > +++ linux-2.6.21-uefi-finaltest4/arch/x86_64/kernel/aperture.c > 2007-06-25 13:59:54.0 -0700 Lots of little glitches there which checkpatch.pl will point out. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.21 1/3] x86_64 EFI64 support Try #2
On Mon, 02 Jul 2007 10:06:15 -0700 Chandramouli Narayanan <[EMAIL PROTECTED]> wrote: > You just sent three patches, all with the same name. Please take care to choose different and good Subject:s for each patch. http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt covers this a bit. > EFI x86_64 support Patch 1 of 3 (try #2) > > - Being experimental, dropped default option for CONFIG_EFI. > > - Implemented EFI to E820 memory map conversion. This is based on > bootloader support. The ELILO bootloader x86_64 support has been > updated to pass E820 map to kernel. This simplified kernel efi code. > Also the duplicate code for setting up page table for > EFI run time is gotten rid of with simpler patch. > > -- > NOTE: The ELILO patch to perform EFI to E820 map conversion is being > submitted to sourceforge project maintainer. > -- > > - UEFI wrapper code in earlier patch is now replaced with code adapted from > NDIS wrapper sourceforge project. > > - Parameters in EFI calls are cast to (u64) to rid build warnings. > > - Code that is supposed to be __init only in arch/x86_64/kernel/efi.c > is prefixed as such. > > - Documentation/x86_64/uefi.txt adds instructions on how to set up EFI64 > system. > > - Documentation/i386/zero-page.txt notes differences in the boot parameters > for x86_64. The efi init code uses these parameters passed by the > bootloader. > > - Added missing KERN_ prefixes in EFI code. probe_kernel_address() used for > checking firmware vendor in efi init code. > > - The dependency on X86_64 in the configuration of EFI_RTC is dropped > since we have hardware realtime clock support > > Issues _not_ addressed (per feedback from Eric Biederman) > > - Virtual mode support is still retained in this patch. On looking at the > configuration options, the EFI variable support is required at runtime. > For instance, the firmware driver configuration support with EFI variable > via sysfs would require this. I'm not sure if virtual mode support > can be killed altogether. More investigation needed here. > > - The variable efi_enabled is used throughout across architecutres if > CONFIG_EFI option is enabled. The i386 code also uses this variable. > This is something that can be revisited with code consolidation across > architectures. > > Signed-off-by: Chandramouli Narayanan <[EMAIL PROTECTED]> All the above text tells us the differences between. v2 and v3. It all will be of minimal interest for the final got commit and hence it will be removed (by me, typically). That will leave us with no cvhangelog for this patch. Please provide a changelog with this patch. The above-linked-to document has some guidelines. Please feed these patches through the latest version of scripts/checkpatch.pl and consider addressing the resulting warnings. Many are generated. > + * Copyright (C) 2006 Giridhar Pemmasani > + * Copyright (C) 2007-2010 Intel Corp > + * Contributed by Chandramouli Narayanan<[EMAIL PROTECTED]> > + * Adapted NDIS wrapper macros from http://ndiswrapper.sourceforge.net > + * for EFI x86_64 linux support > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + */ > +extern efi_status_t LIN2WIN0(void *fp); > +extern efi_status_t LIN2WIN1(void *fp, u64 arg1); > +extern efi_status_t LIN2WIN2(void *fp, u64 arg1, u64 arg2); > +extern efi_status_t LIN2WIN3(void *fp, u64 arg1, u64 arg2, u64 arg3); > +extern efi_status_t LIN2WIN4(void *fp, u64 arg1, u64 arg2, u64 arg3, u64 > arg4); > +extern efi_status_t LIN2WIN5( > + void *fp, u64 arg1, u64 arg2, u64 arg3, u64 arg4, u64 arg5); > +extern efi_status_t LIN2WIN6( > + void *fp, u64 arg1, u64 arg2, u64 arg3, u64 arg4, u64 arg5, u64 arg6); Why are these all-upper-case? That convention is conventionally used for macros. > --- linux-2.6.21-orig/arch/x86_64/kernel/efi.c1969-12-31 > 16:00:00.0 -0800 > +++ linux-2.6.21-uefi-finaltest4/arch/x86_64/kernel/efi.c 2007-06-26 > 14:39:27.0 -0700 > @@ -0,0 +1,531 @@ > +/* > + * Extensible Firmware Interface > + * > + * Based on Extensible Firmware Interface Specification version 1.0 > + * > + * Copyright (C) 1999 VA Linux Systems > + * Copyright (C) 1999 Walt Drummond <[EMAIL PROTECTED]> > + * Copyright (C) 1999-2002 Hewlett-Packard Co. > + * David
[RFC PATCH 0/2] raid5: 65% sequential-write performance improvement, stripe-queue take2
The first take of the stripe-queue implementation[1] had a performance limiting bug in __wait_for_inactive_queue. Fixing that issue drastically changed the performance characteristics. The following data from tiobench shows the relative performance difference of the stripe-queue patchset. Unit information File size = megabytes Blk Size = bytes Num Thr = number of threads Avg Rate = relative throughput CPU% = relative percentage of CPU used during the test CPU Eff = Rate divided by CPU% - relative throughput per cpu load Configuration = Platform: 1200Mhz iop348 with 4-disk sata_vsc array mdadm --create /dev/md0 /dev/sd[abcd] -n 4 -l 5 mkfs.ext2 /dev/md0 mount /dev/md0 /mnt/raid tiobench --size 2048 --numruns 5 --block 4096 --block 131072 --dir /mnt/raid Sequential Reads FileBlk Num Avg Maximum CPU Identifier SizeSizeThr Rate(CPU%) Eff --- -- - --- -- -- - 2.6.22-rc7-iop1 204840961 0% 4% -3% 2.6.22-rc7-iop1 204840962 -38%-33%-8% 2.6.22-rc7-iop1 204840964 -35%-30%-8% 2.6.22-rc7-iop1 204840968 -14%-11%-3% 2.6.22-rc7-iop1 204813107 1 2% 1% 2% 2.6.22-rc7-iop1 204813107 2 -11%-10%-2% 2.6.22-rc7-iop1 204813107 4 -7% -6% -1% 2.6.22-rc7-iop1 204813107 8 -9% -6% -4% Random Reads FileBlk Num Avg Maximum CPU Identifier SizeSizeThr Rate(CPU%) Eff --- -- - --- -- -- - 2.6.22-rc7-iop1 204840961 -9% 15% -21% 2.6.22-rc7-iop1 204840962 -1% -30%42% 2.6.22-rc7-iop1 204840964 -14%-22%10% 2.6.22-rc7-iop1 204840968 -21%-28%9% 2.6.22-rc7-iop1 204813107 1 -8% -4% -4% 2.6.22-rc7-iop1 204813107 2 -13%-13%0% 2.6.22-rc7-iop1 204813107 4 -15%-15%0% 2.6.22-rc7-iop1 204813107 8 -13%-13%0% Sequential Writes FileBlk Num Avg Maximum CPU Identifier SizeSizeThr Rate(CPU%) Eff --- -- - --- -- -- - 2.6.22-rc7-iop1 204840961 25% 11% 12% 2.6.22-rc7-iop1 204840962 41% 42% -1% 2.6.22-rc7-iop1 204840964 40% 18% 19% 2.6.22-rc7-iop1 204840968 15% -5% 21% 2.6.22-rc7-iop1 204813107 1 65% 57% 4% 2.6.22-rc7-iop1 204813107 2 46% 36% 8% 2.6.22-rc7-iop1 204813107 4 24% -7% 34% 2.6.22-rc7-iop1 204813107 8 28% -15%51% Random Writes FileBlk Num Avg Maximum CPU Identifier SizeSizeThr Rate(CPU%) Eff --- -- - --- -- -- - 2.6.22-rc7-iop1 204840961 2% -8% 11% 2.6.22-rc7-iop1 204840962 -1% -19%21% 2.6.22-rc7-iop1 204840964 2% 2% 0% 2.6.22-rc7-iop1 204840968 -1% -28%37% 2.6.22-rc7-iop1 204813107 1 2% -3% 5% 2.6.22-rc7-iop1 204813107 2 3% -4% 7% 2.6.22-rc7-iop1 204813107 4 4% -3% 8% 2.6.22-rc7-iop1 204813107 8 5% -9% 15% The write performance numbers are better than I expected and would seem to address the concerns raised in the thread "Odd (slow) RAID performance"[2]. The read performance drop was not expected. However, the numbers suggest some additional changes to be made to the queuing model. Where read performance is dropping there appears to be an equal drop in CPU utilization, which seems to suggest that pure read requests be handled immediately without a trip to the the stripe-queue workqueue. Although it is not shown in the above data, another positive aspect is that increasing the cache size past a certain point causes the write performance gains to erode. In other words negative returns in contrast to diminishing returns. The stripe-queue can only carry out optimizations while the cache is busy. When the cache is large requests can be handled without waiting, and performance approaches the original 1:1 (queue-to-stripe-head) model. CPU speed dictates the maximum effective cache size. Once the CPU can no longer keep the stripe-queue saturated performance falls off from the peak. This is a positive change because it shows that the new queuing model can produce higher performance with less resources, but it does require more care when changing 'stripe_cache_size.' The above numbers were taken with the default cache size of 256. Changes since take1: * separate write and overwrite in the io_weight fields, i.e. an overwrite no longer implies a write * rename
New systems: eu.kernel.org
Hi all, Thanks to HP, ISC and Umeå Universitet, kernel.org now has official servers in Europe. Specifically, we have www1.eu.kernel.org hosted at ISC Amsterdam, and www2.eu.kernel.org at UMU (Umeå, Sweden.) They are collectively accessible as www.eu.kernel.org. This is a full service of kernel.org and not a mirror. In the future, we hope to add some sort of smart DNS to automatically redirect traffic, as well as additional services in Europe. -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: [tifm] Infinite loop
Renato S. Yamane escreveu: When I insert a SDCard in my laptop M45-S355 my system crash because tifm start a infinite loop. See below more detail about SD/MMC Card and infinite loop. ... I forgot: $uname -vr 2.6.21.1 #1 PREEMPT Sun May 20 22:28:53 BRT 2007 Best regards, Renato - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Oliver Neukum writes: > USB devices certainly have suspend methods. Indeed, and the USB framework has code to know when the host controller is suspended and avoid trying to send out urbs in that case. Or at least it did last time I looked at it in any detail; it's been "just working" - including suspending and resuming, without the freezer - for quite a while now. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 06/10] Immediate Value - i386 Optimization
Chuck Ebbert wrote: On 07/03/2007 04:18 PM, H. Peter Anvin wrote: One could, though, use an indirect jump to achieve, if not as good, at least most of the effect: movl$, jmp * Yeah, but there's this GCC bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22448 You can't even dereference labels in an ASM statement. I was told in absolute terms that any use of & other than to pass it to goto was not supported, and would not be supported. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305 Seems that passing to an asm() falls into the same class of problem I had. I think the underlying problem is that if the code containing the label is in an inlined function or unrolled loop, the reference can't be resolved properly anyway. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/2] 2.6.22-rc7: known regressions
On Tue, Jul 03, 2007 at 07:50:26PM +0200, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Tuesday 03 July 2007, Michal Piotrowski wrote: > > > IDE > > > > Subject: 2.6.22-rcX: hda: lost interrupt > > References : http://lkml.org/lkml/2007/6/29/121 > > Submitter : David Chinner <[EMAIL PROTECTED]> > > Status : unknown > > David, any news on this one? > > Have you tried libata as suggested by Jeff? Not yet - I've been flat out and haven't got back to it yet. I'll try to get to it today. 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: [PATCH] Remove process freezer from suspend to RAM pathway
On Wed, 2007-07-04 at 00:04 +0200, Oliver Neukum wrote: > Am Dienstag, 3. Juli 2007 schrieb Benjamin Herrenschmidt: > > On Tue, 2007-07-03 at 23:48 +0200, Oliver Neukum wrote: > > > Am Dienstag, 3. Juli 2007 schrieb Benjamin Herrenschmidt: > > > > On Tue, 2007-07-03 at 21:32 +0200, Oliver Neukum wrote: > > > > > > I'm not sure why this can't be made atomic, but assuming, that it > > > > > > can't, fuse should still not need to be implicated. If it is, > > > > > that's > > > > > > an indication about something wrong in the suspend procedure. > > > > > > > > > > Nope, something's wrong in fuse. You must be able to deal with sync > > > > > until every task is frozen. > > > > > > > > Pipe dream > > > > > > Then tell me how you want to avoid that condition. > > > > Don't freeze :-) > > Then you will have to deal with all syscalls unfrozen tasks can make. Yup, and the majority of them is totally harmless. Looks like people around here have a problem with the idea of writing robust drivers ... 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] Improve behaviour of Dreamcast aica ALSA driver in poor resource conditions
On 03/07/07, Adrian McMenamin <[EMAIL PROTECTED]> wrote:
This patch stops the driver from crashing in certain situations (eg if
the network fails when NFS mounted), please apply.
Actually, looked at this again and while the previous patch stopped
the driver from crashing it still locked the sound subsystem. This was
because INIT_WORK was being called on the same work_struct when the
device recovered from the network failure. The patch below ensures
that this does not happen and that instead, PREPARE_WORK is called.
Submitted by: Adrian McMenamin <[EMAIL PROTECTED]>
Signed-off by: Adrian McMenamin <[EMAIL PROTECTED]>
--- alsa-kernel/sh/aica.c 2007-06-23 15:25:55.0 +0100
+++ linux-2.6.21/sound/sh/aica.c2007-07-04 00:01:23.0 +0100
@@ -68,6 +68,7 @@
static struct spu_work_holder {
struct work_struct spu_dma_work;
void *sspointer;
+ int already_started;
} spu_working;
static struct workqueue_struct *aica_queue;
@@ -319,7 +320,13 @@
dreamcastcard = substream->pcm->private_data;
/* Use queue to do the heavy lifting */
spu_working.sspointer = substream;
- INIT_WORK(&(spu_working.spu_dma_work), run_spu_dma);
+ if (spu_working.already_started == 1) {
+ PREPARE_WORK(&(spu_working.spu_dma_work), run_spu_dma);
+ }
+ else {
+ INIT_WORK(&(spu_working.spu_dma_work), run_spu_dma);
+ spu_working.already_started = 1;
+ }
queue_work(aica_queue, &(spu_working.spu_dma_work));
/* Timer may already be running */
if (unlikely(dreamcastcard->timer.data)) {
@@ -366,7 +373,9 @@
*substream)
{
struct snd_card_aica *dreamcastcard = substream->pcm->private_data;
+ flush_workqueue(aica_queue);
del_timer(>timer);
+ aica_chn_halt();
kfree(dreamcastcard->channel);
spu_disable();
return 0;
@@ -402,17 +411,10 @@
static int snd_aicapcm_pcm_trigger(struct snd_pcm_substream
*substream, int cmd)
{
- struct snd_card_aica *dreamcastcard;
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
spu_begin_dma(substream);
break;
- case SNDRV_PCM_TRIGGER_STOP:
- dreamcastcard = substream->pcm->private_data;
- if (dreamcastcard->timer.data)
- del_timer(>timer);
- aica_chn_halt();
- break;
default:
return -EINVAL;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/5] uvesafb: a general description
Gabriel C wrote: Michal Januszewski wrote: uvesafb is a generic driver for VBE2+ compliant video cards; an enhanced version of vesafb and a direct successor of vesafb-tng [1]. [ .. ] I've just tested uvesafb on my workstation ( which has a really old GeForce2 MX 400 Nvidia card ) and it didn't worked here. If I remember right vesafb-ntg worked here and vesafb works for sure :) Here the error from dmesg : [ 37.397298] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3) [ 37.397358] uvesafb: vbe_init() failed with -22 [ 37.397411] uvesafb: probe of uvesafb.0 failed with error -22 Got it to work today with an 2.6.22-rc6-git4 kernel build-in and as module and I like it really . good work. For some reason 2.6.22-rc6 didn't worked here it may have some bug with my harware or something ( anyway 2.6.22-rc6-git4 is just fine ) Dmesg from working kernel attached. Regards, Gabriel C [0.00] Linux version 2.6.22-rc6-git4 ([EMAIL PROTECTED]) (gcc version 4.2.1 20070627 (prerelease)) #1 SMP PREEMPT Wed Jul 4 00:37:17 CEST 2007 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 000a (usable) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - 27f77000 (usable) [0.00] BIOS-e820: 27f77000 - 27f79000 (ACPI NVS) [0.00] BIOS-e820: 27f79000 - 2800 (reserved) [0.00] BIOS-e820: fec0 - fec1 (reserved) [0.00] BIOS-e820: fee0 - fee1 (reserved) [0.00] BIOS-e820: ffb0 - 0001 (reserved) [0.00] 0MB HIGHMEM available. [0.00] 639MB LOWMEM available. [0.00] found SMP MP-table at 000fe710 [0.00] Entering add_active_range(0, 0, 163703) 0 entries of 256 used [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] Normal 4096 -> 163703 [0.00] HighMem163703 -> 163703 [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 -> 163703 [0.00] On node 0 totalpages: 163703 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 4064 pages, LIFO batch:0 [0.00] Normal zone: 1246 pages used for memmap [0.00] Normal zone: 158361 pages, LIFO batch:31 [0.00] HighMem zone: 0 pages used for memmap [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000FD550, 0014 (r0 DELL ) [0.00] ACPI: RSDT 000FD564, 0034 (r1 DELLWS 530 8 ASL 61) [0.00] ACPI: FACP 000FD598, 0074 (r1 DELLWS 530 8 ASL 61) [0.00] ACPI: DSDT FFFE3C22, 2696 (r1 DELLdt_ex 1000 MSFT 10D) [0.00] ACPI: FACS 27F77000, 0040 [0.00] ACPI: SSDT FFFE635F, 0096 (r1 DELLst_ex 1000 MSFT 10D) [0.00] ACPI: APIC 000FD60C, 006C (r1 DELLWS 530 8 ASL 61) [0.00] ACPI: BOOT 000FD678, 0028 (r1 DELLWS 530 8 ASL 61) [0.00] ACPI: PM-Timer IO Port: 0x808 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [0.00] Processor #0 15:2 APIC version 20 [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) [0.00] Processor #2 15:2 APIC version 20 [0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled) [0.00] Processor #1 15:2 APIC version 20 [0.00] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) [0.00] Processor #3 15:2 APIC version 20 [0.00] ACPI: IOAPIC (id[0x04] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 4, version 32, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] ACPI: IRQ0 used by override. [0.00] ACPI: IRQ2 used by override. [0.00] ACPI: IRQ9 used by override. [0.00] Enabling APIC mode: Flat. Using 1 I/O APICs [0.00] Using ACPI (MADT) for SMP configuration information [0.00] Allocating PCI resources starting at 3000 (gap: 2800:d6c0) [0.00] Built 1 zonelists. Total pages: 162425 [0.00] Kernel command line: root=/dev/sda1 ro clocksource=acpi_pm video=uvesafb:1280x1024-32,mtrr:3,ywrap nosplashy quiet [0.00] mapped APIC to d000 (fee0) [0.00] mapped IOAPIC to c000 (fec0) [0.00] Enabling fast FPU save and restore... done. [0.00] Enabling unmasked SIMD FPU exception support... done. [0.00] Initializing CPU#0 [0.00] PID hash table entries: 4096 (order: 12, 16384 bytes) [0.00] Detected 1994.094 MHz processor. [ 30.941323]
2.6.22-rc6-mm1 -- BUG - EIP: [] drm_vma_info+0x2a5/0x310 [drm] SS:ESP 0068:c80cde9c
I ran the command: find /proc | xargs grep a BUG: unable to handle kernel NULL pointer dereference at virtual address printing eip: f8ac1350 *pde = Oops: [#1] SMP Modules linked in: arc4 ecb blkcipher cryptomgr crypto_algapi ieee80211_crypt_wep bluetooth i915 drm acpi_cpufreq cpufreq_conservative cpufreq_powersave cpufreq_performance ac battery video output button processor container firewire_sbp2 parport_pc lp parport pcmcia snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss yenta_socket rsrc_nonstatic sdhci snd_seq_midi_event ipw2200 tifm_7xx1 mmc_core pcmcia_core ieee80211 ieee80211_crypt tifm_core snd_seq snd_timer snd_seq_device evdev shpchp snd iTCO_wdt iTCO_vendor_support pci_hotplug soundcore snd_page_alloc firewire_ohci firewire_core crc_itu_t 8139too ehci_hcd uhci_hcd usbcore fan CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010283 (2.6.22-rc6-mm1 #5) EIP is at drm_vma_info+0x2a5/0x310 [drm] eax: ebx: c80cdf38 ecx: edx: esi: 8000 edi: c467e000 ebp: c80cdf0c esp: c80cde9c ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process grep (pid: 5172, ti=c80cd000 task=c7e9ed60 task.ti=c80cd000) Stack: c467e000 f8ac595a f800 3800 c0526e9c c80cdefc c0165700 0044 0001 c7e9ed60 c467e000 c63b68e0 c1195548 0035 c7e9f328 0001 000800d0 Call Trace: [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === INFO: lockdep is turned off. Code: 24 04 c9 59 ac f8 8b 45 c8 01 d8 89 04 24 e8 3c 66 74 c7 01 c3 89 5d d8 81 fb b0 0f 00 00 77 4a 8b 45 d4 8b 00 89 45 d4 8b 55 d4 <8b> 02 0f 18 00 90 8b 45 10 05 98 01 00 00 39 c2 0f 85 e7 fd ff EIP: [] drm_vma_info+0x2a5/0x310 [drm] SS:ESP 0068:c80cde9c - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tifm] Infinite loop
When I insert a SDCard in my laptop M45-S355 my system crash because tifm start a infinite loop. See below more detail about SD/MMC Card and infinite loop. 05:06.0 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller Subsystem: Toshiba America Info Systems Unknown device ff10 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 168, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at b8001000 (32-bit, non-prefetchable) [size=4K] Bus: primary=05, secondary=06, subordinate=09, sec-latency=176 Memory window 0: 8800-8bfff000 (prefetchable) Memory window 1: bc00-b000 I/O window 0: 8000-80ff I/O window 1: 8400-84ff BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 05:06.2 FireWire (IEEE 1394): Texas Instruments OHCI Compliant IEEE 1394 Host Controller (prog-if 10 [OHCI]) Subsystem: Toshiba America Info Systems Unknown device ff10 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 128 (500ns min, 1000ns max), Cache Line Size: 16 bytes Interrupt: pin C routed to IRQ 11 Region 0: Memory at b800 (32-bit, non-prefetchable) [size=2K] Region 1: Memory at b8004000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME+ 05:06.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller Subsystem: Toshiba America Info Systems Unknown device ff10 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 128 (1750ns min, 1000ns max), Cache Line Size: 16 bytes Interrupt: pin D routed to IRQ 5 Region 0: Memory at b8008000 (32-bit, non-prefetchable) [size=8K] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 05:06.4 Generic system peripheral [0805]: Texas Instruments PCI6411, PCI6421, PCI6611, PCI6621, PCI7411, PCI7421, PCI7611, PCI7621 Secure Digital (SD) Controller Subsystem: Toshiba America Info Systems Unknown device ff10 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 128 (1750ns min, 1000ns max), Cache Line Size: 16 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at b800a000 (32-bit, non-prefetchable) [size=256] Region 1: Memory at b800a100 (32-bit, non-prefetchable) [size=256] Region 2: Memory at b800a200 (32-bit, non-prefetchable) [size=256] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- == [] __sched_text_start+0x62/0x558 [] process_timeout+0x0/0x5 [] msleep+0xd/0x12 [] tifm_7xx1_toggle_sock_power+0x91/0xb2 [tifm_7xx1] [] tifm_7xx1_switch_media+0x6c/0x3a7 [tifm_7xx1] [] autoremove_wake_function+0x0/0x35 [] tifm_7xx1_switch_media+0x0/0x3a7 [tifm_7xx1] [] kthread+0xa0/0xc8 [] kthread+0x0/0xc8 [] kernel_thread_helper+0x7/0x10 === [] __sched_text_start+0x62/0x558 [] printk+0x1b/0x1f [] schedule_timeout+0x7a/0x97 [] process_timeout+0x0/0x5 [] msleep+0xd/0x12 [] tifm_7xx1_toggle_sock_power+0x79/0xb2 [tifm_7xx1] [] tifm_7xx1_switch_media+0x1b4/0x3a7 [tifm_7xx1] [] autoremove_wake_function+0x0/0x35 [] tifm_7xx1_switch_media+0x0/0x3a7 [tifm_7xx1] [] kthread+0xa0/0xc8 [] kthread+0x0/0xc8 [] kernel_thread_helper+0x7/0x10 === [] __sched_text_start+0x62/0x558 [] schedule_timeout+0x7a/0x97 [] process_timeout+0x0/0x5 [] msleep+0xd/0x12 [] tifm_7xx1_toggle_sock_power+0x91/0xb2 [tifm_7xx1] [] tifm_7xx1_switch_media+0x1b4/0x3a7 [tifm_7xx1] [] autoremove_wake_function+0x0/0x35 [] tifm_7xx1_switch_media+0x0/0x3a7 [tifm_7xx1] [] kthread+0xa0/0xc8 [] kthread+0x0/0xc8 [] kernel_thread_helper+0x7/0x10 === [] __sched_text_start+0x62/0x558 [] schedule_timeout+0x7a/0x97 [] process_timeout+0x0/0x5 [] msleep+0xd/0x12 [] tifm_7xx1_toggle_sock_power+0x91/0xb2 [tifm_7xx1] [] tifm_7xx1_switch_media+0x1b4/0x3a7 [tifm_7xx1] []
Re: [PATCH] Re: Sparc32: random invalid instruction occourances on sparc32 (sun4c)
Hi David,
I will try out your patch shortly.
On Tue, 3 Jul 2007, David Woodhouse wrote:
On Tue, 2007-07-03 at 22:25 +0100, Mark Fortescue wrote:
The problem is that sun4c Sparc32 can't handle un-aligned variables so
having a 64bit readzone word that is not aligned on a 64bit boundary is a
problem.
Surely, it can. You just have to tell the compiler that it's not
properly aligned, and it'll emit code to cope. Hence the suggestion that
you use 'unsigned long long __attribute__((aligned(BYTES_PER_WORD))'.
But it's probably better just to make sure it remains aligned; you're
right.
In addition, having looked at the size calculations, it looks to me as if
not all of them got updated to handle 64bit redzone words.
Really? Other than the alignment of the second redzone, what's wrong?
Remember that the 'user word' is still not necessarily 64-bit. And in
fact I suspect that's what is causing the problem -- your object _size_
will be aligned to 8 bytes, including the user word, and then we look
for the second redzone word 12 bytes before the end of the object.
Yes, the user word is a 32bit word and this is part of the issue.
I may be wrong about the size calculations but if you take a look at lines
2174 to 2188 and 2207 to 2203, reading the comments suggest to me that
these need to be changed to match the changes to the RedZone words.
Failing to change these means that 32bit aligned access of the 64bit
RedZone words is still posible and this will kill sun4c.
For the 64bit RedZone word to be 64bit aligned (required by sun4c), the
User word must be 64bit aligned. I don't see where in your patch, this is
enforced.
Does this fix it?
diff --git a/mm/slab.c b/mm/slab.c
index 6d65cf4..3b15671 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -547,7 +547,7 @@ static unsigned long long *dbg_redzone2(struct kmem_cache
*cachep, void *objp)
if (cachep->flags & SLAB_STORE_USER)
return (unsigned long long *)(objp + cachep->buffer_size -
sizeof(unsigned long long) -
- BYTES_PER_WORD);
+ max(BYTES_PER_WORD,
__alignof__(unsigned long long)));
return (unsigned long long *) (objp + cachep->buffer_size -
sizeof(unsigned long long));
}
@@ -2262,9 +2262,14 @@ kmem_cache_create (const char *name, size_t size, size_t
align,
}
if (flags & SLAB_STORE_USER) {
/* user store requires one word storage behind the end of
-* the real object.
+* the real object. But if the second red zone must be
+* aligned 'better' than that, allow for it.
*/
- size += BYTES_PER_WORD;
+ if (flags & SLAB_RED_ZONE
+ && BYTES_PER_WORD < __alignof__(unsigned long long))
+ size += __alignof__(unsigned long long);
+ else
+ size += BYTES_PER_WORD;
}
#if FORCED_DEBUG && defined(CONFIG_DEBUG_PAGEALLOC)
if (size >= malloc_sizes[INDEX_L3 + 1].cs_size
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway
On Tue, Jul 03, 2007 at 06:21:42PM -0400, Alan Stern wrote: > On Tue, 3 Jul 2007, Matthew Garrett wrote: > > We're used to the idea of applications blocking when a resource they're > > using goes away - NFS has done it forever. > > You persist in evading my point. I'm not worried about applications; > I'm worried about drivers. > > Let me put it explicitly: You're writing a driver. You're working on > the read, write, or probe method. You add code to check if a system > sleep is underway. Suppose the answer is Yes -- what does your driver > do next? Leave the process blocked and defer any i/o until after resume. Why does it need to be any more complicated than that? -- 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: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway
On Tuesday, 3 July 2007 23:36, Matthew Garrett wrote: > On Tue, Jul 03, 2007 at 11:37:51PM +0200, Rafael J. Wysocki wrote: > > On Tuesday, 3 July 2007 23:20, Matthew Garrett wrote: > > > We're used to the idea of applications blocking when a resource they're > > > using goes away - NFS has done it forever. > > > > Now, please tell me how many driver writers even thought that something > > might try to access their devices after .suspend() had been executed (or > > even whilie it was being executed)? > > Every single driver that fails under those conditions is already broken, > and has been forever. It's likely that they're broken under run-time > suspend, too. Well, I won't argue with that, but do you actually know how many drivers are broken this way? Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Remove process freezer from suspend to RAM pathway
On Tuesday, 3 July 2007 23:35, Benjamin Herrenschmidt wrote: > On Tue, 2007-07-03 at 23:32 +0200, Rafael J. Wysocki wrote: > > > > Still, do you really think that we're ready to drop it _right_ _now_ > > (I'm > > referring to suspend only) and if so than on what basis (except that > > you > > don't like it, which falls short of being a techical argument)? > > Works fine for me without it ;-) Yeah, that makes sense. ;-) Still, someone needs to take care of bug reports from unlucky people and I wouldn't like to increase the number of these by doing such a high-level change without any preparations ... Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] #if 0 mm/backing-dev.c:congestion_wait_interruptible()
On Tue, 2007-07-03 at 14:48 -0700, Andrew Morton wrote: > On Sun, 1 Jul 2007 22:20:51 +0200 > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > congestion_wait_interruptible() is no longer used. > > We might as well just delete it? I agree. We're better off deleting it, but either would be fine by me. Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61
Hi, Zoltan Boszormenyi írta: Hi, I am testing your current code with akpm's beautifying patches for about an hour now. I have seen no problems with it so far. Still using the patch on 2.6.22-rc6 and no problems so far. It's really stable. I am looking forward to the next version and the inclusion into mainstream kernels. Thanks! Best regards, Zoltán Böszörményi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/44] Pass struct vfsmount to the inode_create LSM hook
On Saturday 30 June 2007 11:29, Christoph Hellwig wrote: > On Tue, Jun 26, 2007 at 04:07:57PM -0700, [EMAIL PROTECTED] wrote: > > This is needed for computing pathnames in the AppArmor LSM. > > Please see the various per-mountpoint r/o thread that NACKed all the > vfsmount additions and have the rationale for it. The per-mountpoint flags can be checked at the vfs level instead of checking down in the filesystems. That's all pretty nice; it avoids a number of problems. (I think the latest patches of Dave Hansen are archived at http://lwn.net/Articles/239630/.) The lSM hooks are a rather different story: we cannot move LSM functionality into the vfs without breaking the LSM abstraction. LSMs already are not agnostic of vfsmount anymore right now. They are free to use the additional vfsmounts, or just ignore them. So what are the specific issues you have with this? Thanks, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dio: remove bogus refcounting BUG_ON
Linus, Andrew, please apply the bug fix patch at the end of this reply
for .22.
> >>One of our perf. team ran into this while doing some runs.
> >>I didn't see anything obvious - it looks like we converted
> >>async IO to synchronous one. I didn't spend much time digging
> >>around.
OK, I think this BUG_ON() is just broken. I wasn't able to find any
obvious bugs from reading the code which would cause the BUG_ON() to
fire. If it's reproducible I'd love to hear what the recipe is.
I did notice that this BUG_ON() is evaluating dio after having dropped
it's ref :/. So it's not completely absurd to fear that it's a race
with the dio's memory being reused, but that'd be a pretty tight race.
Let's remove this stupid BUG_ON and see if that test box still has
trouble. It might just hit the valid BUG_ON a few lines down, but this
unsafe BUG_ON needs to go.
---
dio: remove bogus refcounting BUG_ON
Badari Pulavarty reported a case of this BUG_ON is triggering during
testing. It's completely bogus and should be removed.
It's trying to notice if we left references to the dio hanging around in
the sync case. They should have been dropped as IO completed while this
path was in dio_await_completion(). This condition will also be
checked, via some twisty logic, by the BUG_ON(ret != -EIOCBQUEUED) a few
lines lower. So to start this BUG_ON() is redundant.
More fatally, it's dereferencing dio-> after having dropped its
reference. It's only safe to dereference the dio after releasing the
lock if the final reference was just dropped. Another CPU might free
the dio in bio completion and reuse the memory after this path drops the
dio lock but before the BUG_ON() is evaluated.
This patch passed aio+dio regression unit tests and aio-stress on ext3.
Signed-off-by: Zach Brown <[EMAIL PROTECTED]>
Cc: Badari Pulavarty <[EMAIL PROTECTED]>
diff -r 509ce354ae1b fs/direct-io.c
--- a/fs/direct-io.cSun Jul 01 22:00:49 2007 +
+++ b/fs/direct-io.cTue Jul 03 14:56:41 2007 -0700
@@ -1106,7 +1106,7 @@ direct_io_worker(int rw, struct kiocb *i
spin_lock_irqsave(>bio_lock, flags);
ret2 = --dio->refcount;
spin_unlock_irqrestore(>bio_lock, flags);
- BUG_ON(!dio->is_async && ret2 != 0);
+
if (ret2 == 0) {
ret = dio_complete(dio, offset, ret);
kfree(dio);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] pata_hpt3x3: Major reworking and testing
On Tuesday 03 July 2007, Sergei Shtylyov wrote: > Hello. > > Bartlomiej Zolnierkiewicz wrote: > > > http://www.linuxhq.com/kernel/v2.3/10/drivers/block/hpt343.c > > > Does anybody have DOS driver for HPT343? Google doesn't have it... > > I have the drivers for HPT34[35] -- tried dissassembling them some years > ago... /me wants Bart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Remove process freezer from suspend to RAM pathway
On Tuesday, 3 July 2007 23:35, Benjamin Herrenschmidt wrote:
>
> > I don't think that would matter.
> >
> > Still, I can remove the sync from the suspend code path only, leaving it in
> > the hibernation code path. The patch will be bigger, but well.
> >
> > Any objection to that?
>
> Makes sense to sync before suspend tho, to limit the amount of dirty
> non-written pages in case things go wrong.
OK, below is the updated patch.
Greetings,
Rafael
---
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
The syncing of filesystems from within the freezer in not needed for suspend to
RAM and leads to problems with FUSE. Change freeze_processes() so that it
doesn't execute sys_sync() and introduce the "syncing" version of it to be
called from the hibernation code paths.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
include/linux/freezer.h | 14 --
kernel/power/disk.c |2 +-
kernel/power/main.c |6 ++
kernel/power/process.c |8 +---
kernel/power/user.c |2 +-
5 files changed, 25 insertions(+), 7 deletions(-)
Index: linux-2.6.22-rc7/include/linux/freezer.h
===
--- linux-2.6.22-rc7.orig/include/linux/freezer.h 2007-07-04
00:21:26.0 +0200
+++ linux-2.6.22-rc7/include/linux/freezer.h2007-07-04 00:22:37.0
+0200
@@ -62,7 +62,7 @@ static inline int thaw_process(struct ta
}
extern void refrigerator(void);
-extern int freeze_processes(void);
+extern int __freeze_processes(int sync_filesystems);
extern void thaw_processes(void);
static inline int try_to_freeze(void)
@@ -134,7 +134,7 @@ static inline void clear_freeze_flag(str
static inline int thaw_process(struct task_struct *p) { return 1; }
static inline void refrigerator(void) {}
-static inline int freeze_processes(void) { BUG(); return 0; }
+static inline int __freeze_processes(int s) { BUG(); return 0; }
static inline void thaw_processes(void) {}
static inline int try_to_freeze(void) { return 0; }
@@ -145,4 +145,14 @@ static inline int freezer_should_skip(st
static inline void set_freezable(void) {}
#endif
+static inline int freeze_processes(void)
+{
+ return __freeze_processes(0);
+}
+
+static inline int freeze_processes_with_sync(void)
+{
+ return __freeze_processes(1);
+}
+
#endif /* FREEZER_H_INCLUDED */
Index: linux-2.6.22-rc7/kernel/power/disk.c
===
--- linux-2.6.22-rc7.orig/kernel/power/disk.c 2007-07-04 00:21:26.0
+0200
+++ linux-2.6.22-rc7/kernel/power/disk.c2007-07-04 00:21:44.0
+0200
@@ -281,7 +281,7 @@ static int prepare_processes(void)
int error = 0;
pm_prepare_console();
- if (freeze_processes()) {
+ if (freeze_processes_with_sync()) {
error = -EBUSY;
unprepare_processes();
}
Index: linux-2.6.22-rc7/kernel/power/main.c
===
--- linux-2.6.22-rc7.orig/kernel/power/main.c 2007-07-04 00:21:26.0
+0200
+++ linux-2.6.22-rc7/kernel/power/main.c2007-07-04 00:23:40.0
+0200
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include "power.h"
@@ -231,6 +232,11 @@ static int enter_state(suspend_state_t s
if (!valid_state(state))
return -ENODEV;
+
+ printk("Syncing filesystems ... ");
+ sys_sync();
+ printk("done.\n");
+
if (!mutex_trylock(_mutex))
return -EBUSY;
Index: linux-2.6.22-rc7/kernel/power/process.c
===
--- linux-2.6.22-rc7.orig/kernel/power/process.c2007-07-04
00:21:26.0 +0200
+++ linux-2.6.22-rc7/kernel/power/process.c 2007-07-04 00:21:44.0
+0200
@@ -179,9 +179,9 @@ static int try_to_freeze_tasks(int freez
}
/**
- * freeze_processes - tell processes to enter the refrigerator
+ * __freeze_processes - tell processes to enter the refrigerator
*/
-int freeze_processes(void)
+int __freeze_processes(int sync_filesystems)
{
int error;
@@ -190,7 +190,9 @@ int freeze_processes(void)
if (error)
return error;
- sys_sync();
+ if (sync_filesystems)
+ sys_sync();
+
error = try_to_freeze_tasks(FREEZER_KERNEL_THREADS);
if (error)
return error;
Index: linux-2.6.22-rc7/kernel/power/user.c
===
--- linux-2.6.22-rc7.orig/kernel/power/user.c 2007-07-04 00:21:26.0
+0200
+++ linux-2.6.22-rc7/kernel/power/user.c2007-07-04 00:21:44.0
+0200
@@ -153,7 +153,7 @@ static int snapshot_ioctl(struct inode *
mutex_lock(_mutex);
error = pm_notifier_call_chain(PM_HIBERNATION_PREPARE);
if (!error) {
- error =
Re: [PATCH] fix error handling in ext3_create_journal
On Mon, 2 Jul 2007 00:11:11 +0200
Borislav Petkov <[EMAIL PROTECTED]> wrote:
>
> ---
> From: Borislav Petkov <[EMAIL PROTECTED]>
>
> Fix error handling in ext3_create_journal according to kernel conventions.
>
> Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
> --
>
> Index: linux-2.6.22-rc6/fs/ext3/super.c
> ===
> --- linux-2.6.22-rc6/fs/ext3/super.c.orig 2007-07-01 21:12:51.0
> +0200
> +++ linux-2.6.22-rc6/fs/ext3/super.c 2007-07-01 21:14:32.0 +0200
> @@ -2075,6 +2075,7 @@
> unsigned int journal_inum)
> {
> journal_t *journal;
> + int err;
>
> if (sb->s_flags & MS_RDONLY) {
> printk(KERN_ERR "EXT3-fs: readonly filesystem when trying to "
> @@ -2082,13 +2083,15 @@
> return -EROFS;
> }
>
> - if (!(journal = ext3_get_journal(sb, journal_inum)))
> + journal = ext3_get_journal(sb, journal_inum);
> + if (!journal)
> return -EINVAL;
>
> printk(KERN_INFO "EXT3-fs: creating new journal on inode %u\n",
> journal_inum);
>
> - if (journal_create(journal)) {
> + err = journal_create(journal);
> + if (err) {
> printk(KERN_ERR "EXT3-fs: error creating journal.\n");
> journal_destroy(journal);
> return -EIO;
Please prepare the equivalent patch for ext4. Without that, it'd probably
be better to avoid applying the ext3 patch: there are advantages to keeping
the two in sync where possible.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] genericserial: Remove bogus optimisation check and dead code paths
On Tue, 03 Jul 2007 23:36:22 +0200 Morten Helgesen <[EMAIL PROTECTED]> wrote: > /* > > Problems to take into account are: > > -1- Interrupts that empty part of the buffer. > -> -2- page faults on the access to userspace. > +> -2- Page faults on access to userspace. #2 no longer applies (don't before the caller) > > -3- Other processes that are also trying to do a "write". #3 no longer applies (locked by tty layer) > - /* get exclusive "write" access to this port (problem 3) */ > + /* Get exclusive "write" access to this port (problem 3) */ > /* This is not a spinlock because we can have a disk access (page > - fault) in copy_from_user */ No copy_from_user any more. Actually that locking code wants review and maybe removal so is another project altogether Definitely an improvement Acked-by: Alan Cox <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway
On Tue, 3 Jul 2007, Matthew Garrett wrote: > On Tue, Jul 03, 2007 at 05:16:37PM -0400, Alan Stern wrote: > > On Tue, 3 Jul 2007, Matthew Garrett wrote: > > > But that's fine - "Are we undergoing a systemwide suspend" is an easy > > > question to ask. Freezing processes instead means that most of those > > > paths will never be tested. > > > > The question is easy to ask, but it's not so easy to figure out what > > you should do if the answer is Yes. Freezing processes instead means > > that those "untested" paths -- in many, many drivers -- won't have to > > exist at all. > > We're used to the idea of applications blocking when a resource they're > using goes away - NFS has done it forever. You persist in evading my point. I'm not worried about applications; I'm worried about drivers. Let me put it explicitly: You're writing a driver. You're working on the read, write, or probe method. You add code to check if a system sleep is underway. Suppose the answer is Yes -- what does your driver do next? Make your answer as detailed as you reasonably can. And be careful to arrange things so that an ongoing I/O operation doesn't get messed up when your suspend method is called. 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 1/4] scsi: megaraid_sas -- add hibernation support
On Sun, 01 Jul 2007 12:31:23 -0400
bo yang <[EMAIL PROTECTED]> wrote:
> The megaraid_sas driver doesn't support the hibernation, the
> suspend/resume routine implemented to support the hibernation.
>
> Signed-off-by: Bo Yang <[EMAIL PROTECTED]>
>
> ---
>
> drivers/scsi/megaraid/megaraid_sas.c | 308 +++--
> drivers/scsi/megaraid/megaraid_sas.h |1
> 2 files changed, 239 insertions(+), 70 deletions(-)
>
> diff -rupN linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c
> linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c
> --- linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c 2007-06-20
> 02:18:24.0 -0400
> +++ linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c 2007-06-30
> 03:21:27.0 -0400
wordwrapped.
> @@ -1804,6 +1804,81 @@ static void megasas_complete_cmd_dpc(uns
> }
>
> /**
> + * megasas_issue_init_mfi - Initializes the FW
> + * @instance: Adapter soft state
> + *
> + * Issues the INIT MFI cmd
> + */
> +static int
> +megasas_issue_init_mfi(struct megasas_instance *instance)
> +{
> + u32 context;
> +
> + struct megasas_cmd *cmd;
> +
> + struct megasas_init_frame *init_frame;
> + struct megasas_init_queue_info *initq_info;
> + dma_addr_t init_frame_h;
> + dma_addr_t initq_info_h;
Please use tabs, not spaces.
> + /*
> + * Prepare a init frame. Note the init frame points to queue info
> + * structure. Each frame has SGL allocated after first 64 bytes. For
> + * this frame - since we don't need any SGL - we use SGL's space as
> + * queue info structure
> + *
> + * We will not get a NULL command below. We just created the pool.
> + */
> + cmd = megasas_get_cmd(instance);
> +
> + init_frame = (struct megasas_init_frame *)cmd->frame;
> + initq_info = (struct megasas_init_queue_info *)
> + ((unsigned long)init_frame + 64);
> +
> + init_frame_h = cmd->frame_phys_addr;
> + initq_info_h = init_frame_h + 64;
> +
> + context = init_frame->context;
> + memset(init_frame, 0, MEGAMFI_FRAME_SIZE);
> + memset(initq_info, 0, sizeof(struct megasas_init_queue_info));
> + init_frame->context = context;
> +
> + initq_info->reply_queue_entries = instance->max_fw_cmds + 1;
> + initq_info->reply_queue_start_phys_addr_lo = instance->reply_queue_h;
> +
> + initq_info->producer_index_phys_addr_lo = instance->producer_h;
> + initq_info->consumer_index_phys_addr_lo = instance->consumer_h;
> +
> + init_frame->cmd = MFI_CMD_INIT;
> + init_frame->cmd_status = 0xFF;
> + init_frame->queue_info_new_phys_addr_lo = initq_info_h;
> +
> + init_frame->data_xfer_len = sizeof(struct megasas_init_queue_info);
> +
> + /*
> + * disable the intr before firing the init frame to FW
> + */
> + instance->instancet->disable_intr(instance->reg_set);
> +
> + /*
> + * Issue the init frame in polled mode
> + */
> +
> + if (megasas_issue_polled(instance, cmd)) {
> + printk(KERN_DEBUG "megasas: Failed to init firmware\n");
I'd have though KERN_ERR was appropriate here?
> + megasas_return_cmd(instance, cmd);
> + goto fail_fw_init;
> + }
> +
> + megasas_return_cmd(instance, cmd);
> +
> + return 0;
> +
> + fail_fw_init:
> + return -EINVAL;
> +}
>
> ..
>
> - if (megasas_issue_polled(instance, cmd)) {
> - printk(KERN_DEBUG "megasas: Failed to init firmware\n");
hm, it was KERN_DEBUG before. Perhaps that was wrong.
> +static int
> +megasas_set_dma_mask(struct pci_dev *pdev)
> +{
> + /*
> + * All our contollers are capable of performing 64-bit DMA
> + */
> + if (IS_DMA64) {
Bah.
#define IS_DMA64 (sizeof(dma_addr_t) == 8)
that should not be in a driver-private header file.
> +
> + fail_irq:
> + fail_init_mfi:
Opinions vary, but we usually indent labels by zero or one spaces.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Input: Support for a less exclusive grab.
On Tue, Jul 03, 2007 at 12:45:55PM -0400, Zephaniah E. Hull wrote: > Not really, what happens when the user presses alt-F1? Well, if the console is switched to medium raw or raw mode, nothing happens. > A way to tell the kernel that events from a given input device should > not go to the console has been needed since the very first time an X > driver allowed keyboard events from /dev/input/event, and that > still has not changed. And the ages old method that X has been using before the existence of the input layer still works fine, as far as I know. > We just want a more flexible approach then what we are already using[0]. I'm fine with that, I just wonder whether attacking it on the input layer side is the right way to do it: If you want to disable the console, tell the console. That way, we don't have to figure out which exact kernel input handlers are console and which are not. > I'll see about writing something up when I get back to my computers[1] > and have things set back up[2]. Enjoy whatever computerless period you're planning! -- Vojtech Pavlik Director SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [EXT4 set 4][PATCH 1/5] i_version:64 bit inode version
On Mon, Jul 02, 2007 at 10:58:33AM -0400, Mingming Cao wrote: > Trond or Bruce, can you please review these patch series and ack if you > agrees? Thanks, looks like what we need! How will nfsd tell whether it can really on a given filesystem's i_version, or whether it should fall back on ctime? > As to performance concerns that raise before the inode version counter > (at least for ext4) is done inside ext4_mark_inode_dirty), so there is > no extra IO work to store this counter to disk. So what's the motivation for the "noversion" mount option? --b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] util-linux-ng 2.13-rc1
The first util-linux-ng 2.13 release candidate is available at
ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/v2.13/
Thanks to all who help with util-linux resuscitation:
H. Peter Anvin
Ian Kent
and contribute to this project:
Arkadiusz Miskiewicz Matthias Koenig
Cliff Wickman Mike Frysinger
David Brownell Pádraig Brady
David Miller Radek Biba
Jason Vas Dias Ram Pai
Kay SieversStepan Kasal
Luciano Chavez Steve Grubb
Marco d'Itri Valerie Henson
Martin Schlemmer
Feedback and bug reports, as always, are welcomed.
Karel
Util-linux-ng 2.13 Release Notes
Release highlights:
--
mount(8) doesn't include NFS client code anymore. Don't forget to
install nfs-utils 1.1.0 or newer with /sbin/[u]mount.{nfs,nfs4}.
mount(8) doesn't include filesystem detection code anymore. You
have to compile --with-fsprobe={blkid,volume_id}, and libblkid
(e2fsprogs) or libvolume_id (udev >= v110) is required.
mount(8) supports new relatime, context, fscontext, and defcontext
mount options.
losetup(8) supports command line option "-a" to list all used loop
devices, '-s' to print a device name if "-f" and a file argument
are present, and "-r" to create a read-only loop device.
fdisk(8) Sun label support has been improved. fdisk(8) is also able
to warn about detected GPT (fdisk doesn't support GPT).
taskset(1) is independent on hardcoded NR_CPUS. chrt(1) supports
SCHED_BATCH scheduling policy.
The package build system is now based on autotools. The build system
supports separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
SUID_LDFLAGS). For more details see the README file
hwclock(8) supports command line option --rtc= and /dev/rtc0
device. --systohc functionality has been improved, and it doesn't cause
a 500ms inaccuracy each time it is used.
Audit system support (--with-audit) has been added to hwclock(8) and
login(1).
SELinux support (--with-selinux) has been added to mkswap(8) and
mount(8).
The setarch(8) upstream has been merged with util-linux-ng.
Fixed security issues:
-
CVE-2007-0822 - mount(8) allows local users to trigger a NULL
dereference and an application crash
CVE-2006-7108 - login(1) omits PAM account validation when auth is
skipped
Changelog:
-
agetty:
add 'O' escape code to display domain name
check gethostname() return value
blockdev:
add BLKFRAGET/BLKFRASET ioctls
cleanup usage() and update man page
build-sys:
add AC_GNU_SOURCE
add Automake option dist-bzip2
add missing files
add SUID_CFLAGS
add SUID_LDFLAGS
add support for audit
amend .gitignore
call automake after autoconf
cleanup architecture conditionals
cleanup sys-utils/ rdev symlinks
configure.am selinux support cleanup
declare SUID_CFLAGS and SUID_LDFLAGS as precious
do not build convenience libraries in lib/
do not kick off AM_CFLAGS by SUID_CFLAGS
do not play with DEFS, use AM_CPPFLAGS
do not set with_foo twice
do not use internal Autoconf variables
do not use wildcards in EXTRA_DIST
factor out common parts from mount/Makefile.am
fix HAVE_NCURSES
fix ifdef ENABLE_WIDECHAR usage
fix linking when ncurses is built with --with-termlib=tinfo
fix README filenames and add missing files to EXTRA_DISTs
fix the example configure call in README
fix the final message of autogen.sh
in configure.ac, change "po" -> "$srcdir/po"
in the clean targets use "find ... | xargs rm -f"
let configure instantiate the misc-utils/*.pl scripts
make the getopt example directory relative to datadir
merge adjacent AC_CONFIG_HEADERS and AC_CONFIG_FUNCS calls
minor fixes in configure.in
mount/Makefile.am tiny cleanup
mount/Makefile.am tiny cleanup II
move -D flags to *_CPPFLAGS
move the optimization flags to AM_CFLAGS
--prefix defaults to /usr
remove aclocal.m4 from SCM
remove AC_PROG_RANLIB
remove config.h.in from VCS
remove config/include-Makefile.am from EXTRA_DIST
remove DEFAULT_INCLUDES workaround
remove -fomit-frame-pointer
remove generated autotools stuff from git
remove po/Makevars.template from EXTRA_DIST
remove swapargs.h, move the tests to main configure.ac
rename to -ng, change maintainer name
replace AC_TRY_* by AC_*_IFELSE
s/AC_HELP_STRING/AS_HELP_STRING/
set DISTCHECK_CONFIGURE_FLAGS in top-level makefile
simplify "clean" in tests/Makefile.am
update po/POTFILES.in
use dist_example_DATA
use
Re: 2.6.22-rc7: known regressions with patches
On 2007.07.03 14:42:25 -0700, Linus Torvalds wrote: > > > On Tue, 3 Jul 2007, Bj?rn Steinbrink wrote: > > Andi said that one of the regression fixes wasn't critical for .22 and > > that he wants to do a stopgap for the other regression (my patch > > sucked), reverting the code to the .21 version. So you can drop the > > patches and/or me here. > > Can you say which patch should be reverted. This thing really shouldn't > have gone on this long, I would have hopef we had the oprofile thing > sorted out already.. That would be commit 09198e68501a7e34737cd9264d266f42429abcdc, for which there are already a few fixes in your tree. Andi, did you intent to fully revert that, or just certain parts of it? Björn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove process freezer from suspend to RAM pathway
Am Dienstag, 3. Juli 2007 schrieb Benjamin Herrenschmidt: > On Tue, 2007-07-03 at 23:48 +0200, Oliver Neukum wrote: > > Am Dienstag, 3. Juli 2007 schrieb Benjamin Herrenschmidt: > > > On Tue, 2007-07-03 at 21:32 +0200, Oliver Neukum wrote: > > > > > I'm not sure why this can't be made atomic, but assuming, that it > > > > > can't, fuse should still not need to be implicated. If it is, > > > > that's > > > > > an indication about something wrong in the suspend procedure. > > > > > > > > Nope, something's wrong in fuse. You must be able to deal with sync > > > > until every task is frozen. > > > > > > Pipe dream > > > > Then tell me how you want to avoid that condition. > > Don't freeze :-) Then you will have to deal with all syscalls unfrozen tasks can make. Regards Oliver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how do versioning filesystems take snapshot of opened files?
On Tuesday July 3, [EMAIL PROTECTED] wrote: > > Getting a snapshot that is useful with respect to application data > requires help from the application. Certainly. > The app needs to be shutdown or > paused prior to the snapshot and then started up again after the > snapshot is taken. Alternately, the app needs to be able to cope with unexpected system shutdown (aka crash) and the same ability will allow it to cope with an atomic snapshot. It may be able to recover more efficiently from an expected shutdown, so being able to tell the app about an impending snapshot is probably a good idea, but it should be advisory only. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Re: Sparc32: random invalid instruction occourances on sparc32 (sun4c)
On Tue, 2007-07-03 at 14:41 -0700, David Miller wrote: > Please don't use get_unaligned() or whatever to fix this, it's > going to generate the byte-at-a-time accesses on sparc64 > which doesn't need it since the redzone will be aligned. Yes, get_unaligned() would suck. But 'u64 __aligned__((BYTES_PER_WORD))' as I suggested should result in a single 64-bit load on 64-bit architectures, and two 32-bit loads on 32-bit architectures. But I think the patch I just sent is a better option than that anyway. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/4] scsi: megaraid_sas -- add hibernation support
The megaraid_sas driver doesn't support the hibernation, the
suspend/resume routine implemented to support the hibernation.
Signed-off-by: Bo Yang <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 308 +++--
drivers/scsi/megaraid/megaraid_sas.h |1
2 files changed, 239 insertions(+), 70 deletions(-)
diff -rupN linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c
linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c
--- linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c 2007-06-20
02:18:24.0 -0400
+++ linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c 2007-06-30
03:21:27.0 -0400
@@ -1804,6 +1804,81 @@ static void megasas_complete_cmd_dpc(uns
}
/**
+ * megasas_issue_init_mfi - Initializes the FW
+ * @instance: Adapter soft state
+ *
+ * Issues the INIT MFI cmd
+ */
+static int
+megasas_issue_init_mfi(struct megasas_instance *instance)
+{
+ u32 context;
+
+ struct megasas_cmd *cmd;
+
+ struct megasas_init_frame *init_frame;
+ struct megasas_init_queue_info *initq_info;
+ dma_addr_t init_frame_h;
+ dma_addr_t initq_info_h;
+
+ /*
+* Prepare a init frame. Note the init frame points to queue info
+* structure. Each frame has SGL allocated after first 64 bytes. For
+* this frame - since we don't need any SGL - we use SGL's space as
+* queue info structure
+*
+* We will not get a NULL command below. We just created the pool.
+*/
+ cmd = megasas_get_cmd(instance);
+
+ init_frame = (struct megasas_init_frame *)cmd->frame;
+ initq_info = (struct megasas_init_queue_info *)
+ ((unsigned long)init_frame + 64);
+
+ init_frame_h = cmd->frame_phys_addr;
+ initq_info_h = init_frame_h + 64;
+
+ context = init_frame->context;
+ memset(init_frame, 0, MEGAMFI_FRAME_SIZE);
+ memset(initq_info, 0, sizeof(struct megasas_init_queue_info));
+ init_frame->context = context;
+
+ initq_info->reply_queue_entries = instance->max_fw_cmds + 1;
+ initq_info->reply_queue_start_phys_addr_lo = instance->reply_queue_h;
+
+ initq_info->producer_index_phys_addr_lo = instance->producer_h;
+ initq_info->consumer_index_phys_addr_lo = instance->consumer_h;
+
+ init_frame->cmd = MFI_CMD_INIT;
+ init_frame->cmd_status = 0xFF;
+ init_frame->queue_info_new_phys_addr_lo = initq_info_h;
+
+ init_frame->data_xfer_len = sizeof(struct megasas_init_queue_info);
+
+ /*
+* disable the intr before firing the init frame to FW
+*/
+ instance->instancet->disable_intr(instance->reg_set);
+
+ /*
+* Issue the init frame in polled mode
+*/
+
+ if (megasas_issue_polled(instance, cmd)) {
+ printk(KERN_DEBUG "megasas: Failed to init firmware\n");
+ megasas_return_cmd(instance, cmd);
+ goto fail_fw_init;
+ }
+
+ megasas_return_cmd(instance, cmd);
+
+ return 0;
+
+ fail_fw_init:
+ return -EINVAL;
+}
+
+/**
* megasas_init_mfi - Initializes the FW
* @instance: Adapter soft state
*
@@ -1816,15 +1891,7 @@ static int megasas_init_mfi(struct megas
u32 max_sectors_1;
u32 max_sectors_2;
struct megasas_register_set __iomem *reg_set;
-
- struct megasas_cmd *cmd;
struct megasas_ctrl_info *ctrl_info;
-
- struct megasas_init_frame *init_frame;
- struct megasas_init_queue_info *initq_info;
- dma_addr_t init_frame_h;
- dma_addr_t initq_info_h;
-
/*
* Map the message registers
*/
@@ -1901,52 +1968,8 @@ static int megasas_init_mfi(struct megas
goto fail_reply_queue;
}
- /*
-* Prepare a init frame. Note the init frame points to queue info
-* structure. Each frame has SGL allocated after first 64 bytes. For
-* this frame - since we don't need any SGL - we use SGL's space as
-* queue info structure
-*
-* We will not get a NULL command below. We just created the pool.
-*/
- cmd = megasas_get_cmd(instance);
-
- init_frame = (struct megasas_init_frame *)cmd->frame;
- initq_info = (struct megasas_init_queue_info *)
- ((unsigned long)init_frame + 64);
-
- init_frame_h = cmd->frame_phys_addr;
- initq_info_h = init_frame_h + 64;
-
- memset(init_frame, 0, MEGAMFI_FRAME_SIZE);
- memset(initq_info, 0, sizeof(struct megasas_init_queue_info));
-
- initq_info->reply_queue_entries = instance->max_fw_cmds + 1;
- initq_info->reply_queue_start_phys_addr_lo = instance->reply_queue_h;
-
- initq_info->producer_index_phys_addr_lo = instance->producer_h;
- initq_info->consumer_index_phys_addr_lo = instance->consumer_h;
-
- init_frame->cmd = MFI_CMD_INIT;
- init_frame->cmd_status = 0xFF;
- init_frame->queue_info_new_phys_addr_lo = initq_info_h;
-
-
Re: [PATCH] Remove process freezer from suspend to RAM pathway
On Tue, 2007-07-03 at 23:48 +0200, Oliver Neukum wrote: > Am Dienstag, 3. Juli 2007 schrieb Benjamin Herrenschmidt: > > On Tue, 2007-07-03 at 21:32 +0200, Oliver Neukum wrote: > > > > I'm not sure why this can't be made atomic, but assuming, that it > > > > can't, fuse should still not need to be implicated. If it is, > > > that's > > > > an indication about something wrong in the suspend procedure. > > > > > > Nope, something's wrong in fuse. You must be able to deal with sync > > > until every task is frozen. > > > > Pipe dream > > Then tell me how you want to avoid that condition. Don't freeze :-) 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: [EXT4 set 4][PATCH 1/5] i_version:64 bit inode version
On Jul 03, 2007 10:24 -0400, Trond Myklebust wrote: > It looks OK to me, but you might want to strip out the now redundant > i_version updates in add_dirent_to_buf(), ext4_rmdir(), ext4_rename(). Agreed, and I thought we discussed that already on the ext4 list. > I also have some questions about how this will affect the readdir code: > unless I missed something, the filp->f_version is still unsigned long, > so the comparisons and assignments in ext4_readdir()/ext4_dx_readdir() > no longer make sense. I don't see them as any worse than existing checks. For 32-bit systems we only ever had a 32-bit in-memory version anyway so using only the low 32 bits of i_version in f_version is no more racy than in the past. For 64-bit systems using the full on-disk i_version is possible. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Re: Sparc32: random invalid instruction occourances on sparc32 (sun4c)
On Tue, 2007-07-03 at 22:25 +0100, Mark Fortescue wrote:
> The problem is that sun4c Sparc32 can't handle un-aligned variables so
> having a 64bit readzone word that is not aligned on a 64bit boundary is a
> problem.
Surely, it can. You just have to tell the compiler that it's not
properly aligned, and it'll emit code to cope. Hence the suggestion that
you use 'unsigned long long __attribute__((aligned(BYTES_PER_WORD))'.
But it's probably better just to make sure it remains aligned; you're
right.
> In addition, having looked at the size calculations, it looks to me as if
> not all of them got updated to handle 64bit redzone words.
Really? Other than the alignment of the second redzone, what's wrong?
Remember that the 'user word' is still not necessarily 64-bit. And in
fact I suspect that's what is causing the problem -- your object _size_
will be aligned to 8 bytes, including the user word, and then we look
for the second redzone word 12 bytes before the end of the object.
Does this fix it?
diff --git a/mm/slab.c b/mm/slab.c
index 6d65cf4..3b15671 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -547,7 +547,7 @@ static unsigned long long *dbg_redzone2(struct kmem_cache
*cachep, void *objp)
if (cachep->flags & SLAB_STORE_USER)
return (unsigned long long *)(objp + cachep->buffer_size -
sizeof(unsigned long long) -
- BYTES_PER_WORD);
+ max(BYTES_PER_WORD,
__alignof__(unsigned long long)));
return (unsigned long long *) (objp + cachep->buffer_size -
sizeof(unsigned long long));
}
@@ -2262,9 +2262,14 @@ kmem_cache_create (const char *name, size_t size, size_t
align,
}
if (flags & SLAB_STORE_USER) {
/* user store requires one word storage behind the end of
-* the real object.
+* the real object. But if the second red zone must be
+* aligned 'better' than that, allow for it.
*/
- size += BYTES_PER_WORD;
+ if (flags & SLAB_RED_ZONE
+ && BYTES_PER_WORD < __alignof__(unsigned long long))
+ size += __alignof__(unsigned long long);
+ else
+ size += BYTES_PER_WORD;
}
#if FORCED_DEBUG && defined(CONFIG_DEBUG_PAGEALLOC)
if (size >= malloc_sizes[INDEX_L3 + 1].cs_size
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] #if 0 mm/backing-dev.c:congestion_wait_interruptible()
On Sun, 1 Jul 2007 22:20:51 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote: > congestion_wait_interruptible() is no longer used. We might as well just delete 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: [PATCH] Remove process freezer from suspend to RAM pathway
Am Dienstag, 3. Juli 2007 schrieb Benjamin Herrenschmidt: > On Tue, 2007-07-03 at 21:32 +0200, Oliver Neukum wrote: > > > I'm not sure why this can't be made atomic, but assuming, that it > > > can't, fuse should still not need to be implicated. If it is, > > that's > > > an indication about something wrong in the suspend procedure. > > > > Nope, something's wrong in fuse. You must be able to deal with sync > > until every task is frozen. > > Pipe dream Then tell me how you want to avoid that condition. Oliver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] genericserial: Remove bogus optimisation check and dead code paths
Alan Cox wrote: On Tue, 03 Jul 2007 16:39:05 +0200 Morten Helgesen <[EMAIL PROTECTED]> wrote: Alan Cox wrote: [...snip...] @@ -75,11 +64,11 @@ if (! (port->flags & ASYNC_INITIALIZED)) return; /* Take a lock on the serial tranmit buffer! */ - LOCKIT; + mutex_lock(& port->port_write_mutex); ^ Contains additional whitespace. Its an old driver, it doesn't follow the coding style too well at all - viz stuff like if (! ( the line above. Given its age and limited userbase I don't plan to go and make it conform either, but I will take patches for the formatting (and the spelling errors it is full of) from someone who wants to do the work. Alan Ok, so how is this for a start? - Proper indenting. - Fixes for the most obvious typos and spelling errors. Signed-off-by: Morten Helgesen <[EMAIL PROTECTED]> == Morten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway
Am Dienstag, 3. Juli 2007 schrieb Matthew Garrett: > On Tue, Jul 03, 2007 at 11:37:51PM +0200, Rafael J. Wysocki wrote: > > On Tuesday, 3 July 2007 23:20, Matthew Garrett wrote: > > > We're used to the idea of applications blocking when a resource they're > > > using goes away - NFS has done it forever. > > > > Now, please tell me how many driver writers even thought that something > > might try to access their devices after .suspend() had been executed (or > > even whilie it was being executed)? > > Every single driver that fails under those conditions is already broken, > and has been forever. It's likely that they're broken under run-time > suspend, too. There _is_ no runtime syspend in working condition. The interface to do that has been scheduled for removal. Oliver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
