atapicam problem in today's kernel

[Shin-ichi Yoshimoto]

Today's kernel with atapicam said:

acd0: WARNING - REQUEST_SENCE record from missing interrupt

and can not boot. Without one is OK.

-- 
Shin-ichi YOSHIMOTO <[EMAIL PROTECTED]>
http://diary.waishi.jp/~yosimoto/diary/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ATAng no good for me

[Soren Schmidt]

It seems Daniel Eischen wrote:
> On a kernel built just a few hours ago, it hangs on boot
> right after:
> 
> acd0: CDROM  at ata0-master PIO4

Get atapicam out and see if that helps..

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: What's happened to CDIOCREADAUDIO & friends?

[Soren Schmidt]

It seems Vladimir Kushnir wrote:
> 
> > > Together with sys/cdio.h, where both ioc_read_audio and CDIOCREADAUDIO are
> > > declared
> >
> > I'll get rid of those...
> >
> Again, a pity. What benefits do we gain here? Speed? CDDA extraction never
> required all that much of it, and to be honest the difference will hardly
> be measurable. The only thing it will give is (once again) an interface
> completely different from other OSs (== some extra pain for developers ==
> fewer applications).

Excuse me ? AFAIK we are the *only* OS with the CDIOCREADAUDIO interface.
I should know since I put the code in the ATAPI driver way back when our
device system couldn't handle != %DEV_BSIZE requests.

Anyhow, its been ages since it was announced that there is a new and
right way to grap audio, that noone hasn't cared about it, well...

So stop whining and get the port maintainers to fix the ports that
breaks because of this (it would maybe even reduce the diffs :) ).

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SATA drive lock-up

[Soren Schmidt]

It seems Derek Ragona wrote:
> I have a single SATA drive on an Adaptec 1210SA card.
> 
> The drive will give a write error warning a few times, then will repeatedly 
> give:
> ad4: timeout sending command=ca
> 
> The only recovery is the reset switch, reboot single-user fsck, and then 
> come back up in multiuser.
> 
> These errors occur with disk access, but not with a predictable nature (not 
> on large files, or small files, etc.)

And you are on an uptodate -current ?

If so I'd suspect HW ...

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SATA drive lock-up

[Putinas]

Since Adapted 1210SA is based on Sil3112A controller I still also have same problem 
what I reported few weeks before with my onboard sil3112a controller.
tested tonight with fresh kernel 

- Original Message - 
From: "Soren Schmidt" <[EMAIL PROTECTED]>
To: "Derek Ragona" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, September 20, 2003 10:07 AM
Subject: Re: SATA drive lock-up


It seems Derek Ragona wrote:
> I have a single SATA drive on an Adaptec 1210SA card.
> 
> The drive will give a write error warning a few times, then will repeatedly 
> give:
> ad4: timeout sending command=ca
> 
> The only recovery is the reset switch, reboot single-user fsck, and then 
> come back up in multiuser.
> 
> These errors occur with disk access, but not with a predictable nature (not 
> on large files, or small files, etc.)

And you are on an uptodate -current ?

If so I'd suspect HW ...

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ATAng no good for me

[David R. Colyer]

Is atapicam a kernel config option?

I can't seem to find it, and now since a cvsup up on the 17h, my plextor scsi 
cdrw locks my system and then reboots immediately after a burning program, 
(i've tried several) initializes the drive.  It worked several weeks ago just 
fine.  Any suggestions would be greatly appreciated.  Thanks in advance.

David R. Colyer

On Saturday 20 September 2003 01:55 am, Soren Schmidt wrote:
> It seems Daniel Eischen wrote:
> > On a kernel built just a few hours ago, it hangs on boot
> > right after:
> >
> > acd0: CDROM  at ata0-master PIO4
>
> Get atapicam out and see if that helps..
>
> -Søren
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> --
> ActivatorMail(tm) ver.00811031 Scanned for all viruses by
> www.activatormail.com intelligent anti-virus anti-spam service

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[Harald Schmalzbauer]

Kris Kennaway wrote:
On Sat, Sep 20, 2003 at 08:14:07AM +0200, Harald Schmalzbauer wrote:

Well, for weeks now I couldn't compile (almost) any port. It seems that 
ports aren't tested against -current. Is that true?


No.


Not only the -pthread removement broke countless ports (some of them are 
easy to fix others aren't) also the entire new kde fails.
Is there no aim to have ports running on -current?


Also incorrect.  The 4.9 ports freeze is holding up commits to fix
compile failures on 5.1.
Oh I see. Thats a reason. If I only knew about that freeze before my 
"pkg_delete -a" but that's just my problem

Thanks,

-Harry

Kris


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SATA drive lock-up

[Derek Ragona]

This was using the 9/18 snapshot, I tried to cvsup it to the most current, 
but the drive errors prevent the update.

I just reloaded with the 9/19 snapshot, and will report if the error still 
exists.

As for the hardware, it is all brand new hardware, and the system dual 
boots, the other OS has no issues.

-Derek

At 10:07 AM 9/20/2003 +0200, Soren Schmidt wrote:
It seems Derek Ragona wrote:
> I have a single SATA drive on an Adaptec 1210SA card.
>
> The drive will give a write error warning a few times, then will 
repeatedly
> give:
> ad4: timeout sending command=ca
>
> The only recovery is the reset switch, reboot single-user fsck, and then
> come back up in multiuser.
>
> These errors occur with disk access, but not with a predictable nature 
(not
> on large files, or small files, etc.)

And you are on an uptodate -current ?

If so I'd suspect HW ...

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[Matt]

Harald Schmalzbauer wrote:
Oh I see. Thats a reason. If I only knew about that freeze before my 
"pkg_delete -a" but that's just my problem

Thanks,

-Harry
I unfortunatly did the same thing. I wanted to upgrade to gnome 2.4 and 
seeing as this box really doesn't have any ports installed other than X 
and gnome I just ran pkg_deinstall -Ofa and started from scratch 
installing x11/XFree86-4 and x11/gnome2. Then realised that that may 
have been a bad thing when devel/pwlib failed to compile with -pthread 
issues.

Normally I am quite patient and will spend time fixing stuff, I knew how 
to change -pthread into ${PTHREAD_LIBS} etc but being in a 80x25 text 
console at the time with no working window manager I took the easy route 
out and cvsup'd to before the pthread commits instead. Installed gnome2 
which went no problems.

I will now just wait till after the 4.9 port freeze is over before going 
back to the current -current level.

It's the first time I've been "bitten" as such by running -current on my 
desktop, but hey. That's what running -current is all about :)

Keep up the good work, I look forward to 5.2!

Matt.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ATAng no good for me

[Dan Naumov]

On Sat, 2003-09-20 at 12:32, David R. Colyer wrote:
> Is atapicam a kernel config option?

 [14:11]-[jago]-[~]: cat /usr/src/sys/i386/conf/JAGO | grep atapicam
#device atapicam# BROKEN in -CURRENT !!!

Hope this helps.

Sincerely,
Dan Naumov

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Sound card troubles

[Bruce Mackay]

Hey all,

I get the following hang up when I try booting up,  here's the problem area...

pcm0:  at device 31.5 on pci0
pcm0: unable to map IO port space
device_probe_and_attach: pcm0 attach returned 6

I'm running a CVSUP -current from Thu Sep 18 12:34:00 EDT 2003,  I have a 
Yamaha YMF753 Codex Chip and it's Sound Blaster Pro compatible card,  anyone have any 
suggestions?

Thanks,
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

if_sk build fails

[Pawel Worach]

Hi!

Last if_sk update broke buildkernel

===> sk
rm -f .depend
mkdep -f .depend -a   -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ 
-I@/../include  /usr/src/sys/modules/sk/../../pci/if_sk.c
/usr/src/sys/pci/if_sk.c:129:26: pci/yukonreg.h: No such file or directory
mkdep: compile failed

missed to cvs add yukonreg.h?

   - Pawel

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Bus error

[Andre Guibert de Bruet]

On Sat, 15 Nov 2003, Philipp Westphal wrote:

> Hi today, cvsup'ed my source and build world ...
> and now get an so called
>
> Bus error
>
> while i want to su, anyone know about it (or fixed it)

1) Adjust your system clock so that it's set to something reasonable.
2) What CFLAGS do you have in /etc/make.conf?
3) Is your kernel in sync with your userland?
4) Have you run mergemaster since the last round of PAM changes?

Regards,

> Andre Guibert de Bruet | Enterprise Software Consultant >
> Silicon Landmark, LLC. | http://siliconlandmark.com/>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

ubt0, Bluetooth and kernel memory leaking

[Gary Palmer]

Hi,

It seems when using rfcomm_pppd (at least) as a Bluetooth <-> LAN
gateway there is a fairly large memory leak which eventually crashes
the box running the ppp server.  To track down where, I recorded the
output of kern.malloc every minute until the box crashed.  At the
start of the debugging run, I saw:

   devbuf   441  2650K   2861K 2504  
16,32,64,128,256,512,1024,2048,4096,8192,16384,65536


A mere 32 minutes later (right before it crashed), it was up a
considerable ammount:

   devbuf 89943184451K 184451K92399  
16,32,64,128,256,512,1024,2048,4096,8192,16384,65536

I'm pretty sure that kernel virtual memory got exhausted and the
machine paniced and rebooted.

I'm not even sure where to start looking for this. I'm using a MSI USB
dongle:

ubt0: vendor 0x0db0 product 0x1967, rev 1.10/5.25, addr 2
ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; 
wMaxPacketSize=49; nframes=6, buffer size=294

% sh /etc/rc.bluetooth start ubt0
BD_ADDR: 00:10:dc:e9:59:f4
Features: 0xff 0xff 0xf 00 00 00 00 00 
<3-Slot> <5-Slot>  
   
   

   
Max. ACL packet size: 192 bytes
Number of ACL packets: 8
Max. SCO packet size: 64 bytes
Number of SCO packets: 8

This is on -current from approx. Aug 14 2003.

The other end (client) was another MSI USB dognle on a Windows laptop.

Any ideas?

Thanks,

Gary
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ubt0, Bluetooth and kernel memory leaking

[Maksim Yevmenkin]

Hello Gary,
 
> It seems when using rfcomm_pppd (at least) as a Bluetooth <-> LAN
> gateway there is a fairly large memory leak which eventually crashes
> the box running the ppp server.  To track down where, I recorded the
> output of kern.malloc every minute until the box crashed.  At the
> start of the debugging run, I saw:
> 
>devbuf   441  2650K   2861K 2504 
> 16,32,64,128,256,512,1024,2048,4096,8192,16384,65536
> 
> A mere 32 minutes later (right before it crashed), it was up a
> considerable ammount:
> 
>devbuf 89943184451K 184451K92399 
> 16,32,64,128,256,512,1024,2048,4096,8192,16384,65536
> 
> I'm pretty sure that kernel virtual memory got exhausted and the
> machine paniced and rebooted.

hmmm... please correct me if i wrong, but devbuf means memory allocated 
with M_DEVBUF. if that is true then ng_ubt(4) is likely not a problem as
it never allocated memory from M_DEVBUF.
 
> I'm not even sure where to start looking for this. I'm using a MSI USB
> dongle:

[...]

this all looks normal to me. i seem to recall very similar discussion. 
someone else had exactly the same problem. i think last time it was tracked
back to USB code memory leak.

> This is on -current from approx. Aug 14 2003.

i just quickly checked the CVS. according to your -current date you should
have this fix. can you double check? perhaps there is another bug somewhere.

i will take close look at ng_ubt(4) today once again.

=

CVS log for src/sys/dev/usb/usb_mem.c

Revision 1.4 / (download) - annotate - [select for diffs], Tue Jul 29 05:07:37
2003 UTC (7 weeks, 4 days ago) by jmg
Branch: MAIN
CVS Tags: HEAD
Changes since 1.3: +2 -0 lines
Diff to previous 1.3 (colored)

fix another bus_dma leak due to not having a size param for our bus_dma
allocation function.  With this patch, it prevents continous growth of
the devbuf memory pool.

Tested with ssh  dd of=/dev/null < /dev/zero and vmstat -m | grep devbuf

==

thanks,
max


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: nvidia-driver still fails on -CURRENT

[Julian St.]

On Sat, 30 Aug 2003 17:56:43 +0200
"Julian St." <[EMAIL PROTECTED]> wrote:

