November 2005 - openSUSE AMD64 - openSUSE Mailing Lists

OFF-TOPIC - *very* bad
by Jurzitza, Dieter 16 Nov '05

16 Nov '05

Dear listmembers, a big please: could you try sudo -s <ROOTPASSWD> ROOTSHELL Ctrl-d (back to original shell) sudo -s ROOTSHELL !!!! No question for password. This should never happen. !!!! Ctrl-d (back to original shell) I perceive this as a serious bug. I see this here on SuSE 9.3 (both amd64 and i586) and have no other platform to test - any feedback is highly appreciated! The system asks again for the password after a certain amount of time (10min to 30min). I haven't debugged this with too much depth. Thanks in advance, take care Dieter Jurzitza -- ________________________________________________ HARMAN BECKER AUTOMOTIVE SYSTEMS Dr.-Ing. Dieter Jurzitza Manager Hardware Systems System Development Industriegebiet Ittersbach Becker-Göring Str. 16 D-76307 Karlsbad / Germany Phone: +49 (0)7248 71-1577 Fax: +49 (0)7248 71-1216 eMail: DJurzitza(a)harmanbecker.com Internet: http://www.becker.de ******************************************* Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. *******************************************

7 6

Postfix + Cyrus SASL problems
by Florin Vlaicu 16 Nov '05

16 Nov '05

