anoncvs update interval time...
Hi! Does anyone know how fast the anoncvs server updates (e.g. in which intervals) ? I saw that a patch was commited a while ago (or at least the matching message appeared at cvs-commit :) but anoncvs was still not updated... Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 2426 901568 FAX +49 2426 901569 (;O/ \/ \O;) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another Suggested Rendiition Fix
> I was committing it as this came through. Thanks--and I'm sorry for jumping the gun. > There's a good chance that moving the location of that register > restoration should be unconditional given the nature of what is > going on there. It'd be nice to get some feedback from > someone with a Verite 1000. I'm thinking the same thing. I've shaken another tree on this front. I don't expect it to pan out, but we can hope. - Original Message - From: "David Dawes" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, February 23, 2004 8:17 PM Subject: Re: Another Suggested Rendiition Fix > On Mon, Feb 23, 2004 at 07:48:32PM -0500, Eric Wittry wrote: > >I have opened a Bugzilla bug report (1204 for Drivers) that documents a > >Rendition bug and provides a suggested fix. (I also created--and marked as > >resolved--1200 through 1203 to document issues addressed by the last patch to > >the Rendition driver.) I will summarize that report here. > > I was committing it as this came through. There's a good chance > that moving the location of that register restoration should be > unconditional given the nature of what is going on there. It'd be nice > to get some feedback from someone with a Verite 1000. > > David > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XvMC indirect rendering / dri direct / extensions
On Tue, 24 Feb 2004, Thomas Hellstrom wrote: > Hi! > > I'm a bit new to this, so please forgive me if asking stupid questions. > > I have had a look at the XvMC API for the purpose of eventually making a > trial extension to the via driver for the via MPEG2 decoding engine. The > current VIA API for this is accessing the HW mmio directly more or less > without interaction and sync with the X server and will require root > privileges. > > Now, much of what's needed is there.. creating of contexts, surfaces and > subpictures. The rest would require either an extension of the XvMC API > or implementing just a subset of the XvMC calls and modify the VIA API > to get surfaces and context from this "XvMC light" and interact with drm > to be able to lock hardware and map mmio as a non root user. > > I think this should be implemented as an indirect driver since this > would eliminate the need for hw locking and dealing with memory > protection issues while still keeping communications at a minimum, but > this would require some extensions to the XvMC API mainly for describing > an MPEG frame and for adding slice data. Looking at the XvMc code in > current X, although the draft standard describes support for indirect > functionality, the infrastructure (including protocol extensions and > function hooks) does not seem complete ? While the API and specification allows indirect rendering, the implementation does not. Indirect rendering of Mpeg isn't very attractive due the large amount of communication between the client and X-server that would be required. Indirect rendering of XvMC was something that could be added at some point, but I didn't expect that anyone would actually get around to implementing it because the performance is expected to be unsatisfactory. Note that the XvMC pipeline comes after the MPEG variable length decode. I'm guessing that the amount of data pushed through an indirect socket probably exceeds the size of the raw MPEG file. As for a direct implementation. The problem is essentially the same as the one solved by OpenGL. I would expect OpenGL's solutions to the HW access problems to work for XvMC as well. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another Suggested Rendiition Fix
On Mon, Feb 23, 2004 at 07:48:32PM -0500, Eric Wittry wrote: >I have opened a Bugzilla bug report (1204 for Drivers) that documents a >Rendition bug and provides a suggested fix. (I also created--and marked as >resolved--1200 through 1203 to document issues addressed by the last patch to >the Rendition driver.) I will summarize that report here. I was committing it as this came through. There's a good chance that moving the location of that register restoration should be unconditional given the nature of what is going on there. It'd be nice to get some feedback from someone with a Verite 1000. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Printer-builtin fontpaths broken / was: Re: CVS Update: xc (branch: trunk)
David Dawes wrote:
>
> On Thu, Feb 19, 2004 at 11:20:50PM +0100, Roland Mainz wrote:
> >David Dawes wrote:
> >> >David Dawes wrote:
> >> >> CVSROOT:/home/x-cvs
> >> >> Module name:xc
> >> >> Changes by: [EMAIL PROTECTED] 04/02/11 13:11:26
> >> >>
> >> >> Log message:
> >> >>799. Some more font path checks.
> >> >>
> >> >> Modified files:
> >> >> xc/lib/font/fontfile/:
> >> >> dirfile.c encparse.c fontfile.c
> >> >> xc/programs/Xserver/hw/xfree86/:
> >> >> CHANGELOG
> >> >>
> >> >> Revision ChangesPath
> >> >> 3.18 +17 -1 xc/lib/font/fontfile/dirfile.c
> >> >> 1.20 +7 -2 xc/lib/font/fontfile/encparse.c
> >> >> 3.22 +30 -11xc/lib/font/fontfile/fontfile.c
> >> >> 3.3139+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG
> >> >
> >> >David:
> >> >Somehow these changes broke Xprt's handing of printer builtin fonts
> >> >(e.g. font paths prefixed with "PRINTER:" which are "enabled"
> >> >dynamically on per-model-config basis).
> >>
> >> Can you isolate which of the changes causes the problem by adding them
> >> in one at a time?
> >
> >Yes, it seems that my original observation was wrong. Not the
> >printer-builtin fonts are affected but parts of the font path are
> >dropped.
> >The following statement in xc/lib/font/fontfile/dirfile.c causes the
> >failure:
> >(from
> >http://xprint.freedesktop.org/cgi-bin/bugzilla/attachment.cgi?id=95&action=view)
> >-- snip --
> >+ }
> >+ if (!found_font) {
> >+ FontFileFreeDir (dir);
> >+ fclose(file);
> >+ return BadFontPath;
> >}
> >-- snip --
> >It seems that the change now makes it mandatory that the Xserver allows
> >to drop invalid font path elements... ;-/
>
> I guess that's this change:
>
> 70. Changed behavior of fontfile: don't drop the entire directory if some
> fonts cannot be rendered (Egbert Eich).
>
> What exactly is it doing that breaks the printer fonts?
It seems that my original observation about missing printer buildin
fonts was wrong. The server refused to start and I thought that this was
caused by problems with the printer buildin fonts (note that I have
modified the font code in my own tree - if someone tries to start Xprt
with an invalid (or missing) configuration the server now refuses to
start (this is mainly to get rid of the myths about Xprint caused by
server misconfiguration)). After some more debugging I realised that the
dropping of font path elements isn't supported by my codebase (since I
am working on a X11R6.6-based tree which misses the code which can drop
parts of the font path without aborting the server startup) so the
server fails to start. My fault... ;-(
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 2426 901568 FAX +49 2426 901569
(;O/ \/ \O;)
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Another Suggested Rendiition Fix
I have opened a Bugzilla bug report (1204 for Drivers) that documents a
Rendition bug and provides a suggested fix. (I also created--and marked as
resolved--1200 through 1203 to document issues addressed by the last patch to
the Rendition driver.) I will summarize that report here.
The Rendition driver causes sporadic system lock-ups on text mode entry
(associated with either VT switching or with exitting the server). This problem
seems to have a long pedigree--I see it in release notes for XFree86 4.0
(http://www.xfree86.org/4.0/rendition9.html#9), and it is still in the release
notes for 4.3 (http://www.xfree86.org/4.3.0/rendition9.html#9). While I cannot
reproduce this problem at will, I have never managed 20 consecutive switches to
text mode (in the same server run) without seeing the lockup.
Here is the proposed fix:
$ diff -c vmodes.c.4.3.99.903 vmodes.c
*** vmodes.c.4.3.99.903 2002-12-11 12:23:33.0 -0500
--- vmodes.c2004-02-22 02:17:31.0 -0500
***
*** 376,382
int iob=pRendition->board.io_base;
verite_restoredac (pScreenInfo, reg);
! verite_out32(iob+MODEREG,reg->mode);
verite_out8(iob+MEMENDIAN,reg->memendian);
verite_out32(iob+DRAMCTL,reg->dramctl);
verite_out32(iob+SCLKPLL,reg->sclkpll);
--- 376,393
int iob=pRendition->board.io_base;
verite_restoredac (pScreenInfo, reg);
!
! /*
! * If this is a Verite 1000, restore the MODEREG
! * register now. The MODEREG gets restored later
! * for the Verite 2x00 because restoring it here
! * has been confirmed to cause intermittent
! * system locks.
! */
! if (pRendition->board.chip == V1000_DEVICE) {
! verite_out32(iob+MODEREG,reg->mode);
! }
!
verite_out8(iob+MEMENDIAN,reg->memendian);
verite_out32(iob+DRAMCTL,reg->dramctl);
verite_out32(iob+SCLKPLL,reg->sclkpll);
***
*** 397,402
--- 408,425
while ((verite_in32(iob+CRTCSTATUS)&CRTCSTATUS_VERT_MASK) ==
CRTCSTATUS_VERT_ACTIVE);
}
+
+ /*
+ * If this is a Verite 2x00, restore the MODEREG
+ * register now. The MODEREG register is restored
+ * earlier for the Verite 1000, but is restored
+ * here for the Verite 2x00 to prevent system
+ * locks.
+ */
+ if (pRendition->board.chip != V1000_DEVICE) {
+ verite_out32(iob+MODEREG,reg->mode);
+ }
+
verite_out32(iob+CRTCHORZ,reg->crtch);
verite_out32(iob+CRTCVERT,reg->crtcv);
verite_out32(iob+FRAMEBASEA, reg->vbasea);
I lack hardware documentation, so I cannot point to anything categorically
stating that this is the correct resolution--I arrived at this fix through a lot
of blind tweaking and some comparisons to 3.3.6, which does not seem to exhibit
the problem. Version 3.3.6 fails to lock the machine through more than fifty
switches into text mode (at which point I give up). With the above change, I
have seen the same results under 4.4 RC3.
For convenience, I have attached the updated file
(xc/programs/hw/xfree86/drivers/rendition/vmodes.c).
Eric Wittry
eswittry&yahoo.com
(replace ampersand with "@")
vmodes.c
Description: Binary data
XvMC indirect rendering / dri direct / extensions
Hi! I'm a bit new to this, so please forgive me if asking stupid questions. I have had a look at the XvMC API for the purpose of eventually making a trial extension to the via driver for the via MPEG2 decoding engine. The current VIA API for this is accessing the HW mmio directly more or less without interaction and sync with the X server and will require root privileges. Now, much of what's needed is there.. creating of contexts, surfaces and subpictures. The rest would require either an extension of the XvMC API or implementing just a subset of the XvMC calls and modify the VIA API to get surfaces and context from this "XvMC light" and interact with drm to be able to lock hardware and map mmio as a non root user. I think this should be implemented as an indirect driver since this would eliminate the need for hw locking and dealing with memory protection issues while still keeping communications at a minimum, but this would require some extensions to the XvMC API mainly for describing an MPEG frame and for adding slice data. Looking at the XvMc code in current X, although the draft standard describes support for indirect functionality, the infrastructure (including protocol extensions and function hooks) does not seem complete ? Also if implementing direct XvMC is considered, DRI seems very tightly coupled and mixed with Hw accelerated OpenGL . Is there a simple way to only get access only to the drm HW lock and non-root client mmio / framebuffer mapping? Hints to relevant documentation would be appreciated. Thanks Thomas ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Printer-builtin fontpaths broken / was: Re: CVS Update: xc (branch: trunk)
On Thu, Feb 19, 2004 at 11:20:50PM +0100, Roland Mainz wrote:
>David Dawes wrote:
>> >David Dawes wrote:
>> >> CVSROOT:/home/x-cvs
>> >> Module name:xc
>> >> Changes by: [EMAIL PROTECTED] 04/02/11 13:11:26
>> >>
>> >> Log message:
>> >>799. Some more font path checks.
>> >>
>> >> Modified files:
>> >> xc/lib/font/fontfile/:
>> >> dirfile.c encparse.c fontfile.c
>> >> xc/programs/Xserver/hw/xfree86/:
>> >> CHANGELOG
>> >>
>> >> Revision ChangesPath
>> >> 3.18 +17 -1 xc/lib/font/fontfile/dirfile.c
>> >> 1.20 +7 -2 xc/lib/font/fontfile/encparse.c
>> >> 3.22 +30 -11xc/lib/font/fontfile/fontfile.c
>> >> 3.3139+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG
>> >
>> >David:
>> >Somehow these changes broke Xprt's handing of printer builtin fonts
>> >(e.g. font paths prefixed with "PRINTER:" which are "enabled"
>> >dynamically on per-model-config basis).
>>
>> Can you isolate which of the changes causes the problem by adding them
>> in one at a time?
>
>Yes, it seems that my original observation was wrong. Not the
>printer-builtin fonts are affected but parts of the font path are
>dropped.
>The following statement in xc/lib/font/fontfile/dirfile.c causes the
>failure:
>(from
>http://xprint.freedesktop.org/cgi-bin/bugzilla/attachment.cgi?id=95&action=view)
>-- snip --
>+ }
>+ if (!found_font) {
>+ FontFileFreeDir (dir);
>+ fclose(file);
>+ return BadFontPath;
>}
>-- snip --
>It seems that the change now makes it mandatory that the Xserver allows
>to drop invalid font path elements... ;-/
I guess that's this change:
70. Changed behavior of fontfile: don't drop the entire directory if some
fonts cannot be rendered (Egbert Eich).
What exactly is it doing that breaks the printer fonts?
David
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver
Hi, I wrote: > an interesting thing to know is whether there are i855GM notebooks by > other companies using the same BIOS build (3066) and if these show the > same problem. Googling the net I found these release notes by Intel (http://www.levi.cz/pub/support/driver/vga/intel/i830_845_852_855_865/pv13.5/relnotes_135.htm) saying "Video BIOS Ver.3066 causes the system to hang". This isn't very detailed but maybe if refers to the bug we're talking about. CU Christian -- Christian Zietz - CHZ-Soft - [EMAIL PROTECTED] WWW: http://chzsoft.com.ar/ - Fido: Christian [EMAIL PROTECTED]:2437/74.9 PGP-Key auf Anfrage oder ueber http://wwwkeys.de.pgp.net (Port 11371) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver
Hallo, an interesting thing to know is whether there are i855GM notebooks by other companies using the same BIOS build (3066) and if these show the same problem. CU Christian -- Christian Zietz - CHZ-Soft - [EMAIL PROTECTED] WWW: http://chzsoft.com.ar/ - Fido: Christian [EMAIL PROTECTED]:2437/74.9 PGP-Key auf Anfrage oder ueber http://wwwkeys.de.pgp.net (Port 11371) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver
On Mon, Feb 23, 2004 at 07:29:32PM +0100, Christian Zietz wrote: > Hi, > > Alan Hourihane schrieb: > > > Is there a string 'DELL' or similar in the BIOS that we can use the > > function xf86ReadBIOS() to detect this buggy BIOS and skip using this > > function call in this case ? > > No, there is no reference to Dell in the BIOS. I'm not even sure if they > configure the BIOS. I just know that there is the possibility to do so > and that the faulty table is in an area where some values can be > configured by the OEM. So it doesn't need to be a bug introduced by > Dell, it's just one possible explanation. No, but currently we've only had reports of people with a Dell BIOS complain of problems. > But I suppose that all computers made by Dell affected by this bug use > BIOS build 3066. So you could scan for "3066Intel(r)", although I don't > think this would be a good idea. Dell could release a BIOS update or > other computers from other companies with a different build number could > be affected, too. Right, so a combination of the build number and something else would nail it down furthur. > So, why not continue to use a configuration option? I don't see any > problems caused by not calling this particular function. I don't mind leaving the option in, but it's nice to be able to print out the detected monitor information for those BIOS' that actually work. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver
Hi, Alan Hourihane schrieb: > Is there a string 'DELL' or similar in the BIOS that we can use the > function xf86ReadBIOS() to detect this buggy BIOS and skip using this > function call in this case ? No, there is no reference to Dell in the BIOS. I'm not even sure if they configure the BIOS. I just know that there is the possibility to do so and that the faulty table is in an area where some values can be configured by the OEM. So it doesn't need to be a bug introduced by Dell, it's just one possible explanation. But I suppose that all computers made by Dell affected by this bug use BIOS build 3066. So you could scan for "3066Intel(r)", although I don't think this would be a good idea. Dell could release a BIOS update or other computers from other companies with a different build number could be affected, too. So, why not continue to use a configuration option? I don't see any problems caused by not calling this particular function. CU Christian PS: Some video BIOS developer must be a fan of Star Wars. A string I found in all BIOS versions I had a look at was "Use the force Luke". ;-) -- Christian Zietz - CHZ-Soft - [EMAIL PROTECTED] WWW: http://chzsoft.com.ar/ - Fido: Christian [EMAIL PROTECTED]:2437/74.9 PGP-Key auf Anfrage oder ueber http://wwwkeys.de.pgp.net (Port 11371) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver
On Mon, Feb 23, 2004 at 06:19:46PM +0100, Christian Zietz wrote: > Hi, > > Egbert Eich schrieb: > > > I think it would be worthwhile to investigate the origin or the problem > > and report it to Intel to fix it in the BIOS - in case they have broken > > something. It looks like an endless loop to me. > > I made some research with a little tool of mine which allows me to load > and use another BIOS than the pre-installed one. (This tool is NOT going > to be released.) > The BIOS dump I got from an Inspiron 510m crashes under DOS, too. This > crash only occurs for CX (device number) 0x01. It's not an endless loop > but a jump to "nowhere". Let me explain: Depending on the device number > the address of the function to call is taken from a table. This fails > for device 1 and isn't properly caught so a jump to the middle of some > other (totally unrelated) function is executed. That obviously leads to > the crash. > BIOS build 3197 (which can be obtained from the Intel web site) doesn't > have that bug. Since the table with the addresses is in the (partially) > user configurable BIOS data block, the missing table entry could also be > a configuration error made by Dell. But as Dell's policy towards Linux > is "we don't support it", chances are low to get a new BIOS asking there. Christian, Is there a string 'DELL' or similar in the BIOS that we can use the function xf86ReadBIOS() to detect this buggy BIOS and skip using this function call in this case ? Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver
Hi, I just forgot to say, that BIOS build 3197 is newer than the one installed on the new Dell machines (build 3066). So if it was an error by Intel they already fixed it. CU Christian ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver
Hi, Egbert Eich schrieb: > I think it would be worthwhile to investigate the origin or the problem > and report it to Intel to fix it in the BIOS - in case they have broken > something. It looks like an endless loop to me. I made some research with a little tool of mine which allows me to load and use another BIOS than the pre-installed one. (This tool is NOT going to be released.) The BIOS dump I got from an Inspiron 510m crashes under DOS, too. This crash only occurs for CX (device number) 0x01. It's not an endless loop but a jump to "nowhere". Let me explain: Depending on the device number the address of the function to call is taken from a table. This fails for device 1 and isn't properly caught so a jump to the middle of some other (totally unrelated) function is executed. That obviously leads to the crash. BIOS build 3197 (which can be obtained from the Intel web site) doesn't have that bug. Since the table with the addresses is in the (partially) user configurable BIOS data block, the missing table entry could also be a configuration error made by Dell. But as Dell's policy towards Linux is "we don't support it", chances are low to get a new BIOS asking there. CU Christian -- Christian Zietz - CHZ-Soft - [EMAIL PROTECTED] WWW: http://chzsoft.com.ar/ - Fido: Christian [EMAIL PROTECTED]:2437/74.9 PGP-Key auf Anfrage oder ueber http://wwwkeys.de.pgp.net (Port 11371) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: my Radeon 8500 log
Fred Heitkamp wrote: It was suggested I post my log to the list. OpenGL programs from xscreensaver lock up my Linux hard. Do other GL applications, such as glxgears, work? Do the xscreensaver hacks work when run directly from the command line? (**) RADEON(0): Option "BackingStore" (**) RADEON(0): Backing store enabled Could you try with backing store disabled? That configuration isn't commonly tested with 3D acceleration, so it's possible, however unlikely, that some bugs may have crept in related to that. Also, are any messages logged to /var/log/dmesg? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Problems with RC3
Hi! Am 23.02.2004 um 01:39 schrieb Chris Rankin: Hi, I have installed the RC3 release of XFree86 4.4, and I have noticed a couple of issues. Firstly, the /usr/X11R6/lib/X11/config/ directory is missing. You should look into your install.log hopefully catched during 'make install'. Whenever I had missing files after an X11 buiid, I was able to find errors during the build process in makes log files. 73, Mario -- Mario Klebsch [EMAIL PROTECTED] PGP-Key available at http://www.klebsch.de/public.key Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0 Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
fwd: gasoline prices too high?
RE: increase your gas mileage by 27%+ This amazing, revolutionary device Increases Gas Mileage 27%+ by helping fuel burn better using three patented processes from General Motors. Just snap this amazing Fuel saving device over your fuel supply line and it will begin working immediately! http://www.bacug.com?axel=53
Re: version 4.4.0-rc2
On Mon, Feb 23, 2004 at 12:21:41PM +0200, Jarmo wrote: > Hope this is right place to send... Could you please STOP sending DUPES of this 40KB mail to [EMAIL PROTECTED] Bernd ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
version 4.4.0-rc2
Hope this is right place to send... Every time I startx get: Feb 22 21:41:01 oh1mrr kernel: mtrr: 0xe000,0x400 overlaps existing 0xe000,0x100 Feb 22 21:41:01 oh1mrr kernel: mtrr: 0xe000,0x400 overlaps existing 0xe000,0x100 Feb 22 21:41:01 oh1mrr kernel: [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held Feb 22 21:41:01 oh1mrr kernel: [drm:radeon_unlock] *ERROR* Process 1256 using kernel context 0 Feb 22 21:41:02 oh1mrr kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0). Feb 22 21:41:02 oh1mrr kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly. And here's my XFree86.log: XFree86 Version 4.3.99.902 (4.4.0 RC 2) Release Date: 18 December 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.25-0.pre7.1mdkenterprise i686 [ELF] Current Operating System: Linux oh1mrr.ampr.org 2.6.2 #2 Thu Feb 5 21:02:53 EET 2004 i686 Build Date: 06 February 2004 Changelog Date: 04 February 2004 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Sun Feb 22 21:41:00 2004 (==) Using config file: "/etc/X11/XF86Config-4" (==) ServerLayout "layout1" (**) |-->Screen "screen1" (0) (**) | |-->Monitor "monitor1" (**) | |-->Device "device1" (**) |-->Input Device "Keyboard1" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "fi" (**) XKB: layout: "fi" (WW) Option "XkbOptions" requires an string value (==) Keyboard: CustomKeycode disabled (**) |-->Input Device "Mouse1" (**) FontPath set to "unix/:-1" (==) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (**) Option "AllowMouseOpenFail" (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.7 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="The XFree86 Project" compiled for 4.3.99.902, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor="The XFree86 Project" compiled for 4.3.99.902, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.7 Using vt 7 (--) using VT number 7 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1106,3189 card 1106,3189 rev 80 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1106,b198 card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:0a:0: chip 10ec,8139 card 1259,2503 rev 10 class 02,00,00 hdr 00 (II) PCI: 00:0b:0: chip 1274,5000 card 4942,4c4c rev 01 class 04,01,00 hdr 00 (II) PCI: 00:0d:0: chip 10ec,8029 card 10ec,8029 rev 00 class 02,00,00 hdr 00 (II) PCI: 00:0f:0: chip 1106,0571 card 1106,0571 rev 06 class 01,01,8a hdr 00 (II) PCI: 00:11:0: chip 1106,3227 card 1106,3227 rev 00 class 06,01,00 hdr 80 (II) PCI: 00:13:0: chip 1106,3044 card 0611,4430 rev 80 class 0c,00,10 hdr 00 (II) PCI: 01:00:0: chip 1002,5144 card 1002,001a rev 00 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000c (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0x9000 - 0x90ff (0x100) IX[B] [1] -1 0 0x9400 - 0x94ff (0x100) IX[B] [2] -1 0 0x9800 - 0x98ff (0x100) IX[B] [3] -1 0 0x9c00 - 0x9cff (0x100) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xec00 - 0xedff (0x200) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xe000 - 0xe7ff (0x800) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:17:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (--) PCI:*(1:0:0) ATI Technologies Inc Radeon R100 QD [Radeon 7200] rev 0, Mem @ 0xe000/27, 0xed00/19, I/O @ 0x9000/8 (II) Addr
version 4.4.0-rc2
Hope this is right place to send... Every time I startx get: Feb 22 21:41:01 oh1mrr kernel: mtrr: 0xe000,0x400 overlaps existing 0xe000,0x100 Feb 22 21:41:01 oh1mrr kernel: mtrr: 0xe000,0x400 overlaps existing 0xe000,0x100 Feb 22 21:41:01 oh1mrr kernel: [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held Feb 22 21:41:01 oh1mrr kernel: [drm:radeon_unlock] *ERROR* Process 1256 using kernel context 0 Feb 22 21:41:02 oh1mrr kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0). Feb 22 21:41:02 oh1mrr kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly. And here's my XFree86.log: XFree86 Version 4.3.99.902 (4.4.0 RC 2) Release Date: 18 December 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.25-0.pre7.1mdkenterprise i686 [ELF] Current Operating System: Linux oh1mrr.ampr.org 2.6.2 #2 Thu Feb 5 21:02:53 EET 2004 i686 Build Date: 06 February 2004 Changelog Date: 04 February 2004 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Sun Feb 22 21:41:00 2004 (==) Using config file: "/etc/X11/XF86Config-4" (==) ServerLayout "layout1" (**) |-->Screen "screen1" (0) (**) | |-->Monitor "monitor1" (**) | |-->Device "device1" (**) |-->Input Device "Keyboard1" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "fi" (**) XKB: layout: "fi" (WW) Option "XkbOptions" requires an string value (==) Keyboard: CustomKeycode disabled (**) |-->Input Device "Mouse1" (**) FontPath set to "unix/:-1" (==) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (**) Option "AllowMouseOpenFail" (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.7 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="The XFree86 Project" compiled for 4.3.99.902, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor="The XFree86 Project" compiled for 4.3.99.902, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.7 Using vt 7 (--) using VT number 7 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1106,3189 card 1106,3189 rev 80 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1106,b198 card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:0a:0: chip 10ec,8139 card 1259,2503 rev 10 class 02,00,00 hdr 00 (II) PCI: 00:0b:0: chip 1274,5000 card 4942,4c4c rev 01 class 04,01,00 hdr 00 (II) PCI: 00:0d:0: chip 10ec,8029 card 10ec,8029 rev 00 class 02,00,00 hdr 00 (II) PCI: 00:0f:0: chip 1106,0571 card 1106,0571 rev 06 class 01,01,8a hdr 00 (II) PCI: 00:11:0: chip 1106,3227 card 1106,3227 rev 00 class 06,01,00 hdr 80 (II) PCI: 00:13:0: chip 1106,3044 card 0611,4430 rev 80 class 0c,00,10 hdr 00 (II) PCI: 01:00:0: chip 1002,5144 card 1002,001a rev 00 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000c (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0x9000 - 0x90ff (0x100) IX[B] [1] -1 0 0x9400 - 0x94ff (0x100) IX[B] [2] -1 0 0x9800 - 0x98ff (0x100) IX[B] [3] -1 0 0x9c00 - 0x9cff (0x100) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xec00 - 0xedff (0x200) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xe000 - 0xe7ff (0x800) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:17:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (--) PCI:*(1:0:0) ATI Technologies Inc Radeon R100 QD [Radeon 7200] rev 0, Mem @ 0xe000/27, 0xed00/19, I/O @ 0x9000/8 (II) Addr
sugper viagrga, ashley be big man in bed beggar
fabuklous! I took the only one pijll of Cialgs and that was such a GREAT weekend! All the girls at the party were just punch-drungk with my potentiagl I have fgcked all of them THREE times but my dgck WAS able to do some more! Cgalis - it`s COOL!!! The best weekend stuff I've ever trgied! Haven`t you tgried yet? Shipped world wide! DO IT at http://medspro.net/sv/index.php?pid=evaph6163 http://medspro.net/sv/index.php?pid=evaph6163 austin breadroot
version 4.4.0-rc2
Hope this is right place to sen... Every time I startx get: Feb 22 21:41:01 oh1mrr kernel: mtrr: 0xe000,0x400 overlaps existing 0xe000,0x100 Feb 22 21:41:01 oh1mrr kernel: mtrr: 0xe000,0x400 overlaps existing 0xe000,0x100 Feb 22 21:41:01 oh1mrr kernel: [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held Feb 22 21:41:01 oh1mrr kernel: [drm:radeon_unlock] *ERROR* Process 1256 using kernel context 0 Feb 22 21:41:02 oh1mrr kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0). Feb 22 21:41:02 oh1mrr kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly. And here's my XFree86.log: XFree86 Version 4.3.99.902 (4.4.0 RC 2) Release Date: 18 December 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.25-0.pre7.1mdkenterprise i686 [ELF] Current Operating System: Linux oh1mrr.ampr.org 2.6.2 #2 Thu Feb 5 21:02:53 EET 2004 i686 Build Date: 06 February 2004 Changelog Date: 04 February 2004 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Sun Feb 22 21:41:00 2004 (==) Using config file: "/etc/X11/XF86Config-4" (==) ServerLayout "layout1" (**) |-->Screen "screen1" (0) (**) | |-->Monitor "monitor1" (**) | |-->Device "device1" (**) |-->Input Device "Keyboard1" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "fi" (**) XKB: layout: "fi" (WW) Option "XkbOptions" requires an string value (==) Keyboard: CustomKeycode disabled (**) |-->Input Device "Mouse1" (**) FontPath set to "unix/:-1" (==) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (**) Option "AllowMouseOpenFail" (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.7 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="The XFree86 Project" compiled for 4.3.99.902, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor="The XFree86 Project" compiled for 4.3.99.902, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.7 Using vt 7 (--) using VT number 7 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1106,3189 card 1106,3189 rev 80 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1106,b198 card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:0a:0: chip 10ec,8139 card 1259,2503 rev 10 class 02,00,00 hdr 00 (II) PCI: 00:0b:0: chip 1274,5000 card 4942,4c4c rev 01 class 04,01,00 hdr 00 (II) PCI: 00:0d:0: chip 10ec,8029 card 10ec,8029 rev 00 class 02,00,00 hdr 00 (II) PCI: 00:0f:0: chip 1106,0571 card 1106,0571 rev 06 class 01,01,8a hdr 00 (II) PCI: 00:11:0: chip 1106,3227 card 1106,3227 rev 00 class 06,01,00 hdr 80 (II) PCI: 00:13:0: chip 1106,3044 card 0611,4430 rev 80 class 0c,00,10 hdr 00 (II) PCI: 01:00:0: chip 1002,5144 card 1002,001a rev 00 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000c (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0x9000 - 0x90ff (0x100) IX[B] [1] -1 0 0x9400 - 0x94ff (0x100) IX[B] [2] -1 0 0x9800 - 0x98ff (0x100) IX[B] [3] -1 0 0x9c00 - 0x9cff (0x100) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xec00 - 0xedff (0x200) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xe000 - 0xe7ff (0x800) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:17:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (--) PCI:*(1:0:0) ATI Technologies Inc Radeon R100 QD [Radeon 7200] rev 0, Mem @ 0xe000/27, 0xed00/19, I/O @ 0x9000/8 (II) Addres
Re: i855GM: New BIOS breaks i810-driver
Christian Zietz writes: > Hi, > > as I already pointed out some of the users affected by the problem don't > want to or aren't able to build XFree86 out of the CVS sources. > So I wrote a small hack which wraps around int 0x10 and prevents the > function in question (ax=0x5f64, bx=0x0300) from being called. I'm aware > that that's a much dirtier solution to the problem than the patched > driver but nonetheless I think it might be useful for people who want to > use the precompiled XFree86 that came with their distribution. > > Download URL for 855wrap: http://www.chzsoft.com.ar/855wrap.tar.gz > I think it would be worthwhile to investigate the origin or the problem and report it to Intel to fix it in the BIOS - in case they have broken something. It looks like an endless loop to me. Since the problem appears both to happen inside the emulator and vm86 mode it points to the BIOS however we cannot say for sure. One may want to try to set up registers and execute this command from 'debug' inside DOS to see if this ends up in an endless loop also. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Problems with RC3
On Mon, 23 Feb 2004, [iso-8859-1] Chris Rankin wrote: > Secondly, there are no "pex5" and "xie" modules in > /usr/X11R6/lib/modules/extensions/. Now I never knew > what these modules did, and I suspect that they might > have been removed before 4.4 because I've previously > "overlaid" the new XFree86 release on top on the > existing one. (Having made a copy, of course.) pex5, the PHIGS extension for X, and xie, the X Image Extension were not built by default in 4.3 (although I believe that they still built if you changed build options appropriately). I doubt that they have recieved any significant testing since then, so they may have suffered software rot. > Should I delete these from my installation and config file > instead? I haven't found anything about these modules > in the RELNOTES for either 4.3 or 4.4. I would indeed delete these from your install and config. -- Andrew C. Aitchison Cambridge [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
