linuxconsole-dev

Re: Two Nvidia cards, and black screen

[<ce...@ri...>]

han...@sa... a =E9crit :
> I disabled NVRestore from the nv driver, and now the monitor won't go t=
o=20
> sleep anymore, however the picture on the monitor freezes (all movement=
=20
> stops), the mouse-pointer dissapears, and input from the keyboard is no=
t=20
> accepted anymore.
>=20
> As soon as I stop the second X server, activity on the first X server=20
> resumes (mouse and keyboad become active again). So things are moving i=
n=20
> the right direction. Would you have any idea what to do about the=20
> freezing of the mouse/keyboad?

Did you disable NVSync() and NVLockUnlock() issued at the same time ? if=20
not, try to suppress them.

C=E9dric

Re: Two Nvidia cards, and black screen

[<ce...@ri...>]

han...@sa... a =E9crit :
> Am I still correct to assume that at least in theory it would be=20
> possible to modify the int10 module (whereas you have modified the=20
> radeon driver) to get the around the problem?

I don't think so but there is an interesting option to try:

Screen Section
Option "NoInt10" "boolean"
Disables the Int10 module, a module that uses the int10 call to the BIOS
of the graphics card to initialize it. Default: false.

I'm still thinking that the cause of the screen blanking is the driver
which try to restore the console in VGA text mode at shutdown.

C=E9dric

Re: Two Nvidia cards, and black screen

[<han...@sa...>]

Hi,

I disabled NVRestore from the nv driver, and now the monitor won't go to=20
sleep anymore, however the picture on the monitor freezes (all movement=20
stops), the mouse-pointer dissapears, and input from the keyboard is not=20
accepted anymore.

As soon as I stop the second X server, activity on the first X server=20
resumes (mouse and keyboad become active again). So things are moving in=20
the right direction. Would you have any idea what to do about the=20
freezing of the mouse/keyboad?

Thanks,
Hans

>=20
> After reading vgahw, radeon and nv source code, it seems to me that both
> problems (blanc screen and DPMS) are related to vgahw functions call.
>=20
> I'm afraid there's no solution with the stock drivers because I presume
> there is a ressource conflict on VGA IOs between the two cards.
>=20
> I would suggest to use a modified nv driver for the secondary card to
> prevent messing the primary card settings. I guess the function=20
> NVRestore should be disabled to prevent the blank the screen at shutdown.=
=20
> As for DPMS, I didn't look at it yet.
>=20
> C=E9dric
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev

Re: Two Nvidia cards, and black screen

[<han...@sa...>]

Hi,

I noticed the closed source nvidia driver has the following option:

Option "UseInt10Module" "boolean"

    Enable use of the X Int10 module to soft-boot all secondary cards,
    rather than POSTing the cards through the NVIDIA kernel module.
    Default: off (POSTing is done through the NVIDIA kernel module).

I tried using this option, first on one , then one the other, and=20
finally on both cards, but to no effect (other then some error message=20
about accessing the vga bios on one card).

Am I still correct to assume that at least in theory it would be=20
possible to modify the int10 module (whereas you have modified the=20
radeon driver) to get the around the problem?

I will try to use a modified nv driver as you suggested later today.

Thanks for all your help!

-Hans

>=20
> After reading vgahw, radeon and nv source code, it seems to me that both
> problems (blanc screen and DPMS) are related to vgahw functions call.
>=20
> I'm afraid there's no solution with the stock drivers because I presume
> there is a ressource conflict on VGA IOs between the two cards.
>=20
> I would suggest to use a modified nv driver for the secondary card to
> prevent messing the primary card settings. I guess the function=20
> NVRestore should be disabled to prevent the blank the screen at shutdown.=
=20
> As for DPMS, I didn't look at it yet.
>=20
> C=E9dric
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev

Re: Two Nvidia cards, and black screen

[<ce...@ri...>]

han...@sa... a =E9crit :
> Right now there is one thing that really disturbs me, and that is the=20
> fact that after 6 hours of playing around with the X servers today, I=20
> once got both displays up and running perfectly, but just once. The next=
=20
> time I tried it with exactly the same settings, once again it didn't work.
>=20
> Another thing that I have noticed is that I can change back and forth=20
> between both running xservers by using either "xset -dpms -display :0.0"=
=20
> or "xset -dpms -display :1.0". This will wake up the monitor of one X=20
> server, while putting to sleep the other ones monitor and vice/versa.
>=20
> I'm not giving up yet though ;) I must have missed something.. I have=20
> also been trying with the opensouce "nv" driver, but get the same results.

