Re: How to best debug kernel problems
John Reiser wrote: > Does serial console (Documentation/serial-console.txt) work over the > modem port of a T61? Isn't the modem port actually a soundcard channel on modern laptops? David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] replacing report with libreport
On Thu, 30 Jun 2011 17:26:41 -0700, AW (Adam) wrote: > On Fri, 2011-07-01 at 01:23 +0200, Michael Schwendt wrote: > > On Thu, 30 Jun 2011 21:06:17 +0200, JM (Jiri) wrote: > > > > > >Whats the way forward from here in F15? > > > > > > > >gene/ > > > > > > > > > > 1. bumping the version of the report-gtk package should do the trick - I > > > already contacted the maintainer and ask him to do - as this seems to > > > work for rawhide: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=715373#c55 > > > > And as pointed out in bz, it still needs a corresponding libreport-gtk > > update that doesn't have the bad Obs/Prov pair anymore. > > > > > 3. last resort would be asking rel-engs to remove the broken libreport > > > from the stable repositories (if it's even possible) > > > > Won't happen, because it is installed on users' machines already, and I > > doubt > > we would like an unknown number of users to fix this mess themselves. > > Well, updates-testing is 'you get to keep both halves' territory. Adam, Adam, Adam ;) it's this one in "updates": https://admin.fedoraproject.org/updates/libreport-2.0.4-1.fc15 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to best debug kernel problems
On Thu, Jun 30, 2011 at 10:17 PM, Stephen John Smoogen wrote: > Does turning on kdump and installing debuginfo kernel stuff change > things in a way that a watchdog oops won't happen? I doubt the debuginfo package install has anything to do with it, as that is really only used by things like crash (and maybe perf?). Enabling kdump does cause some changes though, as the kernel will reserve a section of memory to put the kdump kernel in. It's plausible that your machine is tripping on some memory issues and enabling kdump is forcing the kernel to not touch that memory at runtime. It's something of a long shot but it's plausible. If you haven't already, try running memtest86+ for a while and see if it comes back with any errors. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 718190] New: perl-Coro-6.0 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Coro-6.0 is available https://bugzilla.redhat.com/show_bug.cgi?id=718190 Summary: perl-Coro-6.0 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Coro AssignedTo: ppi...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, kwiz...@gmail.com, boche...@fedoraproject.org, ppi...@redhat.com, psab...@redhat.com Classification: Fedora Story Points: --- Latest upstream release: 6.0 Current version in Fedora Rawhide: 5.372 URL: http://search.cpan.org/dist/Coro/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rawhide report: 20110701 changes
Compose started at Fri Jul 1 08:15:33 UTC 2011 Broken deps for x86_64 -- acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) audacious-plugin-xmp-3.3.0-7.fc16.x86_64 requires audacious(plugin-api) = 0:19 bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) camcardsync-0.1.1-4.fc15.x86_64 requires libhal.so.1()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libebook-1.2.so.10()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libcamel-provider-1.2.so.25()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libcamel-1.2.so.25()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libgnome-desktop-3.so.0()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk_images.so.1.1()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk.so.1.1()(64bit) gdb-heap-0.5-5.fc16.x86_64 requires glibc(x86-64) = 0:2.13.90 gedit-valencia-0.3.0-4.fc14.x86_64 requires libvala-0.10.so.0()(64bit) ghc-hinotify-0.3.1-9.fc16.i686 requires libHSarray-0.3.0.2-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSdirectory-1.1.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSghc-prim-0.2.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSold-time-1.0.0.6-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSold-locale-1.0.0.2-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSunix-2.4.2.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSfilepath-1.2.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSbase-4.3.1.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSinteger-gmp-0.2.0.3-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHScontainers-0.4.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSghc-prim-0.2.0.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSold-time-1.0.0.6-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSbase-4.3.1.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSinteger-gmp-0.2.0.3-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSold-locale-1.0.0.2-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSfilepath-1.2.0.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires ghc(base-4.3.1.0) = 0:c33a1741503ded8a0170884e8a2e4fa2 ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHScontainers-0.4.0.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSarray-0.3.0.2-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSunix-2.4.2.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSdirectory-1.1.0.0-ghc7.0.2.so()(64bit) ghc-hinotify-devel-0.3.1-9.fc16.i686 requires ghc = 0:7.0.2 ghc-hinotify-devel-0.3.1-9.fc16.i686 requires ghc = 0:7.0.2 ghc-hinotify-devel-0.3.1-9.fc16.x86_64 requires ghc-devel(base-4.3.1.0) = 0:c33a1741503ded8a0170884e8a2e4fa2 ghc-hinotify-devel-0.3.1-9.fc16.x86_64 requires ghc = 0:7.0.2 ghc-hinotify-devel-0.3.1-9.fc16.x86_64 requires ghc = 0:7.0.2 ghc-hinotify-prof-0.3.1-9.fc16.x86_64 requires ghc-prof(base-4.3.1.0) = 0:c33a1741503ded8a0170884e8a2e4fa2 gmediaserver-0.13.0-7.fc15.x86_64 requires libupnp.so.3()(64bit) gmediaserver-0.13.0-7.fc15.x86_64 requires libthreadutil.so.2()(64bit) gnome-applet-bubblemon-2.0.15-1.fc13.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-cpufire-1.6-3.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-globalmenu-0.7.9-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0 gn
relro and precompiled headers
Hello, when I'm building Code::Block in rawhide I'm getting into troubles with the "relro" feature when combined with pre-compiled headers. with default flags I get: ... g++ -DHAVE_CONFIG_H -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../src/include -I../../src/sdk/wxscintilla/include -I../../src/include/scripting/include -I../../src/include/scripting/sqplus -I../../src/include/mozilla_chardet -Ulinux -Uunix -O2 -ffast-math -DCB_AUTOCONF -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wl,-z,relro -m64 -mtune=generic -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -o ../../src/include/sdk.h.gch -xc++-header ./sdk.h In file included from ./sdk_common.h:40:0, from ./sdk_precomp.h:13, from ./sdk.h:17: ./prep.h:32:1: warning: identifier ‘nullptr’ will become a keyword in C ++0x [-Wc++0x-compat] In file included from ./sdk_common.h:40:0, from ./sdk_precomp.h:13, from ./sdk.h:17: ./prep.h: In member function ‘ID::operator void*() const’: ./prep.h:333:45: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status and with "relro" removed the headers are pre-compiled as are in F<=15 Is it a bug or feature in g++ or somewhere else? Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
nss_db
glibc now includes libnss_db again, so the nss_db package is no longer needed from f16 onward. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Deprecating portreserve
On Fri, Jul 01, 2011 at 12:09:35AM -0500, Matt Domsch wrote: > On Wed, Jun 29, 2011 at 06:34:35PM +0100, Matthew Garrett wrote: > > Is that port number exposed to the OS in any way? > > Not that I can recall, which is why it was a horrible design. IIRC it > was just the remote IPMI port, but there may have been a few others. That's borderline criminal. Is there any way to identify that such systems have this? Anything in smbios? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Deprecating portreserve
On Fri, 2011-07-01 at 00:09 -0500, Matt Domsch wrote: > On Wed, Jun 29, 2011 at 06:34:35PM +0100, Matthew Garrett wrote: > > On Wed, Jun 29, 2011 at 12:27:47PM -0500, Matt Domsch wrote: > > > > > Portreserve is also useful to reserve (not let the OS make use of) > > > ports that are needed by an embedded management controller that > > > intercepts delivery of packets to the port and delivers them to the > > > BMC (e.g. the PowerEdge 1955 BMC). While we've done away with that > > > behavior in newer systems, such are still in production use. > > > > Is that port number exposed to the OS in any way? > > Not that I can recall, which is why it was a horrible design. IIRC it > was just the remote IPMI port, but there may have been a few others. > > I misremembered [1] the system type, it was the PowerEdge 1855, not > the newer 1955. So we did fix that particular bit of pain in newer > generations. In that case, it was the IPMI port 623/tcp that was > snarfing packets. > > [1] > http://lists.us.dell.com/pipermail/linux-poweredge/2005-November/023606.html > I had some of the 1850s that had this "feature". Istr nis binding to 623 and then not working and it utterly mystifying more than one of us for a while as to why that was happening. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bootstrap macro
On Fri, Jul 1, 2011 at 9:29 AM, Petr Pisar wrote: > On Thu, Jun 30, 2011 at 06:08:49PM +0200, Iain Arnell wrote: >> >> Interesting though this is, why are we trying to bootstrap the entire >> rebuild? Perl 5.14 is sufficiently compatible with 5.12 that we can >> continue to provide perl(:MODULE_COMPAT_5.12.*) in perl-5.14.1 rpm >> until the rebuild is (nearly) complete and only need to worry about >> bootstrapping the arch-specific stuff (a much smaller problem set with >> no circular deps that affected my rebuild in mock). Once all the >> arch-specific stuff is rebuilt, all of the noarch packages should just >> work (except those with real failures due to new features - mostly >> regex stringification messing up tests). >> > The noarch compatibility between 5.12 and 5.14 is almost perfect, but this > could not be true in future upgrades. Being able to bootstrap perl fully > automatically is great benefit. E.g we plan converting fractional versions to > version object strings (due to compatibility with RPM), so bootstrap build is > wanted prerequisite. (Not mentioning moving packages between distributions or > testing other crazy ideas like parallel installation of different Perl > versions). I remember 5.12 rebuild and it was horror because of mixing old and > new builds. If new Perl is going to be released each year, we need to have > automated solution that can deal with all (ok. almost all) potential problems > the Perl rebase can bring. Sure, full bootstrap rebuild would be nice to have. But wouldn't it be better to work out the details locally using mock first? We're now approaching the fourth week of this mass rebuild and still have at least 700 packages to go The branch/feature freeze is already less than one month away. -- Iain. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 718225] New: bad dependency: fogot epoch
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: bad dependency: fogot epoch https://bugzilla.redhat.com/show_bug.cgi?id=718225 Summary: bad dependency: fogot epoch Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: perl-Module-Pluggable AssignedTo: extras-orp...@fedoraproject.org ReportedBy: jrei...@bitwagon.com QAContact: extras...@fedoraproject.org CC: extras-orp...@fedoraproject.org, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 718225] bad dependency: forgot %{_isa}
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=718225 --- Comment #2 from John Reiser 2011-07-01 10:00:59 EDT --- Typo: the bugzilla usability problem is bug 519251. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 718225] bad dependency: forgot %{_isa}
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=718225
John Reiser changed:
What|Removed |Added
Summary|bad dependency: fogot epoch |bad dependency: forgot
||%{_isa}
--- Comment #1 from John Reiser 2011-07-01 09:59:17 EDT
---
[Sorry, bugzilla usability error: in Summary results in a Commit!
(bug 519521, bug 627383)]
Description: "yum update" shows a error in which perl-Module-Pluggable
"Requires: perl = 4:5.12.3-160.fc16" which is missing the %{_isa} and thus
fails because "4:perl-5.12.3-160.fc16.x86_64" is installed.
Version-Release number of selected component:
1:perl-Module-Pluggable-3.90-160.fc16.noarch
How reproducible: every time (3 times so far)
Steps to reproduce:
1. yum update
Actual results:
Error: Package: 1:perl-Module-Pluggable-3.90-160.fc16.noarch (rawhide)
Requires: perl = 4:5.12.3-160.fc16
Installed: 4:perl-5.12.4-159.fc15.x86_64 (@updates/15)
perl = 4:5.12.4-159.fc15
Available: 4:perl-5.12.3-160.fc16.x86_64 (rawhide)
perl = 4:5.12.3-160.fc16
Expected results: successful update
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 718225] bad dependency: forgot %{_isa}
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=718225 --- Comment #3 from John Reiser 2011-07-01 10:02:51 EDT --- The same problem exists with: Error: Package: 1:perl-Pod-Escapes-1.04-160.fc16.noarch (rawhide) Requires: perl = 4:5.12.3-160.fc16 Installed: 4:perl-5.12.4-159.fc15.x86_64 (@updates/15) perl = 4:5.12.4-159.fc15 Available: 4:perl-5.12.3-160.fc16.x86_64 (rawhide) perl = 4:5.12.3-160.fc16 Error: Package: 1:perl-Pod-Simple-3.13-160.fc16.noarch (rawhide) Requires: perl = 4:5.12.3-160.fc16 Installed: 4:perl-5.12.4-159.fc15.x86_64 (@updates/15) perl = 4:5.12.4-159.fc15 Available: 4:perl-5.12.3-160.fc16.x86_64 (rawhide) perl = 4:5.12.3-160.fc16 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: nss_db
On Fri, Jul 01, 2011 at 02:15:21PM +0200, Andreas Schwab wrote: > glibc now includes libnss_db again, so the nss_db package is no longer > needed from f16 onward. Okay, I've updated git, pkgdb, and comps, and filed a ticket with release engineering to block the builds from the compose. Thanks, Nalin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 718225] bad dependency: forgot %{_isa}
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=718225 Petr Sabata changed: What|Removed |Added CC||cw...@alumni.drew.edu, ||iarn...@gmail.com, ||ka...@ucw.cz, ||lkund...@v3.sk, ||mmasl...@redhat.com, ||ppi...@redhat.com, ||psab...@redhat.com, ||rc040...@freenet.de, ||tcall...@redhat.com Component|perl-Module-Pluggable |perl AssignedTo|extras-orphan@fedoraproject |mmasl...@redhat.com |.org| --- Comment #4 from Petr Sabata 2011-07-01 10:11:17 EDT --- Those are 'perl' subpackages. Correcting the component to 'perl'. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: How to best debug kernel problems
On Fri, Jul 1, 2011 at 04:37, Josh Boyer wrote: > On Thu, Jun 30, 2011 at 10:17 PM, Stephen John Smoogen > wrote: >> Does turning on kdump and installing debuginfo kernel stuff change >> things in a way that a watchdog oops won't happen? > > I doubt the debuginfo package install has anything to do with it, as > that is really only used by things like crash (and maybe perf?). > Enabling kdump does cause some changes though, as the kernel will > reserve a section of memory to put the kdump kernel in. It's > plausible that your machine is tripping on some memory issues and > enabling kdump is forcing the kernel to not touch that memory at > runtime. It's something of a long shot but it's plausible. I am going to try the memtest. The system this morning was incredibly sluggish with a yum install taking several times longer than in the past. A reboot of the system this morning had it oops a lot on agetty versus working.. but it locked up solid so a power reboot was needed so I couldn't get anything 'saved' from ram. sigh. Will run memtest86 for the day and see if that gets anything. I had tested the system earlier on my rawhide experience with the IBM maintenance tools but they may miss something. > If you haven't already, try running memtest86+ for a while and see if > it comes back with any errors. > > josh > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- Stephen J Smoogen. "The core skill of innovators is error recovery, not failure avoidance." Randy Nelson, President of Pixar University. "Let us be kind, one to another, for most of us are fighting a hard battle." -- Ian MacLaren -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] replacing report with libreport
On Fri, Jul 1, 2011 at 1:57 AM, Michael Schwendt wrote: > Adam, Adam, Adam ;) it's this one in "updates": > https://admin.fedoraproject.org/updates/libreport-2.0.4-1.fc15 Is there an open ticket about the report package that needs to be bumped to get this cleaned up. It seems from the ticket traffic I've ready you've figured out a minimally disruptive packaging fix for the report package. Has the report package maintainer(s) weighed in? Again, not pointing fingers as to who should be doing the work to clean it up, I'm just trying to figure out where the hold up is in cleaning this up as expediently as possible. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to best debug kernel problems
On Fri, Jul 1, 2011 at 10:44, Stephen John Smoogen wrote: > On Fri, Jul 1, 2011 at 04:37, Josh Boyer wrote: >> On Thu, Jun 30, 2011 at 10:17 PM, Stephen John Smoogen >> wrote: >>> Does turning on kdump and installing debuginfo kernel stuff change >>> things in a way that a watchdog oops won't happen? >> >> I doubt the debuginfo package install has anything to do with it, as >> that is really only used by things like crash (and maybe perf?). >> Enabling kdump does cause some changes though, as the kernel will >> reserve a section of memory to put the kdump kernel in. It's >> plausible that your machine is tripping on some memory issues and >> enabling kdump is forcing the kernel to not touch that memory at >> runtime. It's something of a long shot but it's plausible. > > I am going to try the memtest. The system this morning was incredibly > sluggish with a yum install taking several times longer than in the > past. A reboot of the system this morning had it oops a lot on agetty > versus working.. but it locked up solid so a power reboot was needed > so I couldn't get anything 'saved' from ram. sigh. > > Will run memtest86 for the day and see if that gets anything. I had > tested the system earlier on my rawhide experience with the IBM > maintenance tools but they may miss something. > So ran memtest86+ for the morning, and nothing showed up. Rebooted into 3.0 and it watchdog halted on me in a way that FN-CNTRL-SHIFT-SYSRQ-B didn't do anything. Power cycling caused it to reboot into another watchdog issue so I went into single user mode. There I was able to turn off watchdog resets and exit (this was not meant to be a solution as much to see what would be causing stuff). What seems to happen is I get slower and slower accesses of some sort to disks. [Sorry for the wishy-washy wording I need to figure out how to better debug this for you guys.] System came up and I logged in after 5 minutes. Doing a yum update took about 4 seconds to get to the (y/N) part and then afterwords sat there and then did a long set of disk accesses. Doing it again took even longer with long pauses. My guess is something is sitting in the CPU and the watchdog saw nothing happening for 10 seconds and whacked. On the third time the system just sat there and never returned (keyboard doesn't seem to allow for a reset so I don't know what is going on.) At the moment, the system is usable with the 2.6.38 from Fedora-15 (though systemd will not allow a reboot due to constantly trying to restart systemd-kmsg something) Will look into getting a modem null cable though I may just go for a picture of the watchdog issue. -- Stephen J Smoogen. "The core skill of innovators is error recovery, not failure avoidance." Randy Nelson, President of Pixar University. "Let us be kind, one to another, for most of us are fighting a hard battle." -- Ian MacLaren -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
