I think with the new vmap changes that went in in -pre7 means
you will need to get a new drm module (like from X cvs or
http://dri.sourceforge.net/downloads.phtml) and recompile it
with the new kernel headers which will then pick up the define
-DVMAP_4_ARGS in the Makefile and give you a good module that works.
The DRI kernel trees need updating.
Can you download from the link above and cd to drm and do a
make -f Makefile.linux radeon.o
and report please if that works for you without crashing glx* ?
Mitch
-------- Original Message --------
Subject: Re: Linux 2.4.22-pre10-ac1 DRI doesn't work with
Date: Tue, 5 Aug 2003 14:36:49 -0600
From: Erik Andersen <andersen:codepoet:org>
Reply-To: andersen:codepoet:org
To: [email protected]
CC: [email protected]
References: <[email protected]>
On Tue Aug 05, 2003 at 08:37:38PM +0100, [email protected] wrote:
>
> Works fine with XFree86 4.3.x, 2.4.22-pre10 and the radeon.o
> drm module. If you look backwards in your strace file, what is the
> device that file descriptor 5 belongs to ?
I have XFree86 4.2.1 (i.e. xfree86-common, xserver-xfree86,
xlibmesa3-gl, etc) version 4.2.1-9 from Debian unstable installed.
I think you mean file descriptor 4:
open("/dev/dri/card0", O_RDWR) = 4
$ ls -la /dev/dri/card0
crw-rw-rw- 1 root root 226, 0 Jul 12 04:21 /dev/dri/card0
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
On Mer, 2003-08-06 at 15:38, [email protected] wrote:
> I think with the new vmap changes that went in in -pre7 means
> you will need to get a new drm module (like from X cvs or
> http://dri.sourceforge.net/downloads.phtml) and recompile it
> with the new kernel headers which will then pick up the define
> -DVMAP_4_ARGS in the Makefile and give you a good module that works.
>
> The DRI kernel trees need updating.
That doesn't seem a 2.4.22 candidate thing to me. If vmap broke the DRI
then the vmap patch wants reverting for 2.4.22 IMHO, and looking at for
2.4.23.
On 7 Aug 2003, Alan Cox wrote:
> On Mer, 2003-08-06 at 15:38, [email protected] wrote:
> > I think with the new vmap changes that went in in -pre7 means
> > you will need to get a new drm module (like from X cvs or
> > http://dri.sourceforge.net/downloads.phtml) and recompile it
> > with the new kernel headers which will then pick up the define
> > -DVMAP_4_ARGS in the Makefile and give you a good module that works.
> >
> > The DRI kernel trees need updating.
>
> That doesn't seem a 2.4.22 candidate thing to me. If vmap broke the DRI
> then the vmap patch wants reverting for 2.4.22 IMHO, and looking at for
> 2.4.23.
I dont understand how the vmap change can break DRM.
The vmap patch only changes internal mm/vmalloc.c code (vmalloc() call
acts exactly the same way as before AFAICS).
Anyway, Mitch (or Erik who's seeing the problem), can please revert the
vmap() change to check if its causing the mentioned problem?
The patch is attached. Apply it with -R.
On Iau, 2003-08-07 at 15:26, Christoph Hellwig wrote:
> > Anyway, Mitch (or Erik who's seeing the problem), can please revert the
> > vmap() change to check if its causing the mentioned problem?
>
> vmap() doesn't break DRM. The external drm code just detects that
> vmap is present and then uses the new interface, but this new code
> also expects a new exported symbol.
>
> The DRM code in your tree is completly unaffected.
Cool. So its a non issue for people not using the XFree CVS
> I dont understand how the vmap change can break DRM.
>
> The vmap patch only changes internal mm/vmalloc.c code (vmalloc() call
> acts exactly the same way as before AFAICS).
>
> Anyway, Mitch (or Erik who's seeing the problem), can please revert the
> vmap() change to check if its causing the mentioned problem?
vmap() doesn't break DRM. The external drm code just detects that
vmap is present and then uses the new interface, but this new code
also expects a new exported symbol.
The DRM code in your tree is completly unaffected.
On Thu, 7 Aug 2003, Christoph Hellwig wrote:
> > I dont understand how the vmap change can break DRM.
> >
> > The vmap patch only changes internal mm/vmalloc.c code (vmalloc() call
> > acts exactly the same way as before AFAICS).
> >
> > Anyway, Mitch (or Erik who's seeing the problem), can please revert the
> > vmap() change to check if its causing the mentioned problem?
>
> vmap() doesn't break DRM. The external drm code just detects that
> vmap is present and then uses the new interface, but this new code
> also expects a new exported symbol.
And which symbol is that?
> The DRM code in your tree is completly unaffected.
Fine.
On Thu, Aug 07, 2003 at 11:47:53AM -0300, Marcelo Tosatti wrote:
> > vmap() doesn't break DRM. The external drm code just detects that
> > vmap is present and then uses the new interface, but this new code
> > also expects a new exported symbol.
>
> And which symbol is that?
Ask the DRI folks. They posted a patch on lkml a few days ago.
So now that 2.6.0-test2 runs on a 386EX/25 with 8MB of memory, and the CF
disk is working properly, I have a few observations regarding the change in
kernels, and the impact that I see.
These are not (necessarily) judgements, and the comparison may not be 100% on
equal footing, but nonetheless, they're what I see. If you have suggestions,
I'll be happy to try them. So, with abestos suite in standby mode:
Both kernels are very limited in what's compiled in. Basically, it's 386
optioned, with math emulation enabled, IDE for hard disk only, PPP with
compression, ethernet (but no drivers, just enough so that PPP works),
SYSVIPC, ext2 support, /proc support, serial console (serial.h has been
modified for 6 serial ports, 2 16450s (the 386EX native ports), and 2
external 16C752's (each channel on a dedicated interrupt).
The 2.2.12 version is compiled with GCC 2.91.66, the 2.6.0-test2 version with
GCC 2.96.
Kernel 2.2.12 is a BlueCat variation, which has some minor tweaks to reduce
the footprint, modifications to remove real-time clock support, and the
CLOCK_TICK_RATE changed from 1193180 to 1000000. The 2.6.0-test2 kernel has
similiar modifications, implemented as much as possible in the mach-
directories. 2.2.12 also has support for an AT1700 ethernet controller
(whose hardware is not present in the system, currently). 2.6.0-test2 is
build without this.
2.2.12 compiles out at 755712 bytes, which is uncompressed (we don't compress
the kernel because a 386EX/25 takes too long to uncompress). The values
reported by the kernel as it comes up are: 6884k/8192k availale (596k kernel
code, 416k reserved, 272k data, 24k init).
2.6.0-tests compiles out at 1163392 bytes (again, uncompressed, for the same
reason). The values reported by the kernel are: 6296k/8132k available (932k
kernel code, 1424k reserved, 239k data, 68k init, 0k highmem). The
CONFIG_EMBEDDED is set (admittedly, I haven't grepped the code to see what
all this variable impacts).
I'm sure the reserved value is something I'm failing to tune myself that's
been tweaked into the BlueCat distro. That's something I need to look into.
But 300K of code growth (33%!) for the same basic functionality strikes me
as... not good. Any thoughts on this issue?
For reasons unknown, whereas 2.2.12 picked up the values for how much memory
we have stuffed into a fake BIOS block, 2.6.0-test2 does not (nor did
2.5.69). I have to set a mem=7744k into the boot params. Anything more, and
I get kernel paging faults at startup. I'm unclear why this is, but since it
can be worked around at the moment, I can let it lay.
2.2.12 reports 3.49 Bogomips, 2.6.0-test2 reports varying values, depending
on what HZ is set to (more on this shortly). 4.14 for HZ=100, 8.19 for
HZ=1000. I realize that Bogomips are meaningless, and didn't at some point
the method for determining them change? I do find it odd that that the
rating should change by changing the HZ value, however.
Interactive performance is an atrocity with 2.6.0-test2. Something as simple
as backspacing though a command line can cause overrun errors. Whereas
before zmodeming a file down was not an issue with 2.2.12 (this, in fact, is
how software is applied to the CF card), it fails completely under
2.6.0-test2. In addition, I started getting 'serial8250: too much work for
irq4'. Granted, the console port is a 16450, which has no FIFO. But to go
to a newer kernel and get this error doesn't seem right. Perhaps there's
some performance tuning I'm missing, but I do know that it was not required
under 2.2.12, so I'm not sure why I would need to do that under 2.6.0-test2.
I have not run hdparm on the drives, but e2fsck coming up on a dirty
partition is amazingly slow on 2.6.0-test2. On a 32MB CF card with 25% usage
(about 300 files), it takes less than 10 seconds under 2.2.12. On
2.6.0-test2, I'm seeing on the order of 40+ seconds. Long enough, in fact,
that the watchdog that makes sure the system has booted into the application
is timing out and punting the system.
Any thoughts or things to look for would be greatly appreciated. I realize
that many people doing embedded work on small processors are using the older
kernels. I'd like to use a newer one, since the device driver interface is
so much cleaner, and I'd like to use a CF+WiFi card, which is not supported
in the older kernels.
I've posted the .config files, along with the System.map and kernel images to
http://tinymicros.com/linux. The final images are run through "objcopy -O
binary -R .note -R .comment -R .stab -R .stabstr vmlinux vmlinuz" to produce
the image that goes into the FLASH parts.
--John
"J.C. Wren" <[email protected]> wrote:
>
> Interactive performance is an atrocity with 2.6.0-test2. Something as simple
> as backspacing though a command line can cause overrun errors. Whereas
> before zmodeming a file down was not an issue with 2.2.12 (this, in fact, is
> how software is applied to the CF card), it fails completely under
> 2.6.0-test2.
It sounds like something is spinning in-kernel.
What do `free' and `cat /proc/meminfo' and `top' say?
The next step would be to generate a kernel profile.
Here's the output of the system coming up, and 'free' and 'cat /proc/meminfo'. Don't have a version of top currently compiled for it, but 'uptime' says 0.00 0.00 0.00 after it's sitting idle a bit.
Linux version 2.6.0-slimedr ([email protected]) (gcc version 2.96 20000731
(Red Hat Linux 7.3 2.96-113)) #31 Thu Aug 7 00:22:22 EDT 2003
Video mode to be used for restore is 3e0
BIOS-provided physical RAM map:
PROM: 0000000000000000 - 000000000009f000 (usable)
PROM: 0000000000100000 - 00000000040ffc00 (usable)
user-defined physical RAM map:
user: 0000000000000000 - 000000000009f000 (usable)
user: 0000000000100000 - 00000000007f1000 (usable)
7MB LOWMEM available.
On node 0 totalpages: 2033
DMA zone: 2033 pages, LIFO batch:1
Normal zone: 0 pages, LIFO batch:1
HighMem zone: 0 pages, LIFO batch:1
Building zonelist for node : 0
Kernel command line: root=/dev/hda1 hdb=none ide0=0x1f0,0x3f6,0x09 ide0=noautotune hda=notremovable console=ttyS0,57600 mem=7744k
ide_setup: hdb=none -- BAD OPTION
ide_setup: ide0=0x1f0,0x3f6,0x09
ide_setup: ide0=noautotune
ide_setup: hda=notremovable
Initializing CPU#0
PID hash table entries: 32 (order 5: 256 bytes)
Calibrating delay loop... 4.14 BogoMIPS
Memory: 6296k/8132k available (932k kernel code, 1424k reserved, 239k data, 68k
init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... No.
Dentry cache hash table entries: 1024 (order: 0, 4096 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
-> /dev
-> /dev/console
-> /root
CPU: 386
Checking 'hlt' instruction... OK.
Checking for popad bug... OK.
POSIX conformance testing by UNIFIX
Initializing RT netlink socket
BIO: pool of 256 setup, 14Kb (56 bytes/bio)
biovec pool[0]: 1 bvecs: 5 entries (12 bytes)
biovec pool[1]: 4 bvecs: 2 entries (48 bytes)
biovec pool[2]: 16 bvecs: 1 entries (192 bytes)
biovec pool[3]: 64 bvecs: 0 entries (768 bytes)
biovec pool[4]: 128 bvecs: 0 entries (1536 bytes)
biovec pool[5]: 256 bvecs: 0 entries (3072 bytes)
pty: 256 Unix98 ptys configured
Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16450
ttyS1 at I/O 0x2f8 (irq = 3) is a 16450
ttyS2 at I/O 0x300 (irq = 12) is a ST16654
ttyS3 at I/O 0x310 (irq = 14) is a ST16654
ttyS4 at I/O 0x320 (irq = 5) is a ST16654
ttyS5 at I/O 0x330 (irq = 6) is a ST16654
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
hda: 32MB CTS, ATA DISK drive
Using anticipatory scheduling elevator
ide0 at 0x1f0-0x1f7,0x3f6 on irq 9
hda: max request size: 128KiB
hda: 64000 sectors (33 MB) w/4KiB Cache, CHS=500/4/32
hda: hda1
NET4: Linux TCP/IP 1.0 for NET4.0
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 512 bind 512)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 68k freed
bash# free
total used free shared buffers cached
Mem: 6388 3252 3136 0 260 1960
-/+ buffers/cache: 1032 5356
Swap: 0 0 0
bash# cat /proc/meminfo
MemTotal: 6388 kB
MemFree: 3148 kB
Buffers: 260 kB
Cached: 1972 kB
SwapCached: 0 kB
Active: 1728 kB
Inactive: 816 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 6388 kB
LowFree: 3148 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 32 kB
Writeback: 0 kB
Mapped: 1120 kB
Slab: 552 kB
Committed_AS: 4052 kB
PageTables: 48 kB
VmallocTotal: 1032168 kB
VmallocUsed: 0 kB
VmallocChunk: 1032168 kB
bash#
--John
On Thursday 07 August 2003 13:34 pm, Andrew Morton wrote:
> "J.C. Wren" <[email protected]> wrote:
> > Interactive performance is an atrocity with 2.6.0-test2. Something as
> > simple as backspacing though a command line can cause overrun errors.
> > Whereas before zmodeming a file down was not an issue with 2.2.12 (this,
> > in fact, is how software is applied to the CF card), it fails completely
> > under 2.6.0-test2.
>
> It sounds like something is spinning in-kernel.
>
> What do `free' and `cat /proc/meminfo' and `top' say?
>
> The next step would be to generate a kernel profile.
On Thu Aug 07, 2003 at 10:27:03AM -0300, Marcelo Tosatti wrote:
> > That doesn't seem a 2.4.22 candidate thing to me. If vmap broke the DRI
> > then the vmap patch wants reverting for 2.4.22 IMHO, and looking at for
> > 2.4.23.
>
> I dont understand how the vmap change can break DRM.
>
> The vmap patch only changes internal mm/vmalloc.c code (vmalloc() call
> acts exactly the same way as before AFAICS).
>
> Anyway, Mitch (or Erik who's seeing the problem), can please revert the
> vmap() change to check if its causing the mentioned problem?
>
> The patch is attached. Apply it with -R.
Reverting this patch has no effect on the problem....
$ glxgears
Illegal instruction
same as before,
As a guess, the "Unknown" in the drm detection below could
be related to my problem.... As could the fact I have 2 GB
ram installed. Or the fact I'm running SMP. dunno.
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 1919M
agpgart: Detected Intel(R) 865G chipset
agpgart: AGP aperture is 64M @ 0xf8000000
[----------snip-----------]
[drm] AGP 0.99 on Unknown @ 0xf8000000 64MB
[drm] Initialized radeon 1.1.1 20010405 on minor 0
00:01.0 PCI bridge: Intel Corp. 82865G/PE/P Processor to AGP Controller (rev 02) (prog-if 00 [Normal decode])
Flags: bus master, 66Mhz, fast devsel, latency 64
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: fe800000-fe8fffff
Prefetchable memory behind bridge: e7e00000-f7dfffff
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA])
Subsystem: PC Partner Limited RV100 QY [Sapphire Radeon VE 7000]
Flags: bus master, stepping, 66Mhz, medium devsel, latency 64, IRQ 16
Memory at e8000000 (32-bit, prefetchable) [size=128M]
I/O ports at c000 [size=256]
Memory at fe8f0000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at fe8c0000 [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
On Iau, 2003-08-07 at 18:23, J.C. Wren wrote:
> For reasons unknown, whereas 2.2.12 picked up the values for how much memory
> we have stuffed into a fake BIOS block, 2.6.0-test2 does not (nor did
> 2.5.69). I have to set a mem=7744k into the boot params. Anything more, and
> I get kernel paging faults at startup. I'm unclear why this is, but since it
> can be worked around at the moment, I can let it lay.
2.5.x/2.6 (and 2.4) use E820 memory sizing before E801 and earlier
systems. Make sure your E820 tables are right I guess.
> I have not run hdparm on the drives, but e2fsck coming up on a dirty
> partition is amazingly slow on 2.6.0-test2. On a 32MB CF card with 25% usage
> (about 300 files), it takes less than 10 seconds under 2.2.12. On
> 2.6.0-test2, I'm seeing on the order of 40+ seconds. Long enough, in fact,
> that the watchdog that makes sure the system has booted into the application
> is timing out and punting the system.
You bluecat probably sets umask by default if its designed to keep
latency low. So hdparm -u1 /dev/hda first.