After reading vgahw, radeon and nv source code, it seems to me that both
problems (blanc screen and DPMS) are related to vgahw functions call.

I'm afraid there's no solution with the stock drivers because I presume
there is a ressource conflict on VGA IOs between the two cards.

I would suggest to use a modified nv driver for the secondary card to
prevent messing the primary card settings. I guess the function=20
NVRestore should be disabled to prevent the blank the screen at shutdown.=20
As for DPMS, I didn't look at it yet.

C=E9dric

Re: Two Nvidia cards, and black screen

[<han...@sa...>]

Hi,

Thanks for the information. It seems like mode switching doesn't help.

Right now there is one thing that really disturbs me, and that is the=20
fact that after 6 hours of playing around with the X servers today, I=20
once got both displays up and running perfectly, but just once. The next=20
time I tried it with exactly the same settings, once again it didn't=20
work.

Another thing that I have noticed is that I can change back and forth=20
between both running xservers by using either "xset -dpms -display :0.0"=20
or "xset -dpms -display :1.0". This will wake up the monitor of one X=20
server, while putting to sleep the other ones monitor and vice/versa.

I'm not giving up yet though ;) I must have missed something.. I have=20
also been trying with the opensouce "nv" driver, but get the same=20
results.

I'll have to contiunue tomorrow.

-Hans

