On Sun, 2005-02-20 at 09:23 -0800, Linus Torvalds wrote:
>
> On Sun, 20 Feb 2005, Russell King wrote:
> > On Sat, Feb 19, 2005 at 08:36:12PM -0500, Steven Rostedt wrote:
> > > BIOS-e820: - 0009f000 (usable)
> > > BIOS-e820: 0009f000 - 000a (reserved)
On Sat, 2005-02-19 at 20:02 -0800, Linus Torvalds wrote:
>
> On Sat, 19 Feb 2005, Steven Rostedt wrote:
> >
> > On Sat, 2005-02-19 at 18:10 -0800, Linus Torvalds wrote:
> >
> > > I _think_ it's the code in arch/i386/pci/fixup.c that does this. See the
> > >
> > > static void __devinit
On Sat, 2005-02-19 at 20:02 -0800, Linus Torvalds wrote:
On Sat, 19 Feb 2005, Steven Rostedt wrote:
On Sat, 2005-02-19 at 18:10 -0800, Linus Torvalds wrote:
I _think_ it's the code in arch/i386/pci/fixup.c that does this. See the
static void __devinit
On Sun, 2005-02-20 at 09:23 -0800, Linus Torvalds wrote:
On Sun, 20 Feb 2005, Russell King wrote:
On Sat, Feb 19, 2005 at 08:36:12PM -0500, Steven Rostedt wrote:
BIOS-e820: - 0009f000 (usable)
BIOS-e820: 0009f000 - 000a (reserved)
I think I might have a new datapoint to add to this discussion:
I've got a IBM Thinkpad T42 with 1 GB RAM. Never had any problems
with PCMCIA, but that's probably just because another PCI device has
been mapped into the hole in the BIOS memory map:
[EMAIL PROTECTED]:~$ grep e820 /var/log/dmesg
I think I might have a new datapoint to add to this discussion:
I've got a IBM Thinkpad T42 with 1 GB RAM. Never had any problems
with PCMCIA, but that's probably just because another PCI device has
been mapped into the hole in the BIOS memory map:
[EMAIL PROTECTED]:~$ grep e820 /var/log/dmesg
On Sun, 2005-02-20 at 09:56 -0800, Linus Torvalds wrote:
> Steven, does this fix it without the need for any kernel command line (or
> any other patches, for that matter - ie revert all the transparency-
> changing ones)?
>
> Linus
>
Hi Linus,
I just tried it out (after removing
On Sun, 20 Feb 2005, Linus Torvalds wrote:
Russell, what do your eagle-eyes think of a patch like this?
Steven, does this fix it without the need for any kernel command line (or
any other patches, for that matter - ie revert all the transparency-
changing ones)?
Linus
I tried the patch on my G40
On Sun, 20 Feb 2005, Linus Torvalds wrote:
>
> But the PCI allocations are not at all limited by MAXMEM - they want to be
> in the low 4GB, but that's the only real limit. So using "max_low_pfn" to
> determine where to start PCI allocations is pretty bogus.
>
> I'll try to write something
On Sun, 20 Feb 2005, Russell King wrote:
> On Sat, Feb 19, 2005 at 08:36:12PM -0500, Steven Rostedt wrote:
> > BIOS-e820: - 0009f000 (usable)
> > BIOS-e820: 0009f000 - 000a (reserved)
> > BIOS-e820: 000d - 000d4000 (reserved)
>
On Sun, 2005-02-20 at 10:20 +, Russell King wrote:
> BTW, try passing:
>
> reserve=0x3fefa000,0x6000
>
> to the kernel - this will mark the "hole" reserved and should reallocate
> the resources which are clashing with the RAM.
>
I just tried this on 2.6.9 (with no patches) and it
On Sun, 2005-02-20 at 08:22 +, Russell King wrote:
> Your BIOS is broken. You probably have 1GB of RAM which extends from
> 0x to 0x4000.
Just to leave no doubt. Yes, I have a Gig of RAM.
-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Sat, 2005-02-19 at 22:51 -0800, Linus Torvalds wrote:
> Does a patch like this (instead of your version) work for you? It removes
> the Intel quirk entirely, and replaces it with the "if there's no
> resource, use the parent resource as the default fallback" code.
Hi Linus,
I live on the
On Sun, Feb 20, 2005 at 10:19:02AM +, Russell King wrote:
On Sun, Feb 20, 2005 at 10:52:12AM +0100, David Härdeman wrote:
Is the hole between 0x36f6fa000 and 0x3f70?
Looks like it.
And what would be the proper way of fixing it (assuming that IBM won't
issue a fixed BIOS)?
Try passing:
On Sun, Feb 20, 2005 at 11:20:59AM +0100, Dominik Brodowski wrote:
> > Is the hole between 0x36f6fa000 and 0x3f70?
> >
> > And what would be the proper way of fixing it (assuming that IBM won't
> > issue a fixed BIOS)?
>
> passing "reserve=0x3f6fa000,0x600" as kernel boot option. Please
On Sun, Feb 20, 2005 at 10:52:12AM +0100, David Härdeman wrote:
> On Sun, Feb 20, 2005 at 09:26:59AM +, Russell King wrote:
> >On Sun, Feb 20, 2005 at 10:22:09AM +0100, David Härdeman wrote:
> >>I see the same problem with an IBM Thinkpad G40, and only when there is
> >>1Gb of memory or more
On Sun, Feb 20, 2005 at 08:22:26AM +, Russell King wrote:
> On Sat, Feb 19, 2005 at 08:36:12PM -0500, Steven Rostedt wrote:
> > Linux version 2.6.10 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian
> > 1:3.3.5-8)) #13 SMP Sat Feb 19 20:12:19 EST 2005
> > BIOS-provided physical RAM map:
> >
On Sun, Feb 20, 2005 at 10:52:12AM +0100, David Härdeman wrote:
> e820 map:
> BIOS-provided physical RAM map:
> BIOS-e820: - 0009f000 (usable)
> BIOS-e820: 0009f000 - 000a (reserved)
> BIOS-e820: 000ce000 - 000d (reserved)
>
On Sun, Feb 20, 2005 at 09:26:59AM +, Russell King wrote:
On Sun, Feb 20, 2005 at 10:22:09AM +0100, David Härdeman wrote:
I see the same problem with an IBM Thinkpad G40, and only when there is
1Gb of memory or more in the machine.
Check to see if your e820 map has a hole in it, and whether
On Sun, Feb 20, 2005 at 10:22:09AM +0100, David Härdeman wrote:
> Steven Rostedt wrote:
> > I have a IBM Thinkpad G41 with a pentium4M with Hyperthreading. I can't
> > get the PCMCIA working at all. I've tried turning off hyperthreading,
> > I've tried with and without preempt, I've even added
Steven Rostedt wrote:
I have a IBM Thinkpad G41 with a pentium4M with Hyperthreading. I can't
get the PCMCIA working at all. I've tried turning off hyperthreading,
I've tried with and without preempt, I've even added pci=noacpi. I've
added Len's ACPI patches, but nothing works.
I see the same
On Sat, Feb 19, 2005 at 08:36:12PM -0500, Steven Rostedt wrote:
> Linux version 2.6.10 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian
> 1:3.3.5-8)) #13 SMP Sat Feb 19 20:12:19 EST 2005
> BIOS-provided physical RAM map:
> BIOS-e820: - 0009f000 (usable)
> BIOS-e820:
On Sat, Feb 19, 2005 at 08:36:12PM -0500, Steven Rostedt wrote:
Linux version 2.6.10 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian
1:3.3.5-8)) #13 SMP Sat Feb 19 20:12:19 EST 2005
BIOS-provided physical RAM map:
BIOS-e820: - 0009f000 (usable)
BIOS-e820:
Steven Rostedt wrote:
I have a IBM Thinkpad G41 with a pentium4M with Hyperthreading. I can't
get the PCMCIA working at all. I've tried turning off hyperthreading,
I've tried with and without preempt, I've even added pci=noacpi. I've
added Len's ACPI patches, but nothing works.
I see the same
On Sun, Feb 20, 2005 at 10:22:09AM +0100, David Härdeman wrote:
Steven Rostedt wrote:
I have a IBM Thinkpad G41 with a pentium4M with Hyperthreading. I can't
get the PCMCIA working at all. I've tried turning off hyperthreading,
I've tried with and without preempt, I've even added
On Sun, Feb 20, 2005 at 09:26:59AM +, Russell King wrote:
On Sun, Feb 20, 2005 at 10:22:09AM +0100, David Härdeman wrote:
I see the same problem with an IBM Thinkpad G40, and only when there is
1Gb of memory or more in the machine.
Check to see if your e820 map has a hole in it, and whether
On Sun, Feb 20, 2005 at 10:52:12AM +0100, David Härdeman wrote:
e820 map:
BIOS-provided physical RAM map:
BIOS-e820: - 0009f000 (usable)
BIOS-e820: 0009f000 - 000a (reserved)
BIOS-e820: 000ce000 - 000d (reserved)
BIOS-e820:
On Sun, Feb 20, 2005 at 08:22:26AM +, Russell King wrote:
On Sat, Feb 19, 2005 at 08:36:12PM -0500, Steven Rostedt wrote:
Linux version 2.6.10 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian
1:3.3.5-8)) #13 SMP Sat Feb 19 20:12:19 EST 2005
BIOS-provided physical RAM map:
BIOS-e820:
On Sun, Feb 20, 2005 at 10:52:12AM +0100, David Härdeman wrote:
On Sun, Feb 20, 2005 at 09:26:59AM +, Russell King wrote:
On Sun, Feb 20, 2005 at 10:22:09AM +0100, David Härdeman wrote:
I see the same problem with an IBM Thinkpad G40, and only when there is
1Gb of memory or more in the
On Sun, Feb 20, 2005 at 11:20:59AM +0100, Dominik Brodowski wrote:
Is the hole between 0x36f6fa000 and 0x3f70?
And what would be the proper way of fixing it (assuming that IBM won't
issue a fixed BIOS)?
passing reserve=0x3f6fa000,0x600 as kernel boot option. Please also post
On Sun, Feb 20, 2005 at 10:19:02AM +, Russell King wrote:
On Sun, Feb 20, 2005 at 10:52:12AM +0100, David Härdeman wrote:
Is the hole between 0x36f6fa000 and 0x3f70?
Looks like it.
And what would be the proper way of fixing it (assuming that IBM won't
issue a fixed BIOS)?
Try passing:
On Sat, 2005-02-19 at 22:51 -0800, Linus Torvalds wrote:
Does a patch like this (instead of your version) work for you? It removes
the Intel quirk entirely, and replaces it with the if there's no
resource, use the parent resource as the default fallback code.
Hi Linus,
I live on the East
On Sun, 2005-02-20 at 08:22 +, Russell King wrote:
Your BIOS is broken. You probably have 1GB of RAM which extends from
0x to 0x4000.
Just to leave no doubt. Yes, I have a Gig of RAM.
-- Steve
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Sun, 2005-02-20 at 10:20 +, Russell King wrote:
BTW, try passing:
reserve=0x3fefa000,0x6000
to the kernel - this will mark the hole reserved and should reallocate
the resources which are clashing with the RAM.
I just tried this on 2.6.9 (with no patches) and it worked. So
On Sun, 20 Feb 2005, Russell King wrote:
On Sat, Feb 19, 2005 at 08:36:12PM -0500, Steven Rostedt wrote:
BIOS-e820: - 0009f000 (usable)
BIOS-e820: 0009f000 - 000a (reserved)
BIOS-e820: 000d - 000d4000 (reserved)
On Sun, 20 Feb 2005, Linus Torvalds wrote:
But the PCI allocations are not at all limited by MAXMEM - they want to be
in the low 4GB, but that's the only real limit. So using max_low_pfn to
determine where to start PCI allocations is pretty bogus.
I'll try to write something that
On Sun, 20 Feb 2005, Linus Torvalds wrote:
Russell, what do your eagle-eyes think of a patch like this?
Steven, does this fix it without the need for any kernel command line (or
any other patches, for that matter - ie revert all the transparency-
changing ones)?
Linus
I tried the patch on my G40
On Sun, 2005-02-20 at 09:56 -0800, Linus Torvalds wrote:
Steven, does this fix it without the need for any kernel command line (or
any other patches, for that matter - ie revert all the transparency-
changing ones)?
Linus
Hi Linus,
I just tried it out (after removing all
On Sat, 19 Feb 2005, Linus Torvalds wrote:
>
> Does a patch like this (instead of your version) work for you? It removes
> the Intel quirk entirely, and replaces it with the "if there's no
> resource, use the parent resource as the default fallback" code.
Here's a very very slightly changed
On Sat, 19 Feb 2005, Steven Rostedt wrote:
>
> + /* the 2448 bridge is not transparent */
> + dev->device != 0x2448)
Btw, I've got a laptop with the exact same bridge chip PCI ID (well, mine
is "rev 83", while yours claims to be "rev 81"), and mine definitely _is_
transparent.
On Sat, 19 Feb 2005, Steven Rostedt wrote:
>
> On Sat, 2005-02-19 at 18:10 -0800, Linus Torvalds wrote:
>
> > I _think_ it's the code in arch/i386/pci/fixup.c that does this. See the
> >
> > static void __devinit pci_fixup_transparent_bridge(struct pci_dev *dev)
> >
> > thing, and try to
On Sat, 2005-02-19 at 18:10 -0800, Linus Torvalds wrote:
> I _think_ it's the code in arch/i386/pci/fixup.c that does this. See the
>
> static void __devinit pci_fixup_transparent_bridge(struct pci_dev *dev)
>
> thing, and try to disable it. Maybe that rule is wrong, and triggers much
>
On Sat, 19 Feb 2005, Steven Rostedt wrote:
>
> Here's the scoop:
>
> cat /proc/iomem:
Ok. This one does not show device 00:1e.0 _at_all_. It had:
I/O behind bridge: 3000-6fff
Memory behind bridge: c200-cfff
Prefetchable memory behind bridge:
On Sat, 2005-02-19 at 16:59 -0800, Linus Torvalds wrote:
> The parent bridge has IO port mappings at 3000-6fff, and IO memory
> mappings at c200-cfff and f000-f7ff. The cardbus stuff
> _should_ all be behind those regions, but instead they are at 3fefb000 and
>
On Sat, 19 Feb 2005, Steven Rostedt wrote:
>
> :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 81) (prog-if 00
> [Normal decode])
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR+ FastB2B-
> Status: Cap- 66MHz- UDF- FastB2B+
Sorry for the repost, but I figured I might get the attention of someone
that has an IBM Thinkpad G41 with the updated subject.
--
Hi everyone,
I've been banging my head on this one a couple of days with no luck.
I have a IBM Thinkpad G41 with a pentium4M with
Sorry for the repost, but I figured I might get the attention of someone
that has an IBM Thinkpad G41 with the updated subject.
--
Hi everyone,
I've been banging my head on this one a couple of days with no luck.
I have a IBM Thinkpad G41 with a pentium4M with
On Sat, 19 Feb 2005, Steven Rostedt wrote:
:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 81) (prog-if 00
[Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr-
On Sat, 2005-02-19 at 16:59 -0800, Linus Torvalds wrote:
The parent bridge has IO port mappings at 3000-6fff, and IO memory
mappings at c200-cfff and f000-f7ff. The cardbus stuff
_should_ all be behind those regions, but instead they are at 3fefb000 and
On Sat, 19 Feb 2005, Steven Rostedt wrote:
Here's the scoop:
cat /proc/iomem:
Ok. This one does not show device 00:1e.0 _at_all_. It had:
I/O behind bridge: 3000-6fff
Memory behind bridge: c200-cfff
Prefetchable memory behind bridge:
On Sat, 2005-02-19 at 18:10 -0800, Linus Torvalds wrote:
I _think_ it's the code in arch/i386/pci/fixup.c that does this. See the
static void __devinit pci_fixup_transparent_bridge(struct pci_dev *dev)
thing, and try to disable it. Maybe that rule is wrong, and triggers much
too
On Sat, 19 Feb 2005, Steven Rostedt wrote:
On Sat, 2005-02-19 at 18:10 -0800, Linus Torvalds wrote:
I _think_ it's the code in arch/i386/pci/fixup.c that does this. See the
static void __devinit pci_fixup_transparent_bridge(struct pci_dev *dev)
thing, and try to disable it.
On Sat, 19 Feb 2005, Steven Rostedt wrote:
+ /* the 2448 bridge is not transparent */
+ dev-device != 0x2448)
Btw, I've got a laptop with the exact same bridge chip PCI ID (well, mine
is rev 83, while yours claims to be rev 81), and mine definitely _is_
transparent.
On my
On Sat, 19 Feb 2005, Linus Torvalds wrote:
Does a patch like this (instead of your version) work for you? It removes
the Intel quirk entirely, and replaces it with the if there's no
resource, use the parent resource as the default fallback code.
Here's a very very slightly changed patch.
54 matches
Mail list logo
