Re: HEADSUP! change to atapi-cd driver and burncd

It seems Kenneth Wayne Culver wrote: > > This is because some sloppy firmware coders hasn't implemented the > > "test unit ready" command proberly, it return ready no matter what > > state the drive is in :( I've gotten ahold of one burner that has this > > problem and I'm trying to come up with a

Re: HEADSUP! change to atapi-cd driver and burncd

> This is because some sloppy firmware coders hasn't implemented the > "test unit ready" command proberly, it return ready no matter what > state the drive is in :( I've gotten ahold of one burner that has this > problem and I'm trying to come up with a fix for it... Is this the same problem I wa

Re: HEADSUP! change to atapi-cd driver and burncd

It seems Kent Hauser wrote: > Hi all, > > I've been getting errors with "burncd" that I've not seen before. > Specifically, I'm seeing the following: > > chapel-hill# burncd -f /dev/acd1c -s 4 blank data *1.iso fixate > blanking CD - 100 % done > burncd: ioctl(CDRIOCNEXTWRITEABLEADDR): Devi

Re: HEADSUP! change to atapi-cd driver and burncd

Hi all, I've been getting errors with "burncd" that I've not seen before. Specifically, I'm seeing the following: chapel-hill# burncd -f /dev/acd1c -s 4 blank data *1.iso fixate blanking CD - 100 % done burncd: ioctl(CDRIOCNEXTWRITEABLEADDR): Device busy chapel-hill# Trace messages from /

Re: OpenSSL ASM patch

On Fri, Feb 16, 2001 at 03:57:57PM +1100, Peter Jeremy wrote: > I'm sure something similar would be possible with FreeBSD, but I don't > have the expertise to actually implement it. I'm less certain how > much of a win this would be in the general scheme of things: Apart > from special cases (li

Re: Fix for mountpath lenght

On Thu, 15 Feb 2001, Robert Watson wrote: > As has been pointed out, this is simply incorrect due to an attempt to use > kernel string operators on a string in the kernel address space. Generally > speaking, it's a bad idea to explicitly perform string activities on > userland strings, instead, t

Re: OpenSSL ASM patch

On 2001-Feb-11 13:02:43 -0800, Alfred Perlstein <[EMAIL PROTECTED]> wrote: >* Kris Kennaway <[EMAIL PROTECTED]> [010211 12:52] wrote: >> On Sun, Feb 11, 2001 at 12:47:07PM -0800, Alfred Perlstein wrote: >> > Is it possible to have multiple ASM cores and use the appropriate >> > routines? Or must

That site for buying and selling businesses V

Hey That site on the net for buying and selling businesses is http://bsab.com.au This is the one that Craig Simmons told us he sold his shop from. I've checked it out - it looks great - but I do see a problem for you in that nobody is going to pay you $950k for your business unless you move to

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

> I suggest you take a look at > > >http://www.usenix.org/publications/library/proceedings/als2000/full_papers/browndavid/browndavid_html/ Thank you ! This confused the hell out of me when I first bumped into it on Solaris ! Something to read in the morning -- Brian <[EMAIL PROTECTED]

Re: cvs commit: ports/palm/pilot-link Makefile

On Thu, Feb 15, 2001 at 06:28:10PM +0900, Akinori MUSHA wrote: > knu@archon[2]% uname -a > FreeBSD archon.local.idaemons.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Feb 14 >16:49:24 JST 2001 >[EMAIL PROTECTED]:/villa/work/obj/freebsd/src/usr/local/src/sys/ARCHON >i386 > knu@archon[2]% gcc

REVERSE the AGING PROCESS 10 - 20 Years!

HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)??? Released by your own pituitary gland, HGH starts declining in your 20s, even more in your 30s and 40s, eventually resulting in the shrinkage of major organs-plus all other symptoms related to old age. THIS CAN NOW BE REVERSED!!! IN THOUSANDS OF CL

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Thu, Feb 15, 2001 at 12:44:26PM +, Paul Richards_imap/mail.originative.co.uk/Inbox.sbd/New Mail.sbd/OpenLDAP.sbd/Devel wrote: > I suggest you take a look at > > >http://www.usenix.org/publications/library/proceedings/als2000/full_papers/browndavid/browndavid_html/ Yes, I know how So

Re: Fix for mountpath lenght

As has been pointed out, this is simply incorrect due to an attempt to use kernel string operators on a string in the kernel address space. Generally speaking, it's a bad idea to explicitly perform string activities on userland strings, instead, to rely on the bounds checking in copyinstr() and r

Re: NEWCARD & xl0: watchdog timeout

