Bug#677035: libavcodec52: SEGV when encoding video
On Mon, Jun 11, 2012 at 12:05:05PM +0200, Reinhard Tartler wrote: In order to check if that bug has already been fixed upstream, could you please install the libavcodec-extra-53 package from backports.org and check if the segmentation fault still occurs? I've just tried libav-tools 4:0.8-2~bpo60+1 and libavcodec53 segfaults too, so perhaps the problem is present upstream. After my submission, I've noticed that it crashes with horizontal sizes 626, 632, and 852, but not with sizes 624 and 640. Coupled with the name of the top-of-stack function (sad16_sse2), that suggests a workaround: use horizontal sizes that are multiples of 16. Although I've had no time to examine the code (and I'm no expert in assembly) I guess that the problem might be caused by a wrongly aligned or sized buffer. Regards, g -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514832: [php-maint] Bug#514832: php5: performance: php_curl_stream_read() unnecessarily sleeps 15 secs under heavy load.
I haven't received any news from debian, so I'm forwarding the report upstream myself. (http://bugs.php.net/bug.php?id=47477) best regards -- giuseppe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514832: [php-maint] Bug#514832: php5: performance: php_curl_stream_read() unnecessarily sleeps 15 secs under heavy load.
On Wed, Feb 11, 2009 at 11:34:00AM -0600, Raphael Geissert wrote: I believe this problem is related to http://bugs.php.net/bug.php?id=23258 Although it could be possible that a similar situation happens when using the standard streams functions it is not caused by this bug in curl, because curl is not used by fopen/fsockopen and friends. I'm not very familiar with php, but I believe that libcurl is indeed used when a url is passed as filename to fopen(). The patch looks good, thanks! Have you considered reporting this bug to upstream so that we don't just fix it locally? Please do it, thanks in advance. hm... I've not tested it very extensively, hence it's advisable to have upstream check the patch, before applying it locally. however, I'd rather avoid duplicating this bug report: would you debian php developers mind forwarding the patch upstream? let me know. regards, giuseppe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#465107: texlive-metapost: missing supp-pdf.tex and supp-mis.tex
On Wed, Feb 20, 2008 at 08:21:00PM +0100, Norbert Preining wrote: On Mi, 20 Feb 2008, Ralf Stubner wrote: the file. Being able to include mp files in pdflatex is the prime reason why I have context installed ... Does that mean that the *only* file needed is supp-pdf.tex and supp-mis.tex? [...] Yes, exactly as the subject of the bug report suggests. [...] If they two are enough we could (in 2007 2005 is finished) put them into texlive-metapost which will put them into /usr/share/texmf-texlive/... and at the same time context will ship them in /usr/share/texmf/... so that if context ships newer versions they will be found, and if context is not installed the one from texlive-metapost will be found? Have you considered a solution based on dpkg-divert or update-alternatives? best wishes -- giuseppe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465107: texlive-metapost: missing supp-pdf.tex and supp-mis.tex
On Wed, Feb 20, 2008 at 10:20:30AM +0100, Norbert Preining wrote: supp-pdf.tex is maintained in context and shipped there. If you want automatic conversion you either have to install context, or copy the file. Or you do manual mp2pdf. Hi Norbert Do you mean mptopdf (also in package context)? After all, it seems that even in the modular world of texlive, ConTeXt has to be installed anyway... Unless you decide to split cont-mpd (200 Kb) from the rest of context (32 MB in lenny), then make texlive-metapost Suggest cont-mpd and context Depend on cont-mpd. Best regards, -- giuseppe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314260: close #314260
close 314260 thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#331424: close Bug #331424
close 331424 thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420762: openoffice.org-calc should depend on openoffice.org-base
Hi Rene On Tue, Apr 24, 2007 at 05:10:06PM +0200, Rene Engelhard wrote: Hi, giuseppe bonacci wrote: OOO 2.0 crashed repeatedly when trying to open a relatively simple sxc spreadsheet that OOO 1.x had always opened correctly. What do you define as relatively simple? I mean: no database, no external data source, document macros disabled at open time, only about 30x30 cells, with some it_IT-localized formatting for dates and only a few computed cells. unfortunately I'm not allowed to send you the file. after a couple of failed attempts at finding the reason for the SEGV and interpreting the elegant message unexpected error, next time I will try to recover your file (at least as informative as MS office ones ;-), I found that installing openoffice.org-base and its dependencies solved the problem. Did you use any stuff having to do with databases? Or data sources? Can you provide a backtrace from the crash? Or strace? attached a backtrace. A strict dependency of -calc to -base would be quite nonsensical, otherwise you could forget the whole split directly. (Same with the writer functions needing -base) I agree. but I'm sure the average user faced with the impossibility of opening his much needed document will probably curse debian, rather than appreciate the modularity. regards, -- giuseppe Starting program: /usr/lib/openoffice/program/soffice.bin -calc ~/p.sxc Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1244509984 (LWP 31630)] warning: Lowest section in /usr/lib/libicudata.so.36 is .hash at 00b4 [New Thread -1264489552 (LWP 31633)] [New Thread -1272964176 (LWP 31634)] [New Thread -1300874320 (LWP 31635)] [New Thread -1334412368 (LWP 31636)] [New Thread -1347359824 (LWP 31637)] [New Thread -1356112976 (LWP 31638)] [Thread -1356112976 (LWP 31638) exited] [New Thread -1356112976 (LWP 31641)] [Thread -1347359824 (LWP 31637) exited] [New Thread -1347359824 (LWP 31642)] [Thread -1356112976 (LWP 31641) exited] [New Thread -1356112976 (LWP 31643)] [Thread -1347359824 (LWP 31642) exited] [Thread -1356112976 (LWP 31643) exited] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1244509984 (LWP 31630)] 0xb761e402 in comphelper::OPropertySetAggregationHelper::getFastPropertyValue () from /usr/lib/openoffice/program/libcomphelp4gcc3.so #0 0xb761e402 in comphelper::OPropertySetAggregationHelper::getFastPropertyValue () from /usr/lib/openoffice/program/libcomphelp4gcc3.so #1 0xae86c2a6 in frm::ODatabaseForm::getFastPropertyValue () from /usr/lib/openoffice/program/libfrm680li.so #2 0xb748192a in cppu::OPropertySetHelper::getFastPropertyValue () from /usr/lib/openoffice/program/libuno_cppuhelpergcc3.so.3 #3 0xb761b93a in comphelper::OPropertySetAggregationHelper::getFastPropertyValue () from /usr/lib/openoffice/program/libcomphelp4gcc3.so #4 0xae8586ad in frm::ODatabaseForm::getFastPropertyValue () from /usr/lib/openoffice/program/libfrm680li.so #5 0xb7480d49 in cppu::OPropertySetHelper::getPropertyValue () from /usr/lib/openoffice/program/libuno_cppuhelpergcc3.so.3 #6 0xb11af6eb in isLoadable () from /usr/lib/openoffice/program/libsvx680li.so #7 0xb11cf8fd in FmXFormShell::loadForms () from /usr/lib/openoffice/program/libsvx680li.so #8 0xb11cfd04 in FmXFormShell::viewActivated () from /usr/lib/openoffice/program/libsvx680li.so #9 0xb11de925 in FmFormShell::Activate () from /usr/lib/openoffice/program/libsvx680li.so #10 0xb36a9214 in SfxShell::DoActivate_Impl () from /usr/lib/openoffice/program/libsfx680li.so #11 0xb3693dbe in SfxDispatcher::DoActivate_Impl () from /usr/lib/openoffice/program/libsfx680li.so #12 0xb366ae76 in SfxViewFrame::DoActivate () from /usr/lib/openoffice/program/libsfx680li.so #13 0xb34b20be in SfxApplication::SetViewFrame_Impl () from /usr/lib/openoffice/program/libsfx680li.so #14 0xb366b1f6 in SfxViewFrame::SetViewFrame () from /usr/lib/openoffice/program/libsfx680li.so #15 0xb366e499 in SfxViewFrame::MakeActive_Impl () from /usr/lib/openoffice/program/libsfx680li.so #16 0xb366e71e in SfxViewFrame::Show () from /usr/lib/openoffice/program/libsfx680li.so #17 0xb367e526 in SfxTopFrame::InsertDocument () from /usr/lib/openoffice/program/libsfx680li.so #18 0xb35c77e1 in SfxObjectShell::LoadWindows_Impl () from /usr/lib/openoffice/program/libsfx680li.so #19 0xb367e73a in SfxTopFrame::InsertDocument () from /usr/lib/openoffice/program/libsfx680li.so #20 0xb3657c87 in SfxFrameLoader_Impl::load () from /usr/lib/openoffice/program/libsfx680li.so #21 0xb3084286 in framework::LoadEnv::impl_loadContent () from /usr/lib/openoffice/program/libfwk680li.so #22 0xb3085f0a in framework::LoadEnv::startLoading () from /usr/lib/openoffice/program/libfwk680li.so #23 0xb3086141 in framework::LoadEnv::loadComponentFromURL () from /usr/lib/openoffice/program/libfwk680li.so #24 0xb2f2a9e4 in framework::Desktop::loadComponentFromURL () from
Bug#385557: mozilla-firefox: firefox crashes when printing http://www.springerlink.com/content/f6278062n3j61411
On Mon, Feb 19, 2007 at 05:04:54AM -0500, Eric Dorland wrote: * giuseppe bonacci ([EMAIL PROTECTED]) wrote: Package: mozilla-firefox Version: 1.0.4-2sarge10 Severity: normal trying to print the mentioned url, either to printer or file, crashes firefox. I'll provide further details if needed. best regards Any better in 1.0.4-2sarge15? hi Eric. Unfortunately, FF keeps crashing every time I try to print that url. Were you able to reproduce this behaviour on sarge? -- giuseppe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341377: lsb-core depends on (lpr) AND (lprng | cupsys-client)
You are right. Sorry for bothering you. Too bad the cheap (388k) and priority:standard package lpr must give way to the expensive (4156k) and priority:extra package lprng, or worse. -- g.b. On Wed, Nov 30, 2005 at 09:07:56AM -0500, Chris Lawrence wrote: The newest LSB specification requires /usr/bin/lp to be available - and the BSD-derived lpr package doesn't support/include it. Chris On 11/30/05, giuseppe bonacci [EMAIL PROTECTED] wrote: Package: lsb-core Version: 3.0-11 Severity: important - lsb-core depends on (lpr) AND (lprng | cupsys-client) - lprng and cupsys-client conflict with lpr - lprng and cupsys-bsd provide lpr as a result, installing lsb-core (or any of the lsb-* packages that depend on lsb-core) forces removing lpr in favour of lprng or (cupsys-client + cupsys-bsd), which is both useless and annoying. why doesn't lsb-core depend simply on (lpr | cupsys-client)? best regards -- gb -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages lsb-core depends on: ii alien8.59install non-native packages with d ii at 3.1.9 Delayed job execution and batch pr ii bc 1.06-19 The GNU bc arbitrary precision cal ii binutils 2.16.1-2The GNU assembler, linker and bina ii bsdmainutils 6.1.2 collection of more utilities from ii bsdutils 1:2.12p-8 Basic utilities from 4.4BSD-Lite ii cpio 2.6-9 GNU cpio -- a program to manage ar ii cron 3.0pl1-92 management of regular background p ii debconf [debconf 1.4.59 Debian configuration management sy ii ed 0.2-20 The classic unix line editor ii exim4-daemon-lig 4.54-2 lightweight exim MTA (v4) daemon ii file 4.15-2 Determines file type using magic ii libc62.3.5-8 GNU C Library: Shared libraries an ii libc6-dev [libc- 2.3.5-8 GNU C Library: Development Librari ii locales 2.3.5-8 GNU C Library: National Language ( ii lprng [lpr] 3.8.28-3.0.1lpr/lpd printer spooling system ii lsb-base 3.0-11 Linux Standard Base 3.0 init scrip ii lsb-release 3.0-11 Linux Standard Base version report ii m4 1.4.4-1 a macro processing language ii mailx1:8.1.2-0.20050715cvs-1 A simple mail user agent ii make 3.80-11 The GNU version of the make util ii man-db 2.4.3-3 The on-line manual pager ii mawk 1.3.3-11a pattern scanning and text proces ii ncurses-term 5.5-1 Additional terminal type definitio ii passwd 1:4.0.13-7 change and administer password and ii patch2.5.9-2 Apply a diff file to an original ii pax 1:1.5-15Portable Archive Interchange ii procps 1:3.2.5-1 /proc file system utilities ii psmisc 21.8-1 Utilities that use the proc filesy ii python 2.3.5-3 An interactive high-level object-o ii rsync2.6.6-1 fast remote file copy program (lik ii zlib1g [libz1] 1:1.2.3-8 compression library - runtime lsb-core recommends no packages. -- debconf information excluded -- Chris Lawrence - http://blog.lordsutch.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298709: chrony: just segfaults on amd64
Hi John,
would you mind applying the following patch, rebuilding and re-uploading?
maybe we finally converged, thanks the infinite patience of Felix.
-- gb
From: Felix Zielcke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: chrony: just segfaults on amd64
Date: Tue, 25 Oct 2005 18:23:58 +0200
now I think the attached patch (to be applied to the pristine chrony
sources) should solve the issue.
it did. now chrony doestn't segfault anymore and seems to work :)
From: [EMAIL PROTECTED]
To: Felix Zielcke [EMAIL PROTECTED]
Subject: Re: chrony: just segfaults on amd64
thank you, Felix.
After exploring the code a bit more closely, I found out
1. that I made a stupid mistake (I added an indirection level,
but the code was designed another way);
2. why the resulting buggy executable did not segfault on my server
(because of my config file, some of the functions in addrfilt.c were
not called --- in particular, open_node() was never called).
now I think the attached patch (to be applied to the pristine chrony
sources) should solve the issue.
may I ask you to recompile and test this new patch? I attach both the
patch and the modified addrfilt.c, in case you cannot easily apply the
patch.
best regards.
--- /tmp/chrony-1.20.old/addrfilt.c 2005-10-25 12:45:15.561893000 +0200
+++ /tmp/chrony-1.20/addrfilt.c 2005-10-25 13:01:13.391766233 +0200
@@ -43,17 +43,15 @@
/* Define the table size */
#define TABLE_SIZE (1ULNBITS)
-struct _TableNode;
-
-typedef struct _TableNode ExtendedTable[TABLE_SIZE];
-
typedef enum {DENY, ALLOW, AS_PARENT} State;
typedef struct _TableNode {
State state;
- ExtendedTable *extended;
+ struct _TableNode *extended;
} TableNode;
+typedef struct _TableNode ExtendedTable[TABLE_SIZE];
+
struct ADF_AuthTableInst {
TableNode base;
};
@@ -102,7 +100,7 @@
if (node-extended != NULL) {
for (i=0; iTABLE_SIZE; i++) {
- child_node = ((*(node-extended))[i]);
+ child_node = node-extended + i;
close_node(child_node);
}
Free(node-extended);
@@ -125,10 +123,10 @@
if (node-extended == NULL) {
- node-extended = MallocArray(ExtendedTable, TABLE_SIZE);
+ node-extended = (TableNode *) MallocArray(ExtendedTable, TABLE_SIZE);
for (i=0; iTABLE_SIZE; i++) {
- child_node = ((*(node-extended))[i]);
+ child_node = node-extended + i;
child_node-state = AS_PARENT;
child_node-extended = NULL;
}
@@ -169,7 +167,7 @@
if (!(node-extended)) {
open_node(node);
}
-node = ((*(node-extended))[subnet]);
+node = node-extended + subnet;
bits_to_go -= NBITS;
}
@@ -188,7 +186,7 @@
if (!(node-extended)) {
open_node(node);
}
-node = ((*(node-extended))[subnet]);
+node = node-extended + subnet;
bits_to_go -= NBITS;
}
@@ -200,7 +198,7 @@
}
for (i=subnet, j=0; jN; i++, j++) {
-this_node = ((*(node-extended))[i]);
+this_node = node-extended + i;
if (delete_children) {
close_node(this_node);
}
@@ -284,7 +282,7 @@
if (node-extended) {
subnet = get_subnet(residual);
residual = get_residual(residual);
- node = ((*(node-extended))[subnet]);
+ node = node-extended + subnet;
} else {
/* Make decision on this node */
finished = 1;
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298709: chrony: just segfaults on amd64
hi. can you please provide a backtrace (command: bt) from gdb? I suspect there's something wrong with other parts of the code. thanks. giuseppe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298709: chrony: just segfaults on amd64
On Mon, Oct 24, 2005 at 08:28:43PM +0200, Felix Zielcke wrote: as i said nothing useful but i should have made this clearer on my first post :) but now the complete gdb output except the text cut off between the ... because it's just the same as the other lines this is no surprise, since the executable you are running is stripped. if you want to help, you may recompile the package yourself, by following these steps: as root: - install build-dependencies: fakeroot dpkg-dev build-essential libreadline4-dev bison - put the relevant deb-src lines in your /etc/apt/sources.list deb-src http://ftp.debian.org/debian etch main deb-src http://security.debian.org etch/updates main and apt-get update as a regular user (not root): - cd /tmp/ ; apt-get source chrony ; cd chrony-1.20 - build with DEB_BUILD_OPTIONS=nostrip dpkg-buildpackage -rfakeroot -b - install the package you just made (it's in /tmp), and rerun gdb. you can run gdb on the new executable without even installing (it's in /tmp/chrony-1.20/debian/tmp/usr/...) I hope I did not forget anything... best regards. -- g.b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318959: libc6: unreproducible on powerpc
On Fri, Jul 22, 2005 at 10:34:08PM +0900, GOTO Masanori wrote: tags 318959 unreproducible, moreinfo thanks At Wed, 20 Jul 2005 05:16:32 +0100, Paul Brossier wrote: for info, i have been testing both testcases on powerpc and could not reproduce the issue. Me too. I don't know what the actual problem is - it may be hardware dependent problem, or simply system has another libc6. I'll close this bug. giuseppe, if you have more information about this, please report to us in detail. Regards, -- gotom Hi all. I think that is no hardware problem at all. Instead, Thorsten found a long standing bug in glibc, previously gone unnoticed. I was able to reproduce it on a bunch of x86/32 systems, both intel and amd, and several releases of Debian and RedHat versions: the tag unreproducible is not appropriate. I investigated a bit further, and I think the problem is a violation of the C89 and C99 standards in glibc-2.3.2.ds1/build-tree/glibc-2.3.2/sysdeps/ieee754/dbl-64/s_lround.c, more precisely in line 61. result = ((long int) i0 (j0 - 20)) | (j (52 - j0)) With the argument reported by Thorsten, this statement is executed with j==0x8000 and (52-j0)==32. Kernighan Ritchie, as well as ISO/IEC 9899:1999 (in 6.5.7 Bitwise shift operators) state that ... If the value of the right operand is negative or is greater than or *equal to* the width of the promoted left operand, the behavior is undefined. It turns out that on x86/32 (as far as I could experiment) (0x8000 32) == 0x8000, quite definitely, indeed. :-) And this behaviour probably is unintended: the coder of the above line probably expected to get (0x8000 32) == 0. Now to the reproducibility: - Undefined behaviour is very likely to depend on compiler optimization options, and that explains the mysterious behaviour previously reported. Probably with '-O1' and above the compiler skips the computation at all, and places 0. - I don't know how uint32_t are aligned and operated on in powerpc/64 archs, but maybe different alignment (and different undefined behaviour) is the reason why Paul could not reproduce the bug. BTW, what arch did you run your tests on, GOTO? I don't know ieee754, so I don't dare submit a patch to libc (e.g., if (52 - j0) 31, use 0), but I believe dropping this bug as unreproducible would be a mistake. Better downgrade it and forward upstream. It reminds me of the fdiv bug in early pentiums. Best regards. giuseppe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303757: gsl-doc-pdf: gnuplot-generated images missing from pdf.
On Sat, Apr 09, 2005 at 01:52:45PM -0500, Dirk Eddelbuettel wrote: I agree that that one looks pretty as far as the fonts are concerned. But for the manual as a whole does 'dvips ; ps2pdf ...' create the thumbnails etc pp that the pdf would contain with pdflatex? Hi Dirk You are right, ps2pdf makes no thumbnails. Would you like to try the attached patch, so we can try to massage randist.tex and its friends and keep going the pdftex way, without sacrificing pictures for thumbnails? regards peppe --- gsl-1.6/debian/rules2005-04-10 12:45:39.326184874 +0200 +++ gsl-1.6/debian/rules.peppe 2005-04-10 12:46:14.321419788 +0200 @@ -67,6 +67,16 @@ #cd doc $(MAKE) ps # make pdf cd doc \ + cp -p randist.texi randist.texi.orig \ + sed 's/^.*\\input \(rand.*\)\.tex.*$$/@end [EMAIL PROTECTED] @[EMAIL PROTECTED]/' \ +randist.texi.orig randist.texi \ + for i in rand-*.tex random-walk.tex ; do \ +echo Converting $$i to eps; \ +j=`basename $$i .tex`; \ +tex \batchmode\nopagenumbers\input $$j\bye; \ +dvips $$j; \ +ps2eps -f $$j.ps; \ + done \ for i in *.eps; do \ echo Converting $$i to pdf... epstopdf $$i ; \ done $(MAKE) pdf
Bug#294030: chrony: ioctl test-program
On Fri, Mar 18, 2005 at 07:16:26AM -0600, John Hasler wrote: Thank you for your report. Could you please send details on your hardware? here it is. bohr description: Computer product: To Be Filled By O.E.M. vendor: To Be Filled By O.E.M. by More String version: To Be Filled By O.E.M. capabilities: smbios-2.3 dmi-2.3 *-core description: Motherboard product: P4P800-VM vendor: ASUSTeK Computer INC. physical id: 0 version: Rev 1.xx slot: DIMM3 *-firmware description: BIOS vendor: American Megatrends Inc. physical id: 0 version: 1014.006 (12/20/2004) size: 64KB capacity: 448KB capabilities: isa pci pnp apm upgrade shadowing escd cdboot bootselect socketedrom edd int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int9keyboard int14serial int17printer int10video acpi usb agp ls120boot zipboot biosbootspecification *-cpu description: CPU product: Intel(R) Pentium(R) 4 CPU 3.00GHz vendor: Intel Corp. physical id: 4 version: 15.3.3 slot: CPU 1 size: 3GHz capacity: 3GHz clock: 200MHz capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni monitor ds_cpl cid *-cache:0 description: L1 cache physical id: 5 slot: L1-Cache size: 16KB capacity: 16KB capabilities: pipeline-burst internal data *-cache:1 description: L2 cache physical id: 6 slot: L2-Cache size: 1MB capacity: 1MB capabilities: pipeline-burst internal *-cache:2 DISABLED description: L3 cache physical id: 7 slot: L3-Cache capabilities: internal *-memory description: System Memory physical id: 36 slot: System board or motherboard size: 512MB *-bank:0 description: DIMM SDRAM Synchronous product: PartNum0 vendor: Manufacturer0 physical id: 0 slot: DIMM0 size: 128MB configuration: width=64 *-bank:1 description: DIMM SDRAM Synchronous product: PartNum1 vendor: Manufacturer1 physical id: 1 slot: DIMM1 size: 128MB configuration: width=64 *-bank:2 description: DIMM SDRAM Synchronous product: PartNum2 vendor: Manufacturer2 physical id: 2 slot: DIMM2 size: 128MB configuration: width=64 *-bank:3 description: DIMM SDRAM Synchronous product: PartNum3 vendor: Manufacturer3 physical id: 3 slot: DIMM3 size: 128MB configuration: width=64 *-pci description: Host bridge product: 82865G/PE/P DRAM Controller/Host-Hub Interface vendor: Intel Corp. physical id: fe80 bus info: [EMAIL PROTECTED]:00.0 version: 02 clock: 33MHz *-display UNCLAIMED description: VGA compatible controller (VGA) product: 82865G Integrated Graphics Device vendor: Intel Corp. physical id: 2 bus info: [EMAIL PROTECTED]:02.0 version: 02 size: 128MB clock: 33MHz capabilities: vga bus_master cap_list configuration: irq=169 *-pci:0 description: PCI bridge (Normal decode) product: 82865G/PE/P PCI to CSA Bridge vendor: Intel Corp. physical id: 3 bus info: [EMAIL PROTECTED]:03.0 version: 02 clock: 66MHz capabilities: pci normal_decode bus_master *-network description: Ethernet controller product: 82547EI Gigabit Ethernet Controller (LOM) vendor: Intel Corp. physical id: 1 bus info: [EMAIL PROTECTED]:01.0 version: 00 clock: 66MHz capabilities: bus_master cap_list configuration: driver=e1000 irq=185 *-usb:0 description: USB Controller (UHCI) product: 82801EB/ER (ICH5/ICH5R) USB UHCI #1 vendor: Intel Corp. physical id: 1d bus info: [EMAIL PROTECTED]:1d.0 version: 02 clock: 33MHz capabilities: uhci bus_master configuration: driver=uhci_hcd irq=169 *-usb:1 description: USB Controller
Bug#295400: /usr/sbin/fancontrol: please add option to avoid calling restorefans() on exit
On Wed, Feb 16, 2005 at 06:37:07PM +0100, Aurélien Jarno wrote: I must use fancontrol to avoid getting mad for the noise. but when I reboot (e.g. to boot windows) fancontrol gets killed and restores fan to full speed. If you need to control your fan speed under Windows, use a software under Windows to do that. I'd better say (e.g. to go to single user mode, boot solaris/x86, boot freebsd...) that is: I need to control my fan speed, fullstop. There is a way, but it won't be supported by Debian and by the upstream for the reason explained above, even as an option. Please also note that your request is very specific, so I suggest you either to use a Windows software to control the fan speed, or to modify fancontrol by yourself. the only ways I found are: 1. send fancontrol SIGKILL manually. 2. hand-edit fancontrol. (which I did: but my changes will be overwritten at next package upgrade.) what about a non documented, deeply buried option to restore fans to a configurable percentage of full speed? regards. -- g.b.
Bug#295400: /usr/sbin/fancontrol: please add option to avoid calling restorefans() on exit
On Wed, Feb 16, 2005 at 07:11:38PM +0100, Aurélien Jarno wrote: fancontrol do that job, when it is running. It don't has to do its job when it is not running! Maybe. Let me restate the problem: I don't expect fancontrol to control my fan when it is not running (mankind is not ready for this kind of software...) I don't want to stop my fan when not running fancontrol. in other words I don't want to burn my cpu. should I decide to burn it, I'm able to do that without using fancontrol at all. I would like to keep the fan at exactly the same speed fancontrol has last adjusted it, which I assume is high enough to keep the cpu cool, but not so noisy as full-speed. if the latter is considered dangerous, I'll happily switch to kill -9... regards g.b.
Bug#289845: xdvizilla: subtle syntax error.
On Tue, Jan 11, 2005 at 03:55:44PM +0100, Frank Küster wrote: Is there a specific reason why you chose the reformatting, instead of just adding a `;' before the closing parenthesis? Or is it just the overlong lines? You caught me! That's exactly because my xterms are 80 columns wide. ;-) But as a matter of coding style, let me point out that it's difficult to forget the closing newline in the ``reformatted'' form. Best regards g.b.
