On Tue, Aug 26, 2003 at 09:58:44AM -0500, Eric Sandeen wrote: > On Tue, 26 Aug 2003, Axel Thimm wrote: > > > Boy, that's an annoying bug... it's somewhere in the guts of Red Hat's > > > kernel + nptl patches + O_DIRECT + rpm. > > > > This also bit me with the 20.9 kernel patched to XFS 1.3.0. It seems > > 100% reproducible. :( > > > > Why doesn't this show up with the binary kernels for 19.9? Or does it > > but nobody reported it yet? It also didn't show up with XFS 1.2.0. > > I think it does show up in 19.9. For XFS 1.2.0, that was on a different > underlying kernel - or have you merged 1.2.0 up to 2.4.20-19.9? Yes, the atrpms kernels track latest RH errata and had (up to now) XFS 1.2.0. > > > I think that Red Hat will eventually have a new version of RPM that > > > works with this kernel. In the meantime, I'd either: > > > > > > a) rebuild with patch 1300 in place, if you don't care about using O_DIRECT > > > or > > > b) set up an alias for "rpm" to prefix it with LD_ASSUME_KERNEL=2.2.5 > > > > What are the drawbacks of these methods? Simply performance? a) seems > > bad, because it will degrade overall system performance, > > Not many things use O_DIRECT, actually. And, well, it won't be any worse > than what Red Hat ships originally - wihch turns off O_DIRECT completely > with 1300. We'd just be putting that back in place. Hm, worth considering it for the 2.4.20 series (the actual errata kernels). Latest rawhide/severn kernels have removed that patch. I'll respin a test kernel with O_DIRECT disabled. > > b) is difficult, because the used rpm application is not under > > control of the kernel packager. :( > > not sure what you mean? That not everything will pick up the alias? Yes, for instance. Delivering a kernel rpm does not guarantee that people will read any accompanying documentation. So the next best stab to the problem would be to build rpm without O_DIRECT support. Then the kernel rpm would have to depend on a capability provided by the fixed rpm rpm (yes, it's double ;). But this opens a pit without an end ... :( -- Axel.Thimm@physik.fu-berlin.de
Attachment:
pgp00011.pgp
Description: PGP signature