Re: [PATCH] watchdog: add Nano 7240 driver
On 280, 10 07, 2007 at 01:39:28AM +1000, Gilles Gigan wrote:
> from: Gilles Gigan <[EMAIL PROTECTED]>
>
> Adds watchdog driver for EPIC Nano 7240 boards from IEI
>
> Signed-off-by: Gilles Gigan <[EMAIL PROTECTED]>
> ---
>
> diff -uprN -X linux-2.6.23-rc9/Documentation/dontdiff
> linux-2.6.23-rc9/drivers/char/watchdog/Kconfig
> linux-2.6.23-rc9-dirty/drivers/char/watchdog/Kconfig
> --- linux-2.6.23-rc9/drivers/char/watchdog/Kconfig2007-10-06
> 01:43:44.0 +1000
> +++ linux-2.6.23-rc9-dirty/drivers/char/watchdog/Kconfig 2007-10-06
> 14:49:03.0 +1000
> @@ -455,6 +455,19 @@ config SBC8360_WDT
>
> Most people will say N.
>
> +config SBC7240_WDT
> + tristate "SBC Nano 7240 Watchdog Timer"
> + depends on X86_32
> + ---help---
> + This is the driver for the hardware watchdog found on the IEI
> + single board computers EPIC Nano 7240 (and likely others). This
> + watchdog simply watches your kernel to make sure it doesn't freeze,
> + and if it does, it reboots your computer after a certain amount of
> + time.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called sbc7240_wdt.
> +
> config CPU5_WDT
> tristate "SMA CPU5 Watchdog"
> depends on X86
> diff -uprN -X linux-2.6.23-rc9/Documentation/dontdiff
> linux-2.6.23-rc9/drivers/char/watchdog/Makefile
> linux-2.6.23-rc9-dirty/drivers/char/watchdog/Makefile
> --- linux-2.6.23-rc9/drivers/char/watchdog/Makefile 2007-10-06
> 01:43:44.0 +1000
> +++ linux-2.6.23-rc9-dirty/drivers/char/watchdog/Makefile 2007-10-06
> 14:49:03.0 +1000
> @@ -71,6 +71,7 @@ obj-$(CONFIG_SCx200_WDT) += scx200_wdt.o
> obj-$(CONFIG_PC87413_WDT) += pc87413_wdt.o
> obj-$(CONFIG_60XX_WDT) += sbc60xxwdt.o
> obj-$(CONFIG_SBC8360_WDT) += sbc8360.o
> +obj-$(CONFIG_SBC7240_WDT) += sbc7240.o
> obj-$(CONFIG_CPU5_WDT) += cpu5wdt.o
> obj-$(CONFIG_SMSC37B787_WDT) += smsc37b787_wdt.o
> obj-$(CONFIG_W83627HF_WDT) += w83627hf_wdt.o
> diff -uprN -X linux-2.6.23-rc9/Documentation/dontdiff
> linux-2.6.23-rc9/drivers/char/watchdog/sbc7240_wdt.c
> linux-2.6.23-rc9-dirty/drivers/char/watchdog/sbc7240_wdt.c
> --- linux-2.6.23-rc9/drivers/char/watchdog/sbc7240_wdt.c 1970-01-01
> 10:00:00.0 +1000
> +++ linux-2.6.23-rc9-dirty/drivers/char/watchdog/sbc7240_wdt.c
> 2007-10-06
> 16:54:52.0 +1000
> @@ -0,0 +1,311 @@
> +/*
> + * NANO7240 SBC Watchdog device driver
> + *
> + * Based on w83877f.c by Scott Jennings,
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation;
> + *
> + * Software distributed under the License is distributed on an "AS IS"
> + * basis, WITHOUT WARRANTY OF ANY KIND, either express or
> + * implied. See the License for the specific language governing
> + * rights and limitations under the License.
> + *
> + * (c) Copyright 2007 Gilles GIGAN
> + *
> + * 10/01- 2007 [Initial revision]
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define PREFIX "sbc7240_wdt: "
> +
> +#define ENABLE_SBC7240_PORT 0x443
> +#define DISABLE_SBC7240_PORT 0x043
> +#define SET_TIMEOUT_SBC7240_PORT ENABLE_SBC7240_PORT
> +#define WDT_MAGIC_CHAR 'V'
> +
> +#define WATCHDOG_TIMEOUT 30 /* 30 sec default timeout */
> +#define WATCHDOG_MAX_TIMEOUT 255
> +static int timeout = WATCHDOG_TIMEOUT; /* in seconds */
> +module_param(timeout, int, 0);
> +MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds. (1<=timeout<="
> + __MODULE_STRING(WATCHDOG_MAX_TIMEOUT) ", default="
> + __MODULE_STRING(WATCHDOG_TIMEOUT) ")");
> +
> +#ifdef CONFIG_WATCHDOG_NOWAYOUT
> +#define NOWAYOUT 1
> +#else
> +#define NOWAYOUT 0
> +#endif
> +static int nowayout = NOWAYOUT;
You don't need this #ifdef crap. Just use WATCHDOG_NOWAYOUT instead.
> +module_param(nowayout, int, 0);
> +MODULE_PARM_DESC(nowayout, "Disable watchdog when closing device file");
> +
> +#define OPEN_STATUS_BIT 0
> +#define ENABLED_STATUS_BIT 1
> +static unsigned long wdt_status;
> +
> +/*
> + * Utility routines
> + */
> +
> +static void wdt_disable(void)
> +{
> + /* disable the watchdog */
> + if (test_and_clear_bit(ENABLED_STATUS_BIT, &wdt_status)) {
> + inb_p(DISABLE_SBC7240_PORT);
> + printk(KERN_INFO PREFIX "Watchdog timer is now disabled.\n");
> + }
> +}
> +
> +static void wdt_enable(void)
> +{
> + /* enable the watchdog */
> + if (!test_and_set_bit(ENABLED_STATUS_BIT, &wdt_status)) {
> + inb_p(ENABLE_SBC7240_PORT);
Re: Network slowdown due to CFS
* Jarek Poplawski <[EMAIL PROTECTED]> wrote: > > [...] The timeslices of tasks (i.e. the time they spend on a CPU > > without scheduling away) is _not_ maintained directly in CFS as a > > per-task variable that can be "cleared", it's not the metric that > > drives scheduling. Yes, of course CFS too "slices up CPU time", but > > those slices are not the per-task variables of traditional > > schedulers and cannot be 'cleared'. > > It's not about this comment alone, but this comment plus "no notion" > comment, which appears in sched-design-CFS.txt too. ok - i've re-read it and it indeed is somewhat confusing without additional context. I'll improve the wording. (sched-design-CFS.txt needs an update anyway) 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: OHCI root_port_reset() deadly loop...
> From [EMAIL PROTECTED] Sat Oct 6 23:56:49 2007 > > When root_port_reset() in ohci-hub.c polls for the end of the reset, > it puts no limit on the loop and will only exit the loop when either > the RH_PS_PRS bit clears or the register returns all 1's (the latter > condition is a recent addition). The all-ones typically indicating something like CardBus eject not preceded by a "polite" driver shutdown. > If for some reason the bit never clears, we sit here forever and never > exit the loop. > > I actually hit this on one of my machines, and I'm trying to track > down what's happening. Sounds like a hardware issue -- unless something else is trashing controller state. We've not observed that specific hardware failure before, for what it's worth. Is this SPARC, or is ACPI potentially in play? PCI, or non-PCI? Are the other ports still behaving? Is EHCI maybe trying to switch ownership of that port? Is maybe the (newish) autosuspend stuff kicking in? The OHCI spec requires the controller to stop the reset itself. Most silicon seems to have a built-in 10 msec timeout. > Regardless of why my machine is doing this, there absolutely should be > some upper bound put on the number of times we will run through this > loop, perhaps enough such that up to 5 seconds elapses waiting for the > reset bit to clear. And if it times out we should print a loud > message onto the console, but still try to continue. Patches accepted. :) Since the PRS bit is specified as "write one", with writing zero as no-effect (since the rest is hardware-timed), the only recovery procedure might involve resetting the whole controller. Messy, and not something the usb core has historically handled very well. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OHCI root_port_reset() deadly loop...
From: David Brownell <[EMAIL PROTECTED]> Date: Sun, 07 Oct 2007 00:31:41 -0700 > Is this SPARC, or is ACPI potentially in play? PCI, or non-PCI? It's sparc64 on PCI. > Are the other ports still behaving? Is EHCI maybe trying to switch > ownership of that port? Is maybe the (newish) autosuspend stuff > kicking in? I wouldn't know, the machine hangs and doesn't get any further. > Patches accepted. :) I'm 700 patches deep with an additionally large backlog of patches to apply for the networking and sparc64 tree. I don't have the time, which is why I reported the problem to the OHCI maintainer instead of letting it slip through the cracks. > Since the PRS bit is specified as "write one", with writing zero > as no-effect (since the rest is hardware-timed), the only recovery > procedure might involve resetting the whole controller. Messy, > and not something the usb core has historically handled very well. At a minimum you should exit the loop and print out a warning messages and try to continue even without trying to reset the whole controller if that will take some developer effort. Anything is better than just hanging there forever. Not every user knows to hit ALT-SYSRQ then 'P' to get a register dump to figure out why their computer stopped booting. Every register polling loops, without exception, should have a limit and exit with an error indication when that limit is reached. It will never hang someones machine, because although not this time, in many cases these kinds of hangs are absolutely impossible to debug (interrupts disabled, critical lock held, etc.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lockdep: how to tell it multiple pte locks is OK?
On Sat, 2007-10-06 at 23:31 -0700, Jeremy Fitzhardinge wrote:
> I'm writing some code which is doing some batch processing on pte pages,
> and so wants to hold multiple pte locks at once. This seems OK, but
> lockdep is giving me the warning:
>
> =
> [ INFO: possible recursive locking detected ]
> 2.6.23-rc9-paravirt #1673
> -
> init/1 is trying to acquire lock:
> (__pte_lockptr(new)){--..}, at: [] lock_pte+0x10/0x15
>
> but task is already holding lock:
> (__pte_lockptr(new)){--..}, at: [] lock_pte+0x10/0x15
>
> other info that might help us debug this:
> 4 locks held by init/1:
> #0: (&mm->mmap_sem){}, at: [] copy_process+0xab4/0x12bf
> #1: (&mm->mmap_sem/1){--..}, at: [] copy_process+0xac4/0x12bf
> #2: (&mm->page_table_lock){--..}, at: [] xen_dup_mmap+0x11/0x24
> #3: (__pte_lockptr(new)){--..}, at: [] lock_pte+0x10/0x15
>
> stack backtrace:
> [] show_trace_log_lvl+0x1a/0x2f
> [] show_trace+0x12/0x14
> [] dump_stack+0x16/0x18
> [] __lock_acquire+0x195/0xc5f
> [] lock_acquire+0x88/0xac
> [] _spin_lock+0x35/0x42
> [] lock_pte+0x10/0x15
> [] pin_page+0x67/0x17e
> [] pgd_walk+0x168/0x1ba
> [] xen_pgd_pin+0x42/0xf8
> [] xen_dup_mmap+0x19/0x24
> [] copy_process+0xc79/0x12bf
> [] do_fork+0x99/0x1bf
> [] sys_clone+0x33/0x39
> [] syscall_call+0x7/0xb
> ===
>
>
> I presume this is because I'm holding multiple pte locks (class
> "__pte_lockptr(new)"). Is there some way I can tell lockdep this is OK?
Yeah, the typical way is to use spin_lock_nested(lock, nesting_level),
this allows one to annotate these nestings. However, nesting_level must
not be larger than 8, so if your batch is larger than that, we have a
problem.
> I'm presume I'm the first person to try holding multiple pte locks at
> once, so there's no existing locking order for these locks.
Not quite, things like copy_pte_range() take 2.
> I'm always
> traversing and locking the pagetable in virtual address order (and this
> seems like a sane-enough rule for anyone else who wants to hold multiple
> pte locks).
I'm quite sure copy_pte_range() could be used so that it violates that
order.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Cute feature: colored printk output
On Oct 6 2007 20:50, Bill Davidsen wrote: >> >>> I start my root xterm in white on blue for identification, so color coding >>> sounds like a great idea to me. >> >> This has nothing to do with xterms, this is "VGA color console" only. >> xterm config is in /usr/share/X11/app-defaults/XTerm-color. > > Try reparsing that... I said I use color coding in root xterm, so I am > generally in favor of the color coding concept to make important messages > obvious. Is that clearer? A reparse did 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: sata_sil24 broken since 2.6.23-rc4-mm1
On 10/5/07, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> So I will use the weekend to see if I can find out who issues this
> command and add more debug to that place...
I added some DPRINTK to sil24_qc_issue and sil24_fill_sg, but I only
found one suspicious thing.
My sil24_fill_sg now looks like this:
static inline void sil24_fill_sg(struct ata_queued_cmd *qc,
struct sil24_sge *sge)
{
struct scatterlist *sg;
ata_for_each_sg(sg, qc) {
sge->addr = cpu_to_le64(sg_dma_address(sg));
sge->cnt = cpu_to_le32(sg_dma_len(sg));
if (ata_sg_is_last(sg, qc))
sge->flags = cpu_to_le32(SGE_TRM);
else
sge->flags = 0;
DPRINTK("flags,addr,cnt = 0x%x, 0x%X, 0x%X\n", sge->flags,
sge->addr, sge->cnt);
sge++;
}
}
Suspicious is, that *all* output from this DPRINTK shows flags as 0x0,
so the last sg is never terminated (SGE_TRM is 1<<31)?
But if that is the cause, how is this working at all? Or am I doing
something stupid?
Timing and outputs from five boots:
good:bad:
more morebootmore
3->35 3->353->35 3->35 3->35
3->2a 2->352->35 3->2a 3->2a
3->setup 2->2a2->2a 3->setup 3->setup
2->35 2->352->35 2->35 2->35
1->35 3->2a3->2a 1->35 1->35
2->2a 3->setup 3->setup 2->2a 2->2a
1->2a 1->351->35 1->2a 1->2a
2->35 1->2a1->2a 2->35
1->35 1->351->35 1->35
3->int3->int 3->int3->int3->int
3->35 3->353->35 3->35 3->35
1->5DF/1439C 1->5DC/1439C1->5DE/1439C
2->5E0/143BC 2->5DE/143BC2->5DF/143BC
sg:170E sg:1AAB sg:1A60
XXX:
5DD 5DF 5DC 5DF 5DE
5E0 5E0 5DE 5E0 5DF
The first three columns where working tries, the last two failed one drive.
column 1: ATA_DEBUG added, reboot
column 2: +my additions, reboot
column 3: +my additions, cold boot, wanted to make it fail, but worked
column 4: ATA_DEBUG added, cold boot
column 5: +my additions, cold boot
[x]->[y]: x is the ata-port, 1+2 on the sata_sil24, 3 on sata_nv with swncq
y:35 -> SYNCHRONIZE_CACHE commands that where send to the drive
y:2a -> WRITE_10 commands that where send to the drive
y:setup -> Debug from swncq: nv_swncq_dmafis: dma setup tag 0x0
y:int -> Debug from swncq: nv_swncq_host_interrupt: id 0x3 SWNCQ:
qc_active 0x1 ...
The lines before the XXX:
x->a/b: x is the ata-port, a the paddr from sil24_qc_issue, b the
activate from sil24_qc_issue
All outputs from sil24_qc_issue where identical in each boot sequence,
only differed from run to run.
sg:a: a is the sge->addr from sil24_fill_sg
The lines after the XXX:
This are the addresses that the XXX-printk from sil24_port_start prints.
I hope I explained enough what above table should mean.
This hole sequence (two syncs and one write to each drive) happens
between the output:
[ 40.30] md1: bitmap initialized from disk: read 10/10 pages, set 87 bits
[ 40.32] created bitmap (145 pages) for device md1
and the error on a bad boot:
[ 70.68] ata2.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
[ 70.70] ata2.00: cmd 61/08:00:09:d6:42/00:00:25:00:00/40 tag 0
cdb 0x0 data 4096 out
or if on a good boot:
[ 40.91] md: considering sdb1 ...
(sdb1 is part of another raid)
(If someone whats to complete bootlogs, just ask)
So now I have two questions:
1) What happens in sil24_fill_sg with SGE_TRM?
2) If that is ok, should I try to add debug to sil24_error_intr and/or
sil24_host_intr?
Torsten
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/5] forcedeth: interrupt handling cleanup
* Jeff Garzik <[EMAIL PROTECTED]> wrote: > - spin_unlock(&np->lock); > - printk(KERN_DEBUG "%s: too many iterations (%d) in > nv_nic_irq.\n", dev->name, i); > - break; i like that! One forcedeth annoyance that triggers frequently on one of my testboxes is: [ 120.955202] eth0: too many iterations (6) in nv_nic_irq. [ 121.233865] eth0: too many iterations (6) in nv_nic_irq. [ 129.215450] eth0: too many iterations (6) in nv_nic_irq. [ 139.734408] eth0: too many iterations (6) in nv_nic_irq. [ 144.546811] eth0: too many iterations (6) in nv_nic_irq. [ 153.811005] eth0: too many iterations (6) in nv_nic_irq. [ 154.695879] eth0: too many iterations (6) in nv_nic_irq. [ 155.455078] eth0: too many iterations (6) in nv_nic_irq. [ 173.912162] eth0: too many iterations (6) in nv_nic_irq. 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: [PATCH 0/5] forcedeth: several proposed updates for testing
* Jeff Garzik <[EMAIL PROTECTED]> wrote:
> * I feel TX NAPI is a useful tool, because it provides an independent TX
> process control point and system load feedback point.
> Thus I felt this was slightly superior to tasklets.
/me agrees violently
btw., when i played with this tunable under -rt:
enum {
NV_OPTIMIZATION_MODE_THROUGHPUT,
NV_OPTIMIZATION_MODE_CPU
};
static int optimization_mode = NV_OPTIMIZATION_MODE_THROUGHPUT;
the MODE_CPU one gave (much) _higher_ bandwidth. The queueing model in
forcedeth seemed to be not that robust and i think a single queueing
model should be adopted instead of this tunable. (which i think just hid
some bug/dependency) But i never got to the bottom of it so it's just
the impression i got.
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: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)
On Sun, 7 Oct 2007, Oleg Verych wrote:
> On Sat, Oct 06, 2007 at 11:10:48PM +0200, Sam Ravnborg wrote:
> > On Sat, Oct 06, 2007 at 10:47:21PM +0200, Oleg Verych wrote:
> > > On Sat, Oct 06, 2007 at 08:59:20PM +0200, Sam Ravnborg wrote:
> > > > > Maintenance and acceptance of the m4/make/perl/C/ncurses community of
> > > > > my
> > > > > mainly `TERM=linux ; sed && sh' approach is more important for me.
> > > >
> > > > There is noone having trouble with ncurses dependency today.
> > >
> > > Who wants to meet a zombie anyway?
> >
> > Finding quotes from old threads does not in any way prove your point.
>
> This makes air hot for Roman. I want to prove my point not by words. But
> have to reply with something on my side, until i have work done.
>
> []
> > And until now you have not given one single example of real
> > problems that will be solved by a total rewrite and cannot
> > be solved otherwise.
>
> If you didn't see them in that, what i've posted, then i just have to
> say: i don't need to give anything. There are kvm, lguest, xen with ext2,
> ext3, xfs, etc. And there's no working alternative to build/config
> system. Thus, let me have my try OK? Thanks!
Let's add an alternative to the Makefiles, too
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 8/9] compat_ioctl: call disk->fops->compat_ioctl without BKL
On Sat, Oct 06, 2007 at 08:19:10PM +0200, Arnd Bergmann wrote: > Normally, all compat_ioctl operations are called without the BKL, the > block device operations are an exception to this rule. > > Make this work the same as the other handlers. > > Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> > > --- > It would be good to find out whether it has been using the BKL > on purpose or by accident, before this patch gets applied. Leave it alone, for now - I'm rebasing my series on top of your 1--7 and it will both makes ->ioctl() and ->compat_ioctl() called unlocked and switches ->compat_ioctl() to passing bdev instead of struct file (->unlocked_ioctl() simply dies). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 9/9] compat_ioctl: fix compat_fd_ioctl pointer access
On Sat, Oct 06, 2007 at 08:19:11PM +0200, Arnd Bergmann wrote: > As found by sparse, a user space pointer is assigned to a kernel > data structure while calling other code with set_fs(KERNEL_DS), > which could lead to leaking kernel data if that pointer is > ever accessed. > > I could not find any place in the floppy drivers that actually > uses that pointer, but assigning it to an empty string is > a safer choice and gets rid of the sparse warning. FWIW, I'd kill kmalloc(), switched to compat_alloc_user_space() and copy_in_user() / get_user()+put_user(). And kill set_fs() around that sys_ioctl()... Separate from the rest of this series, though. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Revert "intel_agp: fix stolen mem range on G33"
On 10/06/2007 09:29 PM, Keith Packard wrote: > On Sat, 2007-10-06 at 08:59 -0700, Linus Torvalds wrote: > >> We do have a rule about "no regressions", so I think we'll have to do the >> revert, but it would be nice to hear what the consequences for the revert >> is for the affected hardware and new X.org.. Agree with the first part. Here comes the X log diff: --- orig2007-10-07 11:57:50.0 +0200 +++ agp 2007-10-07 11:56:07.0 +0200 @@ -3,7 +3,7 @@ Release Date: 19 April 2007 X Protocol Version 11, Revision 0, Release 1.3 Build Operating System: Fedora Core 7 Red Hat, Inc. -Current Operating System: Linux bellona 2.6.23-rc8-mm2_64 #58 SMP Fri Sep 28 08:52:12 CEST 2007 x86_64 +Current Operating System: Linux bellona 2.6.23-rc8-mm2_64 #59 SMP Sun Oct 7 11:43:55 CEST 2007 x86_64 Build Date: 11 June 2007 Build ID: xorg-x11-server 1.3.0.0-9.fc7 Before reporting problems, check http://wiki.x.org @@ -12,7 +12,7 @@ Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. -(==) Log file: "/var/log/Xorg.0.log", Time: Sun Oct 7 11:57:20 2007 +(==) Log file: "/var/log/Xorg.0.log", Time: Sun Oct 7 11:54:36 2007 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Default Layout" (**) |-->Screen "Screen0" (0) @@ -34,7 +34,8 @@ (**) Option "BlankTime" "8" (**) Option "StandbyTime" "10" (**) Extension "Composite" is enabled -(II) Open ACPI successful (/var/run/acpid.socket) +(WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) +(II) No APM support in BIOS or kernel (II) Loader magic: 0x7be760 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 @@ -760,18 +761,18 @@ (II) intel(0): 0x0800-0x09ff: textures (32768 kB) (II) intel(0): 0x1000:end of aperture drmOpenDevice: node name is /dev/dri/card0 -drmOpenDevice: open result is 10, (OK) +drmOpenDevice: open result is 9, (OK) drmOpenDevice: node name is /dev/dri/card0 -drmOpenDevice: open result is 10, (OK) +drmOpenDevice: open result is 9, (OK) drmOpenByBusid: Searching for BusID pci::00:02.0 drmOpenDevice: node name is /dev/dri/card0 -drmOpenDevice: open result is 10, (OK) -drmOpenByBusid: drmOpenMinor returns 10 +drmOpenDevice: open result is 9, (OK) +drmOpenByBusid: drmOpenMinor returns 9 drmOpenByBusid: drmGetBusid reports pci::00:02.0 (II) intel(0): [drm] DRM interface version 1.3 (II) intel(0): [drm] created "i915" driver at busid "pci::00:02.0" (II) intel(0): [drm] added 8192 byte SAREA at 0x2efff000 -(II) intel(0): [drm] mapped SAREA 0x2efff000 to 0x7f794b3bb000 +(II) intel(0): [drm] mapped SAREA 0x2efff000 to 0x7fd637f76000 (II) intel(0): [drm] framebuffer handle = 0xd400 (II) intel(0): [drm] added 1 reserved context for kernel (II) intel(0): [drm] Registers = 0xffa8 @@ -838,11 +839,11 @@ (II) Initializing built-in extension DAMAGE (II) Initializing built-in extension XEVIE drmOpenDevice: node name is /dev/dri/card0 -drmOpenDevice: open result is 11, (OK) +drmOpenDevice: open result is 10, (OK) drmOpenByBusid: Searching for BusID pci::00:02.0 drmOpenDevice: node name is /dev/dri/card0 -drmOpenDevice: open result is 11, (OK) -drmOpenByBusid: drmOpenMinor returns 11 +drmOpenDevice: open result is 10, (OK) +drmOpenByBusid: drmOpenMinor returns 10 drmOpenByBusid: drmGetBusid reports pci::00:02.0 (WW) AIGLX: 3D driver claims to not support visual 0x23 (WW) AIGLX: 3D driver claims to not support visual 0x24 @@ -906,7 +907,7 @@ (II) : ps2EnableDataReporting: succeeded (II) Mouse0-usb-:00:1d.0-1.2/input0: Off (II) intel(0): [drm] removed 1 reserved context for kernel -(II) intel(0): [drm] unmapping 8192 bytes of SAREA 0x2efff000 at 0x7f794b3bb000 +(II) intel(0): [drm] unmapping 8192 bytes of SAREA 0x2efff000 at 0x7fd637f76000 (EE) intel(0): I830 Vblank Pipe Setup Failed 0 (EE) intel(0): I830 Vblank Pipe Setup Failed 0 (EE) intel(0): I830 Vblank Pipe Setup Failed 0 And it seems to work, so I think no regression here. regards, -- Jiri Slaby ([EMAIL PROTECTED]) Faculty of Informatics, Masaryk University - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] Time-based RFC 4122 UUID generator
Hello Valdis,
On Sunday 07 October 2007, [EMAIL PROTECTED] wrote:
> On Sat, 06 Oct 2007 15:53:37 +0200, Helge Deller said:
> > --- a/drivers/char/random.c
> > +++ b/drivers/char/random.c
> > @@ -1157,6 +1158,8 @@ void generate_random_uuid(unsigned char uuid_out[16])
> > uuid_out[6] = (uuid_out[6] & 0x0F) | 0x40;
> > /* Set the UUID variant to DCE */
> > uuid_out[8] = (uuid_out[8] & 0x3F) | 0x80;
> > + /* Set multicast bit to avoid conflicts with NIC MAC addresses */
> > + uuid_out[10] |= 0x80;
> > }
>
>
> Erm, was it *intended* that you also changed the behavior of
> generate_random_uuid()?
Thanks that you ask!
I really should have mentioned it in my initial posting.
Yes, this change was intentional, as it in fact fixes a possible bug in the
original code.
Section 4.1.6 in RFC 4122 states regarding the "NodeID":
: For systems with no IEEE address, a randomly or pseudo-randomly
: generated value may be used; see Section 4.5. The multicast bit must
: be set in such addresses, in order that they will never conflict with
: addresses obtained from network cards.
So up to now it was just pure ("random") luck if this bit was set or not.
While at it...
My patch addressed another small non-critical glitch in the current
implementation as well.
An "strace cat /proc/sys/kernel/random/uuid" shows:
:
: open("/proc/sys/kernel/random/uuid", O_RDONLY|O_LARGEFILE) = 3
: fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
: read(3, "378244d0-9b27-4f92-8b3a-386ed526"..., 1024) = 37
: write(1, "378244d0-9b27-4f92-8b3a-386ed526"...,
37378244d0-9b27-4f92-8b3a-386ed52692a8) = 37
: read(3, "", 1024) = 0
: close(3)= 0
: ...
The first read() returns the newly generated random uuid.
The second read() just returns zero, but the current implementation then
already created a new uuid which wasn't used at all.
Although this is not critical, it was nevertheless leaking unnecessarily
entropy from the pool.
For the case of the new time-based UUIDs it was worse. It unnecessary
incremented the clock_seq number.
This issue is addressed by this part of my patch (esp.: "*ppos > 0"):
@@ -1191,13 +1317,13 @@ static int proc_do_uuid(ctl_table *table, int write,
struct file *filp,
ctl_table fake_table;
unsigned char buf[64], tmp_uuid[16], *uuid;
- uuid = table->data;
- if (!uuid) {
- uuid = tmp_uuid;
- uuid[8] = 0;
+ /* random/time UUIDs need to be read completely at once */
+ if (table->ctl_name != RANDOM_BOOT_ID && *ppos > 0) {
+ *lenp = 0;
+ return 0;
}
Helge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
libertas and endianness
Somehow (haven't found out why it suddenly got compiled, no .config
changes) this showed up in the list of warnings in 2.6.23-rc9 compared
to -rc8 on one of my m68k builds:
| drivers/net/wireless/libertas/cmd.c:189: warning: large integer implicitly
truncated to unsigned type
| drivers/net/wireless/libertas/cmd.c:195: warning: large integer implicitly
truncated to unsigned type
The offending lines are:
| wep->keytype[i] = cpu_to_le16(cmd_type_wep_40_bit);
| wep->keytype[i] = cpu_to_le16(cmd_type_wep_104_bit);
I.e. it tries to store 0x0100 resp. 0x0200 into keytype[i], which is is u8.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] New message-logging API (kprint)
On 10/6/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote: > On Sat, 6 Oct 2007 01:01:10 +0200 > "Miguel Ojeda" <[EMAIL PROTECTED]> wrote: > > > On 10/5/07, Rob Landley <[EMAIL PROTECTED]> wrote: > > > On Friday 05 October 2007 2:01:08 am Miguel Ojeda wrote: > > > > > > > > I think we all are trying to give ideas to improve the current logging > > > > API. > > > > > > > > If something works, it's great; but it doesn't mean that it can't be > > > > improved, right? > > > > > > I'm all for improving the kernel, but my definition of "improved" does not > > > include every possible change. I balance "smaller and simpler" with "more > > > features". Complexity is a cost, we should get something in return. > > > > > > Making the same functionality simpler makes it "cheaper" from a > > > development > > > standpoint. Smaller and simpler means less overhead, less to understand, > > > less to go wrong. It's also attractive to me personally, because I am a > > > Bear > > > of Very Little Brain and between the dozen or so projects I try to > > > follow, I > > > have trouble fitting all the details in my head when they're tricky or > > > they > > > change ever time I look at them. (Especially when I get distracted from > > > one > > > of those projects for 3-6 months and come back to find it changed.) > > > > I fully agree. However, I just gave away some ideas that I believe > > they can make printk() easier and more understandable than it is right > > now (for example, standardizing kprint_[registered,detected,...] > > messages is something that I think it can simplify everyday use of > > messages, both to people who has to code it, review/search the code > > and people that reads the kernel output). > > > > > > > > I recognize constantly having to learn new things as part of the cost of > > > living, and making things more complicated happens as you add features. > > > But > > > when somebody reinvents the wheel it's really nice to have clearly spelled > > > out the advantages of the new wheel vs the old one. It's nice for there > > > to > > > _be_ clear advantages, offsetting the increased complexity cost. > > > > I got your point, and I agree. However, I also see the possibilities > > that a change of the logging API can bring: If someday it gets > > improved, maybe such day should be improved as far as possible. This > > kind of stuff that affect so many things are not going to change for > > long periods of time, as you said. > > > > Still, I know some kind of changes can be really complex and maybe are > > unproductive. I think the point is to get a middle point between new > > complexity vs. new features. > > > The beauty of printk is it's current simplicity. And even with that > developers > get it wrong. The changes seem like added complexity with little real gain. > > Plus none of the changes address the issue of getting better information. > The kernel is already so noisy that most distributions boot with the quiet > flag to shut it up. So less messages is probably better! > I agree. On the one hand, some changes are complex (like "blocks" implementation) and maybe they will not help at all. I'm not agreeing with every change :) On the other hand, the new tags (more standarized messages and simplified code) and all the information given by the new syslog retrieved from userspace (formatted messages => better information possibly) can do a lot of good (and maybe even more in the future, with a lot more stuff inside the kernel), without creating noise at boot at all. That kind of changes I think they would do more good than bad. -- Miguel Ojeda http://maxextreme.googlepages.com/index.htm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] firewire: point to migration document
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> --- drivers/firewire/Kconfig |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Index: linux/drivers/firewire/Kconfig === --- linux.orig/drivers/firewire/Kconfig +++ linux/drivers/firewire/Kconfig @@ -11,7 +11,8 @@ config FIREWIRE This is the "Juju" FireWire stack, a new alternative implementation designed for robustness and simplicity. You can build either this stack, or the classic stack (the ieee1394 driver, ohci1394 etc.) - or both. + or both. Please read http://wiki.linux1394.org/JujuMigration before + you enable the new stack. To compile this driver as a module, say M here: the module will be called firewire-core. It functionally replaces ieee1394, raw1394, -- Stefan Richter -=-=-=== =-=- --=== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Sleeping in RCU list traversal
Hello.
Peter Zijlstra wrote:
> > Can I sleep between rcu_read_lock() and rcu_read_unlock() ?
> > As far as I saw, rcu_read_lock() makes in_atomic() true, so I think I can't
> > sleep.
> You can indeed not sleep in an rcu_read_lock() section. However, you
> could grab a reference on an item, stop the iteration, drop
> rcu_read_lock. Do you thing, re-acquire rcu_read_lock(), drop the ref,
> and continue the iteration.
Something like this?
rcu_read_lock();
list_for_each_rcu(p, ...) {
ptr = list_entry(p, struct ..., list);
/* Grab a reference to "ptr". */
rcu_read_unlock();
my_task_that_may_sleep(ptr);
rcu_read_lock();
/* Drop a reference to "ptr". */
}
rcu_read_unlock();
Regarding my case, memory region pointed by "ptr" never be removed.
Do I need to grab a reference to "ptr" ?
Regards.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 8/9] compat_ioctl: call disk->fops->compat_ioctl without BKL
On Sunday 07 October 2007, Al Viro wrote: > On Sat, Oct 06, 2007 at 08:19:10PM +0200, Arnd Bergmann wrote: > > It would be good to find out whether it has been using the BKL > > on purpose or by accident, before this patch gets applied. > > Leave it alone, for now - I'm rebasing my series on top of your 1--7 > and it will both makes ->ioctl() and ->compat_ioctl() called unlocked > and switches ->compat_ioctl() to passing bdev instead of struct file > (->unlocked_ioctl() simply dies). ok, excellent. Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re:Sleeping in RCU list traversal
Hi
>Something like this?
>
>rcu_read_lock();
>list_for_each_rcu(p, ...) {
> ptr = list_entry(p, struct ..., list);
> /* Grab a reference to "ptr". */
> rcu_read_unlock();
> my_task_that_may_sleep(ptr);
> rcu_read_lock();
> /* Drop a reference to "ptr". */
>}
>rcu_read_unlock();
>Regarding my case, memory region pointed by "ptr" never be removed.
>Do I need to grab a reference to "ptr" ?
In Document/RCU/whatisRCU.txt
Note that the value returned by rcu_dereference() is valid
only within the enclosing RCU read-side critical section.
For example, the following is -not- legal:
rcu_read_lock();
p = rcu_dereference(head.next);
rcu_read_unlock();
x = p->address;
rcu_read_lock();
y = p->data;
rcu_read_unlock();
Holding a reference from one RCU read-side critical section
to another is just as illegal as holding a reference from
one lock-based critical section to another! Similarly,
using a reference outside of the critical section in which
it was acquired is just as illegal as doing so with normal
locking.
Jun Wang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 6/n] forcedeth: protect slow path with mutex
commit abca163a14b28c234df9bf38034bc967ff81c3aa
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Sun Oct 7 07:22:14 2007 -0400
[netdrvr] forcedeth: wrap slow path hw manipulation inside hw_mutex
* This makes sure everybody who wants to start/stop the RX and TX engines
first acquires this mutex.
* tx_timeout code was deleted, replaced by scheduling reset_task.
* linkchange moved to a workqueue (always inside hw_mutex)
* simplified irq handling a bit
* make sure to disable workqueues before NAPI
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/net/forcedeth.c | 272 ++--
1 file changed, 175 insertions(+), 97 deletions(-)
abca163a14b28c234df9bf38034bc967ff81c3aa
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index a037f49..d1c1efa 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -63,6 +63,7 @@
#include
#include
#include
+#include
#include
#include
@@ -647,6 +648,12 @@ struct nv_skb_map {
unsigned int dma_len;
};
+struct nv_mc_info {
+ u32 addr[2];
+ u32 mask[2];
+ u32 pff;
+};
+
/*
* SMP locking:
* All hardware access under dev->priv->lock, except the performance
@@ -709,6 +716,8 @@ struct fe_priv {
unsigned int pkt_limit;
struct timer_list oom_kick;
struct work_struct reset_task;
+ struct work_struct linkchange_task;
+ struct work_struct mcast_task;
struct delayed_work stats_task;
u32 reset_task_irq;
int rx_ring_size;
@@ -731,14 +740,18 @@ struct fe_priv {
int tx_ring_size;
/* vlan fields */
- struct vlan_group *vlangrp;
+ struct vlan_group *vlangrp;
/* msi/msi-x fields */
- u32 msi_flags;
- struct msix_entry msi_x_entry[NV_MSI_X_MAX_VECTORS];
+ u32 msi_flags;
+ struct msix_entry msi_x_entry[NV_MSI_X_MAX_VECTORS];
/* flow control */
- u32 pause_flags;
+ u32 pause_flags;
+
+ struct mutexhw_mutex;
+
+ struct nv_mc_info mci;
};
/*
@@ -2120,27 +2133,9 @@ static void nv_tx_timeout(struct net_device *dev)
spin_lock_irq(&np->lock);
- /* 1) stop tx engine */
- nv_stop_tx(dev);
-
- /* 2) process all pending tx completions */
- if (!nv_optimized(np))
- nv_tx_done(dev, np->tx_ring_size);
- else
- nv_tx_done_optimized(dev, np->tx_ring_size);
+ np->reset_task_irq = np->irqmask;
+ schedule_work(&np->reset_task);
- /* 3) if there are dead entries: clear everything */
- if (np->get_tx_ctx != np->put_tx_ctx) {
- printk(KERN_DEBUG "%s: tx_timeout: dead entries!\n", dev->name);
- nv_drain_tx(dev);
- nv_init_tx(dev);
- setup_hw_rings(dev, NV_SETUP_TX_RING);
- }
-
- netif_wake_queue(dev);
-
- /* 4) restart tx engine */
- nv_start_tx(dev);
spin_unlock_irq(&np->lock);
}
@@ -2476,6 +2471,7 @@ static int nv_change_mtu(struct net_device *dev, int
new_mtu)
* guessed, there is probably a simpler approach.
* Changing the MTU is a rare event, it shouldn't matter.
*/
+ mutex_lock(&np->hw_mutex);
nv_disable_irq(dev);
netif_tx_lock_bh(dev);
spin_lock(&np->lock);
@@ -2503,6 +2499,7 @@ static int nv_change_mtu(struct net_device *dev, int
new_mtu)
spin_unlock(&np->lock);
netif_tx_unlock_bh(dev);
nv_enable_irq(dev);
+ mutex_unlock(&np->hw_mutex);
}
return 0;
}
@@ -2535,6 +2532,8 @@ static int nv_set_mac_address(struct net_device *dev,
void *addr)
/* synchronized against open : rtnl_lock() held by caller */
memcpy(dev->dev_addr, macaddr->sa_data, ETH_ALEN);
+ mutex_lock(&np->hw_mutex);
+
if (netif_running(dev)) {
netif_tx_lock_bh(dev);
spin_lock_irq(&np->lock);
@@ -2552,6 +2551,8 @@ static int nv_set_mac_address(struct net_device *dev,
void *addr)
} else {
nv_copy_mac_to_hw(dev);
}
+
+ mutex_unlock(&np->hw_mutex);
return 0;
}
@@ -2605,17 +2606,61 @@ static void nv_set_multicast(struct net_device *dev)
}
addr[0] |= NVREG_MCASTADDRA_FORCE;
pff |= NVREG_PFF_ALWAYS;
+
+ if (mutex_trylock(&np->hw_mutex)) {
+ spin_lock_irq(&np->lock);
+
+ nv_stop_rx(dev);
+
+ writel(addr[0], base + NvRegMulticastAddrA);
+ writel(addr[1], base + NvRegMulticastAddrB);
+ writel(mask[0], base + NvRegMulticastMaskA);
+ writel(mask[1], base + NvRegMulticastMaskB);
+ writel(pff, base + NvRegPacketFilterFlags);
+ dprintk(KE
"Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
Hallo, Ingo. On Sun, Oct 07, 2007 at 08:07:07AM +0200, Ingo Molnar wrote: > > * Oleg Verych <[EMAIL PROTECTED]> wrote: > > > > > * completely useless, if properly implemented in userspace (with > > > > much reacher functionality). > > > > > > that's hogwash. No user-space runs during early bootup. (and yes i > > > want a color code at glance if something hangs in early bootup) > > > Nothing will color-code crashes, etc., etc. Control of the _kernel_ > > > console by user-space is complete nonsense. > > > > If it is so important for major kernel developer like you, Ingo, then > > why there's no scrollback at first place? Why nothing like that was > > not implemented up until now? To clarify. `Scrollback' here is *useful* scrollback during early boot and OOPs (which is absent, AFAIK), "nothing like that" is coloring of the messages by loglevel. > even if it were true (which it isnt), that is not an argument against > including a useful change that exists now and that people are interested > in. Coloring isn't useful. If it was, it would be implemented ~16 years ago. > (and yes, i have implemented kernel console improvements in the past > and vga scrollback support was in fact amongst one of my first ever > Linux kernel hacks so your comment is doubly wrong.) This `scrollback' is usual late boot / console one. If fact useful, until first tty switch or if `screen` cannot be used. But for some reason if scrolling region (DECSTBM) is less than whole screen, nothing works. And if width set to odd number of columns `stty columns $((80-1))` whole output becomes somewhat funny. > > My first ever Linux hack was changing default console output color. I > > think it was seven years ago. I though, it was not serious, if nobody > > did that already (in the 2.2.14). > > > > Please, don't mix important stuff here. I know, what kernel console > > is. > > your arguments are not an answer to my technical points, which i'll > repeat here: > > | | [...] No user-space runs during early bootup. (and yes i want a > | | color code at glance if something hangs in early bootup) The kernel developer talks about what is important to him. This is not technical point. > | | Nothing will color-code crashes, etc., etc. Because without userspace kernel panics. And if something is broken very early, then time to do kernel development better (not to break working early booting stuff for everybody), rather than to talk about importance of the color. I think, same applies to kernel debugger, that still is not in mainline (AFAIK). > | | Control of the _kernel_ console by user-space is complete nonsense. Not control, but flexible coloring (any kind of highlighting), selecting of useful information, i.e. making output more user friendly. This are things, which all *users* (not developers) expect in boot process of the one's _machine_, as opposed to debugging (early boot) kernel bugs. > today's console code development goes in exactly the opposite direction: > we are including (formerly-) user-space console functionality in the > kernel so that we can for example print oopses even if we are in X mode. I'm not sure what kind of printing it is. I do not use X much, but when i did, i recall MCE messages in xterm, when over-clocked CPU was going crazy, though. > > > this is nice and robust functionality that i personally welcome. The > > > default is not changed in any way. > > > > > > (btw., i corrected the subject line to remove the 'NAK'. Why do you > > > think you can 'NAK' a patch in this field?) > > > > I added comment (like this), so anyone can skip reading body, if > > headers are "Oleg Verych && NAK". In case if `NAK' have a magic > > meaning in the LKML, like control characters in the tty, i'm sorry. > > yes, a 'NAK' has a particular meaning on lkml. But what about (NAK && ! any_important_kernel_developer_name)? > > But how to express opinion quickly and easily? > > by writing a quick email expressing your opinion and waiting to see the > discussion play out itself ... Quick is not for me (i did accepted "config NO" size reduction review, btw), but for those, who reads LKML or looks on archive search results. I just am amazed how `Subject' is miss-used. I personally like to have most of the interesting information gathered from all that thousands of (not only LKML) messages. But a thread with all-like-one subjects, subjects that for some reason are taking place on the screen of MUAs (empty space if they are the same). Thus, short (easy to get right) summary in subject is more that welcome by me. > but it is very rude to 'NAK' a patch and it should only be done > carefully. That was a review of the implementation, an opinion on whole idea. Idea of yet another ugly kernel functionality, just because *BSD kernels have one. I like highlighting, i like to make it very flexible, nice and interesting[0]. This is possible only in the userspace, right after first process ran from initramfs. T
Re: [PATCH 0/5] forcedeth: several proposed updates for testing
Ingo Molnar wrote:
* Jeff Garzik <[EMAIL PROTECTED]> wrote:
* I feel TX NAPI is a useful tool, because it provides an independent TX
process control point and system load feedback point.
Thus I felt this was slightly superior to tasklets.
/me agrees violently
btw., when i played with this tunable under -rt:
enum {
NV_OPTIMIZATION_MODE_THROUGHPUT,
NV_OPTIMIZATION_MODE_CPU
};
static int optimization_mode = NV_OPTIMIZATION_MODE_THROUGHPUT;
the MODE_CPU one gave (much) _higher_ bandwidth. The queueing model in
forcedeth seemed to be not that robust and i think a single queueing
model should be adopted instead of this tunable. (which i think just hid
some bug/dependency) But i never got to the bottom of it so it's just
the impression i got.
That's interesting. It will be informative to narrow down the variables
affected by this. My changes stirred the pot quite a bit :)
* 'throughput' mode enables MSI-X, and separate interrupt vectors for RX
and TX. so, NVIDIA's MSI-X implementation, our generic MSI-X support,
or "Known bugs" (see top of file) may be a factor here.
* 'throughput' mode also changes the NIC's timer interrupt frequency
* do you recall if you were running in NAPI mode? It defaulted to off
in Kconfig, but I turned it on unconditionally.
* I think TX NAPI has the potential to make the optimization_mode
irrelevant (along with the other changes, most notably the interrupt
handling change)
* and overall, yes, if we can have a single queueing model /
optimization mode I am strongly in favor of that.
Testing welcome ;-) Though these patches are raw and "hot off the
presses", so unrelated bugs are practically a certainty. And I am
worrying about the "Known bugs" note at the top. My gut feeling is that
this was, in part, misunderstanding on the part of reverse-engineers,
since corrected when NVIDIA started contributing to the driver.
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 2/5] forcedeth: interrupt handling cleanup
Yinghai Lu wrote: On 10/6/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: commit a606d2a111cdf948da5d69eb1de5526c5c2dafef Author: Jeff Garzik <[EMAIL PROTECTED]> Date: Fri Oct 5 22:56:05 2007 -0400 [netdrvr] forcedeth: interrupt handling cleanup * nv_nic_irq_optimized() and nv_nic_irq_other() were complete duplicates of nv_nic_irq(), with the exception of one function call. Consolidate all three into a single interrupt handler, deleting a lot of redundant code. * greatly simplify irq handler locking. Prior to this change, the irq handler(s) would acquire and release np->lock for each action (RX, TX, other events). For the common case -- RX or TX work -- the lock is always acquired, making all successive acquire/release combinations largely redundant. Acquire the lock at the beginning of the irq handler, and release it at the end of the irq handler. This is simple, easy, and obvious. * remove irq handler work loop. All interesting events emanating from the irq handler either have their own work loops, or they poke a timer into action. Therefore, delete the pointless master interrupt handler work loop. Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> drivers/net/forcedeth.c | 325 +++- 1 file changed, 77 insertions(+), 248 deletions(-) any chance to create three verion irq handlers for ioapic, msi, msi-x...? MACRO or inline function? MSI-X already has its own separate interrupt handlers. MSI and INTx call the same interrupt handling code, like the unmodified driver goes. Creating an MSI-specific irq handler would not save very much AFAICS, but I might be missing something. Do you have ideas/suggestions for a different method? 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/
[GIT PULL] last minute FireWire update
Linus, please pull from the for-linus branch at git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git for-linus to receive the following simple but hopefully effective update. drivers/firewire/Kconfig |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) commit a1134dd48d59e532b801659163539bf01cae7673 Author: Stefan Richter <[EMAIL PROTECTED]> Date: Sun Oct 7 12:31:22 2007 +0200 firewire: point to migration document Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> diff --git a/drivers/firewire/Kconfig b/drivers/firewire/Kconfig index d011a76..fe9e768 100644 --- a/drivers/firewire/Kconfig +++ b/drivers/firewire/Kconfig @@ -11,7 +11,8 @@ config FIREWIRE This is the "Juju" FireWire stack, a new alternative implementation designed for robustness and simplicity. You can build either this stack, or the classic stack (the ieee1394 driver, ohci1394 etc.) - or both. + or both. Please read http://wiki.linux1394.org/JujuMigration before + you enable the new stack. To compile this driver as a module, say M here: the module will be called firewire-core. It functionally replaces ieee1394, raw1394, -- Stefan Richter -=-=-=== =-=- --=== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Revert "intel_agp: fix stolen mem range on G33"
On Sat, Oct 06, 2007 at 12:41:21PM +0200, Jiri Slaby wrote: > On 10/06/2007 07:42 AM, Kyle McMartin wrote: > > This reverts commit f443675affe3f16dd428e46f0f7fd3f4d703eeab, which > > breaks horribly if you aren't running an unreleased xf86-video-intel > > driver out of git. > > I guess, this will break my graphics, no? > http://lkml.org/lkml/2007/9/20/447 You need to upgrade Mesa. Cheers, Daniel signature.asc Description: Digital signature
Re: [PATCH] watchdog: add Nano 7240 driver
Andrey Panin wrote:
+#ifdef CONFIG_WATCHDOG_NOWAYOUT
+#define NOWAYOUT 1
+#else
+#define NOWAYOUT 0
+#endif
+static int nowayout = NOWAYOUT;
You don't need this #ifdef crap. Just use WATCHDOG_NOWAYOUT instead.
done
+ if ((_IOC_DIR(cmd) & _IOC_READ) &&
+ (!access_ok(VERIFY_WRITE, (void __user *)arg, _IOC_SIZE(cmd
+ return -EFAULT;
+ if ((_IOC_DIR(cmd) & _IOC_WRITE) &&
+ (!access_ok(VERIFY_READ, (void __user *)arg, _IOC_SIZE(cmd
+ return -EFAULT;
Is this really needed ?
removed
Signed-off-by: Gilles Gigan <[EMAIL PROTECTED]>
---
diff -uprN -X linux-2.6.23-rc9/Documentation/dontdiff
linux-2.6.23-rc9/drivers/char/watchdog/Kconfig
linux-2.6.23-rc9-dirty/drivers/char/watchdog/Kconfig
--- linux-2.6.23-rc9/drivers/char/watchdog/Kconfig 2007-10-06
01:43:44.0 +1000
+++ linux-2.6.23-rc9-dirty/drivers/char/watchdog/Kconfig2007-10-06
14:49:03.0 +1000
@@ -455,6 +455,19 @@ config SBC8360_WDT
Most people will say N.
+config SBC7240_WDT
+ tristate "SBC Nano 7240 Watchdog Timer"
+ depends on X86_32
+ ---help---
+ This is the driver for the hardware watchdog found on the IEI
+ single board computers EPIC Nano 7240 (and likely others). This
+ watchdog simply watches your kernel to make sure it doesn't freeze,
+ and if it does, it reboots your computer after a certain amount of
+ time.
+
+ To compile this driver as a module, choose M here: the
+ module will be called sbc7240_wdt.
+
config CPU5_WDT
tristate "SMA CPU5 Watchdog"
depends on X86
diff -uprN -X linux-2.6.23-rc9/Documentation/dontdiff
linux-2.6.23-rc9/drivers/char/watchdog/Makefile
linux-2.6.23-rc9-dirty/drivers/char/watchdog/Makefile
--- linux-2.6.23-rc9/drivers/char/watchdog/Makefile 2007-10-06
01:43:44.0 +1000
+++ linux-2.6.23-rc9-dirty/drivers/char/watchdog/Makefile 2007-10-06
14:49:03.0 +1000
@@ -71,6 +71,7 @@ obj-$(CONFIG_SCx200_WDT) += scx200_wdt.o
obj-$(CONFIG_PC87413_WDT) += pc87413_wdt.o
obj-$(CONFIG_60XX_WDT) += sbc60xxwdt.o
obj-$(CONFIG_SBC8360_WDT) += sbc8360.o
+obj-$(CONFIG_SBC7240_WDT) += sbc7240.o
obj-$(CONFIG_CPU5_WDT) += cpu5wdt.o
obj-$(CONFIG_SMSC37B787_WDT) += smsc37b787_wdt.o
obj-$(CONFIG_W83627HF_WDT) += w83627hf_wdt.o
diff -uprN -X linux-2.6.23-rc9/Documentation/dontdiff
linux-2.6.23-rc9/drivers/char/watchdog/sbc7240_wdt.c
linux-2.6.23-rc9-dirty/drivers/char/watchdog/sbc7240_wdt.c
--- linux-2.6.23-rc9/drivers/char/watchdog/sbc7240_wdt.c1970-01-01
10:00:00.0 +1000
+++ linux-2.6.23-rc9-dirty/drivers/char/watchdog/sbc7240_wdt.c 2007-10-07
21:06:35.0 +1000
@@ -0,0 +1,299 @@
+/*
+ * NANO7240 SBC Watchdog device driver
+ *
+ * Based on w83877f.c by Scott Jennings,
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation;
+ *
+ * Software distributed under the License is distributed on an "AS IS"
+ * basis, WITHOUT WARRANTY OF ANY KIND, either express or
+ * implied. See the License for the specific language governing
+ * rights and limitations under the License.
+ *
+ * (c) Copyright 2007 Gilles GIGAN <[EMAIL PROTECTED]>
+ *
+ * 10/01- 2007 [Initial revision]
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PREFIX "sbc7240_wdt: "
+
+#define ENABLE_SBC7240_PORT0x443
+#define DISABLE_SBC7240_PORT 0x043
+#define SET_TIMEOUT_SBC7240_PORT ENABLE_SBC7240_PORT
+#define WDT_MAGIC_CHAR 'V'
+
+#define WATCHDOG_TIMEOUT 30 /* 30 sec default timeout */
+#define WATCHDOG_MAX_TIMEOUT 255
+static int timeout = WATCHDOG_TIMEOUT; /* in seconds */
+module_param(timeout, int, 0);
+MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds. (1<=timeout<="
+__MODULE_STRING(WATCHDOG_MAX_TIMEOUT) ", default="
+__MODULE_STRING(WATCHDOG_TIMEOUT) ")");
+
+static int nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, int, 0);
+MODULE_PARM_DESC(nowayout, "Disable watchdog when closing device file");
+
+#define OPEN_STATUS_BIT0
+#define ENABLED_STATUS_BIT 1
+static unsigned long wdt_status;
+
+/*
+ * Utility routines
+ */
+
+static void wdt_disable(void)
+{
+ /* disable the watchdog */
+ if (test_and_clear_bit(ENABLED_STATUS_BIT, &wdt_status)) {
+ inb_p(DISABLE_SBC7240_PORT);
+ printk(KERN_INFO PREFIX "Watchdog timer is now disabled.\n");
+ }
+}
+
+static void wdt_enable(void)
+{
+ /* enable the watchdog */
+ if (!test_and_set_bit(ENABLED_STATUS_BIT,
[NET] IPv6 oops bisected
The commit commit 5f5dace1ce001b24fb8286e09ffd3c4d2b547e09 Author: Denis V. Lunev <[EMAIL PROTECTED]> Date: Thu Sep 27 12:41:26 2007 -0700 [NET]: Various dst_ifdown routines to catch refcounting bugs causes a 100% reproducible oops in net-2.6.24.git, in ip6_route_add(). Platform: x86-64 Fedora 7 Config and lspci attached. 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) 00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2) 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3) 00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 05:05.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) 40:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) 40:01.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01) 40:02.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) 40:02.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01) 41:04.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX 440] (rev a3) 61:04.0 SCSI storage controller: Marvell Technology Group Ltd. Unknown device 6042 (rev 02) 61:06.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07) 61:06.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07) 80:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) 80:01.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc9 # Sun Oct 7 08:44:56 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CPUSETS is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG
Re: Sleeping in RCU list traversal
Hello.
Thank you for pointing out.
Jun WANG wrote:
> >rcu_read_lock();
> >list_for_each_rcu(p, ...) {
> > ptr = list_entry(p, struct ..., list);
> > /* Grab a reference to "ptr". */
> > rcu_read_unlock();
> > my_task_that_may_sleep(ptr);
> > rcu_read_lock();
> > /* Drop a reference to "ptr". */
> > }
> > rcu_read_unlock();
>
> In Document/RCU/whatisRCU.txt
> Note that the value returned by rcu_dereference() is valid
> only within the enclosing RCU read-side critical section.
Excuse me, but I think "p" is used only between rcu_read_lock() and
rcu_read_unlock().
Is it illegal to use "ptr" after rcu_read_unlock() if "ptr" is obtained before
rcu_read_unlock() ?
Regards.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [NET] IPv6 oops bisected
Jeff Garzik wrote: The commit commit 5f5dace1ce001b24fb8286e09ffd3c4d2b547e09 Author: Denis V. Lunev <[EMAIL PROTECTED]> Date: Thu Sep 27 12:41:26 2007 -0700 [NET]: Various dst_ifdown routines to catch refcounting bugs causes a 100% reproducible oops in net-2.6.24.git, in ip6_route_add(). Platform: x86-64 Fedora 7 Config and lspci attached. And indeed, reverting this commit with 'patch -R' makes things work again. 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: 2.6.23-rc9-rt2
Hello Steve, Do you have any plans to support nested or reentrant Interrupt Handling schemes. Thank you, Jaswinder SIngh. On 10/5/07, Steven Rostedt <[EMAIL PROTECTED]> wrote: > We are pleased to announce the 2.6.23-rc9-rt2 tree, which can be > downloaded from the new location: > > http://www.kernel.org/pub/linux/kernel/projects/rt/ > > Changes since 2.6.23-rc9-rt1 > > - x86_64 disable IST for debug (Andi Kleen) > > - Better handling of dynticks going bad in RCU (Steven Rostedt) > > - Preempt RCU boosting (Steven Rostedt based on Paul E. McKenney's > stuff) > > Again, this still holds experimental code. But I've been running it on a > few boxes already (and even the box I'm writing this on). > > to build a 2.6.23-rc9-rt2 tree, the following patches should be applied: > > http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.22.tar.bz2 > http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.23-rc9.bz2 > http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.23-rc9-rt2.bz2 > > The broken out patches are also available. > > -- Steve > > > > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.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: [NET] IPv6 oops bisected
Jeff Garzik wrote: > Jeff Garzik wrote: >> The commit >> >> commit 5f5dace1ce001b24fb8286e09ffd3c4d2b547e09 >> Author: Denis V. Lunev <[EMAIL PROTECTED]> >> Date: Thu Sep 27 12:41:26 2007 -0700 >> >> [NET]: Various dst_ifdown routines to catch refcounting bugs >> >> causes a 100% reproducible oops in net-2.6.24.git, in ip6_route_add(). >> >> Platform: x86-64 Fedora 7 >> >> Config and lspci attached. > > And indeed, reverting this commit with 'patch -R' makes things work again. > > Jeff Can you me command to execute to reproduce the problem? and oops if possible. Regards, Den - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] Time-based RFC 4122 UUID generator
On Sun, 07 Oct 2007 12:08:10 +0200, you said:
> Thanks that you ask!
> I really should have mentioned it in my initial posting.
>
> Yes, this change was intentional, as it in fact fixes a possible bug in the
> original code.
> Section 4.1.6 in RFC 4122 states regarding the "NodeID":
> : For systems with no IEEE address, a randomly or pseudo-randomly
> : generated value may be used; see Section 4.5. The multicast bit must
> : be set in such addresses, in order that they will never conflict with
> : addresses obtained from network cards.
>
> So up to now it was just pure ("random") luck if this bit was set or not.
Sounds like a valid bugfix then - but it should probably be sent upstream
separately, with it's own changelog (what I quoted above should be fine)...
Remember - one patch, one logical change, so your patch should be split up
(among other things, that way the bugfix can proceed even if the new-function
part gets hung up in review).
Other than splitting it up, I have no further comments on either part.. Enjoy...
pgp9RsNYCzLRF.pgp
Description: PGP signature
NAK nettiquete (was Re: "Re: [PATCH 0/2] Colored kernel output (run2)"
On Sun, 07 Oct 2007 13:10:35 +0200, Oleg Verych said: > > > I added comment (like this), so anyone can skip reading body, if > > > headers are "Oleg Verych && NAK". In case if `NAK' have a magic > > > meaning in the LKML, like control characters in the tty, i'm sorry. > > > > yes, a 'NAK' has a particular meaning on lkml. > > But what about (NAK && ! any_important_kernel_developer_name)? The few times I've tried to NAK something outright, I've always tried to attach plenty of technical explanation (usually of the form "Gaak, this oopses my laptop") :), and cc: the relevant important_name, and hope they listen. Fortunately, most of the time I can get away with a politely phrased variation of "important_name would probably appreciate if you fixed XYZ and resubmitted" comment.. ;) pgpcTEBl2ISAm.pgp Description: PGP signature
Re: Sleeping in RCU list traversal
> Hello.
>
> Thank you for pointing out.
>
> Jun WANG wrote:
> > >rcu_read_lock();
> > >list_for_each_rcu(p, ...) {
> > > ptr = list_entry(p, struct ..., list);
> > > /* Grab a reference to "ptr". */
> > > rcu_read_unlock();
> > > my_task_that_may_sleep(ptr);
> > > rcu_read_lock();
> > > /* Drop a reference to "ptr". */
> > > }
> > > rcu_read_unlock();
>>>Regarding my case, memory region pointed by "ptr" never be removed.
>>>Do I need to grab a reference to "ptr" ?
> >
> > In Document/RCU/whatisRCU.txt
> > Note that the value returned by rcu_dereference() is valid
> > only within the enclosing RCU read-side critical section.
> Excuse me, but I think "p" is used only between rcu_read_lock() and
> rcu_read_unlock().
> Is it illegal to use "ptr" after rcu_read_unlock() if "ptr" is obtained
> before rcu_read_unlock() ?
>
> Regards.
>
I'm sorry,I think I got your idea, if you do not need ptr in
my_task_that_may_sleep(), why you need to grab a reference to "ptr". If
your my_task_that_may_sleep() needs ptr, and according to the
>"memory region pointed by "ptr" never be removed." you say,
it is ok to use "ptr" after rcu_read_ulock(). The basic idea behind RCU
is to split updates into "removal" and "reclamation" phases. If you
memory region pointed by "ptr" will not "reclamation" in sleep, it is ok
Regards.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sata_sil24 broken since 2.6.23-rc4-mm1
[Adding Jens Axboe, the author of what looks like the probable cause]
On 10/7/07, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> My sil24_fill_sg now looks like this:
> static inline void sil24_fill_sg(struct ata_queued_cmd *qc,
> struct sil24_sge *sge)
> {
> struct scatterlist *sg;
>
> ata_for_each_sg(sg, qc) {
> sge->addr = cpu_to_le64(sg_dma_address(sg));
> sge->cnt = cpu_to_le32(sg_dma_len(sg));
> if (ata_sg_is_last(sg, qc))
> sge->flags = cpu_to_le32(SGE_TRM);
> else
> sge->flags = 0;
> DPRINTK("flags,addr,cnt = 0x%x, 0x%X, 0x%X\n", sge->flags,
> sge->addr, sge->cnt);
> sge++;
> }
> }
>
> Suspicious is, that *all* output from this DPRINTK shows flags as 0x0,
> so the last sg is never terminated (SGE_TRM is 1<<31)?
> But if that is the cause, how is this working at all? Or am I doing
> something stupid?
Looking closer at
http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commitdiff;h=ec6fdded4d76aa54aa57341e5dfdd61c507b1dcd
the change to libata.h seems bogus :
in ata_qc_first_sg:
oldnew
return qc->__sgreturn qc->__sg
qc->__sg - qc->__sg == 0 qc->n_iter=0
-> sg - qc->__sg corresponds to qc->n_iter
in ata_qc_next_sg:
sg++; sg_next(sg); qc->n_iter++;
sg - qc->__sg < qc->n_elem qc->n_iter < qc->nelem
-> sg - qc->__sg corresponds to qc->n_iter
but in ata_sg_is_last:
(sg - qc->__sg) +1 == qc->n_elem qc->n_iter == qc->n_elem
if sg - qc->__sg corresponds to qc->n_iter then shoudn't it be
qc->n_iter+1 == qc->n_elem?
That missing +1 would explain, why the SGE_TRM never gets set.
And it would fit the symptoms, that the boot would fail at random. If
the "correct" garbage was in place to where the sglist runs off it
hangs the drive.
And that would even fit the two different errors that I only got one time each:
* a completely illegal access (PCI master abort while fetching SGT)
* wrong alignment of the SGT (SGT no on qword boundary)
At that that times the garbage seemed to point invalid addresses.
But I'm still not understanding, how the kernel could only fail
sometimes at bootup, but after that working without any visible
errors? Is the sil-chip rather intelligent about detecting corrupted
sglists and silently ignoring them?
Torsten
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] forcedeth: process TX completions using NAPI
Jeff Garzik wrote:
commit 57cbfacc00d69be2ba02b65d1021442273b76263
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Fri Oct 5 23:25:56 2007 -0400
[netdrvr] forcedeth: process TX completions using NAPI
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/net/forcedeth.c | 143 +++-
1 file changed, 83 insertions(+), 60 deletions(-)
The attached patch fixes an obvious bug. Once applied, TX NAPI actually
works :)
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 1c236e6..e25c05e 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -3059,7 +3059,7 @@ static irqreturn_t nv_nic_irq_tx(int foo, void *data)
static int nv_napi_tx_poll(struct napi_struct *napi, int budget)
{
- struct fe_priv *np = container_of(napi, struct fe_priv, napi);
+ struct fe_priv *np = container_of(napi, struct fe_priv, tx_napi);
struct net_device *dev = np->dev;
u8 __iomem *base = get_hwbase(dev);
unsigned long flags;
Re: [PATCH 6/n] forcedeth: protect slow path with mutex
Jeff Garzik wrote:
commit abca163a14b28c234df9bf38034bc967ff81c3aa
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Sun Oct 7 07:22:14 2007 -0400
[netdrvr] forcedeth: wrap slow path hw manipulation inside hw_mutex
* This makes sure everybody who wants to start/stop the RX and TX engines
first acquires this mutex.
* tx_timeout code was deleted, replaced by scheduling reset_task.
* linkchange moved to a workqueue (always inside hw_mutex)
* simplified irq handling a bit
* make sure to disable workqueues before NAPI
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/net/forcedeth.c | 272 ++--
1 file changed, 175 insertions(+), 97 deletions(-)
You will need the attached patch to even build (oops).
Also, testing shows there is a mutex deadlock somewhere.
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index d1c1efa..91926b1 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -2929,6 +2929,7 @@ static void nv_linkchange_task(struct work_struct *work)
static void nv_link_irq(struct net_device *dev)
{
+ struct fe_priv *np = netdev_priv(dev);
u8 __iomem *base = get_hwbase(dev);
u32 miistat;
@@ -4378,6 +4379,7 @@ static int nv_ethtool_begin (struct net_device *dev)
struct fe_priv *np = get_nvpriv(dev);
mutex_lock(&np->hw_mutex);
+ return 0;
}
static void nv_ethtool_complete (struct net_device *dev)
Re: [PATCH 0/5] forcedeth: several proposed updates for testing
Jeff Garzik wrote:
The 'fe-lock' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git fe-lock
contains the following changes that I would like to get tested:
[netdrvr] forcedeth: make NAPI unconditional
[netdrvr] forcedeth: interrupt handling cleanup
[netdrvr] forcedeth: process TX completions using NAPI
[netdrvr] forcedeth: internal simplification and cleanups
[netdrvr] forcedeth: timer overhaul
OK, I've successfully tested patches 1-5 on an AMD64 system with
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
A trivial s/napi/tx_napi/ fix must be applied to patch #3 (sent in
separate email). Once that is done, the patchset works flawlessly here,
passing simple RX, TX, RX+TX TCP stress tests.
I never ran into any TX problems, of the type hinted at by the "Known
bugs" section at the top of forcedeth.c. Either (a) my chip does not
have that bug, (b) my chip needs DEV_NEED_TIMERIRQ for other reasons, or
(c) the issue is not a hardware issue but a driver bug that is now fixed.
I'm going to hope its (c), But only testing will tell.
Jeff
P.S. Depending on when this gets fixed, you might have to revert
net-2.6.24.git commit 5f5dace1ce001b24fb8286e09ffd3c4d2b547e09 ("[NET]:
Various dst_ifdown routines to catch refcounting bugs").
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [NET] IPv6 oops bisected
Denis V. Lunev wrote: Jeff Garzik wrote: Jeff Garzik wrote: The commit commit 5f5dace1ce001b24fb8286e09ffd3c4d2b547e09 Author: Denis V. Lunev <[EMAIL PROTECTED]> Date: Thu Sep 27 12:41:26 2007 -0700 [NET]: Various dst_ifdown routines to catch refcounting bugs causes a 100% reproducible oops in net-2.6.24.git, in ip6_route_add(). Platform: x86-64 Fedora 7 Config and lspci attached. And indeed, reverting this commit with 'patch -R' makes things work again. Jeff Can you me command to execute to reproduce the problem? and oops if possible. The command is Fedora 7 initscripts... (typing in by hand) /etc/sysconfig/network-scripts/network-functions-ipv6: line 246: 1760 Killed LC_ALL=C /sbin/ip $options NULL pointer dereference at 0x03f8 backtrace: :ipv6:ip6_route_add+0x1b1/0x543 rtnetlink_rcv_msg inet6_rtm_newroute netlink_run_queue rtnetlink_rcv netlink_data_ready netlink_sendskb netlink_sendmsg sock_send_msg mntput_no_expire autoremove_wake_function find_lock_page zone_statistics get_page_from_freelist __alloc_pages move_addr_to_kernel verify_iovec sys_sendmsg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NAK nettiquete (was Re: "Re: [PATCH 0/2] Colored kernel output (run2)"
> The few times I've tried to NAK something outright, I've always tried to > attach > plenty of technical explanation Fair comment to my "silly" response The problems I see are - We run on a lot more than VGA PC consoles - We have serial consoles (which may or may not be VT132/ANSI compliant) - The printk paths are run at IRQ time ASAP to get messages to console, that could mean we split existing colour escape code processing and the like. - People redirect the console feed other places via ioctl. Some of them parse "<%d>" as the start But most importantly: - If you want to do "pretty" boot up you do it in X or frame buffer (which is going to get easier and easier with the X shift to kernel side video support) - If you want to do a coloured display after boot then this is a matter for your logging tools As with translation the kernel is the wrong place to do this work. What I would much rather people thought about was - Marker modes for translation (so you know which bits of a message are formatted up) - More consistency on the use of "name: blah" to make it easier to parse - Turning more messages from kernel logs to events when it makes sense (eg "Disk Full", "Media Error", "CPU on fire") So if you want to do a pretty boot, then solve the big picture, the framebuffer initrd graphical boot, the boot display, the combining of artwork and messages in user space from initrd run code. 'leet kernel messages in flashing red are not really the problem that needs solving to do this. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NAK nettiquete (was Re: "Re: [PATCH 0/2] Colored kernel output (run2)"
On Oct 7 2007 16:12, Alan Cox wrote: > >- We run on a lot more than VGA PC consoles >- We have serial consoles (which may or may not be VT132/ANSI compliant) Yes, and the serial driver does not usually pass on vc->vc_color to the real hardware. If it did, it would have to transform it back into an unportable ANSI code and send that. So we don't do that. >- The printk paths are run at IRQ time ASAP to get messages to console, >that could mean we split existing colour escape code processing and the >like. Oleg already persuaded me to add options to toally configure it out, so there is no impact for you. >- People redirect the console feed other places via ioctl. Some of them >parse "<%d>" as the start Interestingly enough, the part is not transferred over serial, but that seems another story. >- If you want to do "pretty" boot up you do it in X or frame buffer >(which is going to get easier and easier with the X shift to kernel side >video support) fb is slow. Feels like a 9600bps serial line. Let everyone have his own fun. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lockdep: how to tell it multiple pte locks is OK?
Peter Zijlstra wrote: >> >> I presume this is because I'm holding multiple pte locks (class >> "__pte_lockptr(new)"). Is there some way I can tell lockdep this is OK? >> > > Yeah, the typical way is to use spin_lock_nested(lock, nesting_level), > this allows one to annotate these nestings. However, nesting_level must > not be larger than 8, so if your batch is larger than that, we have a > problem. > Yeah, my batches are up to about 32. >> I'm presume I'm the first person to try holding multiple pte locks at >> once, so there's no existing locking order for these locks. >> > > Not quite, things like copy_pte_range() take 2. > Hm, and it uses SINGLE_DEPTH_NESTING... >> I'm always >> traversing and locking the pagetable in virtual address order (and this >> seems like a sane-enough rule for anyone else who wants to hold multiple >> pte locks). >> > > I'm quite sure copy_pte_range() could be used so that it violates that > order. > Good point. It's not a problem for me because they're two ptes in different pagetables, whereas my multiple ptes are always within the same pagetable. Someone wanting to lock multiple ptes from multiple pagetables would have a more complex locking order problem. (Or if we end up sharing ptes between pagetables it might get tricky.) J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)"
(changing Subject: back again, since Alan's returning to that topic...) On Sun, 07 Oct 2007 16:12:22 BST, Alan Cox said: > What I would much rather people thought about was > > - Marker modes for translation (so you know which bits of a message are > formatted up) > - More consistency on the use of "name: blah" to make it easier to parse > - Turning more messages from kernel logs to events when it makes sense > (eg "Disk Full", "Media Error", "CPU on fire") What would it take to have a pointer chain at a *well known* location or similar magic so if a machine died, I'd be able to hook up a laptop with a FireWire cable and do firescope magic to extract at least/just the dmesg buffer? (Yes, I know this requires a 1394 port and some previous cooperation and setup on the part of the 1394 driver. Assume I can get away with saying "add this to your kernel command line to make debugging easier for me" ;) (And yes, 5 years ago I'd have been wanting a "dump dmesg to floppy" patch, but times move one and 1394 is more likely than a floppy now...) pgpGF7VXYbtP4.pgp Description: PGP signature
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
* Oleg Verych <[EMAIL PROTECTED]> wrote: > > even if it were true (which it isnt), that is not an argument > > against including a useful change that exists now and that people > > are interested in. > > Coloring isn't useful. If it was, it would be implemented ~16 years > ago. Congratulations, this is the most stupid argument i've ever read on lkml. 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: [ofa-general] Updated InfiniBand/RDMA merge plans for 2.6.24
No mention about the iwarp port space issue? Here is the status of the current proposed patch: - needs another round of changes based on Sean's feedback - Arkady raised issues about the pain this puts on admins - it forces services like nfs-rdma, which already separates the nfs-rdma server by port number, to needlessly use a separate subnet for the rdma service. I'm at a loss as to how to proceed. Any ideas? Steve. Roland Dreier wrote: Since 2.6.23 still isn't out, and I've managed to reduce my patch review backlog a bit, it's probably a good idea to give another update about what I have queued for 2.6.24 already and what I hope to get to before the merge window opens. Core: - My user_mad P_Key index support patch. Merged this, although I still owe Sasha a patch to update libraries to use this. - A fix to the user_mad 32-bit big-endian userspace 64/32 problem with the method_mask when registering agents. Merged. - Sean's QoS changes. Merged. - Sean's IB CM MRA interface changes. I merged these -- what the heck, if it breaks we can back them out. ULPs: - Pradeep's IPoIB CM support for devices that don't have SRQs. Sean started reviewing but I didn't see any updated patches. - Moni's IPoIB bonding support. Seems like we found a clean set of changes, and these will go in via another (Jeff Garzik's?) tree. - Rolf's IPoIB MGID scope changes. No review progress here. - Eli and Michael's IPoIB stateless offload (checksum offload, LSO, LRO, etc). Not much review progress here; I'll try to chip away at the series and see what we can get into 2.6.24. - Or's IPoIB/userspace multicast coexistence stuff. I think we've converged on this; I'll merge this once a final version of the patch appears. HW specific: - I already merged patches to enable MSI-X by default for mthca and mlx4. I hope there aren't too many systems that get hosed if a MSI-X interrupt is generated. - Jack and Michael's mlx4 FMR support. Merged. I guess the fix for running in Xen domU may need to wait for 2.6.25, but I'll see what I can do. - ehca patch queue. Merged everything I think. - Steve's mthca router mode support. No one looked at it, seems like it's at risk of missing the window. - Arthur's mthca doorbell alignment fixes. I still need to check various approaches; I'll definitely merge something for 2.6.24. - Michael's mlx4 WQE shrinking patch. May miss the window and go for 2.6.25, I'll see if I can get to it. Here are a few topics that I believe will not be ready in time for the 2.6.24 window and will need to wait for 2.6.25: - Multiple CQ event vector support. I haven't seen any discussions about how ULPs or userspace apps should decide which vector to use, and hence no progress has been made since we deferred this during the 2.6.23 merge window. - XRC. Given the length of the backlog above and the fact that a first draft of this code has not been posted yet, I don't see any way that we could have something this major ready in time. BOILERPLATE === I keep patches in a git tree, available from git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git There are several branches of interest in this tree: for-2.6.23 - changes queued for merging into the current kernel release for-2.6.24 - changes queued for the next merge window for-linus - changes I have asked Linus to pull upstream for-mm - pulled by Andrew for inclusion in -mm I frequently rewrite history and rebase my tree, so the best way to track it is to keep a clone of Linus's tree around and then pull a fresh copy of my tree with git clone --reference /path/to/linus/tree \ git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git If you would like me to merge a patch, please send it to me as soon as it is ready. Do NOT wait for the merge window to open; if your change is not strictly a fix and you send it to me after the merge window opens, then it will likely have to wait for the next merge window. Please let me know if your patch is a fix that should go into the current release or if it can wait for the next merge window; if it is a fix, please describe the severity of the issue your are fixing, so I can make a good judgement about which release it should go into. Including a good changelog entry that explains what you are changing, why you are changing it, and how your change accomplishes your goal will greatly increase the chance of your patch being merged promptly. Getting an independent review and a Reviewed-by: line also helps a lot. The files Documentation/SubmittingPatches and Documentation/SubmitChecklist in kernel source tree also have a lot of good advice that makes it easier for me to handle your patches. DETAILS === Here is the complete list of patches I have in my for-2.6.24 branch: Ali Ayoub (1): IB/sa: Error handling thinko fix Anton Blanchard (3):
Re: NAK nettiquete (was Re: "Re: [PATCH 0/2] Colored kernel output (run2)"
> >- If you want to do "pretty" boot up you do it in X or frame buffer > >(which is going to get easier and easier with the X shift to kernel side > >video support) > > fb is slow. Feels like a 9600bps serial line. So fix your fb. There is enough information to cover 2D scrolling for most modern cards now. > Let everyone have his own fun. The point isn't to put everyones "fun" into the kernel, or by now it would have become a steaming heap. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 for 2.6.23] Driver core: fix regression with SYSFS_DEPRECTATED
Subject: Driver core: fix SYSF_DEPRECATED breakage for nested classdevs
From: Dmitry Torokhov <[EMAIL PROTECTED]>
We should only reparent to a class former class devices that
form the base of class hierarchy. Nested devices should still
grow from their real parents.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
Tested-by: Andrey Borzenkov <[EMAIL PROTECTED]>
Tested-by: Anssi Hannula <[EMAIL PROTECTED]>
---
Linus,
Please consider applying this patch before releasing 2.6.23. It fixes
a regression in UDEV/HAL caused by conversion of input devices from
class devices to regular devices.
Thanks,
Dmitry
Index: linux/drivers/base/core.c
===
--- linux.orig/drivers/base/core.c
+++ linux/drivers/base/core.c
@@ -586,9 +586,13 @@ void device_initialize(struct device *de
static struct kobject * get_device_parent(struct device *dev,
struct device *parent)
{
- /* Set the parent to the class, not the parent device */
- /* this keeps sysfs from having a symlink to make old udevs happy */
- if (dev->class)
+ /*
+* Set the parent to the class, not the parent device
+* for topmost devices in class hierarchy.
+* This keeps sysfs from having a symlink to make old
+* udevs happy
+*/
+ if (dev->class && (!parent || parent->class != dev->class))
return &dev->class->subsys.kobj;
else if (parent)
return &parent->kobj;
\\
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 2.6.16.54
Location: ftp://ftp.kernel.org/pub/linux/kernel/v2.6/ git tree: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git RSS feed of the git tree: http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=rss Changes since 2.6.16.53: Adrian Bunk (2): Linux 2.6.16.54-rc1 Linux 2.6.16.54 Alexander Shmelev (1): [SPARC32]: Fix bug in sparc optimized memset. David S. Miller (1): [MATH-EMU]: Fix underflow exception reporting. Ilpo Järvinen (1): TCP: Fix TCP handling of SACK in bidirectional flows James Bottomley (1): [MCA] fix bus matching Konstantin Sharlaimov (2): [PPP]: Fix osize too small errors when decoding mppe. [PPP]: Fix output buffer size in ppp_decompress_frame(). Mark Fortescue (1): [SPARC32]: Fix rounding errors in ndelay/udelay implementation. Neil Brown (16): md: Add '4' to the list of levels for which bitmaps are supported md: Don't clear bits in bitmap when writing to one device fails during recovery md/bitmap: fix online removal of file-backed bitmaps md/bitmap: cleaner separation of page attribute handlers in md/bitmap md/bitmap: use set_bit etc for bitmap page attributes md/bitmap: remove unnecessary page reference manipulations from md/bitmap code md/bitmap: remove dead code from md/bitmap md/bitmap: tidy up i_writecount handling in md/bitmap md: Allow re-add to work on array without bitmaps md: fix resync speed calculation for restarted resyncs md: fix a plug/unplug race in raid5 md: fix some small races in bitmap plugging in raid5 md: allow SET_BITMAP_FILE to work on 64bit kernel with 32bit userspace md: assorted md and raid1 one-liners md: fix a few problems with the interface (sysfs and ioctl) to md md: avoid possible BUG_ON in md bitmap handling Makefile |2 arch/sparc/kernel/entry.S | 14 ++- arch/sparc/lib/memset.S |2 drivers/mca/mca-bus.c |2 drivers/md/bitmap.c | 126 +- drivers/md/md.c | 107 +++-- drivers/md/raid1.c| 20 drivers/md/raid5.c| 46 +++--- drivers/net/ppp_generic.c | 15 +++ include/asm-sparc/sfp-machine.h |6 + include/asm-sparc64/sfp-machine.h |2 include/linux/compat_ioctl.h |2 include/linux/raid/bitmap.h |3 include/linux/raid/md_k.h |3 include/math-emu/op-common.h |5 - include/math-emu/soft-fp.h|7 + net/ipv4/tcp_input.c |5 - 17 files changed, 226 insertions(+), 141 deletions(-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sysfs: backport of sysfs_readdir fix from 2.6.22.y to 2.6.16.y (CVE-2007-3104)
> This patch solves CVE-2007-3104 - sysfs_readdir oops. >... Thanks, I've applied a similar but slightly different fix in 2.6.16.55-rc1. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.6.16.55-rc1
Security fixes since 2.6.16.54:
- CVE-2005-0504: fix buffer overflow in the moxa driver
- CVE-2007-2453: random fixes
- CVE-2007-3104: store sysfs inode nrs in s_ino to avoid readdir oopses
- CVE-2007-3105: random: fix bound check ordering
- CVE-2007-3848: Reset current->pdeath_signal on SUID binary execution
- CVE-2007-4571: Convert snd-page-alloc proc file to use seq_file
- CVE-2007-4573: x86_64: Zero extend all registers after ptrace in 32bit entry
path
Location:
ftp://ftp.kernel.org/pub/linux/kernel/people/bunk/linux-2.6.16.y/testing/
git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
RSS feed of the git tree:
http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=rss
Changes since 2.6.16.54:
Adrian Bunk (8):
unexport ktime_get_real
unexport neigh_update_hhs
unexport cpufreq_parse_governor
unexport csr1212_release_keyval
sound/core/pcm_lib.c: don't export static functions
unexport ip_conntrack_{,un}register_notifier
snd_mem_proc_read(): convert to list_for_each_entry*
Linux 2.6.16.55-rc1
Andi Kleen (1):
x86_64: Zero extend all registers after ptrace in 32bit entry path
(CVE-2007-4573)
Dann Frazier (1):
fix buffer overflow in the moxa driver (CVE-2005-0504)
Eric Sandeen (1):
sysfs: store sysfs inode nrs in s_ino to avoid readdir oopses
(CVE-2007-3104)
Kumar Gala (1):
[POWERPC] Flush registers to proper task context
Marcel Holtmann (1):
Reset current->pdeath_signal on SUID binary execution (CVE-2007-3848)
Matt Mackall (3):
random: fix error in entropy extraction (CVE-2007-2453 1 of 2)
random: fix seeding with zero entropy (CVE-2007-2453 2 of 2)
random: fix bound check ordering (CVE-2007-3105)
Mikael Pettersson (1):
[SPARC]: fix sparc64 gcc 4.2 compile failure
Nick Bowler (1):
[IPSEC] AH4: Update IPv4 options handling to conform to RFC 4302.
Takashi Iwai (1):
Convert snd-page-alloc proc file to use seq_file (CVE-2007-4571)
Makefile |2
arch/powerpc/kernel/process.c|6 -
arch/x86_64/ia32/ia32entry.S | 18 +++-
arch/x86_64/kernel/ptrace.c |4 -
drivers/char/moxa.c |8 +-
drivers/char/random.c| 76 +++
drivers/cpufreq/cpufreq.c|1
drivers/ieee1394/ieee1394_core.c |1
fs/exec.c| 13 ++-
fs/sysfs/dir.c | 16 ++--
fs/sysfs/inode.c |1
fs/sysfs/mount.c |1
include/asm-sparc/mostek.h |2
include/asm-sparc64/mostek.h |2
include/linux/sysfs.h|1
kernel/hrtimer.c |2
net/core/neighbour.c |1
net/ipv4/ah4.c |2
net/ipv4/netfilter/ip_conntrack_standalone.c |2
sound/core/memalloc.c| 72 ++
sound/core/pcm_lib.c |4 -
21 files changed, 136 insertions(+), 99 deletions(-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Oct 7 2007 13:10, Oleg Verych wrote: >This `scrollback' is usual late boot / console one. If fact useful, >until first tty switch or if `screen` cannot be used. But for some >reason if scrolling region (DECSTBM) is less than whole screen, nothing >works. Actually, scrolling begins to work once userspace starts, and the scrollback buffer (given enough size) still contains the first screenful when Linux started, which may include the bootloader (if the loader did not zero the screen before handing control over). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Colored kernel output (run3)
* Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> Colored kernel message output (1/2)
>
> This patch makes it possible to give kernel messages a selectable
> color. It can be chosen at compile time, overridden at boot time, and
> changed at run time.
minor fix: i had to use the slightly modified patch below instead of the
one you posted, so that the second patch applies fine. Color output is
just fine with this plus your #2 one applied. Adding
vt.printk_color=0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08 to the boot line
worked as expected.
Ingo
--->
Colored kernel message output (1/2)
This patch makes it possible to give kernel messages a selectable
color. It can be chosen at compile time, overridden at boot time,
and changed at run time.
References: http://lkml.org/lkml/2007/4/1/162
http://lkml.org/lkml/2007/10/5/199
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
drivers/char/Kconfig | 42 ++
drivers/char/vt.c| 24
2 files changed, 66 insertions(+)
Index: linux/drivers/char/Kconfig
===
--- linux.orig/drivers/char/Kconfig
+++ linux/drivers/char/Kconfig
@@ -58,6 +58,48 @@ config VT_CONSOLE
If unsure, say Y.
+config VT_CKO
+ bool "Colored kernel message output"
+ depends on VT_CONSOLE
+ ---help---
+ This option enables kernel messages to be emitted in
+ colors other than the default.
+
+ If unsure, say N.
+
+config VT_PRINTK_COLOR
+ hex "Colored kernel message output"
+ range 0x00 0xFF
+ depends on VT_CKO
+ default 0x07
+ ---help---
+ This option defines with which color kernel messages will be
+ printed to the console.
+
+ The value you need to enter here is the value is composed
+ (OR-ed) of a foreground and a background color.
+
+ Foreground:
+ 0x00 = black, 0x08 = dark gray,
+ 0x01 = red, 0x09 = light red,
+ 0x02 = green, 0x0A = light green,
+ 0x03 = brown, 0x0B = yellow,
+ 0x04 = blue,0x0C = light blue,
+ 0x05 = magenta, 0x0D = light magenta,
+ 0x06 = cyan,0x0E = light cyan,
+ 0x07 = gray,0x0F = white,
+
+ (Foreground colors 0x08 to 0x0F do not work when a VGA
+ console font with 512 glyphs is used.)
+
+ Background:
+ 0x00 = black, 0x40 = blue,
+ 0x10 = red, 0x50 = magenta,
+ 0x20 = green, 0x60 = cyan,
+ 0x30 = brown, 0x70 = gray,
+
+ For example, 0x1F would yield white on red.
+
config HW_CONSOLE
bool
depends on VT && !S390 && !UML
Index: linux/drivers/char/vt.c
===
--- linux.orig/drivers/char/vt.c
+++ linux/drivers/char/vt.c
@@ -73,6 +73,7 @@
*/
#include
+#include
#include
#include
#include
@@ -2344,6 +2345,24 @@ struct tty_driver *console_driver;
#ifdef CONFIG_VT_CONSOLE
+#ifdef CONFIG_VT_CKO
+static unsigned int printk_color __read_mostly = CONFIG_VT_PRINTK_COLOR;
+module_param(printk_color, uint, S_IRUGO | S_IWUSR);
+
+static inline void vc_set_color(struct vc_data *vc, unsigned char color)
+{
+ vc->vc_color = color_table[color & 0xF] |
+ (color_table[(color >> 4) & 0x7] << 4) |
+ (color & 0x80);
+ update_attr(vc);
+}
+#else
+static unsigned int printk_color;
+static inline void vc_set_color(const struct vc_data *vc, unsigned char c)
+{
+}
+#endif
+
/*
* Console on virtual terminal
*
@@ -2384,12 +2403,14 @@ static void vt_console_print(struct cons
hide_cursor(vc);
start = (ushort *)vc->vc_pos;
+ vc_set_color(vc, printk_color);
/* Contrived structure to try to emulate original need_wrap behaviour
* Problems caused when we have need_wrap set on '\n' character */
while (count--) {
c = *b++;
if (c == 10 || c == 13 || c == 8 || vc->vc_need_wrap) {
+ vc_set_color(vc, vc->vc_def_color);
if (cnt > 0) {
if (CON_IS_VISIBLE(vc))
vc->vc_sw->con_putcs(vc, start, cnt,
vc->vc_y, vc->vc_x);
@@ -2402,6 +2423,7 @@ static void vt_console_print(struct cons
bs(vc);
start = (ushort *)vc->vc_pos;
myx = vc->vc_x;
+ vc_set_color(vc, printk_color);
continue;
}
if (c != 13)
@@ -2409,6 +2431,7 @@ static void vt_console_print(struct cons
cr(vc);
start = (ushort *)vc->vc_pos;
myx = vc->vc_x;
+ vc_set_color(vc, pr
Re: [PATCH 1/2] Colored kernel output (run3)
On Oct 7 2007 18:38, Ingo Molnar wrote: > >minor fix: i had to use the slightly modified patch below instead of the >one you posted, so that the second patch applies fine. What is it that you changed? The printk patches are right at the front, so there should not be any fuzz or offsets (might vary when not at Linus's git top). 18:42 ichi:/ws/linux/linux-2.6.23 > head -n6 patches/series checkpatch1.diff checkpatch2.diff checkfiles.diff xt_TCPOPTSTRIP.diff vt-printk-color.diff vt-printk-color-per-loglevel.diff >Color output is >just fine with this plus your #2 one applied. Adding >vt.printk_color=0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08 to the boot line >worked as expected. Use decimal if feasible. (vt.printk_color=1,2,3,4,5,6,7,8) The maximum command line still seems to be 255 on i386, as I noticed while trying to replace the VGA color table :-( - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Colored kernel output (run3)
Jan, > This patch makes it possible to give kernel messages a selectable > color. It can be chosen at compile time, overridden at boot time, and > changed at run time. here's some (good) text footprint data: with the feature disabled (which is the default), the text size difference with patch #1: vmlinux: textdata bss dec hex filename 7732358 1157269 401408 9291035 8dc51b vmlinux.before 7732358 1157269 401408 9291035 8dc51b vmlinux.after i.e. no overhead. Text size difference with patch #2: vmlinux: textdata bss dec hex filename 7732358 1157269 401408 9291035 8dc51b vmlinux.before 7732374 1157269 401408 9291051 8dc52b vmlinux.after 16 bytes, or 0.0002% of the total text size. So there's in essence no text overhead to talk about. So the text overhead argument is a red herring. 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/
Strange network related data corruption
Hello, I am encountering some strange data corruption when transferring data from one of my PCs that I use as a file-server. on the server: FILE=; | cut -d" " -f1 | nc -lp5000 -q0; while nc -lp5000 -q0 < $FILE; do : ; done on the client: H=; SUM=$(nc -q0 $H 5000);sleep 1s; while nc -q0 $H 5000 | sha1sum | (grep -v $SUM || echo -n .); do sleep 1s ;done (output looks somewhat like this: ..6dd5fb1ce29d270acdfbb02d00921bf75d141773 - ... ) I would expect the sha1sum to be the same in every pass (assuming the source file does not change). But every few passes (with no apparent pattern) there is a different sum returned. I first noticed this when transferring large files (backups) with with SMB and NFS(v3 and v4) but to rule that out I tried netcat in the way noted above. When I have the server do the sha1sum of the file locally the problem is not reproducible. When I do this with a small file that easily fits into the cache the problem stays reproducible. Another thing I did was to use dd to transfer data in 1GiB chunks from /dev/zero and generate the sha1sum on the client. There I was not able to reproduce the problem. The server is a Athlon64 3400+ (good old Clawhammer) with 1GiB RAM. I use 4 SATA drives in a software RAID5 configuration, attached to a Promise TX4 300 SATA-II controller. The filesystem is ext3 without special mount-options. The dist is Debian/Sid for AMD64 with self-compiled kernel 2.6.23-rc9 (.config attached). The clients I tried are a Core2Duo 6600 with 3GiB of RAM, also Debian/Sid AMD64 (kernel 2.6.23-rc9) and a Centrino notebook with Pentium M and 1GiB of RAM (Debian/Sid i386, kernel 2.6.23-rc7). All PCs mentioned have gigabit ethernet and are connected via a gigabit switch. I tried these tests between the clients and could not reproduce the problem there. I had the server run memtest68+ with 20 passes without problems. I tried several kernel versions on the server (from .18 to .23-rc9), all showed the problem. I suspect a hardware problem, but I cannot isolate the part responsible. I tried another ethernet adapter (the 3com905cin lspci output) and I also tried the onboard sata controller(s) (2 ports via and 2 ports promise tx2). I don't know if this is a kernel problem or just my and my setup, but maybe some one on this list has an idea wher I could look next. Thanks and regards Malte -- --- Malte Schröder [EMAIL PROTECTED] ICQ# 68121508 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: can't change euid 0 to uid != running user
On Fri, Oct 05, 2007 at 08:28:50AM -0700, Ray Lee wrote:
> On 10/5/07, Luciano Rocha <[EMAIL PROTECTED]> wrote:
> > I have the following problem:
> > $ sudo -u ie -s # or sudo su ie
> > unable to change to runas uid: Resource temporarily unavailable
> >
> > Works:
> > $ sudo su, followed by su ie
> >
> > The first sudo also worked while I had a shell under user ie.
> >
> > When I exited, it stopped working, but it is now working every time I
> > trie it.
> >
> > dmesg shows:
> >
> > [82602.729330] kobject_add failed for 504 with -EEXIST, don't try to
> >register things with the same name in the same directory.
> > [82602.729365] [] kobject_shadow_add+0x16e/0x1a0
> > [82602.729383] [] kobject_set_name+0x29/0x92
> > [82602.729504] [] user_kobject_create+0x6a/0x90
> > [82602.729520] [] alloc_uid+0x18f/0x1d7
> > [82602.729530] [] set_user+0x1c/0x8f
> > [82602.729539] [] sys_setresuid+0xd5/0x162
> > [82602.729552] [] syscall_call+0x7/0xb
> > [82602.729575] ===
> >
> > $ git describe
> > v2.6.23-rc9-156-ga95dacb
> >
> > (Clone of Linus' tree, after rc9, with some patches from
> > mingo/linux-2.6-sched-devel.git, and a fix for lguest (didn't link due
> > to kasprintf)).
>
> Hmm, it works for me under 2.6.23-rc6, so it's either a difference
> between our .configs or a late regression. If you could bisect the
> problem (starting with reverting Ingo's sched devel patches and lguest
> patches, and trying that), then that would tell us where the issue is.
>
Without the patches, i.e., a clean Linus tree (v2.6.23-rc9-41-g804b3f9),
I can't reproduce it anymore.
The commits since v2.6.23-rc9:
804b3f9a16e446cb023417faec58b6506c834052 Merge branch 'upstream-linus' of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev
3e0ca2f148f97c5748f52bcf2a69dd17cb2b1d13 Merge branch 'upstream-linus' of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6
c7659e2c139d0be4647bef89188a932e0254d709 Merge branch 'upstream' of
git://ftp.linux-mips.org/pub/scm/upstream-linus
66b1f1a982bf4dbad9fa0de25b8d95c4936f05c4 Merge branch 'for-linus' of
master.kernel.org:/pub/scm/linux/kernel/git/cooloney/blackfin-2.6
991bf528f602882580d0918842b125255d246a19 drivers/ata/pata_ixp4xx_cf.c: ioremap
return code check
90925d3050253ff7b4f5d1660071df75f44bd0ff Ata: pata_marvell, use ioread* for
iomap-ped memory
4007b493ee6e4a52c2b618ab8361847fba5bf116 libata: fix for sata_mv >64KB DMA
segments
bda0233b89c10ae46ccecb78bffdaf0fd7833d17 ocfs2: Unlock mutex in local alloc
failure case
529d303e075aa6d988f30935b8995ffb382ad38e sky2: jumbo frame regression fix
5c55c434917429f229a1bf43def97fd421f444c6 Merge branch 'fixes-jgarzik' of
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6 into
upstream-fixes
cda6a20b68c1f21f4b4bc9cd3ee08494e7ebf0d5 Blackfin arch: fix PORT_J BUG for
BF537/6 EMAC driver reported by Kalle Pokki <[EMAIL PROTECTED]>
c58c2140f08de4ad0b0dbd48f6e78168dc321042 Blackfin arch: gpio pinmux and
resource allocation API required by BF537 on chip ethernet mac driver
9ea0f043fec38fadb0101fbf29563a5635f42e93 [MIPS] Terminally fix
local_{dec,sub}_if_positive
fef74705ea310acd716c2722bfeb0f796cf23640 [MIPS] Type proof reimplementation of
cmpxchg.
f6a9e6dec537dc1d9d2c62d7b8ad205d0993bddc [MIPS] pg-r4k.c: Fix a typo in an
R4600 v2 erratum workaround
ee0a8169b693e1c708d0f9af0a5e4ade65a65439 [PATCH] softmac: Fix compiler-warning
4365e99f9587b94010e9818a4237ce2b1c734e91 [PATCH] bcm43xx: Correct printk with
PFX before KERN_
f778089cb2445dfc6dfd30a7a567925fd8589f1e Merge branch 'sas-fixes' of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6
db7a89db5e3bc6ba131965183577b15fd6fc92cc Merge branch 'upstream-linus' of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6
2910ca6f8ae69648623b3c05b79be87dd7bda73d Merge branch 'upstream-linus' of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev
d237098c03eb91cef240e9a1b248c0e1ecd1c80c Merge
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched
114d5b1ca265f8a582dcbf0030da20ccdddbe8e1 Merge branch 'master' of
master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6
2b3b29080d702e5488f214276170ab46adc40ee5 Merge branch 'master' of
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
e80eaf9904d5b19512265e1435372b2e12146a5f Merge branch 'merge' of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc
d136552e8beadcf5e59089292e2ba44f09e3aad8 aic94xx: fix DMA data direction for
SMP requests
f662fe5a0b144efadbfc00e8040e603ec318746e dm9601: Fix receive MTU
593ff56ef2a23ed3a66ee87d9c9b33044b9fb193 mv643xx_eth: Do not modify struct
netdev tx_queue_len
50626297b1beb0a29c0f174be39f36485533216c qla3xxx: bugfix: Fix VLAN rx
completion handling.
b323e0e49fe9331ee3a7a336af879d6e303b16b3 qla3xxx: bugfix: Add memory barrier
before accessing rx completion.
4c74d4ec3524a8f31deadd115139dd93bc91d598 ata_piix: add another TECRA M3 entry
to broken suspend list
30084fbd1caa
[PATCH] Fix Oops in toshiba_acpi error return path
This fixes oops when registering backlight device fails. Attached as I still
cannot convince kmail to not mangle long lines ...
-andrey
Subject: [PATCH] Fix Oops in toshiba_acpi error return path
From: Andrey Borzenkov <[EMAIL PROTECTED]>
When backlight_device_register() fails, return after undo initialization,
do not try to use pointer that just was reset to NULL
This fixes this oops:
[ 1595.177672] [] show_trace_log_lvl+0x1a/0x30
[ 1595.177706] [] show_trace+0x12/0x20
[ 1595.177718] [] dump_stack+0x15/0x20
[ 1595.177728] [] kobject_shadow_add+0x125/0x1c0
[ 1595.177754] [] kobject_add+0xa/0x10
[ 1595.177764] [] device_add+0x97/0x5d0
[ 1595.16] [] device_register+0x12/0x20
[ 1595.177786] [] backlight_device_register+0x9f/0x110 [backlight]
[ 1595.177814] [] toshiba_acpi_init+0x117/0x15e [toshiba_acpi]
[ 1595.177834] [] sys_init_module+0xfd/0x14e0
[ 1595.177871] [] sysenter_past_esp+0x5f/0x99
[ 1595.177883] ===
[ 1595.177890] Could not register toshiba backlight device
[ 1595.177985] BUG: unable to handle kernel NULL pointer dereference at virtual address 0004
...
[ 1595.394097] EIP:0060:[]Not tainted VLI
[ 1595.394101] EFLAGS: 00010282 (2.6.23-rc9-1avb #24)
[ 1595.480081] EIP is at toshiba_acpi_init+0x143/0x15e [toshiba_acpi]
Signed-off-by: Andrey Borzenkov <[EMAIL PROTECTED]>
---
drivers/acpi/toshiba_acpi.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi/toshiba_acpi.c b/drivers/acpi/toshiba_acpi.c
index 13369b4..18660cc 100644
--- a/drivers/acpi/toshiba_acpi.c
+++ b/drivers/acpi/toshiba_acpi.c
@@ -591,9 +591,12 @@ static int __init toshiba_acpi_init(void)
NULL,
&toshiba_backlight_data);
if (IS_ERR(toshiba_backlight_device)) {
+ int ret = PTR_ERR(toshiba_backlight_device);
+
printk(KERN_ERR "Could not register toshiba backlight device\n");
toshiba_backlight_device = NULL;
toshiba_acpi_exit();
+ return ret;
}
toshiba_backlight_device->props.max_brightness = HCI_LCD_BRIGHTNESS_LEVELS - 1;
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 1/2] Colored kernel output (run3)
On Oct 7 2007 18:44, Ingo Molnar wrote: >> This patch makes it possible to give kernel messages a selectable >> color. It can be chosen at compile time, overridden at boot time, and >> changed at run time. > >here's some (good) text footprint data: > >with the feature disabled (which is the default), the text size >difference with patch #1: > > vmlinux: > textdata bss dec hex filename > 7732358 1157269 401408 9291035 8dc51b vmlinux.before > 7732358 1157269 401408 9291035 8dc51b vmlinux.after > I already posted the numbers. But it seems like the archives like lkml.org or marc.info did not archive them (but i've cc'ed plenty so you did not miss it.). See below. >i.e. no overhead. Text size difference with patch #2: > > vmlinux: > textdata bss dec hex filename > 7732358 1157269 401408 9291035 8dc51b vmlinux.before > 7732374 1157269 401408 9291051 8dc52b vmlinux.after > >16 bytes, or 0.0002% of the total text size. So there's in essence no >text overhead to talk about. So the text overhead argument is a red >herring. 16 bytes, huh? Can't be. That would be like, perhaps 5, x86 instructions. ||Date: Sat, 6 Oct 2007 22:09:13 +0200 (CEST) ||Subject: [PATCH 0/2] Colored kernel output (run3) || ||ok, so to make Oleg happy, here is run3 with a bool config option. || ||i386>> || 48679 vt.o w/o anything || 48679 vt.o w/patch1 || 49117 vt.o w/patch1+ CONFIG_VT_CKO=y || 49198 vt.o w/patch1+patch2 + CONFIG_VT_CKO=y || || 519 total cost of CKO || ||x86_64>> || 71892 vt.o w/patch1+patch2 || 72787 vt.o w/patch1+patch2 + CONFIG_VT_CKO=y || || 895 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MSI interrupts and disable_irq
Jeff Garzik wrote: Interested parties should try the forcedeth patches I just posted :) The patches look good, but I would still prefer to understand why the current implementation causes crashes before rewriting everything. I've just noticed that netpoll_send_skb() calls ->hard_start_xmit() and ->poll() within local_irq_save(). Thus it seems that spin_lock_irqsave() must be used in the poll() and hard_start_xmit() callbacks, at least in nics that support POLL_CONTROLLER :-( -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sleeping in RCU list traversal
Hello. Jun WANG wrote: > I'm sorry,I think I got your idea, if you do not need ptr in > my_task_that_may_sleep(), why you need to grab a reference to "ptr". If > your my_task_that_may_sleep() needs ptr, and according to the > "memory region pointed by "ptr" never be removed." you say, > it is ok to use "ptr" after rcu_read_ulock(). The basic idea behind RCU > is to split updates into "removal" and "reclamation" phases. If you > memory region pointed by "ptr" will not "reclamation" in sleep, it is ok I need "ptr" in my_task_that_may_sleep(), but regarding my case, memory region pointed by "ptr" will never be kfree()ed. So, I don't need to grab a reference to "ptr" because memory region pointed by "ptr" will never be kfree()ed. And it is legal to use "ptr" after rcu_read_unlock() because memory region pointed by "ptr" will never be kfree()ed. Thank you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lockdep: how to tell it multiple pte locks is OK?
On Sat, 06 Oct 2007 23:31:33 -0700 > I'm presume I'm the first person to try holding multiple pte locks at > once, so there's no existing locking order for these locks. I'm > always traversing and locking the pagetable in virtual address order > (and this seems like a sane-enough rule for anyone else who wants to > hold multiple pte locks). I'm not sure that's a valid assumption in light of things like sharing pagetables between processes etc etc.. (granted, that one is out of tree right now but I still hope it'll go in some day:) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Colored kernel output (run3)
* Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > vmlinux: > > textdata bss dec hex filename > > 7732358 1157269 401408 9291035 8dc51b vmlinux.before > > 7732374 1157269 401408 9291051 8dc52b vmlinux.after > > > >16 bytes, or 0.0002% of the total text size. So there's in essence no > >text overhead to talk about. So the text overhead argument is a red > >herring. > > 16 bytes, huh? Can't be. That would be like, perhaps 5, x86 instructions. yes, it's that low, and it's with the feature disabled. (People who enable a feature will of course see text size increase, but that's beside the point.) 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: [PATCH 1/2] Colored kernel output (run3)
On Oct 7 2007 18:59, Ingo Molnar wrote: >> > vmlinux: >> > textdata bss dec hex filename >> > 7732358 1157269 401408 9291035 8dc51b vmlinux.before >> > 7732374 1157269 401408 9291051 8dc52b vmlinux.after >> > >> >16 bytes, or 0.0002% of the total text size. So there's in essence no >> >text overhead to talk about. So the text overhead argument is a red >> >herring. >> >> 16 bytes, huh? Can't be. That would be like, perhaps 5, x86 instructions. > >yes, it's that low, and it's with the feature disabled. Ah, with CONFIG_CKO=n, right. But where does that 16 byte increase come from, when vt.o itself remains constant in size? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Colored kernel output (run3)
* Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Oct 7 2007 18:59, Ingo Molnar wrote: > >> > vmlinux: > >> > textdata bss dec hex filename > >> > 7732358 1157269 401408 9291035 8dc51b vmlinux.before > >> > 7732374 1157269 401408 9291051 8dc52b vmlinux.after > >> > > >> >16 bytes, or 0.0002% of the total text size. So there's in essence no > >> >text overhead to talk about. So the text overhead argument is a red > >> >herring. > >> > >> 16 bytes, huh? Can't be. That would be like, perhaps 5, x86 instructions. > > > >yes, it's that low, and it's with the feature disabled. > > Ah, with CONFIG_CKO=n, right. But where does that 16 byte increase > come from, when vt.o itself remains constant in size? comes from printk.o: textdata bss dec hex filename 6068 231 17636 239355d7f kernel/printk.o 6075 231 17636 239425d86 kernel/printk.o the effect of the extra parameter. But that is not worth #ifdef-ing for. For all practical purposes there's no overhead. 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: lockdep: how to tell it multiple pte locks is OK?
On Oct 7, 2007, at 9:58 AM, Arjan van de Ven wrote: On Sat, 06 Oct 2007 23:31:33 -0700 I'm presume I'm the first person to try holding multiple pte locks at once, so there's no existing locking order for these locks. I'm always traversing and locking the pagetable in virtual address order (and this seems like a sane-enough rule for anyone else who wants to hold multiple pte locks). I'm not sure that's a valid assumption in light of things like sharing pagetables between processes etc etc.. (granted, that one is out of tree right now but I still hope it'll go in some day:) Well, yes, but that will take some thought about how split pte locks will work anyway (or more specifically, fork will probably just end up reusing the pte pages and avoid the need to do any cross-pagetable pte locking anyway, though I guess that will be deferred to COW handling). So are you saying I should pass up the opportunity to optimise a relatively hot path (fork/exec/exit) because it will need some further thought if/when shared ptes get implemented? Doesn't seem like a good tradeoff... J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory controller merge (was Re: -mm merge plans for 2.6.24)
On Fri, 5 Oct 2007, Balbir Singh wrote: > Hugh Dickins wrote: > > > > That's where it should happen, yes; but my point is that it very > > often does not. Because the swap cache page (read in as part of > > the readaround cluster of some other cgroup, or in swapoff by some > > other cgroup) is already assigned to that other cgroup (by the > > mem_cgroup_cache_charge in __add_to_swap_cache), and so goes "The > > page_cgroup exists and the page has already been accounted" route > > when mem_cgroup_charge is called from do_swap_page. Doesn't it? > > > > You are right, at this point I am beginning to wonder if I should > account for the swap cache at all? We account for the pages in RSS > and when the page comes back into the page table(s) via do_swap_page. > If we believe that the swap cache is transitional and the current > expected working behaviour does not seem right or hard to fix, > it might be easy to ignore unuse_pte() and add/remove_from_swap_cache() > for accounting and control. It would be wrong to ignore the unuse_pte() case: what it's intending to do is correct, it's just being prevented by the swapcache issue from doing what it intends at present. (Though I'm not thrilled with the idea of it causing an admin's swapoff to fail because of a cgroup reaching mem limit there, I do agree with your earlier argument that that's the right thing to happen, and it's up to the admin to fix things up - my original objection came from not realizing that normally the cgroup will reclaim from itself to free its mem. Hmm, would the charge fail or the mm get OOM'ed?) Ignoring add_to/remove_from swap cache is what I've tried before, and again today. It's not enough: if you trying run a memhog (something that allocates and touches more memory than the cgroup is allowed, relying on pushing out to swap to complete), then that works well with the present accounting in add_to/remove_from swap cache, but it OOMs once I remove the memcontrol mods from mm/swap_state.c. I keep going back to investigate why, keep on thinking I understand it, then later realize I don't. Please give it a try, I hope you've got better mental models than I have. And I don't think it will be enough to handle shmem/tmpfs either; but won't worry about that until we've properly understood why exempting swapcache leads to those OOMs, and fixed that up. > > Are we misunderstanding each other, because I'm assuming > > MEM_CGROUP_TYPE_ALL and you're assuming MEM_CGROUP_TYPE_MAPPED? > > though I can't see that _MAPPED and _CACHED are actually supported, > > there being no reference to them outside the enum that defines them. > > I am also assuming MEM_CGROUP_TYPE_ALL for the purpose of our > discussion. The accounting is split into mem_cgroup_charge() and > mem_cgroup_cache_charge(). While charging the caches is when we > check for the control_type. It checks MEM_CGROUP_TYPE_ALL there, yes; but I can't find anything checking for either MEM_CGROUP_TYPE_MAPPED or MEM_CGROUP_TYPE_CACHED. (Or is it hidden in one of those preprocesor ## things which frustrate both my greps and me!?) > > Or are you deceived by that ifdef NUMA code in swapin_readahead, > > which propagates the fantasy that swap allocation follows vma layout? > > That nonsense has been around too long, I'll soon be sending a patch > > to remove it. > > The swapin readahead code under #ifdef NUMA is very confusing. I sent a patch to linux-mm last night, to remove that confusion. > I also > noticed another confusing thing during my test, swap cache does not > drop to 0, even though I've disabled all swap using swapoff. May be > those are tmpfs pages. The other interesting thing I tried was running > swapoff after a cgroup went over it's limit, the swapoff succeeded, > but I see strange numbers for free swap. I'll start another thread > after investigating a bit more. Those indeed are strange behaviours (if the swapoff really has succeeded, rather than lying), I not seen such and don't have an explanation. tmpfs doesn't add any weirdness there: when there's no swap, there can be no swap cache. Or is the swapoff still in progress? While it's busy, we keep /proc/meminfo looking sensible, but m can show negative free swap (IIRC). I'll be interested to hear what your investigation shows. Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lockdep: how to tell it multiple pte locks is OK?
On Sun, 7 Oct 2007 10:17:47 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > > On Oct 7, 2007, at 9:58 AM, Arjan van de Ven wrote: > > > On Sat, 06 Oct 2007 23:31:33 -0700 > > > >> I'm presume I'm the first person to try holding multiple pte locks > >> at once, so there's no existing locking order for these locks. I'm > >> always traversing and locking the pagetable in virtual address > >> order (and this seems like a sane-enough rule for anyone else who > >> wants to hold multiple pte locks). > > > > I'm not sure that's a valid assumption in light of things like > > sharing pagetables between processes etc etc.. > > (granted, that one is out of tree right now but I still hope it'll > > go in some day:) > > Well, yes, but that will take some thought about how split pte locks > will work anyway (or more specifically, fork will probably just end > up reusing the pte pages and avoid the need to do any > cross-pagetable pte locking anyway, though I guess that will be > deferred to COW handling). > > So are you saying I should pass up the opportunity to optimise a > relatively hot path (fork/exec/exit) because it will need some > further thought if/when shared ptes get implemented? s/implemented/merged/ :) IN fact shared pagetables are already there for hugepages. For small pages it's a patch at this point. > Doesn't seem > like a good tradeoff... no I'm not saying that. I'm just saying that I'm worried about the locking robustness of your trick in general. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NAK nettiquete (was Re: "Re: [PATCH 0/2] Colored kernel output (run2)"
Em Sun, Oct 07, 2007 at 04:12:22PM +0100, Alan Cox escreveu: > > The few times I've tried to NAK something outright, I've always tried to > > attach > > plenty of technical explanation > > Fair comment to my "silly" response > > The problems I see are > > - We run on a lot more than VGA PC consoles > - We have serial consoles (which may or may not be VT132/ANSI compliant) > - The printk paths are run at IRQ time ASAP to get messages to console, > that could mean we split existing colour escape code processing and the > like. > - People redirect the console feed other places via ioctl. Some of them > parse "<%d>" as the start > > But most importantly: > > - If you want to do "pretty" boot up you do it in X or frame buffer > (which is going to get easier and easier with the X shift to kernel side > video support) > - If you want to do a coloured display after boot then this is a matter > for your logging tools > > As with translation the kernel is the wrong place to do this work. > > What I would much rather people thought about was > > - Marker modes for translation (so you know which bits of a message are > formatted up) > - More consistency on the use of "name: blah" to make it easier to parse > - Turning more messages from kernel logs to events when it makes sense > (eg "Disk Full", "Media Error", "CPU on fire") > > So if you want to do a pretty boot, then solve the big picture, the > framebuffer initrd graphical boot, the boot display, the combining of > artwork and messages in user space from initrd run code. > > 'leet kernel messages in flashing red are not really the problem that > needs solving to do this. Its kinda like we pronounce printk dead for first level error reporting. We are getting more and more closer to that with all the macros that do just that... I'm not following kernel development as I think I should be, but...: dev_printk dev_dbg dev_vdbg DCCP_WARN DCCP_CRIT DCCP_PR_DEBUG LIMIT_NETDEBUG With some more researching I'm sure I'd find more printk wrappers. But I guess this should make some sort of point: using these wrappers get us closer to what Alan wants: consistent printk messages. Such that the life of kcolorls like wrappers get to the point that the life of user level debugging loggers can jump and shout in happiness for providing even nifty popup messages on "modern desktops". As if the problem with modern desktops (or server consoles) was just that... gimme a way to configure wpa-psk on my brand new company notebook without having to resort to, ugh, command line assistance... Bluetooth without having to manually do "service bluetooth start"... - Arnaldo P.S.: I know that that is just in the making, dbus and a lot of other buzzwords that keep promising to solve these kinds of problems :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sleeping in RCU list traversal
On Mon, 2007-10-08 at 01:56 +0900, Tetsuo Handa wrote: > So, I don't need to grab a reference to "ptr" > because memory region pointed by "ptr" will never be kfree()ed. > And it is legal to use "ptr" after rcu_read_unlock() > because memory region pointed by "ptr" will never be kfree()ed. Still think that is a very BAD (tm) idea. Esp since with the help of RCU there is hardly any performance loss of not doing proper deletes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On 10/07/2007 06:12 PM, Ingo Molnar wrote: * Oleg Verych <[EMAIL PROTECTED]> wrote: Coloring isn't useful. If it was, it would be implemented ~16 years ago. Congratulations, this is the most stupid argument i've ever read on lkml. "Ay. World is finished. Everyone can go home and watch Friends reruns now." But well, there actually have been worse arguments given that VGA console is getting less and less important. I recently did a perusal of alternative distributions and didn't find a single one that didn't default to having a splash screen hide the kernel during boot (and if I'm not mistaken, only one of them provided me with the option during installation to not boot into X immediately afterwards). Sure, that in itself needn't necesarily be of concern to anyone who, err, is not concerned but any such colouring feature appearing when there's only a smathering of people left that still cares about the VGA console in the first place really isn't all _that_ far out as an argument... Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix Oops in toshiba_acpi error return path
On Sunday 07 October 2007, Andrey Borzenkov wrote: > This fixes oops when registering backlight device fails. Attached as I still > cannot convince kmail to not mangle long lines ... > > -andrey > Re: kmail - it usually behaves well with the patches as long as you turn off word wrapping and use "Insert file..." to insert them. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Oct 7 2007 20:47, Rene Herman wrote: > >> > Coloring isn't useful. If it was, it would be implemented ~16 years >> > ago. >> >> Congratulations, this is the most stupid argument i've ever read on lkml. > > "Ay. World is finished. Everyone can go home and watch Friends reruns now." > > But well, there actually have been worse arguments given that VGA console is > getting less and less important. >[...] > Sure, that in itself needn't necesarily be of concern to anyone who, err, is > not concerned but any such colouring feature appearing when there's only a > smathering of people left that still cares about the VGA console in the first > place really isn't all _that_ far out as an argument... In case you have not noticed, the coloring also applies to FB. As far as I can oversee, it's only "missing" for serial and PROMs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 0/3 checkpatch updates, new checkfiles script
In message <[EMAIL PROTECTED]>, Ingo Molnar writes:
>
> * Erez Zadok <[EMAIL PROTECTED]> wrote:
>
> > So, I ran the above script and it found nearly 1.5 million reported
> > warnings/errors, with drivers being the largest abuser, not
> > surprisingly. [...]
>
> have you tried that with the latest version too:
>
>
> http://www.kernel.org/pub/linux/kernel/people/apw/checkpatch/checkpatch.pl-next
>
> it outputs far fewer false positives.
>
> Ingo
Andy, Ingo,
I tried the new checkpatch.pl on 2.6.23-rc9:
$ ./scripts/checkpatch.pl -q --file --emacs fs/namei.c
and got many perl warnings such as:
Use of uninitialized value in concatenation (.) or string at
./scripts/checkpatch.pl line 455.
followed by the usual verbose error message instead of one-per-line as I
assume the --emacs option is supposed to produce:
:2823: WARNING: EXPORT_SYMBOL(foo); should immediately follow its
function/variable
#2823: FILE: namei.c:2820:
+EXPORT_SYMBOL(vfs_mkdir);
BTW, calling the option --emacs is a bit too restrictive. Emacs didn't
invent the format of "filename:linenumeber:message". C compilers had it
before. Even "grep -n *" had it before. That's why I think calling it a
"terse output" option may be more accurate.
The following small patch to checkpath.pl-next seems to fix the perl
warnings, but it still outputs the long error messages along with the
shorter one-liners.
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index bdc493e..bbc4825 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -85,7 +85,7 @@ for my $filename (@ARGV) {
push(@rawlines, $_);
}
close(FILE);
- if (!process($ARGV, @rawlines)) {
+ if (!process($filename, @rawlines)) {
$exit = 1;
}
@rawlines = ();
@@ -452,7 +452,7 @@ sub process {
my $rawline = $line;
- $prefix = "$ARGV:$linenr: " if ($emacs);
+ $prefix = "$filename:$linenr: " if ($emacs);
#extract the filename as it passes
if ($line=~/^\+\+\+\s+(\S+)/) {
Cheers,
Erez.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote: > On 10/07/2007 06:12 PM, Ingo Molnar wrote: > > >* Oleg Verych <[EMAIL PROTECTED]> wrote: > > >>Coloring isn't useful. If it was, it would be implemented ~16 years > >>ago. > > > >Congratulations, this is the most stupid argument i've ever read on > >lkml. > > "Ay. World is finished. Everyone can go home and watch Friends reruns now." > > But well, there actually have been worse arguments given that VGA console > is getting less and less important. I recently did a perusal of alternative > distributions and didn't find a single one that didn't default to having a > splash screen hide the kernel during boot (and if I'm not mistaken, only > one of them provided me with the option during installation to not boot > into X immediately afterwards). I don't recall having seen any splash screen on Slackware. And fortunately, the mainstream distros still provide the option to boot in text mode. > Sure, that in itself needn't necesarily be of concern to anyone who, err, > is not concerned but any such colouring feature appearing when there's only > a smathering of people left that still cares about the VGA console in the > first place really isn't all _that_ far out as an argument... There are two distinct populations : - those who are afraid of boot messages and prefer "splash" screens. Those people are most common users, grown in non-IT environments. They are happy to see a big logo on their BIOS to hide important boot errors, and they are the ones who would never have imagined that pressing Escape during the boot of windows 3.1/95 provided them with the full text messages. Basically, they want to ensure they will never have to worry about things they don't understand. - those who are troubleshooting their system in the early stages (kernel, filesystems, network, services, ...). These ones *need* boot messages. And there, depending on the hardware, sometimes the FB is better because it shows larger lines, sometimes it's worse because the scrollback is limited by too low memory. I personally fit in the second category. And I'm sure most people on this list do. I would be miserably sad if I couldn't get my boot messages anymore. It already irritates me a lot to loose the ones displayed before switching to frame-buffer when a hang happens just afterwards... I would say that while I'm not particularly fond of flashy colors everywhere, I think that being able to use colors to indicate particular actions in progress or conditions can be a good thing. RAID errors, devices disabled due to command-line parameters, and general anomalies which can cause a hang or panic a few line laters are worth coloring. And I don't believe in userland's help here, because for that type of messages, the indication should be returned immediately. For instance, anyone who has experienced read errors on and IDE disk knows that it can literally take hours/days to boot, after displaying thousands of messages. Here, having the ability to see that no IRQ was assigned or something like this could help. Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
msync(2) bug(?), returns AOP_WRITEPAGE_ACTIVATE to userland
According to vfs.txt, ->writepage() may return AOP_WRITEPAGE_ACTIVATE back to the VFS/VM. Indeed some filesystems such as tmpfs can return AOP_WRITEPAGE_ACTIVATE; and stackable file systems (e.g., Unionfs) also return AOP_WRITEPAGE_ACTIVATE if the lower f/s returned it. Anyway, some Ubuntu users of Unionfs reported that msync(2) sometimes returns AOP_WRITEPAGE_ACTIVATE (decimal 524288) back to userland. Therefore, some user programs fail, esp. if they're written such as this: err = msync(...); if (err != 0) // fail They temporarily fixed the specific program in question (apt-get) to check if (err < 0) // fail Is this a bug indeed, or are user programs supposed to handle AOP_WRITEPAGE_ACTIVATE (I hope not the latter). If it's a kernel bug, what should the kernel return: a zero, or an -errno (and which one)? Thanks, Erez. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On 10/07/2007 08:58 PM, Jan Engelhardt wrote: On Oct 7 2007 20:47, Rene Herman wrote: Coloring isn't useful. If it was, it would be implemented ~16 years ago. Congratulations, this is the most stupid argument i've ever read on lkml. "Ay. World is finished. Everyone can go home and watch Friends reruns now." But well, there actually have been worse arguments given that VGA console is getting less and less important. [...] Sure, that in itself needn't necesarily be of concern to anyone who, err, is not concerned but any such colouring feature appearing when there's only a smathering of people left that still cares about the VGA console in the first place really isn't all _that_ far out as an argument... In case you have not noticed, the coloring also applies to FB. As far as I can oversee, it's only "missing" for serial and PROMs. Must say I did concentrate on VGA, but the [...] bit in the quote above was about how everything I encountered put up a bootsplash hiding _everything_ and about booting into X immediately, not about FB... I saw you remark on FB console in a reply to Alan just now and I quite agree with you. The (current) FB console is slow and I'll add "dumb" myself. When you have a 1280x1024 screen available, you get to do cool things like put up nice little windows and exclamation mark icons on errors, not just pretend you're really 132x50 (or whatever). Alan's sketched more generic markup/unification would be The Way Forward it seems. Given that TWF is mostly defined as "That Which Is Not" (and how it seems to have a tendency to defend that status vigorously) telling me/us to shelve that objection for 10 years might be okay -- but generally I'm having a fairly hard time getting excited about printk colourizing. Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Sun, Oct 07, 2007 at 09:13:09PM +0200, Willy Tarreau wrote: > On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote: > > On 10/07/2007 06:12 PM, Ingo Molnar wrote: > > > > >* Oleg Verych <[EMAIL PROTECTED]> wrote: > > > > >>Coloring isn't useful. If it was, it would be implemented ~16 years > > >>ago. > > > > > >Congratulations, this is the most stupid argument i've ever read on > > >lkml. [] > I would say that while I'm not particularly fond of flashy colors > everywhere, I think that being able to use colors to indicate particular > actions in progress or conditions can be a good thing. RAID errors, > devices disabled due to command-line parameters, and general anomalies > which can cause a hang or panic a few line laters are worth coloring. That *is* the coloring, i'm talking about. > And I don't believe in userland's help here, because for that type of > messages, the indication should be returned immediately. In the very buggy cases, i think, everything just hang. Otherwise initramfs stuff can deal with it. > For instance, anyone who has experienced read errors on and IDE disk > knows that it can literally take hours/days to boot, after displaying > thousands of messages. Here, having the ability to see that no IRQ was > assigned or something like this could help. As i'm pretty much in all that text(tty)-mode stuff anyway, maybe after some time i will propose something klibc/tty based. Mainly a bit of user interface: split scrolling regions for errors and notifications; flexible color schemas (keyword highlighting); keyboard events. Of course it will work in such IDE cases, only if driver is a module. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 Kernel Markers - performance characterization with large IO load on large-ish system
* Alan D. Brunelle <[EMAIL PROTECTED]> wrote: > o All kernels start off with Linux 2.6.23-rc6 + 2.6.23-rc6-mm1 > > o '- bt cfg' or '+ bt cfg' means a kernel without or with blktrace > configured respectively. > > o '- markers' or '+ markers' means a kernel without or with the > 11-patch marker series respectively. > > 38 runs without blk traces being captured (dropped hi/lo value from 40 runs) > > Kernel Options Min valAvg valMax valStd Dev > -- - - - - > - markers - bt cfg 15.349127 16.169459 16.372980 0.184417 > + markers - bt cfg 15.280382 16.202398 16.409257 0.191861 > > - markers + bt cfg 14.464366 14.754347 16.052306 0.463665 > + markers + bt cfg 14.421765 14.644406 15.690871 0.233885 actually, the pure marker overhead seems to be a regression: > - markers - bt cfg 15.349127 16.169459 16.372980 0.184417 > + markers - bt cfg 15.280382 16.202398 16.409257 0.191861 why isnt the marker near zero-cost as it should be? (as long as they are enabled but are not in actual use) 2% increase is _ALOT_. That's the whole point of good probes: they do not slow down the normal kernel. _Worst case_ it should be at most a few instructions overhead but that does not explain the ~2% wall-clock time regression you measured here. So there's something wrong going on - either markers have unacceptably high cost, or the measurement is not valid. 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: [PATCH 2/5] forcedeth: interrupt handling cleanup
On 10/7/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: > Yinghai Lu wrote: > > On 10/6/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: > >> commit a606d2a111cdf948da5d69eb1de5526c5c2dafef > >> Author: Jeff Garzik <[EMAIL PROTECTED]> > >> Date: Fri Oct 5 22:56:05 2007 -0400 > >> > >> [netdrvr] forcedeth: interrupt handling cleanup > >> > >> * nv_nic_irq_optimized() and nv_nic_irq_other() were complete > >> duplicates > >> of nv_nic_irq(), with the exception of one function call. > >> Consolidate > >> all three into a single interrupt handler, deleting a lot of > >> redundant > >> code. > >> > >> * greatly simplify irq handler locking. > >> > >> Prior to this change, the irq handler(s) would acquire and release > >> np->lock for each action (RX, TX, other events). > >> > >> For the common case -- RX or TX work -- the lock is always acquired, > >> making all successive acquire/release combinations largely redundant. > >> > >> Acquire the lock at the beginning of the irq handler, and release it > >> at > >> the end of the irq handler. This is simple, easy, and obvious. > >> > >> * remove irq handler work loop. > >> > >> All interesting events emanating from the irq handler either have > >> their own work loops, or they poke a timer into action. > >> > >> Therefore, delete the pointless master interrupt handler work loop. > >> > >> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> > >> > Do you have ideas/suggestions for a different method? in the e1000 driver, it has seperate handler for msi and ioapic. but in forcedeth, the nv_nic_irq_optimized keep check msi_flags..., with num of msi interrupt number, that could cause cpu loading get a little bit high..., even the network performance is ok. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] forcedeth: several proposed updates for testing
On 10/7/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: > Jeff Garzik wrote: > > The 'fe-lock' branch of > > git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git fe-lock > OK, I've successfully tested patches 1-5 on an AMD64 system with > > 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3) need to test that with mcp55 based, that will use MSI. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Oops] on 2.6.23-rc9 sysRq Show Tasks (t)
On Sun, Oct 07, 2007 at 01:12:38AM +0400, Alexey Dobriyan wrote: > On Sat, Oct 06, 2007 at 10:14:06PM +0200, Ahmed S. Darwish wrote: > > Pressing sysRq+T always produce an Oops for every running system task (94 > > Oopses, that's a record ;)). > > uh-oh. For every sleeping task, I think. > > > The bug is 100% reproducable. Should I begin bisecting/investigating the > > issue or it's a known problem ? > > Start with some old kernel, like mmm.. 2.6.0. The fact that same behaviour > was present there may make you think about faulty assumptions you've > made. > Yeah I understood my mistake (not an Oops, a normal behaviour). Thanks for your advice :). -- Ahmed S. Darwish HomePage: http://darwish.07.googlepages.com Blog: http://darwish-07.blogspot.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[TRIVIAL PATCH] Remove unused variable in drivers/dma/ioatdma.c
Hi, I found this in an `allyesconfig' build: CC drivers/dma/ioatdma.o drivers/dma/ioatdma.c: In function #ioat_dma_free_chan_resources#: drivers/dma/ioatdma.c:247: warning: unused variable #chanctrl# Hannes Signed-off-by: Johannes Weiner <[EMAIL PROTECTED]> diff --git a/drivers/dma/ioatdma.c b/drivers/dma/ioatdma.c index 41b18c5..d9db64b 100644 --- a/drivers/dma/ioatdma.c +++ b/drivers/dma/ioatdma.c @@ -244,7 +244,6 @@ static void ioat_dma_free_chan_resources(struct dma_chan *chan) struct ioat_dma_chan *ioat_chan = to_ioat_chan(chan); struct ioat_device *ioat_device = to_ioat_device(chan->device); struct ioat_desc_sw *desc, *_desc; - u16 chanctrl; int in_use_descs = 0; ioat_dma_memcpy_cleanup(ioat_chan); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.23-rc9-git5: Known regressions from 2.6.22
This message contains a list of some known regressions from 2.6.22 for which there are no fixes in the mainline that I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.22, please let me know either and I'll add them to the list. Subject:zd1211 device is no longer configured Submitter: Oliver Neukum <[EMAIL PROTECTED]> References: http://marc.info/?l=linux-usb-devel&m=118854967709322&w=2 http://bugzilla.kernel.org/show_bug.cgi?id=8972 Caused-By: Daniel Drake <[EMAIL PROTECTED]> commit 74553aedd46b3a2cae986f909cf2a3f99369decc Subject:Oops while modprobing phy fixed module Submitter: Gabriel C <[EMAIL PROTECTED]> References: http://lkml.org/lkml/2007/7/14/63 http://bugzilla.kernel.org/show_bug.cgi?id=9060 Handled-By: Satyam Sharma <[EMAIL PROTECTED]> Vitaly Bordug <[EMAIL PROTECTED]> Tejun Heo <[EMAIL PROTECTED]> Patch: http://lkml.org/lkml/2007/7/18/506 Subject:ACPI problems: 2.6.22-git17 working, 2.6.23-rc1* is not Submitter: Danny ter Haar <[EMAIL PROTECTED]> References: http://lkml.org/lkml/2007/7/27/298 http://lkml.org/lkml/2007/7/29/371 http://bugzilla.kernel.org/show_bug.cgi?id=9061 Handled-By: Len Brown <[EMAIL PROTECTED]> Subject:empty suspend stopped working around 2.6.23-rc4 Submitter: Pavel Machek <[EMAIL PROTECTED]> References: http://lkml.org/lkml/2007/9/11/326 http://bugzilla.kernel.org/show_bug.cgi?id=9075 Subject:umount triggers a warning in jfs and takes almost a minute Submitter: Oliver Neukum <[EMAIL PROTECTED]> References: http://lkml.org/lkml/2007/9/4/73 http://bugzilla.kernel.org/show_bug.cgi?id=9076 Handled-By: Dave Kleikamp <[EMAIL PROTECTED]> Patch: http://bugzilla.kernel.org/attachment.cgi?id=13023&action=view Subject:NETDEV WATCHDOG: eth0: transmit timed out Submitter: Karl Meyer <[EMAIL PROTECTED]> References: http://lkml.org/lkml/2007/8/13/737 http://bugzilla.kernel.org/show_bug.cgi?id=9079 Handled-By: Francois Romieu <[EMAIL PROTECTED]> Subject:Weird network problems with 2.6.23-rc2 Submitter: Shish <[EMAIL PROTECTED]> References: http://lkml.org/lkml/2007/8/11/40 http://bugzilla.kernel.org/show_bug.cgi?id=9080 Subject:powersaving degradation, (time spend in C0 goes up after a while) Submitter: Christian Leber <[EMAIL PROTECTED]> References: http://lkml.org/lkml/2007/9/2/142 http://lkml.org/lkml/2007/9/2/207 http://bugzilla.kernel.org/show_bug.cgi?id=9081 Subject:kernel oops when unplugging usb mouse, sometimes hardlock when moving mouse Submitter: o. meijer <[EMAIL PROTECTED]> References: http://bugzilla.kernel.org/show_bug.cgi?id=9111 Handled-By: Dmitry Torokhov <[EMAIL PROTECTED]> Subject:2.6.23-rcX SG_GET_SCSI_ID regression? Submitter: Joerg Platte <[EMAIL PROTECTED]> References: http://lkml.org/lkml/2007/10/3/101 http://bugzilla.kernel.org/show_bug.cgi?id=9123 For details, please follow the links given in references. As you can see, there is a Bugzilla entry for each of the listed regressions. I'm the owner of some of these entries, so if you want me to reassign them to someone else, please let me know. There also is a Bugzilla entry used for tracking the regressions from 2.6.22, unresolved as well as resolved, at: http://bugzilla.kernel.org/show_bug.cgi?id=9056 Please let me know if there are any Bugzilla entries that should be added to the list in there. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On 10/07/2007 09:13 PM, Willy Tarreau wrote: On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote: But well, there actually have been worse arguments given that VGA console is getting less and less important. I recently did a perusal of alternative distributions and didn't find a single one that didn't default to having a splash screen hide the kernel during boot (and if I'm not mistaken, only one of them provided me with the option during installation to not boot into X immediately afterwards). I don't recall having seen any splash screen on Slackware. Indeed, but that's the distribution I use and considered switching away from. Just my luck eh? :-\ There are two distinct populations : - those who are afraid of boot messages and prefer "splash" screens. Those people are most common users, grown in non-IT environments. They are happy to see a big logo on their BIOS to hide important boot errors, and they are the ones who would never have imagined that pressing Escape during the boot of windows 3.1/95 provided them with the full text messages. Basically, they want to ensure they will never have to worry about things they don't understand. Nor want to understand, often. - those who are troubleshooting their system in the early stages (kernel, filesystems, network, services, ...). These ones *need* boot messages. And there, depending on the hardware, sometimes the FB is better because it shows larger lines, sometimes it's worse because the scrollback is limited by too low memory. I personally fit in the second category. And I'm sure most people on this list do. As do I ofcourse. An operating system kernel development list might provide for a fairly non-average balanced population of "am / am not interested in the inner workings of computers". Given that most everyone these days uses a computer, it's still a really small percentage though -- and as evidenced by the bootsplash thing, even of Linux users (and I've in fact heard real-life people say they disliked the noisy Linux bootup due to "all those errors"). I would be miserably sad if I couldn't get my boot messages anymore. It already irritates me a lot to loose the ones displayed before switching to frame-buffer when a hang happens just afterwards... Oh quite. I use VGA console myself. But not being able to get to the bootup messages anymore even for people who do care is not the issue. It's about finding it a bit hard to get excited about colourization when the "obvious" way forward is so much more graphically oriented. As also commented in another reply just now, ways forward also tend to have their problems but this kind of "innovation" takes me back to the time when our favorite bulletins board adopted ANSI colours. Today, that seems just a tad pathetic... Again, it might not hurt any either, but sheesh. Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Oct 7 2007 21:13, Willy Tarreau wrote: >There are two distinct populations : > - those [...] >who would never have imagined that pressing Escape >during the boot of windows 3.1/95 provided them with the full text >messages. This is news to me. DOS always showed messages, and under Win95, it was either F8 or removing logo.sys. I did troubleshoot it ;-) > - those who are troubleshooting their system [...] > >I personally fit in the second category. > >I would say that while I'm not particularly fond of flashy colors >everywhere I have to agree so really. Just because there's a color option for everything does not mean one should use it. In fact, I moved away[2] from the default Midnight Commander styling because it's just - as Dave calls it - salad colors[1]. Some is good, as long as it is not excessive. While I could imagine that Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, this is not what serious people would do. [1] http://tinyurl.com/yr9zgq [2] http://tinyurl.com/234ba3 >, I think that being able to use colors to indicate particular >actions in progress or conditions can be a good thing. RAID errors, >devices disabled due to command-line parameters, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sleeping in RCU list traversal
Hello. Peter Zijlstra wrote: > > So, I don't need to grab a reference to "ptr" > > because memory region pointed by "ptr" will never be kfree()ed. > > And it is legal to use "ptr" after rcu_read_unlock() > > because memory region pointed by "ptr" will never be kfree()ed. > > Still think that is a very BAD (tm) idea. Esp since with the help of RCU > there is hardly any performance loss of not doing proper deletes. > Elements I keep in RCU list are policy table for access control that are referred throughout the lifetime of the kernel. So, there is hardly any needs to delete these elements. Honestly speaking, I don't need to use RCU list at all. Just using a singly linked list that doesn't support deletion is enough. But James Morris advises me to use the existing API ( http://lkml.org/lkml/2007/10/2/156 http://lkml.org/lkml/2007/10/3/124 ). Thank you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: msync(2) bug(?), returns AOP_WRITEPAGE_ACTIVATE to userland
Hi Erez,
On 10/7/07, Erez Zadok <[EMAIL PROTECTED]> wrote:
> Anyway, some Ubuntu users of Unionfs reported that msync(2) sometimes
> returns AOP_WRITEPAGE_ACTIVATE (decimal 524288) back to userland.
> Therefore, some user programs fail, esp. if they're written such as
> this:
[snip]
On 10/7/07, Erez Zadok <[EMAIL PROTECTED]> wrote:
> Is this a bug indeed, or are user programs supposed to handleÂ
> AOP_WRITEPAGE_ACTIVATE (I hope not the latter). If it's a kernel bug,
> what should the kernel return: a zero, or an -errno (and which one)?
It's a kernel bug. AOP_WRITEPAGE_ACTIVATE is a hint to the VM to avoid
writeback of the page in the near future. I wonder if it's enough that we
change the return value to zero from
mm/page-writeback.c:write_cache_pages() in case we hit AOP_WRITEPAGE_ACTIVE...
Pekka
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 63512a9..717f341 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -672,8 +672,10 @@ retry:
ret = (*writepage)(page, wbc, data);
- if (unlikely(ret == AOP_WRITEPAGE_ACTIVATE))
+ if (unlikely(ret == AOP_WRITEPAGE_ACTIVATE)) {
unlock_page(page);
+ ret = 0;
+ }
if (ret || (--(wbc->nr_to_write) <= 0))
done = 1;
if (wbc->nonblocking && bdi_write_congested(bdi)) {
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On 10/07/2007 09:56 PM, Jan Engelhardt wrote: Some is good, as long as it is not excessive. While I could imagine that Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, this is not what serious people would do. [1] http://tinyurl.com/yr9zgq [2] http://tinyurl.com/234ba3 Given this discussion, I find it really appropriate that you are posting _graphics_ of your text screens :-) Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Oct 7 2007 21:27, Rene Herman wrote: > > I saw you remark on FB console in a reply to Alan just now and I > quite agree with you. The (current) FB console is slow and I'll add > "dumb" myself. When you have a 1280x1024 screen available, you get > to do cool things like put up nice little windows and exclamation > mark icons on errors, not just pretend you're really 132x50 (or > whatever). CVIDIX, while card-dependent I think, is much better at speed than FB while still providing 720x400 or even higher. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Oct 7 2007 22:00, Rene Herman wrote: > On 10/07/2007 09:56 PM, Jan Engelhardt wrote: > >> Some is good, as long as it is not excessive. While I could imagine that >> Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, this >> is not what serious people would do. >> >> [1] http://tinyurl.com/yr9zgq >> [2] http://tinyurl.com/234ba3 > > Given this discussion, I find it really appropriate that you are posting > _graphics_ of your text screens :-) I can give you a VCSA file (as produced by /dev/vcsa1) if you like, complete with VCSA reader. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] forcedeth: several proposed updates for testing
Yinghai Lu wrote: On 10/7/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: Jeff Garzik wrote: The 'fe-lock' branch of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git fe-lock OK, I've successfully tested patches 1-5 on an AMD64 system with 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3) need to test that with mcp55 based, that will use MSI. I would love to see an MSI-X test too (might have to turn on throughput mode). 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 2/5] forcedeth: interrupt handling cleanup
Yinghai Lu wrote: On 10/7/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: Yinghai Lu wrote: On 10/6/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: commit a606d2a111cdf948da5d69eb1de5526c5c2dafef Author: Jeff Garzik <[EMAIL PROTECTED]> Date: Fri Oct 5 22:56:05 2007 -0400 [netdrvr] forcedeth: interrupt handling cleanup * nv_nic_irq_optimized() and nv_nic_irq_other() were complete duplicates of nv_nic_irq(), with the exception of one function call. Consolidate all three into a single interrupt handler, deleting a lot of redundant code. * greatly simplify irq handler locking. Prior to this change, the irq handler(s) would acquire and release np->lock for each action (RX, TX, other events). For the common case -- RX or TX work -- the lock is always acquired, making all successive acquire/release combinations largely redundant. Acquire the lock at the beginning of the irq handler, and release it at the end of the irq handler. This is simple, easy, and obvious. * remove irq handler work loop. All interesting events emanating from the irq handler either have their own work loops, or they poke a timer into action. Therefore, delete the pointless master interrupt handler work loop. Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> Do you have ideas/suggestions for a different method? in the e1000 driver, it has seperate handler for msi and ioapic. but in forcedeth, the nv_nic_irq_optimized keep check msi_flags..., with num of msi interrupt number, that could cause cpu loading get a little bit high..., even the network performance is ok. With all the activity in the interrupt handler, a few in-cache branches are definitely going to be lost in the noise. Separating the interrupt handlers between MSI and non-MSI tends to be of more benefit when the separation is accompanied by more efficient locking in the MSI interrupt handler, or a different mode of interrupt clear, or some other attribute. Though CPU usage would be a good thing to measure, with these patches. 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: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On 10/07/2007 10:04 PM, Jan Engelhardt wrote: On Oct 7 2007 22:00, Rene Herman wrote: On 10/07/2007 09:56 PM, Jan Engelhardt wrote: Some is good, as long as it is not excessive. While I could imagine that Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, this is not what serious people would do. [1] http://tinyurl.com/yr9zgq [2] http://tinyurl.com/234ba3 Given this discussion, I find it really appropriate that you are posting _graphics_ of your text screens :-) I can give you a VCSA file (as produced by /dev/vcsa1) if you like, complete with VCSA reader. No, the PNGs will do thanks, it was obviuously a bit of a cheap shot. Still, it _is_ somewhat of a comment on what's expected these days. Rene - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix SH4 DMAC API
On Sat, Oct 06, 2007 at 02:52:43PM +0100, Adrian McMenamin wrote: > This patch fixes the DMA cascade by masking the correct bits. > > Tested and working with Dreamcast PVR2 DMA. With this patch applied > the existing mainline code in arch/sh/drivers/dma/dma-sh.c works, > whereas before I was patching that to get round this problem. > > Signed-off by: Adrian McMenamin <[EMAIL PROTECTED]> > Applied, 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/
tty UI (Re: [PATCH 0/2] Colored kernel output (run2))
On Sun, Oct 07, 2007 at 10:04:44PM +0200, Jan Engelhardt wrote: > > On Oct 7 2007 22:00, Rene Herman wrote: > > On 10/07/2007 09:56 PM, Jan Engelhardt wrote: > > > >> Some is good, as long as it is not excessive. While I could imagine that > >> Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, > >> this > >> is not what serious people would do. > >> > >> [1] http://tinyurl.com/yr9zgq > >> [2] http://tinyurl.com/234ba3 > > > > Given this discussion, I find it really appropriate that you are posting > > _graphics_ of your text screens :-) > > I can give you a VCSA file (as produced by /dev/vcsa1) if you like, > complete with VCSA reader. In fact mc config (ini) section is a better way. I use default blue (which is very annoying) for root user, to be aware of possible results. Otherwise i use black background: [Colors] color_terminals=linux,xterm base_color=normal=lightgray,black:marked=magenta,black:executable=green,black:directory=lightgray,black:editnormal=green,black:editbold=red,black The most exiting event recently was, that `lynx` in debian got updated, so it displays much more colors for HTML formatting now. I'm happy. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tty UI (Re: [PATCH 0/2] Colored kernel output (run2))
On Oct 7 2007 22:50, Oleg Verych wrote: > >In fact mc config (ini) section is a better way. Yes, for the default colors. But /usr/share/mc/syntax/ specifies more of them. >I use default blue (which is very annoying) If blue were annoying, it would not be the default Windows background (since Windows 2000). Then again, it's personal preference, so I suppose you have a red/green desktop wallpaper for X11? >The most exiting event recently was, that `lynx` in debian got updated, so >it displays much more colors for HTML formatting now. I'm happy. lynx. Update. Ha. Get w3m. Seriously. :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] [0/6] Some scheduler changes for sched-devel
- Various source code cleanups (no functional changes) - Shrink binary size by refactoring some code - One K8 optimization that is unfortunately not measurable. But it sounded good in theory! @) (if you have a better scheduling latency benchmark than lmbench3 it would be cool to try) - One real bug fix for a obscure problem All against the sched-devel git tree with d024f67c652f7f0519d2a1906b646286abbb2e48 head. Future wishlist: someone document all the magic numbers in the load balancer code. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/6] scheduler: Remove some unnecessary gotos in sched.c
No need to be more spagetti than absolutely necessary.
Replace loops implemented with gotos with real loops.
Replace err = ...; goto x; x: return err; with return ...;
No functional changes.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linux-2.6-sched-devel/kernel/sched.c
===
--- linux-2.6-sched-devel.orig/kernel/sched.c
+++ linux-2.6-sched-devel/kernel/sched.c
@@ -555,16 +555,13 @@ static inline void finish_lock_switch(st
static inline struct rq *__task_rq_lock(struct task_struct *p)
__acquires(rq->lock)
{
- struct rq *rq;
-
-repeat_lock_task:
- rq = task_rq(p);
- spin_lock(&rq->lock);
- if (unlikely(rq != task_rq(p))) {
+ for (;;) {
+ struct rq *rq = task_rq(p);
+ spin_lock(&rq->lock);
+ if (likely(rq == task_rq(p)))
+ return rq;
spin_unlock(&rq->lock);
- goto repeat_lock_task;
}
- return rq;
}
/*
@@ -577,15 +574,14 @@ static struct rq *task_rq_lock(struct ta
{
struct rq *rq;
-repeat_lock_task:
- local_irq_save(*flags);
- rq = task_rq(p);
- spin_lock(&rq->lock);
- if (unlikely(rq != task_rq(p))) {
+ for (;;) {
+ local_irq_save(*flags);
+ rq = task_rq(p);
+ spin_lock(&rq->lock);
+ if (likely(rq == task_rq(p)))
+ return rq;
spin_unlock_irqrestore(&rq->lock, *flags);
- goto repeat_lock_task;
}
- return rq;
}
static void __task_rq_unlock(struct rq *rq)
@@ -1076,69 +1072,71 @@ void wait_task_inactive(struct task_stru
int running, on_rq;
struct rq *rq;
-repeat:
- /*
-* We do the initial early heuristics without holding
-* any task-queue locks at all. We'll only try to get
-* the runqueue lock when things look like they will
-* work out!
-*/
- rq = task_rq(p);
+ for (;;) {
+ /*
+* We do the initial early heuristics without holding
+* any task-queue locks at all. We'll only try to get
+* the runqueue lock when things look like they will
+* work out!
+*/
+ rq = task_rq(p);
- /*
-* If the task is actively running on another CPU
-* still, just relax and busy-wait without holding
-* any locks.
-*
-* NOTE! Since we don't hold any locks, it's not
-* even sure that "rq" stays as the right runqueue!
-* But we don't care, since "task_running()" will
-* return false if the runqueue has changed and p
-* is actually now running somewhere else!
-*/
- while (task_running(rq, p))
- cpu_relax();
+ /*
+* If the task is actively running on another CPU
+* still, just relax and busy-wait without holding
+* any locks.
+*
+* NOTE! Since we don't hold any locks, it's not
+* even sure that "rq" stays as the right runqueue!
+* But we don't care, since "task_running()" will
+* return false if the runqueue has changed and p
+* is actually now running somewhere else!
+*/
+ while (task_running(rq, p))
+ cpu_relax();
- /*
-* Ok, time to look more closely! We need the rq
-* lock now, to be *sure*. If we're wrong, we'll
-* just go back and repeat.
-*/
- rq = task_rq_lock(p, &flags);
- running = task_running(rq, p);
- on_rq = p->se.on_rq;
- task_rq_unlock(rq, &flags);
+ /*
+* Ok, time to look more closely! We need the rq
+* lock now, to be *sure*. If we're wrong, we'll
+* just go back and repeat.
+*/
+ rq = task_rq_lock(p, &flags);
+ running = task_running(rq, p);
+ on_rq = p->se.on_rq;
+ task_rq_unlock(rq, &flags);
- /*
-* Was it really running after all now that we
-* checked with the proper locks actually held?
-*
-* Oops. Go back and try again..
-*/
- if (unlikely(running)) {
- cpu_relax();
- goto repeat;
- }
+ /*
+* Was it really running after all now that we
+* checked with the proper locks actually held?
+*
+* Oops. Go back and try again..
+*/
+ if (unlikely(running)) {
+ cpu_relax();
+ continue;
+ }
- /*
-* It's not enough that it's not actively running,
-* it must be off the runqueue _en
[PATCH] [2/6] scheduler: Refactor common code of sleep_on / wait_for_completion
These functions were largely cut'n'pasted. This moves
the common code into single helpers instead. Advantage
is about 1k less code on x86-64 and 91 lines of code removed.
It adds one function call to the non timeout version of
the functions; i don't expect this to be measurable.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linux-2.6-sched-devel/kernel/sched.c
===
--- linux-2.6-sched-devel.orig/kernel/sched.c
+++ linux-2.6-sched-devel/kernel/sched.c
@@ -3689,206 +3689,115 @@ void fastcall complete_all(struct comple
}
EXPORT_SYMBOL(complete_all);
-void fastcall __sched wait_for_completion(struct completion *x)
+static inline long __sched
+do_wait_for_common(struct completion *x, long timeout, int state)
{
- might_sleep();
-
- spin_lock_irq(&x->wait.lock);
if (!x->done) {
DECLARE_WAITQUEUE(wait, current);
wait.flags |= WQ_FLAG_EXCLUSIVE;
__add_wait_queue_tail(&x->wait, &wait);
do {
- __set_current_state(TASK_UNINTERRUPTIBLE);
- spin_unlock_irq(&x->wait.lock);
- schedule();
- spin_lock_irq(&x->wait.lock);
- } while (!x->done);
- __remove_wait_queue(&x->wait, &wait);
- }
- x->done--;
- spin_unlock_irq(&x->wait.lock);
-}
-EXPORT_SYMBOL(wait_for_completion);
-
-unsigned long fastcall __sched
-wait_for_completion_timeout(struct completion *x, unsigned long timeout)
-{
- might_sleep();
-
- spin_lock_irq(&x->wait.lock);
- if (!x->done) {
- DECLARE_WAITQUEUE(wait, current);
-
- wait.flags |= WQ_FLAG_EXCLUSIVE;
- __add_wait_queue_tail(&x->wait, &wait);
- do {
- __set_current_state(TASK_UNINTERRUPTIBLE);
+ if (state == TASK_INTERRUPTIBLE &&
+ signal_pending(current)) {
+ __remove_wait_queue(&x->wait, &wait);
+ return -ERESTARTSYS;
+ }
+ __set_current_state(state);
spin_unlock_irq(&x->wait.lock);
timeout = schedule_timeout(timeout);
spin_lock_irq(&x->wait.lock);
if (!timeout) {
__remove_wait_queue(&x->wait, &wait);
- goto out;
+ return timeout;
}
} while (!x->done);
__remove_wait_queue(&x->wait, &wait);
}
x->done--;
-out:
- spin_unlock_irq(&x->wait.lock);
return timeout;
}
-EXPORT_SYMBOL(wait_for_completion_timeout);
-int fastcall __sched wait_for_completion_interruptible(struct completion *x)
+static long __sched
+wait_for_common(struct completion *x, long timeout, int state)
{
- int ret = 0;
-
might_sleep();
spin_lock_irq(&x->wait.lock);
- if (!x->done) {
- DECLARE_WAITQUEUE(wait, current);
-
- wait.flags |= WQ_FLAG_EXCLUSIVE;
- __add_wait_queue_tail(&x->wait, &wait);
- do {
- if (signal_pending(current)) {
- ret = -ERESTARTSYS;
- __remove_wait_queue(&x->wait, &wait);
- goto out;
- }
- __set_current_state(TASK_INTERRUPTIBLE);
- spin_unlock_irq(&x->wait.lock);
- schedule();
- spin_lock_irq(&x->wait.lock);
- } while (!x->done);
- __remove_wait_queue(&x->wait, &wait);
- }
- x->done--;
-out:
+ timeout = do_wait_for_common(x, timeout, state);
spin_unlock_irq(&x->wait.lock);
+ return timeout;
+}
- return ret;
+void fastcall __sched wait_for_completion(struct completion *x)
+{
+ wait_for_common(x, MAX_SCHEDULE_TIMEOUT, TASK_UNINTERRUPTIBLE);
}
-EXPORT_SYMBOL(wait_for_completion_interruptible);
+EXPORT_SYMBOL(wait_for_completion);
unsigned long fastcall __sched
-wait_for_completion_interruptible_timeout(struct completion *x,
- unsigned long timeout)
+wait_for_completion_timeout(struct completion *x, unsigned long timeout)
{
- might_sleep();
-
- spin_lock_irq(&x->wait.lock);
- if (!x->done) {
- DECLARE_WAITQUEUE(wait, current);
-
- wait.flags |= WQ_FLAG_EXCLUSIVE;
- __add_wait_queue_tail(&x->wait, &wait);
- do {
- if (signal_pending(current)) {
- timeout = -ERESTARTSYS;
- __remove_wait_queue(&x->wait, &wait);
- got
