On Fri, 22 Feb 2008, Chase Venters wrote:
> I've been making myself more familiar with git lately and I'm curious what
> habits others have adopted. (I know there are a few documents in circulation
> that deal with using git to work on the kernel but I don't think this has
> been specifically c
As far as I can tell, the only differences in either dmesg or lspci
between the broken one and the working one are the phrasing of messages,
not what's happening.
Out of curiousity, what do you see for the "Console: " line when you boot?
It's possible that the VGA console code somehow got broke
On Sun, 17 Feb 2008, Frans Pop wrote:
> On Sunday 17 February 2008, Daniel Barkalow wrote:
> > On Sun, 17 Feb 2008, Frans Pop wrote:
> > > Daniel Barkalow wrote:
> > > > For some reason I can't see and don't know how to debug, in 2.6.23 on
> > >
On Sun, 17 Feb 2008, Frans Pop wrote:
> Daniel Barkalow wrote:
> > For some reason I can't see and don't know how to debug, in 2.6.23 on my
> > server I don't get the vga console, but only get the dummy console.
>
> Please check if this bug report matc
For some reason I can't see and don't know how to debug, in 2.6.23 on my
server I don't get the vga console, but only get the dummy console.
I also noticed that the documentation is wrong and the Kconfig file is
confused; it's impossible to not have DUMMY_CONSOLE set, because at least
one of PR
On Tue, 29 Jan 2008, Alan Cox wrote:
> > The SCSI error reporting really ought to include a simple interpretation
> > of the error for end users ("The drive doesn't support this command" "A
> > sector's data got lost" "The drive timed out" "The drive failed" "The
> > drive is entirely gone"). T
On Tue, 29 Jan 2008, Alan Cox wrote:
> > not one problem but lots---is sufficiently widespread that a Mini HOWTO,
> > say, would be really welcome and, I'm guessing, widely used.
>
> We don't see very many libata problems at the distro level and they for
> the most part boil down to
>
> - error
On Tue, 29 Jan 2008, Alan Cox wrote:
> > things in the kernel that refer to SCSI probably should say "storage" (or
> > "ATA", really, but that would make the acronyms confusing).
>
> SCSI is a command protocol. It is what your CD-ROM drive and USB storage
> devices talk (albeit with a bit of an
On Tue, 29 Jan 2008, Gene Heskett wrote:
> >For starters, enable CONFIG_BLK_DEV_SR.
>
> That could stand to be moved or renamed, it is well buried in the menu for
> the
> REAL scsi stuffs, which I don't have any of. Enabled & building now.
The "SCSI support type (disk, tape, CD-ROM)" sectio
On Mon, 28 Jan 2008, Gene Heskett wrote:
> On Monday 28 January 2008, Daniel Barkalow wrote:
> >On Mon, 28 Jan 2008, Gene Heskett wrote:
> >> On Monday 28 January 2008, Daniel Barkalow wrote:
> >> >Building this and installing it along with the appropriate initrd (w
On Mon, 28 Jan 2008, Gene Heskett wrote:
> On Monday 28 January 2008, Daniel Barkalow wrote:
> >Building this and installing it along with the appropriate initrd (which
> >might be handled by Fedora's install scripts)
>
> Or mine, which I've been using for years
On Mon, 28 Jan 2008, Mike Frysinger wrote:
> On Jan 28, 2008 7:08 PM, Daniel Barkalow <[EMAIL PROTECTED]> wrote:
> > Could you submit the XML files and the autogeneration code? The C file
> > isn't really source. Not only is it big, it'll probably change around a
&g
On Mon, 28 Jan 2008, Mike Frysinger wrote:
> On Jan 28, 2008 8:04 AM, richard kennedy <[EMAIL PROTECTED]> wrote:
> > Mike Frysinger wrote:
> > > On Jan 28, 2008 5:40 AM, Bryan Wu <[EMAIL PROTECTED]> wrote:
> > >> On Mon, 2008-01-28 at 05:16 -0500, Mike Frysinger wrote:
> > >>> the trouble is that
On Mon, 28 Jan 2008, Richard Heck wrote:
> Daniel Barkalow wrote:
> > Can you switch back to old IDE to get your work done (and to make sure it's
> > not a hardware issue that's developed recently)?
> I think it'd be really, REALLY helpful to a lot of people if
On Mon, 28 Jan 2008, Gene Heskett wrote:
> I believe at this point, its moot. I captured quite a few instances of that
> error message while rebooting the last time, all of which occurred long
> before I logged in and did a startx (I boot to runlevel 3 here), so the
> kernel was NOT tainted at
On Sun, 20 Jan 2008, Matt Mackall wrote:
> Your usage of "overall power" here is wrong. Power is an instantaneous
> quantity (1/s) like velocity, and you are comparing it to energy which
> is not an instaneous quantity, more like distance.
>
> If we throttle the velocity of a car from 100km/h to
On Thu, 27 Dec 2007, Linus Torvalds wrote:
> On Thu, 27 Dec 2007, Daniel Barkalow wrote:
> >
> > I'd actually bet that the hardware bug is actually that any device that
> > gives a CRS response the first time will have its Vendor ID appear as 0001
> > on sub
On Thu, 27 Dec 2007, Kai Ruhnau wrote:
> Linus Torvalds wrote:
> > On Thu, 27 Dec 2007, Linus Torvalds wrote:
> >
> >> Kai, can you try that? Just remove the call to pci_enable_crs() in
> >> pci_scan_bridge() in drivers/pci/probe.c, and see if mmconfig starts
> >> working for you?
> >>
>
On Fri, 16 Nov 2007, Romano Giannetti wrote:
>
> (Cc: trimmed a bit).
>
> On Thu, 2007-11-15 at 11:19 -0500, Daniel Barkalow wrote:
> > On Thu, 15 Nov 2007, Theodore Tso wrote:
> [...]
> > > A full kernel build with everything selected can take good 30 minutes o
On Thu, 15 Nov 2007, Theodore Tso wrote:
> On Wed, Nov 14, 2007 at 06:23:34PM -0500, Daniel Barkalow wrote:
> > I don't see any reason that we couldn't have a tool accessible to Ubuntu
> > users that does a real "git bisect". Git is really good at being script
On Thu, 15 Nov 2007, Michael Gerdau wrote:
> > This code is far to be perfect, some part is outdated, bcopy() use instead
> > of memcpy() for example. More annoying are the comment, the file is 3306
> > lines while there is only 1640 line of code, nothing bad per se but looking
> > some comments:
On Tue, 13 Nov 2007, Theodore Tso wrote:
> There are two parts to this. One is a Ubuntu development kernel which
> we can give to large numbers of people to expand our testing pool.
> But if we don't do a better job of responding to bug reports that
> would be generated by expanded testing this w
On Tue, 23 Oct 2007, David Miller wrote:
> From: Daniel Barkalow <[EMAIL PROTECTED]>
> Date: Wed, 24 Oct 2007 00:58:45 -0400 (EDT)
>
> > I'm not sure all of the pci_intx() calls in msi.c should be skipped when
> > the quirk applies; I think some of them m
On Tue, 23 Oct 2007, David Miller wrote:
>
> The forthcoming patches are also available from:
>
> kernel.org:/pub/scm/linux/kernel/git/davem/msiquirk-2.6.git
>
> and clean up the handling of the common quirk wherein setting
> INTX_DISABLE will mistakedly disable MSI generation for some
>
On Mon, 22 Oct 2007, David Miller wrote:
> My suggestion is:
>
> 1) Leave the pci_intx() twiddling code in drivers/pci/msi.c
>
> 2) Add quirks for "INTX_DISABLE turns off MSI too", this sets
>a flag in the pci_dev.
>
> 3) The pci_intx() calls in drivers/pci/msi.c are skipped if this
>fl
On Mon, 22 Oct 2007, Jeff Garzik wrote:
> Daniel Barkalow wrote:
> > On Fri, 19 Oct 2007, Jeff Garzik wrote:
> >
> > > Linas Vepstas wrote:
> > > > On Fri, Oct 19, 2007 at 09:17:23PM +0800, Shane Huang wrote:
> > > > > Since we have litt
On Fri, 19 Oct 2007, Jeff Garzik wrote:
> Linas Vepstas wrote:
> > On Fri, Oct 19, 2007 at 09:17:23PM +0800, Shane Huang wrote:
> > > Since we have little experience on PCI and MSI here, we had to try to
> >
> > As someone else pointed out, AMD should have *lots* of people with
> > pci and msi ex
On Thu, 18 Oct 2007, David Miller wrote:
> From: "Shane Huang" <[EMAIL PROTECTED]>
> Date: Thu, 18 Oct 2007 18:37:59 +0800
>
> > Hi Miller:
> >
> > Thank you for your response.
> >
> > The reason why MSIs of these northbridges do not work is still under
> > further debug, we are NOT able to tel
On Wed, 27 Jun 2007, hermann pitton wrote:
> Hi,
>
> such stuff causes a lot of troubles since long.
>
> Are there any rules, or can everybody go on as some sort of freelancer
> exclusively on such? I don't like it!
http://www.linux-foundation.org/en/NDA_program
In short, the Linux Foundation
On Mon, 18 Jun 2007, Linus Torvalds wrote:
> On Mon, 18 Jun 2007, Carlo Wood wrote:
>
> > diff --git a/scripts/package/Makefile b/scripts/package/Makefile
> > index 7c434e0..f758b75 100644
> > --- a/scripts/package/Makefile
> > +++ b/scripts/package/Makefile
>
> but this one has actually been mod
On Sat, 16 Jun 2007, Carlo Wood wrote:
> On Sat, Jun 16, 2007 at 01:28:13AM -0400, Daniel Barkalow wrote:
> > That's not actually the right image. There's a graph of commits with a lot
> > of splitting and joining lines. Each branch and each tag sits something in
>
On Sat, 16 Jun 2007, Carlo Wood wrote:
> I don't understand - any branch that I am on has many tags. I can use
> 'git reset --hard sometag' to change the source tree to that tag (which
> works if I look at the version in the Makefile and pick tags that are
> far apart enough).
That's not actually
On Sat, 16 Jun 2007, Carlo Wood wrote:
> Therefore I have the following questions:
>
> 1) What git command will ASSURE that I get the LATEST
>kernel tree checked out?
>
> I tried this:
>
> hikaru:/usr/src/kernel/git/linux-2.6>git branch -l
> * bisect
> master
> origin
> hikaru:/usr/src/k
On Thu, 26 Apr 2007, Adrian Bunk wrote:
> Linus said 2.6.20 was a stable kernel. My impression was that at least
> two of the regressions from my 2.6.20 regressions list should have been
> fixed before 2.6.20.
>
> They have both been fixed through -stable, but I also remember a quite
> experie
On Thu, 26 Apr 2007, Adrian Bunk wrote:
> Number of different known regressions compared to 2.6.20 at the time
> of the 2.6.21 release:
> 14
I count 13. (v2) had 15 items, of which 2 were subsequently fixed or found
to be inapplicable.
> Number of different known regressions compared to 2.6.20
On Fri, 16 Feb 2007, Heikki Orsila wrote:
> I just read
>
> http://kerneltrap.org/node/7729
>
> and it occured to me that it would be informative to have a new device
> driver macro. The motivation for the new macro would be 4 issues:
>
> * Is it possible to get specifications for
On Tue, 13 Feb 2007, Chuck Ebbert wrote:
> drivers/usb/net/usbnet.c:
>
> int
> usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
> {
> struct usbnet *dev;
> struct net_device *net;
> struct usb_host_interface
On Sun, 11 Feb 2007, Rafael J. Wysocki wrote:
> The problem is it was made implicit long ago. The design is "optimistic", so
> to speak, and I think we have the following choices:
>
> 1) Change the design to make the kernel refuse to suspend if there are any
> drivers not explicitly flagged as "
On Sat, 10 Feb 2007, Rafael J. Wysocki wrote:
> On Saturday, 10 February 2007 11:02, Nigel Cunningham wrote:
>
> > Well, the original desire was to stop new drivers getting in without
> > proper power management.
>
> I know, but I agree with the argument that having a driver without the
> suspend
On Sun, 4 Feb 2007, Robert Hancock wrote:
> Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to
> 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get
> received and so the machine can't get an IP address. I tried reverting all the
> -mm changes to drivers/ne
On Tue, 23 Jan 2007, Jesper Juhl wrote:
> Now that 2.6.19 is out, most likely not. -stable releases are made
> for the latest stable 2.6.x kernel, once 2.6.x+1 is out that's the one
> -stable patches are made for (2.6.16 is an exception)..
There's generally a bit of overlap. 2.6.17.14 was about
On Fri, 5 Jan 2007, Petr Vandrovec wrote:
> Hi,
> unfortunately it is not everything :-(
>
> I cannot get MSI to work on IDE interface under any circumstances - in legacy
> mode it always uses IRQ14/15 regardless of whether MSI is enabled or not
> (that's probably correct), but in native mode a
On Thu, 4 Jan 2007, Roland Dreier wrote:
> > So my question is - what is real reason for disabling INTX when in MSI
> mode?
> > According to PCI spec it should not be needed, and it hurts at least chips
> > listed below:
> >
> > 00:13.0 0c03: 1002:4374 USB Controller: ATI Technologies Inc I
On Fri, 29 Dec 2006, Adrian Bunk wrote:
> On Fri, Dec 29, 2006 at 01:14:13PM -0500, Daniel Barkalow wrote:
>
> > There's also http://lkml.org/lkml/2006/12/21/47; the included patch break
> > my nVidia devices and probably all PCIX devices, so it's not right, but
>
There's also http://lkml.org/lkml/2006/12/21/47; the included patch break
my nVidia devices and probably all PCIX devices, so it's not right, but
something has to be done to fix ATI. My guess is a quirk to say that
pci_intx doesn't work on certain devices and should just be skipped, but
I'm not
On Thu, 21 Dec 2006, Petr Vandrovec wrote:
> So my question is - what is real reason for disabling INTX when in MSI mode?
> According to PCI spec it should not be needed.
The PCI spec is at least not clear enough on the matter to keep nVidia
from thinking that it's the OS's responsibility to mak
On Tue, 19 Dec 2006, John M Flinchbaugh wrote:
> I saw a mention of interrupt handling for forcedeth cards is the
> 2.6.19.1 changelog, but I still see this error in 2.6.19.1. It started
> in 2.6.19, and it didn't happen in 2.6.18.1.
Nope; the issue fixed in 2.6.19.1 has always existed (provided
On Mon, 18 Dec 2006, Linus Torvalds wrote:
> Static vs dynamic matters for whether it's an AGGREGATE work. Clearly,
> static linking aggregates the library with the other program in the same
> binary. There's no question about that. And that _does_ have meaning from
> a copyright law angle, sin
On Thu, 7 Dec 2006, Jeff Garzik wrote:
> "it boots" on ICH7 at least.
It solves my problem (and doesn't break anything).
-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mo
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 whil
Some device manufacturers seem to think it's the OS's responsibility to
disable legacy interrupt delivery when using MSI. If the driver doesn't
handle it (which they generally don't), and the device isn't PCI-Express,
a steady stream of legacy interrupts will be delivered in addition to the
MSI
>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
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 matc
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
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 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
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/
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
> ker
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 the
61 matches
Mail list logo
