I'm trying it in i686 and x86_64 systems and so far seems to work fine on F12. On the x86_64 system, on a Dell i1545 laptop, I do notice a couple of messages in the dmesg output that I don't understand.
One pair is Calgary: detecting Calgary via BIOS EBDA Calgary: unable to locate Rio Grande table in EBDA - bailing!
The other is a bunch of messages of the form name_count maxed, losing inode data: dev=00:07, inode 9303 repeated several times, and also bunch more with different dev and inode numbers.
Is either of these bad? I don't get them on the i686 system.
jhhaynes at earthlink dot net
On 02/02/2010 06:20 PM, Michael Cronenworth wrote:
Jim Haynes wrote:
I'm trying it in i686 and x86_64 systems and so far seems to work fine on F12.
It's not fine. Abrt is broken and won't be fixed any time soon. Hopefully the kernel gods will *not* push 2.6.32 until abrt is fixed.
I believe that the temporary loss of abrt should not prevent the enormous benefits of the newer kernel - iwlagn is working properly for the first time in a long time ... these are wonderful improvements.
Fixing real bugs far outweighs the short term (or whatever) loss of a SEGV app monitor tool.
the kernels hangs sometimes for me... lenovo x301 with updates-testing enabled. didnt have time to analyze it properly yet. going back to an older kernel version works fine.
kind regards, Rudolf Kastl
On Tue, Feb 02, 2010 at 05:05:53PM -0700, Petrus de Calguarium wrote:
Jim Haynes wrote:
One pair is Calgary: detecting Calgary via BIOS EBDA Calgary: unable to locate Rio Grande table in EBDA - bailing!
I have the same error, but it occurred long before the recent kernel-2.6.32. It was in 2.6.31 as well.
This isn't an error, it's just an alarmist way of saying "looking for hardware you don't have"
Dave
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/03/2010 11:33 AM, Dave Jones wrote:
On Tue, Feb 02, 2010 at 05:05:53PM -0700, Petrus de Calguarium wrote:
Jim Haynes wrote:
One pair is Calgary: detecting Calgary via BIOS EBDA Calgary: unable to locate Rio Grande table in EBDA - bailing!
I have the same error, but it occurred long before the recent kernel-2.6.32. It was in 2.6.31 as well.
This isn't an error, it's just an alarmist way of saying "looking for hardware you don't have"
Dave
The 2.6.32-40 kernel is pretty decent. On my T400 -39 didn't work at all. but -40 seems to do the trick nicely. It works happily with both intel and ati video cards.
Kevi
- -- Get my public GnuPG key from http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D0BD5D1
On Wed, Feb 03, 2010 at 11:36:46AM -0700, Kevin DeKorte wrote:
The 2.6.32-40 kernel is pretty decent. On my T400 -39 didn't work at all. but -40 seems to do the trick nicely. It works happily with both intel and ati video cards.
Thanks, it's likely still going to be a bit of a rough road as KMS settles down from being out of tree to stabilizing in tree. Anyway, thanks for testing.
regards, Kyle
On Wed, Feb 03, 2010 at 13:39:37 -0500, Kyle McMartin kyle@mcmartin.ca wrote:
On Wed, Feb 03, 2010 at 11:36:46AM -0700, Kevin DeKorte wrote:
The 2.6.32-40 kernel is pretty decent. On my T400 -39 didn't work at all. but -40 seems to do the trick nicely. It works happily with both intel and ati video cards.
Thanks, it's likely still going to be a bit of a rough road as KMS settles down from being out of tree to stabilizing in tree. Anyway, thanks for testing.
The 2.6.32 f12 kernels seem to be working OK for me in general. I don't think anything has bitten me recently. I have an rv530 on -39 (which will go to -40 today) and an nv20 something on and another machine used headless on the -40 kernel.
On the 2.6.33 kernel I opened a bug about some traceback like info related to encrypted block devices (but things work). I continue to see only one cpu used from time to time, but that is an old issue going way back.
On Wed, Feb 3, 2010 at 6:39 PM, Kyle McMartin kyle@mcmartin.ca wrote:
On Wed, Feb 03, 2010 at 11:36:46AM -0700, Kevin DeKorte wrote:
The 2.6.32-40 kernel is pretty decent. On my T400 -39 didn't work at all. but -40 seems to do the trick nicely. It works happily with both intel and ati video cards.
Thanks, it's likely still going to be a bit of a rough road as KMS settles down from being out of tree to stabilizing in tree. Anyway, thanks for testing.
KMS with my nouvea based Dell Latitude D630 just gives me a black screen with kernel-2.6.32.7-37.fc12.x86_64. Is there a bug tracking regressions with this kernel or is it a known issue?
Peter
On Thu, 2010-02-04 at 23:47 +0000, Peter Robinson wrote:
On Wed, Feb 3, 2010 at 6:39 PM, Kyle McMartin kyle@mcmartin.ca wrote: On Wed, Feb 03, 2010 at 11:36:46AM -0700, Kevin DeKorte wrote: > The 2.6.32-40 kernel is pretty decent. On my T400 -39 didn't work at > all. but -40 seems to do the trick nicely. It works happily with both > intel and ati video cards. >
Thanks, it's likely still going to be a bit of a rough road as KMS settles down from being out of tree to stabilizing in tree. Anyway, thanks for testing.KMS with my nouvea based Dell Latitude D630 just gives me a black screen with kernel-2.6.32.7-37.fc12.x86_64. Is there a bug tracking regressions with this kernel or is it a known issue?
File a bug if there isn't one already, and link to it in Bodhi:
https://admin.fedoraproject.org/updates/F12/FEDORA-2010-1237
I just submitted 2 kerneloops reports from abrt on the 2.6.32.7-37 kernel.
When I run blueproximity on my x86_64 f12 laptop I get about 10 such crashes simultaneously every 2 minutes.
Apart from blueproximity the immediate experience seems good.
birger
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/12/2010 09:43 AM, birger wrote:
I just submitted 2 kerneloops reports from abrt on the 2.6.32.7-37 kernel.
When I run blueproximity on my x86_64 f12 laptop I get about 10 such crashes simultaneously every 2 minutes.
Apart from blueproximity the immediate experience seems good.
birger
Have you tried kernel-2.6.32.8-48.rc2.fc12.x86_64? It seems to work pretty well for me.
Kevin
- -- Get my public GnuPG key from http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D0BD5D1
On Tue, 2010-02-02 at 17:16 -0600, Jim Haynes wrote:
I'm trying it in i686 and x86_64 systems and so far seems to work fine on F12. On the x86_64 system, on a Dell i1545 laptop, I do notice a couple of messages in the dmesg output that I don't understand.
One pair is Calgary: detecting Calgary via BIOS EBDA Calgary: unable to locate Rio Grande table in EBDA - bailing!
The other is a bunch of messages of the form name_count maxed, losing inode data: dev=00:07, inode 9303 repeated several times, and also bunch more with different dev and inode numbers.
Is either of these bad? I don't get them on the i686 system.
jhhaynes at earthlink dot net
On Athlon 64 , x32 install, I can't build virtual machine windows xp with qemu and 2.6.31.12 but all is ok with 2.6.32.7
Cristian Sava
-
Adam Williamson -
Birger Monsen -
Bruno Wolff III -
Cristian Sava -
Dave Jones -
Genes MailLists -
Jim Haynes -
Kevin DeKorte -
Kyle McMartin -
Michael Cronenworth -
Peter Robinson -
Petrus de Calguarium -
Rudolf Kastl