> Hello,
> 
> some people reported strange behavior of nvidia-driver: after starting
> X the screen flickers shortly and then displays gibberish in
> text-mode. The system is still responsive, as one can login via serial
> console. XFree86.0.log stops at: (II) NVIDIA(0): Setting mode
> "1024x768"
> 
> I also experience this problem since I updated from 5.1-RELEASE to
> -CURRENT in order to try out ATAng (which works perfectly so far on my
> box). In contrast to other reports I am _unable_ to get a working
> nvidia-driver by changing AGP settings, even with NvAGP set to "0". 

My last updating to -CURRENT (Sept 16th) made this issue go away.
nvidia-driver works perfectly for me now. Don't know what caused it,
though...

Regards,
Julian

-- 
 Absolute Zero is cool -- 0K?


pgp0.pgp
Description: PGP signature

Re: ATAng no good for me

[Daniel Eischen]

On Sat, 20 Sep 2003, Soren Schmidt wrote:

> It seems Daniel Eischen wrote:
> > On a kernel built just a few hours ago, it hangs on boot
> > right after:
> > 
> > acd0: CDROM  at ata0-master PIO4
> 
> Get atapicam out and see if that helps..

No, using latest sources, with or without atapicam, does
not solve the problem.  It still hangs.

Full verbose boot log at:

  http://people.freebsd.org/~deischen/ata_hang.091903

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ATAng no good for me

[Soren Schmidt]

It seems Daniel Eischen wrote:
> > It seems Daniel Eischen wrote:
> > > On a kernel built just a few hours ago, it hangs on boot
> > > right after:
> > > 
> > > acd0: CDROM  at ata0-master PIO4
> > 
> > Get atapicam out and see if that helps..
> 
> No, using latest sources, with or without atapicam, does
> not solve the problem.  It still hangs.
> 
> Full verbose boot log at:
> 
>   http://people.freebsd.org/~deischen/ata_hang.091903

No idea, I cant get it to fail here 

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ATAng no good for me

[Lars Eggert]

Daniel Eischen wrote:
On Sat, 20 Sep 2003, Soren Schmidt wrote:
It seems Daniel Eischen wrote:

On a kernel built just a few hours ago, it hangs on boot
right after:
acd0: CDROM  at ata0-master PIO4
Get atapicam out and see if that helps..
No, using latest sources, with or without atapicam, does
not solve the problem.  It still hangs.
As a datapoint, I experienced the hang with atapicam, too. Removing it 
helped in my case.

Lars
--
Lars Eggert <[EMAIL PROTECTED]>   USC Information Sciences Institute


smime.p7s
Description: S/MIME Cryptographic Signature

Re: ATAng no good for me

[Bryan Liesner]

On Sat, 20 Sep 2003, Lars Eggert wrote:

> Daniel Eischen wrote:
> > On Sat, 20 Sep 2003, Soren Schmidt wrote:
> >>It seems Daniel Eischen wrote:
> >>
> >>>On a kernel built just a few hours ago, it hangs on boot
> >>>right after:
> >>>
> >>>acd0: CDROM  at ata0-master PIO4
> >>
> >>Get atapicam out and see if that helps..
> >
> > No, using latest sources, with or without atapicam, does
> > not solve the problem.  It still hangs.
>
> As a datapoint, I experienced the hang with atapicam, too. Removing it
> helped in my case.

I experienced the hang with atapicam, and removing it helps.  These
symptoms happened immediately after the commit of ata-queue.c v1.5.

Reverting back to 1.4 removed the issue altogether.  I tried to get a
verbose boot message using ata-queue 1.5 and 1.6, but got way, way too
many spurious interrupt messages to have anything useful to share...


-Bryan
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ubt0, Bluetooth and kernel memory leaking

[Gary Palmer]

Maksim Yevmenkin wrote in message ID
<[EMAIL PROTECTED]>:
> i just quickly checked the CVS. according to your -current date you should
> have this fix. can you double check? perhaps there is another bug somewhere.
> 
> i will take close look at ng_ubt(4) today once again.
> 
> =
> 
> CVS log for src/sys/dev/usb/usb_mem.c
> 
> Revision 1.4 / (download) - annotate - [select for diffs], Tue Jul 29 05:07:3
> 7
> 2003 UTC (7 weeks, 4 days ago) by jmg
> Branch: MAIN
> CVS Tags: HEAD
> Changes since 1.3: +2 -0 lines
> Diff to previous 1.3 (colored)
> 
> fix another bus_dma leak due to not having a size param for our bus_dma
> allocation function.  With this patch, it prevents continous growth of
> the devbuf memory pool.
> 
> Tested with ssh  dd of=/dev/null < /dev/zero and vmstat -m | grep devbu
> f
> 
> ==
> 
> thanks,
> max
> 

Max,

Thanks for the quick answer. Actually, my build didn't have that bug
fix and I'd somehow missed it while looking for relevant fixes since
my compile. I'm rebuilding now and will let you know if it doesn't
work.

Thanks,

Gary
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt

[Thomas Quinot]

Le 2003-09-20, Daniel Eischen écrivait :

> No, using latest sources, with or without atapicam, does
> not solve the problem.  It still hangs.

Please try the patch below, it should at least work around the problem.

>   http://people.freebsd.org/~deischen/ata_hang.091903

Interesting, the last 2 lines are :

ata0: spurious interrupt - status=0x50 error=0x00
acd0: WARNING - REQUEST_SENSE recovered from missing interrupt

so I'd suspect there is some race condition between the interrupt
and the REQUEST_SENSE command. Søren, shouldn't ata_interrupt lock the
channel before copying ch->running?

Thomas.

