You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
(235) |
Apr
(30) |
May
(32) |
Jun
(86) |
Jul
(81) |
Aug
(108) |
Sep
(27) |
Oct
(22) |
Nov
(34) |
Dec
(10) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(78) |
Feb
(10) |
Mar
(81) |
Apr
(27) |
May
(13) |
Jun
(105) |
Jul
(78) |
Aug
(52) |
Sep
(59) |
Oct
(90) |
Nov
(127) |
Dec
(49) |
2002 |
Jan
(102) |
Feb
(72) |
Mar
(54) |
Apr
(98) |
May
(25) |
Jun
(23) |
Jul
(123) |
Aug
(14) |
Sep
(52) |
Oct
(65) |
Nov
(48) |
Dec
(48) |
2003 |
Jan
(22) |
Feb
(25) |
Mar
(29) |
Apr
(12) |
May
(16) |
Jun
(11) |
Jul
(20) |
Aug
(20) |
Sep
(43) |
Oct
(84) |
Nov
(98) |
Dec
(56) |
2004 |
Jan
(28) |
Feb
(39) |
Mar
(41) |
Apr
(28) |
May
(88) |
Jun
(17) |
Jul
(43) |
Aug
(57) |
Sep
(54) |
Oct
(42) |
Nov
(32) |
Dec
(58) |
2005 |
Jan
(80) |
Feb
(31) |
Mar
(65) |
Apr
(41) |
May
(20) |
Jun
(34) |
Jul
(62) |
Aug
(73) |
Sep
(81) |
Oct
(48) |
Nov
(57) |
Dec
(57) |
2006 |
Jan
(63) |
Feb
(24) |
Mar
(18) |
Apr
(9) |
May
(22) |
Jun
(29) |
Jul
(47) |
Aug
(11) |
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Aivils <ai...@un...> - 2004-04-05 07:51:58
|
> I'm working on a problem where I need to be able to have multiple X > servers responding concurrently (the video driver is not actually > writing to a framebuffer device), and so I was trying out > the /proc/bus/pci/hackvideo patch provided by linuxconsole/ruby. It > does not seem to solve my problem, but I would like to understand what > it is supposed to do (to hopefully give me better insight into where my > problem is). I believe the following code in proc_bus_pci_write() in > drivers/pci/proc.c is the only modification to the 2.6 kernel code > (other than reading & writing the proc entry) for the hackvideo patch: > > if (pci_hackvideo && (pos == PCI_CMD_STAT_REG) && pos - position to write > (buf[0] <= PCI_CMD_MASTER_ENABLE) && buf[0] - data to write > ((dev->class>>8) == 0x0300 || > (dev->class>>8) == 0x0400 || > (dev->class>>8) == 0x0000 ) ) dev->class - is video adapter PCI device class > return -EINVAL; > > It is not clear to me what this code is doing, however. xf86 cannot write PCI disable command in to device I/O port. > Can anyone > offer an explanation? http://startx.times.lv/eng-xf.html > Does it relate to XFree86's disabling of port I/O > access when switching VTs? If so, is it designed to block the > functionality of a particular function called within xf86VTSwitch() in > xc/programs/Xserver/hw/xfree86/common/xf86Events.c? I do not know. This patch disallow pciIoAccessDisable() normal work (file: xc/programs/Xserver/hw/xfree86/common/xf86pciBus.c) and other pci*Disable() funcs will not work normal. xf86 will use Linux /proc interface with this config: Section "ServerFlags" Option "PciOsConfig" "1" EndSection Practice. Nvidia closed source drivers version 1.0-2880 - 1.0-4496 will hung up system, when xf86 on AGP video adapter restart. Now, recent 1.0-5336 works very well, seems this is lucky case.(2.4.25, xfree4.3.0-7mdk) Almost AGP xf86 restart will hung up system, when /proc/bus/pci/hackvideo used. You can use xf86 without restart :) Aivils Stoss |
From: David C. <da...@co...> - 2004-04-04 22:02:03
|
I'm working on a problem where I need to be able to have multiple X servers responding concurrently (the video driver is not actually writing to a framebuffer device), and so I was trying out the /proc/bus/pci/hackvideo patch provided by linuxconsole/ruby. It does not seem to solve my problem, but I would like to understand what it is supposed to do (to hopefully give me better insight into where my problem is). I believe the following code in proc_bus_pci_write() in drivers/pci/proc.c is the only modification to the 2.6 kernel code (other than reading & writing the proc entry) for the hackvideo patch: if (pci_hackvideo && (pos == PCI_CMD_STAT_REG) && (buf[0] <= PCI_CMD_MASTER_ENABLE) && ((dev->class>>8) == 0x0300 || (dev->class>>8) == 0x0400 || (dev->class>>8) == 0x0000 ) ) return -EINVAL; It is not clear to me what this code is doing, however. Can anyone offer an explanation? Does it relate to XFree86's disabling of port I/O access when switching VTs? If so, is it designed to block the functionality of a particular function called within xf86VTSwitch() in xc/programs/Xserver/hw/xfree86/common/xf86Events.c? TIA for any insight you can offer, David Coulthart |
From: Aivils <ai...@un...> - 2004-03-30 06:01:30
|
> Subject: I created ruby patch against 2.6.5-rc2-mm3 and -mm5 > is anyone interested? Aivil, James? No. Power done :( > They compile without warnings but they do not work. :-( > I think I caught every changes after 2.6.3 but I must missed > something. More experienced eye is needed. > The -mm3 version oopses on boot. I have early printk switched on > so I can see kernel messages but it dies very early. I haven't booted > the -mm5 version yet, just reapplied and fixed the small rejects. Current You can remove vt_sysfs.o and accordant funcs. Seems bug exists in tty_open(), which mean complete walkthrough again, again and again. You can manualy download 2.6.2 version from CVS because tags do not exist. Aivils |
From: Zoltan B. <zb...@fr...> - 2004-03-29 18:41:25
|
Hi, is anyone interested? Aivil, James? They compile without warnings but they do not work. :-( I think I caught every changes after 2.6.3 but I must missed something. More experienced eye is needed. The -mm3 version oopses on boot. I have early printk switched on so I can see kernel messages but it dies very early. I haven't booted the -mm5 version yet, just reapplied and fixed the small rejects. I do not attach them because both are about 90K gzipped. Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi |
From: James S. <jsi...@in...> - 2004-03-26 18:28:30
|
On Fri, 26 Mar 2004, Derrick Wippler wrote: > Is this the mailing list for the input API currently implemented in the 2.6.4 > kernel linux/drivers/char/keyboard.c? > > I have found an issue, and am looking for documentation. > Yes :-) |
From: James S. <jsi...@in...> - 2004-03-26 18:28:11
|
> Then shouldn't the PC speaker config option be ON as default? > Most keyboard's today do not have PC speakers or "beepers" in them. > Wouldn't that be a reasonable default? I agree. I have no idea why Linus made the default to be off. Perhaps we should send a updated default config with the PC speaker set to on to linus. |
From: Derrick W. <de...@lo...> - 2004-03-26 17:58:30
|
Then shouldn't the PC speaker config option be ON as default? Most keyboard's today do not have PC speakers or "beepers" in them. Wouldn't that be a reasonable default? On Friday 26 March 2004 12:41 pm, James Simmons wrote: > > That is very obscure!! Why would PC speaker support be an kernel option? > > On some platforms the speaker is built into the keyboard. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Linuxconsole-dev mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev -- D E R R I C K J. W I P P L E R Logical Solutions, Inc. Software Developer <de...@lo...> Before Xerox, five carbons were the maximum extension of anybody's ego. |
From: James S. <jsi...@in...> - 2004-03-26 17:41:21
|
> That is very obscure!! Why would PC speaker support be an kernel option? On some platforms the speaker is built into the keyboard. |
From: Derrick W. <de...@lo...> - 2004-03-26 16:14:51
|
On Friday 26 March 2004 11:01 am, you wrote: > On Fri, Mar 26, 2004 at 10:29:57AM -0500, Derrick Wippler wrote: > > It appears that the KIOCSOUND ioctl call is broken in the 2.6 kernels. > > KIOSOUND calls kd_nosound() and kd_mksound() in > > linux/drivers/char/keyboard.c to emit sound. These functions do not > > appear to be working, I am quickly trying to learn the input API and how > > the input_event() request that kd_mksound() calls is failing. However > > there is very little documentation on the subject, and because I'm not > > familiar with input devices the code is confusing. > > > > For example, in kd_mksound() the code loops thru a list of (I'm assuming) > > keyboard devices, looking for one that has the EV_SND bit turned on. But > > it never finds any. So I'm attempting to find where the > > handle->dev->evbit bit is set. I'm assuming that would be when the input > > device is registered with the input API, but I cannot seam to find it!! > > > > Any assistance would be greatly appreciated. > > You probably should enable the PC Speaker driver under Input/Misc. That is very obscure!! Why would PC speaker support be an kernel option? I performed a very thorough search of the config options. Even using this command the search the Kconfig's # for i in `find | grep Kconfig`; do echo $i;fgrep "speaker" $i;done if only I had greped for "Speaker" instead of "speaker". Grrrr!!!! What a waste of time!!!!! (1 full day, before e-mailing for help). Thanks tho !!!! -- D E R R I C K J. W I P P L E R Logical Solutions, Inc. Software Developer <de...@lo...> Sex is a natural bodily process, like a stroke. |
From: Vojtech P. <vo...@su...> - 2004-03-26 16:00:31
|
On Fri, Mar 26, 2004 at 10:29:57AM -0500, Derrick Wippler wrote: > It appears that the KIOCSOUND ioctl call is broken in the 2.6 kernels. > KIOSOUND calls kd_nosound() and kd_mksound() in linux/drivers/char/keyboard.c > to emit sound. These functions do not appear to be working, I am quickly > trying to learn the input API and how the input_event() request that > kd_mksound() calls is failing. However there is very little documentation on > the subject, and because I'm not familiar with input devices the code is > confusing. > > For example, in kd_mksound() the code loops thru a list of (I'm assuming) > keyboard devices, looking for one that has the EV_SND bit turned on. But it > never finds any. So I'm attempting to find where the handle->dev->evbit bit > is set. I'm assuming that would be when the input device is registered with > the input API, but I cannot seam to find it!! > > Any assistance would be greatly appreciated. You probably should enable the PC Speaker driver under Input/Misc. -- Vojtech Pavlik SuSE Labs, SuSE CR |
From: Derrick W. <de...@lo...> - 2004-03-26 15:34:17
|
It appears that the KIOCSOUND ioctl call is broken in the 2.6 kernels. KIOSOUND calls kd_nosound() and kd_mksound() in linux/drivers/char/keyboard.c to emit sound. These functions do not appear to be working, I am quickly trying to learn the input API and how the input_event() request that kd_mksound() calls is failing. However there is very little documentation on the subject, and because I'm not familiar with input devices the code is confusing. For example, in kd_mksound() the code loops thru a list of (I'm assuming) keyboard devices, looking for one that has the EV_SND bit turned on. But it never finds any. So I'm attempting to find where the handle->dev->evbit bit is set. I'm assuming that would be when the input device is registered with the input API, but I cannot seam to find it!! Any assistance would be greatly appreciated. -- D E R R I C K J. W I P P L E R Logical Solutions, Inc. Software Developer <de...@lo...> 'I generally avoid temptation unless I can't resist it." -- Mae West |
From: Derrick W. <de...@lo...> - 2004-03-26 13:19:08
|
Is this the mailing list for the input API currently implemented in the 2.6.4 kernel linux/drivers/char/keyboard.c? I have found an issue, and am looking for documentation. -- D E R R I C K J. W I P P L E R Logical Solutions, Inc. Software Developer <de...@lo...> Take my word for it, the silliest woman can manage a clever man, but it needs a very clever woman to manage a fool. -- Kipling |
From: James S. <jsi...@in...> - 2004-03-23 18:25:56
|
What does your config look like? On Tue, 23 Mar 2004, Mattias Carlsson wrote: > Hello > > I downloaded Ruby 2.6 from bitkeepers ~two weeks ago. I've had the common > 2.6.2 kernel running and tried to compile Ruby as I did with that. This > caused two compiler errors that conserned power management-console and the > framebuffer-console but I guess that those areas are being rebuilt in this > branch so I disabled them and the compilation worked just fine. > > But when I tried to boot the kernel bzImage, grub prints loading > kernel.................ok and then the screen goes black. Just a flashing > cursor. > > I compiled as I otherwise did with 2.6.2 using gcc 2.95.3, does the ruby need > some booting attributes? My system looks as it did under 2.6.2 and maybe > there are some things that need to be mended with, can somebody recommend a > up to date guide for installing the Ruby kernel. > > Mattias > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Linuxconsole-dev mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev > |
From: James S. <jsi...@in...> - 2004-03-23 18:25:21
|
No problem. Sorry abpout the conflicts. Especially with fbcon.c. The changes have been going in. I still need to do some more work for mainline still. On Tue, 23 Mar 2004, Aivils wrote: > > Subject: 2.6.4-ruby when? > > I cannot do it, because i have not a wish. > i am tired out. > > Aivils > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Linuxconsole-dev mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev > |
From: Aivils <ai...@un...> - 2004-03-23 14:22:49
|
> Subject: 2.6.4-ruby when? I cannot do it, because i have not a wish. i am tired out. Aivils |
From: Mattias C. <mat...@st...> - 2004-03-23 08:12:15
|
Hello I downloaded Ruby 2.6 from bitkeepers ~two weeks ago. I've had the common 2.6.2 kernel running and tried to compile Ruby as I did with that. This caused two compiler errors that conserned power management-console and the framebuffer-console but I guess that those areas are being rebuilt in this branch so I disabled them and the compilation worked just fine. But when I tried to boot the kernel bzImage, grub prints loading kernel.................ok and then the screen goes black. Just a flashing cursor. I compiled as I otherwise did with 2.6.2 using gcc 2.95.3, does the ruby need some booting attributes? My system looks as it did under 2.6.2 and maybe there are some things that need to be mended with, can somebody recommend a up to date guide for installing the Ruby kernel. Mattias |
From: Boszormenyi Z. <zb...@fr...> - 2004-03-22 08:33:13
|
Hi, I'd like to ask when ruby will be updated to a newer kernel? Linux-2.6.4 has patches from earlier -mm patchsets that conflict with ruby-2.6. -- Best regards, Zoltán Böszörményi --------------------- What did Hussein say about his knife? One in Bush worth two in the hand. |
From: Mark P. <mp...@o2...> - 2004-03-20 17:31:17
|
Hi, I'm trying to get my remote control to be picked up as a keyboard in X. The remote control seems to be accessible on /dev/input/event3. /dev/input/event3 bustype : BUS_I2C vendor : 0x0 product : 0x0 version : 0 name : "i2c IR (PV951)" phys : "i2c-2//ir0" bits ev : EV_SYN EV_KEY EV_REP I tried to add the following to my XF86Config file: Section "InputDevice" Identifier "Keyboard1" Driver "keyboard" Option "XkbRules" "xfree86" Option "Device" "/dev/input/event3" EndSection but when I run xev and press buttons on my remote control no events are generated. Whenever I press a button on the control something like the following appears in messages (press the 6 button): i2c IR (PV951): unknown key: key=0x06 raw=0x06 down=1 i2c IR (PV951): unknown key: key=0x06 raw=0x06 down=0 How can I use this remote control in X? I'm running XFree86 4.3.0 with Linux 2.6.4 on a modifed Fedora Core 1 install. The remote came with my TV card (PV951). Can anyone help me? Thanks, Mark Phalan |
From: Boszormenyi Z. <zb...@fr...> - 2004-03-12 07:16:50
|
Boszormenyi Zoltan =EDrta: > Svetoslav Slavtchev =EDrta: >> sorry for the late reply, >> and hope you are already 64bit :-) > = > = > I burned the 3 CD five minutes ago, they will be installed > today evening. :-) Didn't install. :-( I got a nasty oops about "Attempt to kill swapper task" on booting the install CD. The md5sums were OK. :-( -- = Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi --------------------- What did Hussein say about his knife? One in Bush worth two in the hand. |
From: Boszormenyi Z. <zb...@fr...> - 2004-03-11 12:04:22
|
Svetoslav Slavtchev =EDrta: >>>and more importantly the cpu is not 32bit, but 64 :-) >>>!!! you are the first non i386 ruby user !!!! >> >>This is not true, yet. :-) The system is i386 version of Fedora Core 1.= >>I am downloading the ISOs of FC1/x86_64 now... > = > = > sorry for the late reply, > and hope you are already 64bit :-) I burned the 3 CD five minutes ago, they will be installed today evening. :-) >>>isn't it great that ruby also works on other archs :-) >>> >> >>>which remainds me, >>>have you applied the x86_64 ruby changes ? >> >>Where are they? The CVS contains arch/i386 but no other archs. > = > = > you might check the bk tree http://linuxconsole.bkbits.net/ > = > attached is a bit older diff, it should be pretty trivial to merge Yes, this is the exact difference between ruby-2.6 and the mainline i386 setup.c, too. > do you have the drops with the sb card ? > on-board sound tend to be problematic sometimes I haven't tried it yet. But as I remember from the emu10k1 sources, this chip can DMA only under 256MB, so the kernel has to double-copy if the user buffer is above that. It can cause dropouts, too. I will try to get an old Vortex2 card, it does not have PCI addressign problems and it just got a shiny new ALSa driver... Hmm, I will ask on the kernel list if the Athlon64 IOMMU can address this in 64bit mode. >>>>>>My main problem is that localhost:1.0 is destroyed by logging >>>>>>out on localhost:0.0. >>>>> >>>>>Destroyed how - logging out kills the other xserver too? >>>> >>>>The monitor goes black, looks powersave mode but it's not. >>>>Pressing Ctrl-Alt-BkSpace brings back the gdm login. >>> >>>have you tried disabling all DPMS stuff in XFree and kernel ? >> >>That should not be a problem, as I said I can login/logout on >>display :1.0 any time I want, it does not bother display :0.0. >>It's logging out on :0.0 that confuses :1.0, its monitor goes blank. >>On :0.0 the gdm login screen comes back as it should on logout. > = > = > it might be some DRI bug :( > have you tried disabling DRI ? No, this happened with DRI disabled, too. It seems that Wayne Whitney is right: > Anyway, my understanding of the problem is this, which may be completel= y > nonsensical: There is still some (legacy VGA?) resource each card has > which X expects to be mapped at a particular address, so that only one > card can have this resource mapped at a time. Since :1 is started up > second, it has the resource mapped to the :1 card most of the time. Wh= en > :0 exits, its X process expects that resource to be mapped to the :0 ca= rd > and goes ahead and writes to that address. But the address is mapped t= o > the :1 card, so the :1 card is screwed up. diff -u XFree86.0.log XFree86.1.log =2E.. @@ -513,7 +512,7 @@ compiled for 4.3.0, module version =3D 0.1.0 ABI class: XFree86 Video Driver, version 0.6 (II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset i= s 0x0000 -(II) RADEON(0): PCI bus 0 card 6 func 0 +(II) RADEON(0): PCI bus 1 card 0 func 0 (**) RADEON(0): Depth 24, (--) framebuffer bpp 32 (II) RADEON(0): Pixel depth =3D 24 bits stored in 4 bytes (32 bpp pixma= ps) (=3D=3D) RADEON(0): Default visual is TrueColor The "... vgaHWGetIOBase: hwp->IOBase is 0x03d0 ..." line is the same. >>>i think disabling : >>>power managment --> APM ... --> enable console blanking ... = >> >>>fixed it >> >>I use ACPI on this machine. > = > and ? > you have totaly disabled APM ? The kernel does not use it. I compiled in both and ACPI wins. -- = Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi --------------------- What did Hussein say about his knife? One in Bush worth two in the hand. |
From: Svetoslav S. <sv...@gm...> - 2004-03-11 11:13:58
|
> >>The monitor goes black, looks powersave mode but it's not. > >>Pressing Ctrl-Alt-BkSpace brings back the gdm login. > > > > have you tried disabling all DPMS stuff in XFree and kernel ? > > Tried it, did not really help. I have disabled dpms in the monitor > section of the XF86Config, and after restarting both displays by > pressing Ctrl-Alt-BkSpace, it worked. I was able to login/logout > on both displays without disturbing the other one. > Reboot: problem appeared again. hm, strange :( have you tried also disabling DPMS in the device section ? best, svetljo PS: you might also try turning on & of dpms using xset, /* not just off, but on & off */ -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz |
From: Svetoslav S. <sv...@gm...> - 2004-03-11 11:05:36
|
> > and more importantly the cpu is not 32bit, but 64 :-) > > !!! you are the first non i386 ruby user !!!! > > This is not true, yet. :-) The system is i386 version of Fedora Core 1. > I am downloading the ISOs of FC1/x86_64 now... sorry for the late reply, and hope you are already 64bit :-) > > isn't it great that ruby also works on other archs :-) > > > > > which remainds me, > > have you applied the x86_64 ruby changes ? > > Where are they? The CVS contains arch/i386 but no other archs. you might check the bk tree http://linuxconsole.bkbits.net/ attached is a bit older diff, it should be pretty trivial to merge > >>>I've noticed that tuxracer doesn't like a compile going on at > >>>the same time, but that's on a 333MHz processor. A dual cpu > >>>setup fixed that for me. > >> > >>Playing a movie in Xine while rpmbuild --rebuild XFree86 > >>causes sound dropouts (very rare) and frame drops (even less) > >>That's with the onboard AC97 sound card. > > > > > > > > are all the apps compiled for 64bit? > > i would expect no problems with such a beast CPU, > > have you tried updating alsa ? > > another soundcard? > > i don't see such problems with > > > amd XP2700 > > > 1024 MB DDR333 RAM > > I only have 512M, but DDR400. > > > sb audigy > > I also have an SB Live! 1024. > > > radeon AIW 7500 AGP > > > geforce4 440 PCI do you have the drops with the sb card ? on-board sound tend to be problematic sometimes > >>>>My main problem is that localhost:1.0 is destroyed by logging > >>>>out on localhost:0.0. > >>> > >>>Destroyed how - logging out kills the other xserver too? > >> > >>The monitor goes black, looks powersave mode but it's not. > >>Pressing Ctrl-Alt-BkSpace brings back the gdm login. > > > > > have you tried disabling all DPMS stuff in XFree and kernel ? > > That should not be a problem, as I said I can login/logout on > display :1.0 any time I want, it does not bother display :0.0. > It's logging out on :0.0 that confuses :1.0, its monitor goes blank. > On :0.0 the gdm login screen comes back as it should on logout. it might be some DRI bug :( have you tried disabling DRI ? > > some time ago my monitor used to go in power saving even as i type > > and i think Andreas Schuldei had the same problem > > i think disabling : > > power managment --> APM ... --> enable console blanking ... > > > fixed it > > I use ACPI on this machine. and ? you have totaly disabled APM ? best, svetljo -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz |
From: James S. <jsi...@in...> - 2004-03-10 18:44:10
|
> >> The point is, that everything is rock-solid, and can be stable for > >> weeks/months. Only executing a graphical java app will crash > >> the X server.. Has anyone seen this before? > > > >Strange indeed. I haven't seen that, What I see though is that > >running xterm or rxvt or similiar kills my xserver. Do you have pty's enabled? > Seems i sink in the open source bog. > 2.4.XX backstreet-ruby as rule runs identical 2.4.XX vanilla. > 2.6.XX-ruby behave otherwise in each end. Strange. Sometime in the near future I like to work on a JVM to support our multi-desktop system. |
From: Boszormenyi Z. <zb...@fr...> - 2004-03-10 07:05:56
|
Svetoslav Slavtchev =EDrta: > could you post somewere on a http/ftp server XF config files, logs, > glxinfo output ? http://www.users.broadband.hu/forsz98kft/dd.tar.gz (dd for dual-display) $ tar tzvf dd.tar.gz -rw-rw-r-- zozo/zozo 12747 2004-03-09 17:00:22 dmesg.log -rw-r--r-- zozo/zozo 18324 2004-03-09 17:01:39 gdm.conf -rw-rw-r-- zozo/zozo 3143 2004-03-09 17:49:23 glxinfo.0.0.log -rw-rw-r-- zozo/zozo 2980 2004-03-09 17:49:28 glxinfo.1.0.log -rwxr-xr-x zozo/zozo 292 2004-03-09 17:01:10 rc.local -rw-r--r-- zozo/zozo 4264 2004-03-09 17:42:13 XF86Config -rw-r--r-- zozo/zozo 53918 2004-03-09 17:39:20 XFree86.0.log -rw-r--r-- zozo/zozo 47124 2004-03-09 17:39:21 XFree86.1.log -rw-rw-r-- zozo/zozo 3070 2004-03-09 17:50:59 xvinfo.0.0.log -rw-rw-r-- zozo/zozo 3065 2004-03-09 17:50:54 xvinfo.1.0.log >>The monitor goes black, looks powersave mode but it's not. >>Pressing Ctrl-Alt-BkSpace brings back the gdm login. > = > have you tried disabling all DPMS stuff in XFree and kernel ? Tried it, did not really help. I have disabled dpms in the monitor section of the XF86Config, and after restarting both displays by pressing Ctrl-Alt-BkSpace, it worked. I was able to login/logout on both displays without disturbing the other one. Reboot: problem appeared again. -- = Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi --------------------- What did Hussein say about his knife? One in Bush worth two in the hand. |
From: Wayne W. <wh...@Ma...> - 2004-03-09 15:53:17
|
On Tue, 9 Mar 2004 Boszormenyi Zoltan <zb...@fr...> wrote: > Yesterday I compiled 4.3.0-62 from FC2 test and that fixed the keyboard > controller hardware access the kernel complained constantly but it also > "destroys" the :1.0 when I logout on :0.0. > > Sorry, I did not described what it means in the first post. The screen > goes black on :1.0. It looks like it goes into powersave mode. I think > the X that drives :0.0 does some register settings in the hardware of > :1.0 and the X that drives :1.0 looses track of what's going on. I > pressed Ctrl-Alt-BkSpace on :1.0 after the monitor went black and the > gdm login screen came back. I have the exact same problem. My setup is two Radeon RV100 QY [Radeon 7000/VE], one AGP and one PCI. When I log out of the AGP console :0, it "destroys" the PCI console :1. I have found that I can restore the :1 console by getting X to reinitialize the display, e.g. with Ctrl-Alt-KeyPadMinus (followed by Ctrl-Alt-KeyPadPlus to get back to the previous resolution). When the display comes back, the top few lines of the screen have been scribbled on. To restore the display, it is enough to have X execute xf86Screens[0]->LeaveVT(0, 0) followed by xf86Screens[0]->EnterVT(0, 0), so as a hack I bound Ctrl-Alt-KeyPadDivide to this sequence in programs/Xserver/hw/xfree86/common/xf86Events.c. Anyway, my understanding of the problem is this, which may be completely nonsensical: There is still some (legacy VGA?) resource each card has which X expects to be mapped at a particular address, so that only one card can have this resource mapped at a time. Since :1 is started up second, it has the resource mapped to the :1 card most of the time. When :0 exits, its X process expects that resource to be mapped to the :0 card and goes ahead and writes to that address. But the address is mapped to the :1 card, so the :1 card is screwed up. Cheers, Wayne |