Re: R200 PCI faster with TCL disabled.

2004-10-19 Thread Keith Whitwell
Jacek Rosik wrote:
Hi,
I was testing some apps on my PCI 9200. And I noticed that they run
terribly slow. But when i switched to wireframe mode the frame rate
seemed much better. This seemed strange. IIRC radeons are much faster in
rendering solid geometry than wireframe. So after a little thinking I
set R200_NO_TCL an run those apps again. Automagicaly they became about
4 times faster: ~20/~90 fps. Nice, a fallback which is faster than
normal path :). Any ideas?
It may be that TCL mode is pushing more stuff (more state, larger vertices) 
across the bus, which is an OK tradeoff on AGP, but a net loss on PCI.

Keith
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 1657] GLX/DRI failure on XOrg 6.8.0/1

2004-10-19 Thread bugzilla-daemon
Please do not reply to this email: if you want to comment on the bug, go to  
the URL shown below and enter yourcomments there.   
 
https://freedesktop.org/bugzilla/show_bug.cgi?id=1657
   




--- Additional Comments From [EMAIL PROTECTED]  2004-10-19 01:49 ---
Perhaps you could give me something to start with (Interface Doc of old
and new api, usesful links) to fix the ATI Rage driver.

Maybe sperate support for both, new and old api, could also be a
temporarely solution, although drivers supporting the new interface
would be the much better way. The old glx api could be frozen in it's deprecated
state seperately from the new api. 

However, most of the drivers are binary only.
For example, the only usable driver for VIA unichrome KM400 is the binary
one, since VIA doesn't offer the reg. description to the unichrome
project. Thus, the Unichrome project seems to look for a needle in a
haystack and is mostly busy with removing and reorganizing the early
stage source code, offered once by VIA. 
As you posted, the fglrx has same problems.

It seems the companies will prefer to distribute closed source drivers
for the next (long) time. So a hybrid solution could be the fastest way
for users (except NVidia users), although it would result in redundancy. Anyway,
3D cards could by used independent from the will of the closed source driver
developers, since companies like ati develop their linux driver with very low
priority. Even lesser priority has the compatibility with XOrg.
   
   
-- 
Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email   
   
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Stereo support for radeons.

2004-10-19 Thread Jacek Rosik
Hi!

Here is my work on adding stereo support for radeon. It consists of
patches against drm (as of 2004/10/04) , mesa (as of 6.2 release) and
xorg (as of 6.8.1 release). Note that 'linux-core' drm version is
untested as it doesn't work with my pci r200, and i don't have an agp
card currently.

Everything is also in my subversion repository:
http://serce.ics.p.lodz.pl/svn/people/jrosik/dri-jpr/trunk

This work is not complete, but it's quite usable. Things not working are
rare situations or not worth the work required (at least in my opinion).
These things are:

* Inidrect rendering - Problem is with writing anything into front right
buffer. I thought about faking offscreen pixmap which lies in front
right buffer. I even hat, some semiworking implementation, what was
missing was tracking window cliprects.

* Rendering into fronbuffer - This only happens when app renders into
non stereo visual (front buffer) and there is app having stereo visual.
This is rather rare situation, so I don't think its very important.

Also Vladimir Dergachev pointed out that there are some stereo scpecific
registers on radeons. I haven't found such thing in radeon_regs.h. He
promised to provied some info later, so I'll probably review my changes.
But current method is quite generic, and can be implemented for all
cards supporting pagfliping (at least I think so).

Please review those patches and let me know what You think abut them. 

best,
-- 
Jacek Rosik [EMAIL PROTECTED]


radeon-stereo.diff.tar.gz
Description: application/compressed-tar


Re: Radeon 9600 with radeon DRM module

2004-10-19 Thread Nicolai Haehnle
On Monday 18 October 2004 16:04, Tino Keitel wrote:
 On Mon, Oct 18, 2004 at 09:13:57 +0200, Tino Keitel wrote:
 
 [...]
 
  Thanks again. Looks like I used the wrong 2d driver patch before
  (xorg680.atipatch.r300). Now the glxinfo output looks right:
  
  OpenGL renderer string: Mesa DRI R300 20040924 AGP 4x NO-TCL
  
  However, glxgears only prints out this messages and exits:
  
  disabling 3D acceleration
  drmCommandWrite: -22

You're probably using the main-kernel or DRI version of the DRM. You need 
the DRM from r300_driver/drm, because only that version of the DRM 
implements the new ioctls.

 Hm, this looks funny (from r300_context.c):
 
 if (1 ||
 driQueryOptionb(r300-radeon.optionCache, no_rast)) {
 fprintf(stderr, disabling 3D acceleration\n);
 
 Is this intended behaviour? I thought the r300 only exists to provide
 3D acceleration.

That's perfectly correct behaviour. My intention is to start with a purely 
software rendered driver and go from there. Right now, no primitives will 
be hardware accelerated, only glClear() actually uses the hardware path.

Yes, that's a disappointment, but at least the driver is actually very 
stable (for me, that is ;)).
If you think there should be more features, your help is always welcome :)

