Need to use i586 kernel and i386 glibc for via c7 epia system
Hi all, A bit offtopic for this list, but this is the best place I could think of to discuss this. A friend of mine had trouble with 2 different via c7 epia motherboards (mini itx boards with single chip chipset with unichrome integrated graphics) machines. They would freeze (hard) pretty much at random while working in programs like openoffice or firefox. He end up writing a script which would repeatedly start firefox and thunderbird, wait for the cpu load to become zero, kill them again, etc. This killed the system reproducable, usually within the hour, always within 5 hours. He gave one to me with the request to see if I could fix it. After many days of experimenting (latest bios update, try various settings, verify cooling, etc), I've found out that (on a fully up2date Fedora 7 system) replacing the i686 kernel with the i586 one and the glibc with the i386 (and openssl, but that wasn't used afaik) will make the system stable. So appearantly the via c7 isn't all that i686 compatible as via claims, I suspect that there may be a problem with certain i686 specific synchronisation instructions, but that is just a hunge. This leads to the conclusion, that anacondo should perhaps be modified to mark these systems as i586 and thus choose a i586 kernel and a i386 glibc when installing on them. But before filing a but I first wanted to discuss this here. Regards, Hans ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Need to use i586 kernel and i386 glibc for via c7 epia system
Nicolas Mailhot wrote: Le Lun 27 août 2007 12:07, Hans de Goede a écrit : Hi all, A bit offtopic for this list, but this is the best place I could think of to discuss this. ... So appearantly the via c7 isn't all that i686 compatible as via claims As Alan will likely repeat, the glibc definition of i686 is not conformant with the Intel definition of i686. It includes instructions Intel declared optional, and Via does not implement. So a glibc i686 binary won't run on all the i686 processors on the market. I know, but this is a via C7 (not a C3) which _does_ implement the instructions to match the rpm definition of i686 (which means it does implement cmov), but appearantly it doesn't implement them too well. Regards, Hans ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: The NFS nosharecache patch in F7 is broken
On Tue, 2007-08-21 at 12:14 -0400, Steve Dickson wrote: Dave Jones wrote: On Tue, Aug 21, 2007 at 10:29:53AM -0400, Chuck Ebbert wrote: If people try mounting several exports from the same filesystem, it fails with confusing error messages if the mount options are different for some of the mount points. Adding nosharecache to the mount options fixes that, but people with working setups suddenly find they need this new option to use a setup that used to work without it. Should we just revert that patch? Thats been the million dollar question lately... there has been quite a bit of complaints about this patch... but note the check does do some correct sanity checking so the changes it point would be a good thing to do But with that said, I would if making it a warning first, giving people time to clean up their setups and then making it an error later on... steved. It is important that people know about the consequences of using nosharecache: namely that they may see cache corruption when accessing the same file via different mountpoints. That is why I firmly believe it should _NOT_ be a default. Trond ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [RFC PATCH] lirc IR receiver drivers
Jarod Wilson wrote: Eric Sandeen wrote: Jarod Wilson wrote: Hey all, So... As I've mentioned on various forums here and there in the recent past, I'd really like to see fedora carry the lirc drivers (http://www.lirc.org/) in-kernel, and help push them into the upstream kernel. I finally got around to doing something significant about it this evening. The link below is the completion of my first attempt at a patch tailored for upstream, based partially on work done by Mario Limonciello for Ubuntu (cc'd). http://people.redhat.com/jwilson/lirc/linux-2.6-lirc.patch Cool, I tossed a few build-related fixes (warnings, deprecated interfaces/flags, etc..) on top of this up at http://people.redhat.com/esandeen/lirc/ Very nice. Gah, at least one of those fixes some things I screwed up merging in the latest bits from cvs... (There's also usb stuff going on I don't understand in the commandir driver :) but with the warning about the callback it will probably explode when run.) Hrm, that's not so good... I was thinking of seeing if I could find one somewhere for cheap, but ouch, those things look pricey... http://www.commandir.com/order/ Also given that each subdir under drivers/input/lirc generally has just one .c file, I'd probably flatten it out, and drop everything into drivers/input/lirc/*.c Yeah, that idea crossed my mind too after I'd sent the mail off before drifting off to sleep. I'll do that for the next rendition. Also in Kconfig, INPUT_LIRC and LIRC_DEV seem a little redundant - perhaps each individual driver should just do select LIRC_DEV rather than depends on? and remove the prompt for LIRC_DEV? Sounds like a good idea to me. All of the work Eric and I did over the weekend is now in a proper git tree, which can be browsed (and cloned) here: http://git.wilsonet.com/linux-2.6-lirc.git/ A few more clean-ups and we'll slap this puppy into an actual rawhide kernel build to start getting some wider testing... -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