Index: atapi-cam.c
===
RCS file: /home/ncvs/src/sys/dev/ata/atapi-cam.c,v
retrieving revision 1.23
diff -u -r1.23 atapi-cam.c
--- atapi-cam.c 19 Sep 2003 16:25:44 -  1.23
+++ atapi-cam.c 20 Sep 2003 19:29:41 -
@@ -561,6 +561,7 @@
 #endif
 if (hcb_status != 0) {
csio->scsi_status = SCSI_STATUS_CHECK_COND;
+#if 0
if ((csio->ccb_h.flags & CAM_DIS_AUTOSENSE) == 0) {
int8_t ccb[16] = { ATAPI_REQUEST_SENSE, 0, 0, 0,
sizeof(struct atapi_sense), 0, 0, 0, 0, 0, 0,
@@ -572,6 +573,7 @@
csio->ccb_h.status |= CAM_AUTOSNS_VALID;
}
}
+#endif
free_hcb_and_ccb_done(hcb, CAM_SCSI_STATUS_ERROR);
 }
 else {

-- 
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SATA drive lock-up

[Derek Ragona]

The 9/19 snapshot has the same issues.

I will try to cvsup it and build a new kernel, if I can.

-Derek

At 05:36 AM 9/20/2003 -0500, Derek Ragona wrote:
This was using the 9/18 snapshot, I tried to cvsup it to the most current, 
but the drive errors prevent the update.

I just reloaded with the 9/19 snapshot, and will report if the error still 
exists.

As for the hardware, it is all brand new hardware, and the system dual 
boots, the other OS has no issues.

-Derek

At 10:07 AM 9/20/2003 +0200, Soren Schmidt wrote:
It seems Derek Ragona wrote:
> I have a single SATA drive on an Adaptec 1210SA card.
>
> The drive will give a write error warning a few times, then will 
repeatedly
> give:
> ad4: timeout sending command=ca
>
> The only recovery is the reset switch, reboot single-user fsck, and then
> come back up in multiuser.
>
> These errors occur with disk access, but not with a predictable nature 
(not
> on large files, or small files, etc.)

And you are on an uptodate -current ?

If so I'd suspect HW ...

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ATAng no good for me

[Thomas Quinot]

Le 2003-09-20, David R. Colyer écrivait :

> Is atapicam a kernel config option?

It is a device (cf. man atapicam): you can enable it with
"device atapicam" in your kernel config file.

> I can't seem to find it, and now since a cvsup up on the 17h, my plextor scsi 
> cdrw locks my system and then reboots immediately after a burning program, 
> (i've tried several) initializes the drive.  It worked several weeks ago just 
> fine.  Any suggestions would be greatly appreciated.  Thanks in advance.

If it is an SCSI (SPI) drive, then ATAPI/CAM is irrelevant. The purpose
of ATAPI/CAM is to allow access to ATAPI drives through the CAM
framework.

Thomas.

-- 
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ATAng still problematic

[Thomas Quinot]

Le 2003-09-19, Dan Naumov écrivait :

> Disabling atapicam in the kernel or detaching the drive from the system
> works around the problem.

Please try the patch I posted a few moments ago under "ATAng no good for
me/REQUEST_SENSE recovered from missing interrupt".

Thomas.

-- 
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SATA drive lock-up

[Derek Ragona]

The system died in buildworld, this time it fell into the debugger.

spec_getpages(ad4s1d) I/O read failure (error=5)

-Derek

At 02:53 PM 9/20/2003 -0500, Derek Ragona wrote:
The 9/19 snapshot has the same issues.

I will try to cvsup it and build a new kernel, if I can.

-Derek

At 05:36 AM 9/20/2003 -0500, Derek Ragona wrote:
This was using the 9/18 snapshot, I tried to cvsup it to the most 
current, but the drive errors prevent the update.

I just reloaded with the 9/19 snapshot, and will report if the error 
still exists.

As for the hardware, it is all brand new hardware, and the system dual 
boots, the other OS has no issues.

-Derek

At 10:07 AM 9/20/2003 +0200, Soren Schmidt wrote:
It seems Derek Ragona wrote:
> I have a single SATA drive on an Adaptec 1210SA card.
>
> The drive will give a write error warning a few times, then will 
repeatedly
> give:
> ad4: timeout sending command=ca
>
> The only recovery is the reset switch, reboot single-user fsck, and then
> come back up in multiuser.
>
> These errors occur with disk access, but not with a predictable 
nature (not
> on large files, or small files, etc.)

And you are on an uptodate -current ?

If so I'd suspect HW ...

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt

[Shin-ichi Yoshimoto]

Subject: Re: ATAng no good for me/REQUEST_SENSE recovered from missing 
interrupt,
On Sat, 20 Sep 2003 21:53:11 +0200, Thomas Quinot wrote:
> Please try the patch below, it should at least work around the problem.

I tried your patch. 

> acd0: WARNING - REQUEST_SENSE recovered from missing interrupt

This message disappeared, but It still hang 

-- 
Shin-ichi YOSHIMOTO <[EMAIL PROTECTED]>
http://diary.waishi.jp/~yosimoto/diary/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Network problems

[Cameron Murdoch]

I have a strange problem with my Dell Inspiron Laptop.  The network card
will stop responding to all network traffic.  This happens very
regulally, though without any obvious pattern.  Sometimes it only
appears as slight packet lose though normally the network connection
goes completly.  But then at other times the connection stays up for a
resonable time.  I have tried different cables, hubs, etc but to no
avail.  

Link status doesn't seem to get dropped, only IP.

When the connection gets dropped doing an ifconfig down/up on the
interface does ?

Unplugging and then inserting the network cable will restore the
connection for at least a few seconds.

I am running a recent current:
FreeBSD opal.macaroon.net 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Fri Sep 19
21:59: 12 BST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/OPAL
i386

The network card is an integrated intel card, (fxp0):

fxp0: flags=8843 mtu 1500
options=3
inet 10.1.10.200 netmask 0xff00 broadcast 10.1.10.255
ether 00:20:e0:69:50:3c
media: Ethernet autoselect (100baseTX )
status: active

Unfortunatly I can't remember when it started happening.  I have been
tracking current weekly for the past few months.  It certainly seems to
be getting worse though.

Any help would be much appriciated.

Cameron
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt

[Thomas Quinot]

Le 2003-09-20, Shin-ichi Yoshimoto écrivait :

> > acd0: WARNING - REQUEST_SENSE recovered from missing interrupt
> This message disappeared, but It still hang 

Can you get a backtrace at that point?

-- 
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Network problems

[Cameron Murdoch]

On Sat, 2003-09-20 at 23:10, Cameron Murdoch wrote:

> When the connection gets dropped doing an ifconfig down/up on the
> interface does ?

This was supposed to say that ifconfig down/up does not help, only
removing/inserting the network cable.

Also, sorry about the wrong email address in the privious email, I got a
little trigger happy!

Cam
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Network problems

[Derek Ragona]

try to get a diagnostic program from dell or the card maker.  If the 
diagnostics are fine, it may be power management, you will need to check 
and reset to off any power management that effects the NIC.

-Derek

At 11:18 PM 9/20/2003 +0100, you wrote:
I have a strange problem with my Dell Inspiron Laptop.  The network card
will stop responding to all network traffic.  This happens very
regulally, though without any obvious pattern.  Sometimes it only
appears as slight packet lose though normally the network connection
goes completly.  But then at other times the connection stays up for a
resonable time.  I have tried different cables, hubs, etc but to no
avail.
Link status doesn't seem to get dropped, only IP.

When the connection gets dropped doing an ifconfig down/up on the
interface does ?
Unplugging and then inserting the network cable will restore the
connection for at least a few seconds.
I am running a recent current:
FreeBSD opal.macaroon.net 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Fri Sep 19
21:59: 12 BST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/OPAL
i386
The network card is an integrated intel card, (fxp0):

fxp0: flags=8843 mtu 1500
options=3
inet 10.1.10.200 netmask 0xff00 broadcast 10.1.10.255
ether 00:20:e0:69:50:3c
media: Ethernet autoselect (100baseTX )
status: active
Unfortunatly I can't remember when it started happening.  I have been
tracking current weekly for the past few months.  It certainly seems to
be getting worse though.
Any help would be much appriciated.

Cameron
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Network problems

[Scott Likens]

On Sat, 2003-09-20 at 15:10, Cameron Murdoch wrote:
> I have a strange problem with my Dell Inspiron Laptop.  The network card
> will stop responding to all network traffic.  This happens very
> regulally, though without any obvious pattern.  Sometimes it only
> appears as slight packet lose though normally the network connection
> goes completly.  But then at other times the connection stays up for a
> resonable time.  I have tried different cables, hubs, etc but to no
> avail.  
> 
> Link status doesn't seem to get dropped, only IP.
> 
> When the connection gets dropped doing an ifconfig down/up on the
> interface does ?
> 
> Unplugging and then inserting the network cable will restore the
> connection for at least a few seconds.
> 
> I am running a recent current:
> FreeBSD opal.macaroon.net 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Fri Sep 19
> 21:59: 12 BST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/OPAL
> i386
> 
> The network card is an integrated intel card, (fxp0):
> 
> fxp0: flags=8843 mtu 1500
> options=3
> inet 10.1.10.200 netmask 0xff00 broadcast 10.1.10.255
> ether 00:20:e0:69:50:3c
> media: Ethernet autoselect (100baseTX )
> status: active
> 
> Unfortunatly I can't remember when it started happening.  I have been
> tracking current weekly for the past few months.  It certainly seems to
> be getting worse though.
> 
> Any help would be much appriciated.
> 
> Cameron

First few questiond i'd have to ask is simple,

First, do you use DHCP?

What are you doing exactly when it looses 'net or 'ip?

Specifically, does it come out of suspend mode?  cable fall out? maybe
the dhcp server times out?

Is there any messages on the console or viewable via 'dmesg'?

Thanks


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Harald Schmalzbauer <[EMAIL PROTECTED]> writes:
: Not only the -pthread removement broke countless ports (some of them are 

Maybe I missed the reason why FreeBSD needs to be unique wrt threading
programs and not have -pthread...

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Network problems

[Scott Likens]

On Sat, 2003-09-20 at 15:10, Cameron Murdoch wrote:
> I have a strange problem with my Dell Inspiron Laptop.  The network card
> will stop responding to all network traffic.  This happens very
> regulally, though without any obvious pattern.  Sometimes it only
> appears as slight packet lose though normally the network connection
> goes completly.  But then at other times the connection stays up for a
> resonable time.  I have tried different cables, hubs, etc but to no
> avail.  
> 
> Link status doesn't seem to get dropped, only IP.
> 
> When the connection gets dropped doing an ifconfig down/up on the
> interface does ?
> 
> Unplugging and then inserting the network cable will restore the
> connection for at least a few seconds.
> 
> I am running a recent current:
> FreeBSD opal.macaroon.net 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Fri Sep 19
> 21:59: 12 BST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/OPAL
> i386
> 
> The network card is an integrated intel card, (fxp0):
> 
> fxp0: flags=8843 mtu 1500
> options=3
> inet 10.1.10.200 netmask 0xff00 broadcast 10.1.10.255
> ether 00:20:e0:69:50:3c
> media: Ethernet autoselect (100baseTX )
> status: active
> 
> Unfortunatly I can't remember when it started happening.  I have been
> tracking current weekly for the past few months.  It certainly seems to
> be getting worse though.
> 
> Any help would be much appriciated.
> 
> Cameron

First few questiond i'd have to ask is simple,

First, do you use DHCP?

What are you doing exactly when it looses 'net or 'ip?

Specifically, does it come out of suspend mode?  cable fall out? maybe
the dhcp server times out?

Is there any messages on the console or viewable via 'dmesg'?

Thanks


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Network problems

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Derek Ragona <[EMAIL PROTECTED]> writes:
: try to get a diagnostic program from dell or the card maker.  If the 
: diagnostics are fine, it may be power management, you will need to check 
: and reset to off any power management that effects the NIC.

These cards don't have any meaningful power management that happens to
them, except around a suspend/resume.  These cards used to work
flawlessly, but I've not tried mine in some months, so I don't know if
it still working.  I do know that a lot of fxp driver work has been
happening over the last several months...

Wraner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Network problems

[Cameron Murdoch]

On Sat, 2003-09-20 at 23:50, Scott Likens wrote:
*snip*
> First, do you use DHCP?

No, not on this laptop.

> What are you doing exactly when it looses 'net or 'ip?

Nothing specific that I can see.  Sometimes nothing, sometimes an nfs
installworld, which was a bit dangerous seeing as the connection would
drop every few mins/secs.


> Is there any messages on the console or viewable via 'dmesg'?

None at all.

Cheers,

Cam
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt

[Shin-ichi Yoshimoto]

Subject: Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt,
On Sun, 21 Sep 2003 00:23:36 +0200, Thomas Quinot wrote:
> Can you get a backtrace at that point?

I could not get a backtrace because infinite loop occured like this:

[snip]
ata0-master: pio=0x0c wdma=0x22 udma=0x46 cable=80pin
ad0: setting UDMA100 on Intel ICH4 chip
GEOM: create disk ad0 dp=0xc6202e70
ad0:  ATA-7 disk at ata0-master
ad0: 239372MB (490234752 sectors), 486344 C, 16 H, 63 S, 512 B
ad0: 16 secs/int, 1 depth queue, UDMA100
GEOM: new disk ad0
ata1-master: pio=0x0c wdma=0x22 udma=0x44 cable=80pin
acd0: setting UDMA66 on Intel ICH4 chip
acd0:  DVDR drive at ata1 as master
acd0: read 5512KB/s (5512KB/s) write 2067KB/s (2067KB/s), 2048KB buffer, UDMA66
acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet
acd0: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof
acd0: Audio: play, 256 volume levels
acd0: Mechanism: ejectable tray, unlocked
acd0: Medium: no/blank disc
pcm0: measured ac97 link rate at 47995 Hz, will use 48000 Hz
bus_explore done
sbp_post_explore (sbp_cold=2)
[0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:490223412
[1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0
[2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0
[3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0
GEOM: Configure ad0s1, start 32256 length 250994386944 end 250994419199
GEOM: Configure ad0s1a, start 0 length 1073741824 end 1073741823
GEOM: Configure ad0s1b, start 1073741824 length 2147483648 end 3221225471
GEOM: Configure ad0s1c, start 0 length 250994386944 end 250994386943
GEOM: Configure ad0s1d, start 3221225472 length 107374182400 end 110595407871
GEOM: Configure ad0s1e, start 110595407872 length 107374182400 end 217969590271
GEOM: Configure ad0s1f, start 217969590272 length 33024796672 end 250994386943
(probe0:ata0:0:0:0): error 22
(probe0:ata0:0:0:0): Unretryable Error
(probe1:ata0:0:1:0): error 22
(probe1:ata0:0:1:0): Unretryable Error
(probe3:ata1:0:1:0): error 22
(probe3:ata1:0:1:0): Unretryable Error
(probe4:sbp0:0:0:0): error 22
(probe4:sbp0:0:0:0): Unretryable Error
(probe5:sbp0:0:1:0): error 22
(probe5:sbp0:0:1:0): Unretryable Error
(probe6:sbp0:0:2:0): error 22
(probe6:sbp0:0:2:0): Unretryable Error
(probe7:sbp0:0:3:0): error 22
(probe7:sbp0:0:3:0): Unretryable Error
(probe8:sbp0:0:4:0): error 22
(probe8:sbp0:0:4:0): Unretryable Error
(probe9:sbp0:0:5:0): error 22
(probe9:sbp0:0:5:0): Unretryable Error
(probe10:sbp0:0:6:0): error 22
(probe10:sbp0:0:6:0): Unretryable Error
(probe0:ata0:0:0:0): error 22
(probe0:ata0:0:0:0): Unretryable Error
(probe1:ata0:0:1:0): error 22
(probe1:ata0:0:1:0): Unretryable Error
(probe3:ata1:0:1:0): error 22
(probe3:ata1:0:1:0): Unretryable Error
(probe2:ata1:0:0:0): Retrying Command
(probe2:ata1:0:0:0): Retrying Command
(probe2:ata1:0:0:0): Retrying Command
(probe2:ata1:0:0:0): Retrying Command
(probe2:ata1:0:0:0): Retrying Command
(probe2:ata1:0:0:0): Retrying Command
(probe2:ata1:0:0:0): Retrying Command
(probe2:ata1:0:0:0): Retrying Command
(probe2:ata1:0:0:0): Retrying Command
..repeat..
..
..

-- 
Shin-ichi YOSHIMOTO <[EMAIL PROTECTED]>
http://diary.waishi.jp/~yosimoto/diary/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Network problems

[Scott Likens]

On Sat, 2003-09-20 at 16:04, Cameron Murdoch wrote:
> On Sat, 2003-09-20 at 23:50, Scott Likens wrote:
> *snip*
> > First, do you use DHCP?
> 
> No, not on this laptop.
> 
> > What are you doing exactly when it looses 'net or 'ip?
> 
> Nothing specific that I can see.  Sometimes nothing, sometimes an nfs
> installworld, which was a bit dangerous seeing as the connection would
> drop every few mins/secs.
> 
> 
> > Is there any messages on the console or viewable via 'dmesg'?
> 
> None at all.
> 
> Cheers,
> 
> Cam
> 

Have you tried to replace the network card with a different one to see
if you get the same results?

either the same type of card, or a different type?

It might be a weird bug in that card, or in the driver.


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt

[Bryan Liesner]

On Sat, 20 Sep 2003, Thomas Quinot wrote:

> Le 2003-09-20, Daniel Eischen écrivait :
>
> > No, using latest sources, with or without atapicam, does
> > not solve the problem.  It still hangs.
>
> Please try the patch below, it should at least work around the problem.
>
> >   http://people.freebsd.org/~deischen/ata_hang.091903
>
> Interesting, the last 2 lines are :
>
> ata0: spurious interrupt - status=0x50 error=0x00
> acd0: WARNING - REQUEST_SENSE recovered from missing interrupt
>
> so I'd suspect there is some race condition between the interrupt
> and the REQUEST_SENSE command. Søren, shouldn't ata_interrupt lock the
> channel before copying ch->running?
>
> Thomas.
>
> Index: atapi-cam.c
> ===

The patch doesn't take care of the hang for me.  Did anyone read _any_
of my previous posts?

Bryan


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Network problems

[Cameron Murdoch]

On Sun, 2003-09-21 at 00:16, Scott Likens wrote:
> On Sat, 2003-09-20 at 16:04, Cameron Murdoch wrote:
> > On Sat, 2003-09-20 at 23:50, Scott Likens wrote:
> > > First, do you use DHCP?
> > 
> > No, not on this laptop.
> > 
> > > What are you doing exactly when it looses 'net or 'ip?
> > 
> > Nothing specific that I can see.  Sometimes nothing, sometimes an nfs
> > installworld, which was a bit dangerous seeing as the connection would
> > drop every few mins/secs.
> > 
> 
> Have you tried to replace the network card with a different one to see
> if you get the same results?
> 
> either the same type of card, or a different type?
> 
> It might be a weird bug in that card, or in the driver.

It is an integrated card, so no :)

As Warner said in another email, this card normally works flawlessly.  I
have many pci versions of it in other machines running current which do
not have this problem, so it could be hardware, but it seems a little
strange to me.

Cheers,

Cam
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Getting -pthread support back into local source tree

[Dan Naumov]

Hello

Seeing as -pthread support has been removed from -CURRENT breaking
_LOTS_ of ports, is it possible to "get it back" into a local source
tree ? If so, how ? Thanks in advance.

Sincerely,
Dan Naumov

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Getting -pthread support back into local source tree

[Scot W. Hetzel]

From: "Dan Naumov" <[EMAIL PROTECTED]>
> Seeing as -pthread support has been removed from -CURRENT breaking
> _LOTS_ of ports, is it possible to "get it back" into a local source
> tree ? If so, how ? Thanks in advance.
>
All you need to do is add:

CONFIGURE_ENV+=PTHREAD_LIBS=${PTHREAD_LIBS} \
PTHREAD_CFLAGS=${PTHREAD_CFLAGS}

To the port that is broken by having -pthread support removed, then compile
the port.

If it still fails to compile, then you'll need to add a sed command to the
port that replaces -pthread with ${PTHREAD_LIBS} and -DTHREAD_SAFE with
${PTHREAD_LIBS} in the configure script or the Makefiles.

After you have it working, send-pr your patch to gnats and the port
maintainer.  This is the only way to get these problems fixed, if the port
maintainer doesn't have time to fix the port to work on -CURRENT.

Scot

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[Daniel Eischen]

On Sat, 20 Sep 2003, M. Warner Losh wrote:

> In message: <[EMAIL PROTECTED]>
> Harald Schmalzbauer <[EMAIL PROTECTED]> writes:
> : Not only the -pthread removement broke countless ports (some of them are 
> 
> Maybe I missed the reason why FreeBSD needs to be unique wrt threading
> programs and not have -pthread...

Because -pthread allows selection of one specific threadling library,
not multiple.  It is also unnecessary since the library is specified
as a link option, not a compiler option.  In the future, -pthread
will be a NOOP, but it suits us now to have it cause an error so
that ports that don't honor PTHREAD_LIBS can be found and fixed.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[Doug Barton]

On Sat, 20 Sep 2003, Daniel Eischen wrote:

> On Sat, 20 Sep 2003, M. Warner Losh wrote:
>
> > In message: <[EMAIL PROTECTED]>
> > Harald Schmalzbauer <[EMAIL PROTECTED]> writes:
> > : Not only the -pthread removement broke countless ports (some of them are
> >
> > Maybe I missed the reason why FreeBSD needs to be unique wrt threading
> > programs and not have -pthread...
>
> Because -pthread allows selection of one specific threadling library,
> not multiple.  It is also unnecessary since the library is specified
> as a link option, not a compiler option.  In the future, -pthread
> will be a NOOP, but it suits us now to have it cause an error so
> that ports that don't honor PTHREAD_LIBS can be found and fixed.

IF this is a good idea (and I'm not convinced it is), I still have two
major objections to it. First, this action was taken with very little
(any?) discussion. Second, the timing is truly horrible, occurring
during a ports freeze.

If your goal is actually to find and fix broken ports, there are a LOT
of other options, including enlisting volunteers, and using the package
building cluster.

I'd really like to see this change backed out, at minimum until the
ports freeze is over.

Doug

-- 

This .signature sanitized for your protection

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Getting -pthread support back into local source tree

[Scot W. Hetzel]

From: "Scot W. Hetzel" <[EMAIL PROTECTED]>
> From: "Dan Naumov" <[EMAIL PROTECTED]>
> > Seeing as -pthread support has been removed from -CURRENT breaking
> > _LOTS_ of ports, is it possible to "get it back" into a local source
> > tree ? If so, how ? Thanks in advance.
> >
> All you need to do is add:
>
> CONFIGURE_ENV+=PTHREAD_LIBS=${PTHREAD_LIBS} \
>
PTHREAD_CFLAGS=${PTHREAD_CFLAGS}
>
A better place for the above is to add it to bsd.port.mk where
PTHREAD_{CFLAGS,LIBS} are defined. With the attached patch.

Scot



pthread.patch
Description: Binary data
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Daniel Eischen <[EMAIL PROTECTED]> writes:
: On Sat, 20 Sep 2003, M. Warner Losh wrote:
: 
: > In message: <[EMAIL PROTECTED]>
: > Harald Schmalzbauer <[EMAIL PROTECTED]> writes:
: > : Not only the -pthread removement broke countless ports (some of them are 
: > 
: > Maybe I missed the reason why FreeBSD needs to be unique wrt threading
: > programs and not have -pthread...
: 
: Because -pthread allows selection of one specific threadling library,
: not multiple.  It is also unnecessary since the library is specified
: as a link option, not a compiler option.  In the future, -pthread
: will be a NOOP, but it suits us now to have it cause an error so
: that ports that don't honor PTHREAD_LIBS can be found and fixed.

Why does -pthread necessarily force selection of one specific
threading library?  All it means is that it is that the program uses
posix threads, at least traditionally.  How FreeBSD causes that to
happen is an interesting implementation detail for some, but irrelvant
for most ports.  Couldn't -pthread be made to give the user the
default threading package, and for those that matter a more specific
one can be specified?

It is insane to have FreeBSD be different than all other systems for
this trivial reason.  Why fix everthing in the world when allowing
-pthread to be a noop would solve the problem?  Seems like we're being
overly picky for no real gain.  I guess I just don't understand.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Doug Barton <[EMAIL PROTECTED]> writes:
: I'd really like to see this change backed out, at minimum until the
: ports freeze is over.

Me too.  I'd like to see a discussion of this in arch@ as well.  I
know that people have a low bikeshed tolerance these days, but this is
a really big change and should be talked about first.  We've retained
much less widely used interfaces for compatibility for a year or two
at times, yet -pthread was removed with little or no discussion.  That
doesn't seem right to me.  It would be one thing if FreeBSD were the
only os using it, but it appears that everybody else that supports
threads uses it, and making FreeBSD the odd man out seems a little
extreme unless there's some big gain that I've overlooked.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[Dan Naumov]

On Sun, 2003-09-21 at 04:09, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Doug Barton <[EMAIL PROTECTED]> writes:
> : I'd really like to see this change backed out, at minimum until the
> : ports freeze is over.

My thoughts exactly.

Sincerely,
Dan Naumov
-- 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[John Birrell]

On Sat, Sep 20, 2003 at 07:05:33PM -0600, M. Warner Losh wrote:
> Why does -pthread necessarily force selection of one specific
> threading library?  All it means is that it is that the program uses
> posix threads, at least traditionally.  How FreeBSD causes that to
> happen is an interesting implementation detail for some, but irrelvant
> for most ports.  Couldn't -pthread be made to give the user the
> default threading package, and for those that matter a more specific
> one can be specified?

This subject *has* been discussed both within FreeBSD and with the GCC
maintainers. I think that the consensus from those who chose to participate
in that discussion was that -pthread would be a noop on FreeBSD.

> It is insane to have FreeBSD be different than all other systems for
> this trivial reason.  Why fix everthing in the world when allowing
> -pthread to be a noop would solve the problem?  Seems like we're being
> overly picky for no real gain.  I guess I just don't understand.

Having -pthread as a noop doesn't fix the ports breakage. For years ports
have worked on the basis that libc_r was linked to get user-space threads
*instead* of libc. This was the result of certain people in the FreeBSD
developer community not wanting thread stubs in libc. Since libc was
linked by default (unless -nostdlib was specified), it was necessary to
have gcc know to use libc_r instead. That is why the -pthread argument
was added. FWIW, Linux and the other BSDs didn't have a -pthread argument
back then.

Now that libc has thread stubs in libc (in current), there is no longer
any need to have gcc know about any of the thread libraries. That's a
good thing IMO. The FSF wants GCC to have a -pthread argument on all
platforms and they are happy to have it as a noop.

I doubt that there would ever be a good time to make this change. The fact
that 4.9 has been delayed is making the problem seem worse because people
can't commit fixes to the tree. While 4.9 is delayed (due to the PAE
instability which never should have been allowed), the ports tree should
be unlocked. The fixes are simple. Make them and move on.

-- 
John Birrell
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
John Birrell <[EMAIL PROTECTED]> writes:
: On Sat, Sep 20, 2003 at 07:05:33PM -0600, M. Warner Losh wrote:
: > Why does -pthread necessarily force selection of one specific
: > threading library?  All it means is that it is that the program uses
: > posix threads, at least traditionally.  How FreeBSD causes that to
: > happen is an interesting implementation detail for some, but irrelvant
: > for most ports.  Couldn't -pthread be made to give the user the
: > default threading package, and for those that matter a more specific
: > one can be specified?
: 
: This subject *has* been discussed both within FreeBSD and with the GCC
: maintainers. I think that the consensus from those who chose to participate
: in that discussion was that -pthread would be a noop on FreeBSD.

But it was completely removed.  That sounds like the consensus wasn't
followed.  Why was it then removed?

: > It is insane to have FreeBSD be different than all other systems for
: > this trivial reason.  Why fix everthing in the world when allowing
: > -pthread to be a noop would solve the problem?  Seems like we're being
: > overly picky for no real gain.  I guess I just don't understand.
: 
: Having -pthread as a noop doesn't fix the ports breakage. For years ports
: have worked on the basis that libc_r was linked to get user-space threads
: *instead* of libc. This was the result of certain people in the FreeBSD
: developer community not wanting thread stubs in libc. Since libc was
: linked by default (unless -nostdlib was specified), it was necessary to
: have gcc know to use libc_r instead. That is why the -pthread argument
: was added. FWIW, Linux and the other BSDs didn't have a -pthread argument
: back then.

So we change -pthread to mean "link in the default threading package,
with whatever magic is necessary for that package" rather than "link
in libc_r instead of libc".

: Now that libc has thread stubs in libc (in current), there is no longer
: any need to have gcc know about any of the thread libraries. That's a
: good thing IMO. The FSF wants GCC to have a -pthread argument on all
: platforms and they are happy to have it as a noop.

Then why was it completely removed?

: I doubt that there would ever be a good time to make this change. The fact
: that 4.9 has been delayed is making the problem seem worse because people
: can't commit fixes to the tree. While 4.9 is delayed (due to the PAE
: instability which never should have been allowed), the ports tree should
: be unlocked. The fixes are simple. Make them and move on.

At the very least, we should put it back as a noop.  The timing on
this really sucks because it breaks the ports tree for an extended
period of time.  While the fixes are simple, they haven't been made
yet.  The fact that the tree is frozen makes it seem like a really bad
time to make the change.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[John Birrell]

On Sat, Sep 20, 2003 at 08:06:25PM -0600, M. Warner Losh wrote:
> But it was completely removed.  That sounds like the consensus wasn't
> followed.  Why was it then removed?

It got discussed a bit more after the removal. That was the time when the
GCC people got involved. The discussions where on FreeBSD public lists.

> So we change -pthread to mean "link in the default threading package,
> with whatever magic is necessary for that package" rather than "link
> in libc_r instead of libc".

A better way is to just link to the thread package you want. Keep knowledge
of thread libraries outside GCC. There really is nothing simpler that
adding -lc_r or -lpthread or -lmyownthreadlib. No magic required.

> Then why was it completely removed?

Dan removed it because it wasn't needed and nobody said anything otherwise.

> At the very least, we should put it back as a noop.  The timing on
> this really sucks because it breaks the ports tree for an extended
> period of time.  While the fixes are simple, they haven't been made
> yet.  The fact that the tree is frozen makes it seem like a really bad
> time to make the change.

Yes, I think it should go back as a noop (mostly to satisfy the GCC
people though).

It sucks that the 4.9 pre-release instability has been so severe. It bit
me so much I ended up using current instead. Major functionality changes
to things like VM shouldn't be made so late in a branch. It is a point
*NINE* release after all.

Unfreeze the ports tree then! I'm not a ports committer, but I'm willing
to help out fixing the problems on -current if that would help. Lets
go forward, not back.

-- 
John Birrell
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Fixing -pthreads (Re: ports and -current)

[Kris Kennaway]

On Sat, Sep 20, 2003 at 08:43:18PM -0400, Daniel Eischen wrote:
> On Sat, 20 Sep 2003, M. Warner Losh wrote:
> 
> > In message: <[EMAIL PROTECTED]>
> > Harald Schmalzbauer <[EMAIL PROTECTED]> writes:
> > : Not only the -pthread removement broke countless ports (some of them are 
> > 
> > Maybe I missed the reason why FreeBSD needs to be unique wrt threading
> > programs and not have -pthread...
> 
> Because -pthread allows selection of one specific threadling library,
> not multiple.  It is also unnecessary since the library is specified
> as a link option, not a compiler option.  In the future, -pthread
> will be a NOOP, but it suits us now to have it cause an error so
> that ports that don't honor PTHREAD_LIBS can be found and fixed.

OK, here's what we can do to fix this:

1) Put back -pthread in -current so all the ports don't fail

2) I will build a full set of -current packages with the -pthread
error still in place, to determine the list of packages that need to
be fixed (in fact I already have this, see
http://dosirak.kr.freebsd.org/errorlogs).

3) You, John Birrell, and whoever else is interested in fixing these
ports can work on them at your own pace without disrupting life for
the rest of the users.  Once they're all fixed, we can turn the error
back on or make it a NOP or do whatever else is decided to be
appropriate.

4) It is likely that steps 2 and 3 will need to be iterated several
times, because there are dozens of ports that need to be fixed, and
many of them are hiding other ports that depend on them and also need
to be fixed.

Kris


pgp0.pgp
Description: PGP signature

Re: Fixing -pthreads

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Kris Kennaway <[EMAIL PROTECTED]> writes:
: 1) Put back -pthread in -current so all the ports don't fail

I've been thinking about just doing that, but was holding off to make
sure people had a chance to do this in the absense of dragging out a
big stick.

: 2) I will build a full set of -current packages with the -pthread
: error still in place, to determine the list of packages that need to
: be fixed (in fact I already have this, see
: http://dosirak.kr.freebsd.org/errorlogs).
: 
: 3) You, John Birrell, and whoever else is interested in fixing these
: ports can work on them at your own pace without disrupting life for
: the rest of the users.  Once they're all fixed, we can turn the error
: back on or make it a NOP or do whatever else is decided to be
: appropriate.
: 
: 4) It is likely that steps 2 and 3 will need to be iterated several
: times, because there are dozens of ports that need to be fixed, and
: many of them are hiding other ports that depend on them and also need
: to be fixed.

I think this is an excellent plan.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
John Birrell <[EMAIL PROTECTED]> writes:
: On Sat, Sep 20, 2003 at 08:06:25PM -0600, M. Warner Losh wrote:
: > But it was completely removed.  That sounds like the consensus wasn't
: > followed.  Why was it then removed?
: 
: It got discussed a bit more after the removal. That was the time when the
: GCC people got involved. The discussions where on FreeBSD public lists.

Yes.  However, it is clear that the pain level wasn't adequately
disclosed at the time of the removal.

: > So we change -pthread to mean "link in the default threading package,
: > with whatever magic is necessary for that package" rather than "link
: > in libc_r instead of libc".
: 
: A better way is to just link to the thread package you want. Keep knowledge
: of thread libraries outside GCC. There really is nothing simpler that
: adding -lc_r or -lpthread or -lmyownthreadlib. No magic required.

Works for me.

: > Then why was it completely removed?
: 
: Dan removed it because it wasn't needed and nobody said anything otherwise.

Time has proven the "not needed" part was premature.

: > At the very least, we should put it back as a noop.  The timing on
: > this really sucks because it breaks the ports tree for an extended
: > period of time.  While the fixes are simple, they haven't been made
: > yet.  The fact that the tree is frozen makes it seem like a really bad
: > time to make the change.
: 
: Yes, I think it should go back as a noop (mostly to satisfy the GCC
: people though).

Sounds like we're in violent agreement.

: It sucks that the 4.9 pre-release instability has been so severe. It bit
: me so much I ended up using current instead. Major functionality changes
: to things like VM shouldn't be made so late in a branch. It is a point
: *NINE* release after all.

The problem is that they put an experimental feature into the tree in
a way that wasn't a noop for non-users of that feature.  This was done
because it would be more painful to make it a complete noop.  I've
said a few times that if PAE isn't ready for 4.9, it should be backed
out and firmed up for 4.10, but re seems to think it is a must have
feature in 4.9.

FWIW, I'm running today's RELENG_4 w/o PAE.  I'll see if there are big
issues.

: Unfreeze the ports tree then! I'm not a ports committer, but I'm willing
: to help out fixing the problems on -current if that would help. Lets
: go forward, not back.

I'll let the portmgr folks comment on this.  I think this is a good
idea.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current (really 4.9 stability)

[Frank Mayhar]

M. Warner Losh wrote:
> FWIW, I'm running today's RELENG_4 w/o PAE.  I'll see if there are big
> issues.

FYI, I've been running 4.9-prerelease since last week, all without PAE.
Booted it on all my boxen (including a web server and a database server)
as well as doing hardware reconfigurations and testing a device driver.
All _without_ PAE, which I won't touch until it has shaken out a bit.
Everything has been rock-solid, no problems at all.  Were it not for
PAE, I would say to go ahead and release it.
-- 
Frank Mayhar [EMAIL PROTECTED]  http://www.exit.com/
Exit Consulting http://www.gpsclock.com/
http://www.exit.com/blog/frank/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: really 4.9 stability

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Frank Mayhar <[EMAIL PROTECTED]> writes:
: Everything has been rock-solid, no problems at all.  Were it not for
: PAE, I would say to go ahead and release it.

That's good to hear.  The re@ folks at devsummit had said that even
w/o PAE enabled, bad things were happening to people.  However, I've
seen a number of reports since then that contradict this, or that the
instability isn't that common.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Network problems

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Cameron Murdoch <[EMAIL PROTECTED]> writes:
: As Warner said in another email, this card normally works flawlessly.  I
: have many pci versions of it in other machines running current which do
: not have this problem, so it could be hardware, but it seems a little
: strange to me.

Normally I'd have this in my Dell to test it, but the disk drive on it
is kaput right now, so I have to wait for a few days to do that.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[John Birrell]

On Sat, Sep 20, 2003 at 07:24:07PM -0700, Kris Kennaway wrote:
> 3) You, John Birrell, and whoever else is interested in fixing these
> ports can work on them at your own pace without disrupting life for
> the rest of the users.  Once they're all fixed, we can turn the error
> back on or make it a NOP or do whatever else is decided to be
> appropriate.

OK, so what's the commit procedure going to be? This could generate an
awful lot of little PRs.

Scot posted a patch for bsd.port.mk. Is that going to be committed?
That's needed.

Are you prepared to unlock the ports tree and allow a blanket commit auth
for commits that only change patch-configure? That should catch most of
the simple cases.

-- 
John Birrell
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Kris Kennaway]

On Sun, Sep 21, 2003 at 02:03:40PM +1000, John Birrell wrote:
> On Sat, Sep 20, 2003 at 07:24:07PM -0700, Kris Kennaway wrote:
> > 3) You, John Birrell, and whoever else is interested in fixing these
> > ports can work on them at your own pace without disrupting life for
> > the rest of the users.  Once they're all fixed, we can turn the error
> > back on or make it a NOP or do whatever else is decided to be
> > appropriate.
> 
> OK, so what's the commit procedure going to be? This could generate an
> awful lot of little PRs.

