kerneloops - any need to raise a bugzilla?
by planetf1
I hit a kernel oops this morning where my rawhide x86 X environment just
hung. The system was still running and accesible via ssh.
kerneloops is enabled, and submitted a problem automatically
I can see the issue (or similar to) is here ->
http://www.kerneloops.org/guilty.php?guilty=radeon_commit_ring&version=2....
Do I still need to raise a rawhide bugzilla, or is kerneloops sufficient
(it's certainly convenient!)
Here's the info
Feb 27 11:23:23 snowdon kernel: BUG: unable to handle kernel paging
request at 6b6b6b6b
Feb 27 11:23:23 snowdon kernel: IP: [<f811e88d>]
radeon_commit_ring+0x73/0x9d [radeon]
Feb 27 11:23:23 snowdon kernel: *pdpt = 00000000301fc001 *pde =
0000000000000000
Feb 27 11:23:23 snowdon kernel: Oops: 0000 [#1] SMP
Feb 27 11:23:23 snowdon kernel: last sysfs file:
/sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:01/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/energy_full
Feb 27 11:23:23 snowdon kernel: Modules linked in: vmnet parport_pc
vmblock vmci vmmon vfat fat usb_storage iptable_nat nf_nat iwl3945 nfs
lockd nfs_acl auth_r
pcgss sunrpc ppdev parport aes_i586 aes_generic fuse tun bridge stp llc
bnep sco l2cap bluetooth autofs4 ipv6 nf_conntrack_irc nf_conntrack_ftp
cpufreq_ondeman
d acpi_cpufreq dm_multipath kvm uinput snd_hda_codec_analog
snd_hda_intel snd_hda_codec snd_hwdep snd_seq_dummy snd_seq_oss
snd_seq_midi_event arc4 snd_seq thi
nkpad_acpi ecb snd_seq_device hwmon snd_pcm_oss snd_mixer_oss iTCO_wdt
snd_pcm iTCO_vendor_support rfkill i2c_i801 pcspkr joydev snd_timer
yenta_socket video m
ac80211 nsc_ircc rsrc_nonstatic output e1000e snd irda soundcore
lib80211 cfg80211 snd_page_alloc crc_ccitt ext4 jbd2 crc16 radeon drm
i2c_algo_bit i2c_core [l
ast unloaded: vmnet]
Feb 27 11:23:23 snowdon kernel:
Feb 27 11:23:23 snowdon kernel: Pid: 5188, comm: Xorg Not tainted
(2.6.29-0.157.rc6.git2.fc11.i686.PAE #1) 200893G
Feb 27 11:23:23 snowdon kernel: EIP: 0060:[<f811e88d>] EFLAGS: 00013246
CPU: 1
Feb 27 11:23:23 snowdon kernel: EIP is at radeon_commit_ring+0x73/0x9d
[radeon]
Feb 27 11:23:23 snowdon kernel: EAX: f5e6a060 EBX: f9f22000 ECX:
00000028 EDX: 6b6b6b6b
Feb 27 11:23:23 snowdon kernel: ESI: 0000383f EDI: f4b65780 EBP:
e48e4d8c ESP: e48e4d84
Feb 27 11:23:23 snowdon kernel: DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Feb 27 11:23:23 snowdon kernel: Process Xorg (pid: 5188, ti=e48e4000
task=e4951500 task.ti=e48e4000)
Feb 27 11:23:23 snowdon kernel: Stack:
Feb 27 11:23:23 snowdon kernel: f5e6a060 00003833 e48e4d9c f812030f
f5e6a060 f5e69030 e48e4db0 f812252b
Feb 27 11:23:23 snowdon kernel: f5e69030 f5e69040 f4b65780 e48e4db8
f8128a6f e48e4dd4 f80ad8a1 e48e4dcc
Feb 27 11:23:23 snowdon kernel: c0550d05 f5e69030 f5e69040 f4b65780
e48e4df8 f80ae047 f57c2658 f5e69190
Feb 27 11:23:23 snowdon kernel: Call Trace:
Feb 27 11:23:23 snowdon kernel: [<f812030f>] ?
radeon_do_cp_idle+0xf8/0x106 [radeon]
Feb 27 11:23:23 snowdon kernel: [<f812252b>] ?
radeon_do_release+0x5e/0x127 [radeon]
Feb 27 11:23:23 snowdon kernel: [<f8128a6f>] ?
radeon_driver_lastclose+0xd/0xf [radeon]
Feb 27 11:23:23 snowdon kernel: [<f80ad8a1>] ? drm_lastclose+0x3b/0x24e
[drm]
Feb 27 11:23:23 snowdon kernel: [<c0550d05>] ? _raw_spin_unlock+0x74/0x78
Feb 27 11:23:23 snowdon kernel: [<f80ae047>] ? drm_release+0x3e7/0x415 [drm]
Feb 27 11:23:23 snowdon kernel: [<c04b4e69>] ? __fput+0xd4/0x161
Feb 27 11:23:23 snowdon kernel: [<c04b4f10>] ? fput+0x1a/0x1c
Feb 27 11:23:23 snowdon kernel: [<c04b22e3>] ? filp_close+0x56/0x60
Feb 27 11:23:23 snowdon kernel: [<c04393f7>] ? put_files_struct+0x5d/0xa1
Feb 27 11:23:23 snowdon kernel: [<c043946e>] ? exit_files+0x33/0x37
Feb 27 11:23:23 snowdon kernel: [<c043ac75>] ? do_exit+0x1c8/0x74f
Feb 27 11:23:23 snowdon kernel: [<c0443de6>] ? dequeue_signal+0xc7/0x13e
Feb 27 11:23:23 snowdon kernel: [<c043b260>] ? do_group_exit+0x64/0x8b
Feb 27 11:23:23 snowdon kernel: [<c04440c4>] ?
get_signal_to_deliver+0x267/0x27e
Feb 27 11:23:23 snowdon kernel: [<c0408a12>] ? do_notify_resume+0x6e/0x60f
Feb 27 11:23:23 snowdon kernel: [<c0457c30>] ?
trace_hardirqs_on_caller+0x18/0x145
Feb 27 11:23:23 snowdon kernel: [<c0443bbc>] ? sigprocmask+0x27/0xc6
Feb 27 11:23:23 snowdon kernel: [<c0457c30>] ?
trace_hardirqs_on_caller+0x18/0x145
Feb 27 11:23:23 snowdon kernel: [<c0475e2c>] ?
audit_syscall_entry+0x16b/0x191
Feb 27 11:23:23 snowdon kernel: [<c0456f7d>] ?
trace_hardirqs_off_caller+0x18/0xa3
Feb 27 11:23:23 snowdon kernel: [<c0409778>] ? work_notifysig+0x13/0x1b
Feb 27 11:23:23 snowdon kernel: Code: 83 b8 58 03 00 00 00 74 08 8b 90
5c 03 00 00 eb 1a 8b 90 d0 00 00 00 8b 52 10 eb 0f 8b 90 90 03 00 00 8b
52 10 81 c2 10 0
7 00 00 <8b> 12 8b 88 90 03 00 00 8b 50 1c 8b 49 10 81 c1 14 07 00 00 89
Feb 27 11:23:23 snowdon kernel: EIP: [<f811e88d>]
radeon_commit_ring+0x73/0x9d [radeon] SS:ESP 0068:e48e4d84
Feb 27 11:23:23 snowdon kernel: ---[ end trace 9438d7f7ad5750a0 ]---
Feb 27 11:23:23 snowdon kernel: Fixing recursive fault but reboot is needed!
Feb 27 11:23:35 snowdon kerneloops: Submitted 1 kernel oopses to
www.kerneloops.org
Thanks..
15 years, 1 month
MAVEN_OPTS and mvn-jpp
by Jerry James
I'm having a build failure, on rawhide only, of a Java package that is
built with maven. When I run maven from the command line, if I give
it more than one -DXXX option, it always complains that the second one
is not a valid target. I took a tip from a web site that mentions
this problem and tried this (where the first 3 -DXXX options are from
/usr/bin/mvn-jpp, and the 4th is the recommended way of using mvn-jpp
in a spec file):
$ export MAVEN_OPTS="-Dmaven2.offline.mode -Dmaven2.ignore.versions
-Dmaven2.usejppjars -Dmaven.repo.local=$MAVEN_REPO_LOCAL"
$ mvn install
That worked. Is this an expected change? If so, both the
/usr/bin/mvn-jpp script and the wiki description of how to use maven
will have to be changed. If not, does anyone have any idea why
multiple -DXXX options aren't working for me? Again, this is on
Rawhide only. Thanks,
--
Jerry James
http://loganjerry.googlepages.com/
15 years, 1 month
Heads up for rawhide users: if you missed an update, you're stuck
by Jason L Tibbitts III
Just a note to rawhide users who don't update every day: if you missed
the upgrade to rpm-4.6.0-8.fc11, you now cannot read many (and soon
all) packages in rawhide, including the current version of the rpm
package. I believe there was a two day window to do this, so if you
haven't updated since Tuesday you might be stuck.
To get going again, visit koji and manually download the -8 packages
for your arch, update them manually, and then let yum update you the
rest of the way.
http://koji.fedoraproject.org/koji/buildinfo?buildID=83804
Perhaps some enterprising person will drop these in a repo for easy
access before koji garbage collects them.
- J<
15 years, 1 month
Build error, ld segmentation fault
by Pavel Alexeev (aka Pahan-Hubbitus)
Recently I build new version fotoxx.
http://koji.fedoraproject.org/koji/taskinfo?taskID=1172197
i586 build sucsessful, but x86_64 failed with strange error (
http://koji.fedoraproject.org/koji/taskinfo?taskID=1172197 )
+ make -j4 PREFIX=/usr DOCDIR=/usr/share/doc/fotoxx-6.0
fotoxx-6.0.cpp: In function 'void* flatten_thread(void*)':
fotoxx-6.0.cpp:3778: warning: no return statement in function returning
non-void
fotoxx-6.0.cpp: In function 'void* tune_thread(void*)':
fotoxx-6.0.cpp:4148: warning: no return statement in function returning
non-void
fotoxx-6.0.cpp: In function 'void* color_dep_thread(void*)':
fotoxx-6.0.cpp:4490: warning: no return statement in function returning
non-void
fotoxx-6.0.cpp: In function 'void* sharp_thread(void*)':
fotoxx-6.0.cpp:4800: warning: no return statement in function returning
non-void
fotoxx-6.0.cpp: In function 'void* resize_thread(void*)':
fotoxx-6.0.cpp:5996: warning: no return statement in function returning
non-void
fotoxx-6.0.cpp: In function 'void* trim_thread(void*)':
fotoxx-6.0.cpp:6107: warning: no return statement in function returning
non-void
fotoxx-6.0.cpp: In function 'void* rotate_thread(void*)':
fotoxx-6.0.cpp:6374: warning: no return statement in function returning
non-void
fotoxx-6.0.cpp: In function 'void* HDR_dialog_thread(void*)':
fotoxx-6.0.cpp:7018: warning: no return statement in function returning
non-void
*collect2: ld terminated with signal 11 [Segmentation fault]*
/usr/bin/ld: i386 architecture of input file
`libfreeimage.a(BitmapAccess.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file
`libfreeimage.a(FreeImage.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `libfreeimage.a(GetType.o)'
is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file
`libfreeimage.a(PixelAccess.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `libfreeimage.a(Plugin.o)'
is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file
`libfreeimage.a(PluginBMP.o)' is incompatible with i386:x86-64 output
I think error "*collect2: ld terminated with signal 11 [Segmentation
fault]*" is not simple error build? Or it is error of my package?
Should I file bug? For binutils?
With best wishes, Pavel Alexeev (aka Pahan-Hubbitus)
15 years, 1 month
Two Python packages seek loving maintainers
by Andrew Price
I find myself in a position which leaves me little opportunity for
taking care of my Fedora packages at the moment. I have two packages,
- pybackpack: a Gnome GUI backup program, and
- python-twyt: a Twitter API library and commandline client
which I would like to request assistance with, or somebody willing to
take over one, or both of them.
I'm the upstream developer for both packages so you will have my full
cooperation and attention if/when any issues arise which require
upstream attention. Searching bugzilla returns "zarro boogs" for both
packages, so they're either well-written, or rarely-used *ahem* :-)
They're still both in active development so bugs will get fixed upstream
and I'll still take an active interest in how they're progressing in
Fedora but I won't get in the way of the new maintainers.
Any takers?
--
Andy Price
15 years, 1 month
Bodhi Help
by Truch, Matthew
I'm trying to push a (simultaneous) update to (to testing of) three packages:
CCfits-2.1-2.fc10
kst-1.7.0-4.fc10
cfitsio-3.130-2.fc10
However, it fails, claiming that "mtruch does not have commit access to
CCfits". However, according to the PackageDB, I do, albeit they were
conferred to me about 8 hours ago. Am I doing something wrong? Is
there a (longer than a few hours) delay before I can submit updates once
I get commit access?
--
"299792458 m/s. It's not just a good idea, It's the law."
--------------------------
Matthew Truch
Department of Physics and Astronomy
University of Pennsylvania
matt(a)truch.net
http://matt.truch.net/
15 years, 1 month
Help wanted: Orphan master
by Jesse Keating
Just like previous releases, we will be purging orphans from rawhide
before the feature freeze. This prevents cruft from making it into the
next release and needing to be maintained for the life of the next
release.
This cycle, Warren has asked that releng find another party to manage
the Orphanarium purging. This requires somebody to query the various
tools to discover which packages are orphaned, but not blocked in our
development tag (dist-f11) and to post the lists so that people can take
ownership or let them die. After a short window, the list will be
delivered to releng for blocking in Koji.
Would any of you like to help releng with this task?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
15 years, 1 month