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
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
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
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
> > > > my se
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 matches the issue y
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 matches the issue you are seeing:
http
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
my server I don't get the vga console, but only get the dummy
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 broken
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
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
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").
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
>
> -
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)"
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) section of
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 accent).
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:
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). There's too much
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
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.
You're
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
> > wh
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 you, or someon
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
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 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 you, or someone,
could explain
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 this file
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.
You're ahead of a surprising number
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
whole lot when you make small changes
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 (which
might be handled by Fedora's
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 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 subseque
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 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?
We could also
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 subsequent mmconfig accesses, which means
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 minu
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 or
more, and that's on a fast dual-core
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 scripted
>
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 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 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 scripted
by fancy GUIs. It should be easy
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
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
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 might
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 might be there so that the legacy
interrupt
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 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
>
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 l
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
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 experience on
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 little experience on PCI and MSI here, we had to try to
As someone else
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
flag from #2
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
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 tell its hardware
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 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 can
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
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 modified. To
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
> > thi
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
this web. The difference between
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
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
>
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.6git branch -l
* bisect
master
origin
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 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
>
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
experienced
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
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 at
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 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 the
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 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 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
>
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/resume
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
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
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 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
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
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 IXP SB400
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 as
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
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
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
something has to be done to fix ATI
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
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 make
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
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,
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, since
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]
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]
More
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
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
1 - 100 of 121 matches
Mail list logo