Call for volunteers, take the list of failed ports from dosirak and
divide it up between yourselves, then mark off the ports as fixes are
developed.  The fixes can be committed once the freeze is over (and
they are demonstrated not to break on 4.x).

There's no reason this needs to be coordinated through GNATS, and
indeed that would probably be counter-productive.  Since it won't be
affecting people outside the testing group who continue to run a gcc
that treats -pthread as an error, duplicate or bogus PRs won't be
generated by people who aren't in the loop.

> Scot posted a patch for bsd.port.mk. Is that going to be committed?
> That's needed.

Sure, if it works.  I can test it once the current 5.x build finishes
on dosirak.

> Are you prepared to unlock the ports tree and allow a blanket commit auth
> for commits that only change patch-configure? That should catch most of
> the simple cases.

I'm unsure of the current status - the original schedule called for
the ports tree to be tagged yesterday, but now the schedule has
slipped.  marcus is in charge of this release, so he'll have to
comment on the updated timeline.  However, we need to be careful not
to destabilize 4.9 in committing hasty and poorly-tested fixes for
problems on -current that do not also work on 4.x (this is
unfortunately a common occurrence).

At any rate, 4.9 will be released sooner or later, and in following
step 1) of my proposal the only people the freeze will continue to
affect are those who are working on fixing the -pthread issues, which
can be kept in private repositories for a week or two.  For everyone
else, ports that use -pthread will go back to working again (modulo
pre-existing compile failures).

