On Tuesday, May 01, 2007, Jesse Barnes wrote:
On Monday, April 30, 2007, Olivier Galibert wrote:
On Sun, Apr 29, 2007 at 08:14:37PM -0600, Robert Hancock wrote:
-Validate that the area is reserved even if we read it from the
chipset directly and not from the MCFG table. This catches
On Tuesday, May 01, 2007, Jesse Barnes wrote:
I'm testing it now on my 965...
Bah... nevermind Robert, I see you're doing this already in
pci_mmcfg_reject_broken. I'm about to reboot test now.
Ok, I've tested a bit on my 965 (after re-adding my old patch to support
it) and the new checks
On Sunday, April 29, 2007 7:10 pm Robert Hancock wrote:
> Jesse Barnes wrote:
> > Add support for Intel 915 bridge chips to the new PCI MMConfig
> > detection code. Tested and works on my sole 915 based platform (a
> > Toshiba laptop). I added register masking pe
On Sunday, April 29, 2007 7:10 pm Robert Hancock wrote:
Jesse Barnes wrote:
Add support for Intel 915 bridge chips to the new PCI MMConfig
detection code. Tested and works on my sole 915 based platform (a
Toshiba laptop). I added register masking per Oliver's suggestion,
and moved
e completely unsuitable like on top of RAM or other
> registers. It seems that with some of those 965 chipsets the latter is
> what the BIOS is actually doing, and so when we think we're writing to
> the table we're really writing to random chipset registers and hosing
> things. (Jesse Ba
unsuitable like on top of RAM or other
registers. It seems that with some of those 965 chipsets the latter is
what the BIOS is actually doing, and so when we think we're writing to
the table we're really writing to random chipset registers and hosing
things. (Jesse Barnes ran into this while trying
patches.
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
diff --git a/arch/i386/pci/mmconfig-shared.c b/arch/i386/pci/mmconfig-shared.c
index 747d8c6..1339d31 100644
--- a/arch/i386/pci/mmconfig-shared.c
+++ b/arch/i386/pci/mmconfig-shared.c
@@ -72,6 +72,26 @@ static const char
patches.
Signed-off-by: Jesse Barnes [EMAIL PROTECTED]
diff --git a/arch/i386/pci/mmconfig-shared.c b/arch/i386/pci/mmconfig-shared.c
index 747d8c6..1339d31 100644
--- a/arch/i386/pci/mmconfig-shared.c
+++ b/arch/i386/pci/mmconfig-shared.c
@@ -72,6 +72,26 @@ static const char __init
Keep reading...
On Wednesday, April 25, 2007 4:07 pm Andrew Morton wrote:
> On Wed, 25 Apr 2007 15:35:15 -0700 Jesse Barnes
<[EMAIL PROTECTED]> wrote:
> > I see the other mmconfig stuff is upstream now, can we get this
> > added too? The Asus bug Olivier mentioned also ap
I see the other mmconfig stuff is upstream now, can we get this added
too? The Asus bug Olivier mentioned also appears to be fixed, so this
patch should be safe.
Thanks,
Jesse
On Wednesday, January 10, 2007 6:53 pm Jesse Barnes wrote:
> This is a resend of the patch I sent earlier to Oli
I see the other mmconfig stuff is upstream now, can we get this added
too? The Asus bug Olivier mentioned also appears to be fixed, so this
patch should be safe.
Thanks,
Jesse
On Wednesday, January 10, 2007 6:53 pm Jesse Barnes wrote:
This is a resend of the patch I sent earlier to Oliver
Keep reading...
On Wednesday, April 25, 2007 4:07 pm Andrew Morton wrote:
On Wed, 25 Apr 2007 15:35:15 -0700 Jesse Barnes
[EMAIL PROTECTED] wrote:
I see the other mmconfig stuff is upstream now, can we get this
added too? The Asus bug Olivier mentioned also appears to be
fixed, so
On Friday, April 20, 2007 11:28 am Linus Torvalds wrote:
> On Fri, 20 Apr 2007, Jesse Barnes wrote:
> > Sounds good, hopefully reassigning the bridge resources won't cause
> > too much trouble. Do you have time to hack this up? If not, I
> > could give it a try, as lo
ent
> requirements into account. Then, if some window is too small, we just
> let the pci_assign_unassigned_resources to take care of that.
Sounds good, hopefully reassigning the bridge resources won't cause too
much trouble. Do you have time to hack this up? If not, I could give
it a try, as long as ajax is willing to t
of that.
Sounds good, hopefully reassigning the bridge resources won't cause too
much trouble. Do you have time to hack this up? If not, I could give
it a try, as long as ajax is willing to test...
Thanks,
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Friday, April 20, 2007 11:28 am Linus Torvalds wrote:
On Fri, 20 Apr 2007, Jesse Barnes wrote:
Sounds good, hopefully reassigning the bridge resources won't cause
too much trouble. Do you have time to hack this up? If not, I
could give it a try, as long as ajax is willing to test
ow: a100-a2ff (32M)
PREFETCH window: disabled.
PCI: Bridge: :00:1e.0
IO window: 1000-1fff
MEM window: a100-a30f (~32M)
PREFETCH window: a000-a0ff
...
And these bridges got more space somehow... Greg who's in charge of our
bridge resource allocation code?
Jesse
-
please copy netdev, or better yet [EMAIL PROTECTED] in
the future for e1000 issues like this. Feel free to move the
conversation there, if you would like.
On 4/19/07, David Ford <[EMAIL PROTECTED]> wrote:
I have a rackmount server that has a dual port onboard 82546EB card.
I've googled and
please copy netdev, or better yet [EMAIL PROTECTED] in
the future for e1000 issues like this. Feel free to move the
conversation there, if you would like.
On 4/19/07, David Ford [EMAIL PROTECTED] wrote:
I have a rackmount server that has a dual port onboard 82546EB card.
I've googled and seen
: Bridge: :00:1e.0
IO window: 1000-1fff
MEM window: a100-a30f (~32M)
PREFETCH window: a000-a0ff
...
And these bridges got more space somehow... Greg who's in charge of our
bridge resource allocation code?
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux
t are misnumbered and one is missing.
what does 'ip link' or 'ifconfig -a' show?
Jesse
-
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/
Roberto Nibali wrote:
>>> Sounds sane to me. My overall opinion on eepro100 removal is that
>>> we're not there yet. Rare problem cases remain where e100 fails
>>> but eepro100 works, and it's older drivers so its low priority for
>>> everybody.
>>>
>>> Needs to happen, though...
>>
>> It
Roberto Nibali wrote:
Sounds sane to me. My overall opinion on eepro100 removal is that
we're not there yet. Rare problem cases remain where e100 fails
but eepro100 works, and it's older drivers so its low priority for
everybody.
Needs to happen, though...
It seems that several Tyan
'ip link' or 'ifconfig -a' show?
Jesse
-
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/
ard one
complaint about this bug so far, and that was caused by some code still
in development.
Jesse
-
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.h
, and that was caused by some code still
in development.
Jesse
-
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/
On 3/26/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
hm, on a T60, after suspend/resume, i get an e1000 timeout:
e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Tx Queue <0>
TDH
On 3/26/07, Ingo Molnar [EMAIL PROTECTED] wrote:
hm, on a T60, after suspend/resume, i get an e1000 timeout:
e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Tx Queue 0
TDH
be created due to a shadow resource, which is also
moved to a little later in the boot cycle so it will occur after the
video fixup. Tested and works on my i386 test box.
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
diff -Napur -X /home/jbarnes/dontdiff linux-2.6.21-rc4/arch/i386/pci/f
be created due to a shadow resource, which is also
moved to a little later in the boot cycle so it will occur after the
video fixup. Tested and works on my i386 test box.
Signed-off-by: Jesse Barnes [EMAIL PROTECTED]
diff -Napur -X /home/jbarnes/dontdiff linux-2.6.21-rc4/arch/i386/pci/fixup.c
linux
On Monday, March 19, 2007 1:05 pm David Miller wrote:
> From: Jesse Barnes <[EMAIL PROTECTED]>
> Date: Mon, 19 Mar 2007 12:54:36 -0700
>
> > Kernel based modesetting should get us a lot of things:
>
> But for panics you're ignoring what Peter and I are saying.
suspend/resume support
o some more independence from X for complex gfx setups
o a good mode at early boot time
and several others I'm leaving out at the moment. On the downside, the
modesetting layer will be a chunk of new code, and require enhanced
chip specific mode setting code
at the moment. On the downside, the
modesetting layer will be a chunk of new code, and require enhanced
chip specific mode setting code to be added to the drm/fb drivers.
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
On Monday, March 19, 2007 1:05 pm David Miller wrote:
From: Jesse Barnes [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 12:54:36 -0700
Kernel based modesetting should get us a lot of things:
But for panics you're ignoring what Peter and I are saying.
Mode setting is complex and it is not going
needs it, and of course there are i386 and
x86_64 machines that need it to, so it makes sense that it be generic.
Jesse
-
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/major
and
x86_64 machines that need it to, so it makes sense that it be generic.
Jesse
-
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
remember arguing with davem about
this stuff in the past...
Jesse
-
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/
arguing with davem about
this stuff in the past...
Jesse
-
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/
ROTECTED]>
Yay! I'm glad we can finally get rid of this in favor of the new pata
drivers. Don't forget to kill the stuff in
Documentation/kernel-parameters.txt though.
Acked-by: Jesse Barnes <[EMAIL PROTECTED]>
Jesse
-
To unsubscribe from this list: send the line "unsubscrib
-parameters.txt though.
Acked-by: Jesse Barnes [EMAIL PROTECTED]
Jesse
-
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
tch to make sure it worked
because I couldn't boot 2.6.20-git due to it not finding my RAID0 + lvm
disk.
[PATCH] e1000: fix shared interrupt warning message
From: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000
-alloc_rx_buf
That would be a bug, a possible patch would be (inline and attached):
compile tested, *but* I couldn't test this patch to make sure it worked
because I couldn't boot 2.6.20-git due to it not finding my RAID0 + lvm
disk.
[PATCH] e1000: fix shared interrupt warning message
From: Jesse Brandeburg
John wrote:
> Jesse Brandeburg wrote:
>> What would you like to do? At this stage I would like e100 to work
>> better than it is, but I'm not sure what to do next.
>
> Hello everyone,
>
> I'm resurrecting this thread because it appears we'll need to support
>
John wrote:
Jesse Brandeburg wrote:
What would you like to do? At this stage I would like e100 to work
better than it is, but I'm not sure what to do next.
Hello everyone,
I'm resurrecting this thread because it appears we'll need to support
these motherboards for several months to come
on other platforms
too, with weird ISA I/O and memory space mapping requirements.
Jesse
-
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/
requirements.
Jesse
-
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/
esn't seem like there's a sane general way to fix this up,
aside from some sort of blacklist. Maybe it's best to leave this
particular bridge unsupported for now...
Thanks,
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
it's best to leave this
particular bridge unsupported for now...
Thanks,
Jesse
-
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
supported on other platforms (iirc benh has
been planning to add legacy_* support to ppc for awhile). It would be
great if they were supported everywhere to provide userspace with a
fairly sane way to get at this stuff on all Linux systems...
Should be trivial on i386 I think.
Jesse
-
T
way to get at this stuff on all Linux systems...
Should be trivial on i386 I think.
Jesse
-
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
added Linux-pci
Jesse Brandeburg wrote:
> On 1/16/07, Allen Parker <[EMAIL PROTECTED]> wrote:
>> Allen Parker wrote:
>>> I have a PCI-E pro/1000 MT Quad Port adapter, which works quite well
>>> under 2.6.19.2 but fails to see link under 2.6.20-rc5. Earlier
&g
the
> word out in case someone else is testing this kernel on this nic chipset.
Upon some further investigation with Allen, I got this info, and it
appears that his system is not freeing MSI irq's correctly.
from our discussion:
Allen wrote:
Jesse Brandeburg wrote:
I believe you may have an
someone else is testing this kernel on this nic chipset.
Upon some further investigation with Allen, I got this info, and it
appears that his system is not freeing MSI irq's correctly.
from our discussion:
Allen wrote:
Jesse Brandeburg wrote:
I believe you may have an interrupt delivery problem
added Linux-pci
Jesse Brandeburg wrote:
On 1/16/07, Allen Parker [EMAIL PROTECTED] wrote:
Allen Parker wrote:
I have a PCI-E pro/1000 MT Quad Port adapter, which works quite well
under 2.6.19.2 but fails to see link under 2.6.20-rc5. Earlier
today I reported this to [EMAIL PROTECTED
the 'static const char' to match Ogawa-san's recent cleanup patches.
Over time we can probably associate more PCI IDs with this routine, since
i915 family contains a few other chips. But since I didn't have platforms
to test such additions on, they're left out for now.
Signed-off-by: Jesse
the 'static const char' to match Ogawa-san's recent cleanup patches.
Over time we can probably associate more PCI IDs with this routine, since
i915 family contains a few other chips. But since I didn't have platforms
to test such additions on, they're left out for now.
Signed-off-by: Jesse
On Monday, January 8, 2007 12:45 pm, Olivier Galibert wrote:
> On Sun, Jan 07, 2007 at 11:44:16AM -0800, Jesse Barnes wrote:
> > For reference, here's the probe routine I tried for 965, probably
> > something dumb wrong with it that I'm not seeing atm.
>
> It shouldn't have
GFP_KERNEL); + pci_mmcfg_config[0].base_address = pciexbar;
>
> Hmmm, I'd mask out the reserved bits if I were you. Paranoia :-)
Wouldn't hurt I suppose, want me to post a new patch?
Thanks,
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
. Paranoia :-)
Wouldn't hurt I suppose, want me to post a new patch?
Thanks,
Jesse
-
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
On Monday, January 8, 2007 12:45 pm, Olivier Galibert wrote:
On Sun, Jan 07, 2007 at 11:44:16AM -0800, Jesse Barnes wrote:
For reference, here's the probe routine I tried for 965, probably
something dumb wrong with it that I'm not seeing atm.
It shouldn't have mattered in your case
On Sunday, January 07, 2007 11:42 am, Jesse Barnes wrote:
> This patch updates Oliver's MMConfig bridge detection patches with
> support for 915G bridges. It seems to work ok on my 915GM laptop.
>
> I also tried adding 965 support, but it doesn't work (at least not on my
> G96
families, they may not
be enough that the code would actually be simpler if shared.
Thanks,
Jesse
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
diff -Napur -X /home/jbarnes/dontdiff
linux-2.6.19-mmconfig.orig/arch/i386/pci/mmconfig-shared.c
linux-2.6.19-mmconfig/arch/i386/pci/mm
families, they may not
be enough that the code would actually be simpler if shared.
Thanks,
Jesse
Signed-off-by: Jesse Barnes [EMAIL PROTECTED]
diff -Napur -X /home/jbarnes/dontdiff
linux-2.6.19-mmconfig.orig/arch/i386/pci/mmconfig-shared.c
linux-2.6.19-mmconfig/arch/i386/pci/mmconfig-shared.c
On Sunday, January 07, 2007 11:42 am, Jesse Barnes wrote:
This patch updates Oliver's MMConfig bridge detection patches with
support for 915G bridges. It seems to work ok on my 915GM laptop.
I also tried adding 965 support, but it doesn't work (at least not on my
G965 box). When I enable
sappear?
I think support for these devices can disappear (as I don't think they
will work anyway) but if someone complains we can take into account
what eepro100 did to support it (if anything) and enable it in e100.
Jesse (e100 maintainer)
-
To unsubscribe from this list: send the line "unsubs
On Wednesday, January 3, 2007 5:53 am, Arjan van de Ven wrote:
> On Mon, 2007-01-01 at 21:01 -0800, Jesse Barnes wrote:
> > Using MMCONFIG for PCI config space access is simply an
> > optimization, not a requirement. Therefore, when it can't be used,
> > there's no need for K
On Wednesday, January 3, 2007 5:53 am, Arjan van de Ven wrote:
> On Mon, 2007-01-01 at 21:01 -0800, Jesse Barnes wrote:
> > Using MMCONFIG for PCI config space access is simply an
> > optimization, not a requirement. Therefore, when it can't be used,
> > there's no need for K
On Wednesday, January 3, 2007 5:53 am, Arjan van de Ven wrote:
On Mon, 2007-01-01 at 21:01 -0800, Jesse Barnes wrote:
Using MMCONFIG for PCI config space access is simply an
optimization, not a requirement. Therefore, when it can't be used,
there's no need for KERN_ERR level message
On Wednesday, January 3, 2007 5:53 am, Arjan van de Ven wrote:
On Mon, 2007-01-01 at 21:01 -0800, Jesse Barnes wrote:
Using MMCONFIG for PCI config space access is simply an
optimization, not a requirement. Therefore, when it can't be used,
there's no need for KERN_ERR level message
for these devices can disappear (as I don't think they
will work anyway) but if someone complains we can take into account
what eepro100 did to support it (if anything) and enable it in e100.
Jesse (e100 maintainer)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On Tuesday, January 2, 2007 2:36 am, Alan wrote:
> On Mon, 1 Jan 2007 21:01:38 -0800
>
> Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > Using MMCONFIG for PCI config space access is simply an
> > optimization, not a requirement. Therefore, when it can't be used,
>
On Tuesday, January 2, 2007 2:36 am, Alan wrote:
On Mon, 1 Jan 2007 21:01:38 -0800
Jesse Barnes [EMAIL PROTECTED] wrote:
Using MMCONFIG for PCI config space access is simply an
optimization, not a requirement. Therefore, when it can't be used,
there's no need for
Some hardware reqires
that this has no effect on a normal boot, which is ridiculously
verbose these days.)
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
Thanks,
Jesse
diff --git a/arch/i386/pci/mmconfig.c b/arch/i386/pci/mmconfig.c
index e2616a2..b95e7f3 100644
--- a/arch/i386/pci/mmconfig.c
+++ b/arch/i3
that this has no effect on a normal boot, which is ridiculously
verbose these days.)
Signed-off-by: Jesse Barnes [EMAIL PROTECTED]
Thanks,
Jesse
diff --git a/arch/i386/pci/mmconfig.c b/arch/i386/pci/mmconfig.c
index e2616a2..b95e7f3 100644
--- a/arch/i386/pci/mmconfig.c
+++ b/arch/i386/pci
On 12/20/06, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> Yeah, I guess that's a problem. From a user perspective, the
> functionality is only really useful if the latency is very small. I
> think where possible we'd want to power down the chip while keeping the
> phy up, but it would be nice
On 12/20/06, Arjan van de Ven [EMAIL PROTECTED] wrote:
Yeah, I guess that's a problem. From a user perspective, the
functionality is only really useful if the latency is very small. I
think where possible we'd want to power down the chip while keeping the
phy up, but it would be nice to
t; for example.
FWIW, Kay and Neil recently went back and forth regarding what sorts of
events to generate for MD online/offline events. In concept md
online/offline and dock/undock seem similar enough that the 'change'
events Kay requested for md probably make sense in the dock/undock
context as we
md
online/offline and dock/undock seem similar enough that the 'change'
events Kay requested for md probably make sense in the dock/undock
context as well, but I've Cc'd him just in case.
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
debugging this, but I'm not sure
what we can do from here. If this were a generic code problem more
people would be reporting the issue.
What would you like to do? At this stage I would like e100 to work
better than it is, but I'm not sure what to do next.
Thanks for your patience on this iss
can do from here. If this were a generic code problem more
people would be reporting the issue.
What would you like to do? At this stage I would like e100 to work
better than it is, but I'm not sure what to do next.
Thanks for your patience on this issue,
Jesse
-
To unsubscribe from this list
sorry for the delay, your mail got marked as spam. In the future
please copy networking issues to netdev@vger.kernel.org, and be sure
to copy the maintainers of the driver you're having problems with
(they are in the MAINTAINERS file)
On 11/22/06, Amin Azez <[EMAIL PROTECTED]> wrote:
I notice
sorry for the delay, your mail got marked as spam. In the future
please copy networking issues to netdev@vger.kernel.org, and be sure
to copy the maintainers of the driver you're having problems with
(they are in the MAINTAINERS file)
On 11/22/06, Amin Azez [EMAIL PROTECTED] wrote:
I notice a
On 11/29/06, John <[EMAIL PROTECTED]> wrote:
> Let's go ahead and print the output from e100_load_eeprom
> debug patch attached.
Loading (then unloading) e100.ko fails the first few times (i.e. the
driver claims one of the EEPROMs is corrupted). Thereafter, sometimes it
fails, other times it
On 11/29/06, John [EMAIL PROTECTED] wrote:
Let's go ahead and print the output from e100_load_eeprom
debug patch attached.
Loading (then unloading) e100.ko fails the first few times (i.e. the
driver claims one of the EEPROMs is corrupted). Thereafter, sometimes it
fails, other times it works.
On 11/27/06, John <[EMAIL PROTECTED]> wrote:
John wrote:
>> -0009 : System RAM
>> 000a-000b : Video RAM area
>> 000f-000f : System ROM
>> 0010-0ffe : System RAM
>> 0010-00296a1a : Kernel code
>> 00296a1b-0031bbe7 : Kernel data
>> 0fff-0fff2fff :
On 11/27/06, John [EMAIL PROTECTED] wrote:
John wrote:
-0009 : System RAM
000a-000b : Video RAM area
000f-000f : System ROM
0010-0ffe : System RAM
0010-00296a1a : Kernel code
00296a1b-0031bbe7 : Kernel data
0fff-0fff2fff : ACPI Non-volatile
t open. Something else is
causing interrupts on the e1000 devices' lines.
I suspect the IOAPIC code or ACPI code.
Jesse
-
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/
suspect the IOAPIC code or ACPI code.
Jesse
-
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/
on 2.6.11/12 when it isn't working maybe you should send us the output
of lspci -vvv
just a hint, I'm guessing its power management related, and / or
something to do with the pci bus code.
On 8/30/05, Daniel Drake <[EMAIL PROTECTED]> wrote:
> Forwarding on, please reply-to-all in future.
>
>
on 2.6.11/12 when it isn't working maybe you should send us the output
of lspci -vvv
just a hint, I'm guessing its power management related, and / or
something to do with the pci bus code.
On 8/30/05, Daniel Drake [EMAIL PROTECTED] wrote:
Forwarding on, please reply-to-all in future.
Steve
ly "volatile" or "asm("eieio")" or whatever method your platform
> requires.)
writel() ensures ordering? Only from one CPU, another CPU issuing a
write at some later time may have its write arrive first. See
Documentation/io_ordering.txt for some docume
(eieio) or whatever method your platform
requires.)
writel() ensures ordering? Only from one CPU, another CPU issuing a
write at some later time may have its write arrive first. See
Documentation/io_ordering.txt for some documentation I put together on
this issue.
Jesse
-
To unsubscribe from
On 8/11/05, Stephen D. Williams <[EMAIL PROTECTED]> wrote:
> The chipset is an Intel 8x0 something. Unfortunately, there is a
> heatsink semi-permanently installed over everything. Is there a /proc
> pseudofile that will give me good identifying chipset info to report here?
you can show the
On 8/11/05, Stephen D. Williams [EMAIL PROTECTED] wrote:
The chipset is an Intel 8x0 something. Unfortunately, there is a
heatsink semi-permanently installed over everything. Is there a /proc
pseudofile that will give me good identifying chipset info to report here?
you can show the chipset
t same place, right after announcing the first
> device.
>
> Try booting with noapic.
Thanks a lot, noapic worked. I guess that means this is a generic IRQ
routing or setup issue, rather than something SATA specific?
Jesse
-
To unsubscribe from this list: send the line "unsubscribe
ectors, lba48
Is this a known problem? Is there anything in particular I should try?
Thanks,
Jesse
-
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
Ple
hang
Is this a known problem? Is there anything in particular I should try?
Thanks,
Jesse
-
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
, right after announcing the first
device.
Try booting with noapic.
Thanks a lot, noapic worked. I guess that means this is a generic IRQ
routing or setup issue, rather than something SATA specific?
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
estored when enabling such a device, so that its driver will
> be able to access it.
>
Is it just me or will this stuff help the kexec guys as well? They seem
to have lots of problems because drivers put the device into D3 before the
reload of the new kernel. I think this might help.
such a device, so that its driver will
be able to access it.
Is it just me or will this stuff help the kexec guys as well? They seem
to have lots of problems because drivers put the device into D3 before the
reload of the new kernel. I think this might help.
Jesse
-
To unsubscribe from this list: send
901 - 1000 of 1411 matches
Mail list logo
