Re: Sleeping on isp_mboxwaiting with the following non-sleepablelocks held:

2003-10-22 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Matthew Jacob writes:

Well, I don't agree with the design here, but it is what it is. I'll
make the change that you've added a requirement for. 

This is nothing new, but it is new that we can and do enforce it.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Extracting onto nfs partition locks NFS server

2003-10-22 Thread Kelley Reynolds
I have two -current boxes, one from yesterday, one from a week ago. The most recent is 
the NFS server which locks whenever the other one performs a 'make extract' in the 
NFS-mounted /usr partition. The exports file is the following:

 /usr -alldirs -maproot=root

and the mount options in fstab are
 
 soft,tcp,nfsv3,rw

It's extremely repeatable if there is anything I can do to help diagnose.

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


warnings while kernel build

2003-10-22 Thread Vladimir B. Grebenschikov

While build kernel on RELENG_4 machine I have following warnings (they
prevent success build unless -Werror disabled)

/ext/current/src# make -j8 buildkernel 
...
/ext/current/src/sys/kern/kern_descrip.c:1914: warning: inlining failed
in call to `_fgetvp'
/ext/current/src/sys/kern/kern_descrip.c:1935: warning: called from here
/ext/current/src/sys/kern/kern_descrip.c:1914: warning: inlining failed
in call to `_fgetvp'
/ext/current/src/sys/kern/kern_descrip.c:1942: warning: called from here
/ext/current/src/sys/kern/kern_descrip.c:1914: warning: inlining failed
in call to `_fgetvp'
/ext/current/src/sys/kern/kern_descrip.c:1949: warning: called from here
...
/ext/current/src/sys/vm/vm_map.c:287: warning: inlining failed in call
to `vmspace_dofree'
/ext/current/src/sys/vm/vm_map.c:319: warning: called from here
/ext/current/src/sys/vm/vm_map.c:287: warning: inlining failed in call
to `vmspace_dofree'
/ext/current/src/sys/vm/vm_map.c:343: warning: called from here

kernel config below
==
machine i386
ident   VBOOK
maxusers0

options SCHED_4BSD

options INCLUDE_CONFIG_FILE # Include this file in kernel

cpu I686_CPU  # aka Pentium Pro(tm)

options COMPAT_43
options COMPAT_FREEBSD4 # Enable FreeBSD4 compatibility syscalls

makeoptions CONF_CFLAGS=-O3 -mcpu=pentiumpro
#makeoptions CONF_CFLAGS=-fno-builtin  #Don't allow use of memcmp,
etc.

makeoptions DEBUG=-g  
#makeoptionsKERNEL=foo

options INET#Internet communications protocols
device  ether   #Generic Ethernet
device  loop#Network loopback device
device  bpf #Berkeley packet filter

options PPP_BSDCOMP #PPP BSD-compress support
options PPP_DEFLATE #PPP zlib/deflate/gzip support
options PPP_FILTER  #enable bpf filtering (needs bpfilter)

options IPFIREWALL  #firewall
options IPFIREWALL_VERBOSE  #print information about dropped
packets
options IPFIREWALL_FORWARD  #enable transparent proxy
support
#optionsIPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity
options IPDIVERT#divert sockets
options DUMMYNET

options PFIL_HOOKS 

options FFS #Fast filesystem

options PSEUDOFS
options PROCFS  #Process filesystem

options SOFTUPDATES

# Allow this many swap-devices.
device  scbus   #base SCSI code
device  da  #SCSI direct access devices (aka disks)
device  sa  #SCSI tapes
device  cd  #SCSI CD-ROMs
device  pass#CAM passthrough driver
options SCSI_DELAY=1000 

device  pty #Pseudo ttys - can go as high as 256
device  speaker #Play IBM BASIC-style noises out your speaker

device  md  # Memory disks

device  isa

device  atkbdc
device  atkbd 

device  psm
device  vga

device  sc
options MAXCONS=16  # number of virtual consoles
#optionsSC_DFLT_FONT# compile font in
#makeoptionsSC_DFLT_FONT=cp866-vio
options SC_HISTORY_SIZE=1024# number of history buffer lines
#optionsSC_DISABLE_REBOOT   # disable reboot key sequence

options SC_NO_SUSPEND_VTYSWITCH

device  npx
#device aha

device  ata
device  atadisk# ATA disk drives
device  atapicd# ATAPI CDROM drives
#device atapifd# ATAPI floppy drives
#device atapist# ATAPI tape drives

#device fdc 
device  sio

device  pci

#device apm

device  smbus
device  intpm
device  smb
device  iicbus
device  iicbb
device  ic
device  iic
device  iicsmb  
device  pmtimer


## to module
#device ppbus
#device vpo
#device lpt
#device plip
#device ppi
##devicepps
#device lpbb
#device ppc

options EXT2FS

#optionsKTRACE  #kernel tracing
options DDB
options BREAK_TO_DEBUGGER   #a BREAK on a comconsole goes to
#DDB, if available.


# OLDCARD
#device  pcic
#device  card 1

# NEWCARD
# Pcmcia and cardbus bridge support
#device  cbb   # cardbus (yenta) bridge
#device  pccard
#device  cardbus


#device  wlan
#device  wi

device  random

options _KPOSIX_PRIORITY_SCHEDULING

#device  acpica
#options ACPI_DEBUG

options KBD_INSTALL_CDEV

#device  uhci
#device  ohci
#device  usb
#device  

Re: Question on freeBSD (5.1-CURRENT) portupgrade of Perl5.8andlibiconv 1.9.1_3

2003-10-22 Thread Putinas
if you use portupgrade and you want to pass make arguments you should look at 
/usr/local/etc/pkgtools.conf 
my example  :
  MAKE_ARGS = {
'irc/bitchx-*' = 'WITH_SSL=1 WITH_IPV6=1',
'net/samba*' = 'WITHOUT_CUPS=1',
'databases/mysql323-server*' = 'SKIP_INSTALL_DB=1',
'ftp/proftpd*' = 'WITHOUT_PAM=1',
  }

after you setup it for your needs - your life become pretty easy with portupgrading ...
- Original Message - 
From: Scott Wegener, Roadster Performance [EMAIL PROTECTED]
To: Joe Marcus Clarke [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Scott W [EMAIL PROTECTED]
Sent: Wednesday, October 22, 2003 07:34 AM
Subject: Re: Question on freeBSD (5.1-CURRENT) portupgrade of Perl5.8andlibiconv 
1.9.1_3


 Joe Marcus Clarke wrote:
 
 On Wed, 2003-10-22 at 01:14, Scott W wrote:
   
 
 Hey all.  In doing a portupgrade -RvN for windowmaker, Perl and libiconv 
 were recompiled.  I saved the log output and noticed several oddities I 
 was wondering if anyone can explain?
 
 1..several settings come up as undefined during the Perl build, namely:
 $i_malloc
 $d_setegid
 $d_seteuid
 $i_iconv
 
 These don't look troubling by themselves dur to 'autoconf magic,' but 
 the next one for libiconv is more bothersome:
 
  From libiconv 1.9.1_3 configure:
 checking if libtool supports shared libraries... yes
 
 *** Warning: the command libtool uses to detect shared libraries,
 *** /usr/bin/file, produces output that libtool cannot recognize.
 *** The result is that libtool may fail to recognize shared libraries
 *** as such.  This will affect the creation of libtool libraries that
 *** depend on shared libraries, but programs linked with such libtool
 *** libraries will work regardless of this problem.  Nevertheless, you
 *** may want to report the problem to your system manager and/or to
 *** [EMAIL PROTECTED]
 
 Any ideas?
 
 
 
 This is a byproduct of the new dynamic root layout in -CURRENT. 
 Basically, older versions of libtool try to do file on
 /usr/lib/libc.so.  Recent versions of -CURRENT put libc.so in /lib. 
 Therefore, this fails.  I haven't noticed any real problems because of
 this, but I have reported it to the libtool maintainer, [EMAIL PROTECTED]
   
 
 Great.  That makes sense, as file will return symbolic link rather than 
 an ELF executable, should be a minor adjustment by the maintainer.  Also 
 makes sense on libc in /lib - always disturbs me when I see 'important' 
 system binaries mounted on the /usr filesystem!
 
 Also, is there a way to pass configure options to portupgrade, or should 
 I run make clean  ./configure for each port in an 'upgrade chain' and 
 then force portupgrade to not make clean prior to building/installing?
 
 
 
 Configure arguments?  No.  However, you can use the -m option to pass
 make arguments (e.g. -DWITH_FOO).  To pass configure arguments, you'd
 have to edit the port Makefiles directly.
 
 Joe
   
 
 
 Actually, it _looks_ like there's somewhat of a standard in place within 
 the port Makefiles defining CONFIGURE_ARGS, but I haven't searched 
 through all of them- anyone know if this is a 'freeBSD Makefile 
 standard' that can (generally) be counted on?  If so, at least for 
 specific ports builds, you should be able to define it on the command 
 line to make (as Joe stated) or via passing the parameter to make for 
 portupgradealthough that change doesn't get saved anywhere and will 
 be clobbered by the next cvsup- any clean way to avoid this?  I need to 
 build apache for this system at some point, and somehow I'm not just 
 seeing the defaults as likely to 'fit everyone' on that one?
 
 Thanks again,
 
 Scott
 
 Thanks,
 
 Scott
 
 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 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: ethercons: ethernet console driver for 5-current

2003-10-22 Thread Terry Lambert
Peter Jeremy wrote:
 As with the Linux driver, communication happens at the ethernet link
 layer, using protocol number 0x0666 (entertaining choice).
 
 If Linux is using 0x0666, we should probably pick a different number
 since we're not wire compatible.  Though coming up with a common
 protocol would be even better.

0x666 hex is 1638 decimal, and it's taken:

cnip1638/tcp  CableNet Info Protocol
cnip1638/udp  CableNet Info Protocol

Basically, this is just an experimental protocol that's being played
with here, and if it ever becomes real, then it will need an IANA
protocol number assignment before it's widely deployed.

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


UFS file system problem in either stable or current

2003-10-22 Thread Dan Strick
There seems to be an inconsistency between release 4.9-RC and 5.1 ufs
support.  If I fsck the same ufs (type 1 of course) file system on
both releases, each claims that the other has left incorrect
summary data in the superblock.  Presumably only one can be correct.
I just don't know which to blame.

I couldn't find a FreeBSD problem report about bad summary data.
I will submit one, but since FreeBSD 4.9 is about to be released,
someone might like to check this out.

I happen to have multiple FreeBSD operating systems installed on
the same computer.  This might also be an issue if you move an
external disk between computers.  I don't know if the problem shows
up on all file systems.  It seems to happen on all the half dozen
or so of the file systems that my 4.9-RCx and 5.1 systems share.

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


Re: ethercons: ethernet console driver for 5-current

2003-10-22 Thread Erik Trulsson
On Wed, Oct 22, 2003 at 12:30:41AM -0700, Terry Lambert wrote:
 Peter Jeremy wrote:
  As with the Linux driver, communication happens at the ethernet link
  layer, using protocol number 0x0666 (entertaining choice).
  
  If Linux is using 0x0666, we should probably pick a different number
  since we're not wire compatible.  Though coming up with a common
  protocol would be even better.
 
 0x666 hex is 1638 decimal, and it's taken:
 
 cnip1638/tcp  CableNet Info Protocol
 cnip1638/udp  CableNet Info Protocol

That would be relevant if this protocol used TCP or UDP.
My understanding is that it doesn't, in which case those port
assignments are quite irrelevant.

Looking at the protocol types listed in /usr/include/net/ethernet.h
seems more relevant, unless I have misunderstood something.

 
 Basically, this is just an experimental protocol that's being played
 with here, and if it ever becomes real, then it will need an IANA
 protocol number assignment before it's widely deployed.

Are you sure that IANA would be the right organisation, since AIUI this
isn't a protocol running on top of IP ?

 
 -- Terry

-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


EIB devices/services

2003-10-22 Thread Willem Jan Withagen
Hi,

(Not quite for current@, but that's where leading edge is going on)

For the new house we are building I'm looking into EIB.
(European Installation Bus).
And I'm searching for EIB/IP gateways and applications on FreeBSD.
Has anybody used these kinds of tools with FBSD (or Linux)

Or even better: Any experience is welcomed

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


Re: panic: softdep_deallocate_dependencies: dangling deps

2003-10-22 Thread YONETANI Tomokazu
Hello.

On 2003/10/13 02:09:54, Oliver Fischer wrote:
 My notebook was a little bit panic this night. After rebooting I found 
  this message in my system log:
 
  panic: softdep_deallocate_dependencies: dangling deps

I've been seeing this panic on NetFinity 6000R since end of September.
-CURRENT is installed on a RAID partition, and the partition is controlled
by ips driver, so it's possible that the root of my problem is completely
different from yours, but anyway...

To reproduce it, enable dump device and create many files in a directory:

# mkdir foo; i=0; while :; do echo -n $i  foo/$i; i=$(($i + 1)); done

and go to bed and you'll get a kernel dump in the crash dump directory
in the next morning. At first I thought that the hard disk is damanged,
but the following dd command doesn't panic the machine, just fills up
the partition many times.
# while :; do dd if=/dev/zero of=BIG bs=1048576; done

With -CURRENT built from source as of D2003.10.21.00.00.00, I'm still
able to reproduce this panic, together with new one:
panic: handle_written_inodeblock: live inodedep

Backtraces are available on request.
-- 
YONETANI Tomokazu / Ergo-Brains Inc.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Error assigning master socket: Too many open files

2003-10-22 Thread Andreas Klemm
Hi,

Urgend question, wanna help a collegue, who secured a router,
but trying to scan ports fails with -current.

I don't want to blame anybody, I know what the policy of current
is. If I can't get quick help on this I use a Windows tool,
no problem. I only want to save me the work to install this Win tool
and I think its interesting, to find out, that there might be
a problem.

The machine was freshly booted 
Is there a workaround ?

[EMAIL PROTECTED] /usr/ports/security/portscanner/work/PortScanner-1.2 portscanner -vv 
-v -v -b 1 -e 6 xx.xxx.xxx.xx
xx.xxx.xx.xx
Error assigning master socket: Too many open files
Exit 255

FreeBSD titan.klemm.apsfilter.org 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Oct 19 
16:33:53 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/TITAN  i386

mbuf usage:
GEN cache:  0/224 (in use/in pool)
CPU #0 cache:   65/576 (in use/in pool)
Total:  65/800 (in use/in pool)
Mbuf cache high watermark: 512
Maximum possible: 34432
Allocated mbuf types:
  65 mbufs allocated to data
2% of mbuf map consumed
mbuf cluster usage:
GEN cache:  0/0 (in use/in pool)
CPU #0 cache:   64/120 (in use/in pool)
Total:  64/120 (in use/in pool)
Cluster cache high watermark: 128
Maximum possible: 17216
0% of cluster map consumed
440 KBytes of wired memory reserved (32% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines


Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-CURRENT #0: Sun Oct 19 16:33:53 CEST 2003
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/TITAN
Preloaded elf kernel /boot/kernel/kernel at 0xc07c8000.
Preloaded elf module /boot/kernel/linux.ko at 0xc07c81f4.
Preloaded elf module /boot/kernel/acpi.ko at 0xc07c82a0.
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel Pentium III (997.46-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x686  Stepping = 6
  
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real memory  = 536854528 (511 MB)
avail memory = 516009984 (492 MB)
netsmb_dev: loaded
Pentium Pro MTRR support enabled
npx0: [FAST]
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: ASUS   MED_2001 on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 6 entries at 0xc00f0eb0
acpi0: Power Button (fixed)
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0
acpi_cpu0: CPU on acpi0
acpi_button0: Power Button on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib0: slot 4 INTD is routed to irq 10
pcib0: slot 4 INTD is routed to irq 10
pcib0: slot 9 INTA is routed to irq 3
pcib0: slot 10 INTA is routed to irq 10
agp0: VIA 82C691 (Apollo Pro) host to PCI bridge mem 0xfc00-0xfdff at device 
0.0 on pci0
pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0
pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - AE_NOT_FOUND
pci1: ACPI PCI bus on pcib1
pci1: display, VGA at device 0.0 (no driver attached)
isab0: PCI-ISA bridge at device 4.0 on pci0
isa0: ISA bus on isab0
atapci0: VIA 82C686A UDMA66 controller port 0xd800-0xd80f at device 4.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]
uhci0: VIA 83C572 USB controller port 0xd400-0xd41f irq 10 at device 4.2 on pci0
usb0: VIA 83C572 USB controller on uhci0
usb0: USB revision 1.0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ulpt0: Hewlett-Packard PSC 2200 Series, rev 2.00/1.00, addr 2, iclass 7/1
ulpt0: using bi-directional mode
umass0: Hewlett-Packard PSC 2200 Series, rev 2.00/1.00, addr 2
ugen0: Syncrosoft Protected Executer, rev 1.10/1.01, addr 3
uhci1: VIA 83C572 USB controller port 0xd000-0xd01f irq 10 at device 4.3 on pci0
usb1: VIA 83C572 USB controller on uhci1
usb1: USB revision 1.0
uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
pci0: multimedia, audio at device 9.0 (no driver attached)
fxp0: Intel 82559 Pro/100 Ethernet port 0xa400-0xa43f mem 
0xed00-0xed0f,0xed80-0xed800fff irq 10 at device 10.0 on pci0
fxp0: Ethernet address 00:d0:b7:ba:c1:c2
miibus0: MII bus on fxp0
inphy0: i82555 10/100 media interface on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 
irq 6 drq 2 on acpi0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5 drive on fdc0 drive 0
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0
atkbd0: AT Keyboard flags 0x1 

Re: make release...

2003-10-22 Thread Anthony Fajri

thanks alot for your reply...

but, after patched my FreeBSD with your patch, i still get errors

root   pwd
/home/fajri/data/usr/src/release
root   patch  genesis-patch-ae

root   make release CHROOTDIR=/home/fajri/data/root BUILDNAME=FAJRI
CVSROOT=/home/fajri/data/usr RELEASETAG=RELENG_4_8_RELEASE

cd /home/fajri/data/root/usr  rm -rf src   cvs -R -d /home/fajri/data/usr co
-P -r RELENG_4_8_RELEASE src
cvs [checkout aborted]: no such tag RELENG_4_8_RELEASE
*** Error code 1

Stop in /home/fajri/data/usr/src/release.

root   make release CHROOTDIR=/home/fajri/data/root BUILDNAME=FAJRI
CVSROOT=/home/fajri/data/usr RELEASETAG=RELENG_4_8
cd /home/fajri/data/root/usr  rm -rf src   cvs -R -d /home/fajri/data/usr co
-P -r RELENG_4_8 src
cvs [checkout aborted]: no such tag RELENG_4_8
*** Error code 1

Stop in /home/fajri/data/usr/src/release.



..::f::..

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


Re: Random signals in {build,install}world recently?

2003-10-22 Thread Doug Rabson
On Tue, 2003-10-21 at 07:59, Terry Lambert wrote:
 Christian Brueffer wrote:
   I don't think so.  I tried that on my A7M266D with no effect.  I believe
   something in recent pmap code doesn't like this mobo, or maybe dual
   athlons in general.  I can run RELENG_5_1 rock solid, and -current from
   9/24/03 rock solid, but -current from 10/3 or later gets random sigs
   and eventually panics.  I have scsi disks so it's not ata.
  
  I have the same experiences.  Also AMD A7M-266D with two 1800+ Athlons here.
  Used to work fine, but got random signals with my latest builds.
 
 On thing that occurs to me: try the other scheduler: there were
 recent changes in this area, which may be the problem.

I also get random segfaults and ICEs on my dual 1900+ system with recent
current. It certainly isn't hardware problems since older kernels work
very nicely. I haven't got around to trying to diagnose what is causing
it yet though. I was planning to try disabling a few things like SSE,
PSE etc and see if I could improve things. My kernel is dated from 1
October (I did try a bit later than that but those ones just paniced all
over themselves, very messy).


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


Re: make release...

2003-10-22 Thread Daniel O'Connor
On Wednesday 22 October 2003 22:15, Anthony Fajri wrote:
   thanks alot for your reply...

   but, after patched my FreeBSD with your patch, i still get errors

Err the patch isn't designed to fix your problem, it is just written by me to 
make things a bit easier.

I suggest re-reading my email.

 root   pwd
 /home/fajri/data/usr/src/release
 root   patch  genesis-patch-ae

 root   make release CHROOTDIR=/home/fajri/data/root BUILDNAME=FAJRI
 CVSROOT=/home/fajri/data/usr RELEASETAG=RELENG_4_8_RELEASE

 cd /home/fajri/data/root/usr  rm -rf src   cvs -R -d
 /home/fajri/data/usr co -P -r RELENG_4_8_RELEASE src
 cvs [checkout aborted]: no such tag RELENG_4_8_RELEASE
 *** Error code 1

 Stop in /home/fajri/data/usr/src/release.

 root   make release CHROOTDIR=/home/fajri/data/root BUILDNAME=FAJRI
 CVSROOT=/home/fajri/data/usr RELEASETAG=RELENG_4_8
 cd /home/fajri/data/root/usr  rm -rf src   cvs -R -d
 /home/fajri/data/usr co -P -r RELENG_4_8 src
 cvs [checkout aborted]: no such tag RELENG_4_8
 *** Error code 1

 Stop in /home/fajri/data/usr/src/release.



 ..::f::..

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
  -- Andrew Tanenbaum
GPG Fingerprint - 9A8C 569F 685A D928 5140  AE4B 319B 41F4 5D17 FDD5

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


Re: UFS file system problem in either stable or current

2003-10-22 Thread Peter Schultz
Dan Strick wrote:
There seems to be an inconsistency between release 4.9-RC and 5.1 ufs
support.  If I fsck the same ufs (type 1 of course) file system on
both releases, each claims that the other has left incorrect
summary data in the superblock.  Presumably only one can be correct.
I just don't know which to blame.
I couldn't find a FreeBSD problem report about bad summary data.
I will submit one, but since FreeBSD 4.9 is about to be released,
someone might like to check this out.
I happen to have multiple FreeBSD operating systems installed on
the same computer.  This might also be an issue if you move an
external disk between computers.  I don't know if the problem shows
up on all file systems.  It seems to happen on all the half dozen
or so of the file systems that my 4.9-RCx and 5.1 systems share.
There is no problem AFAIK, you just have to fsck with the matching 
executable.  A lot has changed with FreeBSD 5, spend some time with the 
-current archive and you will learn more.  I'm sure you noticed how your 
findings are consistently inconsistent.

Pete...

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


Re: Sleeping on isp_mboxwaiting with the followingnon-sleepablelocks held:

2003-10-22 Thread Matthew Jacob


It isn't the cannot sleep from geometry calls that is twitting me a
bit, it's the I cannot tell at my call depth in the stack whether some
dork above can't tolerate a sleep[1]. If I've missed some usage point
with the SMP stuff that I *can* tell this with ease, enlighten me.

-matt


[1]: by 'sleep', I mean if I do *my* locking right, I should be able to
yield the processor and wait for an event (an interrupt in this case). A
yield might not actually do anything but call idle- if that's what is
appropriate. There are several things meant by cannot sleep- one is
deadlock avoidance and the other is thread of execution ordering. A
blanket cannot sleep sometimes can mean just plain poor design. I
don't really mean to be inflammatory here but I kinda *am* raising my
eyebrows here with a polite query of are you sure you really want to do
this this way?.

I mean, this particular instance isn't a big deal. Instead of waiting
for a mailbox event to clear I'll poll it, doing nothing useful
otherwise. It's a rare event, but it makes the system sluggish. There
are alternative designs that I could take at this level that would do
neither, but add greatly to code complexity at this level. No big deal,
but still...




On Wed, 22 Oct 2003, Poul-Henning Kamp wrote:

 In message [EMAIL PROTECTED], Matthew Jacob writes:

 Well, I don't agree with the design here, but it is what it is. I'll
 make the change that you've added a requirement for.

 This is nothing new, but it is new that we can and do enforce it.

 --
 Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
 [EMAIL PROTECTED] | TCP/IP since RFC 956
 FreeBSD committer   | BSD since 4.3-tahoe
 Never attribute to malice what can adequately be explained by incompetence.

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


Re: Yet another LOR: vm object/system map

2003-10-22 Thread Yar Tikhiy
On Tue, Oct 21, 2003 at 11:49:41AM -0700, Kris Kennaway wrote:
 On Tue, Oct 21, 2003 at 10:46:12PM +0400, Yar Tikhiy wrote:
  This particular LOR happened upon getting out of swap.
  My knowledge is insufficient to tell if it's a sign of
  a real problem or just a false positive.
 
 See my message from a few days ago where I posted a mail from alc
 showing how to tell whether these are real or not.

Thanks for pointing me out!
Now I see that the LOR I've reported is harmless.
Pardon me for the noise.

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


Re: Random signals in {build,install}world recently?

2003-10-22 Thread Rob MacGregor
From: Doug Rabson [EMAIL PROTECTED]

I also get random segfaults and ICEs on my dual 1900+ system with recent
current. It certainly isn't hardware problems since older kernels work
very nicely. I haven't got around to trying to diagnose what is causing
it yet though. I was planning to try disabling a few things like SSE,
PSE etc and see if I could improve things. My kernel is dated from 1
October (I did try a bit later than that but those ones just paniced all
over themselves, very messy).
I've been seeing those on my laptop (PII-700 in an HP Omnibook 6000).  What 
I did find is that if I disable SSE (options CPU_DISABLE_SSE) then I can 
build without issue.  I haven't had to disable anything else.

Credit for this goes to somebody else on the list (don't remember who) who 
said it worked for them.

 Please DO NOT send me ANY email directly unless it's a privacy issue.
  Reply-to mangled to assist those who don't read the above.
--
Rob  |  What part of no was it you didn't understand?
_
Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Error assigning master socket: Too many open files

2003-10-22 Thread Peter Edwards
Andreas Klemm wrote:

Hi,

Urgend question, wanna help a collegue, who secured a router,
but trying to scan ports fails with -current.
I don't want to blame anybody, I know what the policy of current
is. If I can't get quick help on this I use a Windows tool,
no problem. I only want to save me the work to install this Win tool
and I think its interesting, to find out, that there might be
a problem.
The machine was freshly booted 
Is there a workaround ?
[EMAIL PROTECTED] /usr/ports/security/portscanner/work/PortScanner-1.2 portscanner -vv 
-v -v -b 1 -e 6 xx.xxx.xxx.xx
xx.xxx.xx.xx
Error assigning master socket: Too many open files
Exit 255
The patch applied by the port appears bogus. It adds braces around an 
if that stops it executing the way it was intended. I've a sneaking 
suspicion that the braces were added for clarity, but the indentation 
in the original file is so badly off that the terminating brace was put 
in the wrong place. Try replacing patch-ab with this:

--- portscanner.c.orig  Wed Aug 19 18:37:44 1998
+++ portscanner.c   Wed Oct 22 15:28:05 2003
@@ -25,8 +25,8 @@
/***/
#include stdio.h
-#include sys/socket.h
#include sys/types.h
+#include sys/socket.h
#include netinet/in.h
#include unistd.h
#include netdb.h
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


GEOM_FOX woes

2003-10-22 Thread Sawek ak
Hi,

I tried to use geom_fox to implement multipathing on my machine. The setup
is: Dell PowerEdge 2600, 2 QLogic 2312 FC Adapters, 2 Brocade 2800 Switches,
1 Compaq HSG 80 FC array with 2 redundant FC controllers. I wrote the magic
labels on the disks, according to the script in the announce message:

   http://lists.freebsd.org/pipermail/freebsd-current/2003-June/005288.html

After reboot, none of the devices ending with .fox were writeable. The
original disks (da??c) were unwriteable either. geom_fox detects the devices
just fine. Here is the snippet from dmesg, after loading geom_fox:

Creating new fox (da13)
fox da13.fox lock 0xcb3a5e14
Creating new fox (da12)
fox da12.fox lock 0xcb3a5c14
Creating new fox (da11)
fox da11.fox lock 0xcb3a5994
Creating new fox (da10)
fox da10.fox lock 0xcb3a5814
Creating new fox (da9)
fox da9.fox lock 0xcb3a5614
Creating new fox (da8)
fox da8.fox lock 0xcb3a5f14
Creating new fox (da7)
fox da7.fox lock 0xcb3b1d94
Adding path (da6) to fox (da13.fox)
Adding path (da5) to fox (da12.fox)
Adding path (da4) to fox (da11.fox)

[...similar messages...]

Adding path (da0c) to fox (da7.fox)
Removing path (da0) from fox (da7.fox)
Removing path (da0c) from fox (da7.fox)
Adding path (da0) to fox (da7.fox)
Adding path (da0c) to fox (da7.fox)

I don't know why the paths to da0 and da0c were removed by geom_fox. There
is no connectivity problem for sure. I don't know why there are separate
paths to both da0 and da0c. Regarding the problem with incosistent naming
(which is crucial for safely rebooting the machine), I would suggest naming
the devices after the magic ID written on disk, which would be much
more consistent and meaningful than chosing between multiple device names.

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


Re: GEOM_FOX woes

2003-10-22 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], =?iso-8859-2?q?S=B3awek_=AFak?= 
writes:
Hi,

I tried to use geom_fox to implement multipathing on my machine. The setup
is: Dell PowerEdge 2600, 2 QLogic 2312 FC Adapters, 2 Brocade 2800 Switches,
1 Compaq HSG 80 FC array with 2 redundant FC controllers. I wrote the magic
labels on the disks, according to the script in the announce message:

geom_fox is no where close to finished yet, and your ideas mirror some
of the stuff on my TODO list.

Time, unfortunately, is in short supply for me.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Approval for Hotfix needed for portscanner (was Re: Error assigning master socket: Too many open files)

2003-10-22 Thread Andreas Klemm
On Wed, Oct 22, 2003 at 03:30:41PM +0100, Peter Edwards wrote:
 The patch applied by the port appears bogus. It adds braces around an 
 if that stops it executing the way it was intended. I've a sneaking 
 suspicion that the braces were added for clarity, but the indentation 
 in the original file is so badly off that the terminating brace was put 
 in the wrong place. Try replacing patch-ab with this:
 
 --- portscanner.c.orig  Wed Aug 19 18:37:44 1998
 +++ portscanner.c   Wed Oct 22 15:28:05 2003
 @@ -25,8 +25,8 @@
 /***/
 
 #include stdio.h
 -#include sys/socket.h
 #include sys/types.h
 +#include sys/socket.h
 #include netinet/in.h
 #include unistd.h
 #include netdb.h

Hi Peter,

thanks a lot for your help. You're completely right with your
diagnose and fix.

I'll put portmgr@ on Cc: to be allowed to commit the change
and will happily apply your fix to the port if I get the approval.

look here:

[EMAIL PROTECTED] /usr/ports/security/portscanner portscanner -b 1 -e 6 -vv 
xx.xx.xx.xxx
Resolving: xx.xx.xx.xxx - resolved
Current address: xx.xx.xx.xxx
Port range: 1 to 6
Port 135 found. Service name: loc-srv
Port 445 found. Service name: microsoft-ds
Port 1025 found. Service name: blackjack

Port scan finished !

After changing the patch and reinstalling the port,
the portscanner is completely functional again now.

Best regards

Andreas ///

-- 
Andreas Klemm - Powered by FreeBSD 5.1-CURRENT
Need a magic printfilter today ? - http://www.apsfilter.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


i386_set_ldt warnings

2003-10-22 Thread C. Kukulies
Some (kde) applications now have a warning appear in xconsole:

Warning: pid 595 used static ldt allocation.
See the i386_set_ldt man page for more info
Warning: pid 596 used static ldt allocation.
See the i386_set_ldt man page for more info

Should I worry about that? Rebuild KDE?

--
Chris Christoph P. U. Kukulies kukulies (at) rwth-aachen.de

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


Re: Approval for Hotfix needed for portscanner (was Re: Error assigning master socket: Too many open files)

2003-10-22 Thread Joe Marcus Clarke
On Wed, 2003-10-22 at 11:31, Andreas Klemm wrote:
 On Wed, Oct 22, 2003 at 03:30:41PM +0100, Peter Edwards wrote:
  The patch applied by the port appears bogus. It adds braces around an 
  if that stops it executing the way it was intended. I've a sneaking 
  suspicion that the braces were added for clarity, but the indentation 
  in the original file is so badly off that the terminating brace was put 
  in the wrong place. Try replacing patch-ab with this:
  
  --- portscanner.c.orig  Wed Aug 19 18:37:44 1998
  +++ portscanner.c   Wed Oct 22 15:28:05 2003
  @@ -25,8 +25,8 @@
  /***/
  
  #include stdio.h
  -#include sys/socket.h
  #include sys/types.h
  +#include sys/socket.h
  #include netinet/in.h
  #include unistd.h
  #include netdb.h
 
 Hi Peter,
 
 thanks a lot for your help. You're completely right with your
 diagnose and fix.
 
 I'll put portmgr@ on Cc: to be allowed to commit the change
 and will happily apply your fix to the port if I get the approval.
 
 look here:
 
 [EMAIL PROTECTED] /usr/ports/security/portscanner portscanner -b 1 -e 6 -vv 
 xx.xx.xx.xxx
 Resolving: xx.xx.xx.xxx - resolved
 Current address: xx.xx.xx.xxx
 Port range: 1 to 6
 Port 135 found. Service name: loc-srv
 Port 445 found. Service name: microsoft-ds
 Port 1025 found. Service name: blackjack
 
 Port scan finished !
 
 After changing the patch and reinstalling the port,
 the portscanner is completely functional again now.

Go for it.

Joe

 
 Best regards
 
   Andreas ///
-- 
PGP Key : http://www.marcuscom.com/pgp.asc




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


Re: i386_set_ldt warnings

2003-10-22 Thread Daniel Eischen
On Wed, 22 Oct 2003, C. Kukulies wrote:

 Some (kde) applications now have a warning appear in xconsole:
 
 Warning: pid 595 used static ldt allocation.
 See the i386_set_ldt man page for more info
 Warning: pid 596 used static ldt allocation.
 See the i386_set_ldt man page for more info
 
 Should I worry about that? Rebuild KDE?

Let me guess.  You are using Nividia-supplied drivers/libraries?

It won't bother you unless you want to use libkse or libthr
for your threading library instead of libc_r.  Seeing that
libc_r won't be the default sometime after 5.2-RELEASE, you
might want to complain to NVidia.

Do they supply source or is it binary only?

-- 
Dan Eischen

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


Sleep mutex panic (smbfs)

2003-10-22 Thread Robin P. Blanchard
System from about a week ago just panic'd (unfortunately do not have
kernel.debug lying around). The panic string was:

Lock (sleep mutext)
Srslock not locked
In /usr/src/sys/netsmb/smb_iod.c:97

While down, I put on a new kernel with sources from yesterday. But looks like
said file hasn't been updated in some time:

# fgrep FreeBSD smb_iod.c 
__FBSDID($FreeBSD: src/sys/netsmb/smb_iod.c,v 1.14 2003/08/23 21:43:33
marcel Exp $);


---
Robin P. Blanchard
Systems Integration Specialist
Georgia Center for Continuing Education
fon: 706.542.2404   fax: 706.542.6546
---

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


Re: i386_set_ldt warnings

2003-10-22 Thread Steve Kargl
On Wed, Oct 22, 2003 at 12:09:43PM -0400, Daniel Eischen wrote:
 On Wed, 22 Oct 2003, C. Kukulies wrote:
 
  Some (kde) applications now have a warning appear in xconsole:
  
  Warning: pid 595 used static ldt allocation.
  See the i386_set_ldt man page for more info
  Warning: pid 596 used static ldt allocation.
  See the i386_set_ldt man page for more info
  
  Should I worry about that? Rebuild KDE?
 
 Let me guess.  You are using Nividia-supplied drivers/libraries?
 
 It won't bother you unless you want to use libkse or libthr
 for your threading library instead of libc_r.  Seeing that
 libc_r won't be the default sometime after 5.2-RELEASE, you
 might want to complain to NVidia.
 
 Do they supply source or is it binary only?
 

I see similar messages on the console and I do not
have a nvidia card.  By the time I find the message
the process has terminated, so I have no way of
translating the PID into an actual executable name.

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


success (Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted)

2003-10-22 Thread Michal
I found easy way to ugen problem:
in /etc/devfs.rules I added
[local_ruleset=10]
add path 'ugen*' mode 664
then in /etc/rc.conf
devfs_system_ruleset=local_ruleset
And this is it. Now user can acces camera (PowerShots50) with gtkam. The 
resolution was given by 
(http://lists.freebsd.org/pipermail/freebsd-current/2003-September/009706.html) 
Jeff Walters*. *Based on man devfs it is impossible to resolve this issue. *
*

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


Re: i386_set_ldt warnings

2003-10-22 Thread Dan Nelson
In the last episode (Oct 22), Steve Kargl said:
 On Wed, Oct 22, 2003 at 12:09:43PM -0400, Daniel Eischen wrote:
  On Wed, 22 Oct 2003, C. Kukulies wrote:
   Some (kde) applications now have a warning appear in xconsole:
   
   Warning: pid 595 used static ldt allocation.
   See the i386_set_ldt man page for more info
  
  Let me guess.  You are using Nividia-supplied drivers/libraries?
 
 I see similar messages on the console and I do not have a nvidia
 card.  By the time I find the message the process has terminated, so
 I have no way of translating the PID into an actual executable name.

That's cause whoever coded the warning forgot to print the executable
name in the error message.  Try this patch:

Index: sys_machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/sys_machdep.c,v
retrieving revision 1.91
diff -u -r1.91 sys_machdep.c
--- sys_machdep.c   7 Sep 2003 05:23:28 -   1.91
+++ sys_machdep.c   22 Oct 2003 16:52:49 -
@@ -464,8 +464,8 @@
if (!(uap-start == LDT_AUTO_ALLOC  uap-num == 1)) {
/* complain a for a while if using old methods */
if (ldt_warnings++  NUM_LDT_WARNINGS) {
-   printf(Warning: pid %d used static ldt allocation.\n,
-   td-td_proc-p_pid);
+   printf(Warning: pid %d (%s) used static ldt allocation.\n,
+   td-td_proc-p_pid, td-td_proc-p_comm);
printf(See the i386_set_ldt man page for more info\n);
}
/* verify range of descriptors to modify */


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


SCSI cd errors

2003-10-22 Thread Sven Esbjerg
I upgraded my PC yesterday and have experienced hangs in boot. It seems
like something has changed in the SCSI or GEOM code. I have an Advansys SCSI
controller with two plextor CD drivers attached as well as a HP scanner.
When the CD drives are detected the system hangs. Booting with verbose output
shows errors and timeouts.

The errors:

(probe2:adv0:0:2:0): Retrying Command
(probe2:adv0:0:2:0): error 22
(probe2:adv0:0:2:0): Unretryable Error
(probe4:adv0:0:4:0): error 22
(probe4:adv0:0:4:0): Unretryable Error
(probe6:adv0:0:6:0): error 22
(probe6:adv0:0:6:0): Unretryable Error
GEOM: create disk cd0 dp=0xc68d9e00
GEOM: create disk cd1 dp=0xc6916e00
pass0 at adv0 bus 0 target 2 lun 0
pass0: HP C7670A 3925 Fixed Processor SCSI-2 device 
pass0: 3.300MB/s transfers
pass1 at adv0 bus 0 target 4 lun 0
pass1: PLEXTOR CD-R   PX-W1210S 1.00 Removable CD-ROM SCSI-2 device 
pass1: 10.000MB/s transfers (10.000MHz, offset 15)
pass2 at adv0 bus 0 target 6 lun 0
pass2: PLEXTOR CD-ROM PX-32TS 1.02 Removable CD-ROM SCSI-2 device 
pass2: 10.000MB/s transfers (10.000MHz, offset 15)
pass0 at adv0 bus 0 target 2 lun 0
pass0: HP C7670A 3925 Fixed Processor SCSI-2 device 
pass0: 3.300MB/s transfers
GEOM: new disk cd0
GEOM: new disk cd1
SMP: AP CPU #1 Launched!
SMP: CPU1 ap_init():
 lint0: 0x00010700 lint1: 0x00010400 TPR: 0x SVR: 0x01ff
(cd0:adv0:0:4:0): Retrying Command
(cd1:adv0:0:6:0): Retrying Command
(cd0:adv0:0:4:0): error 6
(cd0:adv0:0:4:0): Unretryable Error
cd0 at adv0 bus 0 target 4 lun 0
cd0: PLEXTOR CD-R   PX-W1210S 1.00 Removable CD-ROM SCSI-2 device 
cd0: 10.000MB/s transfers (10.000MHz, offset 15)
cd0: Attempt to query device size failed: NOT READY, Medium not present -
tray closed
(cd1:adv0:0:6:0): error 6
(cd1:adv0:0:6:0): Unretryable Error
cd1 at adv0 bus 0 target 6 lun 0
cd1: PLEXTOR CD-ROM PX-32TS 1.02 Removable CD-ROM SCSI-2 device 
cd1: 10.000MB/s transfers (10.000MHz, offset 15)
cd1: Attempt to query device size failed: NOT READY, Medium not present
(cd0:adv0:0:4:0): error 6
(cd0:adv0:0:4:0): Unretryable Error
(cd0:adv0:0:4:0): error 6
(cd0:adv0:0:4:0): Unretryable Error
(cd1:adv0:0:6:0): error 6
(cd1:adv0:0:6:0): Unretryable Error
(cd1:adv0:0:6:0): error 6
(cd1:adv0:0:6:0): Unretryable Error

It hangs after announcing it has launched CPU #1 when it prints:
(cd0:adv0:0:4:0): Retrying Command

uname -an
FreeBSD enzo.home.xbsd.net 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Oct 21
21:39:57 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ENZO i386

Full dmesg attached.

If any other info is needed please ask.

Sven Esbjerg
 
060
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=30911106)
pcibios: BIOS version 2.10
Using $PIR table, 8 entries at 0xc00fdef0
PCI-Only Interrupts: 5 10 11 12
Location  Bus Device Pin  Link  IRQs
slot 1  07A   0x02  3 4 5 7 9 10 11 12 14 15
slot 1  07B   0x03  3 4 5 7 9 10 11 12 14 15
slot 1  07C   0x04  3 4 5 7 9 10 11 12 14 15
slot 1  07D   0x01  3 4 5 7 9 10 11 12 14 15
slot 2  08A   0x03  3 4 5 7 9 10 11 12 14 15
slot 2  08B   0x04  3 4 5 7 9 10 11 12 14 15
slot 2  08C   0x01  3 4 5 7 9 10 11 12 14 15
slot 2  08D   0x02  3 4 5 7 9 10 11 12 14 15
slot 3  09A   0x04  3 4 5 7 9 10 11 12 14 15
slot 3  09B   0x01  3 4 5 7 9 10 11 12 14 15
slot 3  09C   0x02  3 4 5 7 9 10 11 12 14 15
slot 3  09D   0x03  3 4 5 7 9 10 11 12 14 15
slot 4  0   10A   0x01  3 4 5 7 9 10 11 12 14 15
slot 4  0   10B   0x02  3 4 5 7 9 10 11 12 14 15
slot 4  0   10C   0x03  3 4 5 7 9 10 11 12 14 15
slot 4  0   10D   0x04  3 4 5 7 9 10 11 12 14 15
slot 5  0   11A   0x02  3 4 5 7 9 10 11 12 14 15
slot 5  0   11B   0x03  3 4 5 7 9 10 11 12 14 15
slot 5  0   11C   0x04  3 4 5 7 9 10 11 12 14 15
slot 5  0   11D   0x01  3 4 5 7 9 10 11 12 14 15
slot 6  0   12A   0x03  3 4 5 7 9 10 11 12 14 15
slot 6  0   12B   0x04  3 4 5 7 9 10 11 12 14 15
slot 6  0   12C   0x01  3 4 5 7 9 10 11 12 14 15
slot 6  0   12D   0x02  3 4 5 7 9 10 11 12 14 15
slot 7  0   13A   0x04  3 4 5 7 9 10 11 12 14 15
slot 7  0   13B   0x01  3 4 5 7 9 10 11 12 14 15
slot 7  0   13C   0x02  3 4 5 7 9 10 11 12 14 15
slot 7  0   13D   0x03  3 4 5 7 9 10 11 12 14 15
embedded01A   0x01  3 4 5 7 9 10 11 12 14 15
embedded01B   0x02  3 4 5 7 9 10 11 12 14 15
embedded01C   0x03  3 4 5 7 9 10 11 12 14 15
embedded01D   0x04  3 4 5 7 9 10 11 12 14 15
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 0 dev 17 func 0
acpi0: Power Button (fixed)
ACPI timer looks GOOD min = 2, max = 3, width = 1
ACPI timer looks GOOD min = 2, max = 3, width = 1
ACPI timer looks GOOD min = 2, max = 3, width = 1
ACPI timer looks GOOD min = 2, max = 3, width = 1
ACPI 

Re: SCSI cd errors

2003-10-22 Thread Bernd Walter
On Wed, Oct 22, 2003 at 07:47:14PM +0200, Sven Esbjerg wrote:
 I upgraded my PC yesterday and have experienced hangs in boot. It seems
 like something has changed in the SCSI or GEOM code. I have an Advansys SCSI
 controller with two plextor CD drivers attached as well as a HP scanner.
 When the CD drives are detected the system hangs. Booting with verbose output
 shows errors and timeouts.

 adv0: AdvanSys ASC3030/50 SCSI controller port 0x9000-0x90ff mem 
 0xfa221000-0xfa2210ff irq 2 at device 7.0 on pci0

irq2 is bogus - there is no such thing since 80286 systems.
Disabling irq2/9 in BIOS setup may help to work around.

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

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


Re: SCSI cd errors

2003-10-22 Thread Scott Lambert
On Wed, Oct 22, 2003 at 07:59:32PM +0200, Bernd Walter wrote:
 On Wed, Oct 22, 2003 at 07:47:14PM +0200, Sven Esbjerg wrote:
  I upgraded my PC yesterday and have experienced hangs in boot. It seems
  like something has changed in the SCSI or GEOM code. I have an Advansys SCSI
  controller with two plextor CD drivers attached as well as a HP scanner.
  When the CD drives are detected the system hangs. Booting with verbose output
  shows errors and timeouts.
 
  adv0: AdvanSys ASC3030/50 SCSI controller port 0x9000-0x90ff mem 
  0xfa221000-0xfa2210ff irq 2 at device 7.0 on pci0
 
 irq2 is bogus - there is no such thing since 80286 systems.
 Disabling irq2/9 in BIOS setup may help to work around.

My Dual PPro200 seems to like IRQ 2:

14:25:32 Wed Oct 22 $ listirqs.sh 
IOAPIC #0 intpin 17 - irq 10
IOAPIC #0 intpin 18 - irq 2
IOAPIC #0 intpin 19 - irq 11
atkbd0: irq 1
atapci1: irq 2
atapci2: irq 2
bt0: irq 2
fxp0: irq 2
sio1  irq 3
sio0  irq 4
fdc0: irq 6
ahc0: irq 10
psmcpnp0: irq 12
ata0: irq 14
ata1: irq 15

It's been that way for a long time.

-- 
Scott LambertKC5MLE   Unix SysAdmin
[EMAIL PROTECTED]  

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


Re: i386_set_ldt warnings

2003-10-22 Thread Andre Guibert de Bruet

On Wed, 22 Oct 2003, Dan Nelson wrote:

 In the last episode (Oct 22), Steve Kargl said:
  On Wed, Oct 22, 2003 at 12:09:43PM -0400, Daniel Eischen wrote:
   On Wed, 22 Oct 2003, C. Kukulies wrote:
Some (kde) applications now have a warning appear in xconsole:
   
Warning: pid 595 used static ldt allocation.
See the i386_set_ldt man page for more info
  
   Let me guess.  You are using Nividia-supplied drivers/libraries?
 
  I see similar messages on the console and I do not have a nvidia
  card.  By the time I find the message the process has terminated, so
  I have no way of translating the PID into an actual executable name.

 That's cause whoever coded the warning forgot to print the executable
 name in the error message.  Try this patch:

 Index: sys_machdep.c
 ===
 RCS file: /home/ncvs/src/sys/i386/i386/sys_machdep.c,v
 retrieving revision 1.91
 diff -u -r1.91 sys_machdep.c
 --- sys_machdep.c 7 Sep 2003 05:23:28 -   1.91
 +++ sys_machdep.c 22 Oct 2003 16:52:49 -
 @@ -464,8 +464,8 @@
   if (!(uap-start == LDT_AUTO_ALLOC  uap-num == 1)) {
   /* complain a for a while if using old methods */
   if (ldt_warnings++  NUM_LDT_WARNINGS) {
 - printf(Warning: pid %d used static ldt allocation.\n,
 - td-td_proc-p_pid);
 + printf(Warning: pid %d (%s) used static ldt allocation.\n,
 + td-td_proc-p_pid, td-td_proc-p_comm);
   printf(See the i386_set_ldt man page for more info\n);
   }
   /* verify range of descriptors to modify */

This could also be accomplished by enabling process accounting and
grepping the output of lastcomm. But yes, this patch is most welcome
nonetheless. :)

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]


ACPI trouble with EPIA-M

2003-10-22 Thread Thorsten Greiner
Hi everybody,

I have a VIA EPIA-M 1 board which works mostly when I disable
ACPI in the bios. Unfortunately the parallel port is controlled by
some Super-IO chip and is not recognized during boot. The same holds
true for serial ports and the floppy controller.

When I enable ACPI in the bios the machine boots normally and
recognizes the parallel port BUT stops after displaying the hd/cdrom
identification , at the point where it would normally start init
(before the Mounting root from ... is displayed).

At this point it just stops. I can break into DDB but nothing
else...

This machine is running a custom kernel based on GENERIC with
several device drivers removed and debugging stuff disabled (DDB is
still there), cvsupped Oct 17. There are no ACPI error messages
displayed during the boot process.

I will happily provide more information on request. Please help me
to get this parallel port going as I want to hook up my printer
there. Thanks!

Regards
-Thorsten

-- 
If you understand what you're doing, you're not learning anything.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: i386_set_ldt warnings

2003-10-22 Thread Dan Nelson
In the last episode (Oct 22), Andre Guibert de Bruet said:
 This could also be accomplished by enabling process accounting and
 grepping the output of lastcomm. But yes, this patch is most welcome
 nonetheless. :)

lastcomm doesn't include the pid, so that would be most difficult :)

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


struct kinfo_proc-ki_tsize is inaccurate

2003-10-22 Thread Chris Bond
Greetings,

When I use kvm_getprocs() together with KERN_PROC_PID to get process
information, the structure it returns contains an inaccurate ki_tsize (text
segment size) variable.  On my machine, it seems to alternate--seemingly at
random--between 1 and 168, neither of which is correct.  The process in
question is suspended when I make the call (ptrace(PT_TRACE_ME...)).

Just wondering what the deal is.


Chris

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


Fwd: gcc compiler issues with gcc version 3.3.1...,,, on freebsd 5-current

2003-10-22 Thread Dorin Hogea
What upgrade path did you use to get to 5.x/CURRENT?
Did you remember to
clear out /usr/include/g++ and perform an
installworld as stated in
current if you've come from 4.x (or a mid-2002
CURRENT)?

I have identical errors while compiling the kde port
(cvsuped on 2003/10/20).  The base system was cvsuped
on 2003/10/06.  Just to make sure I do the right
thing:
1. do I have to delete:
/usr/include/g++ 
or 
/usr/include/c++ (as errors come from the folder
/usr/include/c++/3.3/bits/*.tcc)?
2. To speed up the process, can I run directly make
installworld from single user mode without going
through all the steps from handbook? I haven't deleted
anything yet from the last make installworld
process...

Tbank you and have a good day,
/Dorin.



__
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: i386_set_ldt warnings

2003-10-22 Thread Daniel Eischen
On Wed, 22 Oct 2003, C. Kukulies wrote:

 Some (kde) applications now have a warning appear in xconsole:
 
 Warning: pid 595 used static ldt allocation.
 See the i386_set_ldt man page for more info
 Warning: pid 596 used static ldt allocation.
 See the i386_set_ldt man page for more info
 
 Should I worry about that? Rebuild KDE?

[ ...and all the other responses ]

XFree86 can also load modules, so printing the name of
the process may not help if that is the case.  You can
always try:

$ nm /usr/X11R6/lib/modules/*.a | grep ldt
$ nm /usr/X11R6/lib/modules/*.so.* | grep ldt
$ nm /usr/X11R6/lib/modules/*.a | grep ldt

You can also try it on other libraries and binaries
(if they aren't stripped).

-- 
Dan Eischen

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


Re: panic: Memory modified after free

2003-10-22 Thread Doug White
On Mon, 20 Oct 2003, othermark wrote:

 I have a strange panic during the isa pnp code that does not occur with a
 5.0-release kernel.  I have tried enabling and disabling acpi.  it does
 not effect this panic one way or another.  This is a kernel from -current
 10/20 (today).  I'm not sure how to get this to boot with no way to disable
 pnp probing (pnpbios(4)).

Can you pull out or disable the gig-e card?  Its having trouble
initializing, and I'm wondering if its doing something bad in the process.

That or perhaps you have bad memory.  Do you have ECC RAM in the system?

Here is the failed em attach:

 em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.16 mem
 0xfeae-0xf
 eaf irq 5 at device 0.0 on pci1
 em0: [MPSAFE]
 em0: Hardware Initialization Failedem0: Unable to initialize the hardware
 device_probe_and_attach: em0 attach returned 5

The other em failing (intel motherboard?):

 em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.16 mem
 0xfebe-0xf
 ebf irq 9 at device 1.0 on pci2
 em0: [MPSAFE]
 em0: Hardware Initialization Failedem0: Unable to initialize the hardware
 device_probe_and_attach: em0 attach returned 5

Here is the panic again:

 Memory modified after free 0xc4758800(2044) val=c4756800 @ 0xc47589dc
 panic: Most recently used by bus-sc

 Debugger(panic)
 Stopped at  Debugger+0x54:  xchgl   %ebx,in_Debugger.0
 db where
 Debugger(c083c6e1,c08fe300,c0853cc0,c0c21b4c,100) at Debugger+0x54
 panic(c0853cc0,c083dd01,7fc,c4756800,c47589dc) at panic+0xd5
 mtrash_ctor(c4758800,800,0,583,c4758800) at mtrash_ctor+0x67
 uma_zalloc_arg(c103ae40,0,1,2c21bbc,c0891040) at uma_zalloc_arg+0x1ce
 malloc(7ec,c0891040,1,c473dc80,c478f000) at malloc+0xd3
 isa_add_config(c4765b00,c478d280,0,c478f000,c478f000) at isa_add_config+0x33
 pnp_parse_resources(c478d280,c478e30e,19,0,c478e302) at pnp_parse_resource
 +0x3b8
 pnpbios_identify(c08d0db4,c4765b00,c0863280,c085d008,c08caab0) at
 pnpbios_identify+0x43f
 bus_generic_probe(c4765b00,c0c21d5c,c064f78e,c1cfd180,c474904c) at
 bus_generic_probe+0x62
 isa_probe_children(c4765b00,c08570dd,0,c0c21d98,c0610455) at
 isa_probe_children+0x14
 configure(0,c1e000,c1ec00,c1e000,0) at configure+0x4b
 mi_startup() at mi_startup+0xb5
 begin() at begin+0x2c
 db




-- 
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: warnings while kernel build

2003-10-22 Thread Doug White
On Wed, 22 Oct 2003, Vladimir B. Grebenschikov wrote:


 While build kernel on RELENG_4 machine I have following warnings (they
 prevent success build unless -Werror disabled)

Is there some reason you're trying to compile RELENG_4 with gcc 3.3, which
won't work?

 /ext/current/src# make -j8 buildkernel
 ...
 /ext/current/src/sys/kern/kern_descrip.c:1914: warning: inlining failed
 in call to `_fgetvp'

 makeoptions   CONF_CFLAGS=-O3 -mcpu=pentiumpro

This is an unsupported option.  Do not compile the kernel with any
optimization beyond -O.  This might be the other reason why you are
getting these inlining warnings.

gcc -v?

-- 
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: DVD+R burning flakey after ATAng.

2003-10-22 Thread Pierre Beyssac
On Mon, Oct 20, 2003 at 09:10:39PM -0400, David Gilbert wrote:
 This all started screwing up with ATAng.  At first, ATAng didn't
 support atapicam, but that was rectified.  Now the dvd+rw port
 (growisofs) doesn't work at all ... it finishes with an error that I'm
 loathe to coaster another (expensive) DVD to find out.  burncd will

I've only tried DVD+R burning with growisofs since ATAng. My drive
is a Ricoh MP5125. I've previously burned quite a few DVD+RW with
burncd, it mostly worked before ATAng and it still does.

One problem I have seen is at the fixation phase. I occasionaly
have growisofs returning an error at the end, sometimes it doesn't
seem to matter and sometimes it does (no TOC, preventing any access).
In the latter case I then tried a burncd fixate on it which made
the coaster back into a DVD. It's funny enough since burncd is not
supposed to handle DVD+R AFAIK, but the Ricoh drive apparently did
the right thing anyway.

As usual, YMMV. In my case it's clearly not related to the ISO image
I put on the DVD.
-- 
Pierre Beyssac  [EMAIL PROTECTED] [EMAIL PROTECTED]
Free domains: http://www.eu.org/ or mail [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Ath0 Crash the PC

2003-10-22 Thread Marcos Biscaysaqu
Hi There.
With the debug on in hte kernel ZABU I found this when my Atheros card 
crash:

lock order reversal
1st 0xc36c1e84 rl0 (network driver) @ pci/if_rl.c:1485
2nd 0xc0766280 bridge (bridge) @ net/bridge.c:777
Stack backtrace:
lock order reversal
1st 0xc0768540 ifnet (ifnet) @ net/bridge.c:424
2nd 0xc379307c radix node head (radix node head) @ net/route.c:544
Stack backtrace:
looks like is a Bridge problem, I have the option BRIDGE in my kernel 
may be I need try another way to make the bridge work?

any idea.
thanks


Sam Leffler wrote:

On Tuesday 21 October 2003 06:49 pm, you wrote:
 

I using a pentium III 350Mghz 256 MB RAM , uniprocessor, PCI Atheros
Card Netgear WAG311 a/b/g  atheros chipset AR5212, same thing with a
DLINK PCI AR5212,  the last update of my source was yesterday, anyway  I
have the same problem with older versions.
   I trying now with a diferent PC to see what happend.
I hope this infromation help,  pls tell me if you need more information
   

Yes the information (especially dmesg) helps.

Build your kernel with DDB, INVARIANTS, and WITNESS and -g.  When you get a 
panic collect a stack trace from the ddb prompt and, if possible, a crash 
dump.  Also, if you have an 11a AP try using this machine as a station and 
load the network with tools like netperf and see if you crash..  Also, if you 
have different NIC's, try replacing the RealTek with something else.  I 
typically use fxp or em devices with an Intel Pro/1000 my favorite NIC.

Finally, I notice you have ipfw+divert configured.  I don't know if it is 
being used but if so remove it.  In general try to reduce the system 
configuration to the minimum you need to run tests.

Attached is a typicaly kernel configuration I use for debugging.  I'm 
providing it solely so you can see how to enable the stuff above.

	Sam
 



machine i386
cpu I686_CPU
ident   ZABU
maxusers0
#To statically compile in device wiring instead of /boot/device.hints
#hints  GENERIC.hints   #Default places to look for devices.
makeoptions	DEBUG=-g		#Build kernel with gdb(1) debug symbols

options SCHED_4BSD  #4BSD scheduler
options INET#InterNETworking
options INET6   #IPv6 communications protocols
options FFS #Berkeley Fast Filesystem
options SOFTUPDATES #Enable FFS soft updates support
options UFS_DIRHASH #Improve performance on big directories
options NFSCLIENT   #Network Filesystem Client
options NFSSERVER   #Network Filesystem Server
options MSDOSFS #MSDOS Filesystem
options CD9660  #ISO 9660 Filesystem
options PROCFS  #Process filesystem (requires PSEUDOFS)
options PSEUDOFS#Pseudo-filesystem framework
options COMPAT_43   #Compatible with BSD 4.3 [KEEP THIS!]
options COMPAT_FREEBSD4 #Compatible with FreeBSD4
options KTRACE  #ktrace(1) support
options SYSVSHM #SYSV-style shared memory
options SYSVMSG #SYSV-style message queues
options SYSVSEM #SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions
# Debugging for use in -current
options DDB #Enable the kernel debugger
options INVARIANTS  #Enable calls of extra sanity checking
options INVARIANT_SUPPORT   #Extra sanity checks of internal structures, 
required by INVARIANTS
options WITNESS #Enable checks to detect deadlocks and cycles
options WITNESS_SKIPSPIN#Don't run witness on spinlocks for speed
options		COMPAT_LINUX

device  isa
device  eisa
device  pci
# Floppy drives
device  fdc
# ATA and ATAPI devices
device  ata
device  atadisk # ATA disk drives
device  atapicd # ATAPI CDROM drives
options ATA_STATIC_ID   #Static device numbering
# atkbdc0 controls both the keyboard and the PS/2 mouse
device  atkbdc  # AT keyboard controller
device  atkbd   # AT keyboard
device  psm # PS/2 mouse
device  vga # VGA video card driver
device  agp # support several AGP chipsets
device  sc  # syscons is the default console driver
device  npx # floating point support
device  acpi
# PCCARD (PCMCIA) support
# Pcmcia and cardbus bridge support
device  cbb # cardbus (yenta) bridge
#device pcic# ExCA ISA and PCI bridges
device  pccard

Re: i386_set_ldt warnings

2003-10-22 Thread Bruce Evans
On Wed, 22 Oct 2003, Daniel Eischen wrote:

 On Wed, 22 Oct 2003, C. Kukulies wrote:

  Some (kde) applications now have a warning appear in xconsole:
 
  Warning: pid 595 used static ldt allocation.
  See the i386_set_ldt man page for more info
  Warning: pid 596 used static ldt allocation.
  See the i386_set_ldt man page for more info
 
  Should I worry about that? Rebuild KDE?

 Let me guess.  You are using Nividia-supplied drivers/libraries?

I get these from an old version of wine.  I gave details of why wine
would break if static ldt allocation were removed when removing it
was proposed.

 Do they supply source or is it binary only?

It is effectively binary only, since current versions of wine don't
run my application correctly and the old version doesn't build under
-current.

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


Re: i386_set_ldt warnings

2003-10-22 Thread Jonathan E Fosburgh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wednesday 22 October 2003 10:06 pm, Bruce Evans wrote:
 On Wed, 22 Oct 2003, Daniel Eischen wrote:
  On Wed, 22 Oct 2003, C. Kukulies wrote:


 It is effectively binary only, since current versions of wine don't
 run my application correctly and the old version doesn't build under
 -current.

Is it some application that attempts to access network? For the last couple of 
weeks I have been unable to use Notes under Wine on -CURRENT, it keeps 
hanging trying to go out on the network.  This happened before between 5.0-R 
and 5.1-R, and was fixed somewhere in 5.1-CURRENT.  Unfortunately, I do not 
know what changes to break this.  So could it be an issue with FreeBSD and 
not Wine?

- -- 
Jonathan Fosburgh
AIX/SAN Administrator
UT MD Anderson Cancer Center
Houston, TX
Home Page:
http://www.fosburgh.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQE/l0iHqUvQmqp7omYRAqD2AJ9lKt0jLJlJfi3LKRo9+8fNXY8ePgCfQO+w
Z4w2630Y0dyszToZbq6ESFM=
=WmT1
-END PGP SIGNATURE-
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: __fpclassifyd problem

2003-10-22 Thread Peter Wemm
Daniel Eischen wrote:
 On Mon, 20 Oct 2003, M. Warner Losh wrote:
 
  In message: [EMAIL PROTECTED]
  Scott Long [EMAIL PROTECTED] writes:
  : We need to resolve this before 5.2 in some fashion.  It looks like the
  : easiest thing to do is bump libm.  Is this advisable?
  
  The problem with bumping libm is that we also need, strictly speaking,
  to bump all libarires that depend on libm, and that can be very ugly.
  This moves the bump the major version from the trivial fix class to
  something that we have to think real hard about.  In general one
  cannot bump the major version of 'base' libaries like this w/o careful
  thought and planning.  While we've done that in the past with libc, I
  think we were wrong to do so in some classes of symbol tampering.
  
  Warner ___
  [EMAIL PROTECTED] mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe,
  send any mail to [EMAIL PROTECTED]
  
 
 If it's just __fpclassifyd(), can you just add a compatability
 hack to libm so it works with both libc 4.0 and 5.x?  You
 can make __fpclassifyd a weak definition to the hack in libm.
 I suppose you could also add __fpclassfyd() to libc 4.0.

We tried this at usenix, but it still didn't work.  Obviously there is more
going on.

Before anybody goes and bumps libraries etc, it would be useful to know if
running a statically linked jvm will work on -current.  If that does, then
the next thing to try is using a complete exclusive set of 4.x libraries
and ld-elf.so.1 somewhere and running in a chroot environment.  The next
step is to use the 5.x ld-elf.so.1, but $LD_LIBRARY_PATH to search for and
find the 4.x libraries in preference to the 5.x ones.  And so on.  If it
still works at this point,  then try switching the unbumped libraries one
at a time until it breaks.

Bumping the library versions is only useful IF it actually solves the
problem.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: warnings while kernel build

2003-10-22 Thread Bruce Evans
On Wed, 22 Oct 2003, Doug White wrote:

 On Wed, 22 Oct 2003, Vladimir B. Grebenschikov wrote:

 
  While build kernel on RELENG_4 machine I have following warnings (they
  prevent success build unless -Werror disabled)

 Is there some reason you're trying to compile RELENG_4 with gcc 3.3, which
 won't work?

It works for me.

%%%
RCS file: /home/ncvs/src/sys/i386/i386/identcpu.c,v
Working file: identcpu.c
head: 1.130
...

revision 1.57.2.17
date: 2003/08/05 07:07:37;  author: bde;  state: Exp;  lines: +20 -20
MFC: 1.94 and 1.125 (don't use hard newlines in string literals, and fix
some style bugs on the same lines).

This completes making some RELENG_3 kernels work when compiled by gcc-3.3.

...

revision 1.80.2.16
date: 2003/08/05 07:05:39;  author: bde;  state: Exp;  lines: +19 -19
MFC: 1.94 and 1.125 (don't use hard newlines in string literals, and fix
some style bugs on the same lines).

This completes making some RELENG_4 kernels work when compiled by gcc-3.3.
I intended to make more than some work, but gave up on LINT.  GENERIC
compliles but has not been tested at runtime.

%%%

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


Re: __fpclassifyd problem

2003-10-22 Thread Scott Long
Peter Wemm wrote:
Daniel Eischen wrote:

On Mon, 20 Oct 2003, M. Warner Losh wrote:


In message: [EMAIL PROTECTED]
   Scott Long [EMAIL PROTECTED] writes:
: We need to resolve this before 5.2 in some fashion.  It looks like the
: easiest thing to do is bump libm.  Is this advisable?
The problem with bumping libm is that we also need, strictly speaking,
to bump all libarires that depend on libm, and that can be very ugly.
This moves the bump the major version from the trivial fix class to
something that we have to think real hard about.  In general one
cannot bump the major version of 'base' libaries like this w/o careful
thought and planning.  While we've done that in the past with libc, I
think we were wrong to do so in some classes of symbol tampering.
Warner ___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe,
send any mail to [EMAIL PROTECTED]
If it's just __fpclassifyd(), can you just add a compatability
hack to libm so it works with both libc 4.0 and 5.x?  You
can make __fpclassifyd a weak definition to the hack in libm.
I suppose you could also add __fpclassfyd() to libc 4.0.


We tried this at usenix, but it still didn't work.  Obviously there is more
going on.
Before anybody goes and bumps libraries etc, it would be useful to know if
running a statically linked jvm will work on -current.  If that does, then
the next thing to try is using a complete exclusive set of 4.x libraries
and ld-elf.so.1 somewhere and running in a chroot environment.  The next
step is to use the 5.x ld-elf.so.1, but $LD_LIBRARY_PATH to search for and
find the 4.x libraries in preference to the 5.x ones.  And so on.  If it
still works at this point,  then try switching the unbumped libraries one
at a time until it breaks.
Bumping the library versions is only useful IF it actually solves the
problem.
This sounds like a good plan, though it should be noted that statically 
linking the jvm executable will reder it useless since it won't be able
to dl_open any of the essential JNI modules.

Scott

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


Re: Ath0 Crash the PC

2003-10-22 Thread Sam Leffler
On Wednesday 22 October 2003 07:36 pm, Marcos Biscaysaqu wrote:
 Hi There.
 With the debug on in hte kernel ZABU I found this when my Atheros card
 crash:

 lock order reversal
  1st 0xc36c1e84 rl0 (network driver) @ pci/if_rl.c:1485
  2nd 0xc0766280 bridge (bridge) @ net/bridge.c:777
 Stack backtrace:
 lock order reversal
  1st 0xc0768540 ifnet (ifnet) @ net/bridge.c:424
  2nd 0xc379307c radix node head (radix node head) @ net/route.c:544
 Stack backtrace:


 looks like is a Bridge problem, I have the option BRIDGE in my kernel
 may be I need try another way to make the bridge work?

LOR's will not cause a system crash.  If a LOR causes a problem it will likely 
deadlock your system.

The two LORs shown above are known and should not be a problem.

Sam

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


Re: i386_set_ldt warnings

2003-10-22 Thread Daniel Eischen
On Thu, 23 Oct 2003, Bruce Evans wrote:

 On Wed, 22 Oct 2003, Daniel Eischen wrote:
 
  On Wed, 22 Oct 2003, C. Kukulies wrote:
 
   Some (kde) applications now have a warning appear in xconsole:
  
   Warning: pid 595 used static ldt allocation.
   See the i386_set_ldt man page for more info
   Warning: pid 596 used static ldt allocation.
   See the i386_set_ldt man page for more info
  
   Should I worry about that? Rebuild KDE?
 
  Let me guess.  You are using Nividia-supplied drivers/libraries?
 
 I get these from an old version of wine.  I gave details of why wine
 would break if static ldt allocation were removed when removing it
 was proposed.

I think we didn't care so much about wine because it could be
fixed in source to use dynamic ldt allocation.

  Do they supply source or is it binary only?
 
 It is effectively binary only, since current versions of wine don't
 run my application correctly and the old version doesn't build under
 -current.

Hmm, well one supposes that it could be made to build under
-current.

The messages really are harmless if threading (libkse, libthr)
is not used or if the static ldt allocations happen before
the threads library starts allocating ldts.

-- 
Dan Eischen

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


Re: __fpclassifyd problem

2003-10-22 Thread Daniel Eischen
On Wed, 22 Oct 2003, Peter Wemm wrote:

 Daniel Eischen wrote:
  If it's just __fpclassifyd(), can you just add a compatability
  hack to libm so it works with both libc 4.0 and 5.x?  You
  can make __fpclassifyd a weak definition to the hack in libm.
  I suppose you could also add __fpclassfyd() to libc 4.0.
 
 We tried this at usenix, but it still didn't work.  Obviously there is more
 going on.

I guess so.  That's weird because it seems like it should work.

-- 
Dan Eischen

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