Kris

pgp0.pgp
Description: PGP signature

Re: Fixing -pthreads (Re: ports and -current)

[Joe Marcus Clarke]

On Sun, 2003-09-21 at 00:22, Kris Kennaway wrote:
> On Sun, Sep 21, 2003 at 02:03:40PM +1000, John Birrell wrote:
> > On Sat, Sep 20, 2003 at 07:24:07PM -0700, Kris Kennaway wrote:
> > > 3) You, John Birrell, and whoever else is interested in fixing these
> > > ports can work on them at your own pace without disrupting life for
> > > the rest of the users.  Once they're all fixed, we can turn the error
> > > back on or make it a NOP or do whatever else is decided to be
> > > appropriate.
> > 
> > OK, so what's the commit procedure going to be? This could generate an
> > awful lot of little PRs.
> 
> Call for volunteers, take the list of failed ports from dosirak and
> divide it up between yourselves, then mark off the ports as fixes are
> developed.  The fixes can be committed once the freeze is over (and
> they are demonstrated not to break on 4.x).
> 
> There's no reason this needs to be coordinated through GNATS, and
> indeed that would probably be counter-productive.  Since it won't be
> affecting people outside the testing group who continue to run a gcc
> that treats -pthread as an error, duplicate or bogus PRs won't be
> generated by people who aren't in the loop.
> 
> > Scot posted a patch for bsd.port.mk. Is that going to be committed?
> > That's needed.
> 
> Sure, if it works.  I can test it once the current 5.x build finishes
> on dosirak.
> 
> > Are you prepared to unlock the ports tree and allow a blanket commit auth
> > for commits that only change patch-configure? That should catch most of
> > the simple cases.
> 
> I'm unsure of the current status - the original schedule called for
> the ports tree to be tagged yesterday, but now the schedule has
> slipped.  marcus is in charge of this release, so he'll have to
> comment on the updated timeline.  However, we need to be careful not
> to destabilize 4.9 in committing hasty and poorly-tested fixes for
> problems on -current that do not also work on 4.x (this is
> unfortunately a common occurrence).

I will most likely be tagging the tree sometime this week once things
have stabilized with the recent GNOME and KDE commits.  I do not want to
start having -pthread commits go in at this time as they do not help the
-STABLE build process.

Joe

> 
> At any rate, 4.9 will be released sooner or later, and in following
> step 1) of my proposal the only people the freeze will continue to
> affect are those who are working on fixing the -pthread issues, which
> can be kept in private repositories for a week or two.  For everyone
> else, ports that use -pthread will go back to working again (modulo
> pre-existing compile failures).
> 
> Kris
-- 
PGP Key : http://www.marcuscom.com/pgp.asc




signature.asc
Description: This is a digitally signed message part

Re: ports and -current

[Daniel Eischen]

On Sat, 20 Sep 2003, M. Warner Losh wrote:

