On Mon, Nov 16, 2020 at 02:44:56PM -0800, Linus Torvalds wrote:
> On Mon, Nov 16, 2020 at 2:15 PM Linus Torvalds
> wrote:
> >
> > So I've verified that at least on x86-64, this doesn't really make
> > code generation any worse, and I'm ok with the patch from that
> > standpoint.
>
> .. looking cl
On Sat, Jun 20, 2020 at 07:54:38PM +0200, Andrew Lunn wrote:
> On Sat, Jun 20, 2020 at 05:44:49PM +0100, Ivan Kokshaysky wrote:
> > Commit 0c868627e617e43a295d8 (cpufreq: dt: Allow platform specific
> > intermediate callbacks) added two function pointers to the
> > struct cpu
.174554] Unable to handle kernel execute from non-executable memory at
virtual address 3f87bdc0
...
[ 29.269373] pc : 0x3f87bdc0
[ 29.272957] lr : __cpufreq_driver_target+0x138/0x580
...
Fixed by zeroing out pdata before use.
Signed-off-by: Ivan Kokshaysky
---
drivers/cpu
On Fri, Jun 30, 2017 at 10:16:15AM -0700, Linus Torvalds wrote:
> On Fri, Jun 30, 2017 at 7:30 AM, Thomas Gleixner wrote:
> >> But MCFG problems were a long time ago and noone uses these systems
> >> anymore,
> >> so perhaps he is right.
> >
> > The obvious solution to this is to force type 1 for
On Wed, Feb 13, 2008 at 11:14:43AM -0600, Bob Tracy wrote:
> Ivan Kokshaysky wrote:
> > No SMP, no PRINTK_TIMESTAMPS in my case. Looks like it dies trying to
> > to switch to vga console, but I had no time to debug this yet...
>
> Same basic configuration as Ivan. Concur
n alpha, so this part
Acked-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
Ivan.
--
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 Wed, Feb 13, 2008 at 02:04:32PM +0100, Ingo Molnar wrote:
> > > Unless someone has a good idea what's causing this, I see a massive
> > > "git bisect" project in my future. Won't be able to spend any time
> > > with this until at least the weekend :-(.
> >
> > hm, is this SMP? Alpha uses asm
On Wed, Feb 13, 2008 at 04:22:58PM +1100, Nick Piggin wrote:
> On Tuesday 12 February 2008 04:27, Raúl Porcel wrote:
> > We have a Compaq AlphaServer ES40 and since 2.6.23 it won't boot. I'm
> > attaching the console log and the kernel config.
Looks like your 'aboot' is outdated - see http://lkml.
On Fri, Feb 08, 2008 at 02:46:15PM -0800, Andrew Morton wrote:
> I think it would have been better to define a new CONFIG_MODULEPARAM_CONST
> for those three archictures, rather than muckying up the code like this.
I'd prefer to keep this as is for now (sorta the uglier the better ;-)
I really hop
res due to 'section type conflict' in those rare cases where
param_set/get are local functions.
This fixes http://bugzilla.kernel.org/show_bug.cgi?id=8964
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
---
include/linux/moduleparam.h | 12 +++-
1 files changed, 11
On Fri, Feb 08, 2008 at 03:30:22PM +0200, Adrian Bunk wrote:
> > > On Fri, Feb 08, 2008 at 04:02:59PM +0530, Kamalesh Babulal wrote:
> > >> The 2.6.24-git18 kernel build fails on the power machine with following
> > >> message
> > >> drivers/input/mouse/psmouse-base.c:44: error: __param_proto caus
On Wed, Jan 30, 2008 at 07:42:49AM -0800, Arjan van de Ven wrote:
> Xorg doesn't do pci express ..
Xorg core provides a set of PCI config access functions (via sysfs) for
the graphics drivers. These functions do work correctly with offsets > 256
bytes. Can you guarantee that none of PCI-E video dr
On Tue, Jan 29, 2008 at 08:45:55PM -0700, Matthew Wilcox wrote:
> On Tue, Jan 29, 2008 at 05:19:55AM -0800, Greg KH wrote:
> > Matthew, with Arjan's patch, is anything that currently works now
> > broken? Why do you feel it is somehow "wrong"?
>
> lspci is broken. It used to be able to access ex
The trap handler does properly update the fraction,
but not the exponent...
Thanks to Paolo Bonzini <[EMAIL PROTECTED]> for the bug report
and the testcase.
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
---
arch/alpha/math-emu/math.c |2 +-
1 files changed, 1 insertions(+),
On Sat, Jan 12, 2008 at 09:45:57AM -0800, Arjan van de Ven wrote:
> btw this is my main objection to your patch; it intertwines the conf1
> and mmconfig code even more.
There is nothing wrong with it; please realize that mmconf and conf1 are
just different cpu-side interfaces. Both produce precise
On Sat, Jan 12, 2008 at 07:46:32AM -0800, Arjan van de Ven wrote:
> Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
> > Actually I'm strongly against Arjan's patch. First, it's based on
> > assumption that the MMCONFIG thing is sort of fundamentally broken
> >
On Sat, Jan 12, 2008 at 12:27:05AM -0700, Grant Grundler wrote:
> Looking at setup-bus.c:pci_bridge_check_ranges(), I'm concluding that:
> [7] is IO Range.
> [8] is MMIO
> [9] is Prefetchable MMIO
> [10] no clue...maybe used by host PCI bus controllers.
#10 is for cardbus bridges, IIRC.
> 0x1
uration mechanism for the legacy config space
and extended mechanism (mmconf) for the extended config space is
a simple and very logical approach. It's supposed to resolve all
known mmconf problems. It still allows per-device quirks (tweaking
dev->cfg_size). It also allows to get rid of mmconf
On Fri, Jan 11, 2008 at 02:38:03PM -0700, Matthew Wilcox wrote:
> On Fri, Jan 11, 2008 at 01:28:30PM -0800, Linus Torvalds wrote:
> > Hmm. Were all those reports root-caused to just that BAR probing? If so,
> > we may be in better shape than I worried.
>
> I believe so.
Ditto.
One typical probl
On Sun, Dec 30, 2007 at 07:23:53AM +0100, Anders Hammarquist wrote:
> Trying to compile 2.6.23.12 on alpha (a miata) resulted in this
> failure:
>
> cc1: warnings being treated as errors
> include/asm/io_trivial.h: In function 'cia_readb':
> include/asm/io_trivial.h:75: warning: passing argument 1
On Fri, Dec 28, 2007 at 12:40:53PM -0500, Loic Prylli wrote:
> The only quirk I see removed is a bitmap with an arbitrary size (that we
> don't really know is sufficient for every system), and that is only
> built using comparison between mmconf and type1 accesses. IMHO, there
> is zero knowledge
On Fri, Dec 28, 2007 at 08:14:18AM -0800, Arjan van de Ven wrote:
> it removes code by removing quirks / known not working stuff..
This not working stuff gets detected at probe time - see
drivers/pci/probe.c:pci_cfg_space_size().
Ivan.
--
To unsubscribe from this list: send the line "unsubscribe
config space
and extended mechanism (mmconf) for the extended config space is a simple
and very logical approach. It's supposed to resolve *all* known mmconf
problems. And it still allows per-device quirks (tweaking dev->cfg_size).
And it does *remove* code, not add anything new/untested.
Signe
res due
to 'section type conflict' in those rare cases where param_set/get are
local functions.
This fixes http://bugzilla.kernel.org/show_bug.cgi?id=8964
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
---
include/linux/moduleparam.h | 11 ++-
1 files changed, 10 insertion
These two are defined inline in linux/gameport.h.
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
---
drivers/input/gameport/gameport.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/input/gameport/gameport.c
b/drivers/input/gameport/gameport.c
On Mon, Dec 24, 2007 at 02:22:10AM -0500, Jeff Garzik wrote:
> The phrase "all or none" specifically describes the current practice in
> arch/x86/pci/mmconfig_{32,64}.c whereby a PCI bus always has one, and only
> one, access method.
>
> So the problems you describe are unrelated to "all or none"
On Sun, Dec 23, 2007 at 10:15:10PM +0100, Martin Mares wrote:
> > - During that probe, you set a flag if any device has capabilities that
> > extend beyond 0xff.
>
> Can this work? The extended capabilities are not linked to the normal
> ones in any way.
Good point.
OTOH, we *do* have a flag f
On Sun, Dec 23, 2007 at 12:44:30AM -0500, Jeff Garzik wrote:
> Failures are more predictable and more consistent with an all-or-none
> scenario. The all-or-none solutions are the least complex on the software
> side, and far more widely tested than any mixed config access scheme.
Nope. The vast
On Thu, Dec 20, 2007 at 12:08:33PM -0700, Matthew Wilcox wrote:
> On Thu, Dec 20, 2007 at 02:04:31PM -0500, Tony Camuso wrote:
> > Does anybody see a down side to this?
>
> It'll be slower than it would be if we used mmconfig directly. Now yes,
> nobody should be using pci config space in perform
er architectures are affected
as well.
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
---
fs/binfmt_aout.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/fs/binfmt_aout.c b/fs/binfmt_aout.c
index e176d19..7596e1e 100644
--- a/fs/binfmt_aout.c
+++ b/fs/binf
rammed with a bogus address
when its respective resource gets allocated above the 4G mark.
Note that we cannot yet guarantee correct resource allocations
above 4G, though it might work in some simple cases.
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
---
drivers/pci/setup-bus.c |7
On Thu, Dec 20, 2007 at 03:28:08PM +1100, Benjamin Herrenschmidt wrote:
> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Acked-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
Ivan.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
On Wed, Dec 19, 2007 at 04:10:19PM +1100, Benjamin Herrenschmidt wrote:
> This patch changes the x86 PCI code to disable IO and/or Memory
> decoding on a PCI device when a resource of that type failed to
> be allocated.
Oh, this opens up a can of worms ;-)
In ideal world, the patch would be perfe
On Tue, Dec 18, 2007 at 12:22:34PM -0800, Richard Henderson wrote:
> On Tue, Dec 18, 2007 at 10:21:50AM -0800, Linus Torvalds wrote:
> > ... and that would be an X server issue!).
>
> Of course, fixing the X server to *handle* 64-bit BARs is the correct
> solution. I've no idea how involved that
On Tue, Dec 18, 2007 at 10:01:15AM +1100, Benjamin Herrenschmidt wrote:
> @@ -1040,7 +1040,10 @@ static inline void __devinit alloc_resou
> r->flags |= IORESOURCE_UNSET;
> r->end -= r->start;
> r->start = 0;
Perhaps we should use IORESOURCE_UNSET universal
On Tue, Dec 18, 2007 at 11:02:37AM +1100, Benjamin Herrenschmidt wrote:
> +EXPORT_SYMBOL(pci_enable_device_io);
> +EXPORT_SYMBOL(pci_enable_device_mem);
> EXPORT_SYMBOL(pci_enable_device);
Wouldn't it be better to export only the pci_enable_device_flags()
and make these three just "static inline"
On Mon, Dec 17, 2007 at 01:57:33PM -0800, Kok, Auke wrote:
> what kind of platform actually is doing this? It almost seems like something
> is
> wrong with that platform's BIOS and I wonder if this workaround should not be
> more
> general (IOW is it not just e100 that is affected but other compo
Check that the e100 is in the D0 power state. If it's not, it won't
respond to MMIO accesses and we end up with master-abort machine
checks on some platforms.
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
---
drivers/pci/quirks.c | 14 +-
1 files changed, 13
On Fri, Dec 14, 2007 at 07:51:06AM +1100, Benjamin Herrenschmidt wrote:
> If the device is behind a P2P bridge and the BIOS has set the windows of
> that bridge so tightly that there is no room to allocate the MMIO BAR,
> then a full disable/full enable would fail on a device that would
> otherwise
On Thu, Dec 13, 2007 at 10:20:20PM +1100, Benjamin Herrenschmidt wrote:
> I may have not fully undestood you in my previous reply. You are proposing
> replacing pci_enable_device_bars() with a pair of pci_enable_device_io/mem ?
>
> I think that would be a good idea indeed.
I'm all for it. Never l
to .data.init.refok
section;
- unbreak CPU-specific optimization: rearrange cpuflags-y assignments
so that extended -mcpu value (ev56, pca56, ev67) overrides basic
one (ev5, ev6) and not vice versa.
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
Ivan.
--- 2.6.24-rc5/arch/alpha/Make
On Thu, Dec 13, 2007 at 04:26:42PM +1100, Benjamin Herrenschmidt wrote:
> I can try to whip up some code tomorrow I suppose, though I'm always
> afraid some dodgy x86 setup will blow up...
That scares me too, but something like pci_dangling_bar(dev, idx) with
a default (for now) no-op implementati
On Wed, Dec 12, 2007 at 10:22:22PM -0600, Robert Hancock wrote:
> For the case where you say "I want to enable decoding for this MMIO BAR,
> but not that one", though, I don't see an obvious way to provide that
> guarantee with certainty. Normally, one would expect that if a BAR is
> mapped safe
t DEVPATH strings generated in uevent and therefore to udev
problems.
strncpy.S: unrelated bug I found while testing the above fix - destination
is not properly zero-padded then a byte count exceeds source length.
Actually this is addition to strncpy fix from last year.
Signed-off-by: Ivan K
On Mon, Dec 10, 2007 at 09:08:53AM -0600, Bob Tracy wrote:
> Ivan Kokshaysky wrote:
> > For now I have reassigned the bug #9457 to myself and will gradually hack
> > into udev...
>
> Thanks... Let me know if there's anything useful I can do to help.
It turns out to be
On Sat, Dec 08, 2007 at 10:19:39PM -0600, Bob Tracy wrote:
> I *do* have CONFIG_MAGIC_SYSRQ set. Anyone care to bet whether my
> machine starts working again if I disable it? Sheesh...
Incredible...
Toggling CONFIG_MAGIC_SYSRQ works for me too, so I'm finally able
to reproduce the problem (whic
On Wed, Sep 26, 2007 at 03:20:40PM -0700, Jesse Barnes wrote:
> Ivan, your concern is about disabling things like interrupt controllers
> and power management chips during probe right? You're right that doing
> that could cause problems if we get and interrupt or PMU event at just
> the wrong t
On Tue, Sep 18, 2007 at 06:30:23AM +1000, Benjamin Herrenschmidt wrote:
> At this stage (but we are getting a bit OT), ppc has something like 3
> different PCI code implementations :-) I do have some plans to fix that
> by switching everybody to use pci_assign_unassigned_resources() and
> friends b
On Mon, Sep 17, 2007 at 09:21:47AM +0800, Shaohua Li wrote:
> I can confirm this is an add-in graphics card. the bfd is 00:02.0, so
> it's not behind any AGP/PCI-E bridge.
AFAIKS, 00:02.0 is *integrated* controller. Can you check that "graphic
adapter priority" setting in BIOS is "PCI Express" and
On Sun, Sep 16, 2007 at 10:01:52PM +0200, Benjamin Herrenschmidt wrote:
> Agreed. I have a similar problem on ppc where it's common to have things
> like the main PIC on a PCI device. Note that another problem is (or at
> least was, i haven't checked recently) the P2P bridge scanning code
> that, i
On Sun, Sep 16, 2007 at 01:52:59PM -0600, Matthew Wilcox wrote:
> I don't think it would be that complicated. We could just delay probing
> for mmconfig until after the pci bus probes are done. No changes to
> other architectures needed.
Indeed. Seems like it's a way to go.
> I'm really disappo
On Sun, Sep 16, 2007 at 11:34:35AM -0600, Robert Hancock wrote:
> > The most interesting fact there is that windows *does not* clear
> > PCI_COMMAND_MEMORY bits during PCI bus enumeration, so BIOS writers
> > have to rely on that. Yet another reason why your patch is unsafe.
>
> Windows 98 doesn't
On Fri, Sep 14, 2007 at 05:53:58PM -0600, Robert Hancock wrote:
> In the first one, Linus talks about a USB controller whose SMM code
> chokes on the BAR being disabled. That explanation seems odd to me. If
> it chokes on the BAR disabled, how doesn't it choke on the BAR being
> moved to a diffe
On Fri, Sep 14, 2007 at 08:30:59AM -0600, Robert Hancock wrote:
> Do you have an example of specific hardware that exhibits this problem?
Well, first two results of google search for "disable bar when sizing":
http://lkml.org/lkml/2002/12/21/95
http://lkml.org/lkml/2002/12/20/110
> So far after
On Fri, Sep 14, 2007 at 03:14:01PM +0400, Ivan Kokshaysky wrote:
> whippets doesn't look sane either. ;-)
It's not me, it's a spellchecker :-) I meant "chipsets" of course, sorry.
Ivan.
-
To unsubscribe from this list: send the line "unsubscribe linux
On Thu, Sep 13, 2007 at 09:32:42PM -0600, Robert Hancock wrote:
> Disabling the BAR decoding does not mean disabling the device (aside
> from the one group of host bridge that apparently disables CPU to RAM
> access, whose designers were apparently on crack when they read the PCI
> spec and whi
On Thu, Sep 13, 2007 at 02:53:13AM -0700, Greg KH wrote:
> On Thu, Sep 13, 2007 at 01:55:36AM -0600, Matthew Wilcox wrote:
> > Unfortunately if this patch does cause any machine to break, these will
> > be machines that worked fine up until this point, so that would be a
> > regression, which is wo
From: Jay Estabrook <[EMAIL PROTECTED]>
Files:
arch/alpha/kernel/sys_titan.c
This code corrects the usage of the request_irq() routine.
Signed-off-by: Jay Estabrook <[EMAIL PROTECTED]>
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
---
diff -Naurp a/arch/alpha/kernel/
On Wed, Jul 11, 2007 at 06:07:59PM +0100, Hugh Dickins wrote:
> > + gfp &= ~GFP_DMA;
>
> The canonical form for this masking, even on arches without HIGHMEM,
> appears to be:
> gfp &= ~(__GFP_DMA | __GFP_HIGHMEM);
> But I guess that won't make any actual difference.
As far as I can see, n
you test this one?
---
Take care of DMA flags passed to dma_alloc_coherent().
Particularly ALSA needs that.
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
Ivan.
--- 2.6.22/arch/alpha/kernel/pci_iommu.cMon Jul 9 03:32:17 2007
+++ linux/arch/alpha/kernel/pci_iommu.c Wed Jul 11
e seems to be ok.
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
Ivan.
--- 2.6.22-rc4-mm2/arch/alpha/lib/ev6-csum_ipv6_magic.S Fri Jun 22 15:02:23 2007
+++ linux/arch/alpha/lib/ev6-csum_ipv6_magic.S Fri Jun 22 15:05:38 2007
@@ -76,18 +76,18 @@ csum_ipv6_magic:
cmoveq $6,
h any src/dst [mis]alignment.
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
Ivan.
--- 2.6.22-rc4/arch/alpha/lib/ev6-csum_ipv6_magic.S Sun Feb 4 21:44:54 2007
+++ linux/arch/alpha/lib/ev6-csum_ipv6_magic.S Sun Jun 17 00:41:53 2007
@@ -46,6 +46,10 @@
* add the 3 low ushor
On Wed, May 23, 2007 at 08:10:54PM -0700, Jesse Barnes wrote:
> > +/* Give unknown D-Link network adapters a proper class */
> > +static void __devinit quirk_dlink_unknown(struct pci_dev *dev)
> > +{
> > + if (dev->class = PCI_CLASS_UNKNOWN)
>
> Err, == of course. Obviously I didn't test this.
On Tue, May 22, 2007 at 04:31:22PM -0700, Jesse Barnes wrote:
> On Tuesday, May 22, 2007, Wayne Sherman wrote:
> > If so, the D-Link is not being mapped into the
> > right region, and the bridge it is behind does not have enough memory
> > assigned to it (ff50-ff5f : PCI Bus #02).
>
> Sou
On Mon, May 14, 2007 at 10:45:43AM -0700, Jesse Barnes wrote:
> Any update on this, Ivan? Maybe I missed your post, but I haven't seen
> anything yet...
No, I didn't post anything, sorry. This turned out to be not as trivial
as I thought - I've played with that code on amd64, and results were ra
On Fri, May 11, 2007 at 12:13:52PM -0700, Andrew Morton wrote:
> I've assumed that all three patches are from Jay. Correct?
Yes.
> The way we signify this is to put a From: right at the top of the changelog.
I'll keep this in mind, thanks.
Ivan.
-
To unsubscribe from this list: send the line "
64, and
we've never supported 48-bit KSEG.
2. include/asm-alpha/core_wildfire.h
fix a typo that undoubtedly prevents WILDFIRE support
from working
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
diff -Naurp a/arch/alpha/Kconfig b/arch/alpha/Kconfig
--- a/arch/al
d
directly, rather than always through the ioreadNN/iowriteNN routines.
Examples of the direct calls, via the __raw_readX/writeX macros, are
the memcpy_fromio/toio, _memset_c_io, and scr_memcpyw routines.
Signed-off-by: Jay Estabrook <[EMAIL PROTECTED]>
Signed-off-by: Ivan Kokshaysky <[EMAIL
es for
detecting and translating "legacy" VGA register and memory references to
the real PCI domain.
Signed-off-by: Jay Estabrook <[EMAIL PROTECTED]>
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
diff -Naurp a/arch/alpha/Kconfig c/arch/alpha/Kconfig
--- a/arch/alpha/
On Thu, May 03, 2007 at 10:41:41AM +0200, Wolfgang Erig wrote:
> I am prepared to do tweaks to your small patch, but I need your help.
> My own blindly experiments failed miserably.
I don't think that patch did anything wrong, most likely it just
triggered a bug elsewhere. These two lines from you
On Wed, May 02, 2007 at 04:47:16PM +0200, Wolfgang Erig wrote:
> On Tue, May 01, 2007 at 12:01:56PM -0400, Chuck Ebbert wrote:
> > Output from kernel with CONFIG_PCI_DEBUG could be useful.
> >
> Linux version 2.6.21-gde46c337 ([EMAIL PROTECTED]) (gcc version 4.1.2
> 20061115 (prerelease) (Debian
On Fri, Apr 20, 2007 at 11:28:42AM -0700, Linus Torvalds wrote:
> Actually, I would suggest we not do it automatically (because the need for
> it is just so low, and the downsides are potentially huge - there are just
> too many resources that are "hidden" from us through ACPI tricks and
> havin
On Thu, Apr 19, 2007 at 05:19:20PM -0700, Linus Torvalds wrote:
> I think we used to *never* assign PCI bus resources on x86, but that thing
> got fixed some time ago. Now I think we only re-assign them if they were
> unassigned *or* if the assignment wasn't working before. But I'm not 100%
> su
On Sun, Apr 15, 2007 at 11:01:15AM +0200, Sam Ravnborg wrote:
> > + if (pci_vga_hose && __is_mem_vga(addr)) {
> > h = pci_vga_hose->index;
>
> This code snippet is used in two places.
> A better approach would be to define a small inline function
> that is empty in the NON HOSe case
use in managing access to the device.
Various adjustments are made to the ioremap and ioportmap routines for
detecting and translating "legacy" VGA register and memory references to
the real PCI domain.
Signed-off-by: Jay Estabrook <[EMAIL PROTECTED]>
Signed-off-by: Ivan Kokshaysky
On Fri, Apr 13, 2007 at 12:05:03PM -0700, Andrew Morton wrote:
> alpha-fix-bootp-image-creation.patch
> alpha-prctl-macros.patch
> alpha-fixes-for-specific-machine-types.patch
> alpha-more-fixes-for-specific-machine-types.patch
> alpha-build-fixes-force-architecture.patch
>
> Which of these do you
[CIX stuff reworked, .got change dropped as Richard suggested]
Override compiler .arch directive for generic kernel build.
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
--- linux.orig/arch/alpha/kernel/sys_titan.cThu Apr 12 01:19:47 2007
+++ linux/arch/alpha/kernel/sys_titan.c T
On Wed, Apr 11, 2007 at 01:32:19PM -0400, Jay Estabrook wrote:
> Yes, it does leak, and yes, it should be kmalloced. Something like this?
>
> struct resource *new_vga;
>
> new_vga = kmalloc(sizeof(struct resource), GFP_ATOMIC);
> if (new_vga) {
> *new_vga = alp
On Wed, Apr 11, 2007 at 07:31:10PM +1000, Dave Airlie wrote:
> I already have this queued in the DRM git tree.. Ivan, Jay can you
> check an -mm kernel contains it? it'll go in the next merge window..
Indeed, it's already in -mm tree. Sorry...
Ivan.
-
To unsubscribe from this list: send the line
"got" messages.
Signed-off-by: Jay Estabrook <[EMAIL PROTECTED]>
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
---
diff -Naurp a/arch/alpha/kernel/sys_titan.c b/arch/alpha/kernel/sys_titan.c
--- a/arch/alpha/kernel/sys_titan.c 2007-02-04 13:44:54.0 -0500
+++ b/ar
detecting and translating "legacy" VGA register and memory references to
the real PCI domain.
Signed-off-by: Jay Estabrook <[EMAIL PROTECTED]>
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
---
diff -Naurp a/arch/alpha/Kconfig b/arch/alpha/Kconfig
--- a/arch/alpha
Supply the "isa_virt_to_bus" routine.
Signed-off-by: Jay Estabrook <[EMAIL PROTECTED]>
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
---
diff -Naurp a/arch/alpha/kernel/core_mcpcia.c b/arch/alpha/kernel/core_mcpcia.c
--- a/arch/alpha/kernel/core_mcpcia.c 2007-02-04 13
arch/alpha/kernel/sys_sx164.c
Earlier firmware revisions need MVI fix as well.
arch/alpha/kernel/sys_nautilus.c
On UP1500 firmware reports wrong AGP IRQ (10 instead of 5).
This causes interrupt storm if there is a PCI device that
uses IRQ 5.
Signed-off-by: Ivan
Files:
drivers/char/drm/drmP.h
The PCI domain is the hose's index, not the hose's root bus number.
Note that this code only applies to ALPHA.
Signed-off-by: Jay Estabrook <[EMAIL PROTECTED]>
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
---
diff -Na
Files:
include/asm-alpha/thread_info.h
Provide "prctl" macros for ALPHA.
Signed-off-by: Jay Estabrook <[EMAIL PROTECTED]>
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
---
diff -Naurp a/include/asm-alpha/thread_info.h b/include/asm-alpha/thread_info.h
-
Files:
arch/alpha/boot/bootpz.c
Create a dummy "__kmalloc()" to satisfy the loader; never called.
arch/alpha/boot/tools/objstrip.c
Remove an include that is now (2.6.x) unnecessary.
Signed-off-by: Jay Estabrook <[EMAIL PROTECTED]>
Signed-off-by: Ivan Ko
Assorted fixes and cleanups, including build fixes for recent toolchains,
various platform-specific fixes and graphics support for non-zero PCI
domains.
Thanks to Jay Estabrook for supplying most of these.
Ivan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Mon, Dec 11, 2006 at 02:47:55PM +1100, Benjamin Herrenschmidt wrote:
> So at first, an unassigned resource has the IORESOURCE_UNSET flag set
> (or is supposed to). pci_assign_resource() itself will clear that flag
> if it succeeds.
>
> However, pretty much nothing else checks that flag, so it's
On Thu, Dec 07, 2006 at 08:31:08PM +1100, Nick Piggin wrote:
> It might be reasonable to implement this watered down version, but:
> don't some architectures have restrictions on what instructions can
> be issued between the ll and the sc?
Yes. On Alpha you cannot execute other load/stores, taken
On Wed, Dec 06, 2006 at 10:38:48AM +, Alan wrote:
> VIA south gets used by a lot of the systems but the VIA North bridges
> I've got docs for cover only x86 variants, although one of the older ones
> implies it has both K7 and Alpha support (just as the AMD chipset does)
VIA chips (even southb
On Sat, Sep 03, 2005 at 02:45:08AM +0200, Andreas Koch wrote:
> crucial part seem to be the different bridge initialization sections:
Indeed.
> 2.6.12-rc6 + Ivan's patches:
...
> PCI: Bus 7, cardbus bridge: :06:09.0
> IO window: 6000-6fff
> IO window:
Sorry, I've been on vacation, so I missed quite a few interesting
things that went into 2.6.13 (particularly the change for ROM resource
assignment, which looks excellent).
On the other hand, I had some time to think about PCI assign issues
in 2.6.13-rc series.
The major problem here is that we ca
On Thu, Aug 11, 2005 at 03:35:02PM +0100, Sanjoy Mahajan wrote:
> Right, it is fixed.
Maybe Greg didn't know that - if so, I don't think this
test is necessary.
Ivan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More major
, as reported by
Mikael Pettersson <[EMAIL PROTECTED]>.
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
--- 2.6.13-rc6/drivers/pci/quirks.c Sun Aug 7 12:07:40 2005
+++ linux/drivers/pci/quirks.c Sun Aug 7 14:37:14 2005
@@ -373,6 +373,25 @@ static void __devinit quirk_
On Fri, Aug 05, 2005 at 09:33:54PM -0700, Grant Grundler wrote:
> > ISTR making comments before about the offending patch on linux-pci mailing
> > list. Is this the same patch that assumes pci_dev->resource[i] == BAR[i] ?
>
> I meant the patch assume 1:1 for pci_dev->resource[i] and BAR[i].
> not
We have increased PCIBIOS_MIN_IO to 0x4000, but still want
motherboard resources to be allocated properly. So we need
to state 0x1000 (according to the comment) limit explicitely.
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
--- 2.5.13-rc5/drivers/acpi/motherboard.c Fri Jun 17
o prevent any new PCI resource allocations
in the problematic range (this limitation must apply _only_ to the
root bus resources - see Linus' change in pci_bus_alloc_resource).
As PCIBIOS_MIN_IO and PCIBIOS_MIN_CARDBUS_IO are the same now on i386
and x86-64, we can remove the latter.
Signed-off-b
On Tue, Aug 02, 2005 at 02:21:44PM -0700, Greg KH wrote:
> Nice, care to make up a single patch with these two changes in it?
Yep, I'll do it shortly, plus some minor additions as separate
patches.
Ivan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
On Tue, Aug 02, 2005 at 10:11:40AM -0700, Linus Torvalds wrote:
> So I think it would be much easier to just make the change in
> "pci_bus_alloc_resource()", and say that if the parent resource that we're
> testing starts at some non-zero value, we just use that instead of "min"
> when we call do
On Tue, Aug 02, 2005 at 08:48:21AM -0700, Linus Torvalds wrote:
> The problem with this is that it only papers over the bug.
>
> I don't mind trying to allocate at higher addresses per se: we used to
> have the starting point be 0x4000 at some point, and that part is fine.
> The problem is that
1 - 100 of 201 matches
Mail list logo
