nptl configuration
by divij
Hi,
I want to know that how can i configure nptl on my linux 2.6.10
kernel.I am confused little bit because when I give
the command:->getconf GNU_LIBPTHREAD_VERSION it is returning the value
nptl-0.61 but when i am giving the command:->
/lib/libc.so.6 where it is giving following output:->linuxthreads-0.10
by Xavier Leroy instead of
Native POSIX Threads Library by Ulrich Drepper et al I am using the gcc
version 3.3.3 and Thread Model:-POSIX But when I
am giving:->/lib/tls/libc.so.6 it is giving:->Native POSIX Threads
Library by Ulrich Drepper et al So tell me whether it
is working or not.
Thanks
Divij Kumar Bhatt
18 years, 9 months
Re: rawhide report: 20050711 changes
by Horst H. von Brand
Rodd Clarkson <rodd(a)clarkson.id.au> wrote:
> On Mon, 2005-07-11 at 07:37 -0400, Build System wrote:
>
> > nautilus-2.11.3-1
> > -----------------
> > * Mon Jul 11 2005 Matthias Clasen <mclasen(a)redhat.com> 2.11.3-1
> > - Update to 2.11.3
>
> Ah, this might be a dumb question, but what happened to the Open
> Terminal option when right clicking on the desktop in Gnome?
I second that! That is the /only/ use I ever gave to that particular menu.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
18 years, 9 months
new in 2005-7-9 glibc: no more LinuxThreads
by Ulrich Drepper
Tomorrows glibc will contain the last act of the LinuxThreads saga: its
total demise. It's gone for good.
By the time FC5 will hit the street people had more than three years
time to adapt their code to NPTL. In the last year we've hardly heard
about any problem related to LT vs NPTL and the F4 switch to default to
linking with NPTL also didn't cause any problems we know of.
So, that's it then. LT is really gone for good. It is not possible to
resurrect it as an optional add-on or so. The trunk glibc used in
rawhide and FC5 is already diverging so that in a couple of days (when
we make our usual adjustments to the build environment) almost no
application will run with LT.
Another change caused by this is that it is not possible anymore to use
custom kernels which don't have NPTL support. I.e., no kernels before
2.6 (or 2.4 with NPTL backport) can be used ever again. I don't think
this should be a problem since nobody running such old kernels should
update the userlevel code but people do stupid things so I thought I
mention it.
Those who really need LT for whatever reason have two options:
1. Don't update. Or at least keep a FC4 partition around.
2. Use Xen with a FC4 guest domain. For x86-64 and ppc this should also
be possible in the not too distant future.
I hope everybody who's updating their FC installation from rawhide daily
is reading this. It makes no sense whining about this here or anywhere
else. LT is discontinued upstream, the same changes apply to all
distributions. The good thing is that the spreading of misinformation
about LD_ASSUME_KERNEL is coming to an end. That envvar is still there
and can cause havoc but it cannot do anything useful anymore (for now).
If somebody has scripts or macros which automatically set this envvar,
you better adjust all that code.
As usual, be careful with glibc updates. Especially this one for the
aforementioned reasons and because implementing these changes required
substantial modification of the build process. It's simpler now but
obviously not as well tested.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
18 years, 9 months
how to notify package maintaner?
by Farkas Levente
hi,
is there any standard way to notify any package (core or extras)
maintaner that there is new upstream version of bug/security fix of a
given package? imho it'd be a general and useful think to add somewhere
eg somewhere on fedora homepage an automatic from which select the
current maintaner and send him/her a mail.
yours.
--
Levente "Si vis pacem para bellum!"
18 years, 9 months
Re: rawhide report: 20050711 changes
by Alexandre Oliva
On Jul 11, 2005, Justin Conover <justin.conover(a)gmail.com> wrote:
> Another busted kernel for me, why aren't they including aic7xxx and
> "scsi stuff" ;)
Could be a bug in mkinitrd, or some changes in /proc, or something
entirely different. First off, try to create the initrd by hand
passing mkinitrd the needed --with commands. If that works, start
investigating why mkinitrd doesn't figure out it needs the drivers you
need.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
18 years, 9 months
Kernel patch to work around deficiencies in usbmon
by Pete Zaitcev
Hi, Dave:
We have usbmon enabled now and it's good, but usb-storage moved away
from under me a little bit. It now maps everything for DMA beforehand,
which makes usbmon to miss the SCSI commands and replies.
I am going to address this problem in usbmon, where it belongs, but
it requires some work which is not done.
What do you think about carrying the attached patch for a few months
(I hope to turn around sooner, but you know how that works!)
-- Pete
diff -urp -X dontdiff linux-2.6.12/drivers/usb/storage/transport.c linux-2.6.12-lem/drivers/usb/storage/transport.c
--- linux-2.6.12/drivers/usb/storage/transport.c 2005-06-21 12:58:48.000000000 -0700
+++ linux-2.6.12-lem/drivers/usb/storage/transport.c 2005-07-06 14:00:30.000000000 -0700
@@ -948,8 +948,9 @@ int usb_stor_Bulk_max_lun(struct us_data
int usb_stor_Bulk_transport(struct scsi_cmnd *srb, struct us_data *us)
{
- struct bulk_cb_wrap *bcb = (struct bulk_cb_wrap *) us->iobuf;
- struct bulk_cs_wrap *bcs = (struct bulk_cs_wrap *) us->iobuf;
+ /* Offset into iobuf a little in order to defeat pre-set DMA */
+ struct bulk_cb_wrap *bcb = (struct bulk_cb_wrap *) (us->iobuf + 4);
+ struct bulk_cs_wrap *bcs = (struct bulk_cs_wrap *) (us->iobuf + 4);
unsigned int transfer_length = srb->request_bufflen;
unsigned int residue;
int result;
@@ -960,7 +961,7 @@ int usb_stor_Bulk_transport(struct scsi_
/* Take care of BULK32 devices; set extra byte to 0 */
if ( unlikely(us->flags & US_FL_BULK32)) {
cbwlen = 32;
- us->iobuf[31] = 0;
+ ((unsigned char *)bcb)[31] = 0;
}
/* set up the command wrapper */
18 years, 9 months
Error when starting SMB
by bvest66@adelphia.net
When I attempt to start samba, I get the following:
Starting SMB services: /etc/init.d/functions: line 83: 3072 Aborted $nice $*
I am totally out of ideas.
Thanks!
--
18 years, 9 months
Re: rawhide report: 20050709 changes
by Peter Jones
On Sun, 2005-07-10 at 13:57 -0500, Justin Conover wrote:
> What is an easy way to check the initrd? I have an aic7xxx controller
> with 3x36GB scsi on this box.
>
> dmesg | grep aic
> <Adaptec aic7899 Ultra160 SCSI adapter>
> aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
> <Adaptec aic7899 Ultra160 SCSI adapter>
> aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs
>
>
> uname -r
> 2.6.12-1.1400_FC5smp
cd /tmp
zcat /boot/initrd-2.6.12-1.1425_FC5smp.img > initrd-2.6.12-1.1425_FC5smp.img
mkdir initrd-2.6.12-1.1425_FC5smp
cd initrd-2.6.12-1.1425_FC5smp
cpio -dvi < ../initrd-2.6.12-1.1425_FC5smp.img
look in the "lib" directory it'll create there.
--
Peter
18 years, 9 months
Re: rawhide report: 20050709 changes
by Peter Jones
On Sun, 2005-07-10 at 13:45 -0500, Justin Conover wrote:
> Uncompressing Linux... Ok, booting the kernel.
> Red Hat nash version 4.2.17 starting
> No volume groups found
> Unable to find volume group "VolGroup00"
> ERROR: /bin/lvm exited abnormally with value 5 ! (pid 353)
> mount: error 6 mounting ext3
> ERROR opening /dev/console!!!!: 2
> error dup2'ing fd of 0 to 0
> error dup2'ing fd 0f 0 to 1
> error dup2'ing fd of 0 to 2
> switchroot: mount failed: 22
> Kernel panic - not syncing: Attempted to kill init!
Are the drivers for your storage controllers making it into the initrd?
--
Peter
18 years, 9 months