> In message: <[EMAIL PROTECTED]>
> Daniel Eischen <[EMAIL PROTECTED]> writes:
> : On Sat, 20 Sep 2003, M. Warner Losh wrote:
> : 
> : > In message: <[EMAIL PROTECTED]>
> : > Harald Schmalzbauer <[EMAIL PROTECTED]> writes:
> : > : Not only the -pthread removement broke countless ports (some of them are 
> : > 
> : > Maybe I missed the reason why FreeBSD needs to be unique wrt threading
> : > programs and not have -pthread...
> : 
> : Because -pthread allows selection of one specific threadling library,
> : not multiple.  It is also unnecessary since the library is specified
> : as a link option, not a compiler option.  In the future, -pthread
> : will be a NOOP, but it suits us now to have it cause an error so
> : that ports that don't honor PTHREAD_LIBS can be found and fixed.
> 
> Why does -pthread necessarily force selection of one specific
> threading library?  All it means is that it is that the program uses
> posix threads, at least traditionally.  How FreeBSD causes that to
> happen is an interesting implementation detail for some, but irrelvant
> for most ports.  Couldn't -pthread be made to give the user the
> default threading package, and for those that matter a more specific
> one can be specified?

The default threading package when building in the ports
system is PTHREAD_LIBS.  You can't make -pthread select that.
PTHREAD_LIBS can be overridden in /etc/make.conf or the
environment.  If you want to argue between which you'd
prefer, PTHREAD_LIBS or -pthread, that's fine, but PTHREAD_LIBS
is what we currently have and what I'm going by.

> It is insane to have FreeBSD be different than all other systems for
> this trivial reason.  Why fix everthing in the world when allowing
> -pthread to be a noop would solve the problem?  Seems like we're being
> overly picky for no real gain.  I guess I just don't understand.

Allowing -pthread to be a noop doesn't necessarily solve the
problem right now.  Ports check for -pthread and use it
without also using PTHREAD_LIBS, so they would still be
broke.  Ports that are libraries that use -pthread won't
break when -pthread is NOOP'd, but non-threaded applications
that use those libraries may fail to link.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[Daniel Eischen]

On Sat, 20 Sep 2003, Doug Barton wrote:

> On Sat, 20 Sep 2003, Daniel Eischen wrote:
> 
> > On Sat, 20 Sep 2003, M. Warner Losh wrote:
> >
> > > In message: <[EMAIL PROTECTED]>
> > > Harald Schmalzbauer <[EMAIL PROTECTED]> writes:
> > > : Not only the -pthread removement broke countless ports (some of them are
> > >
> > > Maybe I missed the reason why FreeBSD needs to be unique wrt threading
> > > programs and not have -pthread...
> >
> > Because -pthread allows selection of one specific threadling library,
> > not multiple.  It is also unnecessary since the library is specified
> > as a link option, not a compiler option.  In the future, -pthread
> > will be a NOOP, but it suits us now to have it cause an error so
> > that ports that don't honor PTHREAD_LIBS can be found and fixed.
> 
> IF this is a good idea (and I'm not convinced it is), I still have two
> major objections to it. First, this action was taken with very little
> (any?) discussion. Second, the timing is truly horrible, occurring
> during a ports freeze.

This is the longest ports freeze that I can remember.  I wasn't
expecting it to last long.  Not to change the subject, I thought
it would just be long enough to lay the tag.  I don't think you
should label it as bad timing as much as asking why the freeze is
taking so long.

> If your goal is actually to find and fix broken ports, there are a LOT
> of other options, including enlisting volunteers, and using the package
> building cluster.
> 
> I'd really like to see this change backed out, at minimum until the
> ports freeze is over.

I'd like to see some barking up the other tree.  Why should fixes
to unbreak ports be held up by the freeze?

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[Daniel Eischen]

On Sun, 21 Sep 2003, John Birrell wrote:

> On Sat, Sep 20, 2003 at 07:05:33PM -0600, M. Warner Losh wrote:
> > Why does -pthread necessarily force selection of one specific
> > threading library?  All it means is that it is that the program uses
> > posix threads, at least traditionally.  How FreeBSD causes that to
> > happen is an interesting implementation detail for some, but irrelvant
> > for most ports.  Couldn't -pthread be made to give the user the
> > default threading package, and for those that matter a more specific
> > one can be specified?
> 
> This subject *has* been discussed both within FreeBSD and with the GCC
> maintainers. I think that the consensus from those who chose to participate
> in that discussion was that -pthread would be a noop on FreeBSD.
> 
> > It is insane to have FreeBSD be different than all other systems for
> > this trivial reason.  Why fix everthing in the world when allowing
> > -pthread to be a noop would solve the problem?  Seems like we're being
> > overly picky for no real gain.  I guess I just don't understand.
> 
> Having -pthread as a noop doesn't fix the ports breakage. For years ports
> have worked on the basis that libc_r was linked to get user-space threads
> *instead* of libc. This was the result of certain people in the FreeBSD
> developer community not wanting thread stubs in libc. Since libc was
> linked by default (unless -nostdlib was specified), it was necessary to
> have gcc know to use libc_r instead. That is why the -pthread argument
> was added. FWIW, Linux and the other BSDs didn't have a -pthread argument
> back then.
> 
> Now that libc has thread stubs in libc (in current), there is no longer
> any need to have gcc know about any of the thread libraries. That's a
> good thing IMO. The FSF wants GCC to have a -pthread argument on all
> platforms and they are happy to have it as a noop.
> 
> I doubt that there would ever be a good time to make this change. The fact
> that 4.9 has been delayed is making the problem seem worse because people
> can't commit fixes to the tree. While 4.9 is delayed (due to the PAE
> instability which never should have been allowed), the ports tree should
> be unlocked. The fixes are simple. Make them and move on.

I couldn't agree more :-)  There should be no reason not to commit
fixes to unbreak a port.  5.2-RELEASE has to happen relatively soon also.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Daniel Eischen <[EMAIL PROTECTED]> writes:
: I'd like to see some barking up the other tree.  Why should fixes
: to unbreak ports be held up by the freeze?

Because the ports folks do not want random changes going into the tree
right now given that they have enough build problems on 4.9 related to
GNOME.

Warner

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[Daniel Eischen]

On Sat, 20 Sep 2003, M. Warner Losh wrote:

> In message: <[EMAIL PROTECTED]>
> John Birrell <[EMAIL PROTECTED]> writes:
> : On Sat, Sep 20, 2003 at 07:05:33PM -0600, M. Warner Losh wrote:
> : > Why does -pthread necessarily force selection of one specific
> : > threading library?  All it means is that it is that the program uses
> : > posix threads, at least traditionally.  How FreeBSD causes that to
> : > happen is an interesting implementation detail for some, but irrelvant
> : > for most ports.  Couldn't -pthread be made to give the user the
> : > default threading package, and for those that matter a more specific
> : > one can be specified?
> : 
> : This subject *has* been discussed both within FreeBSD and with the GCC
> : maintainers. I think that the consensus from those who chose to participate
> : in that discussion was that -pthread would be a noop on FreeBSD.
> 
> But it was completely removed.  That sounds like the consensus wasn't
> followed.  Why was it then removed?

Consensus occured after further conversation with our FSF GCC
maintainer.  It doesn't matter now whether it is removed or
NOOP'd; ports still break, but not as obviously.

> : > It is insane to have FreeBSD be different than all other systems for
> : > this trivial reason.  Why fix everthing in the world when allowing
> : > -pthread to be a noop would solve the problem?  Seems like we're being
> : > overly picky for no real gain.  I guess I just don't understand.
> : 
> : Having -pthread as a noop doesn't fix the ports breakage. For years ports
> : have worked on the basis that libc_r was linked to get user-space threads
> : *instead* of libc. This was the result of certain people in the FreeBSD
> : developer community not wanting thread stubs in libc. Since libc was
> : linked by default (unless -nostdlib was specified), it was necessary to
> : have gcc know to use libc_r instead. That is why the -pthread argument
> : was added. FWIW, Linux and the other BSDs didn't have a -pthread argument
> : back then.
> 
> So we change -pthread to mean "link in the default threading package,
> with whatever magic is necessary for that package" rather than "link
> in libc_r instead of libc".

There is no default threading package.  That's what PTHREAD_LIBS
is suppose to do.  If we assigned -pthread to one particular
threading package, there would be no way to have a different
one selected, except perhaps globally with /etc/libmap.conf.
PTHREAD_LIBS allows the port builder to override (via /etc/make.conf)
the default threading library with whatever they want.  You
can't do that with -pthread.

> : Now that libc has thread stubs in libc (in current), there is no longer
> : any need to have gcc know about any of the thread libraries. That's a
> : good thing IMO. The FSF wants GCC to have a -pthread argument on all
> : platforms and they are happy to have it as a noop.
> 
> Then why was it completely removed?

It doesn't matter; NOOP == removed.

> : I doubt that there would ever be a good time to make this change. The fact
> : that 4.9 has been delayed is making the problem seem worse because people
> : can't commit fixes to the tree. While 4.9 is delayed (due to the PAE
> : instability which never should have been allowed), the ports tree should
> : be unlocked. The fixes are simple. Make them and move on.
> 
> At the very least, we should put it back as a noop.  The timing on
> this really sucks because it breaks the ports tree for an extended
> period of time.  While the fixes are simple, they haven't been made
> yet.  The fact that the tree is frozen makes it seem like a really bad
> time to make the change.

Again, whether it is a NOOP or removed, the same ports still break.
It is possible that even more ports could break if it is NOOP'd;
autoconf/configure can detect that -pthread is a valid switch if it
doesn't emit an error.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Daniel Eischen]

On Sat, 20 Sep 2003, Kris Kennaway wrote:

> On Sat, Sep 20, 2003 at 08:43:18PM -0400, Daniel Eischen wrote:
> > On Sat, 20 Sep 2003, M. Warner Losh wrote:
> > 
> > > In message: <[EMAIL PROTECTED]>
> > > Harald Schmalzbauer <[EMAIL PROTECTED]> writes:
> > > : Not only the -pthread removement broke countless ports (some of them are 
> > > 
> > > Maybe I missed the reason why FreeBSD needs to be unique wrt threading
> > > programs and not have -pthread...
> > 
> > Because -pthread allows selection of one specific threadling library,
> > not multiple.  It is also unnecessary since the library is specified
> > as a link option, not a compiler option.  In the future, -pthread
> > will be a NOOP, but it suits us now to have it cause an error so
> > that ports that don't honor PTHREAD_LIBS can be found and fixed.
> 
> OK, here's what we can do to fix this:
> 
> 1) Put back -pthread in -current so all the ports don't fail
> 
> 2) I will build a full set of -current packages with the -pthread
> error still in place, to determine the list of packages that need to
> be fixed (in fact I already have this, see
> http://dosirak.kr.freebsd.org/errorlogs).
> 
> 3) You, John Birrell, and whoever else is interested in fixing these
> ports can work on them at your own pace without disrupting life for
> the rest of the users.  Once they're all fixed, we can turn the error
> back on or make it a NOP or do whatever else is decided to be
> appropriate.
> 
> 4) It is likely that steps 2 and 3 will need to be iterated several
> times, because there are dozens of ports that need to be fixed, and
> many of them are hiding other ports that depend on them and also need
> to be fixed.

Just unfreeze the ports tree and allow broken ports to be
fixed.  Problem solved.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[Daniel Eischen]

On Sat, 20 Sep 2003, M. Warner Losh wrote:

> In message: <[EMAIL PROTECTED]>
> John Birrell <[EMAIL PROTECTED]> writes:
> : On Sat, Sep 20, 2003 at 08:06:25PM -0600, M. Warner Losh wrote:
> : > But it was completely removed.  That sounds like the consensus wasn't
> : > followed.  Why was it then removed?
> : 
> : It got discussed a bit more after the removal. That was the time when the
> : GCC people got involved. The discussions where on FreeBSD public lists.
> 
> Yes.  However, it is clear that the pain level wasn't adequately
> disclosed at the time of the removal.
> 
> : > So we change -pthread to mean "link in the default threading package,
> : > with whatever magic is necessary for that package" rather than "link
> : > in libc_r instead of libc".
> : 
> : A better way is to just link to the thread package you want. Keep knowledge
> : of thread libraries outside GCC. There really is nothing simpler that
> : adding -lc_r or -lpthread or -lmyownthreadlib. No magic required.
> 
> Works for me.
> 
> : > Then why was it completely removed?
> : 
> : Dan removed it because it wasn't needed and nobody said anything otherwise.
> 
> Time has proven the "not needed" part was premature.
> 
> : > At the very least, we should put it back as a noop.  The timing on
> : > this really sucks because it breaks the ports tree for an extended
> : > period of time.  While the fixes are simple, they haven't been made
> : > yet.  The fact that the tree is frozen makes it seem like a really bad
> : > time to make the change.
> : 
> : Yes, I think it should go back as a noop (mostly to satisfy the GCC
> : people though).
> 
> Sounds like we're in violent agreement.

