headers
Alan Stern | 1 Mar 2007 01:01
Picon
Favicon

Re: debug registers and fork

On Wed, 28 Feb 2007, Roland McGrath wrote:

> It is true that debug registers are inherited by fork and clone.
> I am 99% sure that this was never specifically intended, but it
> has been this way for a long time (since 2.4 at least).  It's an
> implicit consequence of the do_fork implementation style, which
> does a blind copy of the whole task_struct and then explicitly
> reinitializes some individual fields.  I suppose this has some
> benefit or other, but it is very prone to new pieces of state
> getting implicitly copied without the person adding that new state
> ever consciously deciding what its inheritance semantics should be.
> 
> Alan Stern is working on a revamp of the x86 debug register
> support.  This is a fine opportunity to clean this area up and
> decide positively what the semantics ought to be.

Absolutely.  Right now I just have a placeholder function with a note
about checking for CLONE_PTRACE.  The cleanest solution, far and away,
would be to have the child process inherit no breakpoints and no debug
register values.

Alan Stern
Permalink | Reply | 2 comments |
headers
Rob Landley | 1 Mar 2007 01:07

Re: Menuconfig has butterfly effects?

On Tuesday 27 February 2007 6:43 pm, Gregor Jasny wrote:
> Hi,
> 
> 2007/2/28, Rob Landley <rob <at> landley.net>:
> > I ran "make ARCH=x86_64 menuconfig", did a lot of editing, and saved
> > the .config.  Then I copied that to a backup, ran "make oldconfig" on the
> 
> I'd try with "make ARCH=x86_64 oldconfig"

I did.  Sorry for the confusion there.  (If I'd gotten that wrong, there'd 
have been a bit more change. :)

Rob
--

-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery
Permalink | Reply | 0 comments |
headers
Bernhard Walle | 1 Mar 2007 01:11
Picon
Picon

Re: MOST(Media Oriented Systems Transport) Interface?

Hello,

* Jan Kiszka <jan.kiszka <at> web.de> [2007-03-01 00:22]:
> Robin Getz wrote:
> > Does anyone have a pointer for a MOST (Media Oriented Systems Transport) driver?
> > 
> > http://en.wikipedia.org/wiki/Media_Oriented_Systems_Transport
> > 
> > I have seen announcements of Linux systems that support MOST:
> > 
> > http://linuxdevices.com/news/NS2586090082.html
> > 
> > But I have not seen the driver architecture, or the protocol that people are running on them...
> > 
> > Any pointers? 
> 
> The were some rumours earlier, but now I actually stumbled over the
> release - and recalled this thread.

Quite interesting that you found it. It was released yesterday, and I
wanted to write an announcement in a few days, at least at the Xenomai
lists. Anyway ...

> This might be what you are looking for:
> 
> http://most4linux.sourceforge.net/

Yes, that's a MOST driver for a OS 8604 PCI interface that I wrote as
Diploma Thesis at Siemens. It was relased as OpenSource just now.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Johannes Berg | 1 Mar 2007 01:12
Favicon

[PATCH] make sscanf honor %n at end of input string

I was playing with some code that sometimes got a string where a %n
match should have been done where the input string ended, for example
like this:

  sscanf("abc123", "abc%d%n", &a, &n);

However, the scanf function in the kernel doesn't convert the %n in that
case because it has already matched the complete input after %d. This
patch changes that.

Signed-off-by: Johannes Berg <johannes <at> sipsolutions.net>

---
Shrug. My use case for this collapsed, but I figured having scanf doing
that correctly might be a good thing.

 lib/vsprintf.c |    9 +++++++++
 1 file changed, 9 insertions(+)

--- wireless-dev.orig/lib/vsprintf.c	2007-03-01 00:28:31.776381760 +0100
+++ wireless-dev/lib/vsprintf.c	2007-03-01 00:59:33.256381760 +0100
 <at>  <at>  -825,6 +825,15  <at>  <at>  int vsscanf(const char * buf, const char
 			break;
 		str = next;
 	}
