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 pci_fixu
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:
>
> 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 tha
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 wor
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
th
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, 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
Have you tried it to get it to work without ACPI in the kernel at all, and
start from there?
Best regards,
Norbert
On Saturday 19 February 2005 22:54, you wrote:
> 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 pentium4
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: 00
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 pat
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 d
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
> t
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: f000-f7
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
> 4000-
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+ ParE
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 Hyperthre
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 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
20 matches
Mail list logo