But you seem to thing -pthread == NOOP unbreaks ports ;-)

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[John Birrell]

On Sun, Sep 21, 2003 at 01:07:15AM -0400, Daniel Eischen wrote:
> But you seem to thing -pthread == NOOP unbreaks ports ;-)

Warner might, but Kris doesn't. Kris is asking for the -pthread option
to be restored to let -current users breath easy while the task of updating
the ports goes on. Then he's happy for it to become a noop.

I susect theat this puts much of the work on a few people rather than many.
I hope it doesn't require a volley of emails to each port maintainer to
resolve each one. People have jumped off buildings for less than that!

-- 
John Birrell
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[Daniel Eischen]

On Sat, 20 Sep 2003, M. Warner Losh wrote:

> In message: <[EMAIL PROTECTED]>
> Daniel Eischen <[EMAIL PROTECTED]> writes:
> : I'd like to see some barking up the other tree.  Why should fixes
> : to unbreak ports be held up by the freeze?
> 
> Because the ports folks do not want random changes going into the tree
> right now given that they have enough build problems on 4.9 related to
> GNOME.

Oddly enough, the GNOME ports are supposedly pretty much PTHREAD_LIBS
compliant.  It's really the KDE ports that have the brunt of the
problems.  Oh, yeah, and they just updated QT and KDE to the latest
releases.  I suppose that's OK, but committing fixes to unbreak
them on -current isn't.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: The bikeshed T-shirt

[Brad Knowles]

At 1:05 AM +0200 2003/09/12, Poul-Henning Kamp wrote:

 I don't want to get into the clothing business, so if you want one,
 you'll probably have to make it yourself.   I can ask the company
 which produced them if they will be willing to ship abroad, but I
 doubt they are set up for that sort of thing.
	Per request, I have updated my version of the "FreeBSD No 
Bikeshed" t-shirt at 
.  I removed 
the "BSDCon'03" text at the bottom and replaced it with "No Bikeshed".

	The slightly modified graphics I created for this shirt are 
available at 
 
and 
, 
under the same "No Bikeshed" license under which PHK released the 
original versions.

--
Brad Knowles, <[EMAIL PROTECTED]>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Daniel Eischen]

On Sat, 20 Sep 2003, Kris Kennaway wrote:

> On Sun, Sep 21, 2003 at 02:03:40PM +1000, John Birrell wrote:
> > On Sat, Sep 20, 2003 at 07:24:07PM -0700, Kris Kennaway wrote:
> > > 3) You, John Birrell, and whoever else is interested in fixing these
> > > ports can work on them at your own pace without disrupting life for
> > > the rest of the users.  Once they're all fixed, we can turn the error
> > > back on or make it a NOP or do whatever else is decided to be
> > > appropriate.
> > 
> > OK, so what's the commit procedure going to be? This could generate an
> > awful lot of little PRs.
> 
> Call for volunteers, take the list of failed ports from dosirak and
> divide it up between yourselves, then mark off the ports as fixes are
> developed.  The fixes can be committed once the freeze is over (and
> they are demonstrated not to break on 4.x).
> 
> There's no reason this needs to be coordinated through GNATS, and
> indeed that would probably be counter-productive.  Since it won't be
> affecting people outside the testing group who continue to run a gcc
> that treats -pthread as an error, duplicate or bogus PRs won't be
> generated by people who aren't in the loop.
> 
> > Scot posted a patch for bsd.port.mk. Is that going to be committed?
> > That's needed.
> 
> Sure, if it works.  I can test it once the current 5.x build finishes
> on dosirak.
> 
> > Are you prepared to unlock the ports tree and allow a blanket commit auth
> > for commits that only change patch-configure? That should catch most of
> > the simple cases.
> 
> I'm unsure of the current status - the original schedule called for
> the ports tree to be tagged yesterday, but now the schedule has
> slipped.  marcus is in charge of this release, so he'll have to
> comment on the updated timeline.  However, we need to be careful not
> to destabilize 4.9 in committing hasty and poorly-tested fixes for
> problems on -current that do not also work on 4.x (this is
> unfortunately a common occurrence).
> 
> At any rate, 4.9 will be released sooner or later, and in following
> step 1) of my proposal the only people the freeze will continue to
> affect are those who are working on fixing the -pthread issues, which
> can be kept in private repositories for a week or two.  For everyone
> else, ports that use -pthread will go back to working again (modulo
> pre-existing compile failures).

Because -pthread has broken ports, fixes are already being
and have been developed.  Just unfreeze the tree or give
permission to commit -current breakage fixes (with the
caveat they are compile tested on -stable).

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: The bikeshed T-shirt

[Daniel Eischen]

On Sun, 21 Sep 2003, Brad Knowles wrote:

> At 1:05 AM +0200 2003/09/12, Poul-Henning Kamp wrote:
> 
> >  I don't want to get into the clothing business, so if you want one,
> >  you'll probably have to make it yourself.   I can ask the company
> >  which produced them if they will be willing to ship abroad, but I
> >  doubt they are set up for that sort of thing.
> 
>   Per request, I have updated my version of the "FreeBSD No 
> Bikeshed" t-shirt at 
> .  I removed 
> the "BSDCon'03" text at the bottom and replaced it with "No Bikeshed".
> 
>   The slightly modified graphics I created for this shirt are 
> available at 
>  
> and 
> , 
> under the same "No Bikeshed" license under which PHK released the 
> original versions.

Can you add a "no -pthread" symbol to it?

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Kris Kennaway]

On Sun, Sep 21, 2003 at 01:04:49AM -0400, Daniel Eischen wrote:
> On Sat, 20 Sep 2003, Kris Kennaway wrote:
> 
> > On Sat, Sep 20, 2003 at 08:43:18PM -0400, Daniel Eischen wrote:
> > > On Sat, 20 Sep 2003, M. Warner Losh wrote:
> > > 
> > > > In message: <[EMAIL PROTECTED]>
> > > > Harald Schmalzbauer <[EMAIL PROTECTED]> writes:
> > > > : Not only the -pthread removement broke countless ports (some of them are 
> > > > 
> > > > Maybe I missed the reason why FreeBSD needs to be unique wrt threading
> > > > programs and not have -pthread...
> > > 
> > > Because -pthread allows selection of one specific threadling library,
> > > not multiple.  It is also unnecessary since the library is specified
> > > as a link option, not a compiler option.  In the future, -pthread
> > > will be a NOOP, but it suits us now to have it cause an error so
> > > that ports that don't honor PTHREAD_LIBS can be found and fixed.
> > 
> > OK, here's what we can do to fix this:
> > 
> > 1) Put back -pthread in -current so all the ports don't fail
> > 
> > 2) I will build a full set of -current packages with the -pthread
> > error still in place, to determine the list of packages that need to
> > be fixed (in fact I already have this, see
> > http://dosirak.kr.freebsd.org/errorlogs).
> > 
> > 3) You, John Birrell, and whoever else is interested in fixing these
> > ports can work on them at your own pace without disrupting life for
> > the rest of the users.  Once they're all fixed, we can turn the error
> > back on or make it a NOP or do whatever else is decided to be
> > appropriate.
> > 
> > 4) It is likely that steps 2 and 3 will need to be iterated several
> > times, because there are dozens of ports that need to be fixed, and
> > many of them are hiding other ports that depend on them and also need
> > to be fixed.
> 
> Just unfreeze the ports tree and allow broken ports to be
> fixed.  Problem solved.

Daniel, this is most unhelpful.  We're a week or two way from
releasing 4.9-RELEASE, and unfreezing now would lead to guaranteed
problems for the release (recall the point of having ports freezes in
the first place).

What, precisely, do you object to in the above proposal?

Kris


pgp0.pgp
Description: PGP signature

Re: The bikeshed T-shirt

[Brad Knowles]

At 1:29 AM -0400 2003/09/21, Daniel Eischen wrote:

 Can you add a "no -pthread" symbol to it?
	I could do up an ash grey t-shirt with slightly modified graphics.

	What would a "no -pthread" symbol look like?

--
Brad Knowles, <[EMAIL PROTECTED]>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[Kris Kennaway]

On Sun, Sep 21, 2003 at 12:46:30AM -0400, Daniel Eischen wrote:

> This is the longest ports freeze that I can remember

I can only suppose that you haven't been paying attention to other
release cycles, because this one is shorter than usual.

>   I wasn't
> expecting it to last long.  Not to change the subject, I thought
> it would just be long enough to lay the tag.  I don't think you
> should label it as bad timing as much as asking why the freeze is
> taking so long.

The release schedule has been on the website for over a month, so
again it looks like you were simply uniformed as to timing and
duration of the release events.

Daniel, I'm trying to be reasonable here, and I think my previous
proposal achieves the ends we all want with a minimum of disruption to
the various parties involved.  Unfortunately I'm seeing a lot of heat
from you and not a lot of discussion.  Can we please try and work
cooperatively?

Kris



pgp0.pgp
Description: PGP signature

Re: Fixing -pthreads (Re: ports and -current)

[Daniel Eischen]

On Sat, 20 Sep 2003, Kris Kennaway wrote:

> On Sun, Sep 21, 2003 at 01:04:49AM -0400, Daniel Eischen wrote:
> > On Sat, 20 Sep 2003, Kris Kennaway wrote:
> > 
> > > On Sat, Sep 20, 2003 at 08:43:18PM -0400, Daniel Eischen wrote:
> > > > On Sat, 20 Sep 2003, M. Warner Losh wrote:
> > > > 
> > > > > In message: <[EMAIL PROTECTED]>
> > > > > Harald Schmalzbauer <[EMAIL PROTECTED]> writes:
> > > > > : Not only the -pthread removement broke countless ports (some of them are 
> > > > > 
> > > > > Maybe I missed the reason why FreeBSD needs to be unique wrt threading
> > > > > programs and not have -pthread...
> > > > 
> > > > Because -pthread allows selection of one specific threadling library,
> > > > not multiple.  It is also unnecessary since the library is specified
> > > > as a link option, not a compiler option.  In the future, -pthread
> > > > will be a NOOP, but it suits us now to have it cause an error so
> > > > that ports that don't honor PTHREAD_LIBS can be found and fixed.
> > > 
> > > OK, here's what we can do to fix this:
> > > 
> > > 1) Put back -pthread in -current so all the ports don't fail
> > > 
> > > 2) I will build a full set of -current packages with the -pthread
> > > error still in place, to determine the list of packages that need to
> > > be fixed (in fact I already have this, see
> > > http://dosirak.kr.freebsd.org/errorlogs).
> > > 
> > > 3) You, John Birrell, and whoever else is interested in fixing these
> > > ports can work on them at your own pace without disrupting life for
> > > the rest of the users.  Once they're all fixed, we can turn the error
> > > back on or make it a NOP or do whatever else is decided to be
> > > appropriate.
> > > 
> > > 4) It is likely that steps 2 and 3 will need to be iterated several
> > > times, because there are dozens of ports that need to be fixed, and
> > > many of them are hiding other ports that depend on them and also need
> > > to be fixed.
> > 
> > Just unfreeze the ports tree and allow broken ports to be
> > fixed.  Problem solved.
> 
> Daniel, this is most unhelpful.  We're a week or two way from
> releasing 4.9-RELEASE, and unfreezing now would lead to guaranteed
> problems for the release (recall the point of having ports freezes in
> the first place).

I don't think committing fixes for -current breakages should cause
problems for 4.9-RELEASE (especially with the caveat that they be
compile tested on -stable).  Out of curiosity, what's the reason
the tag can't be laid now?  In a better world, freezing -stable
shouldn't hinder -current.

> What, precisely, do you object to in the above proposal?

1, 2, and 3.  I don't think backing out -pthread change helps
much in fixing ports...

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports and -current

[Kris Kennaway]

On Sun, Sep 21, 2003 at 03:15:25PM +1000, John Birrell wrote:
> On Sun, Sep 21, 2003 at 01:07:15AM -0400, Daniel Eischen wrote:
> > But you seem to thing -pthread == NOOP unbreaks ports ;-)
> 
> Warner might, but Kris doesn't. Kris is asking for the -pthread option
> to be restored to let -current users breath easy while the task of updating
> the ports goes on. Then he's happy for it to become a noop.
> 
> I susect theat this puts much of the work on a few people rather than many.
> I hope it doesn't require a volley of emails to each port maintainer to
> resolve each one. People have jumped off buildings for less than that!