cu,
Nicolai


pgpDLuMqoy58P.pgp
Description: PGP signature


Re: drm trouble

2004-10-19 Thread Jon Smirl
A fix is in CVS now to make missing/broken I2C buses a non-fatal
error. Fixed in linux-2.6 and linux-core.

-- 
Jon Smirl
[EMAIL PROTECTED]


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: drm trouble

2004-10-19 Thread Roland Scheidegger
Jon Smirl wrote:
On Tue, 19 Oct 2004 03:12:36 +0200, Roland Scheidegger 
[EMAIL PROTECTED] wrote:

Vladimir Dergachev wrote:
On Tue, 19 Oct 2004, Roland Scheidegger wrote:
Jon Smirl wrote:
Does the new radeonfb driver in the kernel load? It uses the 
same I2C initialization code.
excuse my ignorance, but where would I get that new radeonfb 
driver?
Try latest 2.6.x kernel. You might need to apply the rc4 patch.
There is an option in the driver to enable DDC/i2c.
ah ok. I was just confused with old vs. new radeonfb. The one 
in kernel 2.6.8 has that DDC/i2c option already (and it doesn't 
load, but due to another reason). I'll update to 2.6.9 anyway, it 
is already released.

Try running Ben's radeonfb and see if it fails too. It should since 
the i2c code is identical.
Ok, now with kernel 2.6.9. The radeonfb from that kernel seems to load
just fine (after killing vesafb, I've just omitted the vga=xxx boot 
option which seemed to do the trick), though it couldn't register that 
monid neither (but didn't seem to care that much).

Oct 19 18:09:54 ZakTower kernel: ACPI: PCI interrupt :01:00.0[A] - 
GSI 16 (level, low) - IRQ 16
Oct 19 18:09:54 ZakTower kernel: radeonfb: Found Intel x86 BIOS ROM Image
Oct 19 18:09:54 ZakTower kernel: radeonfb: Retreived PLL infos from BIOS
Oct 19 18:09:54 ZakTower kernel: radeonfb: Reference=27.00 MHz 
(RefDiv=12) Memory=275.00 Mhz, System=275.00 MHz
Oct 19 18:09:54 ZakTower kernel: i2c-algo-bit.o: (0) scl=0, sda=0
Oct 19 18:09:54 ZakTower kernel: i2c-algo-bit.o: monid seems to be busy.
Oct 19 18:09:54 ZakTower kernel: radeonfb :01:00.0: Failed to 
register I2C bus monid.
Oct 19 18:09:54 ZakTower kernel: i2c-algo-bit.o: (0) scl=1, sda=1
Oct 19 18:09:54 ZakTower kernel: i2c-algo-bit.o: (1) scl=1, sda=0
Oct 19 18:09:54 ZakTower kernel: i2c-algo-bit.o: (2) scl=1, sda=1
Oct 19 18:09:54 ZakTower kernel: i2c-algo-bit.o: (3) scl=0, sda=1
Oct 19 18:09:54 ZakTower kernel: i2c-algo-bit.o: (4) scl=1, sda=1
Oct 19 18:09:54 ZakTower kernel: i2c-algo-bit.o: dvi passed test.
Oct 19 18:09:54 ZakTower kernel: i2c-algo-bit.o: (0) scl=1, sda=1
Oct 19 18:09:54 ZakTower kernel: i2c-algo-bit.o: (1) scl=1, sda=0
Oct 19 18:09:54 ZakTower kernel: i2c-algo-bit.o: (2) scl=1, sda=1
Oct 19 18:09:54 ZakTower kernel: i2c-algo-bit.o: (3) scl=0, sda=1
Oct 19 18:09:54 ZakTower kernel: i2c-algo-bit.o: (4) scl=1, sda=1
Oct 19 18:09:54 ZakTower kernel: i2c-algo-bit.o: vga passed test.
Oct 19 18:09:54 ZakTower kernel: i2c-algo-bit.o: (0) scl=1, sda=1
Oct 19 18:09:54 ZakTower kernel: i2c-algo-bit.o: (1) scl=1, sda=0
Oct 19 18:09:54 ZakTower kernel: i2c-algo-bit.o: (2) scl=1, sda=1
Oct 19 18:09:54 ZakTower kernel: i2c-algo-bit.o: (3) scl=0, sda=1
Oct 19 18:09:54 ZakTower kernel: i2c-algo-bit.o: (4) scl=1, sda=1
Oct 19 18:09:54 ZakTower kernel: i2c-algo-bit.o: crt2 passed test.
Oct 19 18:09:55 ZakTower kernel: radeonfb: Monitor 1 type CRT found
Oct 19 18:09:55 ZakTower kernel: radeonfb: EDID probed
Oct 19 18:09:55 ZakTower kernel: radeonfb: Monitor 2 type no found
Oct 19 18:09:55 ZakTower kernel: Console: switching to colour frame 
buffer device 80x30
Oct 19 18:09:55 ZakTower kernel: radeonfb: ATI Radeon If  DDR SGRAM 64 MB


Next I would remove all i2c modules except i2c_core and i2c_algo_bit
 and see if it will load.
Didn't change anything. I've even removed all modules in single user
mode (except those still in use like file systems, and
agpgart/amd64-gart which is still shown as in-use and thus can't be 
removed (I guess that's a bug?)) and nothing changed at all.

Another posibility is that the monid port on your card is just 
broken, but you never noticed since you don't have a monitor plugged 
in that needs it.
What exactly are the different ports good for? Getting the monitor EDID
info at least works just fine.
Roland

---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Kernel Oops in drm_set_version

2004-10-19 Thread Felix Kühling
I noticed some kernel oopses in DRM in my kernel log. They don't seem to
be fatal as DRI is still working. This is on a machine with Vesa
framebuffer. On the other box without kernel framebuffer there are no
oopses.

Oct 19 18:30:31 trabant kernel: [drm] Initialized savage 1.0.0 20011023 on minor 0: S3 
Inc. VT8375 [ProSavage8 KM266/KL266]
Oct 19 18:30:31 trabant kernel: [drm] Used old pci detect: framebuffer loaded
Oct 19 18:30:31 trabant kernel: Unable to handle kernel paging request at virtual 
address f000e2c3
Oct 19 18:30:31 trabant kernel:  printing eip:
Oct 19 18:30:31 trabant kernel: cfdb2af0
Oct 19 18:30:31 trabant kernel: *pde = 
Oct 19 18:30:31 trabant kernel: Oops:  [#1]
Oct 19 18:30:31 trabant kernel: Modules linked in: savage drm ipv6 parport_pc lp 
parport snd_via82xx snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer 
snd_page_alloc snd_mpu401_uart snd_rawmidi snd soundcore via_ircc ohci1394 ieee1394 
joydev usbhid via_rhine mii ehci_hcd uhci_hcd usbcore via_agp agpgart
Oct 19 18:30:31 trabant kernel: CPU:0
Oct 19 18:30:31 trabant kernel: EIP:0060:[pg0+261954288/1069666304]Not tainted
Oct 19 18:30:31 trabant kernel: EFLAGS: 00013292   (2.6.8) 
Oct 19 18:30:31 trabant kernel: EIP is at drm_set_busid+0x90/0xf0 [drm]
Oct 19 18:30:31 trabant kernel: eax:    ebx: c9439800   ecx:    edx: 
cfdb749c
Oct 19 18:30:31 trabant kernel: esi:    edi: f000e2c3   ebp: cdd25860   esp: 
cbd7ff08
Oct 19 18:30:31 trabant kernel: ds: 007b   es: 007b   ss: 0068
Oct 19 18:30:31 trabant kernel: Process Xorg (pid: 1915, threadinfo=cbd7e000 
task=cea58c90)
Oct 19 18:30:31 trabant kernel: Stack: cd810b20 0014 cfdb7487  0001 
  ba80 
Oct 19 18:30:31 trabant kernel:c9439800 cbd7ff44 cfdb2e85 0001 0002 
0001  0001 
Oct 19 18:30:31 trabant kernel:0001   c9439800 0001 
cfdb2de0 cfdb1c55 ba80 
Oct 19 18:30:31 trabant kernel: Call Trace:
Oct 19 18:30:31 trabant kernel:  [pg0+261955205/1069666304] drm_setversion+0xa5/0xf0 
[drm]
Oct 19 18:30:31 trabant kernel:  [pg0+261955040/1069666304] drm_setversion+0x0/0xf0 
[drm]
Oct 19 18:30:31 trabant kernel:  [pg0+261950549/1069666304] drm_ioctl+0xe5/0x1ae [drm]
Oct 19 18:30:31 trabant kernel:  [do_int+167/592] do_int+0xa7/0x250
Oct 19 18:30:31 trabant kernel:  [do_int+167/592] do_int+0xa7/0x250
Oct 19 18:30:31 trabant kernel:  [sys_ioctl+175/496] sys_ioctl+0xaf/0x1f0
Oct 19 18:30:31 trabant kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
Oct 19 18:30:31 trabant kernel:  [do_int+167/592] do_int+0xa7/0x250
Oct 19 18:30:31 trabant kernel: Code: f2 ae f7 d1 49 03 4b 04 ba d0 00 00 00 8d 41 02 
e8 7b 23 38 

HTH,
  Felix

-- 
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3  B152 151C 5CC1 D888 E595 |



---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: drm trouble

2004-10-19 Thread Roland Scheidegger
Jon Smirl wrote:
A fix is in CVS now to make missing/broken I2C buses a non-fatal
error. Fixed in linux-2.6 and linux-core.
Ok, thanks. That gets around that problem, though it still doesn't work 
(linux-core, I've not yet tried the linux-2.6 version).
When the X server starts and vesafb is active, I got this:
Oct 19 19:41:16 ZakTower kernel: mtrr: 0xe800,0x400 overlaps 
existing 0xe800,0x20
Oct 19 19:41:17 ZakTower kernel: [drm] Initialized drm 1.0.0 20040925
Oct 19 19:41:17 ZakTower kernel: PCI: Unable to reserve mem region 
#1:[EMAIL PROTECTED] for device :01:00.0
Oct 19 19:41:17 ZakTower kernel: mtrr: 0xe800,0x400 overlaps 
existing 0xe800,0x20
Oct 19 19:41:17 ZakTower kernel: i2c-algo-bit.o: (0) scl=0, sda=0
Oct 19 19:41:17 ZakTower kernel: i2c-algo-bit.o: monid seems to be busy.
Oct 19 19:41:17 ZakTower kernel: [drm:setup_i2c_bus] *ERROR* Failed to 
register I2C bus monid.
Oct 19 19:41:17 ZakTower kernel: i2c-algo-bit.o: (0) scl=1, sda=1
...
Oct 19 19:41:17 ZakTower kernel: i2c-algo-bit.o: crt2 passed test.
Oct 19 19:41:17 ZakTower kernel: [drm] Initialized radeon 1.12.0 
20020828 on minor 0:
Oct 19 19:41:17 ZakTower kernel: [drm] Used old pci detect: framebuffer 
loaded
Oct 19 19:41:17 ZakTower kernel: Unable to handle kernel NULL pointer 
dereference at virtual address 0008
Oct 19 19:41:17 ZakTower kernel:  printing eip:
Oct 19 19:41:17 ZakTower kernel: f12970ab
Oct 19 19:41:17 ZakTower kernel: *pde = 37dc5067
Oct 19 19:41:17 ZakTower kernel: *pte = 
Oct 19 19:41:17 ZakTower kernel: Oops:  [#1]
Oct 19 19:41:17 ZakTower kernel: PREEMPT
Oct 19 19:41:17 ZakTower kernel: Modules linked in: radeon drm nvram 
tuner tvaudio msp3400 bttv video_buf firmware_class i2c_algo_bit 
v4l2_common btcx_risc videodev ir_kbd_i2c ir_common usbserial parport_pc 
lp parport speedstep_lib sk98lin snd_seq_oss snd_pcm_oss snd_mixer_oss 
freq_table thermal processor fan snd_seq_midi snd_emu10k1_synth 
snd_emux_synth snd_seq_virmidi snd_seq_midi_event snd_seq_midi_emul 
button battery ac snd_seq snd_emu10k1 snd_rawmidi snd_pcm snd_timer 
snd_seq_device snd_ac97_codec snd_page_alloc edd joydev snd_util_mem 
snd_hwdep sg via686a sd_mod sr_mod snd soundcore w83781d i2c_sensor 
i2c_isa i2c_viapro i2c_core ehci_hcd uhci_hcd amd64_agp ohci1394 
ieee1394 emu10k1_gp gameport af_packet agpgart 8139too mii evdev usbcore 
ip6t_LOG ipt_TCPMSS ipt_TOS ipt_LOG ipt_state ip6table_mangle ipt_REJECT 
iptable_mangle iptable_filter ip_nat_ftp iptable_nat ip_conntrack_ftp 
ip_conntrack ip_tables ip6table_filter ip6_tables ipv6 ide_cd cdrom ntfs 
nls_utf8 nls_cp850 vfat fat dm_mod
Oct 19 19:41:17 ZakTower kernel: CPU:0
Oct 19 19:41:17 ZakTower kernel: EIP:0060:[f12970ab]Not 
tainted VLI
Oct 19 19:41:17 ZakTower kernel: EFLAGS: 00013286   (2.6.9n)
Oct 19 19:41:17 ZakTower kernel: EIP is at drm_set_busid+0x8b/0xf0 [drm]
Oct 19 19:41:17 ZakTower kernel: eax:    ebx: ede56000   ecx: 
   edx: e671ea90
Oct 19 19:41:17 ZakTower kdm: :0[12617]: IO Error in XOpenDisplay
Oct 19 19:41:17 ZakTower kdm[12371]: X server for display :0 terminated 
unexpectedly
Oct 19 19:41:17 ZakTower kernel: esi:    edi: e834df40   ebp: 
f12973b0   esp: e834df04
Oct 19 19:41:17 ZakTower kdm[12371]: Display :0 cannot be opened
Oct 19 19:41:17 ZakTower kernel: ds: 007b   es: 007b   ss: 0068
Oct 19 19:41:17 ZakTower kernel: Process X (pid: 12497, 
threadinfo=e834d000 task=e959f560)
Oct 19 19:41:17 ZakTower kernel: Stack: e671ea80 0014 f129bd70 
 0001   a710
Oct 19 19:41:17 ZakTower kernel:ede56000 e834df40 f1297456 
0001 0002 0001  0001
Oct 19 19:41:17 ZakTower kernel:0001  0867a340 
ede56000 0007 f12a1914 f1295f5d a710
Oct 19 19:41:17 ZakTower kernel: Call Trace:
Oct 19 19:41:17 ZakTower kernel:  [f1297456] drm_setversion+0xa6/0xf0 
[drm]
Oct 19 19:41:17 ZakTower kernel:  [f1295f5d] drm_ioctl+0x14d/0x21e [drm]
Oct 19 19:41:17 ZakTower kernel:  [b016a099] sys_ioctl+0x1f9/0x2a0
Oct 19 19:41:17 ZakTower kernel:  [b0106049] sysenter_past_esp+0x52/0x71
Oct 19 19:41:17 ZakTower kernel: Code: 00 00 c7 44 24 08 70 bd 29 f1 89 
44 24 0c 8b 43 04 89 14 24 89 44 24 04 e8 53 b5 f7 be 8b 83 dc 06 00 00 
b9 ff ff ff ff 8b 40 34 8b 78 08 89 f0 f2 ae f7 d1 49 03 4b 04 ba d0 
00 00 00 8d 41 02
Oct 19 19:41:17 ZakTower kdm[12371]: Unable to fire up local display :0; 
disabling.
Oct 19 19:41:37 ZakTower kernel: SysRq : Emergency Sync

Leaving me without a console, and forcing me to reboot...
End of Xorg log file:
drmOpenDevice: Open failed
drmOpenByBusid: Searching for BusID pci::01:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 5, (OK)
drmOpenByBusid: drmOpenMinor returns 5
So I tried without vesafb, this worked slightly better:
Oct 19 19:43:46 ZakTower kernel: [drm] Initialized radeon 1.12.0 
20020828 on minor 0:
Oct 19 19:43:46 ZakTower kernel: agpgart: Found an AGP 3.5 

Re: Kernel Oops in drm_set_version

2004-10-19 Thread Jon Smirl
The fault is in drm_set_busid. It's a NULL pointer reference. I'm not
seeing this so it may be savage specific. The only place I can see
where you could get a NULL reference is if the PCI driver didn't set a
name, dev-pdev-driver-name. Can you add a debug statement and check
if there is one? The trap looks like it is in a sprintf.

static int drm_set_busid(drm_device_t * dev)
{
if (dev-unique != NULL)
return EBUSY;

dev-unique_len = 20;
dev-unique = drm_alloc(dev-unique_len + 1, DRM_MEM_DRIVER);
if (dev-unique == NULL)
return ENOMEM;

snprintf(dev-unique, dev-unique_len, pci:%04x:%02x:%02x.%d,
 dev-pci_domain, dev-pci_bus, dev-pci_slot, dev-pci_func);

dev-devname = drm_alloc(strlen(dev-pdev-driver-name) + dev-unique_len + 2,
 DRM_MEM_DRIVER);
if (dev-devname == NULL)
return ENOMEM;

sprintf(dev-devname, [EMAIL PROTECTED], dev-pdev-driver-name, 
dev-unique);

return 0;
}

-- 
Jon Smirl
[EMAIL PROTECTED]


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: drm trouble

2004-10-19 Thread Roland Scheidegger
Roland Scheidegger wrote:
Jon Smirl wrote:
A fix is in CVS now to make missing/broken I2C buses a non-fatal
error. Fixed in linux-2.6 and linux-core.

Ok, thanks. That gets around that problem, though it still doesn't work 
(linux-core, I've not yet tried the linux-2.6 version).
Forgot to mention, when I tried to remove the radeon module after that 
last error (when getting the radeon_do_init_cp errors in the log file) I 
got another kernel oops.

Oct 19 20:02:19 ZakTower kernel: [drm:drm_ati_pcigart_cleanup] *ERROR* 
no scatter/gather memory!
Oct 19 20:02:19 ZakTower kernel: [drm:radeon_do_cleanup_cp] *ERROR* 
failed to cleanup PCI GART!
Oct 19 20:02:19 ZakTower kernel: Unable to handle kernel NULL pointer 
dereference at virtual address 
Oct 19 20:02:19 ZakTower kernel:  printing eip:
Oct 19 20:02:19 ZakTower kernel: f0e722ce
Oct 19 20:02:19 ZakTower kernel: *pde = 
Oct 19 20:02:19 ZakTower kernel: Oops:  [#1]
Oct 19 20:02:19 ZakTower kernel: PREEMPT
Oct 19 20:02:19 ZakTower kernel: Modules linked in: radeon drm nvram 
tuner tvaudio msp3400 bttv video_buf firmware_class i2c_algo_bit 
v4l2_common btcx_risc videodev ir_kbd_i2c ir_common usbserial parport_pc 
lp parport speedstep_lib freq_table thermal via686a processor fan button 
w83781d i2c_sensor i2c_isa snd_seq_oss snd_pcm_oss snd_mixer_oss 
snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi 
snd_seq_midi_event snd_seq_midi_emul snd_seq battery ac i2c_viapro 
i2c_core snd_emu10k1 snd_rawmidi snd_pcm snd_timer snd_seq_device 
snd_ac97_codec snd_page_alloc snd_util_mem snd_hwdep snd soundcore 
sk98lin edd joydev sg sd_mod sr_mod af_packet ehci_hcd uhci_hcd 
emu10k1_gp gameport 8139too mii ohci1394 ieee1394 amd64_agp agpgart 
evdev ipt_TCPMSS ipt_TOS ipt_LOG ipt_state usbcore ip6t_LOG 
ip6table_mangle ipt_REJECT iptable_mangle iptable_filter ip_nat_ftp 
iptable_nat ip_conntrack_ftp ip_conntrack ip_tables ip6table_filter 
ip6_tables ipv6 ide_cd cdrom ntfs nls_utf8 nls_cp850 vfat fat dm_mod
Oct 19 20:02:19 ZakTower kernel: CPU:0
Oct 19 20:02:19 ZakTower kernel: EIP:0060:[f0e722ce]Not 
tainted VLI
Oct 19 20:02:19 ZakTower kernel: EFLAGS: 00010217   (2.6.9n)
Oct 19 20:02:19 ZakTower kernel: EIP is at i2c_del_adapter+0x7e/0x1d0 
[i2c_core]
Oct 19 20:02:19 ZakTower kernel: eax: f0ee6a08   ebx:    ecx: 
f0e77a30   edx: 
Oct 19 20:02:19 ZakTower kernel: esi: ea6a81ac   edi: ea6a8278   ebp: 
ea6a8110   esp: db268e8c
Oct 19 20:02:19 ZakTower kernel: ds: 007b   es: 007b   ss: 0068
Oct 19 20:02:19 ZakTower kernel: Process rmmod (pid: 17483, 
threadinfo=db268000 task=e197d560)
Oct 19 20:02:19 ZakTower kernel: Stack: 0097 eff2f09c 0002 
8000 b03ac900  ea41f800 0008
Oct 19 20:02:19 ZakTower kernel:b010f492 db268ed3 ea6a8000 
0003 ea41f800  f0f8bd1b ea41f800
Oct 19 20:02:19 ZakTower kernel:ea6a8000 f0f83d73 0282 
e4025780 e4025780 e99e8700 f0f9f585 ecf8dc1c
Oct 19 20:02:19 ZakTower kernel: Call Trace:
Oct 19 20:02:19 ZakTower kernel:  [b010f492] mtrr_del_page+0x82/0x1b0
Oct 19 20:02:19 ZakTower kernel:  [f0f8bd1b] 
radeon_delete_i2c_busses+0x3b/0x40 [radeon]
Oct 19 20:02:19 ZakTower kernel:  [f0f83d73] 
radeon_postcleanup+0x23/0x80 [radeon]
Oct 19 20:02:19 ZakTower kernel:  [f0f9f585] drm_cleanup+0x315/0x370 [drm]
Oct 19 20:02:19 ZakTower kernel:  [b0219d68] pci_device_remove+0x28/0x30
Oct 19 20:02:19 ZakTower kernel:  [b026c946] 
device_release_driver+0x56/0x60
Oct 19 20:02:19 ZakTower kernel:  [b026c968] driver_detach+0x18/0x30
Oct 19 20:02:19 ZakTower kernel:  [b026cdd4] bus_remove_driver+0x44/0x80
Oct 19 20:02:19 ZakTower kernel:  [b026d2a8] driver_unregister+0x8/0x20
Oct 19 20:02:19 ZakTower kernel:  [b0219f8b] 
pci_unregister_driver+0xb/0x20
Oct 19 20:02:19 ZakTower kernel:  [f0f9f65f] drm_exit+0x7f/0xc0 [drm]
Oct 19 20:02:19 ZakTower kernel:  [b01344f6] try_stop_module+0x16/0x20
Oct 19 20:02:19 ZakTower kernel:  [b01346c0] sys_delete_module+0x150/0x160
Oct 19 20:02:19 ZakTower kernel:  [b014ba8e] unmap_vma_list+0xe/0x20
Oct 19 20:02:19 ZakTower kernel:  [b014be58] do_munmap+0x128/0x1a0
Oct 19 20:02:19 ZakTower kernel:  [b014bf17] sys_munmap+0x47/0x70
Oct 19 20:02:19 ZakTower kernel:  [b0106049] sysenter_past_esp+0x52/0x71
Oct 19 20:02:19 ZakTower kernel: Code: 85 d2 74 e9 89 e8 ff d2 85 c0 89 
44 24 14 0f 85 ef 00 00 00 8b 03 eb d5 90 8d 74 26 00 8b 9d 68 01 00 00 
8d bd 68 01 00 00 39 fb 8b 33 74 30 8d 85 9c 00 00 00 89 44 24 10 8d 
74 26 00 81 eb d8
Oct 19 20:02:50 ZakTower init: Switching to runlevel: 6
Oct 19 20:03:36 ZakTower kernel:  6SysRq : Emergency Sync

but I'm happy to report that the old linux-2.6 version works!
Roland
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more

Re: drm trouble

2004-10-19 Thread Jon Smirl
On Tue, 19 Oct 2004 18:14:32 +0200, Roland Scheidegger
[EMAIL PROTECTED] wrote:
  Another posibility is that the monid port on your card is just
  broken, but you never noticed since you don't have a monitor plugged
  in that needs it.
 What exactly are the different ports good for? Getting the monitor EDID
 info at least works just fine.

Some cards have 2 DVI, 2 CRT, 1 DVI + 1 CRT, etc. They use different
the different ports for getting EDID depending on the output plugs.

My best bet is that your monid port is just broken or not implement on
the card from whichever vendor made your card. I can change the DRM
code so that this is not a fatal condition.

There is supposed to be some way to decode the VBIOS ROM and tell what
ports the card has. This would let me avoid initializing all of the
I2C ports. But I don't have detailed documentation on this.

 
 Roland
 
 


-- 
Jon Smirl
[EMAIL PROTECTED]


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Kernel Oops in drm_set_version

2004-10-19 Thread Jon Smirl
What do I have to do to X to make it call set_busid? It's not getting
called in my config.

-- 
Jon Smirl
[EMAIL PROTECTED]


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 1657] GLX/DRI failure on XOrg 6.8.0/1

2004-10-19 Thread bugzilla-daemon
Please do not reply to this email: if you want to comment on the bug, go to  
the URL shown below and enter yourcomments there.   
 
https://freedesktop.org/bugzilla/show_bug.cgi?id=1657
   




--- Additional Comments From [EMAIL PROTECTED]  2004-10-19 13:14 ---
As far as we know, mach64 works.  What specific issue are you seeing with the
Mach64 snapshots on top of a clean X.Org 6.8.1 or CVS?

   
   
-- 
Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email   
   
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Kernel Oops in drm_set_version

2004-10-19 Thread Felix Kühling
Am Di, den 19.10.2004 schrieb Jon Smirl um 20:11:
 The fault is in drm_set_busid. It's a NULL pointer reference. I'm not
 seeing this so it may be savage specific. The only place I can see
 where you could get a NULL reference is if the PCI driver didn't set a
 name, dev-pdev-driver-name. Can you add a debug statement and check
 if there is one? The trap looks like it is in a sprintf.

I added these debug statements:

printk(KERN_ERR dev = %p\n, dev);
printk(KERN_ERR dev-pdev = %p\n, dev-pdev);
printk(KERN_ERR dev-pdev-driver = %p\n, dev-pdev-driver);
printk(KERN_ERR dev-pdev-driver-name = %p\n, dev-pdev-driver-name);

This is the output:

dev = c9438800
dev-pdev = cee8c400
dev-pdev-driver = 
dev-pdev-driver-name = f000e2c3

Funny thing is that it doesn't complain about the NULL-pointer
reference. It complains about:

Unable to handle kernel paging request at virtual address f000e2c3

The real problem is that dev-pdev-driver is NULL.

drm_set_busid is called if the minor interface version is = 1. This
interface version is requested by the common DRI code in the Xserver.
This in turn depends on the available libdrm version (quoting
xc/programs/Xserver/GL/dri/dri.c):

if (drmlibmajor == 1  drmlibminor = 2) {
drmSetVersion sv;

/* Get the interface version, asking for 1.1. */
sv.drm_di_major = 1;
sv.drm_di_minor = 1;
sv.drm_dd_major = -1;
err = drmSetInterfaceVersion(pDRIPriv-drmFD, sv);
if (err == 0) {
drmdimajor = sv.drm_di_major;
drmdiminor = sv.drm_di_minor;
} else {
/* failure, so set it to 1.0.0. */
drmdimajor = 1;
drmdiminor = 0;
}
}
else {
/* We can't check the DI DRM interface version, so set it to 1.0.0. */
drmdimajor = 1;
drmdiminor = 0;
}

Are you using an up-to-date libdrm for testing?

BTW, I noticed one small thing in drm_set_version that looks like a
typo:

if_version = DRM_IF_VERSION(sv.drm_di_major, sv.drm_dd_minor);
   -^   -^

Does it make sense to mix driver and interface versions? Shouldn't it
be:

if_version = DRM_IF_VERSION(sv.drm_di_major, sv.drm_di_minor);

Regards,
  Felix

-- 
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3  B152 151C 5CC1 D888 E595 |



---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 1657] GLX/DRI failure on XOrg 6.8.0/1

2004-10-19 Thread bugzilla-daemon
Please do not reply to this email: if you want to comment on the bug, go to  
the URL shown below and enter yourcomments there.   
 
https://freedesktop.org/bugzilla/show_bug.cgi?id=1657
   




--- Additional Comments From [EMAIL PROTECTED]  2004-10-19 15:07 ---
(In reply to comment #5)
 As far as we know, mach64 works.  What specific issue are you seeing with the
 Mach64 snapshots on top of a clean X.Org 6.8.1 or CVS?
 

Huh?!

As i mentioned above, it reports a lot of No matching visual for
__GLcontextMode with visual class = -1 (-1), nplanes = 0

I've installed a fresh mach64 snapshot (19.oct.2004). DRI seems to be more or
less enabled, however, the funny log line remains...

glxinfo prints out a lot of libGL warning: 3D driver claims to not support
visual 0x

and glxgears adds an Error: couldn't get an RGB, Double-buffered visual to it.

(several color depths with a 640x480 resolution tested). 

I think, mach64 does not work correclty...

I'll try XOrg CVS later, this may take some hours.
   
   
-- 
Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email   
   
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: drm trouble

2004-10-19 Thread Alex Deucher
On Tue, 19 Oct 2004 12:24:23 -0400, Jon Smirl [EMAIL PROTECTED] wrote:
 On Tue, 19 Oct 2004 18:14:32 +0200, Roland Scheidegger
 [EMAIL PROTECTED] wrote:
   Another posibility is that the monid port on your card is just
   broken, but you never noticed since you don't have a monitor plugged
   in that needs it.
  What exactly are the different ports good for? Getting the monitor EDID
  info at least works just fine.
 
 Some cards have 2 DVI, 2 CRT, 1 DVI + 1 CRT, etc. They use different
 the different ports for getting EDID depending on the output plugs.
 
 My best bet is that your monid port is just broken or not implement on
 the card from whichever vendor made your card. I can change the DRM
 code so that this is not a fatal condition.
 
 There is supposed to be some way to decode the VBIOS ROM and tell what
 ports the card has. This would let me avoid initializing all of the
 I2C ports. But I don't have detailed documentation on this.

Take a look at the latest radeon ddx in xorg cvs as well has Hui's
latest patch here:
https://freedesktop.org/bugzilla/show_bug.cgi?id=1559
and this older patch here:
http://www.botchco.com/alex/radeon/hy0/x440_radeon_4_newchips.diff

the current cvs DDX uses the bios to get info on what's attached, etc.

Alex

 
 
  Roland
 
 
 
 --
 Jon Smirl
 [EMAIL PROTECTED]
 
 ---
 This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
 Use IT products in your business? Tell us what you think of them. Give us
 Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
 http://productguide.itmanagersjournal.com/guidepromo.tmpl
 --
 ___
 Dri-devel mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/dri-devel



---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Kernel Oops in drm_set_version

2004-10-19 Thread Jon Smirl
Does this fix it for you? I haven't figured out how to trigger it yet. 

[EMAIL PROTECTED] drm-bk]$ bk -r diffs -u
= linux-core/drm_drv.c 1.11 vs edited =
--- 1.11/linux-core/drm_drv.c   2004-10-18 22:58:26 -04:00
+++ edited/linux-core/drm_drv.c 2004-10-20 00:33:20 -04:00
@@ -329,6 +329,8 @@
   pid-subvendor, pid-subdevice,
   pdev))) {
/* stealth mode requires a manual probe */
+   if (!pdev-driver)
+   pdev-driver = driver-pci_driver;
pci_dev_get(pdev);
drm_get_dev(pdev, pciidlist[i], driver);
}
[EMAIL PROTECTED] drm-bk]$ bk -r diffs -u ../patch
[EMAIL PROTECTED] drm-bk]$

-- 
Jon Smirl
[EMAIL PROTECTED]


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Kernel Oops in drm_set_version

2004-10-19 Thread Jon Smirl
On Wed, 20 Oct 2004 00:40:07 -0400, Jon Smirl [EMAIL PROTECTED] wrote:
 Does this fix it for you? I haven't figured out how to trigger it yet.

I think the problem here is that vesafb is not attached as a true
device driver but it has the resources allocated. DRM comes along and
see vesafb so it goes into stealth mode. In stealth mode DRM does not
attach as a true driver either. So now we have the pci device in use
without a driver attached.

The answer here is that because of stealth mode I can't rely on the
pointer  pdev-driver-name to get the driver name. It may be null in
the case of fbdev and xxxfb for an fbdev driver. I need to make a
different pointer for recording the driver name.

-- 
Jon Smirl
[EMAIL PROTECTED]


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Kernel Oops in drm_set_version

2004-10-19 Thread Jon Smirl
I checked in a fix that switches from 
dev-pdev-driver-name
to
drm-driver-pci_driver.name

This should fix the segfaults in stealth mode when the pci driver is
set to the wrong driver (fbdev) or no driver (vesafb).

Please give it a try.

-- 
Jon Smirl
[EMAIL PROTECTED]


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: drm trouble

2004-10-19 Thread Jon Smirl
I checked in a fix that switches from 
dev-pdev-driver-name
to
drm-driver-pci_driver.name

This should fix the segfaults in stealth mode when the pci driver is
set to the wrong driver (fbdev) or no driver (vesafb).

Please give it a try.

-- 
Jon Smirl
[EMAIL PROTECTED]


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel