headers
Andrey A. Chernov | 1 Jun 2004 06:03
Picon
Favicon

Re: misc/67365: sysinstall doesn'r find latinamerican keymap

Synopsis: sysinstall doesn'r find latinamerican keymap

State-Changed-From-To: open->patched
State-Changed-By: ache
State-Changed-When: Mon May 31 21:02:50 PDT 2004
State-Changed-Why: 
Fix committed into -current

http://www.freebsd.org/cgi/query-pr.cgi?pr=67365
_______________________________________________
freebsd-bugs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Remington | 1 Jun 2004 09:04
Favicon

kern/67438: [Patch] CrystalFonts USB LCD add


>Number:         67438
>Category:       kern
>Synopsis:       [Patch] CrystalFonts USB LCD add
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jun 01 00:10:10 PDT 2004
>Closed-Date:
>Last-Modified:
>Originator:     Remington
>Release:        FreeBSD
>Organization:
>Environment:
FreeBSD bart 5.2.1-RELEASE-p6 FreeBSD 5.2.1-RELEASE-p6 #1: Sat May 15 18:22:11 PDT 2004    
root <at> bart:/usr/obj/usr/src/sys/BART  i386

>Description:
I have made some changes to 5.2.1 to support CrystalFontz USB LCD displays. I have personally tested 634,
rumor has 631-633 are tested and working. If anything else is needed gimme a buzz. All diffs must be applied
in /usr/src/sys/dev/usb
>How-To-Repeat:
*** uftdi.c     Sun Aug 24 10:55:55 2003
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Wakely | 1 Jun 2004 10:19
Favicon

Re: misc/66941: Unacceptable stringstream performance


I should have mentioned that the sstream file does not exist in any
official release of GCC 2.95, it was added to FreeBSD's unofficial GCC
2.95.4 release, which is why I reported it here.

The file did exist in the GCC repository briefly between April 2000 and
Feb 2001 but was not included in any release AFAICT.

It's very unlikely that the patch will be applied to the official GCC
tree, since the file has been removed and is only in the Attic:
http://gcc.gnu.org//cgi-bin/cvsweb.cgi/gcc/libstdc++/Attic/sstream

However, if FreeBSD are going to ship the file I believe it should be
patched so it performs reasonably.

jon

_______________________________________________
freebsd-bugs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscribe <at> freebsd.org"
Permalink | Reply | 1 comment |
headers
Jonathan Wakely | 1 Jun 2004 10:30
Favicon

Re: misc/66941: Unacceptable stringstream performance

The following reply was made to PR misc/66941; it has been noted by GNATS.

From: "Jonathan Wakely" <jwakely <at> mintel.com>
To: FreeBSD-gnats-submit <at> FreeBSD.org, freebsd-bugs <at> FreeBSD.org
Cc:  
Subject: Re: misc/66941: Unacceptable stringstream performance
Date: Tue, 1 Jun 2004 09:19:00 +0100

 I should have mentioned that the sstream file does not exist in any
 official release of GCC 2.95, it was added to FreeBSD's unofficial GCC
 2.95.4 release, which is why I reported it here.

 The file did exist in the GCC repository briefly between April 2000 and
 Feb 2001 but was not included in any release AFAICT.

 It's very unlikely that the patch will be applied to the official GCC
 tree, since the file has been removed and is only in the Attic:
 http://gcc.gnu.org//cgi-bin/cvsweb.cgi/gcc/libstdc++/Attic/sstream

 However, if FreeBSD are going to ship the file I believe it should be
 patched so it performs reasonably.

 jon

 

_______________________________________________
freebsd-bugs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply | 0 comments |
headers
candy | 1 Jun 2004 11:22
Picon
Favicon

kern/67444: bge(4) patches to support Broadcom BCM5705K


>Number:         67444
>Category:       kern
>Synopsis:       bge(4) patches to support Broadcom BCM5705K
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jun 01 02:30:27 PDT 2004
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        FreeBSD 5.2.1-RELEASE i386
>Organization:
KGC
>Environment:
System: FreeBSD 5.2.1-RELEASE i386

>Description:
	bge(4) does not support Broadcom BCM5705K.
	The patches will fix it.  BCM5705K works well for me.
>How-To-Repeat:
	none
>Fix:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon L. Nielsen | 1 Jun 2004 15:26
Picon
Favicon

Re: kern/67444: bge(4) patches to support Broadcom BCM5705K

Synopsis: bge(4) patches to support Broadcom BCM5705K

State-Changed-From-To: open->closed
State-Changed-By: simon
State-Changed-When: Tue Jun 1 06:26:20 PDT 2004
State-Changed-Why: 
Duplicate of kern/67110 which has already been committed.

http://www.freebsd.org/cgi/query-pr.cgi?pr=67444
_______________________________________________
freebsd-bugs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
besen-wesen | 1 Jun 2004 16:02
Picon

IPFW & uid bind

Hello,

my firewall's security policy is supposed to allow outgoing connections to
port 53 (DNS) only from 'named' on localhost. Normally IPFW should be able
to do that just fine, since named runs as user and group 'bind' and IPFW can
handle local packets based on uid's or gid's.

Everything else works just fine. One can reduce the problem to this easily
verifiable rule:

# ipfw add 300 count log ip from any to any uid bind

Named indeed does run as bind:

box# ps x -U bind
  PID  TT  STAT      TIME COMMAND
  108  ??  Is     0:01.07 /usr/sbin/named -u bind -g bind

But IPFW does neither count nor log anything when doing DNS lookups:

# nslookup www.xyz.com

Instead filtering based on uid 'root' does work and produces a lot of
occurences:

# ipfw add 300 count log ip from any to any uid root

So what's the matter with 'bind' and IPFW?

Regards,
(Continue reading)

Permalink | Reply | 0 comments |
headers
besen-wesen | 1 Jun 2004 16:22
Picon

IPFW & uid bind - version info

I forgot to mention that I was talking about Release 4.10... Sorry!

--

-- 
+++ Jetzt WLAN-Router für alle DSL-Einsteiger und Wechsler +++
GMX DSL-Powertarife zudem 3 Monate gratis* http://www.gmx.net/dsl

_______________________________________________
freebsd-bugs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Rajesh Mittal | 1 Jun 2004 18:39
Picon
Favicon

kern/67455: EHCI controller is being programmed with incorrect address during ehci_open ( ehci.c)


>Number:         67455
>Category:       kern
>Synopsis:       EHCI controller is being programmed with incorrect address during ehci_open ( ehci.c)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jun 01 09:40:17 PDT 2004
>Closed-Date:
>Last-Modified:
>Originator:     Rajesh Mittal
>Release:        FreeBSD 5.2.1-RELEASE
>Organization:
>Environment:
>Description:
EHCI controller QH endp field can take only 4 bit wide address address ( Refer EHCI specs). The address value
being supplied in ehci_open() (ehci.c code)  is 8 bits. This is bug as the  highest bit in this 8 bit field is 
the direction of endpoint ( UE_DIR_IN/UE_DIR_OUT) not part of the real endpoint address.
This bit needs to be stripped off from the addr value while programming the QH endp field. Currently This bug
results in to EHCI_QH_HRECL incorrectly getting set in the Queue head when the endpoint is an IN endpoint. 
According to EHCI specs ( EHCI revision 0.96 page 74)
"Software must ensure that there is at most one queue head with H-bit set to one".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Uwe Doering | 1 Jun 2004 20:47

kern/67460: pmap_prefault_pageorder array initialization is broken


>Number:         67460
>Category:       kern
>Synopsis:       pmap_prefault_pageorder array initialization is broken
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jun 01 11:50:22 PDT 2004
>Closed-Date:
>Last-Modified:
>Originator:     Uwe Doering
>Release:        FreeBSD 4.5-RELEASE i386
>Organization:
EscapeBox - Managed On-Demand UNIX Servers
>Environment:
System: FreeBSD geminix.org 4.5-RELEASE FreeBSD 4.5-RELEASE #0: Thu May 27 11:49:01 GMT 2004
root <at> localhost:/STABLE_Enhanced_Edition i386

>Description:
There is a comma missing in the table initializing the
pmap_prefault_pageorder array.  This has two effects:

1. The resulting bogus contents of the array thwarts part of the
(Continue reading)

Permalink | Reply | 0 comments |

Gmane