I expect it's about a dozen man-hours of work, or so, if there's a
group of people working on the problem.  If left to the individual
maintainers to solve, it will take a lot longer in wall clock time,
and we'll probably end up with a bunch of incorrect fixes.  It should
be no trouble at all to find volunteer port committers to help with
the task.

Kris


pgp0.pgp
Description: PGP signature

Re: The bikeshed T-shirt

[Daniel Eischen]

On Sun, 21 Sep 2003, Brad Knowles wrote:

> At 1:29 AM -0400 2003/09/21, Daniel Eischen wrote:
> 
> >  Can you add a "no -pthread" symbol to it?
> 
>   I could do up an ash grey t-shirt with slightly modified graphics.
> 
>   What would a "no -pthread" symbol look like?

I'd imagine a thread would look like:

/
   /
   \
\
 \
 /
/
   /
 
or something like that.  I'm sure Terry could draw much better ASCI
art.  Then you'd want a circle around it with a bar thru it ;-)

My question was retorical, BTW.  Don't really spend any time
drawing one :-)

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

StarOffice 6 under CURRENT

[Remington]

FreeBSD bart 5.1-CURRENT FreeBSD 5.1-CURRENT #2: Sat Sep 20 20:34:05 PDT 
2003   [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BART  i386

I am having problems running staroffice under current. My question is is 
anyone else eperiencing this problem?

The initial ports install runs fine but when running setup.bin(via 
executible staroffice6) it fails:
pid 657 (setup.bin), uid 1002: exited on signal 6

Any help is greatly appreciated!

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Kris Kennaway]

On Sun, Sep 21, 2003 at 01:44:35AM -0400, Daniel Eischen wrote:

> I don't think committing fixes for -current breakages should cause
> problems for 4.9-RELEASE (especially with the caveat that they be
> compile tested on -stable).  Out of curiosity, what's the reason
> the tag can't be laid now?  In a better world, freezing -stable
> shouldn't hinder -current.

There are other fixes that are still being committed.  It was a
release engineering decision to upgrade kde and gnome for 4.9-R, and
there are still bugs being shaken out as a result.

Since you (and others who have expressed similar puzzlement about the
need for ports freezes) are not involved in the actual mechanics of
FreeBSD release engineering, please just try to accept that there are
technical challenges in making sure that things don't go wrong at the
last minute, and the way we try to make sure the release doesn't get
botched up by a poorly-considered change at the 11th hour is by
enforcing a period of quietude on the tree so that there's a
reasonable chance that any problems will be detected before the
release instead of after.

This is the reality of it, and wishing that things were different just
isn't productive right now.

> > What, precisely, do you object to in the above proposal?
> 
> 1, 2, and 3.  I don't think backing out -pthread change helps
> much in fixing ports...

Again, why?  Please explain instead of asserting, because that's
getting us nowhere towards resolving this.

Kris

pgp0.pgp
Description: PGP signature

Re: ports and -current

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
John Birrell <[EMAIL PROTECTED]> writes:
: On Sun, Sep 21, 2003 at 01:07:15AM -0400, Daniel Eischen wrote:
: > But you seem to thing -pthread == NOOP unbreaks ports ;-)
: 
: Warner might

It appreas to unbreak one port: icecast.  It was the first port I
found so I assumed many ports were that way, but I couldn't find any
others having gone and looked at the breakage right now.

: but Kris doesn't. Kris is asking for the -pthread option
: to be restored to let -current users breath easy while the task of updating
: the ports goes on. Then he's happy for it to become a noop.

I'd be cool with this.  I don't think the 'unfreeze the ports' option
is a viable one, which leaves us with this.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Sound card troubles

[Doug White]

On Sat, 20 Sep 2003, Bruce Mackay wrote:

>
> Hey all,
>
>   I get the following hang up when I try booting up,  here's the problem area...
>
> pcm0:  at device 31.5 on pci0
> pcm0: unable to map IO port space
> device_probe_and_attach: pcm0 attach returned 6
>
>   I'm running a CVSUP -current from Thu Sep 18 12:34:00 EDT 2003, I
> have a Yamaha YMF753 Codex Chip and it's Sound Blaster Pro compatible
> card, anyone have any suggestions?

Try setting the tunable hw.pci.allow_unsupported_io_range to 1 in
loader.conf and booting. Your machine appears to need special
consideration; most ICH3 chips don't need this option.

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: if_sk build fails

[Doug White]

On Sat, 20 Sep 2003, Pawel Worach wrote:

> Hi!
>
> Last if_sk update broke buildkernel
>
> ===> sk
> rm -f .depend
> mkdep -f .depend -a   -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@
> -I@/../include  /usr/src/sys/modules/sk/../../pci/if_sk.c
> /usr/src/sys/pci/if_sk.c:129:26: pci/yukonreg.h: No such file or directory
> mkdep: compile failed

if_sk.c revision?  It should be 1.65. This was a problem last week or
so...

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Will Andrews]

On Sat, Sep 20, 2003 at 07:24:07PM -0700, Kris Kennaway wrote:
> OK, here's what we can do to fix this:
> 
> 1) Put back -pthread in -current so all the ports don't fail
> 
> 2) I will build a full set of -current packages with the -pthread
> error still in place, to determine the list of packages that need to
> be fixed (in fact I already have this, see
> http://dosirak.kr.freebsd.org/errorlogs).
> 
> 3) You, John Birrell, and whoever else is interested in fixing these
> ports can work on them at your own pace without disrupting life for
> the rest of the users.  Once they're all fixed, we can turn the error
> back on or make it a NOP or do whatever else is decided to be
> appropriate.
> 
> 4) It is likely that steps 2 and 3 will need to be iterated several
> times, because there are dozens of ports that need to be fixed, and
> many of them are hiding other ports that depend on them and also need
> to be fixed.

I don't know if there is much point to #1 at this point since
it's been gone for about 2 weeks now.  #2/3/4 sounds fine to me.

In the meantime KF is working on a patch to properly support
PTHREAD_LIBS in KDE's configure scripts.  We plan to commit it
when the freeze lifts, pending PR #55325.

I suggest that people not build ports on -CURRENT for a few weeks
until things get sorted out, unless they're going to fix the
problems with specific ports.

Regards,
-- 
wca
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

recursive lock problem.

[David Gilbert]

Running a recent current, I got a recursive lock panic with the lock
first acquired in net80211/ieee80211_node.c:525 and reacquired in 547.

The machine in question uses the following wi0 in hostap mode:

wi0:  mem 0xcecff000-0xcecf irq 11 at device 17.0 on pci0
wi0: 802.11 address: 00:05:5d:ee:e6:e7
wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI)
wi0: Intersil Firmware: Primary (1.0.5), Station (1.3.4)
wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps

With the following ifconfig line:

ifconfig_wi0="inet 192.168.192.1/24 media autoselect mode 11b mediaopt hostap ssid 
f00dbar channel 11"

Dave.

-- 

|David Gilbert, Independent Contractor.   | Two things can only be |
|Mail:   [EMAIL PROTECTED]|  equal if and only if they |
|http://daveg.ca  |   are precisely opposite.  |
=GLO
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: The bikeshed T-shirt

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Daniel Eischen <[EMAIL PROTECTED]> writes:
: Can you add a "no -pthread" symbol to it?

Can you give it a rest?  You made a bad call, people are giving you
grief for it.  That is not a bikeshed.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Daniel Eischen]

On Sat, 20 Sep 2003, Kris Kennaway wrote:

> On Sun, Sep 21, 2003 at 01:44:35AM -0400, Daniel Eischen wrote:
> > > What, precisely, do you object to in the above proposal?
> > 
> > 1, 2, and 3.  I don't think backing out -pthread change helps
> > much in fixing ports...
> 
> Again, why?  Please explain instead of asserting, because that's
> getting us nowhere towards resolving this.

Because when things break, people fix them.  There is no
motivation (as seen in the last 2+ years) to fix something
that isn't broken.

Please also see:

  
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=321307+0+archive/2003/freebsd-ports/20030601.freebsd-ports

my posting to ports@ in May of this year.

When the GCC-3.3 import broke a lot of ports, did you ask for it to
be backed out so that ports could first be fixed?  Yeah, OK, we're
in a ports freeze, so that's different now.  But once the freeze
is lifted, I don't see a need to keep -pthread in (assuming it
was added back for the freeze).

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Will Andrews]

On Sun, Sep 21, 2003 at 02:12:55AM -0400, Daniel Eischen wrote:
> Because when things break, people fix them.  There is no
> motivation (as seen in the last 2+ years) to fix something
> that isn't broken.
> 
> Please also see:
> 
>   
> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=321307+0+archive/2003/freebsd-ports/20030601.freebsd-ports
> 
> my posting to ports@ in May of this year.

I wish you'd pushed the issue a bit more aggressively.  Sometimes
people don't pay close enough attention, and I am definitely one
of those people.  My apologies for missing that message.

Regards,
-- 
wca
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: The bikeshed T-shirt

[Daniel Eischen]

On Sun, 21 Sep 2003, M. Warner Losh wrote:

> In message: <[EMAIL PROTECTED]>
> Daniel Eischen <[EMAIL PROTECTED]> writes:
> : Can you add a "no -pthread" symbol to it?
> 
> Can you give it a rest?  You made a bad call, people are giving you
> grief for it.  That is not a bikeshed.

It's just a joke at my own expense.  Sorry to imply otherwise.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: The bikeshed T-shirt

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Daniel Eischen <[EMAIL PROTECTED]> writes:
: It's just a joke at my own expense.  Sorry to imply otherwise.

Yea.  My snapping at you was out of line.  I'm just a little
frustrated and let it get the better of me.  Please forgive me.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Kris Kennaway]

On Sun, Sep 21, 2003 at 02:12:55AM -0400, Daniel Eischen wrote:
> On Sat, 20 Sep 2003, Kris Kennaway wrote:
> 
> > On Sun, Sep 21, 2003 at 01:44:35AM -0400, Daniel Eischen wrote:
> > > > What, precisely, do you object to in the above proposal?
> > > 
> > > 1, 2, and 3.  I don't think backing out -pthread change helps
> > > much in fixing ports...
> > 
> > Again, why?  Please explain instead of asserting, because that's
> > getting us nowhere towards resolving this.
> 
> Because when things break, people fix them.  There is no
> motivation (as seen in the last 2+ years) to fix something
> that isn't broken.

What's the real issue here?  It seems like you're suggesting that it's
not your responsibility to help fix the broken ports, and that other
people should do the work instead.

>   
> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=321307+0+archive/2003/freebsd-ports/20030601.freebsd-ports
> 
> my posting to ports@ in May of this year.

That change doesn't seem to have happened, or to be the same thing
we're discussing here.  Anyway, if you'd been interested in
pre-empting problems with the -pthread change you could have asked me
to do a package build with the change in place to test the waters, and
then worked with me and others to minimize the impact at the time when
the commit went in.  I routinely do this with other committers
(including the gcc imports), and I'm happy to continue doing so.

However, the strategy of just dumping a change into the tree and then
leaving it to others to clean up the mess is not a good one - it's
disruptive to the development cycle, it causes developers to get
bogged down in arguments like we find ourselves having now, and the
bottom line is that it's just not very polite to the people that your
change affects.

> When the GCC-3.3 import broke a lot of ports, did you ask for it to
> be backed out so that ports could first be fixed?

No, kan and I worked together before the change went in to evaluate
the impact on packages, then I coordinated a group of volunteers to
help fix the resulting fallout.  I'm trying to do the same thing now.
Are you willing to be part of the solution to this problem?

Kris

pgp0.pgp
Description: PGP signature

re: StarOffice 6 under CURRENT

[Martin Blapp]

Hi,

>FreeBSD bart 5.1-CURRENT FreeBSD 5.1-CURRENT #2: Sat Sep 20 20:34:05 PDT
>2003   [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BART  i386
>
>I am having problems running staroffice under current. My question is is
>anyone else eperiencing this problem?
>
>The initial ports install runs fine but when running setup.bin(via
>executible staroffice6) it fails:
>pid 657 (setup.bin), uid 1002: exited on signal 6
>
>Any help is greatly appreciated!

Sounds like linprocfs is not running anymore ?

linprocfs on /usr/compat/linux/proc (linprocfs, loc

Martin

Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: 
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"