On Wed, Jan 24, 2001 at 08:23:13AM -0500, Peter Rival wrote:
Yeah, I've been bitten by this quite often. Basically, just edit
arch/alpha/kernel/Makefile and remove irq_pyxis.c from the obj-y
line. I'm not positive what systems require it exactly, but rawhide isn't one of
them. I have a
On Wed, Jan 24, 2001 at 08:34:51PM -0800, Greg from Systems wrote:
calypso 47# uname -a
Linux calypso 2.4.0 #6 SMP Wed Jan 24 20:00:01 PST 2001 alpha unknown
^
...
I used the patch at the bottom of this except for the part that patches:
linux/include/asm-alpha/unistd.h
The most interesting thing here is the pyxis tbia fix.
Whee! I can now copy files from SCSI to bus-master IDE, or
between two IDE drives on separate channels, or do other nice
things without hanging lx/sx164. :-)
The pyxis tbia turned out to be broken in a more nastier way
than one could expect -
On Fri, May 18, 2001 at 10:34:36PM -0400, Tom Vier wrote:
hose-sg_pci = iommu_arena_new(hose, 0xc000, 0x0800, 32768);
*(vip)CIA_IOC_PCI_W3_BASE = 0xc000 | 1;
*(vip)CIA_IOC_PCI_W3_MASK = (0x0800 - 1) 0xfff0;
*(vip)CIA_IOC_PCI_T3_BASE = 0x8000
On Sat, May 19, 2001 at 03:55:02PM +0200, Andrea Arcangeli wrote:
Reading the tsunami specs I learnt 1 tlb entry caches 8 pagetables (not 1)
so the tlb flush will be invalidate immediatly by any PCI DMA run after
the flush on any of the other 7 mappings cached in the same tlb entry.
I have
On Sat, May 19, 2001 at 06:11:27PM -0700, Richard Henderson wrote:
I'd rather keep this around. It should be possible to use on CIA2.
Ok. What do you think about reorg like this:
basically leave the old code as is, and add
if (is_pyxis)
alpha_mv.mv_pci_tbi =
On Sun, May 20, 2001 at 04:40:13AM +0200, Andrea Arcangeli wrote:
I was only talking about when you get the pci_map_sg failed because
you have not 3 but 300 scsi disks connected to your system and you are
writing to all them at the same time allocating zillons of pte, and one
of your drivers
On Mon, May 21, 2001 at 06:55:29AM -0700, Jonathan Lundell wrote:
8 slots (and you're right, 6 is a practical upper limit, fewer for
66 MHz) *per bus*. Buses can proliferate like crazy, so the slot
limit becomes largely irrelevant.
True, but the bandwidth limit is highly relevant. That's
On Mon, May 21, 2001 at 01:19:59PM +0200, Andrea Arcangeli wrote:
Alpha in mainline is just screwedup if a single pci bus tries to dynamic
map more than 128mbyte, changing it to 512mbyte is trivial, growing more
Could you just describe the configuration where increasing sg window
from 128 to
On Tue, May 22, 2001 at 04:29:16PM +0200, Andrea Arcangeli wrote:
Ivan could you test the above fix on the platforms that needs the
align_entry hack?
That was one of the first things I noticed, and I've tried exactly
that (2 instead of ~1UL).
No, it wasn't the cause of the crashes on pyxis, so
On Fri, Sep 08, 2000 at 04:19:25AM -0400, Christopher C. Chimelis wrote:
xor.c: In function `xor_block_alpha':
xor.c:1791: inconsistent operand constraints in an `asm'
xor.c: In function `xor_block_alpha_prefetch':
xor.c:2213: inconsistent operand constraints in an `asm'
Yes, I can
On Sat, Sep 09, 2000 at 12:50:38AM +1100, Anton Blanchard wrote:
Yeah on most architectures you cant do an xchg of a 16 bit quantity.
Rusty has a patch:
...
FWIW, here are __xchg_u8 and __xchg_u16 for Alpha.
Ivan.
--- 2.4.0t8p6/include/asm-alpha/system.hThu Sep 7 19:01:46 2000
+++
Following problems fixed here:
- barrier() undefined for UP kernel
- file locking #defines update
- remove addressless weak symbols ("w")
from System.map (depmod -F breaks on these)
Ivan.
diff -urp 2.4.0t9p7/Makefile linux/Makefile
--- 2.4.0t9p7/Makefile Tue Sep 26 12:13:02 2000
+++
On Fri, Sep 29, 2000 at 04:59:46PM +1100, Stephen Rothwell wrote:
This part was missing from the leases directory notification
patch that was applied to 2.4.0-test9pre5. Please apply.
I've sent more complete patch (fixes also UP build)
couple of days ago.
Ivan.
-
To unsubscribe from this
On Mon, Oct 02, 2000 at 09:24:58AM -0500, Jeff Garzik wrote:
If this change broke your DMA enabling, I think there are other bugs
lurking in the code...
This change also broke CMD646 IDE on alpha lx164.
CMD646: IDE controller on PCI bus 00 dev 58
CMD646: chipset revision 1
CMD646: chipset
On Mon, Oct 02, 2000 at 11:36:03PM -0400, Jay Estabrook wrote:
As suggested days ago by Ivan, one solution is:
-
diff -urN old/include/asm-alpha/bitops.h new/include/asm-alpha/bitops.h
---
On Thu, Oct 12, 2000 at 01:18:53PM -0700, Linus Torvalds wrote:
See the arch/x86/mm/fault.c changes to see what arch-specific changes this
can entail.
This patch works for me...
Ivan.
--- linux/include/asm-alpha/bitops.h.orig Wed Oct 4 17:06:59 2000
+++
On Fri, Oct 13, 2000 at 09:54:14AM -0700, Richard Henderson wrote:
You shouldn't have needed any changes at all to work.
But without that change I've got oopses (fortunately not fatal)
in swapon and modprobe.
The synchronization we already do for the vptb also
takes care of vmalloc.
On Wed, Oct 18, 2000 at 03:46:45PM -0700, Linus Torvalds wrote:
Ok, more of the "lots of small fixes" patches. The most notable of which
is probably the atomic PTE patches by Ben LaHaise, which fixes the
long-standing lost dirty bits problem under SMP, and also cleans up some
of the ia32 PAE
uni16_to_x8() loads unaligned u16 words, returning bogus file names
on an ev5 and older alpha CPUs...
Ivan.
--- 2.4.2-ac4/fs/isofs/joliet.c Fri Feb 9 22:29:44 2001
+++ linux/fs/isofs/joliet.c Mon Feb 26 17:06:54 2001
@@ -10,6 +10,7 @@
#include linux/nls.h
#include linux/slab.h
#include
On Fri, Mar 02, 2001 at 11:32:35AM -0800, Grant Grundler wrote:
Code in parisc-linux CVS (based on 2.4.0) does boot on my OB800
(133Mhz Pentium), C3000, and A500 with PCI-PCI bridge support
working. I'm quite certain PCI-PCI bridge configuration (ie BIOS
didn't configure the bridge) support
On Mon, Mar 05, 2001 at 02:16:05PM -0800, Grant Grundler wrote:
I believe it isn't. ;-) It works on various alphas including
configurations with chained PCI-PCI bridges.
Ok. I overlooked the changes in arch/alpha/kernel/pci.c:pcibios_fixup_bus().
(As you know, things changed alot between
On Tue, Mar 06, 2001 at 12:57:00PM -0800, Grant Grundler wrote:
My A500 console is a "regular" PCI serial device.
[ I use quotes because linux sees the device as a 16550.
But I'm told it's fully emulated in firmware on a special card called
the "GSP" (Guardian Service Processor). ]
Ok.
Surprisingly, it works on lx164. :-)
Ivan.
On Mon, Mar 19, 2001 at 06:46:17PM -0800, Linus Torvalds wrote:
This has only been tested on i386 without PAE, and is known to break other
architectures. Ingo, mind checking what PAE needs? Generally, the changes
are simple, and really only implies
Two issues preventing ruffians from booting 2.4 (with bridges patch)
were found and fixed.
- rather trivial one: someone decided that interrupt 4
(irq 20 from builtin scsi) is 'bogus' ;-)
- another issue is way not trivial and cost Michal and me a
lot of sweat. Type 1 PCI configuration
Some not critical changes, and a bit more testing was done
(on ux164 - including card with an extra bridge, thanks to Michal).
Changes from bridges-2.4.0t11-rth:
- Disable devices before changing BARs
- Handle bridges not supporting IO forwarding
- Handle bridges with their own IO ports
Just out of curiosity I tried S3 Sonic Vibes sound card, which has
only 24 address lines connected, on sx164. This revealed two bugs
in the pci code:
- dma mask 0x00ff (24 bits) exactly fits the ISA scatter-gather
window, but was rejected by pci_dma_supported() due to off-by-one bug.
-
On Tue, Nov 28, 2000 at 09:30:03PM -0500, Wakko Warner wrote:
Doesn't boot on noritake alpha.
It gets to POSIX conformance testing by UNIFIX
and hard locks. the halt switch doesn't even work.
The video card on that system turned out to have pci class
PCI_CLASS_NOT_DEFINED_VGA instead of
On Thu, Nov 30, 2000 at 03:02:42PM -0500, Phillip Ezolt wrote:
Qlogic SCSI support seems broken on 2.4.0-test11 on a Miata (Digital Personal
WorkStation 600au).
When starting up, we get a machine check after initialing the qlogic SCSI code.
Try test12-pre3 - there is the new PCI init
On Thu, Nov 30, 2000 at 11:37:42PM +0100, Andrea Arcangeli wrote:
test12-pre2 crashes at boot on my DS20. This patch workaround the problem
but I would be _very_ surprised if this is the right fix :) It's obviously not
meant for inclusion.
...
- struct resource_list *ln =
On Fri, Dec 01, 2000 at 02:56:43PM -0500, Phillip Ezolt wrote:
What data structure's would I look at? What should I investigate to
verify this?
In the arch/alpha/kernel/pci_iommu.c change
#define DEBUG_ALLOC 0
to
#define DEBUG_ALLOC 2
Perhaps this will give us more info.
At the first look
On Tue, Dec 05, 2000 at 07:55:58AM -0600, [EMAIL PROTECTED] wrote:
In -test11, tmp was declared. Somehow by 12-pre4, it got lost. This puts
it back. It's needed in the BITS_PER_LONG == 64 case.
BITS_PER_LONG == 64 case is broken anyway.
Better fix would be
--- linux/drivers/pci/pci.c.orig
This should fix at least some of the boot problems reported recently.
- boot failure on Miata with 1Gb of memory, fixed by Jay Estabrook.
Address written to the Translated Base Registers of CIA/Pyxis
must be shifted by 2.
- fix oops on DP264 caused by Cypress quirk. We cannot call
On Thu, Dec 07, 2000 at 10:46:08PM +, Russell King wrote:
It appears to be caused by the pci_read_bridge_bases code copying the
pointer to the resources instead of making a copy of the resources
themselves.
No, pci_read_bridge_bases() is obsoleted by new pci setup code. ;-)
You have to
On Fri, Dec 08, 2000 at 03:31:08PM +0100, Benjamin Herrenschmidt wrote:
The problem I have (and this is why I don't setup host resources
properly on multi-host PPCs yet) is that some hosts can have several
non-contiguous ranges (especially with memory, IO is usually a single
contiguous
On Sat, Dec 09, 2000 at 11:38:05AM +, Russell King wrote:
[EMAIL PROTECTED] writes:
2. Why is pdev_device_enable no longer used ?
Right question would be "why is it not used yet?" ;-)
This routine appeared a while ago in one of test12-pre.
It is used from
On Sat, Dec 09, 2000 at 12:53:46PM +, Alan Cox wrote:
If there is surely the driver can override it again before enabling the
master bit or talking to the device ?
It could be done in PCI_FIXUP_FINAL quirks.
Ivan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Wed, Dec 20, 2000 at 10:03:42PM +0300, Alexander Zarochentcev wrote:
New (since test12) optimized memmove function seems to be broken
on alpha platform.
Indeed it is.
If dest and src arguments are misaligned, new memmove does wrong things.
Actually it broke when dest src. Incrementing
On Wed, Oct 25, 2000 at 05:59:39PM -0400, Jeff Garzik wrote:
It may work, but the bridge secondary/subordinate numbers look wrong.
No, these numbers look correct for me. Read comment in drivers/pci/pci.c:
if (!is_cardbus) {
/* Now we can scan all subordinate buses... */
On Wed, Nov 08, 2000 at 01:39:31AM -0800, Richard Henderson wrote:
* Replace cropped found_vga detection code.
I wonder where could I lose this, it was in place initially :-)
+ /* ??? How to turn off a bus from responding to, say, I/O at
+all if there are no I/O ports behind
On Wed, Nov 08, 2000 at 09:37:44AM -0800, Richard Henderson wrote:
Interesting. I hadn't known that. It didn't actually fail with
the ALI bridge, I just assumed it was a mistake. Can anyone with
docs on non-DEC bridges confirm that this is a common thing?
It would be better if someone who
On Wed, Nov 08, 2000 at 03:48:11PM -0800, Richard Henderson wrote:
Whee! We're back in Bootsville.
Cool!
Meanwhile this base/limit stuff got confirmation :-)
Here is a patch against bridges-2.4.0t11-rth.
Ivan.
--- 2.4.0t11p1/drivers/pci/setup-bus.c Wed Nov 8 19:44:42 2000
+++
On Wed, Nov 08, 2000 at 05:43:54PM -0500, Jeff Garzik wrote:
I am still worried that the conditions which generate the following
message indicate a problem still exists. (this message exists w/out
your patch..)
Unknown bridge resource 0: assuming transparent
Well, I believe that transparent
On Thu, Nov 09, 2000 at 09:37:41PM +0100, Gerard Roudier wrote:
Hmmm...
The PCI spec. says that Limit registers define the top addresses
_inclusive_.
Correct.
The spec. does not seem to imagine that a Limit register lower than the
corresponding Base register will ever exist anywhere, in my
On Fri, Apr 20, 2001 at 08:50:38AM +0100, David Howells wrote:
There's also a missing "struct rw_semaphore;" declaration in linux/rwsem.h. It
needs to go in the gap below "#include linux/wait.h". Otherwise the
declarations for the contention handling functions will give warnings about
the
+
+/*
+ * Written by Ivan Kokshaysky [EMAIL PROTECTED], 2001.
+ * Based on asm-alpha/semaphore.h and asm-i386/rwsem.h
+ */
+
+#ifndef _LINUX_RWSEM_H
+#error please dont include asm/rwsem.h directly, use linux/rwsem.h instead
+#endif
+
+#ifdef __KERNEL__
+
+#include linux/list.h
+#include linux
On Thu, May 03, 2001 at 07:28:48PM +0200, Andrea Arcangeli wrote:
I'd love if you could port it on top of this one and to fix it so that
it can handle up to 2^32 sleepers and not only 2^16 like we have to do
on the 32bit archs to get good performance:
On Fri, May 04, 2001 at 10:22:53AM +0100, David Howells wrote:
Hello Ivan,
Hello David!
I don't know whether it will (a) compile, or (b) work... I don't have an alpha
to play with.
It looks ok at a first glance, I can try it today.
I also don't know the alpha function calling convention,
task_struct *tsk = current;
signed long count;
Ivan.
#ifndef _ALPHA_RWSEM_H
#define _ALPHA_RWSEM_H
/*
* Written by Ivan Kokshaysky [EMAIL PROTECTED], 2001.
* Based on asm-alpha/semaphore.h and asm-i386/rwsem.h
*/
#ifndef _LINUX_RWSEM_H
#error please dont include asm/rwsem.h directly, use
On Fri, May 04, 2001 at 04:33:59PM +0200, Andrea Arcangeli wrote:
the 2^16 limit is not a per-user limit it is a global one so the max
user process ulimit is irrelevant.
Only the number of pid and the max number of tasks supported by the
architecture is a relevant limit for this.
Thanks
On Fri, May 04, 2001 at 02:12:40PM -0700, Richard Henderson wrote:
- removed some mb's for non-SMP
This isn't correct. Either you need atomic updates or you don't.
If you don't, then you shouldn't be using ll/sc at all.
I don't think so. On a single CPU system we need atomic updates
to
On Fri, May 04, 2001 at 02:13:18PM -0700, Richard Henderson wrote:
Eh? Would you give me an example that isn't working properly?
Sure.
bar.c:
-
extern void rarely_executed_code(void);
static inline void foo_no_be(void)
{
int ret;
__asm__ __volatile__(nop\n: =r
If you do
(perhaps to coordinate with devices) then the barriers are required.
For IO space access mb's are required, but ll/sc are of no use, AFAIK.
Ugh. You are right, of course. I forgot that drivers are also using
atomic.h, and the intelligent device could be counted as another CPU
to
_ALPHA_RWSEM_H
+#define _ALPHA_RWSEM_H
+
+/*
+ * Written by Ivan Kokshaysky [EMAIL PROTECTED], 2001.
+ * Based on asm-alpha/semaphore.h and asm-i386/rwsem.h
+ */
+
+#ifndef _LINUX_RWSEM_H
+#error please dont include asm/rwsem.h directly, use linux/rwsem.h instead
+#endif
+
+#ifdef __KERNEL__
+
+#include linux
On Tue, Jun 05, 2001 at 05:11:01PM +0200, Maciej W. Rozycki wrote:
Iterating over memory areas twice is ugly.
Hmm, yes. However, your patch isn't pretty, too. You may check
the same area twice, and won't satisfy requested address TASK_UNMAPPED_BASE.
What do you think about following?
On Fri, Jun 08, 2001 at 06:08:46PM +0200, Maciej W. Rozycki wrote:
Still it has two loops...
Ok, here is a single loop version.
Ivan.
--- 2.4.5-ac11/mm/mmap.cFri Jun 8 15:59:35 2001
+++ linux/mm/mmap.c Sat Jun 9 12:50:05 2001
@@ -398,27 +398,37 @@ free_vma:
static inline
On Thu, Jun 07, 2001 at 08:28:04PM +0200, Maciej W. Rozycki wrote:
DU seems to map as low as possible, it would seem.
Yes, I've just checked, starting at 64K...
Maybe we could just
do the same for OSF/1 binaries by setting TASK_UNMAPPED_BASE
appropriately?
No. I've changed in
HAVE_PCI_REQ_REGIONS
--- 2.4.6/drivers/pci/setup-bus.c Sun May 20 04:43:06 2001
+++ linux/drivers/pci/setup-bus.c Thu Jun 14 14:12:12 2001
@@ -12,6 +12,12 @@
/*
* Nov 2000, Ivan Kokshaysky [EMAIL PROTECTED]
* PCI-PCI bridges cleanup, sorted resource allocation
+ *
+ * NOTE: during
On Fri, Jun 29, 2001 at 04:20:59PM +0400, Oleg I. Vdovikin wrote:
we've a bunch of UP2000/UP2000+ boards (similar to DP264) with 666MHz
EV67 Alphas (we're building large Alpha cluster). And we're regulary see
HWRPB cycle frequency bogus and the measured value for the speed in the
range of
On Thu, Jul 05, 2001 at 11:14:19AM +0400, Oleg I. Vdovikin wrote:
Richard, thanks. But please use calibrate_cc version which I've submited
as a patch - it gives more accuracy with maximum latch we can ever use and
With both variants even on a 166MHz CPU you'll get above 1e-7 precision,
On Fri, Jul 06, 2001 at 01:03:38PM +0400, Oleg I. Vdovikin wrote:
return ((long)cc * 100) / CALIBRATE_TIME;
truncates the result to the MHZ because of the '* 100' statement (cc
is an int value, so you just loose the precision).
No, this is ok. 'cc' is long here, and
On Wed, Feb 07, 2001 at 11:50:52AM -0800, Grant Grundler wrote:
Can you explain why pci_assign_unassigned_resources()
calls pdev_enable_device() for every PCI device instead
of having each PCI *driver* call pci_enable_device()
as part of driver initialization?
Mainly because there are
On Mon, Mar 26, 2001 at 07:34:26AM +0100, Alan Cox wrote:
Alpha has probably been broken by the pre8 merge.
Yep, but not too much. This "unbreaks" it.
Ivan.
--- 2.4.2-ac25/include/asm-alpha/pgalloc.h Mon Mar 26 17:59:22 2001
+++ linux/include/asm-alpha/pgalloc.h Mon Mar 26 19:58:19
Basically the same stuff as in -ac tree; added `mm_struct *mm' argument.
Ivan.
--- 2.4.3/include/asm-alpha/pgalloc.h Fri Mar 30 13:54:33 2001
+++ linux/include/asm-alpha/pgalloc.h Fri Mar 30 14:07:46 2001
@@ -241,6 +241,9 @@ extern struct pgtable_cache_struct {
#define pte_quicklist
On Thu, Apr 05, 2001 at 12:20:22PM -0600, Eric W. Biederman wrote:
The point is on the Alpha all ram is always cached, and i/o space is
completely uncached. You cannot do write-combing for video card
memory.
Incorrect. Alphas have write buffers - 6x32 bytes on ev5 and
4x64 on ev6, IIRC. So
On Fri, Apr 06, 2001 at 07:13:21PM +0200, Maciej W. Rozycki wrote:
You do. PCI-space registers are volatile and they may change depending
on what was written (or read) previously. A memory barrier before a PCI
read will ensure you get a value that is relevant to previous code
actions.
On Mon, Apr 09, 2001 at 12:02:54PM +0200, Maciej W. Rozycki wrote:
I think you need an mb here. To force sychronization with other CPUs.
Unless you know you are UP or there is no possibility another CPU may
access the relevant device.
Yes - in most cases you need synchronization at a higher
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%
sure
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
having
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 Kokshaysky [EMAIL PROTECTED
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
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
--- a/include/asm-alpha
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 -Naurp a/drivers/char/drm
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:44:54.0
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
.
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/arch/alpha/kernel/sys_titan.c
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/Kconfig2007-04-02 13:03:21.0
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
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 =
[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 Thu Apr 12
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 think
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 [EMAIL PROTECTED]
--- orig/arch
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 to avod
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 fallback code.
Signed-off-by: Ivan Kokshaysky [EMAIL PROTECTED]
---
arch/x86/pci/mmconfig-shared.c | 35
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.
0x10 is
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 some systems, but none of the facts we have so
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
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 worse.
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 which
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-kernel in
the body of a message
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 a
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
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, it
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
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, in a
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 not
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 but
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 insertions(+), 1
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
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
1 - 100 of 394 matches
Mail list logo