In message <[EMAIL PROTECTED]> Pierre DAVID writes: : If nobody is using NEWCARD because of such warning, I wonder : when NEWCARD will be functionnal for joe user. Be aware that : I already tried the same NEWCARD kernel from a Sony Vaio and : another Dell. Maybe. But also there are known issues

Re: -lc_r against shared library (Re: Failed to build kdesupport2 port)

Daniel Eischen wrote: > [ CC list trimmed ] > > On Thu, 15 Feb 2001, Maxim Sobolev wrote: > > You have totally misunderstood the purpose of my patch. The patch *isn't* intended >as a quick fix for the recent -lc_r/-pthread weirdness, but instead it would provide > > porting team with infrastruct

Re: NEWCARD & xl0: watchdog timeout

On Wed, Feb 14, 2001 at 05:52:27PM -0500, Will Andrews wrote: > On Wed, Feb 14, 2001 at 10:19:24PM +0100, Pierre DAVID wrote: > > I just upgraded my Dell Latitude LT from 4.2-RELEASE TO > > -current (just before 9h Feb): all is working perfectly > > with a GENERIC kernel, pccardd and a 3Com 3C589

Re: -lc_r against shared library (Re: Failed to build kdesupport2 port)

[ CC list trimmed ] On Thu, 15 Feb 2001, Maxim Sobolev wrote: > You have totally misunderstood the purpose of my patch. The patch *isn't* intended >as a quick fix for the recent -lc_r/-pthread weirdness, but instead it would provide > porting team with infrastructure necessary to start convertin

Re: Fix for mountpath lenght

* Alfred Perlstein <[EMAIL PROTECTED]> [010215 10:15] wrote: > This looks right, except that Bruce says that SCARG isn't to be > used, instead just use uap->path. Also, you can't call strlen on a userland pointer. please test patches before submitting them! > > -Alfred > > * Martin Blapp <[EM

Re: -lc_r against shared library (Re: Failed to build kdesupport2 port)

John Indra wrote: > On Thu, Feb 15, 2001 at 02:51:51PM +0200, Maxim Sobolev wrote: > > >> CONFIGURE_ARGS= "LIBS=-pthread" > >> to kdesupport2/Makefile would help. > >> > >> There are some way to ``fix'' this problem: > >> c) Use -lc_r instead of -pthread. > >>As -pthread will be depreciated,

Re: Fix for mountpath lenght

This looks right, except that Bruce says that SCARG isn't to be used, instead just use uap->path. -Alfred * Martin Blapp <[EMAIL PROTECTED]> [010215 09:46] wrote: > > In mount.h, we have a #define MNAMELEN80 > > and in struct statfs {} we have: > > charf_mntonname[MNAMELEN]; /* d

Fix for mountpath lenght

In mount.h, we have a #define MNAMELEN80 and in struct statfs {} we have: charf_mntonname[MNAMELEN]; /* directory on which mounted */ but the kernel does no check to see if the mountpath is longer than MNAMELEN, it just accepts it ? It's impossible to umount(8) it, because umount(

Re: Backward binary compatibility with libc/libm

In message <[EMAIL PROTECTED]> "Akinori MUSHA" writes: : Oops, obviously I missed the 'Major bumping of libFOO' thread. Take : msun into account as well, thanks. I had forgotten about msun :-(. However, I think we're going to try to do this without an interface change in libc that breaks things

Re: Backward binary compatibility with libc/libm

In message <[EMAIL PROTECTED]> "Akinori MUSHA" writes: : Seems some 4.x/3.x binary that is linked with libm.so does not work on : 5-CURRENT because libm.so is not properly associated with (the latest) : libc.so. : : So, when a program lets libm refers to __stdout/__stderr from within, : it fails

Re: libgtop on CURRENT

On Thu, Feb 15, 2001 at 09:48:13PM +0900, Akinori MUSHA wrote: > It is necessary to update libgtop for CURRENT as attached. I haven't > yet got an idea how to fix it to shut up the following error messages, > though. My -current box was a victim of -current a while back. It's currently on R&R b

Re: -lc_r against shared library (Re: Failed to build kdesupport2 port)

On Thu, Feb 15, 2001 at 02:51:51PM +0200, Maxim Sobolev wrote: >> CONFIGURE_ARGS= "LIBS=-pthread" >> to kdesupport2/Makefile would help. >> >> There are some way to ``fix'' this problem: >> c) Use -lc_r instead of -pthread. >>As -pthread will be depreciated, we should use -lc_r for FreeBSD >>

Re: cvs commit: ports/palm/pilot-link Makefile