> Your problem looks similar to the one encountered with radeon cards.
> Except you state that the first display is turned off without vga
> signal. A Radeon card keeps the VGA signal up but the display is black=20
> and can be restored by video mode switching (Ctrl-Alt- /-).
>=20
> In your case, without VGA signal, it shouldn't be possible to restore
> the display but you could check just in case.
>=20
> As explained in my previous mail, the problem occurs when the second
> card do VGA IOs at initialization. Regarding the open source driver
> those functions are provided by the vgahw module (see
> http://www.x.org/X11R6.8.2/doc/DESIGN19.html for details). The log=20
> entries are shown below:
>=20
> (II) Loading sub module "vgahw"
> (II) LoadModule: "vgahw"
> (II) Loading /usr/X11R6/lib/modules/libvgahw.a
> (II) Module vgahw: vendor=3D"X.Org Foundation"
>          compiled for 6.8.2, module version =3D 0.1.0
>          ABI class: X.Org Video Driver, version 0.7
> (II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is=
=20
> 0x0000
>=20
> I don't know if the close source nvidia driver uses this module or
> access the VGA registers by itself. Anyway the only solution is to
> modify the driver to disable VGA IOs.
>=20
> This has been done with the "VGAAccess" option for radeon and rage128=20
> drivers in the following patches posted in the xorg bugzilla:
> https://bugs.freedesktop.org/show_bug.cgi?id=3D2064
> https://bugs.freedesktop.org/show_bug.cgi?id=3D2089
>=20
> Regarding nvidia, you might ask them to implement this feature in their
> driver.
>=20
> Regards,
> C=E9dric
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev

Re: Two Nvidia cards, and black screen

[<ce...@ri...>]

han...@sa... a =E9crit :
> I have 1 NVIDIA Gefore FX 5200 PCI, and one NVIDIA Gefore 6600 PCI-E=20
> card. I have both X servers set up correctly so that they run without=20
> any problem seperatly (with different keyboards and mice). Both X=20
> servers use the nvidia close source 6629 driver.
>=20
> My problem is that whenever I try to start the second X server, while=20
> the first one is already running, the monitor connected to the first X=20
> server goes black (monitor is turned off/signal lost). The xserver=20
> itself however continues running, and all applications (like music from=
=20
> xmms) also continue running. There are no errors in any log files. Ther=
e=20
> is no difference when trying to start the X servers in the opposite=20
> order. Starting the second X server always kills the display of the one=
=20
> already running.

Your problem looks similar to the one encountered with radeon cards.
Except you state that the first display is turned off without vga
signal. A Radeon card keeps the VGA signal up but the display is black=20
and can be restored by video mode switching (Ctrl-Alt-+/-).

In your case, without VGA signal, it shouldn't be possible to restore
the display but you could check just in case.

As explained in my previous mail, the problem occurs when the second
card do VGA IOs at initialization. Regarding the open source driver
those functions are provided by the vgahw module (see
http://www.x.org/X11R6.8.2/doc/DESIGN19.html for details). The log=20
entries are shown below:

(II) Loading sub module "vgahw"
(II) LoadModule: "vgahw"
(II) Loading /usr/X11R6/lib/modules/libvgahw.a
(II) Module vgahw: vendor=3D"X.Org Foundation"
         compiled for 6.8.2, module version =3D 0.1.0
         ABI class: X.Org Video Driver, version 0.7
(II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is=20
0x0000

I don't know if the close source nvidia driver uses this module or
access the VGA registers by itself. Anyway the only solution is to
modify the driver to disable VGA IOs.

This has been done with the "VGAAccess" option for radeon and rage128=20
drivers in the following patches posted in the xorg bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=3D2064
https://bugs.freedesktop.org/show_bug.cgi?id=3D2089

Regarding nvidia, you might ask them to implement this feature in their
driver.

Regards,
C=E9dric

Two Nvidia cards, and black screen

[<han...@sa...>]

Hi!

I have 1 NVIDIA Gefore FX 5200 PCI, and one NVIDIA Gefore 6600 PCI-E 
card. I have both X servers set up correctly so that they run without 
any problem seperatly (with different keyboards and mice). Both X 
servers use the nvidia close source 6629 driver.

My problem is that whenever I try to start the second X server, while 
the first one is already running, the monitor connected to the first X 
server goes black (monitor is turned off/signal lost). The xserver 
itself however continues running, and all applications (like music from 
xmms) also continue running. There are no errors in any log files. There 
is no difference when trying to start the X servers in the opposite 
order. Starting the second X server always kills the display of the one 
already running.

I have tried to turn the monitor back on with "xset dpms dorce on 
-display :0.0", but this doesn't help.

I'm running x.org 6.8.2 with the IsloateDevice patch. I'm actually not 
running ruby anymore, but I'm using the evdev driver for the separate 
keyboards/mice (https://bugs.freedesktop.org/show_bug.cgi?id=968), so in 
a sence I'm posting to the "wrong" list, but I guess people here are the 
most experienced with these kind of setups.

The PCI card is also set as the primary graphics card in bios, otherwise 
it didn't work at all.

Thanks for any help on this!

-Hans

Patches of interest for ATI cards based multi-seats setup

[<ce...@ri...>]

Hi all,

I recently discovered a new option for radeon and r128 driver in Debian xorg 
package:

Option "VGAAccess" "boolean"
Tell the driver if it can do legacy VGA IOs to the card. This is necessary for 
properly resuming consoles when in VGA text mode, but shouldn't be if the 
console is using radeonfb or some other graphic mode driver. Some platforms 
like PowerPC have issues with those, and they aren't necessary unless you 
have a real text mode in console. The default is off on PowerPC and on on 
other architectures.

When set to "off", It solves the issue of secondary radeon card messing up the 
primary one while reinitiliazing.

Those patches are extracted from freedesktop.org xorg CVS HEAD and are 
registered in bugzilla.

See : https://bugs.freedesktop.org/show_bug.cgi?id=2064 for radeon
and: https://bugs.freedesktop.org/show_bug.cgi?id=2089 for r128

Cheers, Cedric

=?iso-8859-1?Q?CIAL=EDSS_V=C0LLlUM_ViAGRR=E0?=

[Raiden P. <Ra...@ju...>]

Hello, 
another.  Already he had hit upon that other.  For such a voyage aIf some =
other planter had bought me, he explained, it is oddsCHAPTER XVIIsilence =
they stared with him across the water at that other ship.your surrender =
I require, my man, not your impudence.as you, Don Diego, are my =
prisoner.telling ye.any other woman of his acquaintance would have =
preserved herleft behind.  It was because of these that they must go =
cautiouslyVery early next morning, before the heat of the day came to =
rendercoast of Hispaniola.  She was on her way from Plymouth to =
Jamaica,asked almost too eagerly:In pain, is he?  I hope he is, the =
damned piratical dog.  But willof this he was belatedly glad to avail =
himself of the skill of Peterinterest in him.  Himself, he was never =
disposed to linger.  He wasplainly written on his enormous yellowish =
countenance.  At his side,

Re: Secondary graphics card and x86_64

[Wayne W. <wh...@po...>]

Hello again,

For the record, I did finally manage to get two Radeon 7000 cards working 
on the Abit AV8 Athlon64 motherboard.  The solution, as previously posted 
here, was to set the PCI card as the boot display in the BIOS.  In my 
case, that was only possible after an updated BIOS was released earlier 
this month, as the previous BIOS had a problem with this configuration.

Cheers, Wayne

Ruby patched 2.6.11 or 2.6.12 kernel for Mandrake(Mandriva)

[yitzhak b. g. <yit...@ya...>]

Can someone point me to where I can obtain a Mandriva
2.6.12 or 2.6.11 kernel with Ruby patches?
Yitzhak

Re: ruby and lirc

[Ludovic P. <pl...@fr...>]

Hello,

I have no problem with 2.6.11 backstreet+lirc. Did not try any other 2.6.=
x...
Your problem may not be related to backstreet at all...

In my case (lirc_atiusb), there is a module included in vanilla 2.6.x whi=
ch=20
treat my remote as a keyboard. I had to remove it and use lirc own module=
 to=20
make things work.

Hope it helps !

Ludovic

Le Samedi 16 Juillet 2005 15:07, Andrej van der Zee a =E9crit :
> Hi,
>
> Does anybody know if LIRC can work together with
> Backstreet Ruby? If so, which kernel version do you
> suggest? I tried it on 2.6.7 and LIRC starts fine but
> it does not respond to any input from my remote
> control.
>
> Thank!
>
> Andrej
>
>
>
>
>
> ___________________________________________________________
> How much free photo storage do you get? Store your holiday
> snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl=
ick
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev

scollback patch

[Hugo V. <hvw...@ya...>]

Hi,

Steve Young posted a scollback patch on 7/12/2005 that
I get errors, but also an unexpected eof. It does not
look right at the end. Can that be posted again or a
link be given?

Thanks!

Hugo

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

ruby and lirc

[Andrej v. d. Z. <ma...@ya...>]

Hi,

Does anybody know if LIRC can work together with
Backstreet Ruby? If so, which kernel version do you
suggest? I tried it on 2.6.7 and LIRC starts fine but
it does not respond to any input from my remote
control. 

Thank!

Andrej




		
___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

Xorg + closed source Nvidia

[Hugo V. <hvw...@ya...>]

Hi,

I discovered what my problem is with Xorg, now that it
has made it as the X-window-system in Debian Unstable.

Currently run TNT2 on AGP and MX-440 on PCI and the
7167 Nvidia closed source driver.

Not being a gamer I never had these in my
XF86Config-4:

	Option      "RenderAccel" 		"true"
	Option 	    "AllowGLXWithComposite" 	"true"

But trying Xorg the docs say to turn those on and...

The X server that you will be using will peg at 100%
and hang in a tight loop.

The gory details are here:
http://www.nvnews.net/vbulletin/showthread.php?t=31858&page=1&pp=15

That forum also mentions it is a sigalarm loop in the
driver.

That bug has been around for a long time and
apparently not about to be fixed.

How did anybody game with Nvidia? Who knows I am not a
gamer.

I would be grateful for card recommendations. Now I am
thinking of 2 dvi Matrox cards because Mark Hurenkamp
reported that he had vc's running on 4 heads with
2.6.9.

Thanks.

Hugo



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Secondary graphics card and x86_64

[Wayne W. <wh...@po...>]

Hello,

I've recently upgraded my ruby system (dual Radeon 7000) from AthlonXP 
(ECS K7S5A) to Athlon64 (ABit AV8), and I can no longer get my secondary 
graphics card to work.  Attempting to access it with X.org X (or with X 
-configure) locks up the machine; there is no Xorg.log to examine. 
Radeonfb finds the card but reports it has no memory; forcing it to assume 
a default memory size also causes a lock up.  Both cards work fine when 
they are the only card in the system.

A previous thread suggested that many x86_64 BIOSes do not properly assign 
PCI resources to secondary video cards.  How would I detect this?  The 
output of 'modprobe radeonfb' followed by lspci is appended below.

I'm really stymied, so any help would be very appreciated.

Thanks, Wayne

# modprobe radeonfb
radeonfb_pci_register BEGIN
PCI: Enabling device 0000:00:0a.0 (0080 -> 0083)
ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 18 (level, low) -> IRQ 18
radeonfb (0000:00:0a.0): Found 0k of SDRAM 64 bits wide videoram
radeonfb (0000:00:0a.0): cannot map FB
radeonfb: probe of 0000:00:0a.0 failed with error -5

[... messages about primary radeon card cut ...]

# lspci -s 00:0a.0 -v -x
00:0a.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA])
         Subsystem: PC Partner Limited: Unknown device 7c02
         Flags: stepping, medium devsel, IRQ 209
         Memory at e0000000 (32-bit, prefetchable) [size=128M]
         I/O ports at ee00 [size=256]
         Memory at fdfe0000 (32-bit, non-prefetchable) [size=64K]
         Capabilities: [50] Power Management version 2
00: 02 10 59 51 83 00 90 02 00 00 00 03 08 00 00 00
10: 08 00 00 e0 01 ee 00 00 00 00 fe fd 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 4b 17 02 7c
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 08 00

PATCH: Move scrollback out of low-level console drivers

[Steve Y. <sd...@mi...>]

  Hello,

  Here is a patch that moves scrollback handling out of the low-level *con 
drivers and into the virtual console layer in vt.c.  It's non-intrusive 
insofar as low-level drivers that do not take advantage of it continue to 
function as usual, but drivers that do want to use it (eg, vgacon after 
this patch is applied) can do so through a rather simple API.  Basically a 
low-level driver signals it wants the vt layer to maintain scrollback through 
vc_data->vc_use_scrollback, and then grabs chunks of scrollback by calling
vt_get_scrollback from the consw->con_scrolldelta function.  The payoff for
users is (a) scrollback can now be an arbitrary length, limited only by
memory and (b) scrollback is preserved between console switches, something
vgacon/etc are unable to do when they are relying solely on origin tricks
to make scrollback happen.

  A few points:
  - ioctls are used to control the vt scrollback.  This is probably not the
best way to do it, but I wasn't sure if procfs, sysfs, or sysctl were the
way to go.  If anyone can recommend a better way to do it I'd be happy to
implement it.
  - A userspace program, cfgscroll (attached) is used to configure scrollback.
It has reasonable defaults, but cfgscroll -e needs to be called to enable
scrollback.  This is because we can't start saving scrollback before kmalloc
works, and I couldn't determine a reasonable way to find out if kmalloc is 
working yet (is there some kind of kmalloc_running flag somewhere?).
The source is junky because hopefully it will go away.
  - /dev/vcs* will return whatever is really on the screen, so if the
user is in the middle of scrollback that's what vcs will return.
If/when gpm starts using the vcs devices, this means users will be able
to select text out of scrollback.
  - This patch is against 2.6.13-rc1-mm1.

  Finally, this is my first attempt at a kernel patch so there's probably some
other things that will need attention.  Any constructive criticism would be
appreciated - hopefully this patch doesn't clash with the work being
done by the linuxconsole folks.

  Thanks,
  Steve.

Better Medz Liife

[Teca E. <Ell...@ga...>]

Hello, 
sprung upon Captain Blood, who stood aloof, alert, tight-lipped,impression. =
 They beheld a town of sufficiently imposing proportionswho have read =
Esquemeling may be in danger of supposing that Henryup again, indicating =
the prisoners.Briefly and clearly he announced to all the object of Lord =
Julian'sremove great part of the wealth this city holds.  We must take =
thema self-sufficient man.having abandoned their work upon finding =
themselves unguarded andbetween your fingers ye'd grow more =
communicative?knees before her brother to implore his pardon for all the =
evilHe becomes your affair.  You are now the Governor.  You will dealto =
be hanged in Port Royal.have a mutiny aboard, and I'll lead it myself =
sooner than surrenderknew each detail of it so well that it was =
impossible he could nowbefore the Spanish Admiral.  Then he bowed stiff =
and formally.  Ablazed out at last.

Re: Ruby cvs 2.6.12 did not compile

[Stefan N. <neu...@tr...>]

Daniel Sobe <har...@se...> writes:

> Am Samstag, den 02.07.2005, 18:11 +0200 schrieb Stefan Neuwirth:
>> Just a guess screenbuf is vc->vc_screenbuf, but then you get:
>> 
>>   CC      drivers/char/vt.o
>> drivers/char/vt.c: In function `take_over_console':
>> drivers/char/vt.c:1912: error: structure has no member named `vc_size_rows'
>> make[2]: *** [drivers/char/vt.o] Error 1
>> make[1]: *** [drivers/char] Error 2
>> make: *** [drivers] Error 2
>> 
>> Changing vc_size_rows to vc_size_row makes things compilable, don't
>> know if it working with the changes...
>
> I had to fix more things (checked out CVS today) to have the kernel
> compile. I found that I had to change "pci_name_bus(name, bus)" to
> "pci_proc_domain(bus)" in drivers/pci/proc.c, add a forward declaration
> of "struct input_handle *input_find_handle(char *phys_descr);" to
> drivers/char/vt_proc.c and to change every occurence of "vt_kmalloced"
> to "kmalloced".
>
> Still, I get an error very early when booting. I cannot capture the full
> output; the trace looks like this:
>
> ret_from_fork
> init
> spawn_ksoftirqd
>
> The diff between 2.6.12.2 and the CVS is attached including the compile
> fixes. Does anybody have an idea of what is wrong?

I recently switched to kernel 2.6.13-rc1-mm1-ruby (compiles an runs
without any problem). Due to my very special needs this kernel is the
best kernel I've seen in 2.6.x. But still a lot of problems, for
example matroxfb and framebuffer console.

  Stefan

Re: Ubuntu & xorg 6.8.2-10 patches

[Ken M. <ke...@th...>]

On Sat, 2005-07-09 at 03:33 -0700, Hugo Vanwoerkom wrote:

> 
> --- Ken McCord <ke...@th...> wrote:
> 
> > Mark Hurenkamp wrote:
> > 
> > >>I'm using the pre-experimental Debian packages
> > based on the original
> > >>Ubuntu packages.  The /etc/apt/sources.list line
> > for them is:
> > >>
> > >>deb http://people.debian.org/~dnusinow/xorg ./
> > >>
> > >>With a 2.6.8 kernel, here's a snippet from my
> > xorg.conf file.
> > >>
> > >>
> > >>Section "InputDevice"
> > >>    Identifier "Keyboard"
> > >>    Driver "kbd"
> > >>    
> > >>
> > >^^^ Here's what solved my problem.
> > >I had a line 'Driver "keyboard"' here, which
> > apparently does not work
> > >with evdev.
> > >I replaced it with the line above, and now things
> > work perfectly.
> > >
> > >  
> > >
> > >>    Option "Protocol" "evdev"
> > >>    Option "Dev Phys" "usb-*.0-1.1/input0"
> > >>    # Option "Dev Name" "NMB Dell USB 7HK
> > Keyboard"
> > >>    Option "XkbRules" "xfree86"
> > >>    Option "XkbModel" "pc104"
> > >>    Option "XkbLayout" "us"
> > >>EndSection
> > >>    
> > >>
> >
> 
> Your post made me curious how far xorg had gotten
> along and I installed from the site you mentioned.
> 
> There was another fix needed to avoid mozilla from
> diappearing and wmxmms to show up, from here:
> http://gentoo-wiki.com/TIP_Xorg_X11_and_Transparency#Enabling_shadows_and_real_transparency
> which solved it.
> 
> Then of course the "eyecandy", I found xcompmgr here:
> http://freedesktop.org/xapps/release/ it apparently is
> not with the .debs.
> 
> And to compile that had to install xcomposite, xfixes,
> xdamage and xrender and link pkgconfig for X to where
> he wants it apparently.
> 
> There is a transset on a key here:
> http://forchheimer.se/transset-df/
> 
> But I never got that to run because e16keyedit dies.
> 
> Which brings us to what all that gets you.
> 
> With a 2.1GHz CPU running xcompmgr -c on only 1 X puts
> the CPU at a constant 56% and X is cute to look at but
> in no whay ready to useful work: way to slow on a
> Nvidia TNT with acceleration set.
> 
> Anybody actually use this in a production mode for
> useful work, like answering emails?
> 
> Hugo
> 


1 - Please reread the first sentence - 'pre-experimental Debian
packages'.

2 - They're based on Ubuntu's Hoary Hedgehog packages - why not check
there?  As far as my limited usage, they're working fine.

Ken

Re: Ubuntu & xorg 6.8.2-10 patches

[Hugo V. <hvw...@ya...>]

--- Ken McCord <ke...@th...> wrote:

> Mark Hurenkamp wrote:
> 
> >>I'm using the pre-experimental Debian packages
> based on the original
> >>Ubuntu packages.  The /etc/apt/sources.list line
> for them is:
> >>
> >>deb http://people.debian.org/~dnusinow/xorg ./
> >>
> >>With a 2.6.8 kernel, here's a snippet from my
> xorg.conf file.
> >>
> >>
> >>Section "InputDevice"
> >>    Identifier "Keyboard"
> >>    Driver "kbd"
> >>    
> >>
> >^^^ Here's what solved my problem.
> >I had a line 'Driver "keyboard"' here, which
> apparently does not work
> >with evdev.
> >I replaced it with the line above, and now things
> work perfectly.
> >
> >  
> >
> >>    Option "Protocol" "evdev"
> >>    Option "Dev Phys" "usb-*.0-1.1/input0"
> >>    # Option "Dev Name" "NMB Dell USB 7HK
> Keyboard"
> >>    Option "XkbRules" "xfree86"
> >>    Option "XkbModel" "pc104"
> >>    Option "XkbLayout" "us"
> >>EndSection
> >>    
> >>
>

Your post made me curious how far xorg had gotten
along and I installed from the site you mentioned.

There was another fix needed to avoid mozilla from
diappearing and wmxmms to show up, from here:
http://gentoo-wiki.com/TIP_Xorg_X11_and_Transparency#Enabling_shadows_and_real_transparency
which solved it.

Then of course the "eyecandy", I found xcompmgr here:
http://freedesktop.org/xapps/release/ it apparently is
not with the .debs.

And to compile that had to install xcomposite, xfixes,
xdamage and xrender and link pkgconfig for X to where
he wants it apparently.

There is a transset on a key here:
http://forchheimer.se/transset-df/

But I never got that to run because e16keyedit dies.

Which brings us to what all that gets you.

With a 2.1GHz CPU running xcompmgr -c on only 1 X puts
the CPU at a constant 56% and X is cute to look at but
in no whay ready to useful work: way to slow on a
Nvidia TNT with acceleration set.

Anybody actually use this in a production mode for
useful work, like answering emails?

Hugo














		
____________________________________________________
Sell on Yahoo! Auctions – no fees. Bid on great items.  
http://auctions.yahoo.com/

Re: Running X server in domU? [sorry, sent to wrong list...]

[Mark H. <mar...@xs...>]

Sorry about my previous message,
I accidentally posted it on the wrong list.

Mark.

Six USB Cards

[Alexandre P. T. <ale...@in...>]

Hi Members

I need to configure 6 cards of USB Sound and I would like information if
somebody already configured and if it could inform the models.  


Yours truly
-- 
Alexandre Penasso Teixeira <ale...@in...>
Insigne Free Software do Brasil

Re: Ruby cvs 2.6.12 did not compile

[Daniel S. <har...@se...>]

Am Samstag, den 02.07.2005, 18:11 +0200 schrieb Stefan Neuwirth:
> Just a guess screenbuf is vc->vc_screenbuf, but then you get:
> 
>   CC      drivers/char/vt.o
> drivers/char/vt.c: In function `take_over_console':
> drivers/char/vt.c:1912: error: structure has no member named `vc_size_rows'
> make[2]: *** [drivers/char/vt.o] Error 1
> make[1]: *** [drivers/char] Error 2
> make: *** [drivers] Error 2
> 
> Changing vc_size_rows to vc_size_row makes things compilable, don't
> know if it working with the changes...

I had to fix more things (checked out CVS today) to have the kernel
compile. I found that I had to change "pci_name_bus(name, bus)" to
"pci_proc_domain(bus)" in drivers/pci/proc.c, add a forward declaration
of "struct input_handle *input_find_handle(char *phys_descr);" to
drivers/char/vt_proc.c and to change every occurence of "vt_kmalloced"
to "kmalloced".

Still, I get an error very early when booting. I cannot capture the full
output; the trace looks like this:

ret_from_fork
init
spawn_ksoftirqd

The diff between 2.6.12.2 and the CVS is attached including the compile
fixes. Does anybody have an idea of what is wrong?

Daniel