Hello, I had some problems with running postfix and Cyrus SASL on openSuSE 10 The first problem i ran into was that although Cyrus SASL was compiled with mysql support it didn't know anything about mysql. this is my proof Nov 9 22:18:20 aka-build postfix/smtpd[23244]: SQL engine 'mysql' not supported Nov 9 22:18:20 aka-build postfix/smtpd[23244]: auxpropfunc error no mechanism available Nov 9 22:18:20 aka-build postfix/smtpd[23244]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql I recompiled the cyrus-sasl package and I added to the --with-mysql option in the spec file also the path to the headers making it --with-mysql=/usr/include/mysql After doing this mysql queries worked Nov 16 00:02:54 aka-build postfix/smtpd[4790]: sql auxprop plugin using mysql engine Nov 16 00:02:54 aka-build postfix/smtpd[4790]: sql plugin Parse the username aka(a)lumina.ro Nov 16 00:02:54 aka-build postfix/smtpd[4790]: sql plugin try and connect to a host Nov 16 00:02:54 aka-build postfix/smtpd[4790]: sql plugin trying to open db 'postfix' on host 'localhost' Nov 16 00:02:54 aka-build postfix/smtpd[4790]: sql plugin Parse the username aka(a)lumina.ro Nov 16 00:02:54 aka-build postfix/smtpd[4790]: sql plugin try and connect to a host Nov 16 00:02:54 aka-build postfix/smtpd[4790]: sql plugin trying to open db 'postfix' on host 'localhost' Nov 16 00:02:54 aka-build postfix/smtpd[4790]: sql plugin Parse the username aka(a)lumina.ro Nov 16 00:02:54 aka-build postfix/smtpd[4790]: sql plugin try and connect to a host Nov 16 00:02:54 aka-build postfix/smtpd[4790]: sql plugin trying to open db 'postfix' on host 'localhost' Now my problem is another one. In my database I have the passwords stored with crypt md5 (system) not the one from mysql (it was easy to migrate from shadow to mysql) So I applied this patch to cyrus-sasl -----------------------begin patch *** lib/checkpw.c.orig Thu Feb 13 14:07:23 2003 --- lib/checkpw.c Thu Feb 13 14:07:03 2003 *************** *** 145,151 **** "*cmusaslsecretPLAIN", NULL }; struct propval auxprop_values[3]; ! if (!conn || !userstr) return SASL_BADPARAM; --- 145,155 ---- "*cmusaslsecretPLAIN", NULL }; struct propval auxprop_values[3]; ! ! /* added lopaka */ ! char *salt = malloc(13); ! char *crypt_passwd = NULL; ! if (!conn || !userstr) return SASL_BADPARAM; *************** *** 182,193 **** goto done; } /* At the point this has been called, the username has been canonified * and we've done the auxprop lookup. This should be easy. */ if(auxprop_values[0].name && auxprop_values[0].values && auxprop_values[0].values[0] ! && !strcmp(auxprop_values[0].values[0], passwd)) { /* We have a plaintext version and it matched! */ return SASL_OK; } else if(auxprop_values[1].name --- 186,211 ---- goto done; } + /* 20030213 lopaka */ + /* encrypt the passwd and then compare it with the encrypted passwd */ + if(strlen(auxprop_values[0].values[0]) > 13) + { + /* MD5 */ + strncpy(salt,auxprop_values[0].values[0],13); + } + else + { + /* DES */ + strncpy(salt,auxprop_values[0].values[0],3); + } + crypt_passwd = crypt(passwd,salt); + /* At the point this has been called, the username has been canonified * and we've done the auxprop lookup. This should be easy. */ if(auxprop_values[0].name && auxprop_values[0].values && auxprop_values[0].values[0] ! && !strcmp(auxprop_values[0].values[0], crypt_passwd)) { /* We have a plaintext version and it matched! */ return SASL_OK; } else if(auxprop_values[1].name ---------------end patch After applying this patch I get this in the log: Nov 16 00:17:34 aka-build postfix/smtpd[15345]: sql auxprop plugin using mysql engine Nov 16 00:17:34 aka-build postfix/smtpd[15345]: sql plugin Parse the username aka(a)lumina.ro Nov 16 00:17:34 aka-build postfix/smtpd[15345]: sql plugin try and connect to a host Nov 16 00:17:34 aka-build postfix/smtpd[15345]: sql plugin trying to open db 'postfix' on host 'localhost' Nov 16 00:17:34 aka-build postfix/smtpd[15345]: sql plugin Parse the username aka(a)lumina.ro Nov 16 00:17:34 aka-build postfix/smtpd[15345]: sql plugin try and connect to a host Nov 16 00:17:34 aka-build postfix/smtpd[15345]: sql plugin trying to open db 'postfix' on host 'localhost' Nov 16 00:17:34 aka-build postfix/smtpd[15345]: sql plugin Parse the username aka(a)lumina.ro Nov 16 00:17:34 aka-build postfix/smtpd[15345]: sql plugin try and connect to a host Nov 16 00:17:34 aka-build postfix/smtpd[15345]: sql plugin trying to open db 'postfix' on host 'localhost' Nov 16 00:17:34 aka-build postfix/smtpd[15345]: begin transaction Nov 16 00:17:34 aka-build postfix/smtpd[15345]: sql plugin create statement from userPassword aka lumina.ro Nov 16 00:17:34 aka-build postfix/smtpd[15345]: sql plugin doing query SELECT password FROM mailbox WHERE username = 'aka(a)lumina.ro'; Nov 16 00:17:34 aka-build postfix/smtpd[15345]: sql plugin create statement from cmusaslsecretPLAIN aka lumina.ro Nov 16 00:17:34 aka-build postfix/smtpd[15345]: sql plugin doing query SELECT password FROM mailbox WHERE username = 'aka(a)lumina.ro'; Nov 16 00:17:34 aka-build postfix/smtpd[15345]: commit transaction Nov 16 00:17:34 aka-build postfix/smtpd[15345]: sql plugin Parse the username aka(a)lumina.ro Nov 16 00:17:34 aka-build postfix/smtpd[15345]: sql plugin try and connect to a host Nov 16 00:17:34 aka-build postfix/smtpd[15345]: sql plugin trying to open db 'postfix' on host 'localhost' Nov 16 00:17:34 aka-build kernel: smtpd[15345]: segfault at ffffffffac1972e0 rip 00002aaaabdbf8b0 rsp 00007fffffe93678 error 4 The thing that worries me is that segfault :P Does anyone have any suggestions?

1 0

BUG in powersaved: cpufreq unreliable with Athlon64 X2 (dual core)
by Bernd Paysan 16 Nov '05

16 Nov '05

[already entered as BUG report into the powersaved project at sf] Hi, As far as I can tell, cpufreq/powersaved seems to have a problem with the Athlon64 X2 dual core chips. If I load just one core, the CPU frequency boost is unreliable (toggles between 1GHz and 2GHz). Loading the second core, too, sort-of-fixes that problem. The reason is obvious: The Athlon X2 has a *single* CPU frequency setting which affects *both* cores. So you can't simply use a SMP setting, treating the two CPUs as two processors with two speed settings, you have to know that it's a dual-core CPU, and that you can't independently set the CPU frequency. If one core is loaded, both must run at double frequency. Note that the kernel does know about this fact: /sys/devices/system/cpu/cpu0/cpufreq> cat affected_cpus 0 1 /sys/devices/system/cpu/cpu1/cpufreq> cat affected_cpus 0 1 Setting powersaved to be more verbose confirms the confusion (the following is with one core loaded by an endless loop, the other core loaded lightly): ------------------------------------------------- Nov 10 13:24:48 linux [powersave]: Info (setSpeed:90) Speed set to: 1800000KHz in file /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed Nov 10 13:24:48 linux [powersave]: Info (setSpeed:90) Speed set to: 2000000KHz in file /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed Nov 10 13:24:48 linux [powersave]: Info (adjustSpeed:196) Speed directly set to max (2000000) MHz Nov 10 13:24:48 linux [powersave]: Info (decreaseSpeed:138) current speed: 2000000KHz new speed: 1800000KHz Nov 10 13:24:48 linux [powersave]: Info (setSpeed:90) Speed set to: 1800000KHz in file /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed Nov 10 13:24:48 linux [powersave]: Info (adjustSpeed:207) Speed decreased to (1800000) MHz Nov 10 13:24:48 linux [powersave]: Info (decreaseSpeed:138) current speed: 2000000KHz new speed: 1800000KHz Nov 10 13:24:48 linux [powersave]: Info (setSpeed:90) Speed set to: 1800000KHz in file /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed Nov 10 13:24:48 linux [powersave]: Info (adjustSpeed:207) Speed decreased to (1800000) MHz Nov 10 13:24:48 linux [powersave]: Info (setSpeed:90) Speed set to: 2000000KHz in file /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed Nov 10 13:24:48 linux [powersave]: Info (adjustSpeed:196) Speed directly set to max (2000000) MHz Nov 10 13:24:48 linux [powersave]: Info (decreaseSpeed:138) current speed: 1800000KHz new speed: 1000000KHz Nov 10 13:24:48 linux [powersave]: Info (setSpeed:90) Speed set to: 1000000KHz in file /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed Nov 10 13:24:48 linux [powersave]: Info (adjustSpeed:207) Speed decreased to (1000000) MHz ------------------------------------------------- This seems to be a pretty severe bug, rendering powersaved pretty unusable on a dual-core Athlon64. I already checked the source, and there really is no code that looks at cpufreq/affected_cpus. There should be only one object per affected set of CPUs, and a list/bitset of processors instead of a single processor number. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/

3 5

AW: [suse-amd64] OFF-TOPIC - *very* bad
by Jurzitza, Dieter 15 Nov '05

15 Nov '05

Dear listmembers, I discovered this accidentally and never ever had had thought that something like this could happen. There are cases where a "sudo" option IMHO is preferrable over an extra root login on some console window, this is why I use it on a common base. And, when installing sudo, I cannot remember having been warned about something like this. Ok, ok, it is a RTFM issue. Nevertheless I cannot see a good reason to use 5 min password asking timeout as the default - I think that 0 min would be appropriate - whoever needs it shorter, can set it accordingly - but on his / her own risk. I think it would be a good policy for SuSE to change this as it is a risk that is adjustable and leaks should - IMHO - not be open as default. Thanks for all your feedback, take care Dieter Jurzitza -- ________________________________________________ HARMAN BECKER AUTOMOTIVE SYSTEMS Dr.-Ing. Dieter Jurzitza Manager Hardware Systems System Development Industriegebiet Ittersbach Becker-Göring Str. 16 D-76307 Karlsbad / Germany Phone: +49 (0)7248 71-1577 Fax: +49 (0)7248 71-1216 eMail: DJurzitza(a)harmanbecker.com Internet: http://www.becker.de > -----Ursprüngliche Nachricht----- > Von: Ken Siersma [mailto:siersmak@ekkinc.com] > Gesendet: Dienstag, 15. November 2005 10:09 > An: suse-amd64(a)suse.com > Betreff: Re: [suse-amd64] OFF-TOPIC - *very* bad > > > Tim Janssen wrote: > >Also, this feature is not Suse specific. The sudo memory is > (I think) > >standard for sudo on most distributions (at least RedHat and Fedora, > >which I can verify). Nevertheless, it is indeed a security issue. > > > >Cheers, > > > >Tim > >--- Siegbert Baude <siegbert.baude(a)gmx.de> wrote: > > > > > >>Jerry Westrick schrieb: > >> > >> > >>>On Tuesday 15 November 2005 11:15, Jurzitza, Dieter wrote: > >>> > >>> > >>> > >>>>Dear listmembers, > >>>>a big please: could you try > >>>> > >>>>sudo -s > >>>><ROOTPASSWD> > >>>>ROOTSHELL > >>>>Ctrl-d > >>>>(back to original shell) > >>>> > >>>>sudo -s > >>>>ROOTSHELL !!!! No question for password. This should > never happen. > >>>>!!!! Ctrl-d (back to original shell) > >>>> > >>>>I perceive this as a serious bug. I see this here on SuSE > 9.3 (both > >>>>amd64 and i586) and have no other platform to test - any > feedback is > >>>>highly appreciated! The system asks again for the > password after a > >>>>certain amount of time (10min to 30min). I haven't debugged this > >>>>with too much depth. Thanks in advance, take care > >>>> > >>>> > >>>> > >>>>Dieter Jurzitza > >>>> > >>>> > >>>> > >>>Ditto SUSE 10.0 Pro (Comercial)... > >>> > >>> > >>> > >>The same on SUSE 9.2, but this is not a bug, it's a feature. "Man > >>sudo" > >>reveals this in the first paragraph, in the paragraph about sudo > >>security you also find interesting pieces of information. > To change this > >>"man sudoers" says: > >> > >>timestamp_timeout > >> Number of minutes that can elapse before > sudo will > >>ask for a passwd again. > >> The default is 5. Set this to 0 to > always prompt for > >>a password. If set to > >> a value less than 0 the user's timestamp > will never > >>expire. This can be used > >> to allow users to create or delete their own > >>timestamps via sudo -v and sudo > >> -k respectively. > >> > >> > >>Ciao > >>Siegbert > >> > >>-- > >>Check the List-Unsubscribe header to unsubscribe > >>For additional commands, email: suse-amd64-help(a)suse.com > >> > >> > >> > > > > > > > AFAIK, it has been standard practice for quite some time to > not install > sudo if you are concerned about security. I don't have it on my home > system which has a direct connection to the internet, with > good reason, > or my firewall at work, which I installed a good 3 years ago. > > -- > Check the List-Unsubscribe header to unsubscribe > For additional commands, email: suse-amd64-help(a)suse.com > > ******************************************* Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. *******************************************

4 3

AW: [suse-amd64] Question on HP - WS XW9300
by Jurzitza, Dieter 15 Nov '05

15 Nov '05

Dear listmembers, many thanks for all the replies. I tried your suggestions, pci=noacpi does the trick. So, if there is any "RTFM" for XW9300 WS out in the net, I would volunteer to put this in, if someone else would do -> fine as well. Thank you once again, happlily shutting off now, take care Dieter Jurzitza -- ________________________________________________ HARMAN BECKER AUTOMOTIVE SYSTEMS Dr.-Ing. Dieter Jurzitza Manager Hardware Systems System Development Industriegebiet Ittersbach Becker-Göring Str. 16 D-76307 Karlsbad / Germany Phone: +49 (0)7248 71-1577 Fax: +49 (0)7248 71-1216 eMail: DJurzitza(a)harmanbecker.com Internet: http://www.becker.de ******************************************* Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. *******************************************

1 0

RE: [suse-amd64] Re: [powersave-devel] [ powersave-Bugs-1353119 ] cpufreq unreliable with Athlon64 X2 (dual core)
by Langsdorf, Mark 14 Nov '05

14 Nov '05

> > Setting powersaved to be more verbose confirms the > > confusion (the following is with one core loaded by an > > endless loop, the other core loaded lightly): > > I remember Mark Langsdorf telling me that if two speeds are > set for two cores on the same socket, the higher one will > be activated on both. For this case the old alogrithm > should still be sufficient and the concerns for > 10.0 stated above should not be the case, but I maybe wrong here. That's true for the version of the driver in SLES, but the cpufreq interface for dual-core changed in 2.6.10 and the new driver is last change wins. -Mark Langsdorf AMD, Inc.

1 0

Re: [suse-amd64] Question on HP - WS XW9300
by Karsten Weiss 14 Nov '05

14 Nov '05

On Fri, 11 Nov 2005, mike wrote: > On Friday 11 November 2005 14:41, Jurzitza, Dieter wrote: > > Dear listmembers, > > after some quirks I succeeded in making a 2x2-CPU HP-Ws work using > > SuSE9.3. However, what I cannot do is shutdown and turn off the > > machine using shutdown -h now. This is probably due to the fact that > > I have to add apci=off on the boot-commandline, otherwise the system > > does not boot. Is there any workaround for this? I would have > > I don't think there is. From what I remember, there is something about a > dual CPU machine prevents the automatic shutdown as with a single cpu > system. It does have something to do with the acpi=off, but exactly > what I'm not sure. I know that on my dual amd 2800 machine, I must hit > the button to turn it off. We also had boot problems with a dual-core xw9300 system because even the latest SuSE 9.3 erratum kernel does not detect the lsi logic scsi controller with the default boot options. However, on my xw9300 system it was sufficient to use "pci=noacpi" instead of "acpi=off" to fix this detection problem. I also tried "pci=lastbus=0x61" without "pci=acpi" but that didn't work out. 0000:61:06.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07) 0000:61:06.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07) Apart from that we still have problems with the internal nic on SuSE 9.3 and latest the nvnet driver. We talked with NVIDIA about it and they would like us to test with a fully acpi-enabled kernel. But as mentioned above this does not work without at least "pci=noacpi". Side node: The vanilla SuSE 9.3 kernel installed by the dvd installer doesn't work with Dual-Core Opterons. However, this can be worked around by temporarily disabling the Dual-Core feature in the bios, installing+upgrading to the latest suse93 kernel and finally reenabling the dual-core feature. Best regards, Karsten -- __________________________________________creating IT solutions Dipl.-Inf. Karsten Weiss science + computing ag phone: +49 7071 9457 452 Hagellocher Weg 71-75 teamline: +49 7071 9457 681 72070 Tuebingen, Germany email: knweiss(a)science-computing.de www.science-computing.de

2 1

Re: [powersave-devel] [ powersave-Bugs-1353119 ] cpufreq unreliable with Athlon64 X2 (dual core)
by Thomas Renninger 14 Nov '05

14 Nov '05

SourceForge.net wrote: > Bugs item #1353119, was opened at 2005-11-10 13:35 > Message generated for change (Tracker Item Submitted) made by Item Submitter > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=700009&aid=1353119&group_… > > Please note that this message will contain a full copy of the comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: None > Group: None > Status: Open > Resolution: None > Priority: 5 > Submitted By: Bernd Paysan (paysan) > Assigned to: Nobody/Anonymous (nobody) > Summary: cpufreq unreliable with Athlon64 X2 (dual core) > > Initial Comment: > Hi, > > As far as I can tell, cpufreq/powersaved (of 0.10.15.1, as in > SuSE 10.0) seems to have a severe problem with the > Athlon64 X2 dual core chips. If I load just one core, the > CPU frequency boost is unreliable (toggles between 1GHz > and 2GHz). Loading the second core, too, sort-of-fixes that > problem. So the assumption, that the higher value when writing to two sibling cores is taken is wrong, but the last value written is taken? See below. > > The reason is obvious: The Athlon X2 has a *single* CPU > frequency setting which affects *both* cores. So you can't > simply use a SMP setting, treating the two CPUs as two > processors with two speed settings, you have to know that > it's a dual-core CPU, and that you can't independently set > the CPU frequency. If one core is loaded, both must run at > double frequency. > > Note that the kernel does know about this fact: > > /sys/devices/system/cpu/cpu0/cpufreq> cat affected_cpus > 0 1 > /sys/devices/system/cpu/cpu1/cpufreq> cat affected_cpus > 0 1 > Yes, I have done this already for SLES9-SP2. IIRC there was no affected_cpus file in 2.6.5, so I had to parse /proc/cpuinfo for siblings and cores. > Setting powersaved to be more verbose confirms the > confusion (the following is with one core loaded by an > endless loop, the other core loaded lightly): I remember Mark Langsdorf telling me that if two speeds are set for two cores on the same socket, the higher one will be activated on both. For this case the old alogrithm should still be sufficient and the concerns for 10.0 stated above should not be the case, but I maybe wrong here. Hmm, I just rechecked. This cannot be the case for newer kernels any more as there /sys/devices/.../cpu0/cpufreq is a link to /sys/devices/.../cpu1/cpufreq so probably the last speed written into one of them gets the active freq. The cpumask approach patch looks nice, but for a quick look, it's not complete (it should need a hack in adjustSpeed function itself, setMode should only be invoked once when the user switches between e.g. dynamic to performance mode). We should either: 1) only create one object per cpu socket that sets the speed for all its cores. Probably the nicer solution (but IIRC needs some redoing of code to be able to access/create file paths to the other CPU(s). 2) Still use CPU core objects and set the speed according to the max Load of both. Disadvantage: memory/performance waste (two objects for 1 socket and two times written into each core). Ok, I just talked with Holger and he already has something. If I understood him right, he goes for 1. based on Bernd's patch and workarounds the accessing file paths problem by checking and ignoring the symlink directory. Be careful that this only works on very current kernels as those symlink directories for dual cores seem to be introduced very recently. We should also check whether all cpufreq drivers (speedstep-centrino, powernow-k8 and acpi-cpufreq) are behaving in the same way. Thanks a lot Bernd and Holger for finding and fixing this, Thomas

1 0

Re: [suse-amd64] Current Asus Support
by Ciro Iriarte 13 Nov '05

13 Nov '05

2005/11/13, Ciro Iriarte <cyruspy(a)gmail.com>: > > How big a power supply? > > 400W or greater? > Looking for a decent 600w PSU (have 2 in mind) > > > > > AMD Athlon 64 3500+ > > > 2GB Corsair RAM > > > > PC3200? > yep > > Dual channel? > not sure > > My 2G RAM on that mb only works at PC3000 in dual channel mode (it is > > PC3200 and works that way if only 1G is installed). > > I'm not sure it is the mb or CPU but my CPU is supposed to handle it and > > there are other cases on the ASUS website (but no solutions yet and > > nothing from ASUS). > > > Any issues with the onboard raid controller?, data corruption? > > CI.- > Sorry for the direct reply....

3 2

Problems with Anjuta 1.2.3
by Detlef Grittner 13 Nov '05

13 Nov '05

I've tried Anjuta 1.2.3 on a Suse x86_64 installation, but the editor isn't working. It overlaps lines and positions them incorrectly during scrolling. Now I've downloaded Anjuta 1.2.4 as source code, built it as 64 bit application, and the editor is working correcly in this version. Has anyone an idea what is wrong with the 1.2.3 version of Suse? Detlef

1 0