On Thu, 7 Dec 2006, Greg KH wrote:
Care to take Jeff's proposed patch, verify that it works and forward it
on to me?
I'll test it tomorrow. Testing disables my network, and making sure the
problem exists without the patch kills my disk controller, so I need to
sit at the computer for a
>From 27fc7625159acb1fd77d4a36a326be521ee79b19 Mon Sep 17 00:00:00 2001
From: Daniel Barkalow <[EMAIL PROTECTED]>
Date: Fri, 1 Dec 2006 14:56:58 -0500
Subject: [PATCH] Disable INTx when enabling MSI in forcedeth
At least some nforce cards continue to send legacy interrupts when MSI
i
From 27fc7625159acb1fd77d4a36a326be521ee79b19 Mon Sep 17 00:00:00 2001
From: Daniel Barkalow [EMAIL PROTECTED]
Date: Fri, 1 Dec 2006 14:56:58 -0500
Subject: [PATCH] Disable INTx when enabling MSI in forcedeth
At least some nforce cards continue to send legacy interrupts when MSI
is enabled
On Wed, 13 Apr 2005, Petr Baudis wrote:
> Dear diary, on Wed, Apr 13, 2005 at 07:01:34PM CEST, I got a letter
> where Daniel Barkalow <[EMAIL PROTECTED]> told me that...
> > For future reference, git is unhappy if you actually do this, because your
> > HEAD won't ma
On Wed, 13 Apr 2005, Petr Baudis wrote:
> Dear diary, on Wed, Apr 13, 2005 at 11:25:04AM CEST, I got a letter
> where David Woodhouse <[EMAIL PROTECTED]> told me that...
> > On Wed, 2005-04-13 at 10:59 +0200, Petr Baudis wrote:
> > > Theoretically, you are never supposed to share your index if
On Wed, 13 Apr 2005, Petr Baudis wrote:
Dear diary, on Wed, Apr 13, 2005 at 11:25:04AM CEST, I got a letter
where David Woodhouse [EMAIL PROTECTED] told me that...
On Wed, 2005-04-13 at 10:59 +0200, Petr Baudis wrote:
Theoretically, you are never supposed to share your index if you work
On Wed, 13 Apr 2005, Petr Baudis wrote:
Dear diary, on Wed, Apr 13, 2005 at 07:01:34PM CEST, I got a letter
where Daniel Barkalow [EMAIL PROTECTED] told me that...
For future reference, git is unhappy if you actually do this, because your
HEAD won't match the (empty) contents of the new
On Tue, 12 Apr 2005, Adam J. Richter wrote:
> On 2005-04-11, Daniel Barkalow wrote:
> >If merge took trees instead of single files, and had some way of detecting
> >renames (or it got additional information about the differences between
> >files), would that give BK-quality
On Tue, 12 Apr 2005, Adam J. Richter wrote:
On 2005-04-11, Daniel Barkalow wrote:
If merge took trees instead of single files, and had some way of detecting
renames (or it got additional information about the differences between
files), would that give BK-quality performance? Or does BK also
On Sun, 10 Apr 2005, Linus Torvalds wrote:
> On Mon, 11 Apr 2005, Jeff Garzik wrote:
> >
> > > But I hope that I can get non-conflicting merges done fairly soon, and
> > > maybe I can con James or Jeff or somebody to try out GIT then...
> >
> > I don't mind being a guinea pig as long as
On Sun, 10 Apr 2005, Linus Torvalds wrote:
On Mon, 11 Apr 2005, Jeff Garzik wrote:
But I hope that I can get non-conflicting merges done fairly soon, and
maybe I can con James or Jeff or somebody to try out GIT then...
I don't mind being a guinea pig as long as someone else does
On Mon, 11 Apr 2005, Petr Baudis wrote:
> Hello,
>
> here goes git-pasky-0.2, my set of patches and scripts upon
> Linus' git, aimed at human usability and to an extent a SCM-like usage.
Incidentally, the git-pasky-base tarball you have up has its checked-out
tree partway between 0.1 and
On Mon, 11 Apr 2005, Petr Baudis wrote:
Hello,
here goes git-pasky-0.2, my set of patches and scripts upon
Linus' git, aimed at human usability and to an extent a SCM-like usage.
Incidentally, the git-pasky-base tarball you have up has its checked-out
tree partway between 0.1 and 0.2,
An significant typo in the driver for the Frobnozzle got omitted. This
patch causes parts of some writes to be silently lost, and is probably
responsible for http://bugzilla.kernel.org/show_bug.cgi?id=5362.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
--- linux-2.6.11/drivers/usb/
An significant typo in the driver for the Frobnozzle got omitted. This
patch causes parts of some writes to be silently lost, and is probably
responsible for http://bugzilla.kernel.org/show_bug.cgi?id=5362.
Signed-off-by: Daniel Barkalow [EMAIL PROTECTED]
--- linux-2.6.11/drivers/usb/gadget
On Mon, 28 Mar 2005, L. A. Walsh wrote:
> However, in this case, if the author is _certain_ the
> pointer can never be NULL, than an "ASSERT(card!=NULL);" might
> be appropriate, where ASSERT is a macro that normally compiles
> in the check, but could compile to "nothing" for embedded or
>
On Mon, 28 Mar 2005, L. A. Walsh wrote:
However, in this case, if the author is _certain_ the
pointer can never be NULL, than an ASSERT(card!=NULL); might
be appropriate, where ASSERT is a macro that normally compiles
in the check, but could compile to nothing for embedded or
kernels
On Fri, 4 Mar 2005, Vojtech Pavlik wrote:
> /* Relative movement packet */
> if (z == 127) {
> - input_report_rel(dev2, REL_X, (x > 383 ? x : (x -
> 768)));
> - input_report_rel(dev2, REL_Y, -(y > 255 ? y : (x -
> 512)));
> +
On Fri, 4 Mar 2005, Vojtech Pavlik wrote:
/* Relative movement packet */
if (z == 127) {
- input_report_rel(dev2, REL_X, (x 383 ? x : (x -
768)));
- input_report_rel(dev2, REL_Y, -(y 255 ? y : (x -
512)));
+
On Thu, 3 Mar 2005, Linus Torvalds wrote:
> - some very _technical_ and objective rules on patches. And they should
>limit the patches severely, so that people can never blame the sucker
>who does the job. For example, I would suggest that "size" be one hard
>technical rule. If
On Thu, 3 Mar 2005, Linus Torvalds wrote:
- some very _technical_ and objective rules on patches. And they should
limit the patches severely, so that people can never blame the sucker
who does the job. For example, I would suggest that size be one hard
technical rule. If the
101 - 121 of 121 matches
Mail list logo
