From jorton at redhat.com Thu Sep 2 20:23:10 2004 From: jorton at redhat.com (Joe Orton) Date: Thu, 2 Sep 2004 21:23:10 +0100 Subject: apache (httpd) on FC1/i386 vs FC2/x86_64: 3-8 times as much memory consumption? In-Reply-To: <20040831140550.GA24708@neu.physik.fu-berlin.de> References: <20040831140550.GA24708@neu.physik.fu-berlin.de> Message-ID: <20040902202310.GA9380@redhat.com> On Tue, Aug 31, 2004 at 04:05:50PM +0200, Axel Thimm wrote: > Hi, > > I recently moved a httpd mirror from i386 to x86_64 hardware. All but > the memory capacity were scaled up (100MBit to 1GBit, Athlon to > Opteron etc.). > > The old server is running FC1/i386 and the new one got > FC2/x86_64. Although both distros have httpd in the same upstream > version (2.0.50) the memory footage is quite different, and leads to > the striking of the oom-killer on the new server: I see the same thing here, not looked into it before though. It's interesting, if you look at the mappings of the httpd process on x86_64, for each mmaped object there is an extra region mapped with PROT_NONE, which you don't see on i686. I presume this is counted in the VmSize calculation - it adds up to about 100Mb of address space on the system I tested. e.g. 2a9b033000 12K r-xp /usr/lib64/libpanel.so.5.3 2a9b036000 1012K ---p /usr/lib64/libpanel.so.5.3 2a9b133000 16K rw-p /usr/lib64/libpanel.so.5.3 vs 00d57000 12K r-xp /usr/lib/libpanel.so.5.3 00d5a000 4K rw-p /usr/lib/libpanel.so.5.3 is this libc behaviour by design? Jakub? > > old (FC1/i386): > > root 3329 0.0 0.2 26900 2408 ? S Aug29 0:01 /usr/sbin/httpd > apache 32746 0.0 0.5 28388 5984 ? S 06:01 0:03 \_ /usr/sbin/httpd > apache 6206 0.0 0.5 28320 5968 ? S 09:31 0:02 \_ /usr/sbin/httpd > apache 8185 0.0 0.5 28452 6080 ? S 10:09 0:04 \_ /usr/sbin/httpd > apache 10293 0.0 0.5 28452 6056 ? S 11:07 0:03 \_ /usr/sbin/httpd > apache 10378 0.0 0.5 28396 5984 ? S 11:09 0:03 \_ /usr/sbin/httpd > [...] > > new (FC2/x86_64): > > root 2177 0.0 1.5 189664 15556 ? S Aug30 0:00 /usr/sbin/httpd > apache 2273 0.0 1.7 193076 17984 ? S Aug30 0:03 \_ /usr/sbin/httpd > apache 2282 0.0 1.7 193052 17996 ? S Aug30 0:04 \_ /usr/sbin/httpd > apache 3125 0.0 1.7 193052 17992 ? S Aug30 0:03 \_ /usr/sbin/httpd > apache 3993 0.0 1.7 193052 18060 ? S 01:27 0:03 \_ /usr/sbin/httpd > apache 3994 0.0 1.7 193052 17976 ? S 01:27 0:02 \_ /usr/sbin/httpd > apache 7193 0.0 1.7 193052 17992 ? S 05:01 0:02 \_ /usr/sbin/httpd > > Is this normal for i386 -> x86_64? Anyone running httpd on x86_64 to > compare numbers? > > Thanks! > -- > Axel.Thimm at ATrpms.net > -- > fedora-list mailing list > fedora-list at redhat.com > To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list From jakub at redhat.com Thu Sep 2 20:34:20 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 2 Sep 2004 16:34:20 -0400 Subject: apache (httpd) on FC1/i386 vs FC2/x86_64: 3-8 times as much memory consumption? In-Reply-To: <20040902202310.GA9380@redhat.com> References: <20040831140550.GA24708@neu.physik.fu-berlin.de> <20040902202310.GA9380@redhat.com> Message-ID: <20040902203420.GI30573@devserv.devel.redhat.com> On Thu, Sep 02, 2004 at 09:23:10PM +0100, Joe Orton wrote: > I see the same thing here, not looked into it before though. > > It's interesting, if you look at the mappings of the httpd process on > x86_64, for each mmaped object there is an extra region mapped with > PROT_NONE, which you don't see on i686. I presume this is counted in > the VmSize calculation - it adds up to about 100Mb of address space on > the system I tested. > > e.g. > > 2a9b033000 12K r-xp /usr/lib64/libpanel.so.5.3 > 2a9b036000 1012K ---p /usr/lib64/libpanel.so.5.3 > 2a9b133000 16K rw-p /usr/lib64/libpanel.so.5.3 > > vs > > 00d57000 12K r-xp /usr/lib/libpanel.so.5.3 > 00d5a000 4K rw-p /usr/lib/libpanel.so.5.3 > > is this libc behaviour by design? Jakub? Well, not glibc, but binutils. The thing is, x86-64 ELF has 1MB pagesize, while i386 ELF 4KB, so the x86-64 binaries and shared libraries must be usable even when kernel uses 1MB pagesize. The gap in between RE and RW segment is there so that the library occupies less memory (eats less 4KB pages). If something counts in PROT_NONE mappings into the process size, it should be fixed. Jakub From jorton at redhat.com Fri Sep 3 10:20:43 2004 From: jorton at redhat.com (Joe Orton) Date: Fri, 3 Sep 2004 11:20:43 +0100 Subject: apache (httpd) on FC1/i386 vs FC2/x86_64: 3-8 times as much memory consumption? In-Reply-To: <20040902203420.GI30573@devserv.devel.redhat.com> References: <20040831140550.GA24708@neu.physik.fu-berlin.de> <20040902202310.GA9380@redhat.com> <20040902203420.GI30573@devserv.devel.redhat.com> Message-ID: <20040903102043.GB11833@redhat.com> On Thu, Sep 02, 2004 at 04:34:20PM -0400, Jakub Jelinek wrote: > On Thu, Sep 02, 2004 at 09:23:10PM +0100, Joe Orton wrote: > > I see the same thing here, not looked into it before though. > > > > It's interesting, if you look at the mappings of the httpd process on > > x86_64, for each mmaped object there is an extra region mapped with > > PROT_NONE, which you don't see on i686. I presume this is counted in > > the VmSize calculation - it adds up to about 100Mb of address space on > > the system I tested. > > > > e.g. > > > > 2a9b033000 12K r-xp /usr/lib64/libpanel.so.5.3 > > 2a9b036000 1012K ---p /usr/lib64/libpanel.so.5.3 > > 2a9b133000 16K rw-p /usr/lib64/libpanel.so.5.3 > > > > vs > > > > 00d57000 12K r-xp /usr/lib/libpanel.so.5.3 > > 00d5a000 4K rw-p /usr/lib/libpanel.so.5.3 > > > > is this libc behaviour by design? Jakub? > > Well, not glibc, but binutils. > The thing is, x86-64 ELF has 1MB pagesize, while i386 ELF 4KB, > so the x86-64 binaries and shared libraries must be usable even when kernel > uses 1MB pagesize. > > The gap in between RE and RW segment is there so that the library occupies > less memory (eats less 4KB pages). > > If something counts in PROT_NONE mappings into the process size, it should > be fixed. Such mappings are certainly counted in the VmSize reported by /proc/pid/status, which looks like it (mm->total_vm) is used in the OOM killer heuristics and also in the 'ps' VSZ output. I couldn't argue otherwise since it is vm space which is being "used". But if these mappings are not really consuming memory, then they are not necessarily the cause of your problems, Axel. It does mean that if you *do* run out of memory, then the httpd processes are more likely to get OOM killed on x86_64 than on i386. joe From Axel.Thimm at ATrpms.net Fri Sep 3 10:40:53 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 3 Sep 2004 12:40:53 +0200 Subject: apache (httpd) on FC1/i386 vs FC2/x86_64: 3-8 times as much memory consumption? In-Reply-To: <20040903102043.GB11833@redhat.com> References: <20040831140550.GA24708@neu.physik.fu-berlin.de> <20040902202310.GA9380@redhat.com> <20040902203420.GI30573@devserv.devel.redhat.com> <20040903102043.GB11833@redhat.com> Message-ID: <20040903104053.GI26676@neu.physik.fu-berlin.de> On Fri, Sep 03, 2004 at 11:20:43AM +0100, Joe Orton wrote: > On Thu, Sep 02, 2004 at 04:34:20PM -0400, Jakub Jelinek wrote: > > On Thu, Sep 02, 2004 at 09:23:10PM +0100, Joe Orton wrote: > > > I see the same thing here, not looked into it before though. > > > > > > It's interesting, if you look at the mappings of the httpd process on > > > x86_64, for each mmaped object there is an extra region mapped with > > > PROT_NONE, which you don't see on i686. I presume this is counted in > > > the VmSize calculation - it adds up to about 100Mb of address space on > > > the system I tested. > > > > > > e.g. > > > > > > 2a9b033000 12K r-xp /usr/lib64/libpanel.so.5.3 > > > 2a9b036000 1012K ---p /usr/lib64/libpanel.so.5.3 > > > 2a9b133000 16K rw-p /usr/lib64/libpanel.so.5.3 > > > > > > vs > > > > > > 00d57000 12K r-xp /usr/lib/libpanel.so.5.3 > > > 00d5a000 4K rw-p /usr/lib/libpanel.so.5.3 > > > > > > is this libc behaviour by design? Jakub? > > > > Well, not glibc, but binutils. > > The thing is, x86-64 ELF has 1MB pagesize, while i386 ELF 4KB, > > so the x86-64 binaries and shared libraries must be usable even when kernel > > uses 1MB pagesize. > > > > The gap in between RE and RW segment is there so that the library occupies > > less memory (eats less 4KB pages). > > > > If something counts in PROT_NONE mappings into the process size, it should > > be fixed. > > Such mappings are certainly counted in the VmSize reported by > /proc/pid/status, which looks like it (mm->total_vm) is used in the OOM > killer heuristics and also in the 'ps' VSZ output. I couldn't argue > otherwise since it is vm space which is being "used". > > But if these mappings are not really consuming memory, then they are not > necessarily the cause of your problems, Axel. It does mean that if you > *do* run out of memory, then the httpd processes are more likely to get > OOM killed on x86_64 than on i386. Well, I can only argue phenomenologically, the same httpd config under FC1/i386/1GB could easily serve the default 150 MaxClients. Migrating to FC2/x86_64/1GB (e.g. same amount of RAM, but i386->x86_64 and FC1->FC2) requires me to reduce MaxClients to below 50 to keep the machine from running OOM. The VM numbers are 8 times as big, and perhaps this figure is irrelevant as discussed above, but the RSS size is also 3 times higher than on the old server, and that is probably hurting (20MB RSS times 150 MaxClients is already at 3GB, while previously it was at 6MB times resulting to 1.2GB). How can I debug the memory consumption on this box? Which figures are the ones to look for and which ones do accumulate for the OOM killer? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jakub at redhat.com Fri Sep 3 10:46:18 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 3 Sep 2004 06:46:18 -0400 Subject: apache (httpd) on FC1/i386 vs FC2/x86_64: 3-8 times as much memory consumption? In-Reply-To: <20040903104053.GI26676@neu.physik.fu-berlin.de> References: <20040831140550.GA24708@neu.physik.fu-berlin.de> <20040902202310.GA9380@redhat.com> <20040902203420.GI30573@devserv.devel.redhat.com> <20040903102043.GB11833@redhat.com> <20040903104053.GI26676@neu.physik.fu-berlin.de> Message-ID: <20040903104618.GN30573@devserv.devel.redhat.com> On Fri, Sep 03, 2004 at 12:40:53PM +0200, Axel Thimm wrote: > How can I debug the memory consumption on this box? Which figures are > the ones to look for and which ones do accumulate for the OOM killer? IMHO best would be to install 32-bit and 64-bit httpd side by side, configure it the same (with a different port number), keep downloading the same page from it and try to grab /proc//maps from both processes. Jakub From jorton at redhat.com Fri Sep 3 11:32:42 2004 From: jorton at redhat.com (Joe Orton) Date: Fri, 3 Sep 2004 12:32:42 +0100 Subject: apache (httpd) on FC1/i386 vs FC2/x86_64: 3-8 times as much memory consumption? In-Reply-To: <20040903104053.GI26676@neu.physik.fu-berlin.de> References: <20040831140550.GA24708@neu.physik.fu-berlin.de> <20040902202310.GA9380@redhat.com> <20040902203420.GI30573@devserv.devel.redhat.com> <20040903102043.GB11833@redhat.com> <20040903104053.GI26676@neu.physik.fu-berlin.de> Message-ID: <20040903113242.GA12256@redhat.com> Actually, I don't see RSS numbers particularly different between i686 and x86_64. For a server under ab load for a static page, I get an RSS of ~10.5Mb on amd64, and ~9.5Mb on i686, which seems like a reasonable difference. This is comparing like for like on RHEL3 U3, I don't have a Hammer box running FC2 to compare. You are comparing active servers not idle ones, right? RSS of an idle server is not interesting since it may be half swapped out. joe From Axel.Thimm at ATrpms.net Fri Sep 3 12:54:12 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 3 Sep 2004 14:54:12 +0200 Subject: apache (httpd) on FC1/i386 vs FC2/x86_64: 3-8 times as much memory consumption? In-Reply-To: <20040903113242.GA12256@redhat.com> References: <20040831140550.GA24708@neu.physik.fu-berlin.de> <20040902202310.GA9380@redhat.com> <20040902203420.GI30573@devserv.devel.redhat.com> <20040903102043.GB11833@redhat.com> <20040903104053.GI26676@neu.physik.fu-berlin.de> <20040903113242.GA12256@redhat.com> Message-ID: <20040903125412.GA31368@neu.physik.fu-berlin.de> On Fri, Sep 03, 2004 at 12:32:42PM +0100, Joe Orton wrote: > Actually, I don't see RSS numbers particularly different between i686 > and x86_64. > > For a server under ab load for a static page, I get an RSS of ~10.5Mb on > amd64, and ~9.5Mb on i686, which seems like a reasonable difference. > This is comparing like for like on RHEL3 U3, I don't have a Hammer box > running FC2 to compare. In my case this was 20MB vs 6MB. > You are comparing active servers not idle ones, right? RSS of an idle > server is not interesting since it may be half swapped out. No, the numbers were from actual full workload scenarios. It must not be a i386 vs x86_64 issue, it can also be FC1->FC2 issue (including kernel 2.4->2.6). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jorton at redhat.com Fri Sep 3 16:16:51 2004 From: jorton at redhat.com (Joe Orton) Date: Fri, 3 Sep 2004 17:16:51 +0100 Subject: apache (httpd) on FC1/i386 vs FC2/x86_64: 3-8 times as much memory consumption? In-Reply-To: <20040903125412.GA31368@neu.physik.fu-berlin.de> References: <20040831140550.GA24708@neu.physik.fu-berlin.de> <20040902202310.GA9380@redhat.com> <20040902203420.GI30573@devserv.devel.redhat.com> <20040903102043.GB11833@redhat.com> <20040903104053.GI26676@neu.physik.fu-berlin.de> <20040903113242.GA12256@redhat.com> <20040903125412.GA31368@neu.physik.fu-berlin.de> Message-ID: <20040903161651.GA14398@redhat.com> On Fri, Sep 03, 2004 at 02:54:12PM +0200, Axel Thimm wrote: > It must not be a i386 vs x86_64 issue, it can also be FC1->FC2 issue > (including kernel 2.4->2.6). I see roughly the same RSS and VSZ between FC1 and FC2 on x86 boxes. I presume you have exactly the same set of modules installed&loaded on both servers? joe From Axel.Thimm at ATrpms.net Fri Sep 3 16:21:46 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 3 Sep 2004 18:21:46 +0200 Subject: apache (httpd) on FC1/i386 vs FC2/x86_64: 3-8 times as much memory consumption? In-Reply-To: <20040903161651.GA14398@redhat.com> References: <20040831140550.GA24708@neu.physik.fu-berlin.de> <20040902202310.GA9380@redhat.com> <20040902203420.GI30573@devserv.devel.redhat.com> <20040903102043.GB11833@redhat.com> <20040903104053.GI26676@neu.physik.fu-berlin.de> <20040903113242.GA12256@redhat.com> <20040903125412.GA31368@neu.physik.fu-berlin.de> <20040903161651.GA14398@redhat.com> Message-ID: <20040903162146.GC31368@neu.physik.fu-berlin.de> On Fri, Sep 03, 2004 at 05:16:51PM +0100, Joe Orton wrote: > On Fri, Sep 03, 2004 at 02:54:12PM +0200, Axel Thimm wrote: > > It must not be a i386 vs x86_64 issue, it can also be FC1->FC2 issue > > (including kernel 2.4->2.6). > > I see roughly the same RSS and VSZ between FC1 and FC2 on x86 boxes. I > presume you have exactly the same set of modules installed&loaded on > both servers? I am using the default set of modules that FC1 resp. FC2 come preconfigured with, I only configure vhosts upon the default config. Is there such a difference FC1 vs FC2 in the set of default modules and the thus consumed memory? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From garmanyj at proxitec.com Tue Sep 7 18:19:04 2004 From: garmanyj at proxitec.com (John Garmany) Date: Tue, 07 Sep 2004 12:19:04 -0600 Subject: Samba Update Message-ID: <413DFB98.3080004@ProxITec.com> Hi, is anyone else getting the a dependencies problems when you run up2date? I get the message: Unresolvable chain of dependencies: samba-3.0.3-5 requires samba-common = 0:3.0.3 When I run rpm -qa|grep samba I get samba-common-3.0.3-5 I also get two entrys for samba-3.0.3-5 rpm -qa |grep samba sambe-client-3.0.3-5 samba-common-3.0.3-5 system-config-samba-1.2.9-2 samba-3.0.3-5 samba-3.0.3-5 How did I end up with two copies of samba and how do I get rid of one? Is the extra samba causing the unresolved chain of dependencies? John From pmatilai at welho.com Wed Sep 8 05:44:49 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 8 Sep 2004 08:44:49 +0300 (EEST) Subject: Samba Update In-Reply-To: <413DFB98.3080004@ProxITec.com> References: <413DFB98.3080004@ProxITec.com> Message-ID: On Tue, 7 Sep 2004, John Garmany wrote: > Hi, is anyone else getting the a dependencies problems when you run up2date? > > I get the message: > Unresolvable chain of dependencies: > samba-3.0.3-5 requires samba-common = 0:3.0.3 Looks like RH forgot to publish an i386 version of the updated samba package for x86_64. I don't remember what exactly (if anything) requires the i386 version on x86_64 but it's there and gets installed by default from "Compatibility Arch Support" section. So up2date tries to update the x86_64 version of samba packages which would pull in samba-common 3.0.6 which in turn would break the i386 version's dependencies. > > When I run rpm -qa|grep samba I get samba-common-3.0.3-5 > I also get two entrys for samba-3.0.3-5 > > rpm -qa |grep samba > sambe-client-3.0.3-5 > samba-common-3.0.3-5 > system-config-samba-1.2.9-2 > samba-3.0.3-5 > samba-3.0.3-5 > > How did I end up with two copies of samba and how do I get rid of one? > Is the extra samba causing the unresolved chain of dependencies? They're not really two copies, the other one is built for i386 and the other for x86_64 (you can check with 'rpm -qa --qf '%{name}-%{version}.%{arch}\n |grep samba') To remove such "duplicates" you can append the architecture to rpm commands, eg to remove i386 version of samba you'd use 'rpm -e samba.i386' The real fix however is for RH to push the updated i386 samba package for x86_64 as well. Or you can point up2date to the i386 update repository in addition to the x86_64 repo as a workaround. - Panu - From jkt at redhat.com Wed Sep 8 19:16:15 2004 From: jkt at redhat.com (Jay Turner) Date: Wed, 8 Sep 2004 15:16:15 -0400 Subject: Samba Update In-Reply-To: References: <413DFB98.3080004@ProxITec.com> Message-ID: <20040908191615.GF3432@redhat.com> On Wed, Sep 08, 2004 at 08:44:49AM +0300, Panu Matilainen wrote: > On Tue, 7 Sep 2004, John Garmany wrote: > > > Hi, is anyone else getting the a dependencies problems when you run up2date? > > > > I get the message: > > Unresolvable chain of dependencies: > > samba-3.0.3-5 requires samba-common = 0:3.0.3 > > Looks like RH forgot to publish an i386 version of the updated samba > package for x86_64. I don't remember what exactly (if anything) requires > the i386 version on x86_64 but it's there and gets installed by default > from "Compatibility Arch Support" section. So up2date tries to update the > x86_64 version of samba packages which would pull in samba-common 3.0.6 > which in turn would break the i386 version's dependencies. Nope, we shipped it: Red Hat Desktop (v. 3 for AMD64/Intel EM64T): 55f454aad84a225fe3e984a6841765ed samba-swat-3.0.6-2.3E.x86_64.rpm a773ae10653c34bc0b82aa0bd442fb33 samba-common-3.0.6-2.3E.x86_64.rpm 1c1b17d2e518d7e96b61c2f05aff7ebd samba-client-3.0.6-2.3E.x86_64.rpm 329297e8b30f956fde14bb1ccabc16b6 samba-3.0.6-2.3E.x86_64.rpm 4540f7279bb9fb55b5170aae496b16d8 samba-3.0.6-2.3E.i386.rpm That from: https://rhn.redhat.com/network/errata/details/package_list.pxt?eid=2358 So, not really sure what's going on. You might want to run 'up2date -v' and see if that output helps point to the issue. - jkt -- --*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--* Jay Turner, QA Technical Lead jkt at redhat.com Red Hat, Inc. If I had only known, I would have been a locksmith. - Albert Einstein From joshua at iwsp.com Wed Sep 8 20:28:13 2004 From: joshua at iwsp.com (Joshua Jensen) Date: Wed, 8 Sep 2004 16:28:13 -0400 Subject: Samba Update In-Reply-To: References: <413DFB98.3080004@ProxITec.com> Message-ID: <20040908202813.GB1760@iwsp.com> As Jay points out, both archs of the package are there. Are you suffering from this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127784 ? Joshua On Wed, Sep 08, 2004 at 08:44:49AM +0300, Panu Matilainen wrote: > On Tue, 7 Sep 2004, John Garmany wrote: > > > Hi, is anyone else getting the a dependencies problems when you run up2date? > > > > I get the message: > > Unresolvable chain of dependencies: > > samba-3.0.3-5 requires samba-common = 0:3.0.3 > > Looks like RH forgot to publish an i386 version of the updated samba > package for x86_64. I don't remember what exactly (if anything) requires > the i386 version on x86_64 but it's there and gets installed by default > from "Compatibility Arch Support" section. So up2date tries to update the > x86_64 version of samba packages which would pull in samba-common 3.0.6 > which in turn would break the i386 version's dependencies. > > > > > When I run rpm -qa|grep samba I get samba-common-3.0.3-5 > > I also get two entrys for samba-3.0.3-5 > > > > rpm -qa |grep samba > > sambe-client-3.0.3-5 > > samba-common-3.0.3-5 > > system-config-samba-1.2.9-2 > > samba-3.0.3-5 > > samba-3.0.3-5 > > > > How did I end up with two copies of samba and how do I get rid of one? > > Is the extra samba causing the unresolved chain of dependencies? > > They're not really two copies, the other one is built for i386 and the > other for x86_64 (you can check with > 'rpm -qa --qf '%{name}-%{version}.%{arch}\n |grep samba') > To remove such "duplicates" you can append the architecture to rpm > commands, eg to remove i386 version of samba you'd use 'rpm -e samba.i386' > The real fix however is for RH to push the updated i386 samba package for > x86_64 as well. Or you can point up2date to the i386 update repository > in addition to the x86_64 repo as a workaround. > > - Panu - > > > -- > amd64-list mailing list > amd64-list at redhat.com > https://www.redhat.com/mailman/listinfo/amd64-list -- Joshua Jensen joshua at iwsp.com "If God didn't want us to eat animals, why did he make them out of meat?" From pmatilai at welho.com Wed Sep 8 19:25:42 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 08 Sep 2004 22:25:42 +0300 Subject: Samba Update In-Reply-To: <20040908191615.GF3432@redhat.com> References: <413DFB98.3080004@ProxITec.com> <20040908191615.GF3432@redhat.com> Message-ID: <1094671542.3289.4.camel@chip.laiskiainen.org> On Wed, 2004-09-08 at 22:16, Jay Turner wrote: > On Wed, Sep 08, 2004 at 08:44:49AM +0300, Panu Matilainen wrote: > > On Tue, 7 Sep 2004, John Garmany wrote: > > > > > Hi, is anyone else getting the a dependencies problems when you run up2date? > > > > > > I get the message: > > > Unresolvable chain of dependencies: > > > samba-3.0.3-5 requires samba-common = 0:3.0.3 > > > > Looks like RH forgot to publish an i386 version of the updated samba > > package for x86_64. I don't remember what exactly (if anything) requires > > the i386 version on x86_64 but it's there and gets installed by default > > from "Compatibility Arch Support" section. So up2date tries to update the > > x86_64 version of samba packages which would pull in samba-common 3.0.6 > > which in turn would break the i386 version's dependencies. > > Nope, we shipped it: > > Red Hat Desktop (v. 3 for AMD64/Intel EM64T): > 55f454aad84a225fe3e984a6841765ed samba-swat-3.0.6-2.3E.x86_64.rpm > a773ae10653c34bc0b82aa0bd442fb33 samba-common-3.0.6-2.3E.x86_64.rpm > 1c1b17d2e518d7e96b61c2f05aff7ebd samba-client-3.0.6-2.3E.x86_64.rpm > 329297e8b30f956fde14bb1ccabc16b6 samba-3.0.6-2.3E.x86_64.rpm > 4540f7279bb9fb55b5170aae496b16d8 samba-3.0.6-2.3E.i386.rpm > > That from: > > https://rhn.redhat.com/network/errata/details/package_list.pxt?eid=2358 > > So, not really sure what's going on. You might want to run 'up2date -v' > and see if that output helps point to the issue. For RHEL yes, but based on the version numbers we're talking about FC2 here: samba-3.0.3-5 is the version in original FC2 and sure enough there is no updated i386 samba package in here: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/2/x86_64/ - Panu - From Axel.Thimm at ATrpms.net Mon Sep 13 01:05:44 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 13 Sep 2004 03:05:44 +0200 Subject: 2.6.8-1.521 memory leak? (was: [...] FC1/i386 vs FC2/x86_64: [...] memory consumption?) In-Reply-To: <20040903104618.GN30573@devserv.devel.redhat.com> References: <20040831140550.GA24708@neu.physik.fu-berlin.de> <20040902202310.GA9380@redhat.com> <20040902203420.GI30573@devserv.devel.redhat.com> <20040903102043.GB11833@redhat.com> <20040903104053.GI26676@neu.physik.fu-berlin.de> <20040903104618.GN30573@devserv.devel.redhat.com> Message-ID: <20040913010544.GB11329@neu.physik.fu-berlin.de> On Fri, Sep 03, 2004 at 06:46:18AM -0400, Jakub Jelinek wrote: > On Fri, Sep 03, 2004 at 12:40:53PM +0200, Axel Thimm wrote: > > How can I debug the memory consumption on this box? Which figures are > > the ones to look for and which ones do accumulate for the OOM killer? > > IMHO best would be to install 32-bit and 64-bit httpd side by side, > configure it the same (with a different port number), > keep downloading the same page from it and try to grab > /proc//maps > from both processes. It turns out that memory gets consumed and not returned back to the system independent of httpd (the oom-killer just strikes there first). On an FC2/x86_64 system (Tyan S2880 with one processor only) with untained 2.6.8-1.521 on 1GB RAM simple compilations can eat up all the memory. I trimmed down such a system up to basic networking to detect which processes were locking the memory, and no userland processes are holding the memory. But almost all memory is flagged as "used" (with negligible size of buffers and cache). Is this a kernel memory leak? Any other information I should collect? (I still cannot judge whether the change from kernel 2.4 to 2.6 or the architecture change i386 to x86_64 is responsible for this due to lack of different combinations) # free total used free shared buffers cached Mem: 1027016 1022600 4416 0 992 7288 -/+ buffers/cache: 1014320 12696 Swap: 2047992 4496 2043496 # vmstat -a procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free inact active si so bi bo in cs us sy id wa 0 0 4496 4352 4548 6556 1 1 399 80 1517 162 2 2 88 8 # cat /proc/meminfo MemTotal: 1027016 kB MemFree: 4352 kB Buffers: 1008 kB Cached: 7316 kB SwapCached: 1148 kB Active: 6528 kB Inactive: 4536 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 1027016 kB LowFree: 4352 kB SwapTotal: 2047992 kB SwapFree: 2043496 kB Dirty: 236 kB Writeback: 0 kB Mapped: 5296 kB Slab: 14388 kB Committed_AS: 535496 kB PageTables: 494900 kB VmallocTotal: 536870911 kB VmallocUsed: 1568 kB VmallocChunk: 536869323 kB HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 2048 kB # ps uaxwwf USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 3472 428 ? S Sep12 0:01 init [3] root 2 0.0 0.0 0 0 ? SWN Sep12 0:00 [ksoftirqd/0] root 3 0.0 0.0 0 0 ? SW< Sep12 0:00 [events/0] root 4 0.0 0.0 0 0 ? SW< Sep12 0:00 \_ [khelper] root 5 0.0 0.0 0 0 ? SW< Sep12 0:00 \_ [kacpid] root 30 0.0 0.0 0 0 ? SW< Sep12 0:00 \_ [kblockd/0] root 44 0.0 0.0 0 0 ? SW Sep12 0:00 \_ [pdflush] root 45 0.0 0.0 0 0 ? SW Sep12 0:02 \_ [pdflush] root 47 0.0 0.0 0 0 ? SW< Sep12 0:00 \_ [aio/0] root 186 0.0 0.0 0 0 ? SW< Sep12 0:00 \_ [ata/0] root 31 0.0 0.0 0 0 ? SW Sep12 0:00 [khubd] root 46 0.0 0.0 0 0 ? SW Sep12 0:01 [kswapd0] root 151 0.0 0.0 0 0 ? SW Sep12 0:00 [kseriod] root 188 0.0 0.0 0 0 ? SW Sep12 0:00 [scsi_eh_0] root 189 0.0 0.0 0 0 ? SW Sep12 0:00 [scsi_eh_1] root 204 0.0 0.0 0 0 ? SW Sep12 0:00 [kjournald] root 339 0.0 0.0 2336 216 ? S< Sep12 0:00 udevd root 896 0.0 0.0 0 0 ? SW Sep12 0:00 [kjournald] root 897 0.0 0.0 0 0 ? SW Sep12 0:00 [kjournald] root 898 0.0 0.0 0 0 ? SW Sep12 0:00 [kjournald] root 899 0.0 0.0 0 0 ? SW Sep12 0:00 [kjournald] root 1637 0.0 0.0 0 0 ? SW< Sep12 0:00 [krfcommd] root 1946 0.0 0.0 18104 748 ? S Sep12 0:00 /usr/sbin/sshd root 5189 0.0 0.1 37540 1056 ? S 02:04 0:00 \_ sshd: root at pts/0 root 5195 0.0 0.0 45656 1020 pts/0 S 02:04 0:00 | \_ -bash root 5255 0.0 0.1 104764 1892 pts/0 S 02:04 0:00 | \_ gkrellm root 29075 0.0 0.0 44836 500 pts/0 S 02:38 0:00 | \_ sleep 10 root 6119 0.0 0.0 37284 1020 ? S 02:19 0:00 \_ sshd: root at pts/1 root 6133 0.0 0.1 45656 1120 pts/1 S 02:19 0:00 | \_ -bash root 29079 0.0 0.0 44476 924 pts/1 S 02:38 0:00 | \_ /bin/sh ./memory.sh root 29083 0.0 0.0 5228 784 pts/1 R 02:38 0:00 | \_ ps uaxwwf root 6193 0.0 0.0 37284 1020 ? S 02:20 0:00 \_ sshd: root at pts/2 root 6212 0.0 0.1 45656 1136 pts/2 S 02:20 0:00 | \_ -bash root 29077 0.0 0.1 35936 1932 ? S 02:38 0:00 \_ sshd: bin [priv] sshd 29078 0.0 0.1 19448 1120 ? S 02:38 0:00 \_ sshd: bin [net] root 2542 0.0 0.0 2344 272 tty1 S Sep12 0:00 /sbin/mingetty tty1 root 2543 0.0 0.0 2344 272 tty2 S Sep12 0:00 /sbin/mingetty tty2 root 2544 0.0 0.0 2344 272 tty3 S Sep12 0:00 /sbin/mingetty tty3 root 2545 0.0 0.0 2344 276 tty4 S Sep12 0:00 /sbin/mingetty tty4 root 2546 0.0 0.0 2344 276 tty5 S Sep12 0:00 /sbin/mingetty tty5 root 2547 0.0 0.0 2344 276 tty6 S Sep12 0:00 /sbin/mingetty tty6 -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Sep 13 09:36:28 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 13 Sep 2004 11:36:28 +0200 Subject: 2.6.8-1.521 memory leak? (was: [...] FC1/i386 vs FC2/x86_64: [...] memory consumption?) In-Reply-To: <20040913010544.GB11329@neu.physik.fu-berlin.de> References: <20040831140550.GA24708@neu.physik.fu-berlin.de> <20040902202310.GA9380@redhat.com> <20040902203420.GI30573@devserv.devel.redhat.com> <20040903102043.GB11833@redhat.com> <20040903104053.GI26676@neu.physik.fu-berlin.de> <20040903104618.GN30573@devserv.devel.redhat.com> <20040913010544.GB11329@neu.physik.fu-berlin.de> Message-ID: <20040913093628.GB3968@neu.physik.fu-berlin.de> As a follow-up, this looks familiar to the following bug reports in bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131251 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131414 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132180 The latter two may be leaking due to the SG_IO/bio_uncopy_user memory leak: http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.8.1/2.6.8.1-mm3/broken-out/bio_uncopy_user-mem-leak.patch But the system in question has no active device driven by SCSI layers (no SATA/SCSI/CD-ROM attached, only plain-old IDE), and the memory leak occurs when trying to rebuild 2.6.8-1.521 kernels or kernel modules. On Mon, Sep 13, 2004 at 03:05:44AM +0200, Axel Thimm wrote: > On Fri, Sep 03, 2004 at 06:46:18AM -0400, Jakub Jelinek wrote: > > On Fri, Sep 03, 2004 at 12:40:53PM +0200, Axel Thimm wrote: > > > How can I debug the memory consumption on this box? Which figures are > > > the ones to look for and which ones do accumulate for the OOM killer? > > > > IMHO best would be to install 32-bit and 64-bit httpd side by side, > > configure it the same (with a different port number), > > keep downloading the same page from it and try to grab > > /proc//maps > > from both processes. > > It turns out that memory gets consumed and not returned back to the > system independent of httpd (the oom-killer just strikes there first). > > On an FC2/x86_64 system (Tyan S2880 with one processor only) with > untained 2.6.8-1.521 on 1GB RAM simple compilations can eat up all the > memory. I trimmed down such a system up to basic networking to detect > which processes were locking the memory, and no userland processes are > holding the memory. But almost all memory is flagged as "used" (with > negligible size of buffers and cache). > > Is this a kernel memory leak? Any other information I should collect? > > (I still cannot judge whether the change from kernel 2.4 to 2.6 or the > architecture change i386 to x86_64 is responsible for this due to lack > of different combinations) > > # free > total used free shared buffers cached > Mem: 1027016 1022600 4416 0 992 7288 > -/+ buffers/cache: 1014320 12696 > Swap: 2047992 4496 2043496 > # vmstat -a > procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- > r b swpd free inact active si so bi bo in cs us sy id wa > 0 0 4496 4352 4548 6556 1 1 399 80 1517 162 2 2 88 8 > # cat /proc/meminfo > MemTotal: 1027016 kB > MemFree: 4352 kB > Buffers: 1008 kB > Cached: 7316 kB > SwapCached: 1148 kB > Active: 6528 kB > Inactive: 4536 kB > HighTotal: 0 kB > HighFree: 0 kB > LowTotal: 1027016 kB > LowFree: 4352 kB > SwapTotal: 2047992 kB > SwapFree: 2043496 kB > Dirty: 236 kB > Writeback: 0 kB > Mapped: 5296 kB > Slab: 14388 kB > Committed_AS: 535496 kB > PageTables: 494900 kB > VmallocTotal: 536870911 kB > VmallocUsed: 1568 kB > VmallocChunk: 536869323 kB > HugePages_Total: 0 > HugePages_Free: 0 > Hugepagesize: 2048 kB > # ps uaxwwf > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > root 1 0.0 0.0 3472 428 ? S Sep12 0:01 init [3] > root 2 0.0 0.0 0 0 ? SWN Sep12 0:00 [ksoftirqd/0] > root 3 0.0 0.0 0 0 ? SW< Sep12 0:00 [events/0] > root 4 0.0 0.0 0 0 ? SW< Sep12 0:00 \_ [khelper] > root 5 0.0 0.0 0 0 ? SW< Sep12 0:00 \_ [kacpid] > root 30 0.0 0.0 0 0 ? SW< Sep12 0:00 \_ [kblockd/0] > root 44 0.0 0.0 0 0 ? SW Sep12 0:00 \_ [pdflush] > root 45 0.0 0.0 0 0 ? SW Sep12 0:02 \_ [pdflush] > root 47 0.0 0.0 0 0 ? SW< Sep12 0:00 \_ [aio/0] > root 186 0.0 0.0 0 0 ? SW< Sep12 0:00 \_ [ata/0] > root 31 0.0 0.0 0 0 ? SW Sep12 0:00 [khubd] > root 46 0.0 0.0 0 0 ? SW Sep12 0:01 [kswapd0] > root 151 0.0 0.0 0 0 ? SW Sep12 0:00 [kseriod] > root 188 0.0 0.0 0 0 ? SW Sep12 0:00 [scsi_eh_0] > root 189 0.0 0.0 0 0 ? SW Sep12 0:00 [scsi_eh_1] > root 204 0.0 0.0 0 0 ? SW Sep12 0:00 [kjournald] > root 339 0.0 0.0 2336 216 ? S< Sep12 0:00 udevd > root 896 0.0 0.0 0 0 ? SW Sep12 0:00 [kjournald] > root 897 0.0 0.0 0 0 ? SW Sep12 0:00 [kjournald] > root 898 0.0 0.0 0 0 ? SW Sep12 0:00 [kjournald] > root 899 0.0 0.0 0 0 ? SW Sep12 0:00 [kjournald] > root 1637 0.0 0.0 0 0 ? SW< Sep12 0:00 [krfcommd] > root 1946 0.0 0.0 18104 748 ? S Sep12 0:00 /usr/sbin/sshd > root 5189 0.0 0.1 37540 1056 ? S 02:04 0:00 \_ sshd: root at pts/0 > root 5195 0.0 0.0 45656 1020 pts/0 S 02:04 0:00 | \_ -bash > root 5255 0.0 0.1 104764 1892 pts/0 S 02:04 0:00 | \_ gkrellm > root 29075 0.0 0.0 44836 500 pts/0 S 02:38 0:00 | \_ sleep 10 > root 6119 0.0 0.0 37284 1020 ? S 02:19 0:00 \_ sshd: root at pts/1 > root 6133 0.0 0.1 45656 1120 pts/1 S 02:19 0:00 | \_ -bash > root 29079 0.0 0.0 44476 924 pts/1 S 02:38 0:00 | \_ /bin/sh ./memory.sh > root 29083 0.0 0.0 5228 784 pts/1 R 02:38 0:00 | \_ ps uaxwwf > root 6193 0.0 0.0 37284 1020 ? S 02:20 0:00 \_ sshd: root at pts/2 > root 6212 0.0 0.1 45656 1136 pts/2 S 02:20 0:00 | \_ -bash > root 29077 0.0 0.1 35936 1932 ? S 02:38 0:00 \_ sshd: bin [priv] > sshd 29078 0.0 0.1 19448 1120 ? S 02:38 0:00 \_ sshd: bin [net] > root 2542 0.0 0.0 2344 272 tty1 S Sep12 0:00 /sbin/mingetty tty1 > root 2543 0.0 0.0 2344 272 tty2 S Sep12 0:00 /sbin/mingetty tty2 > root 2544 0.0 0.0 2344 272 tty3 S Sep12 0:00 /sbin/mingetty tty3 > root 2545 0.0 0.0 2344 276 tty4 S Sep12 0:00 /sbin/mingetty tty4 > root 2546 0.0 0.0 2344 276 tty5 S Sep12 0:00 /sbin/mingetty tty5 > root 2547 0.0 0.0 2344 276 tty6 S Sep12 0:00 /sbin/mingetty tty6 -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From amd64 at linuxfarms.com Fri Sep 17 14:41:00 2004 From: amd64 at linuxfarms.com (Arthur Perry) Date: Fri, 17 Sep 2004 10:41:00 -0400 (EDT) Subject: RHEL AS 3.0 support on AMD64 Message-ID: Hello, I have a quick question about support on RHEL AS 3.0 for X86_64. The support matrix claims that a max of only 16G of RAM is supported for X86_64, but a much larger amount is supported for the x86 platform. Is there a reason for this cutoff at 16G for x86_64? I just need some details from the folks at RedHat to explain this, without making my own assumptions. Thanks in advance! From amd64 at linuxfarms.com Fri Sep 17 14:42:57 2004 From: amd64 at linuxfarms.com (Arthur Perry) Date: Fri, 17 Sep 2004 10:42:57 -0400 (EDT) Subject: RHEL AS 3.0 support on AMD64 In-Reply-To: References: Message-ID: I am sorry. This has changed in the support matrix. It looks like 64G is also now supported. Sorry about that. Thanks anyways. On Fri, 17 Sep 2004, Arthur Perry wrote: > Hello, > > I have a quick question about support on RHEL AS 3.0 for X86_64. > The support matrix claims that a max of only 16G of RAM is supported for > X86_64, but a much larger amount is supported for the x86 platform. > > Is there a reason for this cutoff at 16G for x86_64? > > I just need some details from the folks at RedHat to explain this, without > making my own assumptions. > > Thanks in advance! > > > From riel at redhat.com Sat Sep 18 01:29:19 2004 From: riel at redhat.com (Rik van Riel) Date: Fri, 17 Sep 2004 21:29:19 -0400 (EDT) Subject: RHEL AS 3.0 support on AMD64 In-Reply-To: Message-ID: On Fri, 17 Sep 2004, Arthur Perry wrote: > This has changed in the support matrix. > It looks like 64G is also now supported. The support matrix lists how big a setup Red Hat has tested with. Bigger setups may well work, but since we have not tested them there's always the slight chance that they run into an unknown, obscure bug... This is why the limits in the support matrix may seem a bit on the low side sometimes. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From hugh at mimosa.com Sun Sep 19 17:42:27 2004 From: hugh at mimosa.com (D. Hugh Redelmeier) Date: Sun, 19 Sep 2004 13:42:27 -0400 (EDT) Subject: Samba Update In-Reply-To: <1094671542.3289.4.camel@chip.laiskiainen.org> Message-ID: | From: Panu Matilainen | For RHEL yes, but based on the version numbers we're talking about FC2 | here: samba-3.0.3-5 is the version in original FC2 and sure enough there | is no updated i386 samba package in here: | http://download.fedora.redhat.com/pub/fedora/linux/core/updates/2/x86_64/ I encountered this problem. Panu: thanks very much for your accurate analysis. I've entered this in bugzilla: If it isn't in bugzilla, it probably won't get fixed. I think that this is important since it blocks an update that fixes a security problem. Hugh Redelmeier hugh at mimosa.com voice: +1 416 482-8253 PS: I've learned more about "biarch" in the process. Rather weird and tricky. It isn't obvious that a .i386. package on x86_64 would necessarily be the same as the corresponding .i386. package in i386, but this seems to be the case. I inferred it from Panu's claim and from the fact that the corresponding packages in the original distributions were identical. From Axel.Thimm at ATrpms.net Mon Sep 20 10:32:14 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 20 Sep 2004 12:32:14 +0200 Subject: kernel memory leak on x86_64 in ia32 emulation mode (was: 2.6.8-1.521 memory leak?) In-Reply-To: <20040913093628.GB3968@neu.physik.fu-berlin.de> References: <20040831140550.GA24708@neu.physik.fu-berlin.de> <20040902202310.GA9380@redhat.com> <20040902203420.GI30573@devserv.devel.redhat.com> <20040903102043.GB11833@redhat.com> <20040903104053.GI26676@neu.physik.fu-berlin.de> <20040903104618.GN30573@devserv.devel.redhat.com> <20040913010544.GB11329@neu.physik.fu-berlin.de> <20040913093628.GB3968@neu.physik.fu-berlin.de> Message-ID: <20040920103214.GE26381@neu.physik.fu-berlin.de> On Mon, Sep 13, 2004 at 11:36:28AM +0200, Axel Thimm wrote: > On Mon, Sep 13, 2004 at 03:05:44AM +0200, Axel Thimm wrote: > > On Fri, Sep 03, 2004 at 06:46:18AM -0400, Jakub Jelinek wrote: > > > On Fri, Sep 03, 2004 at 12:40:53PM +0200, Axel Thimm wrote: > > > > How can I debug the memory consumption on this box? Which figures are > > > > the ones to look for and which ones do accumulate for the OOM killer? > > > > > > IMHO best would be to install 32-bit and 64-bit httpd side by side, > > > > It turns out that memory gets consumed and not returned back to the > > system independent of httpd (the oom-killer just strikes there first). The bug has now been identified as a kernel memory leak in 2.6.8-1.521 and 2.6.8-1.541 on a x86_64 system running ia32 bit apps in IA32_EMULATION mode. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132947 It is easily reproducable, and I wonder why there have been so few reports on the net on this (kernel 2.6.8-1.521 has been released before a month). Probably most x86_64 users are running in 64 bits only and don't observe the leak. Any references/fixes are more than welcome. :) > > On an FC2/x86_64 system (Tyan S2880 with one processor only) with > > untained 2.6.8-1.521 on 1GB RAM simple compilations can eat up all the > > memory. I trimmed down such a system up to basic networking to detect > > which processes were locking the memory, and no userland processes are > > holding the memory. But almost all memory is flagged as "used" (with > > negligible size of buffers and cache). > > > > Is this a kernel memory leak? Any other information I should collect? > > > > (I still cannot judge whether the change from kernel 2.4 to 2.6 or the > > architecture change i386 to x86_64 is responsible for this due to lack > > of different combinations) > > > > # free > > total used free shared buffers cached > > Mem: 1027016 1022600 4416 0 992 7288 > > -/+ buffers/cache: 1014320 12696 > > Swap: 2047992 4496 2043496 > > # vmstat -a > > procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- > > r b swpd free inact active si so bi bo in cs us sy id wa > > 0 0 4496 4352 4548 6556 1 1 399 80 1517 162 2 2 88 8 > > # cat /proc/meminfo > > MemTotal: 1027016 kB > > MemFree: 4352 kB > > Buffers: 1008 kB > > Cached: 7316 kB > > SwapCached: 1148 kB > > Active: 6528 kB > > Inactive: 4536 kB > > HighTotal: 0 kB > > HighFree: 0 kB > > LowTotal: 1027016 kB > > LowFree: 4352 kB > > SwapTotal: 2047992 kB > > SwapFree: 2043496 kB > > Dirty: 236 kB > > Writeback: 0 kB > > Mapped: 5296 kB > > Slab: 14388 kB > > Committed_AS: 535496 kB > > PageTables: 494900 kB > > VmallocTotal: 536870911 kB > > VmallocUsed: 1568 kB > > VmallocChunk: 536869323 kB > > HugePages_Total: 0 > > HugePages_Free: 0 > > Hugepagesize: 2048 kB > > # ps uaxwwf > > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > > root 1 0.0 0.0 3472 428 ? S Sep12 0:01 init [3] > > root 2 0.0 0.0 0 0 ? SWN Sep12 0:00 [ksoftirqd/0] > > root 3 0.0 0.0 0 0 ? SW< Sep12 0:00 [events/0] > > root 4 0.0 0.0 0 0 ? SW< Sep12 0:00 \_ [khelper] > > root 5 0.0 0.0 0 0 ? SW< Sep12 0:00 \_ [kacpid] > > root 30 0.0 0.0 0 0 ? SW< Sep12 0:00 \_ [kblockd/0] > > root 44 0.0 0.0 0 0 ? SW Sep12 0:00 \_ [pdflush] > > root 45 0.0 0.0 0 0 ? SW Sep12 0:02 \_ [pdflush] > > root 47 0.0 0.0 0 0 ? SW< Sep12 0:00 \_ [aio/0] > > root 186 0.0 0.0 0 0 ? SW< Sep12 0:00 \_ [ata/0] > > root 31 0.0 0.0 0 0 ? SW Sep12 0:00 [khubd] > > root 46 0.0 0.0 0 0 ? SW Sep12 0:01 [kswapd0] > > root 151 0.0 0.0 0 0 ? SW Sep12 0:00 [kseriod] > > root 188 0.0 0.0 0 0 ? SW Sep12 0:00 [scsi_eh_0] > > root 189 0.0 0.0 0 0 ? SW Sep12 0:00 [scsi_eh_1] > > root 204 0.0 0.0 0 0 ? SW Sep12 0:00 [kjournald] > > root 339 0.0 0.0 2336 216 ? S< Sep12 0:00 udevd > > root 896 0.0 0.0 0 0 ? SW Sep12 0:00 [kjournald] > > root 897 0.0 0.0 0 0 ? SW Sep12 0:00 [kjournald] > > root 898 0.0 0.0 0 0 ? SW Sep12 0:00 [kjournald] > > root 899 0.0 0.0 0 0 ? SW Sep12 0:00 [kjournald] > > root 1637 0.0 0.0 0 0 ? SW< Sep12 0:00 [krfcommd] > > root 1946 0.0 0.0 18104 748 ? S Sep12 0:00 /usr/sbin/sshd > > root 5189 0.0 0.1 37540 1056 ? S 02:04 0:00 \_ sshd: root at pts/0 > > root 5195 0.0 0.0 45656 1020 pts/0 S 02:04 0:00 | \_ -bash > > root 5255 0.0 0.1 104764 1892 pts/0 S 02:04 0:00 | \_ gkrellm > > root 29075 0.0 0.0 44836 500 pts/0 S 02:38 0:00 | \_ sleep 10 > > root 6119 0.0 0.0 37284 1020 ? S 02:19 0:00 \_ sshd: root at pts/1 > > root 6133 0.0 0.1 45656 1120 pts/1 S 02:19 0:00 | \_ -bash > > root 29079 0.0 0.0 44476 924 pts/1 S 02:38 0:00 | \_ /bin/sh ./memory.sh > > root 29083 0.0 0.0 5228 784 pts/1 R 02:38 0:00 | \_ ps uaxwwf > > root 6193 0.0 0.0 37284 1020 ? S 02:20 0:00 \_ sshd: root at pts/2 > > root 6212 0.0 0.1 45656 1136 pts/2 S 02:20 0:00 | \_ -bash > > root 29077 0.0 0.1 35936 1932 ? S 02:38 0:00 \_ sshd: bin [priv] > > sshd 29078 0.0 0.1 19448 1120 ? S 02:38 0:00 \_ sshd: bin [net] > > root 2542 0.0 0.0 2344 272 tty1 S Sep12 0:00 /sbin/mingetty tty1 > > root 2543 0.0 0.0 2344 272 tty2 S Sep12 0:00 /sbin/mingetty tty2 > > root 2544 0.0 0.0 2344 272 tty3 S Sep12 0:00 /sbin/mingetty tty3 > > root 2545 0.0 0.0 2344 276 tty4 S Sep12 0:00 /sbin/mingetty tty4 > > root 2546 0.0 0.0 2344 276 tty5 S Sep12 0:00 /sbin/mingetty tty5 > > root 2547 0.0 0.0 2344 276 tty6 S Sep12 0:00 /sbin/mingetty tty6 > > > > > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hugh at mimosa.com Tue Sep 21 21:05:11 2004 From: hugh at mimosa.com (D. Hugh Redelmeier) Date: Tue, 21 Sep 2004 17:05:11 -0400 (EDT) Subject: Samba Update In-Reply-To: Message-ID: | From: D. Hugh Redelmeier | I've entered this in bugzilla: | And it is now fixed! Thanks to Bill Nottingham of Red Hat. This is a demonstration that it is worthwhile filing problem reports in Bugzilla. -- Hugh Redelmeier hugh at mimosa.com voice: +1 416 482-8253 From eugen at leitl.org Wed Sep 22 06:39:54 2004 From: eugen at leitl.org (Eugen Leitl) Date: Wed, 22 Sep 2004 08:39:54 +0200 Subject: Samba Update In-Reply-To: References: Message-ID: <20040922063954.GG1457@leitl.org> On Tue, Sep 21, 2004 at 05:05:11PM -0400, D. Hugh Redelmeier wrote: > And it is now fixed! > > Thanks to Bill Nottingham of Red Hat. And thanks to you for having reported it. That hanging samba update was a nuisance. > This is a demonstration that it is worthwhile filing problem reports > in Bugzilla. x86_64 still seems to be a fringe architecture, though. -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From eugen at leitl.org Wed Sep 22 08:14:44 2004 From: eugen at leitl.org (Eugen Leitl) Date: Wed, 22 Sep 2004 10:14:44 +0200 Subject: any idea on nVidia/ATI support on X.org on FC3? Message-ID: <20040922081444.GM1457@leitl.org> Any idea what the FC3/X.org support for the x86_64 will be? I haven't been able to get the accelerated nVidia (EnForce 5200 FX) nor ATI (Radeon 9600) going (not that I tried very hard). Ditto dual-head support, xorg.conf needs manual adjustment to work. I understand that at least Radeon support is improved in latest X.org. -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From marshall at novafoundry.com Thu Sep 23 10:51:35 2004 From: marshall at novafoundry.com (Marshall Lewis) Date: Thu, 23 Sep 2004 06:51:35 -0400 Subject: any idea on nVidia/ATI support on X.org on FC3? In-Reply-To: <20040922081444.GM1457@leitl.org> References: <20040922081444.GM1457@leitl.org> Message-ID: <1095936695.18314.6.camel@grendel> I've been using the nVidia drivers with generally no problems. With the switch to udev, I've had issues with the nvidia driver loading automatically after I compile it, so I have to issue a "modprobe nvidia" prior to starting X. But that's pretty much the only glitch I've seen. I do have to configure the xorg.conf file by hand to get twinview working the way I want though.. and I don't actually expect that the tools that come with fedora/redhat will ever support configuring that. But then again.. I'm just used to configuring the file by hand so I haven't looked at the config tool that fedora is shipping with :) What kind of problems are you having with the nVidia setup? Oh, and ATI still hasn't released x86_64 drivers for linux (at least last time I looked (early august)... I eventually gave up on them, sold my card, and bought the nVidia card I have now). -- Marshall On Wed, 2004-09-22 at 10:14 +0200, Eugen Leitl wrote: > Any idea what the FC3/X.org support for the x86_64 will be? > I haven't been able to get the accelerated nVidia (EnForce 5200 FX) nor ATI (Radeon > 9600) going (not that I tried very hard). Ditto dual-head support, xorg.conf > needs manual adjustment to work. > > I understand that at least Radeon support is improved in latest X.org. > > -- > amd64-list mailing list > amd64-list at redhat.com > https://www.redhat.com/mailman/listinfo/amd64-list -- Marshall Lewis From mark at harddata.com Thu Sep 23 15:29:05 2004 From: mark at harddata.com (Mark Lane) Date: Thu, 23 Sep 2004 09:29:05 -0600 Subject: any idea on nVidia/ATI support on X.org on FC3? In-Reply-To: <1095936695.18314.6.camel@grendel> References: <20040922081444.GM1457@leitl.org> <1095936695.18314.6.camel@grendel> Message-ID: <200409230929.05943.mark@harddata.com> On September 23, 2004 04:51 am, Marshall Lewis > Oh, and ATI still hasn't released x86_64 drivers for linux (at least > last time I looked (early august)... I eventually gave up on them, sold > my card, and bought the nVidia card I have now). Have you signed the Petition. ATI promised us drivers last year and still hasn't delivered them. http://www.petitiononline.com/atipet/petition.html > > I understand that at least Radeon support is improved in latest X.org. Yeah maybe but you still can't get 3D from anything over r2xx chipset. -- Mark Lane, CET -- mailto:mark at harddata.com Sales Manager -- Hard Data Ltd -- http://www.harddata.com T: 01-780-456-9771 -- F: 01-780-456-9772 11060 - 166 Avenue Edmonton, AB, Canada, T5X 1Y3 --> Ask me about our New Dual and 4 Way Blade Servers <-- From eugen at leitl.org Thu Sep 23 15:50:32 2004 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 23 Sep 2004 17:50:32 +0200 Subject: any idea on nVidia/ATI support on X.org on FC3? In-Reply-To: <200409230929.05943.mark@harddata.com> References: <20040922081444.GM1457@leitl.org> <1095936695.18314.6.camel@grendel> <200409230929.05943.mark@harddata.com> Message-ID: <20040923155031.GE1457@leitl.org> On Thu, Sep 23, 2004 at 09:29:05AM -0600, Mark Lane wrote: > On September 23, 2004 04:51 am, Marshall Lewis > > Oh, and ATI still hasn't released x86_64 drivers for linux (at least > > last time I looked (early august)... I eventually gave up on them, sold > > my card, and bought the nVidia card I have now). > > Have you signed the Petition. ATI promised us drivers last year and still > hasn't delivered them. > > http://www.petitiononline.com/atipet/petition.html Yeah. I just went back there and signed the second time as a business, as we do use Radeon and Linux at work. > > > I understand that at least Radeon support is improved in latest X.org. > > Yeah maybe but you still can't get 3D from anything over r2xx chipset. Yeah, the support is pathetic. Closed source, or no, but there are chemistry and biology people who absolutely need speedy OpenGL, and this video driver business baffles them completely. VMD list archives are full of support requests. What's really awful is that once one has configured accelerated 3d, it's gone with the next kernel upgrade. Once one gets used to that "feature" Xfree86 idiots change their license, and we're back a couple squares with X.org, and underwhelming support of nVidia/ATI people. Aargh! I'm so sick of it I'm going to get me a budget OS X Mac, just to have some stability with 3d support (nVidia FX 5200 Ultra might look dusty to a gamer, but it's sure enough for science applications). -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Sep 24 08:13:42 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 24 Sep 2004 10:13:42 +0200 Subject: Request for FC3Blocker: #132947 (kernel memory leak on x86_64 in 32/64 mixed mode) Message-ID: <20040924081342.GA4894@neu.nirvana> According to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130887: > This is the master Fedora Core 3 "BLOCKER" bug. Any bug in > Red Hat bugzilla which would be considered a "stop ship" bug > a.k.a. a "ultra brown paper bag" bug, can be marked for consideration > to be a release BLOCKER by adding this bug to it's "Blocks:" field. > > Anyone in the community who wishes to nominate bugs for FC3Blocker > status, should discuss them on the fedora-devel-list at redhat.com, > and once concensus has been reached, someone can flag them as > FC3Blocker, or alternatively as FC3Target. > > This bug has the bug alias "FC3Blocker" for easy access and > blocker flagging. I think https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132947 is a definite candidate: > Running 32 bits applications on x86_64 FC distributions with kernels > based on 2.6.8 (2.6.8-1.521 and 2.6.8-1.541 currently) generate > continuous memory leaks. Returning to the previous 2.6.7 based > kernels turns this behaviour off. The bug comes from FC2 (so testers need not run FC3t2 to verify). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mark at harddata.com Fri Sep 24 16:18:45 2004 From: mark at harddata.com (Mark Lane) Date: Fri, 24 Sep 2004 10:18:45 -0600 Subject: any idea on nVidia/ATI support on X.org on FC3? In-Reply-To: <20040923155031.GE1457@leitl.org> References: <20040922081444.GM1457@leitl.org> <200409230929.05943.mark@harddata.com> <20040923155031.GE1457@leitl.org> Message-ID: <200409241018.45693.mark@harddata.com> On September 23, 2004 09:50 am, Eugen Leitl wrote: > On Thu, Sep 23, 2004 at 09:29:05AM -0600, Mark Lane wrote: > > On September 23, 2004 04:51 am, Marshall Lewis > > > > > Oh, and ATI still hasn't released x86_64 drivers for linux (at least > > > last time I looked (early august)... I eventually gave up on them, sold > > > my card, and bought the nVidia card I have now). > > > > Have you signed the Petition. ATI promised us drivers last year and still > > hasn't delivered them. > > > > http://www.petitiononline.com/atipet/petition.html > > Yeah. I just went back there and signed the second time as a business, as > we do use Radeon and Linux at work. > > > > > I understand that at least Radeon support is improved in latest > > > > X.org. > > > > Yeah maybe but you still can't get 3D from anything over r2xx chipset. > > Yeah, the support is pathetic. Closed source, or no, but there are > chemistry and biology people who absolutely need speedy OpenGL, and this > video driver business baffles them completely. VMD list archives are full > of support requests. Well hopefully this announcement by ATI is not just more vaporware. http://www.theinquirer.net/?article=18664 -- Mark Lane, CET -- mailto:mark at harddata.com Sales Manager -- Hard Data Ltd -- http://www.harddata.com T: 01-780-456-9771 -- F: 01-780-456-9772 11060 - 166 Avenue Edmonton, AB, Canada, T5X 1Y3 --> Ask me about our New Dual and 4 Way Blade Servers <-- From eugen at leitl.org Tue Sep 28 16:00:24 2004 From: eugen at leitl.org (Eugen Leitl) Date: Tue, 28 Sep 2004 18:00:24 +0200 Subject: MD5 digest: BAD Expected Message-ID: <20040928160024.GR1457@leitl.org> Does anyone knows what's up with error messages like Downloading Packages error: rpmts_HdrFromFdno: MD5 digest: BAD Expected(3c92110ada4549cf6818835a7c69e7f0) != (37a261901ff63c1c711f112d17ff82d6) Damaged RPM /var/cache/yum/updates-released/packages/libpng-1.2.5-8.i386.rpm, removing. ? I'm getting these frequently when running yum update on Athlon64 or Opteron (Sun Fire) systems. Ctrl+C and rerunning yum usually fixes this. Are these timeouts due to overloaded servers? Why doesn't Fedora use Bittorrent or other P2P means of update, anyone knows? (Otoh, FC2 did install cleanly on the Sun Fire, while SLES9 did leave a broken install, and SLES8 hung on boot). -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mlauterbach at mail.wtamu.edu Thu Sep 30 08:02:47 2004 From: mlauterbach at mail.wtamu.edu (Matthew E. Lauterbach) Date: Thu, 30 Sep 2004 03:02:47 -0500 Subject: amd64-list Digest, Vol 7, Issue 13 In-Reply-To: <20040929160004.D043572FE5@hormel.redhat.com> Message-ID: <20040930080248.082783E6353@mail.wtamu.edu> On Tue, 28 Sep 2004 18:00:24 +0200, Eugen Leitl wrote > Does anyone knows what's up with error messages like > > Downloading Packages > error: rpmts_HdrFromFdno: MD5 digest: BAD > Expected(3c92110ada4549cf6818835a7c69e7f0) != > (37a261901ff63c1c711f112d17ff82d6) > Damaged RPM > /var/cache/yum/updates-released/packages/libpng-1.2.5-8.i386.rpm, > removing. > > ? > > I'm getting these frequently when running yum update on Athlon64 > or Opteron (Sun Fire) systems. Ctrl+C and rerunning yum > usually fixes this. > > Are these timeouts due to overloaded servers? My guess would be a corrupted mirror. Can you tell if all the bad packages are coming from the same mirror? I wouldn't think that with an overloaded mirror you would get far enough for yum to do a checksum on the package. > > Why doesn't Fedora use Bittorrent or other P2P means of > update, anyone knows? > Not sure. Probably not trivial to implement. Plus, you would have to maintain a seed for each package all at one location to harness the power of bittorrent. This could be feasible with the main repository hosting the seed, the mirrors bittorrenting the packages, and leaving the connection open to help with downloads. However, you would have to implement some sort of failover communication between the main repository and the mirrors so that one of the mirrors could take over hosting the seed if the main repository failed. Then, the client would also have to have some method to failover and try different seed. Maybe some other type of P2P would be better suited to the task? > (Otoh, FC2 did install cleanly on the Sun Fire, while SLES9 > did leave a > broken install, and SLES8 hung on boot). From kevin.jackson at tradermedia.co.uk Thu Sep 30 12:11:35 2004 From: kevin.jackson at tradermedia.co.uk (Kevin Jackson) Date: Thu, 30 Sep 2004 13:11:35 +0100 Subject: Remote Console using SOL / Sending F12 to PXE Boot Message-ID: <571D396508328043BE6D0309DA2204890120A0D3@newl0010.nlw.autotrader.co.uk> Not strictly OT as this could be any hardware, but I'm trying to get Serial Over Lan working and being able to send the keypress F12 from a Linux ssh console session. The setup: Workstation (RHEL 3 WS) - ssh-to - Management Console (RHEL 3 AMD64) - ssh-to SOL Console Session (RHEL 3 AMD64) When the system boots, to force PXE booting the hardware (Sun Fire v20z) requires the F12 key to be pressed. How do I achieve this from the scenario above. I've seen press ^[@, ^[-, ^[2 combinations. I've also seen solutions along the lines of changing F12 keypress binding in PuTTY to be ESC0A - but PuTTY can't be used in the scenario above as 1) I'm using Linux and 2) There is no direct connection to the Management Network to get the SOL connection. The SOL connection is fine from start (BIOS) to installations to Login prompt - just this F12 issue. Any solutions appreciated as I'm slowly going mad. -- Kevin Jackson RHCE Senior Systems Administrator Trader Media Ltd Tel 01925 296 394 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** From mlauterbach at mail.wtamu.edu Thu Sep 30 13:10:13 2004 From: mlauterbach at mail.wtamu.edu (Matthew E. Lauterbach) Date: Thu, 30 Sep 2004 08:10:13 -0500 Subject: Remote Console using SOL / Sending F12 to PXE Boot In-Reply-To: <571D396508328043BE6D0309DA2204890120A0D3@newl0010.nlw.autotrader.co.uk> Message-ID: <20040930131008.EFC183E6298@mail.wtamu.edu> On Thursday, September 30, 2004 7:12 AM, Kevin Jackson wrote: > Not strictly OT as this could be any hardware, but I'm trying > to get Serial > Over Lan working and being able to send the keypress F12 from > a Linux ssh > console session. > > The setup: Workstation (RHEL 3 WS) - ssh-to - Management > Console (RHEL 3 > AMD64) - ssh-to SOL Console Session (RHEL 3 AMD64) > > When the system boots, to force PXE booting the hardware (Sun > Fire v20z) > requires the F12 key to be pressed. You can't alter the boot order in Sun's BIOS? Also, this list doesn't seem to be the most popular. Since your question is hardware neutral, you may have better luck getting a good answer on one of the more popular lists. Sorry, I wasn't much help, but I've never needed to do anything with SOL. Matt From kevin.jackson at tradermedia.co.uk Thu Sep 30 13:17:00 2004 From: kevin.jackson at tradermedia.co.uk (Kevin Jackson) Date: Thu, 30 Sep 2004 14:17:00 +0100 Subject: Remote Console using SOL / Sending F12 to PXE Boot Message-ID: <571D396508328043BE6D0309DA22048903055C5A@newl0010.nlw.autotrader.co.uk> Yes, the loose association with amd64 was the fact that it was Opteron based Sun Fire hardware... The idea of the SOL is that allows us to do full remote administration - altering the BIOS requires someone to physically do that and that's not possible. Well - this is for a new roll out of hardware - I could re-arrange my PXE setup so that ALL boxes first look for the PXE server, and that server is set to drop to hard drive booting. As long as the SOL connection works for installs, I can select installations at the PXE boot screen. Probably the only way I can achieve this. Kev -----Original Message----- From: Matthew E. Lauterbach [mailto:mlauterbach at mail.wtamu.edu] Sent: 30 September 2004 14:10 To: 'Kevin Jackson'; amd64-list at redhat.com Subject: RE: Remote Console using SOL / Sending F12 to PXE Boot On Thursday, September 30, 2004 7:12 AM, Kevin Jackson wrote: > Not strictly OT as this could be any hardware, but I'm trying > to get Serial > Over Lan working and being able to send the keypress F12 from > a Linux ssh > console session. > > The setup: Workstation (RHEL 3 WS) - ssh-to - Management > Console (RHEL 3 > AMD64) - ssh-to SOL Console Session (RHEL 3 AMD64) > > When the system boots, to force PXE booting the hardware (Sun > Fire v20z) > requires the F12 key to be pressed. You can't alter the boot order in Sun's BIOS? Also, this list doesn't seem to be the most popular. Since your question is hardware neutral, you may have better luck getting a good answer on one of the more popular lists. Sorry, I wasn't much help, but I've never needed to do anything with SOL. Matt ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** From mlauterbach at mail.wtamu.edu Thu Sep 30 13:51:35 2004 From: mlauterbach at mail.wtamu.edu (Matthew E. Lauterbach) Date: Thu, 30 Sep 2004 08:51:35 -0500 Subject: Remote Console using SOL / Sending F12 to PXE Boot In-Reply-To: <571D396508328043BE6D0309DA22048903055C5A@newl0010.nlw.autotrader.co.uk> Message-ID: <20040930135136.5A79B3E62F2@mail.wtamu.edu> On Thursday, September 30, 2004 8:17 AM, Kevin Jackson wrote: > The idea of the SOL is that allows us to do full remote > administration - > altering the BIOS requires someone to physically do that and > that's not > possible. > We use a KVM type product that pushes the console sessions out over IP. I think its called IPReach. It can push the console out to specific stations or even make it available over IP. I doubt it was cheap and it may still have problems sending an F12 > Well - this is for a new roll out of hardware - I could > re-arrange my PXE > setup so that ALL boxes first look for the PXE server, and > that server is > set to drop to hard drive booting. As long as the SOL > connection works for > installs, I can select installations at the PXE boot screen. > Probably the only way I can achieve this. > > Kev Matt From kevin.jackson at tradermedia.co.uk Thu Sep 30 14:14:15 2004 From: kevin.jackson at tradermedia.co.uk (Kevin Jackson) Date: Thu, 30 Sep 2004 15:14:15 +0100 Subject: Remote Console using SOL / Sending F12 to PXE Boot Message-ID: <571D396508328043BE6D0309DA22048903055CBA@newl0010.nlw.autotrader.co.uk> Cheers for the info, but the Sun Fire boxes have this feature enabled in its SP to alleviate the need for such hardware so I suspect I'll be in the same boat. Thanks though for your input. Kev -----Original Message----- From: Matthew E. Lauterbach [mailto:mlauterbach at mail.wtamu.edu] Sent: 30 September 2004 14:52 To: 'Kevin Jackson'; amd64-list at redhat.com Subject: RE: Remote Console using SOL / Sending F12 to PXE Boot We use a KVM type product that pushes the console sessions out over IP. I think its called IPReach. It can push the console out to specific stations or even make it available over IP. I doubt it was cheap and it may still have problems sending an F12 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************