+
+	/* Now we've come all the way through so either the input string or
+	 * the format ended. In the former case, there can be a %n at the
+	 * current position in the format that needs to be filled. */
+	if (*fmt == '%' && *(fmt+1) == 'n') {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rob Landley | 1 Mar 2007 01:15

Re: Menuconfig has butterfly effects?

On Tuesday 27 February 2007 6:36 pm, Randy Dunlap wrote:
> > The first hunk I expect, the second I did not.  Anybody care to venture a 
> > guess why the visibility logic is unstable?
> 
> can we get .config^Wtryit ?  (version 0, not version 1)

Unfortunately, the first .config was generated by me tooling around in 
menuconfig, and then overwritten by a later build.  And now I can't reproduce 
the problem. :(

Rob
--

-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery
Permalink | Reply | 0 comments |
headers
David Miller | 1 Mar 2007 01:20
Favicon

[PATCH]: Fix radeon blanking return value.


If you'll recall, over a year ago, I pointed out that the current
Radeon driver erroneously returns -EINVAL for valid blanking codes,
here is a link to that thread:

	http://lkml.org/lkml/2006/1/28/6

No other driver does this, and it confuses the X server into thinking
that the device does not support blanking properly.

As a result I have to switch to a console VC and back to the X server
to unblank the screen, which is rediculious.

I've had to do this for more than 3 years and I'm really tired of this
problem still being around :-)

I looked again and there is simply no reason for the Radeon driver to
return -EINVAL for FB_BLANK_NORMAL.  It claims it wants to do this in
order to convince fbcon to blank in software, right here:

			if (fb_blank(info, blank))
				fbcon_generic_blank(vc, info, blank);

to software blank the screen.  But it only causes that to happen
in the FB_BLANK_NORMAL case.

That makes no sense because the Radeon code does this:

		val |= CRTC_DISPLAY_DIS;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nish Aravamudan | 1 Mar 2007 01:20
Picon

Re: SMP performance degradation with sysbench

On 2/27/07, Nish Aravamudan <nish.aravamudan <at> gmail.com> wrote:
> On 2/27/07, Bill Davidsen <davidsen <at> tmr.com> wrote:
> > Paulo Marques wrote:
> > > Rik van Riel wrote:
> > >> J.A. Magallón wrote:
> > >>> [...]
> > >>> Its the same to answer 4+4 queries than 8 at half the speed, isn't it ?
> > >>
> > >> That still doesn't fix the potential Linux problem that this
> > >> benchmark identified.
> > >>
> > >> To clarify: I don't care as much about MySQL performance as
> > >> I care about identifying and fixing this potential bug in
> > >> Linux.
> > >
> > > IIRC a long time ago there was a change in the scheduler to prevent a
> > > low prio task running on a sibling of a hyperthreaded processor to slow
> > > down a higher prio task on another sibling of the same processor.
> > >
> > > Basically the scheduler would put the low prio task to sleep during an
> > > adequate task slice to allow the other sibling to run at full speed for
> > > a while.
<snip>
> > > If that is the case, turning off CONFIG_SCHED_SMT would solve the problem.
<snip>
> > Note that Intel does make multicore HT processors, and hopefully when
> > this code works as intended it will result in more total throughput. My
> > supposition is that it currently is NOT working as intended, since
> > disabling SMT scheduling is reported to help.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Hancock | 1 Mar 2007 01:21
Picon
Favicon

Re: 2.6.20 SATA error

Gerhard Mack wrote:
>>> Sorry for the false alarm, 
>> There is one thing that seems odd, if you do have an nForce4 chipset, the
>> kernel should be running the SATA controller in ADMA mode in 2.6.20, but it
>> doesn't seem like it is from your dmesg output. Can you post the output of
>> "lspci -vvn"? Also what kind of motherboard is that?
>>
> Sure thing.  It's an Asus m2npv-vm.

Ah, that would be why, it's not one of the original nForce4 
(CK804/MCP04) chipsets, it's the newer nForce 430 (MCP51) chipset which 
doesn't support ADMA. NVidia said they'd be sending some patches to 
allow NCQ support on MCP51 and MCP61 chipsets back in October, but I 
haven't seen any, or information required to implement same..

--

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr <at> nospamshaw.ca
Home Page: http://www.roberthancock.com/
Permalink | Reply | 1 comment |
headers
Stephane Eranian | 1 Mar 2007 01:27
Picon
Favicon

Re: debug registers and fork

Alan,

On Wed, Feb 28, 2007 at 07:01:17PM -0500, Alan Stern wrote:
> On Wed, 28 Feb 2007, Roland McGrath wrote:
> 
> > It is true that debug registers are inherited by fork and clone.
> > I am 99% sure that this was never specifically intended, but it
> > has been this way for a long time (since 2.4 at least).  It's an
> > implicit consequence of the do_fork implementation style, which
> > does a blind copy of the whole task_struct and then explicitly
> > reinitializes some individual fields.  I suppose this has some
> > benefit or other, but it is very prone to new pieces of state
> > getting implicitly copied without the person adding that new state
> > ever consciously deciding what its inheritance semantics should be.
> > 
> > Alan Stern is working on a revamp of the x86 debug register
> > support.  This is a fine opportunity to clean this area up and
> > decide positively what the semantics ought to be.
> 
> Absolutely.  Right now I just have a placeholder function with a note
> about checking for CLONE_PTRACE.  The cleanest solution, far and away,
> would be to have the child process inherit no breakpoints and no debug
> register values.
> 
I agree and that is how we have it on IA-64. With debugging, there is
always another process involved and no matter what I think it needs to 
be aware of the new child. I don't think autoamtic inheritance is good.
It should always be trigger by the controlling process (e.g., debugger).
There is enough support in ptrace to catch the fork/vfork/pthread_create
and decide what to do.  This is how I have coded perfmon so that hardware
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jean Tourrilhes | 1 Mar 2007 01:26
Picon
Favicon

Re: [PATCH 2.6.20] kobject net ifindex + rename

On Wed, Feb 28, 2007 at 07:36:17AM -0800, Greg KH wrote:
> On Tue, Feb 27, 2007 at 05:27:41PM -0800, Jean Tourrilhes wrote:
> > diff -u -p linux/drivers/base/class.j1.c linux/drivers/base/class.c
> > --- linux/drivers/base/class.j1.c	2007-02-26 18:38:10.000000000 -0800
> > +++ linux/drivers/base/class.c	2007-02-27 15:52:37.000000000 -0800
> >  <at>  <at>  -841,6 +841,8  <at>  <at>  int class_device_rename(struct class_dev
> 
> This function is not in the 2.6.21-rc2 kernel, so you might want to
> rework this patch a bit :)

	Thanks for all you good comments. I ported my patch to
2.6.21-rc2, and tested it both on a hotplug and a udev system. Patch
is attached, I would be glad if you could push that through the usual
channels.

	Also, I realised that I forgot to say in my original e-mail
that migrating udev to use ifindex instead of ifname would fix the
remove/add race condition for network devices. But that's not going to
happen overnight...

	Have fun...

	Jean

Signed-off-by: Jean Tourrilhes <jt <at> hpl.hp.com>

---------------------------------------------------------

diff -u -p linux/include/linux/kobject.j1.h linux/include/linux/kobject.h
--- linux/include/linux/kobject.j1.h	2007-02-28 14:26:29.000000000 -0800
(Continue reading)

Permalink | Reply | 6 comments |

Gmane