"Akinori MUSHA" <[EMAIL PROTECTED]> writes: > However, if I put either: > > CXXFLAGS+=-fPIC > > or: > > CFLAGS!= ${ECHO} "${CFLAGS}" | ${SED} -e 's/-O[0-9a-z]*//g' IMHO, this could be rewritten as ${CFLAGS:N-O*} which is more clean than forking a subshell. Cyrille. -- home: mailto:[

Re: -lc_r against shared library (Re: Failed to build kdesupport2 port)

FUJISHIMA Satsuki wrote: > If you paid attention to -ports, you found adding > > CONFIGURE_ARGS= "LIBS=-pthread" > > to kdesupport2/Makefile would help. > > There are some way to ``fix'' this problem: > c) Use -lc_r instead of -pthread. >As -pthread will be depreciated, we should use -lc_r fo

libgtop on CURRENT

It is necessary to update libgtop for CURRENT as attached. I haven't yet got an idea how to fix it to shut up the following error messages, though. LibGTop-Server: kvm_getargv (12): Undefined error: 0 LibGTop-Server: kvm_getargv (11): Undefined error: 0 LibGTop-Server: kv

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

David O'Brien wrote: > > On Thu, Feb 15, 2001 at 11:14:38AM +, Paul Richards wrote: > > Commercial vendors will skip version numbers in their public releases > > if their internal development required more than one bump. > > Which ones? Sun Solaris still ships their libc as "libc.so.1", eve

Re: Backward binary compatibility with libc/libm

At Thu, 15 Feb 2001 20:47:57 +0900, I wrote: > > Seems some 4.x/3.x binary that is linked with libm.so does not work on > 5-CURRENT because libm.so is not properly associated with (the latest) > libc.so. > > So, when a program lets libm refers to __stdout/__stderr from within, > it fails as foll

Re: cvs commit: ports/palm/pilot-link Makefile

I believe this is bug in g++ optimizasion, at least 2.95.3 prerelease. Using -O2 or higher (which impiles -frerun-cse-after-loop) works. Many ports using g++ are hit by this... -- FUJISHIMA Satsuki At Thu, 15 Feb 2001 18:28:10 +0900, Akinori MUSHA wrote: > c++ -I./include -I./include -O -march=

-lc_r against shared library (Re: Failed to build kdesupport2 port)

If you paid attention to -ports, you found adding CONFIGURE_ARGS= "LIBS=-pthread" to kdesupport2/Makefile would help. There are some way to ``fix'' this problem: a) linking -lc_r against libGL. This is denied by John Polstra and he suggested (b). He said libc and libc_r must be strictly s

Backward binary compatibility with libc/libm

Seems some 4.x/3.x binary that is linked with libm.so does not work on 5-CURRENT because libm.so is not properly associated with (the latest) libc.so. So, when a program lets libm refers to __stdout/__stderr from within, it fails as follows. :( /usr/libexec/ld-elf.so.1: /usr/lib/libm.so.

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Thu, Feb 15, 2001 at 11:14:38AM +, Paul Richards wrote: > Commercial vendors will skip version numbers in their public releases > if their internal development required more than one bump. Which ones? Sun Solaris still ships their libc as "libc.so.1", even in Solaris 8. -- -- David ([E

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

David O'Brien wrote: > > We only bumped due to interface changes in the .MAJOR.MINOR days. The > difference is *adding* an interface today does in cause a bump. In the > .MAJOR.MINOR days it would require a bump the MINOR number. In both > days, an incompatible change in an existing interfac

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Wed, Feb 14, 2001 at 12:47:59AM +, Paul Richards wrote: > Instead what we have now is libxyz.so.3 and libxyz.so.3 which are > different from each other. No different than two libxyz.so.3.1 and libxyz.so.3.1 could be (a.out days). (well not entirely true, but in the a.out days, one could ma

Failed to build kdesupport2 port

Hi folks... I am on a FreeBSD 5.0-20010210-CURRENT box. This is a clean system, I installed it from current.freebsd.org I tried to build kdesupport2 port, but it failed. Somehow, when checking for Qt, kdesupport2 configure script died. However, I installed qt 2.2.4 from port cleanly, no errors w

Re: cvs commit: ports/palm/pilot-link Makefile

At Wed, 14 Feb 2001 14:50:25 -0800 (PST), Jun Kuriyama wrote: > kuriyama2001/02/14 14:50:25 PST > > Modified files: > palm/pilot-link Makefile > Log: > - Add write permission at post-patch stage to be able to build > by non-root users. > - Remove -O flag from CFLAGS due

Re: -CURRENT is bad for me...

On Mon, Feb 12, 2001 at 07:59:03AM -0500, Daniel Eischen wrote: >Did you miss the HEADS UP posted to -current? You better read these. Somehow, I just didn't notice that there is a HEADS UP. I have bang my head to the wall because of this sillyness I've done :( I have just reformat my box, and