Re: Reducing debuginfo size by removing unneeded includes
Hi Andi. On Mon, Feb 18, 2008 at 02:12:01PM +0100, Andi Kleen wrote: > Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> writes: > > > > [EMAIL PROTECTED] net-2.6]$ l /tmp/sys_ia32.o.before /tmp/sys_ia32.o.after > > -rw-rw-r-- 1 acme acme 185240 2008-02-06 19:19 /tmp/sys_ia32.o.after > > -rw-rw-r-- 1 acme acme 248328 2008-02-06 19:00 /tmp/sys_ia32.o.before > > > > Almost 64KB only on this object file! > > Just FYI, newer gcc does this in theory automatically when you specify > > -feliminate-unused-debug-types -feliminate-unused-debug-symbols google did not turn up anything useful. Do you have a poiter to where these are described? > There is also -feliminate-dwarf2-dups, but it seems to even increase > obj dir size. Also -feliminate-dwarf2-dups seems to generate a lot of Google only turned up a patch from Mark Mitchell removing this in ~2001 timeframe. So again a pointer would be nice. I use FC8: gcc --version gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33) So this is far behind trunk that you use - but I have not had any real incentive to upgrade. I would like to have a remote understanding of the options before enabling them. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.25-rc2 + smartd = hang
Hi! > So that's using the old IDE drivers. > And the network and USB are sharing IRQ#11 with each > other. > > If you are going to be using newer kernels like this > (2.6.23+), > then you might consider shifting those drives over to > libata drivers. Yes, that will probably fix it for him, but but... maybe we should fix that regression? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 hangs after "Suspending console(s)"
On Tue 2008-02-19 09:52:22, Tino Keitel wrote: > On Mon, Feb 18, 2008 at 20:49:04 +0100, Pavel Machek wrote: > > On Mon 2008-02-18 01:28:15, Tino Keitel wrote: > > > Hi folks, > > > > > > with 2.6.25-rc2, my Mac mini Core Duo hangs at suspend. The last > > > message on the console is "Suspending console(s)". I also tried some > > > other versions after 2.6.24, all of them fail with this hang. > > > > Try adding 'no_console_suspend' to kernel command line. > > Thanks, that gave a bit insight. The last message is now: > > ACPI: PCI interrupt for device :00:02.0 disabled > > This is my graphics card: > > 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile > 945GM/GMS, 943/940GML Express Integrated Graphics Controller > > So it looks like the recent changes that should repair console > sudpend/resume for Intel graphics broke suspend for me. Can you bisect (if it worked before) or add printks to see where it fails? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression: CD burning (k3b) went broke
On Sat, 2008-02-23 at 08:42 +0100, Mike Galbraith wrote: > Meanwhile back at the ranch, reverting > 6b00769fe1502b4ad97bb327ef7ac971b208bfb5 > 40b01b9bbdf51ae543a04744283bf2d56c4a6afa and the one entangled line from > dde2020754aeb14e17052d61784dcb37f252aac2 did restore my burner. It looks like the reason for boot failure with 40b01b9bbdf51ae543a04744283bf2d56c4a6afa may be that one hunk of 6b00769fe1502b4ad97bb327ef7ac971b208bfb5 was supposed to land in 40b01b9bbdf51ae543a04744283bf2d56c4a6afa (per comment); diff --git a/block/blk-map.c b/block/blk-map.c index a7cf63c..09f7fd0 100644 --- a/block/blk-map.c +++ b/block/blk-map.c @@ -154,6 +155,7 @@ int blk_rq_map_user(struct request_queue *q, struct request *rq, bio->bi_io_vec[bio->bi_vcnt - 1].bv_len += pad_len; bio->bi_size += pad_len; + rq->data_len += pad_len; } rq->buffer = rq->data = NULL; Something else looks funny with 6b00769fe1502b4ad97bb327ef7ac971b208bfb5, did something go missing? diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 135c1d0..ba21d97 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -1014,10 +1014,6 @@ static int scsi_init_sgtable(struct request *req, struct scsi_data_buffer *sdb, } req->buffer = NULL; - if (blk_pc_request(req)) - sdb->length = req->data_len; - else - sdb->length = req->nr_sectors << 9; /* * Next, walk the list, and fill in the addresses and sizes of <== here @@ -1026,6 +1022,10 @@ static int scsi_init_sgtable(struct request *req, struct scsi_data_buffer *sdb, count = blk_rq_map_sg(req->q, req, sdb->table.sgl); BUG_ON(count > sdb->table.nents); sdb->table.nents = count; + if (blk_pc_request(req)) + sdb->length = req->data_len; + else + sdb->length = req->nr_sectors << 9; return BLKPREP_OK; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
* Yinghai Lu <[EMAIL PROTECTED]> wrote: > quad core 8 socket system will have apic id lifting.the apic id range > could be [4, 0x23]. and apic_is_clustered_box will think that need to > three clusters and that is large than 2. So it is treated as > clustered_box. > > and will get > > Marking TSC unstable due to TSCs unsynchronized > > even the CPUs have X86_FEATURE_CONSTANT_TSC set. > > this patch will check if the cpu is from AMD. thanks Yinghai, applied. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
On Fri, 22 February 2008 23:28:58 +0100, Krzysztof Halasa wrote: > Al Viro <[EMAIL PROTECTED]> writes: > > > IMO the line length overruns make good warnings. Not as in "here's a cheap > > way to get more changesets", but as in "that code might have other problems > > nearby" kind of heuristics. > > Sure, it does. However the human looking at the code is far better at > spotting such problems. Machine-generated warnings are great when the > machine is actually better than human. I strongly disagree. Machine-generated warnings are a great way of quickly locating a large amount of questionable code in an otherwise overwhelming haystack. It doesn't even matter much, which warnings you look for. Almost all code checkers find the same hotspots. But there is a catch. If you have an over-eager warning police that "fixes all the warnings", the warnings may be gone, but the very real problems in near vicinity are not. Not to mention new problems introduced by those claimed "fixes". One fun hobby in my last job was to write a new code checker and locate those problem areas hidden behind warning-free code. I had to write a new checker so I would see below the polish of "fixes". The actual problems found by the checker were often trivial and near-meaningless. But those warnings are not the point at all, quite the contrary. The only important thing was "that code might have other problems nearby". Note one scary consequence: code checkers in the wrong hands are actively harmful. Jörn -- 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: [patch 1/2] x86,fpu: split FPU state from task struct
On Sat, Feb 23, 2008 at 06:34:38PM -0800, Suresh Siddha wrote: > Split the FPU save area from the task struct. This allows easy migration > of FPU context, and it's generally cleaner. It also allows the following > two optimizations: > > 1) only allocate when the application actually uses FPU, so in the first > lazy FPU trap. This could save memory for non-fpu using apps. Next patch > does this lazy allocation. > > 2) allocate the right size for the actual cpu rather than 512 bytes always. > Patches enabling xsave/xrstor support (coming shortly) will take advantage > of this. >if (next_p->fpu_counter>5) > - prefetch(>i387.fxsave); > + prefetch(FXSAVE(next_p)); Shouldn't that be prefetch(FXSAVE(next)); ? Roger -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: jffs2: -ENOSPC when truncating file?!
On Sun 2008-02-24 09:36:07, David Woodhouse wrote: > > On Sun, 2008-02-24 at 00:57 +0100, Pavel Machek wrote: > > Hi! > > > > I'm trying to free space by truncating big file, and I get: > > > > [EMAIL PROTECTED]:~# ls -al gps.nmea > > -rw-r--r--1 root root 2332070 Feb 19 22:13 gps.nmea > > [EMAIL PROTECTED]:~# > gps.nmea > > -sh: cannot create gps.nmea: No space left on device > > [EMAIL PROTECTED]:~# rm gps.nmea > > [EMAIL PROTECTED]:~# > gps.nmea > > [EMAIL PROTECTED]:~# > > You need to write a log entry indicating the new length of the file. > There is no space for new log entries. > > There is a special case for removal -- 'rm gps.nmea' would work. Perhaps > we should add a special case for truncation too, so that it can also use > the extra pool of free space. Yes, that would be nice. I somehow assumed that truncate can't fail for -ENOSPC ... I was trying to actually free some space on the filesystem... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] x86,fpu: split FPU state from task struct
* Suresh Siddha <[EMAIL PROTECTED]> wrote: > Split the FPU save area from the task struct. This allows easy > migration of FPU context, and it's generally cleaner. It also allows > the following two optimizations: > > 1) only allocate when the application actually uses FPU, so in the > first lazy FPU trap. This could save memory for non-fpu using apps. > Next patch does this lazy allocation. > > 2) allocate the right size for the actual cpu rather than 512 bytes > always. Patches enabling xsave/xrstor support (coming shortly) will > take advantage of this. i like the concept. Please clean up the issues found by Christoph and please also base it against x86.git#testing [this is clear 2.6.26 material and there are already some changes in this area]: http://people.redhat.com/mingo/x86.git/README Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: jffs2: -ENOSPC when truncating file?!
On Sun, 24 February 2008 09:36:07 +0900, David Woodhouse wrote: > On Sun, 2008-02-24 at 00:57 +0100, Pavel Machek wrote: > > > > I'm trying to free space by truncating big file, and I get: > > > > [EMAIL PROTECTED]:~# ls -al gps.nmea > > -rw-r--r--1 root root 2332070 Feb 19 22:13 gps.nmea > > [EMAIL PROTECTED]:~# > gps.nmea > > -sh: cannot create gps.nmea: No space left on device > > [EMAIL PROTECTED]:~# rm gps.nmea > > [EMAIL PROTECTED]:~# > gps.nmea > > [EMAIL PROTECTED]:~# > > You need to write a log entry indicating the new length of the file. > There is no space for new log entries. > > There is a special case for removal -- 'rm gps.nmea' would work. Perhaps > we should add a special case for truncation too, so that it can also use > the extra pool of free space. Could a naïve implementation of this get exploited by doing a large number of truncates that just shave single bytes off various files? Looks like the safe way to do it would be to write out a replacement node for the truncated node, if the special case ever triggers. Jörn -- "[One] doesn't need to know [...] how to cause a headache in order to take an aspirin." -- Scott Culp, Manager of the Microsoft Security Response Center, 2001 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 15/28] netvm: network reserve infrastructure
On Wed, Feb 20, 2008 at 9:46 AM, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> Provide the basic infrastructure to reserve and charge/account network memory.
...
> Index: linux-2.6/net/core/sock.c
> ===
> --- linux-2.6.orig/net/core/sock.c
> +++ linux-2.6/net/core/sock.c
...
> +/**
> + * sk_adjust_memalloc - adjust the global memalloc reserve for critical
> RX
> + * @socks: number of new %SOCK_MEMALLOC sockets
> + * @tx_resserve_pages: number of pages to (un)reserve for TX
> + *
> + * This function adjusts the memalloc reserve based on system demand.
> + * The RX reserve is a limit, and only added once, not for each socket.
> + *
> + * NOTE:
> + *@tx_reserve_pages is an upper-bound of memory used for TX hence
> + *we need not account the pages like we do for RX pages.
> + */
> +int sk_adjust_memalloc(int socks, long tx_reserve_pages)
> +{
> + int nr_socks;
> + int err;
> +
> + err = mem_reserve_pages_add(_tx_pages, tx_reserve_pages);
> + if (err)
> + return err;
> +
> + nr_socks = atomic_read(_socks);
> + if (!nr_socks && socks > 0)
> + err = mem_reserve_connect(_reserve, _reserve_root);
> + nr_socks = atomic_add_return(socks, _socks);
> + if (!nr_socks && socks)
> + err = mem_reserve_disconnect(_reserve);
> +
> + if (err)
> + mem_reserve_pages_add(_tx_pages, -tx_reserve_pages);
> +
> + return err;
> +}
EXPORT_SYMBOL_GPL(sk_adjust_memalloc); is needed here to build sunrpc
as a module.
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: [PATCH 1/1] file capabilities: simplify signal check
Andrew Morton <[EMAIL PROTECTED]> writes:
> um, is that code namespace-clean?
Choke, gag.
There are uid namespace issues but since no one has finished the
uid namespace that I am aware of that is minor.
However the code does not appear clean/maintainable. The normal linux
signal sending policy has already been enforce before we get to this
point.
So unless I am totally mistaken the code should read:
int cap_task_kill(struct task_struct *p, struct siginfo *info,
int sig, u32 secid)
{
if (info != SEND_SIG_NOINFO && (is_si_special(info) ||
SI_FROMKERNEL(info)))
return 0;
if (!cap_issubset(p->cap_permitted, current->cap_permitted))
return -EPERM;
return 0;
}
Although doing it that way violates:
/*
* Running a setuid root program raises your capabilities.
* Killing your own setuid root processes was previously
* allowed.
* We must preserve legacy signal behavior in this case.
*/
Which says to me the code should really read:
int cap_task_kill(struct task_struct *p, struct siginfo *info,
int sig, u32 secid)
{
return 0;
}
The entire point of defining cap_task_kill under
CONFIG_SECURITY_FILE_CAPABLITIES appears to be deny killing processes
with more caps. Killing processes that we could ordinarily kill
which have more caps appears to be precisely the case we have decided
to allow. So the patched version of cap_task_kill appears to be an
expensive way of doing nothing, just waiting for someone to complain
about the last couple of cases it denies until it is truly a noop.
> Thanks.
>
> Begin forwarded message:
>
> Date: Wed, 20 Feb 2008 10:15:50 -0600
> From: "Serge E. Hallyn" <[EMAIL PROTECTED]>
> To: lkml
> Subject: [PATCH 1/1] file capabilities: simplify signal check
>
>
>>From bd076c7245d02be0cc01b7c09bd7170ec5946492 Mon Sep 17 00:00:00 2001
> From: Serge E. Hallyn <[EMAIL PROTECTED]>
> Date: Sun, 17 Feb 2008 20:28:07 -0500
> Subject: [PATCH 1/1] file capabilities: simplify signal check
>
> Simplify the uid equivalence check in cap_task_kill(). Anyone
> can kill a process owned by the same uid.
>
> Without this patch wireshark is reported to fail.
>
> Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]>
> Signed-off-by: Andrew G. Morgan <[EMAIL PROTECTED]>
> ---
> security/commoncap.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/security/commoncap.c b/security/commoncap.c
> index 5aba826..bb0c095 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -552,7 +552,7 @@ int cap_task_kill(struct task_struct *p, struct siginfo
> *info,
>* allowed.
>* We must preserve legacy signal behavior in this case.
>*/
> - if (p->euid == 0 && p->uid == current->uid)
> + if (p->uid == current->uid)
> return 0;
>
> /* sigcont is permitted within same session */
> --
> 1.5.1.1.GIT
So it looks to me like we should just give up trying to deny a few
cases now.
diff --git a/security/commoncap.c b/security/commoncap.c
index 5aba826..c1d1fd7 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -540,41 +540,6 @@ int cap_task_setnice (struct task_struct *p, int nice)
return cap_safe_nice(p);
}
-int cap_task_kill(struct task_struct *p, struct siginfo *info,
- int sig, u32 secid)
-{
- if (info != SEND_SIG_NOINFO && (is_si_special(info) ||
SI_FROMKERNEL(info)))
- return 0;
-
- /*
-* Running a setuid root program raises your capabilities.
-* Killing your own setuid root processes was previously
-* allowed.
-* We must preserve legacy signal behavior in this case.
-*/
- if (p->euid == 0 && p->uid == current->uid)
- return 0;
-
- /* sigcont is permitted within same session */
- if (sig == SIGCONT && (task_session_nr(current) == task_session_nr(p)))
- return 0;
-
- if (secid)
- /*
-* Signal sent as a particular user.
-* Capabilities are ignored. May be wrong, but it's the
-* only thing we can do at the moment.
-* Used only by usb drivers?
-*/
- return 0;
- if (cap_issubset(p->cap_permitted, current->cap_permitted))
- return 0;
- if (capable(CAP_KILL))
- return 0;
-
- return -EPERM;
-}
-
/*
* called from kernel/sys.c for prctl(PR_CABSET_DROP)
* done without task_capability_lock() because it introduces
@@ -605,13 +570,13 @@ int cap_task_setnice (struct task_struct *p, int nice)
{
return 0;
}
+#endif
+
int cap_task_kill(struct task_struct *p, struct siginfo *info,
int sig, u32 secid)
{
return 0;
}
-#endif
-
void cap_task_reparent_to_init (struct task_struct *p)
{
Re: [PATCH 1/1] [SCSI] gdth: misc cleanups, preparation for ISA/EISA hotplug API
On Sun, Feb 24, 2008 at 12:31:17AM -0500, Christoph Hellwig wrote: > On Sun, Feb 24, 2008 at 12:18:23AM -0500, Jeff Garzik wrote: > > hm. We'll see how it plays out... on the remove side, the above is > > exact what happens in gdth_remove_one() without my patch, thus > > consolidating two cases of the same code into one. There is a less-strong > > argument for doing the allocation that way, but it may turn out to be > > useful anyway once the ISA/EISA API conversion is complete. > > EISA ->remove has a different prototype from PCI ->remove from ISA > ->remove, so gdth_remove_one will be split up eventually. Having the > scsi_host_put duplicated in each shouldn't be too much of a problem :) Shouldn't need to duplicate it ... free bus-specific things in the ->remove method, and call a common helper. See advansys_release() and its callers in advansys.c for how I did it. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Xilinx: hwicap: cleanup
Stephen, when you address these comments, please double check the lkml
address. It was misspelled when you sent this patch.
Cheers,
g.
On Sat, Feb 23, 2008 at 11:16 PM, Grant Likely
<[EMAIL PROTECTED]> wrote:
> On Mon, Feb 11, 2008 at 11:24 AM, Stephen Neuendorffer
> <[EMAIL PROTECTED]> wrote:
> > Fix some missing __user tags and incorrect section tags.
> > Convert semaphores to mutexes.
> > Make probed_devices re-entrancy and error condition safe.
> > Fix some backwards memcpys.
> > Some other minor cleanups.
> > Use kerneldoc format.
> >
> > Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
>
> Thanks Steven, some more comments below.
^^
Oops, sorry about the spelling.
g.
>
>
> >
> > ---
> >
> > Grant, Since it appears that the driver will stay in as-is, here are
> > the updates against mainline, based on Jiri's comments.
> > ---
> > drivers/char/xilinx_hwicap/buffer_icap.c | 80 ++--
> > drivers/char/xilinx_hwicap/fifo_icap.c | 60 +++---
> > drivers/char/xilinx_hwicap/xilinx_hwicap.c | 113
>
> > drivers/char/xilinx_hwicap/xilinx_hwicap.h | 24 +++---
> > 4 files changed, 148 insertions(+), 129 deletions(-)
> >
> > diff --git a/drivers/char/xilinx_hwicap/buffer_icap.c
> b/drivers/char/xilinx_hwicap/buffer_icap.c
> > index dfea2bd..2c5d17d 100644
> > --- a/drivers/char/xilinx_hwicap/buffer_icap.c
> > +++ b/drivers/char/xilinx_hwicap/buffer_icap.c
>
> > @@ -148,9 +148,9 @@ static inline void buffer_icap_set_size(void __iomem
> > *base_address,
> > }
> >
> > /**
> > - * buffer_icap_mSetoffsetReg: Set the bram offset register.
> > - * @parameter base_address: contains the base address of the device.
> > - * @parameter data: is the value to be written to the data register.
> > + * buffer_icap_mSetoffsetReg - Set the bram offset register.
>
> This is the only function that is still in camel case; it should
> probably be changed also... In fact, this functions doesn't seem to be
> used at all. Can it just be removed? Are there any other unused
> functions in this driver?
>
>
> > diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
> b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
> > index 24f6aef..eddaa26 100644
> > --- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
> > +++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
>
> > @@ -344,7 +345,7 @@ int hwicap_initialize_hwicap(struct hwicap_drvdata
> > *drvdata)
> > }
> >
> > static ssize_t
> > -hwicap_read(struct file *file, char *buf, size_t count, loff_t *ppos)
> > +hwicap_read(struct file *file, __user char *buf, size_t count, loff_t
> *ppos)
>
> This looks like it should be 'char __user *buf' instead of '__user char
> *buf'.
>
>
> > {
> > struct hwicap_drvdata *drvdata = file->private_data;
> > ssize_t bytes_to_read = 0;
>
> > static ssize_t
> > -hwicap_write(struct file *file, const char *buf,
> > +hwicap_write(struct file *file, const __user char *buf,
> > size_t count, loff_t *ppos)
>
> Ditto on placement of __user
>
>
> > @@ -549,8 +556,7 @@ static int hwicap_release(struct inode *inode, struct
> file *file)
> > int i;
> > int status = 0;
> >
> > - if (down_interruptible(>sem))
> > - return -ERESTARTSYS;
> > + mutex_lock(>sem);
>
> Why not mutex_lock_interruptible()? (goes for all cases of mutex_lock())
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.25-current-git hangs on boot
On Sat, 2008-02-23 at 20:00 +0100, Oliver Pinter wrote: > the pci=nommconf kernel parameter helped it? yes indeed, this switch reliably helps to over come the hang at *this stage* (I tried booting with booth the switch and w/o). however with 50% chance I still see a hang directly after cpuidle: using governor ladder note that I've never seen these hangs on 2.6.24* ... Soeren > On 2/23/08, Soeren Sonnenburg <[EMAIL PROTECTED]> wrote: > > Hi, > > > > trying out newest git, I see a hang with > > ACPI: SSDT 7feb9c10, 02ae (r1 APPLE CPU0Ist 3000 intl 20050309) > > ACPI: SSDT 7feb9910, 02c3 (r1 APPLE CPU0Cst 3001 intl 20050309) > > ... > > ACPI: Processor [CPU0] (supports 8 throttling states) > > ACPI: SSDT 7feb9f10, 0087 (r1 APPLE CPU1Ist 3000 intl 20050309) > > ACPI: SSDT 7feb8f10, 0085 (r1 APPLE CPU1Cst 3001 intl 20050309) > > ... > > ACPI: ACPI0007:01 is registered as cooling_device1 > > ACPI: Processor [CPU1] (supports 8 throttling states) > > > > as the last message... > > > > Any ideas? > > Soeren > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] net driver fixes
From: Jeff Garzik <[EMAIL PROTECTED]> Date: Sun, 24 Feb 2008 00:48:54 -0500 > I trust you... Otherwise I wouldn't have volunteered to move my > upstream from Linus to you :) ... > So (as you saw in last email)... rebased and resend. Thanks :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [POWERPC] mpc5200: fix build error on mpc52xx_psc_spi device driver
From: Grant Likely <[EMAIL PROTECTED]>
Commit id 94f389485e27641348c1951ab8d65157122a8939 (Separate MPC52xx PSC
FIOF regsiters from the rest of PSC) split the PSC fifo registers away
from the core PSC regs. Doing so broke the mpc52xx_psc_spi driver.
This patch teaches the mpc52xx_psc_spi driver about the new PSC fifo
register definitions.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
This is a build error bug fix which needs to go into .25
---
drivers/spi/mpc52xx_psc_spi.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
index 253ed56..a86315a 100644
--- a/drivers/spi/mpc52xx_psc_spi.c
+++ b/drivers/spi/mpc52xx_psc_spi.c
@@ -42,6 +42,7 @@ struct mpc52xx_psc_spi {
/* driver internal data */
struct mpc52xx_psc __iomem *psc;
+ struct mpc52xx_psc_fifo __iomem *fifo;
unsigned int irq;
u8 bits_per_word;
u8 busy;
@@ -139,6 +140,7 @@ static int mpc52xx_psc_spi_transfer_rxtx(struct spi_device
*spi,
{
struct mpc52xx_psc_spi *mps = spi_master_get_devdata(spi->master);
struct mpc52xx_psc __iomem *psc = mps->psc;
+ struct mpc52xx_psc_fifo __iomem *fifo = mps->fifo;
unsigned rb = 0;/* number of bytes receieved */
unsigned sb = 0;/* number of bytes sent */
unsigned char *rx_buf = (unsigned char *)t->rx_buf;
@@ -190,11 +192,11 @@ static int mpc52xx_psc_spi_transfer_rxtx(struct
spi_device *spi,
out_8(>mode, 0);
} else {
out_8(>mode, MPC52xx_PSC_MODE_FFULL);
- out_be16(>rfalarm, rfalarm);
+ out_be16(>rfalarm, rfalarm);
}
out_be16(>mpc52xx_psc_imr, MPC52xx_PSC_IMR_RXRDY);
wait_for_completion(>done);
- recv_at_once = in_be16(>rfnum);
+ recv_at_once = in_be16(>rfnum);
dev_dbg(>dev, "%d bytes received\n", recv_at_once);
send_at_once = recv_at_once;
@@ -331,6 +333,7 @@ static void mpc52xx_psc_spi_cleanup(struct spi_device *spi)
static int mpc52xx_psc_spi_port_config(int psc_id, struct mpc52xx_psc_spi *mps)
{
struct mpc52xx_psc __iomem *psc = mps->psc;
+ struct mpc52xx_psc_fifo __iomem *fifo = mps->fifo;
u32 mclken_div;
int ret = 0;
@@ -346,7 +349,7 @@ static int mpc52xx_psc_spi_port_config(int psc_id, struct
mpc52xx_psc_spi *mps)
/* Disable interrupts, interrupts are based on alarm level */
out_be16(>mpc52xx_psc_imr, 0);
out_8(>command, MPC52xx_PSC_SEL_MODE_REG_1);
- out_8(>rfcntl, 0);
+ out_8(>rfcntl, 0);
out_8(>mode, MPC52xx_PSC_MODE_FFULL);
/* Configure 8bit codec mode as a SPI master and use EOF flags */
@@ -419,6 +422,8 @@ static int __init mpc52xx_psc_spi_do_probe(struct device
*dev, u32 regaddr,
ret = -EFAULT;
goto free_master;
}
+ /* On the 5200, fifo regs are immediately ajacent to the psc regs */
+ mps->fifo = ((void __iomem *)mps->psc) + sizeof(struct mpc52xx_psc);
ret = request_irq(mps->irq, mpc52xx_psc_spi_isr, 0, "mpc52xx-psc-spi",
mps);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] net driver fixes
David Miller wrote: Jeff, I really don't want to pull that tree in. Please trust me as your upstream to handle merging issues, as needed. I trust you... Otherwise I wouldn't have volunteered to move my upstream from Linus to you :) My main issues/motivations were: * quite simply, just force of habit: I'm used to basing off of a recent Linus tree, to guarantee build testing against the latest. * worry about testing against a too-old tree, where non-networking fixes may have a relevant impact on my to-be-pushed netdrvr fixes. But in this case it's fair to say there are no such issues, and it was mainly just out of habit. So (as you saw in last email)... rebased and resend. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
quad core 8 socket system will have apic id lifting.the apic id range could
be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters
and that is large than 2. So it is treated as clustered_box.
and will get
Marking TSC unstable due to TSCs unsynchronized
even the CPUs have X86_FEATURE_CONSTANT_TSC set.
this patch will check if the cpu is from AMD.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel/apic_64.c
index d8d03e0..7d8ffda 100644
--- a/arch/x86/kernel/apic_64.c
+++ b/arch/x86/kernel/apic_64.c
@@ -1180,9 +1180,19 @@ __cpuinit int apic_is_clustered_box(void)
{
int i, clusters, zeros;
unsigned id;
- u16 *bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
+ u16 *bios_cpu_apicid;
DECLARE_BITMAP(clustermap, NUM_APIC_CLUSTERS);
+ /*
+* there is not this kind of box with AMD CPU yet.
+* Some AMD box with quadcore cpu and 8 sockets apicid
+* will be [4, 0x23] or [8, 0x27] could be thought to
+* have three apic_clusters. So go out early.
+*/
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+ return 0;
+
+ bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
bitmap_zero(clustermap, NUM_APIC_CLUSTERS);
for (i = 0; i < NR_CPUS; i++) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git patches] libata fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ahci.c| 23 +--
drivers/ata/libata-core.c | 16 ++--
drivers/ata/libata-pmp.c |4 ++--
drivers/ata/libata-scsi.c |3 ++-
drivers/ata/pata_atiixp.c |4 ++--
drivers/ata/sata_fsl.c|8 +---
include/linux/ata.h |5 +
include/linux/libata.h|1 +
8 files changed, 44 insertions(+), 20 deletions(-)
Alan Cox (1):
pata_atiixp: Use 255 sector limit
Anton Vorontsov (1):
sata_fsl: fix build with ATA_VERBOSE_DEBUG
Mark Lord (1):
libata-pmp: clear hob for pmp register accesses
Pavel Machek (1):
power_state: get rid of write-only variable in SATA
Randy Dunlap (1):
libata-core: fix kernel-doc warning
Shane Huang (1):
[libata] ahci: AMD SB700/SB800 SATA support 64bit DMA
Tejun Heo (1):
libata: automatically use DMADIR if drive/bridge requires it
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 6dd12f7..1db93b6 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -85,6 +85,7 @@ enum {
board_ahci_ign_iferr= 2,
board_ahci_sb600= 3,
board_ahci_mv = 4,
+ board_ahci_sb700= 5,
/* global controller registers */
HOST_CAP= 0x00, /* host capabilities */
@@ -442,6 +443,16 @@ static const struct ata_port_info ahci_port_info[] = {
.udma_mask = ATA_UDMA6,
.port_ops = _ops,
},
+ /* board_ahci_sb700 */
+ {
+ AHCI_HFLAGS (AHCI_HFLAG_IGN_SERR_INTERNAL |
+AHCI_HFLAG_NO_PMP),
+ .flags = AHCI_FLAG_COMMON,
+ .link_flags = AHCI_LFLAG_COMMON,
+ .pio_mask = 0x1f, /* pio0-4 */
+ .udma_mask = ATA_UDMA6,
+ .port_ops = _ops,
+ },
};
static const struct pci_device_id ahci_pci_tbl[] = {
@@ -484,12 +495,12 @@ static const struct pci_device_id ahci_pci_tbl[] = {
/* ATI */
{ PCI_VDEVICE(ATI, 0x4380), board_ahci_sb600 }, /* ATI SB600 */
- { PCI_VDEVICE(ATI, 0x4390), board_ahci_sb600 }, /* ATI SB700/800 */
- { PCI_VDEVICE(ATI, 0x4391), board_ahci_sb600 }, /* ATI SB700/800 */
- { PCI_VDEVICE(ATI, 0x4392), board_ahci_sb600 }, /* ATI SB700/800 */
- { PCI_VDEVICE(ATI, 0x4393), board_ahci_sb600 }, /* ATI SB700/800 */
- { PCI_VDEVICE(ATI, 0x4394), board_ahci_sb600 }, /* ATI SB700/800 */
- { PCI_VDEVICE(ATI, 0x4395), board_ahci_sb600 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4390), board_ahci_sb700 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4391), board_ahci_sb700 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4392), board_ahci_sb700 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4393), board_ahci_sb700 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4394), board_ahci_sb700 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4395), board_ahci_sb700 }, /* ATI SB700/800 */
/* VIA */
{ PCI_VDEVICE(VIA, 0x3349), board_ahci_vt8251 }, /* VIA VT8251 */
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4cf8662..fbc2435 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -153,7 +153,7 @@ MODULE_VERSION(DRV_VERSION);
/**
* ata_force_cbl - force cable type according to libata.force
- * @link: ATA link of interest
+ * @ap: ATA port of interest
*
* Force cable type according to libata.force and whine about it.
* The last entry which has matching port number is used, so it
@@ -2396,6 +2396,7 @@ int ata_dev_configure(struct ata_device *dev)
else if (dev->class == ATA_DEV_ATAPI) {
const char *cdb_intr_string = "";
const char *atapi_an_string = "";
+ const char *dma_dir_string = "";
u32 sntf;
rc = atapi_cdb_len(id);
@@ -2436,13 +2437,19 @@ int ata_dev_configure(struct ata_device *dev)
cdb_intr_string = ", CDB intr";
}
+ if (atapi_dmadir || atapi_id_dmadir(dev->id)) {
+ dev->flags |= ATA_DFLAG_DMADIR;
+ dma_dir_string = ", DMADIR";
+ }
+
/* print device info to dmesg */
if (ata_msg_drv(ap) && print_info)
ata_dev_printk(dev, KERN_INFO,
- "ATAPI: %s, %s, max %s%s%s\n",
+ "ATAPI: %s, %s, max %s%s%s%s\n",
modelbuf, fwrevbuf,
ata_mode_string(xfer_mask),
- cdb_intr_string, atapi_an_string);
+
Re: [PATCH 1/1] [SCSI] gdth: misc cleanups, preparation for ISA/EISA hotplug API
Christoph Hellwig wrote: On Sun, Feb 24, 2008 at 12:18:23AM -0500, Jeff Garzik wrote: hm. We'll see how it plays out... on the remove side, the above is exact what happens in gdth_remove_one() without my patch, thus consolidating two cases of the same code into one. There is a less-strong argument for doing the allocation that way, but it may turn out to be useful anyway once the ISA/EISA API conversion is complete. EISA ->remove has a different prototype from PCI ->remove from ISA ->remove, so gdth_remove_one will be split up eventually. Having the scsi_host_put duplicated in each shouldn't be too much of a problem :) We'll see what the final result is... you might turn out to be right. If people want to avoid merging this patch because of this issue, that's fine. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] [SCSI] gdth: misc cleanups, preparation for ISA/EISA hotplug API
On Sun, Feb 24, 2008 at 12:18:23AM -0500, Jeff Garzik wrote: > hm. We'll see how it plays out... on the remove side, the above is > exact what happens in gdth_remove_one() without my patch, thus > consolidating two cases of the same code into one. There is a less-strong > argument for doing the allocation that way, but it may turn out to be > useful anyway once the ISA/EISA API conversion is complete. EISA ->remove has a different prototype from PCI ->remove from ISA ->remove, so gdth_remove_one will be split up eventually. Having the scsi_host_put duplicated in each shouldn't be too much of a problem :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: power_state: get rid of write-only variable in SATA
Pavel Machek wrote:
power_state is scheduled for removal, and libata uses it in write-only
mode. Remove it.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index b4985bc..a31572d 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6542,8 +6542,6 @@ int ata_host_suspend(struct ata_host *ho
ata_lpm_enable(host);
rc = ata_host_request_pm(host, mesg, 0, ATA_EHI_QUIET, 1);
- if (rc == 0)
- host->dev->power.power_state = mesg;
return rc;
}
@@ -6562,7 +6560,6 @@ void ata_host_resume(struct ata_host *ho
{
ata_host_request_pm(host, PMSG_ON, ATA_EH_SOFTRESET,
ATA_EHI_NO_AUTOPSY | ATA_EHI_QUIET, 0);
- host->dev->power.power_state = PMSG_ON;
applied
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Feb 24
Hi all, I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with allmodconfig for both powerpc and x86_64. There only one minor merge problem and a few build failures (the two in Linus' tree have been fixed and the other reported). We are up to 32 trees, more are welcome (even if they are currently empty). Status of my local build tests is at http://kisskb.ellerman.id.au/kisskb/branch/9/. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] pgpTXeXT6gJ1n.pgp Description: PGP signature
Re: [PATCH 1/1] [SCSI] gdth: misc cleanups, preparation for ISA/EISA hotplug API
Christoph Hellwig wrote:
Eventually we shoud just kill the INT_COAL ifdefed code. It has never
been enabled and clutters up the driver quite badly.
Noted (queued)... fine by me, and makes life easier.
+#ifdef CONFIG_EISA
+ if ((ha->type == GDT_EISA) && (ha->ccb_phys))
+ pci_unmap_single(ha->pdev, ha->ccb_phys, sizeof(gdth_cmd_str),
+PCI_DMA_BIDIRECTIONAL);
+#endif /* CONFIG_EISA */
I don't think moving this into the common helper makes any sense, as
it's only ever done for the eisa adapter. Just keep it local there.
+#ifdef CONFIG_EISA
+ if (ha->type == GDT_EISA) {
+ ha->ccb_phys = pci_map_single(ha->pdev, >cmdext,
+ sizeof(gdth_cmd_str), PCI_DMA_BIDIRECTIONAL);
+ if (!ha->ccb_phys)
+ goto out_free;
+ }
+#endif /* CONFIG_EISA */
Same here.
hm. We'll see how it plays out... on the remove side, the above is
exact what happens in gdth_remove_one() without my patch, thus
consolidating two cases of the same code into one. There is a
less-strong argument for doing the allocation that way, but it may turn
out to be useful anyway once the ISA/EISA API conversion is complete.
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] macb: Fix speed setting
Atsushi Nemoto wrote: Fix NCFGR.SPD setting on 10Mbps. This bug was introduced by conversion to generic PHY layer in kernel 2.6.23. Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]> --- diff --git a/drivers/net/macb.c b/drivers/net/macb.c index 81bf005..1d210ed 100644 --- a/drivers/net/macb.c +++ b/drivers/net/macb.c @@ -148,7 +148,7 @@ static void macb_handle_link_change(struct net_device *dev) if (phydev->duplex) reg |= MACB_BIT(FD); - if (phydev->speed) + if (phydev->speed == SPEED_100) reg |= MACB_BIT(SPD); applied -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2]via-rhine.c: Use-register-offset-definition-for-WOLcgClr
Laura Garcia wrote: Use register offset definition for WOLcgClr. This patch does not change the driver behaviour. Signed-off-by: Laura Garcia Liebana <[EMAIL PROTECTED]> modified: drivers/net/via-rhine.c --- drivers/net/via-rhine.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied, after making the following manual edits: - removed "modified: ..." line, that is redundant to the diffstat, and being before the "---" separator, it is included in the changelog by automated tools - removed all the silly dashes from the subject line. we want something readable, not a filename. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please, put 64-bit counter per task and incr.by.one each ctxt switch.
On Sun, 2008-02-24 at 05:08 +0100, J.C. Pizarro wrote: > One reason: for the objective of gain interactivity, it's an issue that > CFS fair scheduler lacks it. A bug report would be a much better first step toward resolution of any interactivity issues you're seeing than posts which do nothing but suggest that there may be a problem. First define the problem, _then_ fix it. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] [SCSI] gdth: misc cleanups, preparation for ISA/EISA hotplug API
On Sat, Feb 23, 2008 at 11:44:44PM -0500, Jeff Garzik wrote:
> Several misc. cleanups:
>
> - remove recently-noop'd 'reverse_scan' module parm
>
> - remove pointless function prototypes
>
> - remove ha->pccb, its value always == >cmdext
>
> - move thrice-redundant DMA memory alloc and (in EISA's case, mapping)
> into common functions gdth_ha_alloc(), gdth_ha_free()
>
> - delete pointless zero-initializations of ha struct members, as these
> are zeroed when ha is allocated (and never assigned any other value,
> prior to the explicit zero initializations)
>
> - consolidate thrice-repeated spinlock init
Good idea!
> +static void gdth_ha_free(gdth_ha_str *ha)
> +{
> + if (ha->pscratch)
> + pci_free_consistent(ha->pdev, GDTH_SCRATCH,
> + ha->pscratch, ha->scratch_phys);
> + if (ha->pmsg)
> + pci_free_consistent(ha->pdev, sizeof(gdth_msg_str),
> + ha->pmsg, ha->msg_phys);
> +
> +#ifdef INT_COAL
> + if (ha->coal_stat)
> + pci_free_consistent(ha->pdev,
> + sizeof(gdth_coal_status) * MAXOFFSETS,
> + ha->coal_stat, ha->coal_stat_phys);
> +#endif
Eventually we shoud just kill the INT_COAL ifdefed code. It has never
been enabled and clutters up the driver quite badly.
> +#ifdef CONFIG_EISA
> + if ((ha->type == GDT_EISA) && (ha->ccb_phys))
> + pci_unmap_single(ha->pdev, ha->ccb_phys, sizeof(gdth_cmd_str),
> + PCI_DMA_BIDIRECTIONAL);
> +#endif /* CONFIG_EISA */
I don't think moving this into the common helper makes any sense, as
it's only ever done for the eisa adapter. Just keep it local there.
> +#ifdef CONFIG_EISA
> + if (ha->type == GDT_EISA) {
> + ha->ccb_phys = pci_map_single(ha->pdev, >cmdext,
> + sizeof(gdth_cmd_str), PCI_DMA_BIDIRECTIONAL);
> + if (!ha->ccb_phys)
> + goto out_free;
> + }
> +#endif /* CONFIG_EISA */
Same here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
On Sun, 24 Feb 2008, David Newall wrote: > > > which talks more about what matters - too deep indentation. > > What's too deep? Is the following too deep? It would be, if it weren't artificially so, for violates several kernel coding standards, one being that the "case" labels indent with the switch, not under it (the other being the placement of braces). > (Yes, I know, "we don't indent 'case' because it consumes too much > room." No, that's not it at all. We don't indent 'case' because it matches with the 'switch', not because of any room issues. > That's inconsistent with the rest of normal indenting style, and > a poor excuse to keep within an obsolete and unnecessary restriction.) It's not at all inconsistent. It's just making clear how the parts of the function group together. Indenting a case-statement an extra level is as stupid as indenting "else" one extra level from the "if ()" it goes together with. Do you think that would be sane? The fact that the 'case' thing is technically parsed as a separate statement in C doesn't change anything. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] [SCSI] gdth: misc cleanups, preparation for ISA/EISA hotplug API
Several misc. cleanups:
- remove recently-noop'd 'reverse_scan' module parm
- remove pointless function prototypes
- remove ha->pccb, its value always == >cmdext
- move thrice-redundant DMA memory alloc and (in EISA's case, mapping)
into common functions gdth_ha_alloc(), gdth_ha_free()
- delete pointless zero-initializations of ha struct members, as these
are zeroed when ha is allocated (and never assigned any other value,
prior to the explicit zero initializations)
- consolidate thrice-repeated spinlock init
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
---
NOTE: Applies on top of my previous two gdth patches (PCI hotplug prep,
PCI hotplug convert).
drivers/scsi/gdth.c | 299 ++
drivers/scsi/gdth.h |1 -
2 files changed, 108 insertions(+), 192 deletions(-)
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index ad9aff2..b17eb15 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -51,8 +51,6 @@
* reserve_list:h,b,t,l,h,b,t,l,... reserve particular drive(s) with
* h- controller no., b- channel no.,
* t- target ID, l- LUN
- * reverse_scan:Y reverse scan order for PCI controllers
- * reverse_scan:N scan PCI controllers like BIOS
* max_ids:xx - target ID count per channel (1..MAXID)
* rescan:Y rescan all channels/IDs
* rescan:N use all devices found until now
@@ -66,7 +64,7 @@
* force_dma32:Yuse only 32 bit DMA mode
* force_dma32:Nuse 64 bit DMA mode, if supported
*
- * The default values are: "gdth=disable:N,reserve_mode:1,reverse_scan:N,
+ * The default values are: "gdth=disable:N,reserve_mode:1,
* max_ids:127,rescan:N,hdr_channel:0,
* shared_access:Y,probe_eisa_isa:N,force_dma32:N".
* Here is another example: "gdth=reserve_list:0,1,2,0,0,1,3,0,rescan:Y".
@@ -77,7 +75,7 @@
* with ' ' and all ':' with '=' and you must use
* '1' in place of 'Y' and '0' in place of 'N'.
*
- * Default: "modprobe gdth disable=0 reserve_mode=1 reverse_scan=0
+ * Default: "modprobe gdth disable=0 reserve_mode=1
* max_ids=127 rescan=0 hdr_channel=0 shared_access=0
* probe_eisa_isa=0 force_dma32=0"
* The other example: "modprobe gdth reserve_list=0,1,2,0,0,1,3,0 rescan=1".
@@ -148,29 +146,13 @@ static int gdth_sync_event(gdth_ha_str *ha, int service,
unchar index,
static int gdth_async_event(gdth_ha_str *ha);
static void gdth_log_event(gdth_evt_data *dvr, char *buffer);
-static void gdth_putq(gdth_ha_str *ha, Scsi_Cmnd *scp, unchar priority);
-static void gdth_next(gdth_ha_str *ha);
static int gdth_fill_raw_cmd(gdth_ha_str *ha, Scsi_Cmnd *scp, unchar b);
static int gdth_special_cmd(gdth_ha_str *ha, Scsi_Cmnd *scp);
-static gdth_evt_str *gdth_store_event(gdth_ha_str *ha, ushort source,
- ushort idx, gdth_evt_data *evt);
static int gdth_read_event(gdth_ha_str *ha, int handle, gdth_evt_str *estr);
-static void gdth_readapp_event(gdth_ha_str *ha, unchar application,
- gdth_evt_str *estr);
-static void gdth_clear_events(void);
-static void gdth_copy_internal_data(gdth_ha_str *ha, Scsi_Cmnd *scp,
-char *buffer, ushort count, int to_buffer);
static int gdth_internal_cache_cmd(gdth_ha_str *ha, Scsi_Cmnd *scp);
static int gdth_fill_cache_cmd(gdth_ha_str *ha, Scsi_Cmnd *scp, ushort hdrive);
-static void gdth_enable_int(gdth_ha_str *ha);
-static int gdth_test_busy(gdth_ha_str *ha);
-static int gdth_get_cmd_index(gdth_ha_str *ha);
-static void gdth_release_event(gdth_ha_str *ha);
-static int gdth_wait(gdth_ha_str *ha, int index,ulong32 time);
-static int gdth_internal_cmd(gdth_ha_str *ha, unchar service, ushort opcode,
- ulong32 p1, ulong64 p2,ulong64
p3);
static int gdth_search_drives(gdth_ha_str *ha);
static int gdth_analyse_hdrive(gdth_ha_str *ha, ushort hdrive);
@@ -181,7 +163,6 @@ static int gdth_close(struct inode *inode, struct file
*filep);
static int gdth_ioctl(struct inode *inode, struct file *filep,
unsigned int cmd, unsigned long arg);
-static void gdth_flush(gdth_ha_str *ha);
static int gdth_halt(struct notifier_block *nb, ulong event, void *buf);
static int gdth_queuecommand(Scsi_Cmnd *scp,void (*done)(Scsi_Cmnd *));
static int __gdth_queuecommand(gdth_ha_str *ha, struct scsi_cmnd *scp,
@@ -336,8 +317,6 @@ static int reserve_list[MAX_RES_ARGS] =
{0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff};
-/* scan order for PCI controllers */
-static int reverse_scan = 0;
/* virtual channel for the host drives
Re: [PATCH] scsi/mvsas.c needs to include linux/ctype.h fo isalnum
On Sat, 23 Feb 2008 22:39:11 -0600 James Bottomley <[EMAIL PROTECTED]> wrote: > > In future, it would be nice if you could send SCSI patches to the SCSI > list: [EMAIL PROTECTED] Sure thing. > But actually, a more complete version of this one is already upstream as > commit 0a3716eb04ccfdbef6e872a343ba7ce309237e79 Excellent. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] pgpcEXXoaps70.pgp Description: PGP signature
Re: [PATCH] scsi/mvsas.c needs to include linux/ctype.h fo isalnum
On Sun, 2008-02-24 at 15:27 +1100, Stephen Rothwell wrote: > Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> > --- > drivers/scsi/mvsas.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > Discovered while compiling Linus' tree in preparation for today's linux-next. > > diff --git a/drivers/scsi/mvsas.c b/drivers/scsi/mvsas.c > index 30e20e6..de762f4 100755 > --- a/drivers/scsi/mvsas.c > +++ b/drivers/scsi/mvsas.c > @@ -35,6 +35,7 @@ > #include > #include > #include > +#include In future, it would be nice if you could send SCSI patches to the SCSI list: [EMAIL PROTECTED] But actually, a more complete version of this one is already upstream as commit 0a3716eb04ccfdbef6e872a343ba7ce309237e79 James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Lguest] lguest breaks i386 allmodconfig
On Sat, Feb 23, 2008 at 11:32:35PM -0500, Jeff Garzik wrote: > The following > > make ARCH=i386 allmodconfig && \ > make ARCH=i386 -sj5 > > on x86-64 produces the following build breakage at the post-build stage: > > [...] > Root device is (9, 0) > Setup is 12504 bytes (padded to 12800 bytes). > System is 1883 kB > Kernel: arch/x86/boot/bzImage is ready (#2) > ERROR: "LGUEST_PAGES_guest_gdt_desc" [drivers/lguest/lg.ko] undefined! > ERROR: "LGUEST_PAGES_host_gdt_desc" [drivers/lguest/lg.ko] undefined! > ERROR: "LGUEST_PAGES_host_cr3" [drivers/lguest/lg.ko] undefined! > ERROR: "LGUEST_PAGES_regs" [drivers/lguest/lg.ko] undefined! > ERROR: "LGUEST_PAGES_host_idt_desc" [drivers/lguest/lg.ko] undefined! > ERROR: "LGUEST_PAGES_guest_gdt" [drivers/lguest/lg.ko] undefined! > ERROR: "LGUEST_PAGES_host_sp" [drivers/lguest/lg.ko] undefined! > ERROR: "LGUEST_PAGES_regs_trapnum" [drivers/lguest/lg.ko] undefined! > ERROR: "LGUEST_PAGES_guest_idt_desc" [drivers/lguest/lg.ko] undefined! > [...] I suspect that the various patches in this thread (http://marc.info/?t=12033930202) will fix this problem. It's a matter of which on Linus takes, and when. Yours Tony linux.conf.auhttp://www.marchsouth.org/ Jan 19 - 24 2009 The Australian Linux Technical Conference! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Linus Torvalds wrote:
> On Sat, 23 Feb 2008, David Newall wrote:
>
>> Do you actually get 80 columns wide on it?
>>
>
> Do people really care that deeply?
> ...
> And do I find lines longer than 80 charactes unreadable? Hell no.
>
I care, yes. I've found my code looks much prettier, with attendant
improvement in ease of understanding, since I stopped being so anal
about 80 columns. The width of the code, that is first to last
non-blank on each line, is about the same, not because I work to keep
it narrow, but because most statements just are narrow. Sometimes I do
get really wide statements, for example when using deep data structures,
especially as parameters in procedure calls, and this is easier to read
than having to break the line.
I honestly think the reason we used to insist on lines less than 80
characters was because on an 80 character screen, you get slightly
better readability by choosing where to break each line than simply
letting the hardware do it. We don't have the physical limit any more,
so we don't need to impose it structurally.
It's about readability, and with due respect, people who've never tried
it aren't qualified to comment.
> which talks more about what matters - too deep indentation.
What's too deep? Is the following too deep? It's common enough, other
than my refusal to relax consistent indenting style for switch bodies.
The code is readable, and breaking it into multiple procedures just to
de-indent is often impossible, and rarely readable. With a strict 80
character limit, the meat in the sandwich is left with only 20 or so
characters in which to fit. Add a nested switch, and there's virtually
no space left for code.
123456789012345678901234567890123456789012345678901234567890123456 (70)
int procedure(param list)
{
switch (condition)
{
case value:
if (another_condition)
{
if (variant)
meat_in_sandwich;
} else {
code;
}
case value2:
switch (sub_condition)
{
case sub_value:
if (final_test)
{
something(
NULL,
1,
"two");
}
}
}
}
(Yes, I know, "we don't indent 'case' because it consumes too much
room." That's inconsistent with the rest of normal indenting style, and
a poor excuse to keep within an obsolete and unnecessary restriction.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Hang on suspend
On Sat, 2008-02-23 at 21:43 +0100, Rafael J. Wysocki wrote:
> Can you please apply the appened patch and retest?
Didn't apply cleanly to v2.6.25-rc2; I had to mangle one or two lines.
The patch I applied follows at the end of this message.
Unfortunately, it's about the same as before. I got:
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
ACPI: Preparing to enter system sleep state S3
sd 0:0:0:0: [sda] Synchronizing SCSI cache
sd 0:0:0:0: [sda] Stopping disk
nsc-ircc 00:0b: disabled
parport_pc 00:0a: disabled
eth1: Going into suspend...
ACPI: PCI interrupt for device :0b:02.0 disabled
ACPI: PCI interrupt for device :00:1e.3 disabled
ACPI: PCI interrupt for device :00:1e.2 disabled
ACPI: PCI interrupt for device :00:1d.7 disabled
ACPI: PCI interrupt for device :00:1d.3 disabled
ACPI: PCI interrupt for device :00:1d.2 disabled
ACPI: PCI interrupt for device :00:1d.1 disabled
ACPI: PCI interrupt for device :00:1d.0 disabled
BUG: unable to handle kernel NULL pointer dereference at 0090
And the oops and stacktrace that follows appears essentially identical
to the one I already transcribed. If you need it copied, I've got
photographs, but I'd like to save myself the typing...
Those PCI devices, in case it matters, are:
0b:02.0 Wireless card (Intel 2200BG)
00:1e.3 Modem (ICH6 AC'97)
00:1e.2 Audio (ICH6 AC'97)
00:1e.0 82801 Mobile PCI Bridge
00:1d.7 USB2 EHCI
00:1d.3 USB UHCI
00:1d.2 USB UHCI
00:1d.1 USB UHCI
00:1d.0 USB UHCI
The other devices not mentioned are:
0b:00.0 CardBus Bridge: Ricoh Co Ltd RL5c476 II (rev 8d)
02:00.0 Ethernet (Broadcom BCM5751M)
01:00.0 ATI Mobility FireGL V3200
00:1f.3 SMBus (ICH6)
00:1f.2 ICH6M SATA
00:1f.0 ICH6M LPC Interface Bridge
00:1c.2 ICH6 PCI Express Port 3
00:1c.0 ICH6 PCI Express Port 1
00:01.0 915GM/PM PCI Express Root Port
00:00.0 Processor to DRAM Controller
> Thanks,
> Rafael
Thanks for the help!
--
-Julian Blake Kongslie
<[EMAIL PROTECTED]>
If this is a mailing list, please CC me on replies.
vim: set ft=text :
Here's the patch against v2.6.25-rc2 I used:
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index bdc03f7..e3095c7 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -48,7 +48,6 @@
*/
LIST_HEAD(dpm_active);
-static LIST_HEAD(dpm_locked);
static LIST_HEAD(dpm_off);
static LIST_HEAD(dpm_off_irq);
static LIST_HEAD(dpm_destroy);
@@ -81,28 +80,6 @@ void device_pm_add(struct device *dev)
*/
void device_pm_remove(struct device *dev)
{
- /*
-* If this function is called during a suspend, it will be blocked,
-* because we're holding the device's semaphore at that time, which may
-* lead to a deadlock. In that case we want to print a warning.
-* However, it may also be called by unregister_dropped_devices() with
-* the device's semaphore released, in which case the warning should
-* not be printed.
-*/
- if (down_trylock(>sem)) {
- if (down_read_trylock(_sleep_rwsem)) {
- /* No suspend in progress, wait on dev->sem */
- down(>sem);
- up_read(_sleep_rwsem);
- } else {
- /* Suspend in progress, we may deadlock */
- dev_warn(dev, "Suspicious %s during suspend\n",
- __FUNCTION__);
- dump_stack();
- /* The user has been warned ... */
- down(>sem);
- }
- }
pr_debug("PM: Removing info for %s:%s\n",
dev->bus ? dev->bus->name : "No Bus",
kobject_name(>kobj));
@@ -110,7 +87,6 @@ void device_pm_remove(struct device *dev)
dpm_sysfs_remove(dev);
list_del_init(>power.entry);
mutex_unlock(_list_mtx);
- up(>sem);
}
/**
@@ -266,7 +242,7 @@ static void dpm_resume(void)
struct list_head *entry = dpm_off.next;
struct device *dev = to_device(entry);
- list_move_tail(entry, _locked);
+ list_move_tail(entry, _active);
mutex_unlock(_list_mtx);
resume_device(dev);
mutex_lock(_list_mtx);
@@ -275,25 +251,6 @@ static void dpm_resume(void)
}
/**
- * unlock_all_devices - Release each device's semaphore
- *
- * Go through the dpm_off list. Put each device on the dpm_active
- * list and unlock it.
- */
-static void unlock_all_devices(void)
-{
- mutex_lock(_list_mtx);
- while (!list_empty(_locked)) {
- struct list_head *entry = dpm_locked.prev;
- struct device *dev = to_device(entry);
-
- list_move(entry,
lguest breaks i386 allmodconfig
The following make ARCH=i386 allmodconfig && \ make ARCH=i386 -sj5 on x86-64 produces the following build breakage at the post-build stage: [...] Root device is (9, 0) Setup is 12504 bytes (padded to 12800 bytes). System is 1883 kB Kernel: arch/x86/boot/bzImage is ready (#2) ERROR: "LGUEST_PAGES_guest_gdt_desc" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_host_gdt_desc" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_host_cr3" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_regs" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_host_idt_desc" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_guest_gdt" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_host_sp" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_regs_trapnum" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_guest_idt_desc" [drivers/lguest/lg.ko] undefined! [...] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Jan Engelhardt wrote:
> static void blah(void)
> {
> if (foo) {
> bar;
> bar2;
> return;
> }
> if (this) {
> that;
> that2;
> return;
> }
> /* yay, got rid of two levels of indent! */
> good day;
> good day2;
> }
I like this style. It's more readable than the alternative that you
showed. If you hate returns mid-procedure, as some purists do, the
following is also good:
static void blah(void)
{
if (foo) {
bar;
bar2;
} else if (this) {
that;
that2;
} else {
good day;
good day2;
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] scsi/mvsas.c needs to include linux/ctype.h fo isalnum
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> --- drivers/scsi/mvsas.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Discovered while compiling Linus' tree in preparation for today's linux-next. diff --git a/drivers/scsi/mvsas.c b/drivers/scsi/mvsas.c index 30e20e6..de762f4 100755 --- a/drivers/scsi/mvsas.c +++ b/drivers/scsi/mvsas.c @@ -35,6 +35,7 @@ #include #include #include +#include #include #include -- 1.5.4.2 -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [Bug 10030] Suspend doesn't work when SD card is inserted
On Sat, 23 Feb 2008, Alan Stern wrote:
> It happened in a workqueue. There could be lots of similar cases: Some
> interrupt-driven event causes a hotplug action. Since the action can't
> be carried out in interrupt context, the driver has no choice but to
> defer it to a workqueue or kernel thread. Blocking that workqueue or
> kernel thread won't cause a problem _unless_ the driver's
> suspend/resume methods try to synchronize with it. That's the
> difficult case.
In fact this turns out to be exactly the problem with the MMC
subsystem. It uses a dedicated workqueue (kmmcd) to handle state
changes, and mmc_suspend_host() does a flush_workqueue(). If the
workqueue contains an entry to register or unregister a device, this is
guaranteed to deadlock -- and that's exactly what happens when Zdenek
inserts or removes a card during the disk-drive spindown time of a
system sleep.
It looks like the best solution is for mmc_suspend_host() not to flush
the workqueue; instead the workqueue should prevent itself from
running during a suspend. Right now the easiest way to accomplish this
is for the workqueue routines (mmc_detect() and siblings) to acquire
the mmc_host's device semaphore. If in the future the MMC subsystem
adds dynamic PM support then a more complicated arrangement will be
needed.
So the patch below, in combination with the previous patch, might just
fix the whole problem.
Alan Stern
Index: usb-2.6/drivers/mmc/core/core.c
===
--- usb-2.6.orig/drivers/mmc/core/core.c
+++ usb-2.6/drivers/mmc/core/core.c
@@ -731,8 +731,6 @@ void mmc_stop_host(struct mmc_host *host
*/
int mmc_suspend_host(struct mmc_host *host, pm_message_t state)
{
- mmc_flush_scheduled_work();
-
mmc_bus_get(host);
if (host->bus_ops && !host->bus_dead) {
if (host->bus_ops->suspend)
Index: usb-2.6/drivers/mmc/core/mmc.c
===
--- usb-2.6.orig/drivers/mmc/core/mmc.c
+++ usb-2.6/drivers/mmc/core/mmc.c
@@ -441,6 +441,7 @@ static void mmc_detect(struct mmc_host *
BUG_ON(!host);
BUG_ON(!host->card);
+ down(_classdev(host)->sem);
mmc_claim_host(host);
/*
@@ -449,6 +450,7 @@ static void mmc_detect(struct mmc_host *
err = mmc_send_status(host->card, NULL);
mmc_release_host(host);
+ up(_classdev(host)->sem);
if (err) {
mmc_remove(host);
Index: usb-2.6/drivers/mmc/core/sd.c
===
--- usb-2.6.orig/drivers/mmc/core/sd.c
+++ usb-2.6/drivers/mmc/core/sd.c
@@ -500,6 +500,7 @@ static void mmc_sd_detect(struct mmc_hos
BUG_ON(!host);
BUG_ON(!host->card);
+ down(_classdev(host)->sem);
mmc_claim_host(host);
/*
@@ -508,6 +509,7 @@ static void mmc_sd_detect(struct mmc_hos
err = mmc_send_status(host->card, NULL);
mmc_release_host(host);
+ up(_classdev(host)->sem);
if (err) {
mmc_sd_remove(host);
Index: usb-2.6/drivers/mmc/core/sdio.c
===
--- usb-2.6.orig/drivers/mmc/core/sdio.c
+++ usb-2.6/drivers/mmc/core/sdio.c
@@ -195,6 +195,7 @@ static void mmc_sdio_detect(struct mmc_h
BUG_ON(!host);
BUG_ON(!host->card);
+ down(_classdev(host)->sem);
mmc_claim_host(host);
/*
@@ -203,6 +204,7 @@ static void mmc_sdio_detect(struct mmc_h
err = mmc_select_card(host->card);
mmc_release_host(host);
+ up(_classdev(host)->sem);
if (err) {
mmc_sdio_remove(host);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Please, put 64-bit counter per task and incr.by.one each ctxt switch.
On Sun, 24 Feb 2008 05:08:46 +0100 "J.C. Pizarro" <[EMAIL PROTECTED]> wrote: OK, one last reply on the (overly optimistic?) assumption that you are not a troll. > +++ linux-2.6_git-20080224/include/linux/sched.h2008-02-24 > 04:50:18.0 +0100 > @@ -1007,6 +1007,12 @@ > struct hlist_head preempt_notifiers; > #endif > > + unsigned long long ctxt_switch_counts; /* 64-bit switches' count */ > + /* ToDo: > +* To implement a poller/clock for CPU-scheduler that only reads > +* these counts of context switches of the runqueue's tasks. > +* No problem if this poller/clock is not implemented. */ So you're introducing a statistic, but have not yet written any code that uses it? > + p->ctxt_switch_counts = 0ULL; /* task's 64-bit counter inited 0 */ Because we can all read C, there is no need to tell people in comments what the code does. Comments are there to explain why the code does things, if an explanation is needed. > > > I will explain your later why of it. > > > > > > ... and explain exactly why the kernel needs this extra code. > > One reason: for the objective of gain interactivity, it's an issue that > CFS fair scheduler lacks it. Your patch does not actually help interactivity, because all it does is add an irq spinlock in a hot path (bad idea) and a counter which nothing reads. -- All rights reversed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging of completely unreviewed drivers
Pavel Machek wrote: > On Sat 2008-02-23 23:08:58, David Newall wrote: > >> Pavel Machek wrote: >> >>> On Fri 2008-02-22 23:44:09, Krzysztof Halasa wrote: >>> >>> Pavel Machek <[EMAIL PROTECTED]> writes: > Zaurus is one example, second is small screen where you need big font > to keep it readable (x60 on desk). > > Come on, are you doing Linux kernel development on PDA? > > Actually, I'd like to. There's a lot to fix on zaurus. Bit corruption > while sleeping is high on list, but I guess I should move out of > 2.6.16, first. > > >>> I review patches on it, sometimes, yes. >>> >>> >> Do you actually get 80 columns wide on it? >> > > No, something like 62... but it is usually enough. x60 is about 100 > columns wide (big font needed). Then it's a silly example to raise in a serious discussion of this type. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM: Introduce PM_EVENT_HIBERNATE (was: Re: i915 hibernation patch (was: Re: 2.6.25-rc2 System no longer ...))
On Sa, 2008-02-23 at 19:13 +0100, Rafael J. Wysocki wrote:
> Index: linux-2.6/drivers/usb/host/u132-hcd.c
> ===
> --- linux-2.6.orig/drivers/usb/host/u132-hcd.c
> +++ linux-2.6/drivers/usb/host/u132-hcd.c
> @@ -3214,14 +3214,19 @@ static int u132_suspend(struct platform_
> return -ESHUTDOWN;
> } else {
> int retval = 0;
> -if (state.event == PM_EVENT_FREEZE) {
> +
> + switch (state.event) {
> + case PM_EVENT_FREEZE:
> retval = u132_bus_suspend(hcd);
> -} else if (state.event == PM_EVENT_SUSPEND) {
> + break;
> + case PM_EVENT_SUSPEND:
> + case PM_EVENT_HIBERNATE:
> int ports = MAX_U132_PORTS;
> while (ports-- > 0) {
> port_power(u132, ports, 0);
> }
> -}
> + break;
> + }
> if (retval == 0)
> pdev->dev.power.power_state = state;
> return retval;
Hmm. Doesn't compile for me in 2.6.25-rc2-git7:
CC [M] drivers/usb/host/u132-hcd.o
drivers/usb/host/u132-hcd.c: In function ‘u132_suspend’:
drivers/usb/host/u132-hcd.c:3224: error: expected expression before
‘int’
drivers/usb/host/u132-hcd.c:3225: error: ‘ports’ undeclared (first use
in this function)
drivers/usb/host/u132-hcd.c:3225: error: (Each undeclared identifier is
reported only once
drivers/usb/host/u132-hcd.c:3225: error: for each function it appears
in.)
make[3]: *** [drivers/usb/host/u132-hcd.o] Error 1
make[2]: *** [drivers/usb/host] Error 2
make[1]: *** [drivers/usb] Error 2
make: *** [drivers] Error 2
This fixes it:
Thanks
Mirco
---
From: Mirco Tischler <[EMAIL PROTECTED]>
Fixes the following compile error caused by commit
3a2d5b700132f35401f1d9e22fe3c2cab02c2549
...
CC [M] drivers/usb/host/u132-hcd.o
drivers/usb/host/u132-hcd.c: In function ‘u132_suspend’:
drivers/usb/host/u132-hcd.c:3224: error: expected expression before
‘int’
drivers/usb/host/u132-hcd.c:3225: error: ‘ports’ undeclared (first use
in this function)
...
Signed-off-by: Mirco Tischler <[EMAIL PROTECTED]>
---
drivers/usb/host/u132-hcd.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/u132-hcd.c b/drivers/usb/host/u132-hcd.c
index 6fca069..58830b2 100644
--- a/drivers/usb/host/u132-hcd.c
+++ b/drivers/usb/host/u132-hcd.c
@@ -3214,6 +3214,7 @@ static int u132_suspend(struct platform_device
*pdev, pm_message_t state)
return -ESHUTDOWN;
} else {
int retval = 0;
+ int ports = 0;
switch (state.event) {
case PM_EVENT_FREEZE:
@@ -3221,7 +3222,7 @@ static int u132_suspend(struct platform_device
*pdev, pm_message_t state)
break;
case PM_EVENT_SUSPEND:
case PM_EVENT_HIBERNATE:
-int ports = MAX_U132_PORTS;
+ ports = MAX_U132_PORTS;
while (ports-- > 0) {
port_power(u132, ports, 0);
}
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 00/16] (Resend) Use get_personality()
From: Andrew Morton <[EMAIL PROTECTED]> Subject: Re: [PATCH 00/16] (Resend) Use get_personality() Date: Sat, 23 Feb 2008 11:16:29 -0800 Message-ID: <[EMAIL PROTECTED]> > On Sat, 23 Feb 2008 13:37:31 -0500 Christoph Hellwig <[EMAIL PROTECTED]> > wrote: > > > On Sat, Feb 23, 2008 at 12:27:10PM +0300, Alexey Dobriyan wrote: > > > > Use get_personality() can hide the task_struct internals a bit. > > > > > > ->personality is going to become something less trivial? > > > Sorry, but you sound like C++ people writing tons of pointless get/set > > > wrappers. And your get_personality() is worse -- C++ would write it as > > > > > > current->personality() > > > > > > and again, even here, it's immediately visible that current task is > > > involved, not some other task. > > > > Yes, completely agreement. While I might have introduced this gem > > back then it is entirely stupid if you think about it. Please send > > patches to kill get_personality and just use current->personality > > instead. > > > > yup. > > We'll generally only add wrappers of this form if we need to provide > alternative implementations, or if we expect that we shall do so in the > future. > Ok. I will send a patch to remove 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: Please, put 64-bit counter per task and incr.by.one each ctxt switch.
On 2008/2/24, Rik van Riel <[EMAIL PROTECTED]> wrote:
> On Sun, 24 Feb 2008 04:08:38 +0100
> "J.C. Pizarro" <[EMAIL PROTECTED]> wrote:
>
> > We will need 64 bit counters of the slow context switches,
> > one counter for each new created task (e.g. u64 ctxt_switch_counts;)
>
>
> Please send a patch ...
diff -ur linux-2.6_git-20080224.orig/include/linux/sched.h
linux-2.6_git-20080224/include/linux/sched.h
--- linux-2.6_git-20080224.orig/include/linux/sched.h 2008-02-24
01:04:18.0 +0100
+++ linux-2.6_git-20080224/include/linux/sched.h2008-02-24
04:50:18.0 +0100
@@ -1007,6 +1007,12 @@
struct hlist_head preempt_notifiers;
#endif
+ unsigned long long ctxt_switch_counts; /* 64-bit switches' count */
+ /* ToDo:
+* To implement a poller/clock for CPU-scheduler that only reads
+* these counts of context switches of the runqueue's tasks.
+* No problem if this poller/clock is not implemented. */
+
/*
* fpu_counter contains the number of consecutive context switches
* that the FPU is used. If this is over a threshold, the lazy fpu
diff -ur linux-2.6_git-20080224.orig/kernel/sched.c
linux-2.6_git-20080224/kernel/sched.c
--- linux-2.6_git-20080224.orig/kernel/sched.c 2008-02-24
01:04:19.0 +0100
+++ linux-2.6_git-20080224/kernel/sched.c 2008-02-24
04:33:57.0 +0100
@@ -2008,6 +2008,8 @@
BUG_ON(p->state != TASK_RUNNING);
update_rq_clock(rq);
+ p->ctxt_switch_counts = 0ULL; /* task's 64-bit counter inited 0 */
+
p->prio = effective_prio(p);
if (!p->sched_class->task_new || !current->se.on_rq) {
@@ -2189,8 +2191,14 @@
context_switch(struct rq *rq, struct task_struct *prev,
struct task_struct *next)
{
+ unsigned long flags;
+ struct rq *rq_prev;
struct mm_struct *mm, *oldmm;
+ rq_prev = task_rq_lock(prev, ); /* locking the prev task */
+ prev->ctxt_switch_counts++; /* incr.+1 the task's 64-bit counter */
+ task_rq_unlock(rq_prev, ); /* unlocking the prev task */
+
prepare_task_switch(rq, prev, next);
mm = next->mm;
oldmm = prev->active_mm;
> > I will explain your later why of it.
>
>
> ... and explain exactly why the kernel needs this extra code.
One reason: for the objective of gain interactivity, it's an issue that
CFS fair scheduler lacks it.
o:)
linux-2.6_git-20080224_ctxt_switch_counts.patch
Description: Binary data
Re: Tiny cpusets -- cpusets for small systems?
Hi Paul,
> A couple of proposals have been made recently by people working Linux
> on smaller systems, for improving realtime isolation and memory
> pressure handling:
>
> (1) cpu isolation for hard(er) realtime
> http://lkml.org/lkml/2008/2/21/517
> Max Krasnyanskiy <[EMAIL PROTECTED]>
> [PATCH sched-devel 0/7] CPU isolation extensions
>
> (2) notify user space of tight memory
> http://lkml.org/lkml/2008/2/9/144
> KOSAKI Motohiro <[EMAIL PROTECTED]>
> [PATCH 0/8][for -mm] mem_notify v6
>
> In both cases, some of us have responded "why not use cpusets", and the
> original submitters have replied "cpusets are too fat" (well, they
> were more diplomatic than that, but I guess I can say that ;)
My primary issue with cpusets (from CPU isolation perspective that is) was
not the fatness. I did make a couple of comments like "On dual-cpu box
I do not need cpusets to manage the CPUs" but that's not directly related to
the CPU isolation.
For the CPU isolation in particular I need code like this
int select_irq_affinity(unsigned int irq)
{
cpumask_t usable_cpus;
cpus_andnot(usable_cpus, cpu_online_map, cpu_isolated_map);
irq_desc[irq].affinity = usable_cpus;
irq_desc[irq].chip->set_affinity(irq, usable_cpus);
return 0;
}
How would you implement that with cpusets ?
I haven't seen you patches but I'd imagine that they will still need locks and
iterators for "Is CPU N isolated" functionality.
So. I see cpusets as a higher level API/mechanism and cpu_isolated_map as lower
level mechanism that actually makes kernel aware of what's isolated what's not.
Kind of like sched domain/cpuset relationship. ie cpusets affect sched domains
but scheduler does not use cpusets directly.
> I wonder if there might be room for a "tiny cpusets" configuration option:
> * provide the same hooks to the rest of the kernel, and
> * provide the same syntactic interface to user space, but
> * with more limited semantics.
>
> The primary semantic limit I'd suggest would be supporting exactly
> one layer depth of cpusets, not a full hierarchy. So one could still
> successfully issue from user space 'mkdir /dev/cpuset/foo', but trying
> to do 'mkdir /dev/cpuset/foo/bar' would fail. This reminds me of
> very early FAT file systems, which had just a single, fixed size
> root directory ;). There might even be a configurable fixed upper
> limit on how many /dev/cpuset/* directories were allowed, further
> simplifying the locking and dynamic memory behavior of this apparatus.
In a foreseeable future 2-8 cores will be most common configuration.
Do you think that cpusets are needed/useful for those machines ?
The reason I'm asking is because given the restrictions you mentioned
above it seems that you might as well just do
taskset -c 1,2,3 app1
taskset -c 3,4,5 app2
Yes it's not quite the same of course but imo covers most cases. That's what we
do on 2-4 cores these days, and are quite happy with that. ie We either let the
specialized apps manage their thread affinities themselves or use "taskset" to
manage the apps.
> User space would see the same API, except that some valid operations
> on full cpusets, such as a nested mkdir, would fail on tiny cpusets.
Speaking of user-space API. I guess it's not directly related to the
tiny-cpusets
proposal but rather to the cpusets in general.
Stuff that I'm working on this days (wireless basestations) is designed with
the
following model:
cpuN - runs soft-RT networking and management code
cpuN+1 to cpuN+x - are used as dedicated engines
ie Simplest example would be
cpu0 - runs IP, L2 and control plane
cpu1 - runs hard-RT MAC
So if CPU isolation is implemented on top of the cpusets what kind of API do
you envision for such an app ? I mean currently cpusets seems to be mostly
dealing
with entire processes, whereas in this case we're really dealing with the
threads.
ie Different threads of the same process require different policies, some must
run
on isolated cpus some must not. I guess one could write a thread's pid into
cpusets
fs but that's not very convenient. pthread_set_affinity() is exactly what's
needed.
Personally I do not see much use for cpusets for those kinds of designs. But
maybe
I missing something. I got really excited when cpusets where first merged into
mainline but after looking closer I could not really find a use for them, at
least
for not for our apps.
Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.25 patch] fix drivers/usb/host/u132-hcd.c compilation
This patch fixes the following compile error caused by
commit 3a2d5b700132f35401f1d9e22fe3c2cab02c2549:
<-- snip -->
...
CC drivers/usb/host/u132-hcd.o
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/usb/host/u132-hcd.c:
In function ‘u132_suspend’:
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/usb/host/u132-hcd.c:3224:
error: expected expression before ‘int’
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/usb/host/u132-hcd.c:3225:
error: ‘ports’ undeclared (first use in this function)
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/usb/host/u132-hcd.c:3225:
error: (Each undeclared identifier is reported only once
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/usb/host/u132-hcd.c:3225:
error: for each function it appears in.)
make[4]: *** [drivers/usb/host/u132-hcd.o] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
69cf78da6371ad2aca30844858eeea318b37b3ec diff --git
a/drivers/usb/host/u132-hcd.c b/drivers/usb/host/u132-hcd.c
index 6fca069..325c6c7 100644
--- a/drivers/usb/host/u132-hcd.c
+++ b/drivers/usb/host/u132-hcd.c
@@ -3221,9 +3221,11 @@ static int u132_suspend(struct platform_device *pdev,
pm_message_t state)
break;
case PM_EVENT_SUSPEND:
case PM_EVENT_HIBERNATE:
-int ports = MAX_U132_PORTS;
-while (ports-- > 0) {
-port_power(u132, ports, 0);
+ {
+ int ports = MAX_U132_PORTS;
+ while (ports-- > 0) {
+ port_power(u132, ports, 0);
+ }
}
break;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 10030] Suspend doesn't work when SD card is inserted
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> On Sunday, 24 of February 2008, Alan Stern wrote:
> > On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> >
> > > Ultimately no, it's not. However, we are now late in the -rc2 time frame
> > > and
> > > the release of -rc3 seems to be imminent. At this point, IMO, that's the
> > > safest thing to do. BTW, appended is the patch I'd like to get applied.
> >
> > In the interest of having a safe release, I guess you're right.
>
> That's what I'm concerned about at the moment. I'm afraid there won't be
> enough time to nail down all the issues (there may be some we're not even
> aware of).
All right. You'll need to enlarge your big reversal patch by reverting
commit 4145ed6dc597a9bea5f6ae8c574653b2de10620f.
> > Below is my suggested approach, based on yours. It might even solve
> > the MMC problem, who knows? And it adds some potentially useful
> > debugging, although it would be better to dump just the stack of
> > suspending_task. Do you know how to do that from within a timer
> > routine?
>
> No, I don't.
On further checking the answer turns out to be sched_show_task().
That's the routine which gets called for each process when you type
Alt-SysRq-t.
> > I still have no clear idea about what's going on with the ACPI bug in
> > #9874.
>
> It seems that the ACPI code is not prepared to cope with a failing device
> registration, in which case it'd need fixing. Frankly, I'm afraid there may
> be more issues like this throughout the tree.
The fact remains that it is unsafe to register a device during a sleep
transition, although if the device's driver doesn't have a suspend or
resume method you can probably get away with it.
> > However perhaps the bug wouldn't occur if we blocked device
> > registration until after the resume was finished, instead of failing it
> > outright. Since the registration in this case was done in a workqueue
> > thread, blocking wouldn't cause an immediate deadlock.
>
> No, it wouldn't, but the fact that it happens in the ACPI code makes me worry.
It happened in a workqueue. There could be lots of similar cases: Some
interrupt-driven event causes a hotplug action. Since the action can't
be carried out in interrupt context, the driver has no choice but to
defer it to a workqueue or kernel thread. Blocking that workqueue or
kernel thread won't cause a problem _unless_ the driver's
suspend/resume methods try to synchronize with it. That's the
difficult case.
> If we block that code and the things it's supposed to do turn out to be
> necessary for suspending later on, we'll be in trouble.
Exactly.
> > @@ -94,14 +102,15 @@ void device_pm_remove(struct device *dev
> > /* No suspend in progress, wait on dev->sem */
> > down(>sem);
> > up_read(_sleep_rwsem);
> > - } else {
> > - /* Suspend in progress, we may deadlock */
> > + } else if (!in_suspend_context()) {
> > + /* Suspending in another task, we may deadlock */
>
> Well, that shouldn't really deadlock. If it does, there is a potential design
> issue somewhere. I think it might be better to set up a timer in here too.
At this point the driver core owns the device semaphore, so the
unregistration task will block until the sleep is over. If the
driver's resume method has to synchronize with the unregistration task
then it will deadlock. I agree, it would be a design issue. In fact,
it's the same design issue described earlier in this email.
> Although IMO it would be even better to just set up a timer and remove the
> warning altogehter.
That warning was just for debugging purposes. A timer in the resume
path could do the same thing with fewer false alarms, just like the
timer in the suspend path. I have added it to the new patch.
> > dev_warn(dev, "Suspicious %s during suspend\n",
> > __FUNCTION__);
> > dump_stack();
> > /* The user has been warned ... */
> > down(>sem);
> > }
> > + /* Otherwise we're okay */
> > }
> > pr_debug("PM: Removing info for %s:%s\n",
> > dev->bus ? dev->bus->name : "No Bus",
>
> There's a problem here, because we shouldn't release the semaphore if we're
> in the suspend context.
Yes, you're right. It's fixed in the new version.
> > +static void suspend_timeout(unsigned long _dev)
> > +{
> > + struct device *dev = (struct device *) _dev;
> > +
> > + dev_err(dev, "deadlock during suspend!\n");
> > + show_state();
>
> The show_state() seems to be overkill and won't really help if the user can't
> collect the output on the fly using a serial console or something like this.
> [The debug stuff printed here should fit a typical laptop screen, ideally.]
Changed.
> I'd prefer
>
> if (in_suspend_context()) {
>
Re: Please, put 64-bit counter per task and incr.by.one each ctxt switch.
On Sun, 24 Feb 2008 04:08:38 +0100 "J.C. Pizarro" <[EMAIL PROTECTED]> wrote: > We will need 64 bit counters of the slow context switches, > one counter for each new created task (e.g. u64 ctxt_switch_counts;) Please send a patch ... > I will explain your later why of it. ... and explain exactly why the kernel needs this extra code. Asking somebody else to add functionality (or is it bloat? we really cannot tell) to the kernel for you, and not even explaining why is not going to convince anyone. For more hints on how to get functionality into the Linux kernel, please read: http://kernelnewbies.org/UpstreamMerge -- All rights reversed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add the debugfs interface for the sysprof tool
On Sun, 2008-02-24 at 04:49 +0200, Pekka Enberg wrote: > Hi Andrew, > > Andrew Morton wrote: > > I didn't need to write a new kernel module to enable that > > thirteen-character shell script, and I don't believe one needs to write a > > new kernel module to put a nice easy-to-use GUI around oprofile either. > > > > This is one of those i-cant-believe-im-having-this-discussion discussions. > > Sysprof tracks the full stack frame so it can provide meaningful call > tree (who called what) which is invaluable for spotting hot _paths_. I > don't see how oprofile can do that as it tracks instruction pointers only. > > Pekka You could try passing the --callgraph option to opcontrol. -- Nicholas Miell <[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/
Please, put 64-bit counter per task and incr.by.one each ctxt switch.
Hello,
We will need 64 bit counters of the slow context switches,
one counter for each new created task (e.g. u64 ctxt_switch_counts;)
We will only need them during the lifetime of the tasks.
To increment by +1 the task's 64 bit counter (it's fast)
each one slow context switch.
*kernel/sched.c:
void context_switch(...) { ... } # incr. +1 here.
void wake_up_new_task(...) { ... } # ->ctxt_switch_counts = 0ULL;
*include/linux/sched.h:
struct task_struct { ... } # add 64-bit (u64 ctxt_switch_counts;) here.
Please, do it and we can do it better than CFS fair scheduler.
I will explain your later why of it.
O:)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/2] x86,fpu: lazy allocation of FPU area
On Sat, Feb 23, 2008 at 06:34:39PM -0800, Suresh Siddha wrote:
> + if (!tsk->thread.cntxt)
> +tsk->thread.cntxt = alloc_cntxt_struct();
Please use tabs, not spaces for indentation.
> +union thread_cntxt *alloc_cntxt_struct(void)
> +{
> + return kmem_cache_alloc(task_cntxt_cachep, GFP_KERNEL);
> +}
Why do you need this wrapper at all?
> +struct task_struct * alloc_task_struct(struct task_struct *src)
> {
> struct task_struct *tsk;
> tsk = kmem_cache_alloc(task_struct_cachep, GFP_KERNEL);
> + if (tsk && src->thread.cntxt) {
> + tsk->thread.cntxt = alloc_cntxt_struct();
> + if (!tsk->thread.cntxt) {
> + kmem_cache_free(task_struct_cachep, tsk);
> + return NULL;
> + }
> + WARN_ON((unsigned long)tsk->thread.cntxt & 15);
> + } else if (tsk)
> + tsk->thread.cntxt = NULL;
> return tsk;
I think passing the src here doesn't make much sense. Copying
the fpu context structure should be done by the arch dup_task_struct
hook. Now if you free the fpu context in free_thread_info that means
you don't have to have your own arch-specific task_struct allocator
which would be a _lot_ cleaner. Talking about clean I think
the .cntxt field really wants a more descriptive name :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ResCounter: Use read_uint in memory controller
On Sat, Feb 23, 2008 at 6:47 PM, Balbir Singh <[EMAIL PROTECTED]> wrote: > >> res_counter_read_u64() I'd also want to rename all the other > >> *read_uint functions/fields to *read_u64 too. Can I do that in a > >> separate patch? > >> > > > > Sounds sensible to me. > > > > Sure, fair enough. > Actually, since multiple people were asking for this change I did the search/replace and sent it out already (as a precursor of the other patches in the series that I sent today). 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 1/2] x86,fpu: split FPU state from task struct
On Sat, Feb 23, 2008 at 06:34:38PM -0800, Suresh Siddha wrote:
> Split the FPU save area from the task struct. This allows easy migration
> of FPU context, and it's generally cleaner. It also allows the following
> two optimizations:
>
> 1) only allocate when the application actually uses FPU, so in the first
> lazy FPU trap. This could save memory for non-fpu using apps. Next patch
> does this lazy allocation.
>
> 2) allocate the right size for the actual cpu rather than 512 bytes always.
> Patches enabling xsave/xrstor support (coming shortly) will take advantage
> of this.
This sounds like a wonderful idea. But I'm a little unhappy with
some of the rather cosmetic things in this patch:
> if (next_p->fpu_counter>5)
> - prefetch(>i387.fxsave);
> + prefetch(FXSAVE(next_p));
These macros are rather ugly. If you really want them please
a) make them inlines and lowercase with a descriptive name
b) introduce them in a separate patch before the first real
path in the series.
> +++ linux-2.6-x86/kernel/fork.c 2008-02-23 15:08:53.0 -0800
> @@ -87,6 +87,7 @@
> #ifndef __HAVE_ARCH_TASK_STRUCT_ALLOCATOR
> # define alloc_task_struct() kmem_cache_alloc(task_struct_cachep, GFP_KERNEL)
> # define free_task_struct(tsk) kmem_cache_free(task_struct_cachep,
> (tsk))
> +# define memcpy_task_struct(dst, src) do { *dst = *src; } while (0)
> static struct kmem_cache *task_struct_cachep;
> #endif
>
> @@ -142,6 +143,8 @@
> task_struct_cachep =
> kmem_cache_create("task_struct", sizeof(struct task_struct),
> ARCH_MIN_TASKALIGN, SLAB_PANIC, NULL);
> +#else
> + task_struct_slab_init();
> #endif
>
> /*
> @@ -181,7 +184,8 @@
> return NULL;
> }
>
> - *tsk = *orig;
> + memcpy_task_struct(tsk, orig);
I think this is a bad name for this helper, arch_dup_task_struct
would be more descriptive.
But we actually have an arch hook for this kind of thing called
setup_thread_stack which is used by ia64 and m68k just a few lines
later, so it'd be better to look into having a single hook.
(And possibly rename it to arch_dup_task_struct because the name
is a lot more descriptive)
setup_thread_stack
> + memset(FSAVE(tsk), 0, math_cntxt_size);
> + FSAVE(tsk)->cwd = 0x037fu;
> + FSAVE(tsk)->swd = 0xu;
> + FSAVE(tsk)->twd = 0xu;
> + FSAVE(tsk)->fos = 0xu;
Also if you reference the save area so often it'd be better to just
have a local variable for it. Much better readable.
> +struct task_struct * alloc_task_struct(void)
this should be struct task_struct *alloc_task_struct(void)
> +void free_task_struct(struct task_struct *tsk)
> +{
> + kmem_cache_free(task_cntxt_cachep, tsk->thread.cntxt);
> + tsk->thread.cntxt=NULL;
missing spaces around the '='
> -#define I387 (current->thread.i387)
> -#define FPU_info (I387.soft.info)
> +#define I387 (current->thread.cntxt)
> +#define FPU_info (I387->soft.info)
> +#define SOFT(t) (&(t->thread.cntxt->soft))
This is quite butt ugly. But then again it's fpemu, so there's
probably no point touching it until a bored janitor comes around.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Gabriel C wrote: Laurent Riffard wrote: Le 16.02.2008 09:25, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/ [..] I'm getting that in mainline now on one of my older laptops also. we fixed the cause of the machine you quoted; so I suspect yours is different.. Can you get me your stacktrace ? Can you try the patch from this thread to show what memory the offender tries to access ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ResCounter: Use read_uint in memory controller
Andrew Morton wrote: > On Sat, 23 Feb 2008 06:33:34 -0800 "Paul Menage" <[EMAIL PROTECTED]> wrote: > >> On Thu, Feb 21, 2008 at 8:29 PM, Balbir Singh <[EMAIL PROTECTED]> wrote: >>> Looks good, except for the name uint(), can we make it u64(). Integers are >>> 32 >>> bit on both ILP32 and LP64, but we really read/write 64 bit values. >> Yes, that's true. But read_uint() is more consistent with all the >> other instances in cgroups and subsystems. So if we were to call it >> res_counter_read_u64() I'd also want to rename all the other >> *read_uint functions/fields to *read_u64 too. Can I do that in a >> separate patch? >> > > Sounds sensible to me. > Sure, fair enough. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add the debugfs interface for the sysprof tool
Hi Andrew, Andrew Morton wrote: I didn't need to write a new kernel module to enable that thirteen-character shell script, and I don't believe one needs to write a new kernel module to put a nice easy-to-use GUI around oprofile either. This is one of those i-cant-believe-im-having-this-discussion discussions. Sysprof tracks the full stack frame so it can provide meaningful call tree (who called what) which is invaluable for spotting hot _paths_. I don't see how oprofile can do that as it tracks instruction pointers only. Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/2] x86,fpu: split FPU state from task struct
Split the FPU save area from the task struct. This allows easy migration
of FPU context, and it's generally cleaner. It also allows the following
two optimizations:
1) only allocate when the application actually uses FPU, so in the first
lazy FPU trap. This could save memory for non-fpu using apps. Next patch
does this lazy allocation.
2) allocate the right size for the actual cpu rather than 512 bytes always.
Patches enabling xsave/xrstor support (coming shortly) will take advantage
of this.
Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
Index: linux-2.6-x86/arch/x86/kernel/process_64.c
===
--- linux-2.6-x86.orig/arch/x86/kernel/process_64.c 2008-02-22
18:33:17.0 -0800
+++ linux-2.6-x86/arch/x86/kernel/process_64.c 2008-02-23 15:04:30.0
-0800
@@ -630,7 +630,7 @@
/* we're going to use this soon, after a few expensive things */
if (next_p->fpu_counter>5)
- prefetch(>i387.fxsave);
+ prefetch(FXSAVE(next_p));
/*
* Reload esp0, LDT and the page table pointer:
Index: linux-2.6-x86/arch/x86/kernel/traps_64.c
===
--- linux-2.6-x86.orig/arch/x86/kernel/traps_64.c 2008-02-22
18:33:17.0 -0800
+++ linux-2.6-x86/arch/x86/kernel/traps_64.c2008-02-23 15:04:30.0
-0800
@@ -1118,7 +1118,7 @@
if (!used_math())
init_fpu(me);
- restore_fpu_checking(>thread.i387.fxsave);
+ restore_fpu_checking(FXSAVE(me));
task_thread_info(me)->status |= TS_USEDFPU;
me->fpu_counter++;
}
@@ -1154,6 +1154,10 @@
#endif
/*
+* initialize the per thread FP context:
+*/
+init_thread_context();
+ /*
* Should be a barrier for any external CPU state.
*/
cpu_init();
Index: linux-2.6-x86/kernel/fork.c
===
--- linux-2.6-x86.orig/kernel/fork.c2008-02-23 15:03:35.0 -0800
+++ linux-2.6-x86/kernel/fork.c 2008-02-23 15:08:53.0 -0800
@@ -87,6 +87,7 @@
#ifndef __HAVE_ARCH_TASK_STRUCT_ALLOCATOR
# define alloc_task_struct() kmem_cache_alloc(task_struct_cachep, GFP_KERNEL)
# define free_task_struct(tsk) kmem_cache_free(task_struct_cachep, (tsk))
+# define memcpy_task_struct(dst, src) do { *dst = *src; } while (0)
static struct kmem_cache *task_struct_cachep;
#endif
@@ -142,6 +143,8 @@
task_struct_cachep =
kmem_cache_create("task_struct", sizeof(struct task_struct),
ARCH_MIN_TASKALIGN, SLAB_PANIC, NULL);
+#else
+ task_struct_slab_init();
#endif
/*
@@ -181,7 +184,8 @@
return NULL;
}
- *tsk = *orig;
+ memcpy_task_struct(tsk, orig);
+
tsk->stack = ti;
err = prop_local_init_single(>dirties);
Index: linux-2.6-x86/arch/x86/kernel/i387.c
===
--- linux-2.6-x86.orig/arch/x86/kernel/i387.c 2008-02-23 15:03:35.0
-0800
+++ linux-2.6-x86/arch/x86/kernel/i387.c2008-02-23 15:08:53.0
-0800
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -40,16 +41,17 @@
#endif
static unsigned int mxcsr_feature_mask __read_mostly = 0xu;
+unsigned int math_cntxt_size;
+static struct i387_fxsave_struct fx_scratch __cpuinitdata;
-void mxcsr_feature_mask_init(void)
+void __cpuinit mxcsr_feature_mask_init(void)
{
unsigned long mask = 0;
clts();
if (cpu_has_fxsr) {
- memset(>thread.i387.fxsave, 0,
- sizeof(struct i387_fxsave_struct));
- asm volatile("fxsave %0" : : "m" (current->thread.i387.fxsave));
- mask = current->thread.i387.fxsave.mxcsr_mask;
+ memset(_scratch, 0, sizeof(struct i387_fxsave_struct));
+ asm volatile("fxsave %0" : : "m" (fx_scratch));
+ mask = fx_scratch.mxcsr_mask;
if (mask == 0)
mask = 0xffbf;
}
@@ -57,6 +59,17 @@
stts();
}
+void __init init_thread_context(void)
+{
+ if (cpu_has_fxsr)
+ math_cntxt_size = sizeof(struct i387_fxsave_struct);
+#ifdef CONFIG_X86_32
+ else
+ math_cntxt_size = sizeof(struct i387_fsave_struct);
+#endif
+ init_task.thread.cntxt = alloc_bootmem(math_cntxt_size);
+}
+
#ifdef CONFIG_X86_64
/*
* Called at bootup to set up the initial FPU state that is later cloned
@@ -65,10 +78,7 @@
void __cpuinit fpu_init(void)
{
unsigned long oldcr0 = read_cr0();
- extern void __bad_fxsave_alignment(void);
- if (offsetof(struct task_struct, thread.i387.fxsave) & 15)
- __bad_fxsave_alignment();
[patch 2/2] x86,fpu: lazy allocation of FPU area
Only allocate the FPU area when the application actually uses FPU, i.e., in the
first lazy FPU trap. This could save memory for non-fpu using apps.
Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
Cc: Arjan van de Ven <[EMAIL PROTECTED]>
---
Index: linux-2.6-x86/arch/x86/kernel/i387.c
===
--- linux-2.6-x86.orig/arch/x86/kernel/i387.c 2008-02-23 18:27:40.0
-0800
+++ linux-2.6-x86/arch/x86/kernel/i387.c2008-02-23 18:27:41.0
-0800
@@ -9,7 +9,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -67,7 +66,6 @@
else
math_cntxt_size = sizeof(struct i387_fsave_struct);
#endif
- init_task.thread.cntxt = alloc_bootmem(math_cntxt_size);
}
#ifdef CONFIG_X86_64
@@ -105,6 +103,9 @@
return;
}
+ if (!tsk->thread.cntxt)
+tsk->thread.cntxt = alloc_cntxt_struct();
+
if (cpu_has_fxsr) {
memset(FXSAVE(tsk), 0, math_cntxt_size);
FXSAVE(tsk)->cwd = 0x37f;
Index: linux-2.6-x86/arch/x86/kernel/process.c
===
--- linux-2.6-x86.orig/arch/x86/kernel/process.c2008-02-23
18:27:40.0 -0800
+++ linux-2.6-x86/arch/x86/kernel/process.c 2008-02-23 18:27:49.0
-0800
@@ -8,21 +8,25 @@
static struct kmem_cache *task_struct_cachep;
static struct kmem_cache *task_cntxt_cachep;
-struct task_struct * alloc_task_struct(void)
+union thread_cntxt *alloc_cntxt_struct(void)
+{
+ return kmem_cache_alloc(task_cntxt_cachep, GFP_KERNEL);
+}
+
+struct task_struct * alloc_task_struct(struct task_struct *src)
{
struct task_struct *tsk;
tsk = kmem_cache_alloc(task_struct_cachep, GFP_KERNEL);
- if (!tsk)
- return NULL;
- tsk->thread.cntxt = kmem_cache_alloc(task_cntxt_cachep, GFP_KERNEL);
- if (!tsk->thread.cntxt)
- goto error;
- WARN_ON((unsigned long)tsk->thread.cntxt & 15);
+ if (tsk && src->thread.cntxt) {
+ tsk->thread.cntxt = alloc_cntxt_struct();
+ if (!tsk->thread.cntxt) {
+ kmem_cache_free(task_struct_cachep, tsk);
+ return NULL;
+ }
+ WARN_ON((unsigned long)tsk->thread.cntxt & 15);
+ } else if (tsk)
+ tsk->thread.cntxt = NULL;
return tsk;
-
-error:
- kmem_cache_free(task_struct_cachep, tsk);
- return NULL;
}
void memcpy_task_struct(struct task_struct *dst, struct task_struct *src)
@@ -31,13 +35,21 @@
ptr = dst->thread.cntxt;
*dst = *src;
dst->thread.cntxt = ptr;
- memcpy(dst->thread.cntxt, src->thread.cntxt, math_cntxt_size);
+ if (src->thread.cntxt)
+ memcpy(dst->thread.cntxt, src->thread.cntxt, math_cntxt_size);
+}
+
+void free_cntxt_struct(struct task_struct *tsk)
+{
+ if (tsk->thread.cntxt) {
+ kmem_cache_free(task_cntxt_cachep, tsk->thread.cntxt);
+ tsk->thread.cntxt = NULL;
+ }
}
void free_task_struct(struct task_struct *tsk)
{
- kmem_cache_free(task_cntxt_cachep, tsk->thread.cntxt);
- tsk->thread.cntxt=NULL;
+ free_cntxt_struct(tsk);
kmem_cache_free(task_struct_cachep, tsk);
}
Index: linux-2.6-x86/include/asm-x86/i387.h
===
--- linux-2.6-x86.orig/include/asm-x86/i387.h 2008-02-23 18:27:40.0
-0800
+++ linux-2.6-x86/include/asm-x86/i387.h2008-02-23 18:27:41.0
-0800
@@ -25,6 +25,7 @@
extern asmlinkage void math_state_restore(void);
extern void init_thread_context(void);
extern unsigned int math_cntxt_size;
+extern union thread_cntxt *alloc_cntxt_struct(void);
extern user_regset_active_fn fpregs_active, xfpregs_active;
extern user_regset_get_fn fpregs_get, xfpregs_get, fpregs_soft_get;
Index: linux-2.6-x86/include/asm-x86/processor.h
===
--- linux-2.6-x86.orig/include/asm-x86/processor.h 2008-02-23
18:27:40.0 -0800
+++ linux-2.6-x86/include/asm-x86/processor.h 2008-02-23 18:27:41.0
-0800
@@ -743,6 +743,8 @@
.io_bitmap = { [0 ... IO_BITMAP_LONGS] = ~0 }, \
}
+extern void free_cntxt_struct(struct task_struct *);
+
#define start_thread(regs, new_eip, new_esp) do { \
__asm__("movl %0,%%gs": :"r" (0)); \
regs->fs = 0; \
@@ -753,6 +755,7 @@
regs->cs = __USER_CS; \
regs->ip = new_eip; \
regs->sp = new_esp; \
+ free_cntxt_struct(current); \
} while (0)
Index: linux-2.6-x86/include/asm-x86/thread_info.h
Re: dma engine drivers for 2.6.25?
On Thu, Feb 14, 2008 at 10:29 PM, Dan Williams <[EMAIL PROTECTED]> wrote: > On Thu, Feb 14, 2008 at 8:44 PM, Kumar Gala <[EMAIL PROTECTED]> wrote: > > > > On Feb 14, 2008, at 12:14 PM, Dan Williams wrote: > > > > > On Wed, Feb 13, 2008 at 8:52 PM, Kumar Gala > > > <[EMAIL PROTECTED]> wrote: > > >> Dan, > > >> > > >> What's going on with the dma engine drivers for 2.6.25? We had a > > >> Freescale dma driver from Zhang Wei queued up but seems to have been > > >> lost. > > > > > > I pulled it into my tree and am holding it until Zhang has an > > > opportunity to address the pending review comments [1]. I also did > > > not feel comfortable pushing it to Linus without a PPC maintainer's > > > Acked-by/Reviewed-by. > > > > > > I have attached the version I am carrying. > > > > What issues are still open. I was under the belief that Zhang had > > resolved all the issues. > > > > The high priority review item is that the driver performs operation > completion callbacks in hardirq context. Clients of the API assume > that callbacks will happen in softirq context. Of lesser concern is > the use of GFP_ATOMIC in fsl_dma_alloc_descriptor. Other drivers > preallocate a small pool of descriptors. > Have not received a response, so let's try this the other way. I took a closer look and found that my concern should be addressed by the following one-liner: diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index 902e852..cc9a681 100644 --- a/drivers/dma/fsldma.c +++ b/drivers/dma/fsldma.c @@ -685,7 +685,6 @@ static irqreturn_t fsl_dma_chan_do_interrupt(int irq, void *data) "nlndar 0x%016llx\n", (u64)get_cdar(fsl_chan), (u64)get_ndar(fsl_chan)); stat &= ~FSL_DMA_SR_EOSI; - fsl_chan_ld_cleanup(fsl_chan); } /* If it current transfer is the end-of-transfer, With your ack I'll push the driver plus this fixlet for the current kernel. Regards, Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.24.2: 4KSTACKS + PCA403CD IDE CD + pcdrw + mount + PREEMPT -> stack overflow
A loop mount/umounting a pcdrw or iso9660 (through the pktcdvd device) sees a stack overflow in four or five tries. Doing the same thing with the same CD in a normal non-pktcdvd-mounted drive doesn't cause a crash. Here's a couple of oopses. config follows. (There are a wide variety. Some I couldn't collect because they appeared to recurse, blurring past much too fast to read. Some simply didn't go out of the netconsole logger at all for no obvious reason.) (This may or may not be PREEMPT+PREEMPT_BKL-specific: I'll try turning them off tomorrow and repeating.) (The presence of dm in the first oops below must surely be attributed to preempt: certainly my CD isn't managed by dm :) ) pktcdvd: Fixed packets, 32 blocks, Mode-2 disc pktcdvd: Max. media speed: 4 pktcdvd: write speed 2x pktcdvd: 551232kB available on disc UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2004/02/09 07:10 (1000) do_IRQ: stack overflow: 480 Pid: 4645, comm: mount Not tainted 2.6.24.2-dirty #4 [] do_IRQ+0x66/0xc5 [] common_interrupt+0x23/0x28 [] ide_outsl+0x5/0x9 [] ata_output_data+0x4d/0x64 [] atapi_output_bytes+0x19/0x3f [] cdrom_transfer_packet_command+0xb5/0xde [] cdrom_timer_expiry+0x0/0x51 [] cdrom_start_packet_command+0x14f/0x157 [] cdrom_do_pc_continuation+0x0/0x2c [] ide_do_request+0x70a/0x943 [] schedule_timeout+0x13/0x8b [] elv_drain_elevator+0x15/0x58 [] elv_insert+0xf6/0x1d9 [] cdrom_transfer_packet_command+0xb5/0xde [] cdrom_timer_expiry+0x0/0x51 [] ide_do_drive_cmd+0x99/0xe9 [] cdrom_queue_packet_command+0x35/0xa9 [] schedule+0x321/0x33e [] schedule_timeout+0x13/0x8b [] cdrom_read_tocentry+0x96/0xa1 [] blk_end_sync_rq+0x0/0x23 [] cdrom_read_toc+0x14b/0x42e [] blk_end_sync_rq+0x0/0x23 [] ide_do_drive_cmd+0xdf/0xe9 [] ide_cdrom_audio_ioctl+0x13c/0x1de [] dm_bio_destructor+0x0/0x8 [] end_bio_bh_io_sync+0x0/0x27 [] cdrom_check_status+0x55/0x60 [] blk_end_sync_rq+0x0/0x23 [] cdrom_count_tracks+0x64/0x16a [] clone_endio+0x0/0xa3 [] dm_bio_destructor+0x0/0x8 [] cdrom_open+0x190/0x8f8 [] end_bio_bh_io_sync+0x0/0x27 [] bio_fs_destructor+0x0/0xb [] end_bio_bh_io_sync+0x0/0x27 [] bio_fs_destructor+0x0/0xb [] clone_endio+0x0/0xa3 [] dm_bio_destructor+0x0/0x8 [] end_bio_bh_io_sync+0x0/0x27 [] bio_fs_destructor+0x0/0xb [] clone_endio+0x0/0xa3 [] dm_bio_destructor+0x0/0x8 [] get_disk+0x4e/0x65 [] exact_lock+0x7/0xd [] kobj_lookup+0x104/0x12e [] idecd_open+0x72/0x86 [] do_open+0x198/0x238 [] clone_endio+0x0/0xa3 [] __blkdev_get+0x69/0x74 [] blkdev_get+0x12/0x14 [] pkt_open+0x8d/0xc96 [] end_bio_bh_io_sync+0x0/0x27 [] bio_fs_destructor+0x0/0xb [] clone_endio+0x0/0xa3 [] dm_bio_destructor+0x0/0x8 [] clone_endio+0x0/0xa3 [] dm_bio_destructor+0x0/0x8 [] end_bio_bh_io_sync+0x0/0x27 [] bio_fs_destructor+0x0/0xb [] end_bio_bh_io_sync+0x0/0x27 [] bio_fs_destructor+0x0/0xb [] end_bio_bh_io_sync+0x0/0x27 [] bio_fs_destructor+0x0/0xb [] end_bio_bh_io_sync+0x0/0x27 [] bio_fs_destructor+0x0/0xb [] clone_endio+0x0/0xa3 [] dm_bio_destructor+0x0/0x8 [] kobject_get+0xf/0x13 [] get_disk+0x4e/0x65 [] exact_lock+0x7/0xd [] kobj_lookup+0x104/0x12e [] exact_match+0x0/0x4 [] do_open+0x84/0x238 [] EIP: 0060:[] EFLAGS: 00010093 CPU: 0 EIP is at dump_trace+0x52/0x8b EAX: 082a EBX: 0046 ECX: 020a EDX: ESI: EDI: EBP: 0ffc ESP: eeede1c4 DS: 007b ES: 007b FS: GS: 0033 SS: 0068 rocess mount (pid: 4645, ti=eeede000 task=ee537320 task.ti=eeede000)v] show_trace_log_lvl+0x18/0x2c [] show_trace+0xf/0x11 [] dump_stack+0x68/0x6d [] do_IRQ+0x66/0xc5 [] common_interrupt+0x23/0x28 [] ide_outsl+0x5/0x9 [] ata_output_data+0x4d/0x64 [] atapi_output_bytes+0x19/0x3f [] cdrom_transfer_packet_command+0xb5/0xde [] cdrom_timer_expiry+0x0/0x51 [] cdrom_start_packet_command+0x14f/0x157 [] cdrom_do_pc_continuation+0x0/0x2c [] ide_do_request+0x70a/0x943 [] schedule_timeout+0x13/0x8b [] elv_drain_elevator+0x15/0x58 [] elv_insert+0xf6/0x1d9 [] cdrom_transfer_packet_command+0xb5/0xde [] cdrom_timer_expiry+0x0/0x51 [] ide_do_drive_cmd+0x99/0xe9 [] cdrom_queue_packet_command+0x35/0xa9 [] schedule+0x321/0x33e [] schedule_timeout+0x13/0x8b [] cdrom_read_tocentry+0x96/0xa1 [] blk_end_sync_rq+0x0/0x23 [] cdrom_read_toc+0x14b/0x42e [] blk_end_sync_rq+0x0/0x23 [] ide_do_drive_cmd+0xdf/0xe9 [] ide_cdrom_audio_ioctl+0x13c/0x1de [] dm_bio_destructor+0x0/0x8 [] end_bio_bh_io_sync+0x0/0x27 [] cdrom_check_status+0x55/0x60 [] blk_end_sync_rq+0x0/0x23 [] cdrom_count_tracks+0x64/0x16a [] clone_endio+0x0/0xa3 [] dm_bio_destructor+0x0/0x8 [] cdrom_open+0x190/0x8f8 [] end_bio_bh_io_sync+0x0/0x27 [] bio_fs_destructor+0x0/0xb [] end_bio_bh_io_sync+0x0/0x27 [] bio_fs_destructor+0x0/0xb [] clone_endio+0x0/0xa3 [] dm_bio_destructor+0x0/0x8 [] end_bio_bh_io_sync+0x0/0x27 [] bio_fs_destructor+0x0/0xb [] clone_endio+0x0/0xa3 [] dm_bio_destructor+0x0/0x8 [] get_disk+0x4e/0x65 [] exact_lock+0x7/0xd []
Re: [PATCH] Use userland-like functions for reading the ACPI table
On Sat, Feb 23, 2008 at 12:45:38PM -0800, Linus Torvalds wrote:
> >
> > As recommended by Christoph Hellwig, even if we can't rely on the userspace
> > firmware loader so early at boot, at least use normal syscall (as in
> > init/do_mounts_*.c). Similarly, use kfree() instead of ACPI_FREE().
>
> So I'm missing a lot of the background here.
>
> I don't think "sys_open()" is in any way preferable to the alternatives,
> especially since it depends on thread-global state (the file descriptor
> table) rather than much more local state ("struct file" that you've
> opened).
>
> I think the calls to sys_open() in init do_dounts etc are very different:
> they really are more about a real kernel-level almost-user-mode thread
> than a core driver.
Well, that's what this code is like aswell. That's why I recommended
to Eric to move it to init/ and make it look like that code. I haven't
quite caught up with the discussion yet, but Eric think moving it
there might not be a that good idea. Having this code in drivers/
even if it's just called in init time is a bad idea, as people will
copy it. Then again using the functions the code was using before
isn't any better.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] atmel_spi: Fix clock polarity
On Sat, 23 Feb 2008 00:05:07 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > I had it queued for 2.6.26 which I guess was wrong. I'll bump it into > 2.6.25. Thanks! > Is it needed in 2.6.24.x? I think so. The last time that code was changed was before 2.6.23 AFAICT, so perhaps 2.6.23.x as well. I'll have a closer look and pass it on to the stable team when it hits mainline. Haavard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] snd-hda-intel
On Wed, Feb 13, 2008 at 03:31:31PM +0100, Takashi Iwai wrote: > At Wed, 13 Feb 2008 15:25:14 +0100, > Peter Zijlstra wrote: > > > > lspci -vvv: > > > > 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio > > Controller (rev 02) > > Is this a regression, i.e. did you get similar Oops with previous > kernels? This looks like .. http://www.kerneloops.org/guilty.php?guilty=azx_pcm_prepare=2.6.25-rc2=1638912=1639167=oops kerneloops.org claims to have 2 oopses from 2.6.24 there too, but when clicked, they show nothing. Arjan ? Dave -- http://www.codemonkey.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] macb: Fix speed setting
On Sat, 23 Feb 2008 00:03:23 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Thu, 21 Feb 2008 17:41:05 +0100 Haavard Skinnemoen <[EMAIL PROTECTED]> > wrote: > > > From: Atsushi Nemoto <[EMAIL PROTECTED]> > > > > Fix NCFGR.SPD setting on 10Mbps. This bug was introduced by > > conversion to generic PHY layer in kernel 2.6.23. > > So.. shouldn't we fix it in 2.6.23.x and 2.6.24.x? Absolutely. I'll send it to the stable team after it hits mainline. Haavard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Tabs, spaces, indent and 80 character lines
Good evening In the thread "Merging of completely unreviewed drivers" I got reminded of the "use tabs not spaces"-mentality. My question is: why? The tab-character serves us well as a indent-indicator, but for some reason there has been focus on its relation to spaces. On the question "How long should a line at maximum be?" it is relevant (the question is not [1]). So it is set to be as wide as 8 spaces, but when did it become a replacement for 8 spaces? Why hinder a developer who prefer 2, 4, 6 or any other != 8 width? By only using tabs as indents, and changing the CodeStyle to be something like "maximum 80 characters-wide lines, with a tab-setting of 8 spaces", that is possible + easier to write code-checkers [2]. Or are we really that concerned about the disk-space? ;) 2 cents away... /Richard Knutsson [1] As has been pointed out by many, it is the complexity that matters (code-checker). A short line can be overly complicated and still under 80 lines and vice versa. Let the editors handle the long lines for the author (even I should be able to write a decent script who can decide where to chop-off the line). [2] As it is now, it can look like the indentation is ex. ... 2, 2, 5, 3, 3... because the second line is split up. (I think it should have been 2, 2, 2, 3, 3 (or even better: 2, 2, 3, 3 )) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
boot_delay broken ?
The boot_delay switch seems to be behaving strangely in the current -git. Setting it to =10 makes the output 'bursty' it becomes slow for some printk's whilst others scroll by at regular speed. Setting it any higher than that seems to make it pause for a really long time before it outputs any text at all. x86 timer changes perhaps ? Dave -- http://www.codemonkey.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Laurent Riffard wrote:
> Le 16.02.2008 09:25, Andrew Morton a écrit :
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
>
> Got this in dmesg output:
>
> [ cut here ]
> WARNING: at arch/x86/mm/ioremap.c:129 __ioremap+0xc7/0x182()
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 2.6.25-rc2-mm1 #40
> [] warn_on_slowpath+0x41/0x6d
> [] ? trace_hardirqs_on+0xb/0xd
> [] ? acpi_os_release_object+0x8/0xc
> [] ? acpi_ut_delete_object_desc+0x39/0x3e
> [] ? acpi_ut_delete_internal_obj+0x2c1/0x2c9
> [] ? trace_hardirqs_on+0xb/0xd
> [] ? trace_hardirqs_on_caller+0xdf/0x100
> [] ? trace_hardirqs_on+0xb/0xd
> [] __ioremap+0xc7/0x182
> [] ioremap_nocache+0xa/0xc
> [] acpi_os_map_memory+0x11/0x1a
> [] acpi_ex_system_memory_space_handler+0xd3/0x228
> [] ? acpi_ev_address_space_dispatch+0x142/0x1a8
> [] ? acpi_ex_system_memory_space_handler+0x0/0x228
> [] acpi_ev_address_space_dispatch+0x167/0x1a8
> [] acpi_ex_access_region+0x1e4/0x270
> [] acpi_ex_field_datum_io+0x153/0x2a1
> [] ? cache_alloc_debugcheck_after+0xe9/0x165
> [] acpi_ex_extract_from_field+0x91/0x224
> [] ? acpi_ex_read_data_from_field+0x163/0x1b0
> [] acpi_ex_read_data_from_field+0x180/0x1b0
> [] acpi_ex_resolve_node_to_value+0x1aa/0x230
> [] acpi_ex_resolve_to_value+0x270/0x2aa
> [] acpi_ex_resolve_operands+0x24e/0x52f
> [] acpi_ds_exec_end_op+0xb7/0x4f4
> [] acpi_ps_parse_loop+0x5e5/0x79c
> [] acpi_ps_parse_aml+0xb2/0x2dd
> [] acpi_ps_execute_method+0x13d/0x20d
> [] acpi_ns_evaluate+0x10e/0x1b0
> [] acpi_ut_evaluate_object+0x57/0x1a1
> [] acpi_ut_execute_STA+0x22/0x7b
> [] ? acpi_ut_release_mutex+0x85/0x8f
> [] acpi_ns_get_device_callback+0x5a/0x121
> [] acpi_ns_walk_namespace+0xfa/0x114
> [] acpi_get_devices+0x47/0x5d
> [] ? acpi_ns_get_device_callback+0x0/0x121
> [] ? ec_parse_device+0x0/0x6e
> [] acpi_ec_ecdt_probe+0xaa/0x10a
> [] acpi_init+0x73/0x21e
> [] ? class_create+0x4b/0x64
> [] kernel_init+0xa3/0x1f3
> [] ? restore_nocheck_notrace+0x0/0xe
> [] ? kernel_init+0x0/0x1f3
> [] ? kernel_init+0x0/0x1f3
> [] kernel_thread_helper+0x7/0x10
> ===
> ---[ end trace 4eaa2a86a8e2da22 ]---
>
> The offending code in arch/x86/mm/ioremap.c is:
> 101 static void __iomem *__ioremap(unsigned long phys_addr, unsigned long
> size,
> 102enum ioremap_mode mode)
> 103 {
> ...
> 119 /*
> 120 * Don't allow anybody to remap normal RAM that we're using..
> 121 */
> 122 for (pfn = phys_addr >> PAGE_SHIFT; pfn < max_pfn_mapped &&
> 123 (pfn << PAGE_SHIFT) < last_addr; pfn++) {
> 124 if (page_is_ram(pfn) && pfn_valid(pfn) &&
> 125 !PageReserved(pfn_to_page(pfn)))
> 126 return NULL;
> 127 }
> 128
> 129 WARN_ON_ONCE(page_is_ram(pfn));
> 130
>
> The WARN_ON was introduced by git-agpgart.patch.
>
[..]
I'm getting that in mainline now on one of my older laptops also.
> laurent
>
Gabriel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: jffs2: -ENOSPC when truncating file?!
On Sun, 2008-02-24 at 00:57 +0100, Pavel Machek wrote: > Hi! > > I'm trying to free space by truncating big file, and I get: > > [EMAIL PROTECTED]:~# ls -al gps.nmea > -rw-r--r--1 root root 2332070 Feb 19 22:13 gps.nmea > [EMAIL PROTECTED]:~# > gps.nmea > -sh: cannot create gps.nmea: No space left on device > [EMAIL PROTECTED]:~# rm gps.nmea > [EMAIL PROTECTED]:~# > gps.nmea > [EMAIL PROTECTED]:~# You need to write a log entry indicating the new length of the file. There is no space for new log entries. There is a special case for removal -- 'rm gps.nmea' would work. Perhaps we should add a special case for truncation too, so that it can also use the extra pool of free space. -- 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: [Bug 10030] Suspend doesn't work when SD card is inserted
On Sunday, 24 of February 2008, Alan Stern wrote:
> On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
>
> > Ultimately no, it's not. However, we are now late in the -rc2 time frame
> > and
> > the release of -rc3 seems to be imminent. At this point, IMO, that's the
> > safest thing to do. BTW, appended is the patch I'd like to get applied.
>
> In the interest of having a safe release, I guess you're right.
That's what I'm concerned about at the moment. I'm afraid there won't be
enough time to nail down all the issues (there may be some we're not even
aware of).
> It's unfortunate, though -- there's no good way to get thorough testing
> without putting the code in Linus's tree.
Absolutely. Still, the code in question introduces unexpected behavior that
we don't really understand and it's not safe to leave it in the mainline.
> > > How would we then learn about drivers trying to register or unregister a
> > > device during a sleep transition?
> >
> > I think we should fix the ones we know about and try to reintroduce this
> > change in the 2.6.26 time frame. It also seems reasonable to reconsider
> > what
> > we want to achieve, as there may be a better way to do that.
>
> Below is my suggested approach, based on yours. It might even solve
> the MMC problem, who knows? And it adds some potentially useful
> debugging, although it would be better to dump just the stack of
> suspending_task. Do you know how to do that from within a timer
> routine?
No, I don't.
> I still have no clear idea about what's going on with the ACPI bug in
> #9874.
It seems that the ACPI code is not prepared to cope with a failing device
registration, in which case it'd need fixing. Frankly, I'm afraid there may
be more issues like this throughout the tree.
> However perhaps the bug wouldn't occur if we blocked device
> registration until after the resume was finished, instead of failing it
> outright. Since the registration in this case was done in a workqueue
> thread, blocking wouldn't cause an immediate deadlock.
No, it wouldn't, but the fact that it happens in the ACPI code makes me worry.
If we block that code and the things it's supposed to do turn out to be
necessary for suspending later on, we'll be in trouble.
> Index: usb-2.6/drivers/base/power/main.c
> ===
> --- usb-2.6.orig/drivers/base/power/main.c
> +++ usb-2.6/drivers/base/power/main.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> #include "../base.h"
> #include "power.h"
> @@ -59,6 +60,13 @@ static DECLARE_RWSEM(pm_sleep_rwsem);
>
> int (*platform_enable_wakeup)(struct device *dev, int is_on);
>
> +static struct task_struct *suspending_task;
> +
> +bool in_suspend_context(void)
> +{
> + return (suspending_task == current);
> +}
> +
> /**
> * device_pm_add - add a device to the list of active devices
> * @dev: Device to be added to the list
> @@ -94,14 +102,15 @@ void device_pm_remove(struct device *dev
> /* No suspend in progress, wait on dev->sem */
> down(>sem);
> up_read(_sleep_rwsem);
> - } else {
> - /* Suspend in progress, we may deadlock */
> + } else if (!in_suspend_context()) {
> + /* Suspending in another task, we may deadlock */
Well, that shouldn't really deadlock. If it does, there is a potential design
issue somewhere. I think it might be better to set up a timer in here too.
Although IMO it would be even better to just set up a timer and remove the
warning altogehter.
> dev_warn(dev, "Suspicious %s during suspend\n",
> __FUNCTION__);
> dump_stack();
> /* The user has been warned ... */
> down(>sem);
> }
> + /* Otherwise we're okay */
> }
> pr_debug("PM: Removing info for %s:%s\n",
>dev->bus ? dev->bus->name : "No Bus",
There's a problem here, because we shouldn't release the semaphore if we're
in the suspend context.
> @@ -272,6 +281,7 @@ static void dpm_resume(void)
> mutex_lock(_list_mtx);
> }
> mutex_unlock(_list_mtx);
> + suspending_task = NULL;
> }
>
> /**
> @@ -410,6 +420,17 @@ int device_power_down(pm_message_t state
> }
> EXPORT_SYMBOL_GPL(device_power_down);
>
> +/* Provide debugging info if we hang or deadlock during suspend */
> +static struct timer_list suspend_timer;
> +
> +static void suspend_timeout(unsigned long _dev)
> +{
> + struct device *dev = (struct device *) _dev;
> +
> + dev_err(dev, "deadlock during suspend!\n");
> + show_state();
The show_state() seems to be overkill and won't really help if the user can't
collect the output on the fly using a serial console or something like this.
[The debug stuff printed here should
Re: [GIT PATCH] scsi fixes for 2.6.25-rc2
On Sat, 2008-02-23 at 18:31 -0500, Jeff Garzik wrote: > Olof Johansson wrote: > > Hi, > > > > On Sat, Feb 23, 2008 at 09:13:33AM -0600, James Bottomley wrote: > > > >> Jeff Garzik (1): > >> mvsas: Add Marvell 6440 SAS/SATA driver > > [...] > >> drivers/scsi/mvsas.c| 2981 > >> > > > > I just noticed that the file permissions on that file are 755 in current > > git, that was probably not intentional? > > Definitely not intentional. They were 0644 in the original changeset > (the one from me you highlighted), then the second changeset updating > mvsas somehow changed the perms. Actually, unfortunately, it was ... I just didn't spot it. The second patch has this in the header: diff --git a/drivers/scsi/mvsas.c b/drivers/scsi/mvsas.c old mode 100644 new mode 100755 It's git slang for change the mode to executable ... no idea why marvell would do that unless it's something windows related? Anyway, I'll change it back. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
jffs2: -ENOSPC when truncating file?!
Hi! I'm trying to free space by truncating big file, and I get: [EMAIL PROTECTED]:~# ls -al gps.nmea -rw-r--r--1 root root 2332070 Feb 19 22:13 gps.nmea [EMAIL PROTECTED]:~# > gps.nmea -sh: cannot create gps.nmea: No space left on device [EMAIL PROTECTED]:~# rm gps.nmea [EMAIL PROTECTED]:~# > gps.nmea [EMAIL PROTECTED]:~# :-( Kernel is not-so-ancient, on openmoko: [EMAIL PROTECTED]:~# uname -a Linux fic-gta01 2.6.24 #1 PREEMPT Mon Feb 18 21:30:53 GMT 2008 armv4tl unknown [EMAIL PROTECTED]:~# Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] scsi fixes for 2.6.25-rc2
Andrew Morton wrote: On Sat, 23 Feb 2008 12:31:02 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]> wrote: On Sat, 23 Feb 2008, Jeff Garzik wrote: I know I am probably shooting myself in the foot here, since I am the original author of mvsas, but... Should we be adding new drivers during -rc? I'm personally of the opinion that a new driver that doesn't add anything but itself (ie no infrastructure changes etc) is fine. I'd rather have a new, rough driver that might work, than no driver at all, and it's not like it can cause a regression if you don't enable it. Yes, I too think that adding new standalone code in late -rc is OK. ACK, thanks! Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] More accessible usage of custom flags
On Sat, Feb 23, 2008 at 05:28:23PM -0500, Nicholas Marquez wrote: > First of all, thanks for the input! > > On Sat, Feb 23, 2008 at 5:04 PM, Nick Andrew <[EMAIL PROTECTED]> wrote: > > On Sat, Feb 23, 2008 at 04:28:50PM -0500, Nicholas Marquez wrote: > > There are a few places in the Makefile where options would need to be > entered. This just brings those places together in a clean manner and > allows for one to set the flags via the configuration interface. > Though it would be excellent if the kernel had more gcc > micro-optimization (facilitated by such features as the upcoming gcc > 4.3's -finstrument-functions-exclude-function-list option), general > CFLAGS used for the entire kernel do not impact the safety of the > kernel build, assuming that the options are sane. It would be > interesting, however, to see an initiative to tune gcc flags for > important functions and sections within the kernel for optimal > performance given some sort of envisioned usage. (*hint, kernel devs, > hint*) If there are some "common" optimisation flags or sets of flags then maybe they could be turned on/off by invididual config options? There's already CC_OPTIMIZE_FOR_SIZE sorta tagged as experimental. But then, enumerating the allowable flags may limit the user's choices whereas I take it you'd like to expand them. > > > > @@ -487,6 +487,52 @@ > > > >option. If problems are observed, a gcc upgrade may be needed. > > > > > > > >If unsure, say N. > > > > + > > > > +menu "Custom flags" > > > > + > > > > +config CUSTOM_CFLAGS > > > > +string "Custom CFLAGS for kernel" > > > > +default "" > > > > +help > > > > +You can use this to easily set custom gcc CFLAGS to be used > > for the > > > > +entire kernel (including modules). > > > > + > > > > +ONLY ADD CUSTOM CFLAGS IF YOU KNOW WHAT YOU ARE DOING > > > > + > > > > +If unsure, leave blank. > > > > Sorry, but I don't think we need shouting. There are a few options > > already which have bad results if you unknowingly choose the wrong option, > > like enabling EMBEDDED and turning off the BLOCK layer, yet the help > > description doesn't shout. > > Sorry about that. I didn't mean to portray it as "shouting" so much > as a very visible and stern warning. I'm hoping we don't need any stern warnings in the kernel configuration. Although I expect configuring bogus gcc flags is going to break the build far worse than selecting bad options otherwise. If the user makes a mistake in CUSTOM_CFLAGS is the build going to fail with a message "error in CUSTOM_CFLAGS" or is it going to spew out pages of gcc error messages? It is nice if error messages can point back to the source of the error, so the user doesn't have to look through the entire kernel configuration for what they did wrong. > Something else that could be included is a link to the manual for the > (currently used) gcc's command flags > (http://gcc.gnu.org/onlinedocs/gcc-4.2.3/gcc/index.html#toc_Invoking-GCC) > or at least to the online docs, considering that specifying one > specific gcc version's manual would yield various issues. "info gcc" will give all that information in far more detail than I have time to read. > > The boilerplate "If unsure, leave blank" covers (or is meant to cover) > > the situation where the user does not know what they are doing. It says > > "If you don't know what you are doing, just leave this field blank, > > and everything will be OK" ... except it is put in a non-threatening, > > non-demeaning way. > > > > The paragraph in the middle enhances the "help" component of the help > > description, by saying why you might want to use that option. > > I feel that perhaps it is a bit silly to put in such description, as > one using the flags should only do so in knowing specifically which > ones they wish to use and why ahead of time. However, it cannot hurt > to put in more help documentation, so it's a fine suggestion. Well, it can't be both silly and a fine suggestion. Does it dumb down the kernel configuration process too much? I don't want a single person to say "I can't configure this kernel because I don't know what to answer for the CUSTOM_CFLAGS question" and I think the "If unsure, leave blank" at the bottom covers that problem. But I assume you want to encourage experimentation; there will be a person with a bit higher level of skill who might want to start tweaking. Here's something they can start tweaking. Nick. -- PGP Key ID = 0x418487E7 http://www.nick-andrew.net/ PGP Key fingerprint = B3ED 6894 8E49 1770 C24A 67E3 6266 6EB9 4184 87E7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 10030] Suspend doesn't work when SD card is inserted
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> Ultimately no, it's not. However, we are now late in the -rc2 time frame and
> the release of -rc3 seems to be imminent. At this point, IMO, that's the
> safest thing to do. BTW, appended is the patch I'd like to get applied.
In the interest of having a safe release, I guess you're right. It's
unfortunate, though -- there's no good way to get thorough testing
without putting the code in Linus's tree.
> > How would we then learn about drivers trying to register or unregister a
> > device during a sleep transition?
>
> I think we should fix the ones we know about and try to reintroduce this
> change in the 2.6.26 time frame. It also seems reasonable to reconsider what
> we want to achieve, as there may be a better way to do that.
Below is my suggested approach, based on yours. It might even solve
the MMC problem, who knows? And it adds some potentially useful
debugging, although it would be better to dump just the stack of
suspending_task. Do you know how to do that from within a timer
routine?
I still have no clear idea about what's going on with the ACPI bug in
#9874. However perhaps the bug wouldn't occur if we blocked device
registration until after the resume was finished, instead of failing it
outright. Since the registration in this case was done in a workqueue
thread, blocking wouldn't cause an immediate deadlock.
Alan Stern
Index: usb-2.6/drivers/base/power/main.c
===
--- usb-2.6.orig/drivers/base/power/main.c
+++ usb-2.6/drivers/base/power/main.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "../base.h"
#include "power.h"
@@ -59,6 +60,13 @@ static DECLARE_RWSEM(pm_sleep_rwsem);
int (*platform_enable_wakeup)(struct device *dev, int is_on);
+static struct task_struct *suspending_task;
+
+bool in_suspend_context(void)
+{
+ return (suspending_task == current);
+}
+
/**
* device_pm_add - add a device to the list of active devices
* @dev: Device to be added to the list
@@ -94,14 +102,15 @@ void device_pm_remove(struct device *dev
/* No suspend in progress, wait on dev->sem */
down(>sem);
up_read(_sleep_rwsem);
- } else {
- /* Suspend in progress, we may deadlock */
+ } else if (!in_suspend_context()) {
+ /* Suspending in another task, we may deadlock */
dev_warn(dev, "Suspicious %s during suspend\n",
__FUNCTION__);
dump_stack();
/* The user has been warned ... */
down(>sem);
}
+ /* Otherwise we're okay */
}
pr_debug("PM: Removing info for %s:%s\n",
dev->bus ? dev->bus->name : "No Bus",
@@ -272,6 +281,7 @@ static void dpm_resume(void)
mutex_lock(_list_mtx);
}
mutex_unlock(_list_mtx);
+ suspending_task = NULL;
}
/**
@@ -410,6 +420,17 @@ int device_power_down(pm_message_t state
}
EXPORT_SYMBOL_GPL(device_power_down);
+/* Provide debugging info if we hang or deadlock during suspend */
+static struct timer_list suspend_timer;
+
+static void suspend_timeout(unsigned long _dev)
+{
+ struct device *dev = (struct device *) _dev;
+
+ dev_err(dev, "deadlock during suspend!\n");
+ show_state();
+}
+
/**
* suspend_device - Save state of one device.
* @dev: Device.
@@ -419,6 +440,10 @@ int suspend_device(struct device *dev, p
{
int error = 0;
+ /* Provide debugging output in case of a deadlock */
+ setup_timer(_timer, suspend_timeout, (unsigned long) dev);
+ mod_timer(_timer, jiffies + 5*HZ);
+
if (dev->power.power_state.event) {
dev_dbg(dev, "PM: suspend %d-->%d\n",
dev->power.power_state.event, state.event);
@@ -441,6 +466,8 @@ int suspend_device(struct device *dev, p
error = dev->bus->suspend(dev, state);
suspend_report_result(dev->bus->suspend, error);
}
+
+ del_timer_sync(_timer);
return error;
}
@@ -460,6 +487,7 @@ static int dpm_suspend(pm_message_t stat
{
int error = 0;
+ suspending_task = current;
mutex_lock(_list_mtx);
while (!list_empty(_locked)) {
struct list_head *entry = dpm_locked.prev;
Index: usb-2.6/drivers/base/power/power.h
===
--- usb-2.6.orig/drivers/base/power/power.h
+++ usb-2.6/drivers/base/power/power.h
@@ -11,6 +11,7 @@ static inline struct device *to_device(s
return container_of(entry, struct device, power.entry);
}
+extern bool in_suspend_context(void);
extern void device_pm_add(struct device *);
extern void device_pm_remove(struct
Re: [GIT PATCH] scsi fixes for 2.6.25-rc2
Olof Johansson wrote: Hi, On Sat, Feb 23, 2008 at 09:13:33AM -0600, James Bottomley wrote: Jeff Garzik (1): mvsas: Add Marvell 6440 SAS/SATA driver [...] drivers/scsi/mvsas.c| 2981 I just noticed that the file permissions on that file are 755 in current git, that was probably not intentional? Definitely not intentional. They were 0644 in the original changeset (the one from me you highlighted), then the second changeset updating mvsas somehow changed the perms. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/10] CGroup API files: Move "releasable" to cgroup_debug subsystem
The "releasable" control file provided by the cgroup framework exports
the state of a per-cgroup flag that's related to the notify-on-release
feature. This isn't really generally useful, unless you're trying to
debug this particular feature of cgroups.
This patch moves the "releasable" file to the cgroup_debug subsystem.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
include/linux/cgroup.h | 11 +++
kernel/cgroup.c| 23 ---
kernel/cgroup_debug.c | 12 +++-
3 files changed, 22 insertions(+), 24 deletions(-)
Index: cgroup-2.6.25-rc2-mm1/include/linux/cgroup.h
===
--- cgroup-2.6.25-rc2-mm1.orig/include/linux/cgroup.h
+++ cgroup-2.6.25-rc2-mm1/include/linux/cgroup.h
@@ -88,6 +88,17 @@ static inline void css_put(struct cgroup
__css_put(css);
}
+/* bits in struct cgroup flags field */
+enum {
+ /* Control Group is dead */
+ CGRP_REMOVED,
+ /* Control Group has previously had a child cgroup or a task,
+* but no longer (only if CGRP_NOTIFY_ON_RELEASE is set) */
+ CGRP_RELEASABLE,
+ /* Control Group requires release notifications to userspace */
+ CGRP_NOTIFY_ON_RELEASE,
+};
+
struct cgroup {
unsigned long flags;/* "unsigned long" so bitops work */
Index: cgroup-2.6.25-rc2-mm1/kernel/cgroup.c
===
--- cgroup-2.6.25-rc2-mm1.orig/kernel/cgroup.c
+++ cgroup-2.6.25-rc2-mm1/kernel/cgroup.c
@@ -119,17 +119,6 @@ static int root_count;
*/
static int need_forkexit_callback;
-/* bits in struct cgroup flags field */
-enum {
- /* Control Group is dead */
- CGRP_REMOVED,
- /* Control Group has previously had a child cgroup or a task,
-* but no longer (only if CGRP_NOTIFY_ON_RELEASE is set) */
- CGRP_RELEASABLE,
- /* Control Group requires release notifications to userspace */
- CGRP_NOTIFY_ON_RELEASE,
-};
-
/* convenient tests for these bits */
inline int cgroup_is_removed(const struct cgroup *cgrp)
{
@@ -1299,7 +1288,6 @@ enum cgroup_filetype {
FILE_DIR,
FILE_TASKLIST,
FILE_NOTIFY_ON_RELEASE,
- FILE_RELEASABLE,
FILE_RELEASE_AGENT,
};
@@ -2169,11 +2157,6 @@ static u64 cgroup_read_notify_on_release
return notify_on_release(cgrp);
}
-static u64 cgroup_read_releasable(struct cgroup *cgrp, struct cftype *cft)
-{
- return test_bit(CGRP_RELEASABLE, >flags);
-}
-
/*
* for the common functions, 'private' gives the type of file
*/
@@ -2193,12 +2176,6 @@ static struct cftype files[] = {
.write = cgroup_common_file_write,
.private = FILE_NOTIFY_ON_RELEASE,
},
-
- {
- .name = "releasable",
- .read_u64 = cgroup_read_releasable,
- .private = FILE_RELEASABLE,
- }
};
static struct cftype cft_release_agent = {
Index: cgroup-2.6.25-rc2-mm1/kernel/cgroup_debug.c
===
--- cgroup-2.6.25-rc2-mm1.orig/kernel/cgroup_debug.c
+++ cgroup-2.6.25-rc2-mm1/kernel/cgroup_debug.c
@@ -1,5 +1,5 @@
/*
- * kernel/ccontainer_debug.c - Example cgroup subsystem that
+ * kernel/cgroup_debug.c - Example cgroup subsystem that
* exposes debug info
*
* Copyright (C) Google Inc, 2007
@@ -62,6 +62,11 @@ static u64 current_css_set_refcount_read
return count;
}
+static u64 releasable_read(struct cgroup *cgrp, struct cftype *cft)
+{
+ return test_bit(CGRP_RELEASABLE, >flags);
+}
+
static struct cftype files[] = {
{
.name = "cgroup_refcount",
@@ -81,6 +86,11 @@ static struct cftype files[] = {
.name = "current_css_set_refcount",
.read_u64 = current_css_set_refcount_read,
},
+
+ {
+ .name = "releasable",
+ .read_u64 = releasable_read,
+ }
};
static int debug_populate(struct cgroup_subsys *ss, struct cgroup *cont)
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 07/10] CGroup API files: Use cgroup map for memcontrol stats file
Remove the seq_file boilerplate used to construct the memcontrol stats
map, and instead use the new map representation for cgroup control
files
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
mm/memcontrol.c | 30 ++
1 file changed, 6 insertions(+), 24 deletions(-)
Index: cgroup-2.6.25-rc2-mm1/mm/memcontrol.c
===
--- cgroup-2.6.25-rc2-mm1.orig/mm/memcontrol.c
+++ cgroup-2.6.25-rc2-mm1/mm/memcontrol.c
@@ -971,9 +971,9 @@ static const struct mem_cgroup_stat_desc
[MEM_CGROUP_STAT_RSS] = { "rss", PAGE_SIZE, },
};
-static int mem_control_stat_show(struct seq_file *m, void *arg)
+static int mem_control_stat_show(struct cgroup *cont, struct cftype *cft,
+struct cgroup_map_cb *cb)
{
- struct cgroup *cont = m->private;
struct mem_cgroup *mem_cont = mem_cgroup_from_cont(cont);
struct mem_cgroup_stat *stat = _cont->stat;
int i;
@@ -983,8 +983,7 @@ static int mem_control_stat_show(struct
val = mem_cgroup_read_stat(stat, i);
val *= mem_cgroup_stat_desc[i].unit;
- seq_printf(m, "%s %lld\n", mem_cgroup_stat_desc[i].msg,
- (long long)val);
+ cb->fill(cb, mem_cgroup_stat_desc[i].msg, val);
}
/* showing # of active pages */
{
@@ -994,29 +993,12 @@ static int mem_control_stat_show(struct
MEM_CGROUP_ZSTAT_INACTIVE);
active = mem_cgroup_get_all_zonestat(mem_cont,
MEM_CGROUP_ZSTAT_ACTIVE);
- seq_printf(m, "active %ld\n", (active) * PAGE_SIZE);
- seq_printf(m, "inactive %ld\n", (inactive) * PAGE_SIZE);
+ cb->fill(cb, "active", (active) * PAGE_SIZE);
+ cb->fill(cb, "inactive", (inactive) * PAGE_SIZE);
}
return 0;
}
-static const struct file_operations mem_control_stat_file_operations = {
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
-
-static int mem_control_stat_open(struct inode *unused, struct file *file)
-{
- /* XXX __d_cont */
- struct cgroup *cont = file->f_dentry->d_parent->d_fsdata;
-
- file->f_op = _control_stat_file_operations;
- return single_open(file, mem_control_stat_show, cont);
-}
-
-
-
static struct cftype mem_cgroup_files[] = {
{
.name = "usage_in_bytes",
@@ -1041,7 +1023,7 @@ static struct cftype mem_cgroup_files[]
},
{
.name = "stat",
- .open = mem_control_stat_open,
+ .read_map = mem_control_stat_show,
},
};
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 05/10] CGroup API files: Update cpusets to use cgroup structured file API
Many of the cpusets control files are simple integer values, which
don't require the overhead of memory allocations for reads and writes.
Move the handlers for these control files into cpuset_read_u64() and
cpuset_write_u64().
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
kernel/cpuset.c | 155 +---
1 file changed, 81 insertions(+), 74 deletions(-)
Index: cgroup-2.6.25-rc2-mm1/kernel/cpuset.c
===
--- cgroup-2.6.25-rc2-mm1.orig/kernel/cpuset.c
+++ cgroup-2.6.25-rc2-mm1/kernel/cpuset.c
@@ -999,19 +999,6 @@ int current_cpuset_is_being_rebound(void
}
/*
- * Call with cgroup_mutex held.
- */
-
-static int update_memory_pressure_enabled(struct cpuset *cs, char *buf)
-{
- if (simple_strtoul(buf, NULL, 10) != 0)
- cpuset_memory_pressure_enabled = 1;
- else
- cpuset_memory_pressure_enabled = 0;
- return 0;
-}
-
-/*
* update_flag - read a 0 or a 1 in a file and update associated flag
* bit:the bit to update (CS_CPU_EXCLUSIVE, CS_MEM_EXCLUSIVE,
* CS_SCHED_LOAD_BALANCE,
@@ -1023,15 +1010,13 @@ static int update_memory_pressure_enable
* Call with cgroup_mutex held.
*/
-static int update_flag(cpuset_flagbits_t bit, struct cpuset *cs, char *buf)
+static int update_flag(cpuset_flagbits_t bit, struct cpuset *cs,
+ int turning_on)
{
- int turning_on;
struct cpuset trialcs;
int err;
int cpus_nonempty, balance_flag_changed;
- turning_on = (simple_strtoul(buf, NULL, 10) != 0);
-
trialcs = *cs;
if (turning_on)
set_bit(bit, );
@@ -1247,43 +1232,65 @@ static ssize_t cpuset_common_file_write(
case FILE_MEMLIST:
retval = update_nodemask(cs, buffer);
break;
+ default:
+ retval = -EINVAL;
+ goto out2;
+ }
+
+ if (retval == 0)
+ retval = nbytes;
+out2:
+ cgroup_unlock();
+out1:
+ kfree(buffer);
+ return retval;
+}
+
+static int cpuset_write_u64(struct cgroup *cgrp, struct cftype *cft, u64 val)
+{
+ int retval = 0;
+ struct cpuset *cs = cgroup_cs(cgrp);
+ cpuset_filetype_t type = cft->private;
+
+ cgroup_lock();
+
+ if (cgroup_is_removed(cgrp)) {
+ cgroup_unlock();
+ return -ENODEV;
+ }
+
+ switch (type) {
case FILE_CPU_EXCLUSIVE:
- retval = update_flag(CS_CPU_EXCLUSIVE, cs, buffer);
+ retval = update_flag(CS_CPU_EXCLUSIVE, cs, val);
break;
case FILE_MEM_EXCLUSIVE:
- retval = update_flag(CS_MEM_EXCLUSIVE, cs, buffer);
+ retval = update_flag(CS_MEM_EXCLUSIVE, cs, val);
break;
case FILE_SCHED_LOAD_BALANCE:
- retval = update_flag(CS_SCHED_LOAD_BALANCE, cs, buffer);
+ retval = update_flag(CS_SCHED_LOAD_BALANCE, cs, val);
break;
case FILE_MEMORY_MIGRATE:
- retval = update_flag(CS_MEMORY_MIGRATE, cs, buffer);
+ retval = update_flag(CS_MEMORY_MIGRATE, cs, val);
break;
case FILE_MEMORY_PRESSURE_ENABLED:
- retval = update_memory_pressure_enabled(cs, buffer);
+ cpuset_memory_pressure_enabled = !!val;
break;
case FILE_MEMORY_PRESSURE:
retval = -EACCES;
break;
case FILE_SPREAD_PAGE:
- retval = update_flag(CS_SPREAD_PAGE, cs, buffer);
+ retval = update_flag(CS_SPREAD_PAGE, cs, val);
cs->mems_generation = cpuset_mems_generation++;
break;
case FILE_SPREAD_SLAB:
- retval = update_flag(CS_SPREAD_SLAB, cs, buffer);
+ retval = update_flag(CS_SPREAD_SLAB, cs, val);
cs->mems_generation = cpuset_mems_generation++;
break;
default:
retval = -EINVAL;
- goto out2;
+ break;
}
-
- if (retval == 0)
- retval = nbytes;
-out2:
cgroup_unlock();
-out1:
- kfree(buffer);
return retval;
}
@@ -1345,30 +1352,6 @@ static ssize_t cpuset_common_file_read(s
case FILE_MEMLIST:
s += cpuset_sprintf_memlist(s, cs);
break;
- case FILE_CPU_EXCLUSIVE:
- *s++ = is_cpu_exclusive(cs) ? '1' : '0';
- break;
- case FILE_MEM_EXCLUSIVE:
- *s++ = is_mem_exclusive(cs) ? '1' : '0';
- break;
- case FILE_SCHED_LOAD_BALANCE:
- *s++ = is_sched_load_balance(cs) ? '1' : '0';
- break;
- case FILE_MEMORY_MIGRATE:
- *s++ = is_memory_migrate(cs) ? '1' : '0';
- break;
- case
[PATCH 04/10] CGroup API files: Strip all trailing whitespace in cgroup_write_u64
This removes the need for people to remember to pass the -n flag to echo when writing values to cgroup control files. Signed-off-by: Paul Menage <[EMAIL PROTECTED]> --- kernel/cgroup.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) Index: cgroup-2.6.25-rc2-mm1/kernel/cgroup.c === --- cgroup-2.6.25-rc2-mm1.orig/kernel/cgroup.c +++ cgroup-2.6.25-rc2-mm1/kernel/cgroup.c @@ -1321,10 +1321,7 @@ static ssize_t cgroup_write_u64(struct c return -EFAULT; buffer[nbytes] = 0; /* nul-terminate */ - - /* strip newline if necessary */ - if (nbytes && (buffer[nbytes-1] == '\n')) - buffer[nbytes-1] = 0; + strstrip(buffer); val = simple_strtoull(buffer, , 0); if (*end) 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/
[PATCH 08/10] CGroup API files: Drop mem_cgroup_force_empty()
This function isn't needed - a NULL pointer in the cftype read
function will result in the same EINVAL response to userspace.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
mm/memcontrol.c | 14 --
1 file changed, 14 deletions(-)
Index: cgroup-2.6.25-rc2-mm1/mm/memcontrol.c
===
--- cgroup-2.6.25-rc2-mm1.orig/mm/memcontrol.c
+++ cgroup-2.6.25-rc2-mm1/mm/memcontrol.c
@@ -950,19 +950,6 @@ static ssize_t mem_force_empty_write(str
return ret;
}
-/*
- * Note: This should be removed if cgroup supports write-only file.
- */
-
-static ssize_t mem_force_empty_read(struct cgroup *cont,
- struct cftype *cft,
- struct file *file, char __user *userbuf,
- size_t nbytes, loff_t *ppos)
-{
- return -EINVAL;
-}
-
-
static const struct mem_cgroup_stat_desc {
const char *msg;
u64 unit;
@@ -1019,7 +1006,6 @@ static struct cftype mem_cgroup_files[]
{
.name = "force_empty",
.write = mem_force_empty_write,
- .read = mem_force_empty_read,
},
{
.name = "stat",
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 00/10] CGroup API files: Various cleanup to CGroup control files
This patchset is a roll-up of the non-contraversial items of the various patches that I've sent out recently, fixed according to the feedback received. In summary they are: - general rename of read_uint/write_uint to read_u64/write_u64 - use these methods for cpusets and memory controller files - add a read_map cgroup file method, and use it in the memory controller - move the "releasable" control file to the debug subsystem - make the debug subsystem config option default to "n" The only user-visible changes are the movement of the "releasable" file and the fact that some write_u64()-based control files are now more forgiving of additional whitespace at the end of their input. Signed-off-by: Paul Menage <[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 02/10] CGroup API files: Add res_counter_read_u64()
Adds a function for returning the value of a resource counter member,
in a form suitable for use in a cgroup read_u64 control file method.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
include/linux/res_counter.h |5 -
kernel/res_counter.c|5 +
2 files changed, 9 insertions(+), 1 deletion(-)
Index: cgroup-2.6.25-rc2-mm1/include/linux/res_counter.h
===
--- cgroup-2.6.25-rc2-mm1.orig/include/linux/res_counter.h
+++ cgroup-2.6.25-rc2-mm1/include/linux/res_counter.h
@@ -39,8 +39,9 @@ struct res_counter {
spinlock_t lock;
};
-/*
+/**
* Helpers to interact with userspace
+ * res_counter_read_u64() - returns the value of the specified member.
* res_counter_read/_write - put/get the specified fields from the
* res_counter struct to/from the user
*
@@ -51,6 +52,8 @@ struct res_counter {
* @pos: and the offset.
*/
+u64 res_counter_read_u64(struct res_counter *counter, int member);
+
ssize_t res_counter_read(struct res_counter *counter, int member,
const char __user *buf, size_t nbytes, loff_t *pos,
int (*read_strategy)(unsigned long long val, char *s));
Index: cgroup-2.6.25-rc2-mm1/kernel/res_counter.c
===
--- cgroup-2.6.25-rc2-mm1.orig/kernel/res_counter.c
+++ cgroup-2.6.25-rc2-mm1/kernel/res_counter.c
@@ -92,6 +92,11 @@ ssize_t res_counter_read(struct res_coun
pos, buf, s - buf);
}
+u64 res_counter_read_u64(struct res_counter *counter, int member)
+{
+ return *res_counter_member(counter, member);
+}
+
ssize_t res_counter_write(struct res_counter *counter, int member,
const char __user *userbuf, size_t nbytes, loff_t *pos,
int (*write_strategy)(char *st_buf, unsigned long long *val))
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/10] CGroup API files: Add cgroup map data type
Adds a new type of supported control file representation, a map from
strings to u64 values.
Each map entry is printed as a line in a similar format to
/proc/vmstat, i.e. "$key $value\n"
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
include/linux/cgroup.h | 19 +
kernel/cgroup.c| 53 -
2 files changed, 71 insertions(+), 1 deletion(-)
Index: cgroup-2.6.25-rc2-mm1/include/linux/cgroup.h
===
--- cgroup-2.6.25-rc2-mm1.orig/include/linux/cgroup.h
+++ cgroup-2.6.25-rc2-mm1/include/linux/cgroup.h
@@ -166,6 +166,16 @@ struct css_set {
};
+/*
+ * cgroup_map_cb is an abstract callback API for reporting map-valued
+ * control files
+ */
+
+struct cgroup_map_cb {
+ int (*fill)(struct cgroup_map_cb *cb, const char *key, u64 value);
+ void *state;
+};
+
/* struct cftype:
*
* The files in the cgroup filesystem mostly have a very simple read/write
@@ -194,6 +204,15 @@ struct cftype {
* single integer. Use it in place of read()
*/
u64 (*read_u64) (struct cgroup *cont, struct cftype *cft);
+ /*
+* read_map() is used for defining a map of key/value
+* pairs. It should call cb->fill(cb, key, value) for each
+* entry. The key/value pairs (and their ordering) should not
+* change between reboots.
+*/
+ int (*read_map) (struct cgroup *cont, struct cftype *cft,
+struct cgroup_map_cb *cb);
+
ssize_t (*write) (struct cgroup *cont, struct cftype *cft,
struct file *file,
const char __user *buf, size_t nbytes, loff_t *ppos);
Index: cgroup-2.6.25-rc2-mm1/kernel/cgroup.c
===
--- cgroup-2.6.25-rc2-mm1.orig/kernel/cgroup.c
+++ cgroup-2.6.25-rc2-mm1/kernel/cgroup.c
@@ -1484,6 +1484,46 @@ static ssize_t cgroup_file_read(struct f
return -EINVAL;
}
+/*
+ * seqfile ops/methods for returning structured data. Currently just
+ * supports string->u64 maps, but can be extended in future.
+ */
+
+struct cgroup_seqfile_state {
+ struct cftype *cft;
+ struct cgroup *cgroup;
+};
+
+static int cgroup_map_add(struct cgroup_map_cb *cb, const char *key, u64 value)
+{
+ struct seq_file *sf = cb->state;
+ return seq_printf(sf, "%s %llu\n", key, (unsigned long long)value);
+}
+
+static int cgroup_seqfile_show(struct seq_file *m, void *arg)
+{
+ struct cgroup_seqfile_state *state = m->private;
+ struct cftype *cft = state->cft;
+ struct cgroup_map_cb cb = {
+ .fill = cgroup_map_add,
+ .state = m,
+ };
+ return cft->read_map(state->cgroup, cft, );
+}
+
+int cgroup_seqfile_release(struct inode *inode, struct file *file)
+{
+ struct seq_file *seq = file->private_data;
+ kfree(seq->private);
+ return single_release(inode, file);
+}
+
+static struct file_operations cgroup_seqfile_operations = {
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = cgroup_seqfile_release,
+};
+
static int cgroup_file_open(struct inode *inode, struct file *file)
{
int err;
@@ -1496,7 +1536,18 @@ static int cgroup_file_open(struct inode
cft = __d_cft(file->f_dentry);
if (!cft)
return -ENODEV;
- if (cft->open)
+ if (cft->read_map) {
+ struct cgroup_seqfile_state *state =
+ kzalloc(sizeof(*state), GFP_USER);
+ if (!state)
+ return -ENOMEM;
+ state->cft = cft;
+ state->cgroup = __d_cgrp(file->f_dentry->d_parent);
+ file->f_op = _seqfile_operations;
+ err = single_open(file, cgroup_seqfile_show, state);
+ if (err < 0)
+ kfree(state);
+ } else if (cft->open)
err = cft->open(inode, file);
else
err = 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/
[PATCH 01/10] CGroup API files: Rename read/write_uint methods to read_write_u64
Several people have justifiably complained that the "_uint" suffix is
inappropriate for functions that handle u64 values, so this patch just
renames all these functions and their users to have the suffic _u64.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
include/linux/cgroup.h |8
kernel/cgroup.c| 32
kernel/cgroup_debug.c |8
kernel/sched.c | 18 +-
4 files changed, 33 insertions(+), 33 deletions(-)
Index: cgroup-2.6.25-rc2-mm1/include/linux/cgroup.h
===
--- cgroup-2.6.25-rc2-mm1.orig/include/linux/cgroup.h
+++ cgroup-2.6.25-rc2-mm1/include/linux/cgroup.h
@@ -190,20 +190,20 @@ struct cftype {
struct file *file,
char __user *buf, size_t nbytes, loff_t *ppos);
/*
-* read_uint() is a shortcut for the common case of returning a
+* read_u64() is a shortcut for the common case of returning a
* single integer. Use it in place of read()
*/
- u64 (*read_uint) (struct cgroup *cont, struct cftype *cft);
+ u64 (*read_u64) (struct cgroup *cont, struct cftype *cft);
ssize_t (*write) (struct cgroup *cont, struct cftype *cft,
struct file *file,
const char __user *buf, size_t nbytes, loff_t *ppos);
/*
-* write_uint() is a shortcut for the common case of accepting
+* write_u64() is a shortcut for the common case of accepting
* a single integer (as parsed by simple_strtoull) from
* userspace. Use in place of write(); return 0 or error.
*/
- int (*write_uint) (struct cgroup *cont, struct cftype *cft, u64 val);
+ int (*write_u64) (struct cgroup *cont, struct cftype *cft, u64 val);
int (*release) (struct inode *inode, struct file *file);
};
Index: cgroup-2.6.25-rc2-mm1/kernel/cgroup.c
===
--- cgroup-2.6.25-rc2-mm1.orig/kernel/cgroup.c
+++ cgroup-2.6.25-rc2-mm1/kernel/cgroup.c
@@ -1303,10 +1303,10 @@ enum cgroup_filetype {
FILE_RELEASE_AGENT,
};
-static ssize_t cgroup_write_uint(struct cgroup *cgrp, struct cftype *cft,
-struct file *file,
-const char __user *userbuf,
-size_t nbytes, loff_t *unused_ppos)
+static ssize_t cgroup_write_u64(struct cgroup *cgrp, struct cftype *cft,
+ struct file *file,
+ const char __user *userbuf,
+ size_t nbytes, loff_t *unused_ppos)
{
char buffer[64];
int retval = 0;
@@ -1330,7 +1330,7 @@ static ssize_t cgroup_write_uint(struct
return -EINVAL;
/* Pass to subsystem */
- retval = cft->write_uint(cgrp, cft, val);
+ retval = cft->write_u64(cgrp, cft, val);
if (!retval)
retval = nbytes;
return retval;
@@ -1411,18 +1411,18 @@ static ssize_t cgroup_file_write(struct
return -ENODEV;
if (cft->write)
return cft->write(cgrp, cft, file, buf, nbytes, ppos);
- if (cft->write_uint)
- return cgroup_write_uint(cgrp, cft, file, buf, nbytes, ppos);
+ if (cft->write_u64)
+ return cgroup_write_u64(cgrp, cft, file, buf, nbytes, ppos);
return -EINVAL;
}
-static ssize_t cgroup_read_uint(struct cgroup *cgrp, struct cftype *cft,
- struct file *file,
- char __user *buf, size_t nbytes,
- loff_t *ppos)
+static ssize_t cgroup_read_u64(struct cgroup *cgrp, struct cftype *cft,
+ struct file *file,
+ char __user *buf, size_t nbytes,
+ loff_t *ppos)
{
char tmp[64];
- u64 val = cft->read_uint(cgrp, cft);
+ u64 val = cft->read_u64(cgrp, cft);
int len = sprintf(tmp, "%llu\n", (unsigned long long) val);
return simple_read_from_buffer(buf, nbytes, ppos, tmp, len);
@@ -1482,8 +1482,8 @@ static ssize_t cgroup_file_read(struct f
if (cft->read)
return cft->read(cgrp, cft, file, buf, nbytes, ppos);
- if (cft->read_uint)
- return cgroup_read_uint(cgrp, cft, file, buf, nbytes, ppos);
+ if (cft->read_u64)
+ return cgroup_read_u64(cgrp, cft, file, buf, nbytes, ppos);
return -EINVAL;
}
@@ -2141,14 +2141,14 @@ static struct cftype files[] = {
{
.name = "notify_on_release",
- .read_uint = cgroup_read_notify_on_release,
+ .read_u64 = cgroup_read_notify_on_release,
.write = cgroup_common_file_write,
.private = FILE_NOTIFY_ON_RELEASE,
[PATCH 10/10] CGroup API files: Make CGROUP_DEBUG default to off
The cgroup debug subsystem isn't generally useful for users. It should default to "n". Signed-off-by: Paul Menage <[EMAIL PROTECTED]> --- init/Kconfig |1 + 1 file changed, 1 insertion(+) Index: cgroup-2.6.25-rc2-mm1/init/Kconfig === --- cgroup-2.6.25-rc2-mm1.orig/init/Kconfig +++ cgroup-2.6.25-rc2-mm1/init/Kconfig @@ -284,6 +284,7 @@ config CGROUPS config CGROUP_DEBUG bool "Example debug cgroup subsystem" depends on CGROUPS + default n help This option enables a simple cgroup subsystem that exports useful debugging information about the cgroups -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 03/10] CGroup API files: Use read_u64 in memory controller
Update the memory controller to use read_u64 for its
limit/usage/failcnt control files, calling the new
res_counter_read_u64() function.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
mm/memcontrol.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
Index: cgroup-2.6.25-rc2-mm1/mm/memcontrol.c
===
--- cgroup-2.6.25-rc2-mm1.orig/mm/memcontrol.c
+++ cgroup-2.6.25-rc2-mm1/mm/memcontrol.c
@@ -922,13 +922,10 @@ int mem_cgroup_write_strategy(char *buf,
return 0;
}
-static ssize_t mem_cgroup_read(struct cgroup *cont,
- struct cftype *cft, struct file *file,
- char __user *userbuf, size_t nbytes, loff_t *ppos)
+static u64 mem_cgroup_read(struct cgroup *cont, struct cftype *cft)
{
- return res_counter_read(_cgroup_from_cont(cont)->res,
- cft->private, userbuf, nbytes, ppos,
- NULL);
+ return res_counter_read_u64(_cgroup_from_cont(cont)->res,
+ cft->private);
}
static ssize_t mem_cgroup_write(struct cgroup *cont, struct cftype *cft,
@@ -1024,18 +1021,18 @@ static struct cftype mem_cgroup_files[]
{
.name = "usage_in_bytes",
.private = RES_USAGE,
- .read = mem_cgroup_read,
+ .read_u64 = mem_cgroup_read,
},
{
.name = "limit_in_bytes",
.private = RES_LIMIT,
.write = mem_cgroup_write,
- .read = mem_cgroup_read,
+ .read_u64 = mem_cgroup_read,
},
{
.name = "failcnt",
.private = RES_FAILCNT,
- .read = mem_cgroup_read,
+ .read_u64 = mem_cgroup_read,
},
{
.name = "force_empty",
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] x86: fix build on non-C locales.
x86: fix build on some non-C locales[1]. For some locales regex range [a-zA-Z] does not work as it is supposed to so we have to specify LANG=C to make it work as intended. [1] http://en.wikipedia.org/wiki/Estonian_alphabet Signed-off-by: Priit Laes <[EMAIL PROTECTED]> diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile index f385a4b..c58e7b9 100644 --- a/arch/x86/vdso/Makefile +++ b/arch/x86/vdso/Makefile @@ -50,7 +50,8 @@ obj-$(VDSO64-y) += vdso-syms.lds sed-vdsosym := -e 's/^00*/0/' \ -e 's/^\([0-9a-fA-F]*\) . \(VDSO[a-zA-Z0-9_]*\)$$/\2 = 0x\1;/p' quiet_cmd_vdsosym = VDSOSYM $@ - cmd_vdsosym = $(NM) $< | sed -n $(sed-vdsosym) | LC_ALL=C sort > $@ + cmd_vdsosym = $(NM) $< | LC_ALL=C sed -n $(sed-vdsosym) \ + | LC_ALL=C sort > $@ $(obj)/%-syms.lds: $(obj)/%.so.dbg FORCE $(call if_changed,vdsosym)
[PATCH try #1] Kconfig: cleanup block/Kconfig help descriptions
Modify the help descriptions of block/Kconfig for clarity, accuracy and consistency. Refactor the BLOCK description a bit. The wording "This permits ... to be removed" isn't quite right; the block layer is removed when the option is disabled, whereas most descriptions talk about what happens when the option is enabled. Reformat the list of what is affected by disabling the block layer. Add more examples of large block devices to LBD and strive for technical accuracy; block devices of size _exactly_ 2TB require CONFIG_LBD, not only "bigger than 2TB". Also try to say (perhaps not very clearly) that the config option is only needed when you want to have individual block devices of size >= 2TB, for example if you had 3 x 1TB disks in your computer you'd have a total storage size of 3TB but you wouldn't need the option unless you want to aggregate those disks into a RAID or LVM. Improve terminology and grammar on BLK_DEV_IO_TRACE. I also added the boilerplate "If unsure, say N" to most options. Precisely say "2TB and larger" for LSF. Indent the help text for BLK_DEV_BSG by 2 spaces in accordance with the standard. Signed-off-by: Nick Andrew <[EMAIL PROTECTED]> --- I'm not sure why LSF has "If unsure, say Y." I would have thought it pretty uncommon to have such large files. Also if you need LSF, you probably need LBD (can NFS handle 2TB+ files?). Is this a safety feature? How often is Grandma going to mount a filesystem containing 2TB+ sized files? Also the description for BLK_DEV_BSG is pretty obscure. Can anybody suggest why you'd want to do this or what tools you can use or even some documentation? block/Kconfig | 65 + 1 files changed, 42 insertions(+), 23 deletions(-) diff --git a/block/Kconfig b/block/Kconfig index 9bda7bc..a3d8509 100644 --- a/block/Kconfig +++ b/block/Kconfig @@ -5,14 +5,18 @@ menuconfig BLOCK bool "Enable the block layer" if EMBEDDED default y help -This permits the block layer to be removed from the kernel if it's not -needed (on some embedded devices for example). If this option is -disabled, then blockdev files will become unusable and some -filesystems (such as ext3) will become unavailable. +Provide block layer support for the kernel. -This option will also disable SCSI character devices and USB storage -since they make use of various block layer definitions and -facilities. +Disable this option to remove the block layer support from the +kernel. This may be useful for embedded devices. + +If this option is disabled: + + - block device files will become unusable + - some filesystems (such as ext3) will become unavailable. + +Also, SCSI character devices and USB storage will be disabled since +they make use of various block layer definitions and facilities. Say Y here unless you know you really don't want to mount disks and suchlike. @@ -23,9 +27,20 @@ config LBD bool "Support for Large Block Devices" depends on !64BIT help - Say Y here if you want to attach large (bigger than 2TB) discs to - your machine, or if you want to have a raid or loopback device - bigger than 2TB. Otherwise say N. + Enable block devices of size 2TB and larger. + + This option is required to support the full capacity of large + (2TB+) block devices, including RAID, disk, Network Block Device, + Logical Volume Manager (LVM) and loopback. + + For example, RAID devices are frequently bigger than the capacity + of the largest individual hard drive. + + This option is not required if you have individual disk drives + which total 2TB+ and you are not aggregating the capacity into + a large block device (e.g. using RAID or LVM). + + If unsure, say N. config BLK_DEV_IO_TRACE bool "Support for tracing block io actions" @@ -33,19 +48,21 @@ config BLK_DEV_IO_TRACE select RELAY select DEBUG_FS help - Say Y here, if you want to be able to trace the block layer actions + Say Y here if you want to be able to trace the block layer actions on a given queue. Tracing allows you to see any traffic happening - on a block device queue. For more information (and the user space - support tools needed), fetch the blktrace app from: + on a block device queue. For more information (and the userspace + support tools needed), fetch the blktrace tools from: git://brick.kernel.dk/data/git/blktrace.git + If unsure, say N. + config LSF bool "Support for Large Single Files" depends on !64BIT help - Say Y here if you want to be able to handle very large files (bigger - than 2TB), otherwise say N. + Say Y here if you
Re: 2.6.25-rc2 + smartd = hang
Hi, On Saturday 23 February 2008, Anders Eriksson wrote: > > [EMAIL PROTECTED] said: > >> But at this point libata is working much better than the old IDE stuff, and > >> it really is worth moving things over if you can. > > > > Ok, I'll take a stab at that tomorrow. Two things... > > Having switched to ata_piix i can confirm that smartd doesn't hand the system > anymore. > > Still.. There seem to be a bug vs. the old drivers somewhere. Will that be > addressed, or should there be a big warning for the old stuff (DEPRECATED?) Could you try bisecting it down to the guilty commit using git-bisect? [ the "old" stuff got few hundred commits in 2.6.25 ] Thanks, 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: [GIT PATCH] scsi fixes for 2.6.25-rc2
Hi, On Sat, Feb 23, 2008 at 09:13:33AM -0600, James Bottomley wrote: > Jeff Garzik (1): > mvsas: Add Marvell 6440 SAS/SATA driver [...] > drivers/scsi/mvsas.c| 2981 > I just noticed that the file permissions on that file are 755 in current git, that was probably not intentional? -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] More accessible usage of custom flags
First of all, thanks for the input! On Sat, Feb 23, 2008 at 5:04 PM, Nick Andrew <[EMAIL PROTECTED]> wrote: > On Sat, Feb 23, 2008 at 04:28:50PM -0500, Nicholas Marquez wrote: > > Does anyone else have any input on this? Tips, suggestions, ideas, > > comments, constructive criticism, anything at all. I am, however, > > trying to avoid a flame war. > > I missed it the first time you posted it, so thanks for resending. > > > > On Sat, Feb 16, 2008 at 9:52 PM, Nicholas Marquez > > <[EMAIL PROTECTED]> wrote: > > > I submitted this patch to the zen-sources Gentoo community and got > > > much praise and has promptly been included. This kind of thing have > > > very likely already been done in other patchsets, but I haven't seen > > > it around, so I've gone ahead and made one. The idea is that one can > > > enable -Os and various other options transparently through standard > > > kernel configuration, so why bar the builder from any other options to > > > pass on to gcc (et al)? One can indeed add one's own flags in the > > > Makefile, but this method is a good deal friendlier. > > Does using this patch reduce the safety of the kernel build at all? i.e. > is it more likely to build different parts of the kernel with > incompatible options with this patch, compared to if the options were > specified in the Makefile? There are a few places in the Makefile where options would need to be entered. This just brings those places together in a clean manner and allows for one to set the flags via the configuration interface. Though it would be excellent if the kernel had more gcc micro-optimization (facilitated by such features as the upcoming gcc 4.3's -finstrument-functions-exclude-function-list option), general CFLAGS used for the entire kernel do not impact the safety of the kernel build, assuming that the options are sane. It would be interesting, however, to see an initiative to tune gcc flags for important functions and sections within the kernel for optimal performance given some sort of envisioned usage. (*hint, kernel devs, hint*) > > > > > I see that people who build a Linux kernel are largely of two types: > > > ~the ones that understand and know enough that they could, with some > > > nudging and learning, become bonafide kernel devs and > > > ~the ones that understand it to some very basic degree and can get > > > through configuring it without too much trouble (though with limited > > > understanding) > > I'm currently cleaning up the Kconfig help descriptions to try to help > the second group of people. Also I think there's a spectrum of > capabilities involved. I'd like kernel building to be a fun and useful > activity for a wider group of people :-) I praise and applaud your efforts. > > > > > Whilst all other kernel devs are hacking away > > > at the rough and tumultuous innards of the kernel, a few people of > > > less confidence and experience (people like me) could polish the > > > outside to make it more appealing to more people. > > Heh, that includes me too. > > > > > __ > > > diff -dur original/init/Kconfig modified/init/Kconfig > > > --- original/init/Kconfig2008-02-16 20:24:22.0 -0500 > > > +++ modified/init/Kconfig2008-02-16 20:53:48.0 -0500 > > I've just started using StGit and it makes it a lot easier to make, send > and manage patches. You should take a look at it. > > > > > @@ -487,6 +487,52 @@ > > >option. If problems are observed, a gcc upgrade may be needed. > > > > > >If unsure, say N. > > > + > > > +menu "Custom flags" > > > + > > > +config CUSTOM_CFLAGS > > > +string "Custom CFLAGS for kernel" > > > +default "" > > > +help > > > +You can use this to easily set custom gcc CFLAGS to be used > for the > > > +entire kernel (including modules). > > > + > > > +ONLY ADD CUSTOM CFLAGS IF YOU KNOW WHAT YOU ARE DOING > > > + > > > +If unsure, leave blank. > > Sorry, but I don't think we need shouting. There are a few options > already which have bad results if you unknowingly choose the wrong option, > like enabling EMBEDDED and turning off the BLOCK layer, yet the help > description doesn't shout. Sorry about that. I didn't mean to portray it as "shouting" so much as a very visible and stern warning. > > Can I suggest: > > > help > You can use this to easily set custom gcc CFLAGS to be used > for the entire kernel build process (including modules). > > Compiler flags can be used for increasing or reducing > optimisation, enabling debugging, cross compilation > and so on. > > If unsure, leave blank. Something else that could be included is a link to the manual for the (currently used) gcc's command flags (http://gcc.gnu.org/onlinedocs/gcc-4.2.3/gcc/index.html#toc_Invoking-GCC) or at least to the online docs, considering that
Re: bcm43xx regression in 2.6.24 (with patch)
On Saturday 23 February 2008 22:32:46 Alexey Zaytsev wrote: > > The insults being? A few quotes, please. > If you really want to know, the > "Because the new driver works, if you just set it up right." > for me was clearly a hint that I'm just an other imcompetent > user, who can't even follow the instructions from linuxwireless.org. Well. That's 99% of all bugreports I receive. You will understand that I won't explain the same crap that's written on linuxwireless.org over and over 20 times each day to random people. And yes, you belong to the group of my "random people", as I don't remember your name from the top of my head. So in 99% of the cases the user did something wrong. But I still don't see the insult. > And you knew that the new driver did no work with the bcm4311 > chips, which is the sad thing. That is not true. It doesn't work with exactly _one_ revision of the bcm4311 card. And that is already fixed in 2.6.25. I'd like to have that in .24-stable, too, but I guess it's too big. It changes some parts of the DMA engine code. > Not true at all. I my first and second emails, there was not a single word > about who broke the driver. There were only the fix, and the explanation, > why the fix is needed. I really appreciate the work done on the b43 driver, > and I'd emmediately switch to it, if only it worked for me*. Yeah. But I don't like that patch. Then people came and said stuff like I _have_ to accept it because it fixes stuff I broke. Excuse me, but nobody can force me to sign off a patch that I am not completely convinced of. _Even_ if it turns out that a commit made by me broke something. Especially, if there's already another fix for the situation queued up in the development kernel. > I'm the one person who investigated the problem, wrote a > patch and sent it to the lkml. After lurking in #bcm-users > for a day, I saw quite a few users asking why the b43 driver > did not work for them, and the best answer they got, was > got read the linuxwireless.org. Are you sure they all were > just unable to upgrade the firmware? Yeah. Experience shows that. Read the archives. > And by the way, the bcm4311 and b44 combination is not > something I assembled just to piss you off. It's what HP puts > in their HP Compaq nx7300 laptops. They were like the > cheapest Core Duo laptops a year ago, and I'm sure they were > not exclusively made. So be it. And you guess what? We already sent a fix for those people upstream a long time ago. It is in 2.6.25. > > So let's > > apply a questionable fix for it that we don't understand. Hopefully > > that fixes it and doesn't break it again for somebody else... . > > > > I provided an alternative fix. In my very first email. > > Sorry, your fix does not work for my hardware. And you know it. Did you _ever_ even try it? http://linuxwireless.org/en/users/Download -- Greetings Michael. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.25-rc2 + smartd = hang
[EMAIL PROTECTED] said: >> But at this point libata is working much better than the old IDE stuff, and >> it really is worth moving things over if you can. > > Ok, I'll take a stab at that tomorrow. Two things... Having switched to ata_piix i can confirm that smartd doesn't hand the system anymore. Still.. There seem to be a bug vs. the old drivers somewhere. Will that be addressed, or should there be a big warning for the old stuff (DEPRECATED?) /A -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.25-rc2 + smartd = hang
[EMAIL PROTECTED] said: > the comment on the very top of drivers/ata says: > tristate "Serial ATA (prod) and Parallel ATA (experimental) drivers" That's the one I was referring to. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make the kernel NTP code hand 64-bit *unsigned* values to do_div() [try #3]
On Sat, 23 Feb 2008, Andrew Morton wrote: > > > Thomas, do you consider ntp to fall under git-hrt? > > > > I'll pick it up. > > > OK. And this is still > git+ssh://master.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-hrt.git#mm, > yes? Yes > Can we please define the scope of that tree? Primary scope is hrtimer, posixtimer, clockevents & Co. In the last month I fed a lot of timekeeping/ntp stuff via -hrt as well. If there is no objection, I'm happy to provide the sink for those. > Please review > > fix-shadowed-variables-in-kernel-posix-cpu-timersc.patch > timers-simplify-lockdep-stuff.patch > hrtimers-simplify-lockdep-stuff.patch > kill-double_spin_lock.patch > ntp-make-the-kernel-ntp-code-hand-64-bit-unsigned-values-to-do_div.patch > > from http://userweb.kernel.org/~akpm/mmotm/broken-out/. I think they're > all probably git-hrt material. Will do tomorrow, when I'm more awake. > Can we get that tree into linux-next too please? Will contact Stephen. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] More accessible usage of custom flags
On Sat, Feb 23, 2008 at 04:28:50PM -0500, Nicholas Marquez wrote: > Does anyone else have any input on this? Tips, suggestions, ideas, > comments, constructive criticism, anything at all. I am, however, > trying to avoid a flame war. I missed it the first time you posted it, so thanks for resending. > On Sat, Feb 16, 2008 at 9:52 PM, Nicholas Marquez > <[EMAIL PROTECTED]> wrote: > > I submitted this patch to the zen-sources Gentoo community and got > > much praise and has promptly been included. This kind of thing have > > very likely already been done in other patchsets, but I haven't seen > > it around, so I've gone ahead and made one. The idea is that one can > > enable -Os and various other options transparently through standard > > kernel configuration, so why bar the builder from any other options to > > pass on to gcc (et al)? One can indeed add one's own flags in the > > Makefile, but this method is a good deal friendlier. Does using this patch reduce the safety of the kernel build at all? i.e. is it more likely to build different parts of the kernel with incompatible options with this patch, compared to if the options were specified in the Makefile? > > I see that people who build a Linux kernel are largely of two types: > > ~the ones that understand and know enough that they could, with some > > nudging and learning, become bonafide kernel devs and > > ~the ones that understand it to some very basic degree and can get > > through configuring it without too much trouble (though with limited > > understanding) I'm currently cleaning up the Kconfig help descriptions to try to help the second group of people. Also I think there's a spectrum of capabilities involved. I'd like kernel building to be a fun and useful activity for a wider group of people :-) > > Whilst all other kernel devs are hacking away > > at the rough and tumultuous innards of the kernel, a few people of > > less confidence and experience (people like me) could polish the > > outside to make it more appealing to more people. Heh, that includes me too. > > __ > > diff -dur original/init/Kconfig modified/init/Kconfig > > --- original/init/Kconfig2008-02-16 20:24:22.0 -0500 > > +++ modified/init/Kconfig2008-02-16 20:53:48.0 -0500 I've just started using StGit and it makes it a lot easier to make, send and manage patches. You should take a look at it. > > @@ -487,6 +487,52 @@ > >option. If problems are observed, a gcc upgrade may be needed. > > > >If unsure, say N. > > + > > +menu "Custom flags" > > + > > +config CUSTOM_CFLAGS > > +string "Custom CFLAGS for kernel" > > +default "" > > +help > > +You can use this to easily set custom gcc CFLAGS to be used for > > the > > +entire kernel (including modules). > > + > > +ONLY ADD CUSTOM CFLAGS IF YOU KNOW WHAT YOU ARE DOING > > + > > +If unsure, leave blank. Sorry, but I don't think we need shouting. There are a few options already which have bad results if you unknowingly choose the wrong option, like enabling EMBEDDED and turning off the BLOCK layer, yet the help description doesn't shout. Can I suggest: help You can use this to easily set custom gcc CFLAGS to be used for the entire kernel build process (including modules). Compiler flags can be used for increasing or reducing optimisation, enabling debugging, cross compilation and so on. If unsure, leave blank. The boilerplate "If unsure, leave blank" covers (or is meant to cover) the situation where the user does not know what they are doing. It says "If you don't know what you are doing, just leave this field blank, and everything will be OK" ... except it is put in a non-threatening, non-demeaning way. The paragraph in the middle enhances the "help" component of the help description, by saying why you might want to use that option. > > +config CUSTOM_LDFLAGS > > [...] > > +config CUSTOM_AFLAGS > > [...] > > +config CUSTOM_MAKEFLAGS > > [...] Similar comments apply. Nick. -- PGP Key ID = 0x418487E7 http://www.nick-andrew.net/ PGP Key fingerprint = B3ED 6894 8E49 1770 C24A 67E3 6266 6EB9 4184 87E7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] mvsas: fix build warning, clean prototypes
- Fix build 'make randconfig' build warning spotted by Toralf Foerster: drivers/scsi/mvsas.c: In function 'mvs_hexdump': drivers/scsi/mvsas.c:715: error: implicit declaration of function 'isalnum' - Remove unneeded prototypes (spotted by hch) Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> --- NOTE: A proper fix, as noted in initial review (and by hch), would be to convert this driver over to using lib/hexdump.c, to eliminate a hand-rolled hexdump function. drivers/scsi/mvsas.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/drivers/scsi/mvsas.c b/drivers/scsi/mvsas.c index 30e20e6..d4a6ac3 100755 --- a/drivers/scsi/mvsas.c +++ b/drivers/scsi/mvsas.c @@ -35,6 +35,7 @@ #include #include #include +#include #include #include @@ -632,15 +633,6 @@ static int mvs_phy_control(struct asd_sas_phy *sas_phy, enum phy_func func, void *funcdata); static u32 mvs_read_phy_ctl(struct mvs_info *mvi, u32 port); static void mvs_write_phy_ctl(struct mvs_info *mvi, u32 port, u32 val); -static u32 mvs_read_port(struct mvs_info *mvi, u32 off, u32 off2, u32 port); -static void mvs_write_port(struct mvs_info *mvi, u32 off, u32 off2, - u32 port, u32 val); -static u32 mvs_read_port_cfg_data(struct mvs_info *mvi, u32 port); -static void mvs_write_port_cfg_data(struct mvs_info *mvi, u32 port, u32 val); -static void mvs_write_port_cfg_addr(struct mvs_info *mvi, u32 port, u32 addr); -static u32 mvs_read_port_vsr_data(struct mvs_info *mvi, u32 port); -static void mvs_write_port_vsr_data(struct mvs_info *mvi, u32 port, u32 val); -static void mvs_write_port_vsr_addr(struct mvs_info *mvi, u32 port, u32 addr); static u32 mvs_read_port_irq_stat(struct mvs_info *mvi, u32 port); static void mvs_write_port_irq_stat(struct mvs_info *mvi, u32 port, u32 val); static void mvs_write_port_irq_mask(struct mvs_info *mvi, u32 port, u32 val); @@ -649,9 +641,6 @@ static u32 mvs_read_port_irq_mask(struct mvs_info *mvi, u32 port); static u32 mvs_is_phy_ready(struct mvs_info *mvi, int i); static void mvs_detect_porttype(struct mvs_info *mvi, int i); static void mvs_update_phyinfo(struct mvs_info *mvi, int i, int get_st); -static void mvs_free_reg_set(struct mvs_info *mvi, struct mvs_port *port); -static u8 mvs_assign_reg_set(struct mvs_info *mvi, struct mvs_port *port); -static u32 mvs_is_sig_fis_received(u32 irq_status); static int mvs_scan_finished(struct Scsi_Host *, unsigned long); static void mvs_scan_start(struct Scsi_Host *); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.25-rc2 hangs after "Suspending console(s)"
On Wednesday, 20 of February 2008, Tino Keitel wrote: > On Tue, Feb 19, 2008 at 09:52:22 +0100, Tino Keitel wrote: > > On Mon, Feb 18, 2008 at 20:49:04 +0100, Pavel Machek wrote: > > > On Mon 2008-02-18 01:28:15, Tino Keitel wrote: > > > > Hi folks, > > > > > > > > with 2.6.25-rc2, my Mac mini Core Duo hangs at suspend. The last > > > > message on the console is "Suspending console(s)". I also tried some > > > > other versions after 2.6.24, all of them fail with this hang. > > > > > > Try adding 'no_console_suspend' to kernel command line. > > > > Thanks, that gave a bit insight. The last message is now: > > > > ACPI: PCI interrupt for device :00:02.0 disabled > > > > This is my graphics card: > > > > 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile > > 945GM/GMS, 943/940GML Express Integrated Graphics Controller > > > > So it looks like the recent changes that should repair console > > sudpend/resume for Intel graphics broke suspend for me. > > It looks like I was wrong. It also hangs when the i915 module isn't > loaded. Please have a look at: http://bugzilla.kernel.org/show_bug.cgi?id=10065 Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24 panics initializing ne2k in mips.
On Saturday 23 February 2008 01:56:42 Samuel Masham wrote: > On Sat, Feb 23, 2008 at 7:19 AM, Rob Landley <[EMAIL PROTECTED]> wrote: > > The patches that fixed it for me were: > > > > http://kernel.org/hg/index.cgi/linux-2.6/rev/85295 > > http://kernel.org/hg/index.cgi/linux-2.6/rev/85296 > > > > Which, as you can see, were already committed to the kernel repository > > during the 2.6.25 merge window. ... > This fixes the 2.6.24 kernel for qemu, I would like to see these > patches put into the stable series. > > Is that OK for everyone? if they are in the 2.6.25 tree then we just > send the commit ids to the stable team... Sounds good to me: 24649c00ca334955ac7d8a79f5a7834fc7ea441d 46f4f8f665080900e865392f4b3593be463bf0d8 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/
