From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Mathieu Taillefumier <mathieu.taillefumier@free.fr>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [Bug] pci allocation resources problems on x86_64
Date: Fri, 24 Oct 2008 11:31:54 -0700 [thread overview]
Message-ID: <200810241131.55129.jbarnes@virtuousgeek.org> (raw)
In-Reply-To: <4901A4C2.5020805@free.fr>
On Friday, October 24, 2008 3:34 am Mathieu Taillefumier wrote:
> Hi
>
> Sorry, the first files iomem and ioports are not the right one (I used
> the mem option to check if it has any effects). Please find the right
> one in attachments. Sorry again for this mistake.
>
> regards
>
> Mathieu
>
> > Hi,
> >
> > The kernel does not seems to allocate the pci resources correctly on
> > sony laptop (VGN-SZ71 series) when pcmcia slot is used.
> >
> > I track down this bug for long now and I was able to identify where it
> > is probably coming from. The laptop I am using possess a pcmcia card
> > slot that I am using for a tvcard. The kernel is a x86_64 bits kernel
> > (2.6.27.2) and the laptop has 4G of memory. In this case the
> > initialization of the tv-card is pure garbage and the kernel oops
> > after that. Now if I start the laptop with 2G and the same kernel then
> > everything works fine. From that I can assume that the problem does
> > not come from the tvcard driver and maybe not from the pcmcia driver
> > (although I am not completely sure). After discussing on the dvb
> > mailling list we arrive to the conclusion that the problem is probably
> > coming from pci allocation ressources.
> >
> > additional informations :
> >
> > Configurations that work
> >
> > - x86_64 kernels with 2G of memory
> > - x86 kernels with 4G of memory without PAE activated nor 64 bits
> > resources allocations option activated.
> >
> > Config that do not work
> >
> > - x86_64 kernels with 4G of memory
> > - x86 kernels with 4G of memory with 64bits resources allocation
> > activated (without PAE).
> >
> > The problem can be reproduced with kernel-next and the kernel-git so
> > far and probably with earlier kernels although I have try this
> >
> > cat /proc/version
> > Linux version 2.6.27.2-intel-nogem (root@coesite) (gcc version 4.3.1
> > (GCC) ) #4 SMP Wed Oct 22 12:05:55 CEST 2008
> > the lspci output are in one of the files and different dmesg are
> > included. the dmesg-diff give the differences between the working one
> > and the buggy one.
> >
> > I would like to help debugging this
Ultimately we need to do better at grabbing space for PCI allocations on x86.
I was hoping we'd have some patches in 2.6.28 that would help here, but they
weren't ready in time. Can you file a kernel.org bug for this problem with
the files attached? I'll try to find time to put together some
improvements...
--
Jesse Barnes, Intel Open Source Technology Center
next prev parent reply other threads:[~2008-10-24 18:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-24 10:13 [Bug] pci allocation resources problems on x86_64 Mathieu Taillefumier
2008-10-24 10:34 ` Mathieu Taillefumier
2008-10-24 18:31 ` Jesse Barnes [this message]
2008-10-24 20:10 ` mathieu.taillefumier
2008-10-25 8:45 ` Yinghai Lu
2008-10-25 9:04 ` Yinghai Lu
2008-10-25 12:43 ` mathieu.taillefumier
2008-10-25 19:55 ` Yinghai Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200810241131.55129.jbarnes@virtuousgeek.org \
--to=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.taillefumier@free.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox